高并发下控制库存超卖问题（个人建议仅供参考)

（1）库存锁定，预占库存并不真实的扣减库存，只是预先占用库存

（2）针对库存的重复提交问题，设置前端置灰

（3）拦截恶意用户的超量请求，超过50次进入恶意请求判定，放入redis生成用户锁，锁死用户下单操作一分钟，当释放锁之后，根据标记进入核定阶段判断用户是否需要进入下一阶段，结合redis list 做用户阶段性校验问题。（list需要设置过期时间，解决用户阶段重置问题）

redis list阶段性校验

通过list集合内存连续性，做阶段性校验。

（4）订单确认信息页

此处需要真正的扣减库存，并且生成订单，此前项目通过mq高并发延迟方式分离 下单和减库存操作。

订单生成之后发送mq消息，mq消息内扣减库存，存在库存扣减失败问题，造成需要tcc事务回退至上一步。

解决方案，redis内同步库存信息，下单操作时扣减redis内库存，真正的数据库同步通过mq延时消息进行，保证数据库和redis一致的问题相当重要，通过异步任务，测算库存数据是否双库一致问题相当重要。 最终一致性，redis库存和数据库会有一段时间的不一致，但是在延时消息全部执行完毕后，双库数据应保持一致。

本次库存扣减不使用redis分布式锁方式，通过redis原子性递减操作，进行库存的递减。

原子操作使用incr返回当前数值方式，无需再次get操作，否则高并发状态下会出现超卖问题。

记录库存扣减明细，进行库存后续矫正和零点问题排查。

（5）库存扣减明细表由于插入频繁，无需建立过多索引，故而需要同步至mongodb,从MongoDB读取数据进行对账校准问题。

数据库保持原子操作 判断库存不能小于0，高并发直接操作数据库，容易让数据库夯死，通过redis有效拦截请求IO直接至数据库。

redis解锁操作，需要通过lua脚本达到原子一致操作特性。

标签：库存,扣减,list,数据库,redis,并发,操作,超卖,仅供参考
来源： https://blog.csdn.net/ai_liuxl7/article/details/120533807