高并发下的库存扣减方案

https://blog.csdn.net/weixin_34221904/article/details/101690119

高并发下的库存扣减方案
背景
直接进入主题：如果老板让你设计一套高并发下的库存扣减方案，不能出现超买超卖。你是否有相似的工作经验？是否有方案的设计思路？近些年在营销项目组的工作经验让我对【库存扣减】的方案有了些许认知，接下来的文章，带着大家感受下从0-1的库存扣减方案的的诞生，欢迎大家的指导！

那年还很low（DB）
刚开始我们的营销项目组身单力薄，人微言轻；那时营销业务才刚开始发展，此时我们把业务放到第一位，技术方案为满足时间内业务发展所让步。大家应该可以猜到，这个时候我们很low的库存扣减方案-直接上数据库。根据业务诉求，每个活动会保存一份实时变化的库存，参与活动时，实时扣减数据库，操作步骤如下：

①接收业务扣减库存请求
②数据库查询单个活动库存，并对查询的单条数据加锁（select * from 库存表 for update）
③验证库存是否满足扣减数量，满足则扣除

线上遇到了问题(DB锁优化)
可想而知，好景不长，当线上业务逐渐增长，数据库出现了瓶颈。表现主要是数据库性能低，大量的资源处于等待锁的状态，影响线上业务，影响用户体验。当然这里主要原因还是活动库存记录为热点数据，当收到大量扣减库存请求时，针对同一个活动的库存扣减会因为数据库行锁导致大量线程等待。