备案站点的高并发库存扣减与超卖防护

显示有货却下不了单，和卖多了货，是同一个问题的两面

库存并发控制的失败通常以两种相反的形式出现：要么过度保守（库存实际还有，但并发扣减互相冲突，大量正常请求被误判为失败），要么过度乐观（多个请求都读到「还有货」，一起扣减成功，实际卖出的数量超过库存）。这两种问题的根源相同——都是没有正确处理并发读改写的时序问题。

关键要点

• 库存扣减必须是原子操作：读取当前库存和扣减库存之间不能有可被其他请求插入的空隙。
• 乐观锁适合冲突不激烈的场景，悲观锁适合高频争抢的热点；选错会导致要么大量重试失败、要么吞吐骤降。
• 缓存里的库存和数据库里的库存永远存在短暂不一致的窗口，设计时要承认这一点而不是假装它不存在。
• 即使做对了并发控制，仍要有兜底对账，因为分布式系统里总有例外路径能绕过正常流程。

先分清两种失败模式

失败模式	表现	根因
超卖	卖出数量超过实际库存	读取与扣减之间存在竞态窗口
误判无货	库存明明够，大量请求却提示失败	悲观锁粒度过粗，或乐观锁重试次数不够

这两种问题经常同时出现在同一套系统的不同接口上：一个热点商品用了粗粒度的行锁，导致请求排队超时（误判无货）；另一个冷门商品完全没做并发控制，逻辑上「先查后扣」两步之间被并发请求插了队（超卖）。

乐观锁：低冲突场景的首选

乐观锁的做法是在扣减时带上一个版本号或当前库存值作为条件，只有条件匹配时更新才生效，不匹配就重试。它不预先加锁，靠数据库的条件更新语义保证原子性。

优点是无冲突时几乎没有额外开销；缺点是高并发争抢同一行库存时，重试率会急剧上升，大量请求在「读取－失败－重试」之间空转，实际有效吞吐反而下降。适合库存基数大、单个商品被同时抢购的概率不高的常规场景。

悲观锁：高频热点的选择

悲观锁在读取库存时就加锁，其他请求必须等锁释放才能继续，从根本上消除了竞态窗口。代价是并发度直接被锁住的粒度限制——如果所有请求都在等同一把锁，热点商品的吞吐上限就是「单次扣减耗时的倒数」，远低于乐观锁在低冲突下的表现。

给秒杀这类极端热点场景用悲观锁时，通常还要配合库存分片：把一个商品的总库存拆成多个子库存桶，请求先哈希到某个桶再加锁，把原本串行的锁竞争拆成多路并行，显著提升吞吐上限。分片扣减完成后仍需要一次汇总一致性校验。

扣减与下单：原子性的边界该划在哪

一个常见错误是把「扣库存」和「创建订单」放在两次独立的操作里，中间没有事务包裹——扣减成功了，订单创建失败，库存却已经少了，形成幽灵扣减。

正确做法是让扣减和下单在同一个事务边界内完成，或者用补偿机制保证最终一致：扣减库存的同时插入一条待确认的预扣记录，订单创建失败时自动释放预扣。长事务本身要克制，见 数据库连接池与连接数治理，跨服务场景下的对账补偿思路和第三方支付类似，见 第三方服务依赖治理。

预扣记录也需要超时自动释放——用户下单到支付之间有等待窗口，长期占用未支付订单的库存会造成「假性缺货」，这类定时清理任务要做到幂等，见 定时任务运维：幂等、防重与补偿。

缓存库存与数据库库存：接受不一致窗口的存在

高并发场景下直接打数据库扣库存，很容易把数据库压垮，见 数据库连接池与连接数治理。常见做法是把库存前置到缓存，扣减先在缓存里做，再异步同步到数据库。

这个方案的代价是缓存和数据库之间必然存在同步延迟，期间可能出现两边数字不一致。设计上要承认并容忍这个窗口，而不是试图追求瞬时强一致：

