高并发下库存扣减方案：从数据库锁到Redis+Lua防超卖

先抛个问题你有没有半夜上线过一个卖爆的商品第二天醒来发现后台库存变成了负数或者更尴尬一点明明库存只剩10件却卖出了30单客服电话被打爆技术群里哀嚎一片。如果你经历过那你大概率已经和“库存扣减”这个问题正面交过手了。库存扣减这件事单看业务逻辑特别简单——用户下单库存减一。但一旦把它放到高并发、分布式、多服务的真实电商环境里它就变成了一个集并发控制、数据一致性、系统稳定性于一体的经典难题。很多人觉得库存扣减难难的不是“减库存”这个动作而是怎么保证“不该卖的时候一件都卖不出去该卖的时候一件都不能少”。这篇内容我会把库存扣减的常见方案、底层原理、踩坑细节全部拆开揉碎讲一遍适合正在做电商系统、或者准备做秒杀活动的后端开发者参考哪怕你是刚接触订单系统的新人也能从里面找到可以直接落地的思路。1. 库存扣减的本质先想清楚钱和货的关系库存扣减之所以成为难题是因为它本质上不是一个技术问题而是一个“资源分配”问题。库存是有限的买家是无限的当有限的资源被无限地竞争时就必须有规则来保证分配结果的正确性。而技术难题只是这个规则在执行层面的体现。1.1 为什么库存扣减会引发超卖超卖的根本原因是“检查与操作之间有时间差”。举个例子两个用户同时发起购买请求系统先后都查到剩余库存为1都认为“还有货”于是都执行了扣减操作库存变成了-1。这就是典型的“读取-判断-写入”三步操作没有形成原子性导致的竞态条件。很多人第一反应是“用事务锁住不就完了吗”但问题远没有这么简单。在单体应用的早期阶段用数据库事务确实能扛住大部分问题但到了微服务架构、库存中心独立部署之后服务之间的调用变成了网络请求事务的边界被拉长单纯的数据库事务已经无法覆盖整个链路。再加上高并发场景下的性能压力库存扣减就演变成了一个需要权衡一致性、可用性、性能的系统设计问题。1.2 先选好扣减时机下单扣、支付扣还是预占扣在动手写代码之前先想清楚一个关键决策什么时候扣库存这个决定直接影响了整个订单流程的走向。下单即扣减用户提交订单后立刻锁定库存。优点是能保证下单成功的用户一定有货可发体验最好缺点很明显——如果用户下单后不支付库存就被白白占住造成“虚假库存”。据统计电商场景下未支付订单的比例普遍在20%以上如果全量采用下单即扣库存会被大量浪费。支付再扣减用户支付成功后扣库存。优点是不会被未支付订单浪费库存缺点更致命——用户下单时明明看到有货支付时却提示“库存不足”体验极其糟糕严重时甚至引发客诉和舆情。预占超时释放下单时冻结库存同时启动一个超时任务超过一定时间未支付就自动释放。这是目前主流电商普遍采用的折中方案兼顾了体验和库存周转率。我的观点很明确除非你的业务明确是“先款后货”的强预订模式否则不要用纯粹的支付再扣减方案。预占释放是目前权衡体验和效率的最优解后续所有技术选型都建立在这个业务决策之上。1.3 从下单到支付的全流程视角一旦选择了预占超时释放库存扣减的范围就不仅是“下单”这一个动作了。完整的库存流转链路是这样的用户在商品页看到的“剩余库存”来源于库存中心的实时数字。用户提交订单库存中心冻结对应的数量。用户支付成功库存中心把冻结量扣除转为实际扣减。用户超时未支付或主动取消库存中心释放冻结量。这个流程意味着库存中心对外要提供三类基础能力可售库存查询、冻结扣减、释放回补。这些能力背后的并发控制才是库存扣减方案的核心战场。2. 数据库层的并发控制最稳妥的地基库存系统的数据最终一定要落在数据库里所以数据库层的并发控制是所有方案的地基同时它也是目前绝大多数中小业务规模下最可靠、最简单的选择。2.1 悲观锁SELECT ... FOR UPDATE 的硬核方案悲观锁的核心思路很简单我先把这条数据锁住别人谁也别想动等我改完了再放开。实现方式就是在事务里对库存记录执行SELECT ... FOR UPDATE这时候当前事务就持有了该行的排他锁其他事务想读这一行做更新操作时会被阻塞直到当前事务提交或回滚。BEGIN; SELECT stock FROM product WHERE sku_id 10001 FOR UPDATE; -- 业务代码里判断 stock 是否大于0 UPDATE product SET stock stock - 1 WHERE sku_id 10001; COMMIT;注意一个细节判断库存是否充足一定要在锁住之后、扣减之前完成。也就是说必须依赖SELECT ... FOR UPDATE之后读到的那个 stock 值来做判断而不是在锁之前先查一次。悲观锁的优点是一致性极强逻辑直观几乎不会出现超卖。但问题也很明显高并发下性能堪忧。所有请求串行排队锁的争用直接变成了延迟数据库的并发能力被大打折扣。我在实际项目中测过单机数据库在悲观锁模式下QPS能到1000就已经压力很大了这在秒杀场景下根本不够看。所以悲观锁的正确适用场景是并发量不大、但数据准确性要求极高、且不希望引入额外中间件的业务比如后台补货、人工调拨、低频率的订单创建。2.2 乐观锁轻量高效的乐观博弈乐观锁的思路是反过来的——我不锁我假设大概率没人跟我抢但我在更新的时候检查一下版本是否变了。实现方式通常有两种版本号方案和条件更新方案。版本号方案是在库存表里加一个version字段更新时携带旧的版本号如果版本号不匹配就说明有人抢先改过了本次更新失败UPDATE product SET stock stock - 1, version version 1 WHERE sku_id 10001 AND version 5;条件更新方案更轻量直接利用数据库的行锁机制在更新语句里带上库存条件UPDATE product SET stock stock - 1 WHERE sku_id 10001 AND stock 0;这两个方案里我强烈推荐stock 0这个条件更新方案。它不需要额外字段语义一目了然库存大于0才允许扣减。如果影响行数为0说明库存不足或已被其他并发事务抢先扣减应用层重新感知库存即可。乐观锁最大的优势是并发性能远高于悲观锁它利用了数据库自身的原子更新能力没有长时间的锁等待。缺点也很明显——它只保证了“扣减”这一步的正确性如果你的扣减动作不是一个简单的stock - 1比如需要先查库存然后做复杂业务逻辑再决定是否扣减就必须搭配版本号方案自己控制事务。2.3 悲观锁和乐观锁究竟怎么选很多人在这里反复纠结我给出一个简单判断标准如果你业务逻辑的核心就是“扣库存”这个动作优先选乐观锁条件更新方案如果扣减之前需要执行一大堆业务判断例如校验会员等级、优惠券状态、收货地址合法性这些判断和最终扣减必须是一个不可分割的整体那就别硬扛直接上悲观锁。另外补充一点不管用哪种锁数据库事务一定要记得设置合理的超时时间。尤其是悲观锁如果一个事务里做了一堆外部调用耗时过久锁的持有时间就会无限拉长整个系统的吞吐量都会被拖死。我见过一个翻车案例因为一个事务里调了一个超时的外部接口两分钟内下单接口全部卡死数据库连接池被占满这就是锁的副作用被无限放大的典型。2.4 事务的隔离级别与死锁规避在数据库层面做库存扣减时事务隔离级别的选择容易被忽略。MySQL默认的REPEATABLE READ级别对并发更新的影响并不大因为行锁的粒度足够细。不过需要特别留意的是间隙锁Gap Lock的副作用如果更新条件里用了范围查询可能会把整个索引区间锁住导致并发量骤降。库存扣减尽量用主键或唯一索引来定位数据行避免范围条件触发间隙锁。死锁也是事务型库存扣减的高发问题。常见的死锁场景是多个事务以不同的顺序更新同一个商品的两个库存维度例如总库存和可用库存。规避方案很简单——所有相关的更新语句固定为同一个顺序执行比如先更新总库存再更新可用库存全系统统一这个顺序死锁概率会大幅下降。另一个实用的经验是应用层要做好重试机制数据库返回死锁错误后自动重试一次不要一报错就直接抛给用户。3. Redis扣减方案应对高并发的主战场如果业务规模上去了数据库扛不住了那么缓存库存就是绕不开的选项。这里说的缓存库存指的是用Redis来承载高并发下的库存预扣减然后再异步同步到数据库做最终落地。3.1 Redis扣减为什么快单线程与原子性的双重优势Redis的扣减方案之所以能抗住高并发核心在于它天生适合做原子的“递减”操作。Redis是单线程处理命令的对单个key的读写是串行的不存在其他语言多线程环境下的竞态问题。更关键的是Redis提供了DECR命令它能在同一条指令里完成“读取库存-减少库存-写回库存”的整个原子操作DECR sku:stock:10001执行完这条命令后Redis内部就完成了商品的库存减一这期间不可能有另外的请求插入。要做到“库存不足时不能扣成负数”只要在执行DECR前先查看库存值即可但这个“查看”和“扣减”之间依然存在竞态窗口。要想彻底消除竞态就必须引入LUA脚本。3.2 用LUA脚本把“检查”和“扣减”变成一个原子动作LUA脚本之所以在Redis库存方案里不可或缺是因为它可以保证脚本中的多条Redis指令在同一个执行单元内完成不会被中间插入其他请求。库存扣减的核心LUA脚本如下local stock tonumber(redis.call(get, KEYS[1])) if not stock then -- 缓存中没有库存记录可以从数据库加载或拦截请求 return -1 end if stock 0 then -- 库存不足 return 0 end redis.call(decrby, KEYS[1], ARGV[1]) return 1调用这个脚本时传入库存key和扣减数量返回值1表示扣减成功0表示库存不足-1表示缓存未命中需要回源加载。利用Redis脚本的原子性“判断库存是否充足”和“执行扣减”这两个动作就不再存在时间差这是它和单纯DECR方案的本质区别。我要特别强调ARGV[1]扣减数量的灵活性。真实业务里用户往往不是只买一件扣减数量应该是一个动态参数而不是固定减1。DECRBY比DECR更通用脚本里用decrby是更工程化的选择。3.3 缓存库存与数据库库存的同步策略Redis扣减完成了数据库里不能没有记录。标准的做法是Redis是前置的水龙头数据库是后置的水库。用户的每一次下单先走Redis完成快速扣减然后把“下单事件”投递到消息队列由异步消费程序同步更新数据库中的真实库存。这个异步链路天然存在“Redis已经扣了数据库还没扣”的窗口期。一旦数据库扣减失败比如数据库连接异常、事务冲突就需要做补偿回滚——把Redis里的库存再加回去。常见的实现是消费程序捕获异常后发送一个回补消息调用Redis执行INCR或INCRBY回补。更稳的做法是引入定时对账任务每过一段时间比如5分钟系统扫描某一段时间内的订单比对“Redis扣减记录”和“数据库库存变更记录”发现不一致的自动补单或回补。对账机制是异步方案里最后一道防线没有对账的异步扣减方案我可以说基本是不完整的因为它没法保证最终一致性。3.4 库存回补与过期处理Redis里的库存key还面临一个容易被忽视的问题过期时间。很多同学把库存写进Redis后不设置过期时间或者设置了很长的过期结果促销结束后key一直占着内存。折中的做法是给库存key设置一个合理的过期时间比如24小时同时在每次扣减后重置TTL。但要小心一个问题——如果key过期了正想抢购的用户就会触发回源逻辑从数据库重新加载库存到Redis那个瞬间所有的并发请求都会打到数据库上形成缓存击穿。应对缓存击穿的常规三板斧是互斥锁重建只允许一个请求回源加载库存、逻辑过期不设置实际TTL而是在值里存一个过期时间戳、永远不过期定时任务刷新。这几招单独用都有缺陷最好结合使用比如互斥锁加固逻辑过期既能避免击穿又能防止库存永远不更新。4. 扣减方案选型的完整对照与实战排查经验讲了这么多方案很多人最想问的是一个特别接地气的我到底该用哪种我把这个问题放到实战经验这章来回答同时把我在真实系统里踩过的坑、排查过的问题一并分享出来。4.1 不同方案的核心指标对照方案并发能力数据一致性实现复杂度适用场景悲观锁FOR UPDATE低强一致低后台操作、低频写、对一致性要求极高乐观锁条件更新stock 0中强一致低中小电商、常规秒杀、单库可承载乐观锁version版本号中强一致中扣减前需判断多条件的场景Redis LUA脚本扣减高最终一致需异步落库对账较高高并发秒杀、大促场景、库存独立为缓存热点消息队列串行化扣减因队列而异最终一致高极端高流量下压榨吞吐、复杂订单流程在选型时记住一个原则没有最好的方案只有当前阶段最合适的方案。初期业务量小直接用数据库乐观锁扛得住且代码量极少没必要过早引入Redis。当单库的更新成为瓶颈时再考虑Redis前置扣减与异步对账方案这个演进路径踩中的坑最少。4.2 从调研到落地的三步走实践路径第一步确认核心链路。把“库存扣减”在订单流程中涉及到的所有节点列出来查询可售、下单预占、支付确认、取消释放、超时回补。每个节点各自用什么样的数据结构、什么样的命令来承载必须先在文档里定清楚。第二步选择扣减策略。根据并发预估决定用数据库方案还是RedisLUA方案。如果预估峰值QPS超过数据库单表瓶颈具体数值因机器配置而异大致可以按单表几千级和集群的写入能力估算就直接考虑Redis。第三步补齐一致性兜底。无论采用哪种方案都要设计对账程序定期核对订单状态和库存变化记录。这是整个方案能安全上线的最底层保障。4.3 高频问题排查实录问题一库存被扣成了负数但日志里没看到超卖判断错误。这是我遇到的最典型的“低级错误”。排查后发现有人写了一个批量处理脚本用for循环遍历订单去扣库存但每次循环都新开了一个事务事务之间完全独立。更麻烦的是这个脚本的扣减逻辑是——先查库存再组装数据然后发起接口调用更新库存接口调用所在的系统又因为网络抖动出现了丢包重试结果同一个订单被重复扣了两次。这个问题暴露了两个教训第一批量扣库存必须使用单条SQL的原子扣减不能先查再改第二下游接口必须支持幂等订单扣减请求带上唯一业务号重复请求直接拒绝。问题二没到设定的库存阈值Redis却返回“库存不足”。这种现象大多数出在库存预热阶段。系统启动时从数据库加载库存但因为异步加载没有完成用户请求已经进来了此时Redis里还没有这个key返回了-1缓存未命中。我在排查时发现代码在缓存未命中时直接给用户返回“库存不足”但其实是缓存还没建好。正确的处理逻辑应该是缓存未命中时先尝试回源加载再加锁重建缓存而不是直接判定库存为零。另外多实例部署时每个应用实例可能同时触发回源如果不加互斥锁数据库会被大量穿透。问题三Redis扣减成功、数据库落库失败怎么保证不超卖。这是分布式下最典型的“岔路”问题。扣减成功但落库失败会让数据库的库存高于Redis实际结果是“少卖”。回补逻辑要处理好“事务消息”这层落库失败后发送回补请求把Redis库存再加回去。如果加回去又遇到网络抖动导致重复回补Redis的库存反而会越加越多。所以回补动作要天然幂等方案是给每次扣减生成一个全局唯一的扣减批次号Redis端通过记录批次号判断是否已执行过回补。没有幂等的回补就是在玩火。问题四排查锁竞争严重的场景。一个商品的单日销量不高但后台运营频繁手工调整库存导致用户下单时频繁锁等待超时。原因是后台调整库存的脚本用了大粒度悲观锁把整张商品表锁住了。我的解法是让后台操作改成乐观锁的版本号更新只有在版本冲突时才有极小的概率需要人工介入重试用户侧的下单锁等待问题瞬间消失。这个案例给我的启发是别把运维操作和线上交易流量混在同一个锁策略里它们对事务的要求完全不同。4.4 实测经验分享一套兼顾最终一致性的脚手架建议在真实项目里我倾向于部署一套组合方案这里分享我的具体搭配。前端流量入口比如秒杀、抢购走Redis预热LUA脚本扣减。每个商品一个key库存值在活动开始前一次性由后台运营导入。扣减成功后的订单事件写入本地消息表再由发件程序把消息投递到消息队列。消息队列消费端负责把扣减事件同步到数据库库存表同时更新订单状态。数据库库存表采用乐观锁条件更新以失败日志的形式记录扣减异常的订单配合对账任务每小时跑一次核对Redis库存变化量、数据库库存变化量、未支付订单冻结量三者是否对得上。如果某商品当天参与活动的并发量不高比如后台秒杀工具发券类活动完全不用走Redis直接数据库乐观锁就行。到了双十一这种量级再启动Redis方案并且每种商品配一个限流令牌桶防止流量洪峰把下游数据库打垮。我个人的经验是库存扣减从来不是一个“写一行SQL”的事它牵一发动全身任何方案都要花大力气梳理清楚整体链路再决定用什么技术手段解决哪一段问题。方案的好坏最终要看对账、幂等、补偿这些细节做得到不到位而不是看用了多高深的中间件。每上线一次库存相关的大促都像做了一次全链路的安全生产演练把不确定性在那里消除掉了日常运营才真正让人放心。