• 缓存扣减本身要用原子操作（条件递减），避免缓存层自己产生竞态。
• 数据库侧仍要有最终扣减校验，缓存扣减成功不代表数据库一定有货，缓存运维要点见 缓存与 Redis 运维。
• 缓存节点故障或数据丢失时，要有从数据库重建库存缓存的流程，并且重建期间的请求要能安全降级。

高并发下的限流与排队

热点商品的瞬时流量往往远超实际库存能支撑的处理能力，此时让所有请求都去抢锁是低效的——大部分请求注定失败，却仍然消耗了完整的处理链路资源。更好的做法是在入口层先做限流和排队：

• 按商品维度限速，超出承载能力的请求直接快速拒绝或进入排队队列，见 限流、熔断与服务降级。
• 用消息队列削峰，把瞬时洪峰变成后端可以匀速处理的队列，见 消息队列与异步任务运维。
• 提前评估热点场景下系统的实际承载拐点，见 全链路压测与影子环境。

分布式部署下的额外风险

多实例部署时，简单的「读取再更新」逻辑必然会遇到跨实例竞态。这不是加一把应用内的锁就能解决的——锁必须能跨实例生效，涉及的取舍和陷阱见 分布式锁与选主实践。多数场景下，数据库自身的原子更新语义（条件更新并检查受影响行数）比自己实现分布式锁更可靠、更简单，只有原子更新无法覆盖的复杂业务逻辑（如跨多个库存项的组合校验）才值得引入额外的锁机制。

兜底：对账和超卖后的补偿

无论并发控制做得多严密，都要假设极端情况下仍可能出现超卖（比如库存数据在迁移割接期间的短暂不一致，见 跨库迁移与割接实践）。因此需要：

• 定期对账：统计订单总量与库存扣减总量是否匹配，发现差异自动告警。
• 超卖补偿预案：提前想好是取消部分订单、补货、还是折价补偿，业务侧要在系统设计阶段就参与这个决策，而不是等真的超卖了才临时决定。
• 把库存相关的异常路径都纳入监控，扣减失败率、预扣超时释放量都应该是常规观察的指标，见 可观测性建设 与 备案网站监控告警体系。

常见坑

• 先查库存再扣减，两步之间没有原子保护：并发下必然超卖。
• 热点商品用无锁乐观更新且不限重试次数：大量请求空转，看起来像系统故障。
• 扣库存和建订单跨两个独立操作无补偿：出现幽灵扣减，库存越卖越少却没有对应订单。
• 预扣记录没有超时释放：未支付订单长期占着库存，造成假性缺货。
• 只做缓存扣减不做数据库校验：缓存数据丢失或不一致时直接超卖。

常见问题

乐观锁和悲观锁到底怎么选？

看冲突概率。日常商品的库存扣减冲突概率低，用乐观锁开销更小；秒杀这类瞬时高并发争抢同一件商品的场景，乐观锁会因为重试率过高导致有效吞吐下降，更适合悲观锁配合库存分片。同一个系统里，不同商品甚至可以采用不同策略。

已经用了分布式锁，为什么还会超卖？

常见原因是锁的范围没有覆盖完整的读改写周期，或者存在绕过锁的路径（比如后台管理系统直接操作库存表）。也可能是锁本身的实现存在时序漏洞，比如基于异步复制存储实现的锁在故障切换时出现短暂失效，具体机制见 分布式锁与选主实践。

缓存库存和数据库库存不一致，应该以哪个为准？

数据库通常作为最终权威数据源，缓存是加速层。设计上应该允许缓存短暂领先或落后于数据库，但下单最终确认环节要有数据库层面的校验兜底，避免缓存数据错误直接导致超卖。

已经超卖了，运维和业务应该怎么应对？

先通过对账定位超卖的具体订单和数量，再按业务预案处理（补货、部分取消、协商补偿）。事后要复盘超卖发生的具体链路——是并发控制缺失、事务边界错误，还是缓存与数据库不一致——针对性修复，而不是简单加一层重试了事。

资料来源

主流数据库关于乐观并发控制与行锁机制的官方文档，以及电商类高并发库存扣减的公开架构实践资料。本文为通用运维说明，仅供参考，具体方案请结合实际业务规则与一致性要求设计。