库存扣减新思路：状态机+流水+异步对账，告别超卖与少卖

做电商系统的同学，谁没被“库存扣减”折腾过几回？尤其是618、双11大促压测时，接口抖动、超卖、少卖、对不上账，哪一个都能让你从下午排查到天亮。市面上聊库存扣减的文章，十个里有八个是同一套“八股”：数据库乐观锁、Redis预减、异步消息最终一致。这方案本身没错，但很多文章只讲了“怎么用”，没讲“什么时候会出问题”，更没讲“出了问题怎么收场”。

今天这篇，我不准备再复述一遍那套标准答案，而是基于自己做交易中台、库存中心和促销系统的实际经历，聊几个真正在线上扛过压、踩过坑之后提炼出来的新思路。核心围绕三件事：库存扣减的本质到底是什么、传统方案在真实业务里为什么会失灵、以及更抗揍的替代路径怎么设计。如果你是刚接触库存系统的开发，这篇能帮你建立正确的架构直觉；如果你已经在做库存模块，这篇里的几个实战细节和排查思路，大概率能省你几个通宵。

1. 库存扣减八股，到底在讲什么

面试和文章里最常出现的库存扣减方案，翻来覆去就是那三板斧。先把它们摆到台面上，后面才好说清楚新思路“新”在哪里。

1.1 八股库存方案的标准套路

第一板斧是数据库乐观锁扣减。典型SQL长这样：

sql复制UPDATE inventory 
SET stock = stock - #{quantity} 
WHERE sku_id = #{skuId} 
  AND stock >= #{quantity};

然后判断受影响行数，如果为0就说明库存不足或冲突，重试或直接返回失败。这个方案最大的优点是简单可靠，基于数据库的行锁和原子更新，不会出现并发超卖。缺点是性能天花板很明显，单行热点，数据库主库压力大，扛不住极高并发。

第二板斧是Redis预扣减。先读Redis库存，用Lua脚本原子扣减，扣成功了再发消息给数据库做最终扣减。这个方案的性能比直接怼数据库高一两个量级，但也带来了新的烦恼：Redis和数据库之间的数据一致性需要额外保证。Redis扣减成功了，异步任务还没落库，这时候进程挂了、MQ消费失败、消息重复投递，都可能让两边数据对不上。

第三板斧是异步最终一致。下单时不直接扣数据库，而是发一条“占用库存”的消息，由下游消费后修改库存表，用消息的重试机制保证最终一致。这种方案把同步链路变短，用户体验好，但实现复杂度高，要额外处理消息幂等、重复消费、积压和回滚。

1.2 八股方案为什么一到实战就露馅

“模版答案”本身没问题，问题在于面试里讲方案往往是理想环境，而真实业务有真实业务的脏乱差。我举几个真实场景，你看看是不是都遇到过：

• 用户下单占用了库存，但一直不支付，订单超时了，库存要不要释放？谁来释放？延迟消息丢了怎么办？
• 用户下单时有库存，支付回调时再查一次发现没了，订单要不要取消？取消后库存要不要补回去？
• 订单A占用10件，没支付；订单B想买这10件，但看到的是“无货”。等A超时释放后B可能已经流失了，这种隐性损失怎么评估？
• 大促时Redis里库存扣得飞快，数据库异步落库却跟不上，最后对账发现Redis显示有货，数据库已经扣成负数了。

这些问题，八股答案不会主动告诉你。它们横跨一致性、幂等性、超时处理、对账补偿好几个维度，不单纯是“用乐观锁还是用Redis”能解决的。

所以我在做库存系统时的第一个转变是：别再把库存扣减当成一条SQL或者一个接口，而是把它当成一条完整的业务链路来设计。 从用户点击下单到最终库存落库，中间每一步都可能失败，每一步都要想清楚“失败之后怎么办”。

2. 新思路的核心：把“扣库存”拆成“占用—确认—释放”

传统的库存扣减模型是一个“减法模型”，下单就把库存数字减掉，支付不支付都是先减了再说。这个模型最别扭的地方在于：它把“用户有购买意向”和“交易实际完成”混为一谈。

我在项目里推行的新思路，是把库存流转改成一个状态机，核心状态有三个：占用、确认、释放。

2.1 三态状态机的运作方式

• 占用：用户下单时，不是直接把库存总数减掉，而是把相应数量从“可用库存”划到“占用库存”。此时商品在用户端显示“已锁定库存”，其他用户不能再买这部分。
• 确认：用户支付成功，系统把“占用库存”正式核销为“已售库存”，这步才是真正把库存数字减掉。
• 释放：订单超时未支付、用户取消、风控拦截，系统把“占用库存”释放回“可用库存”。

这个思路在数据库层面的落地方案，我倾向于在库存表里同时维护两个字段：可用库存（available_stock）和占用库存（locked_stock）。总库存等于两者之和。

sql复制-- 下单占用库存
UPDATE inventory 
SET locked_stock = locked_stock + #{quantity},
    available_stock = available_stock - #{quantity}
WHERE sku_id = #{skuId} 
  AND available_stock >= #{quantity};

这里的关键是仍然使用条件更新来防超卖，但改的是两个字段的联动值。等支付成功确认时，再执行一次“把锁定变成已售”的更新：

sql复制-- 支付确认，正式核销
UPDATE inventory 
SET locked_stock = locked_stock - #{quantity},
    sold_stock = sold_stock + #{quantity}
WHERE sku_id = #{skuId} 
  AND locked_stock >= #{quantity};

2.2 为什么说这套思路更抗揍

用“三态状态机”替代“一杆子减到底”，最大的收益是：系统有了反悔的余地。

还是那个老场景：用户下单不支付。如果是传统减法模型，库存已经减了，订单超时后你得把库存加回来。加回来这个动作本身不可怕，可怕的是并发场景下加回来与别人下单扣减之间的顺序。比如一个SKU只剩1件，A下了单扣成0，B此时来买显示无货，A超时释放库存加回1，B刷新后又能买了。单看数据没错，但用户的体感是“时有时无”，而且如果A释放和B下单之间有一瞬间数据没对上，运营那边就会收到超卖告警。

在状态机模型里，A下单后库存是“可用0 + 锁1”，B看到的是不可购买，A超时后变成“可用1 + 锁0”，这时候B再来买就能成功。整个过程完全在掌控之中，不会出现“先减再加”的中间态。

更关键的是，状态机模型天然支持超时释放和取消释放的逻辑复用。只要是“释放”，无论是系统超时触发，还是用户点击取消，走的都是同一个接口、同一套幂等控制，完事后的对账口径也统一。

注意：这里的占用库存字段要加索引，因为大促时大量订单都会针对同一批热点SKU更新locked_stock字段，行锁竞争很激烈，索引和SQL更新条件的写法会影响锁的粒度和性能。

3. 新思路的进阶：库存流水驱动 + 异步对账闭环

三态状态机解决了库存流转的语义问题，但线上环境还有一个隐形杀手，叫“分布式系统的部分失败”。占用库存成功了，但订单服务返回超时了，用户以为没下单，又点了一次，结果占用了两次库存。要根治这个问题，单靠状态机还不够，还得引入库存流水（Inventory Ledger）。

3.1 用流水表记每一笔账

我的做法是，每次库存变动都往流水表插入一条记录，包含这些核心字段：

• 流水号：全局唯一，用雪花算法生成，作为幂等键
• 业务单号：对应的订单号、售后单号等
• SKU ID和变动数量：正数代表入库/释放，负数代表扣减/占用
• 变动类型：占用、释放、确认核销、手工调整、盘点损益
• 变动前库存、变动后库存：记录快照，用于排查和补账
• 创建时间、操作人、来源系统

数据库事务里同时做两件事：更新库存表的可用/锁定/已售字段，插入对应的流水记录。这两步放在同一个本地事务里，保证原子性。后面不管哪个环节的数据可疑，都能通过流水表还原完整链路。

这里有个很实用的技巧：订单表里的订单号和库存流水表里的业务单号建立唯一索引，这样即使MQ消息重复投递、接口被重试，插入流水时就会因为唯一键冲突而失败，从而天然实现了幂等。不用引入额外的分布式锁，也不用依赖Redis的setNx。

3.2 异步对账是最后一道保险

写完流水之后，不要以为数据就一定是对的。线上会出现各种各样你预想不到的情况，比如数据库主从延迟导致读到旧数据、消息积压导致同步延迟、人为的脏数据修改等等。所以我坚持在每个库存服务里跑一个异步对账任务。

对账脚本大致是这个思路：

• 每隔一定时间（我这边线上是5分钟跑一批）扫描一段时间内的订单表和库存流水表
• 找出“有订单但无流水记录”或“有流水记录但订单状态不匹配”的数据
• 按不同错误码归类，自动触发补偿任务或者推送到告警平台

打个比分：库存流水表就像是家里的记账本，库存表是钱包里实际的钱。你每次花销都记账，但月底还是要对一下账，看看记账本和实际现金是否一致。异步对账干的就是这个活儿。它不能阻止问题发生，但能把问题控制在“发现即修复”的范围内，而不是等到月底盘点才发现库存对不上，那就真的成了无头悬案。

提示：对账任务切忌全量扫表，一定要按时间窗口增量扫描，并给流水表按创建时间做分区。否则表一大了，对账查询本身就能把从库拖垮。

4. 新思路的实战：热点商品分桶与库存预占

状态机加流水表解决了一致性问题，但性能问题还摆在那里。一个爆款SKU的库存就一行记录，所有并发下单都怼这一行，数据库锁竞争必然严重。我在这里用过的有效方案是“分桶”，同时也想在下面聊聊它适用的边界。

4.1 分桶思路与适用边界

分桶的思路很直观：把某一个SKU的库存拆到多个桶里，每个桶有独立的库存数。下单时通过SKU ID哈希或者随机取模，路由到其中一个桶，只锁那一个桶的行记录。这就像把一扇窄门拆成十扇小门，人流被分散了，每扇门的压力都小了。

java复制// 分桶路由示例
int bucketIndex = Math.abs(skuId.hashCode() ^ orderId.hashCode()) % bucketCount;

分桶方案在秒杀、限量抢购场景下确实有效，实测能把单SKU的数据库并发扣减能力提升好几倍。但它也不是银弹。最明显的问题是单桶库存不均，哈希分配不均匀时，某个桶提前耗尽，但其他桶还有货，用户那边就会看到“明明有库存却下不了单”的虚假超卖。

所以我在生产里用分桶时一般配合几个策略：

• 桶数不要拍脑袋定，要结合SKU的预估QPS和单行更新的数据库性能压测结果来定
• 分桶只用在真正有热点风险的SKU上，普通商品全部走统一库存，避免过度设计
• 桶耗尽时提供一次fallback重试：如果命中桶没货，再查一次其他桶是否有余量，有则“借”一个桶扣减

4.2 本地预占与Redis降级

分桶解决的是单行热点，但所有流量还是打到数据库。有些场景下，我们还想进一步削峰。比如预售活动开始的第一秒，可能有几万个请求同时进来，每个都要查询库存够不够、更新库存、插入流水。即便分桶，数据库压力依然不小。

我的做法是引入一层本地预占。用Redis的Lua脚本做库存预扣减，预扣成功后才异步触发数据库的正式占用。这样用户请求只需要跟Redis打交道，扛并发能力高出几个档次。但这里要注意，Redis只是预占，不是最终结果。一旦数据库侧扣减失败，必须主动把Redis里的预占数加回来，否则会出现Redis库存被“扣穿”，而数据库还一仓库存的假象。

有人会问，这跟前面说的“八股Redis预减”有什么区别？区别在于最终一致性的落点：

• 八股方案：Redis扣减结果为准，数据库被动同步，两边容易越走越偏
• 我的方案：数据库的库存流水为准，Redis只是一个前置的快速闸门，闸门和账本之间定期校准

落地时我用了一个很轻量的校准策略：每次从Redis扣减时都带上一个自增的token，数据库扣减成功后回写这个token对应的最终状态。对账任务扫描那些“Redis扣了但数据库没有对应流水”的token，反向补偿Redis。既利用了Redis的性能，又没有牺牲数据库这个最终账本的准确性。

5. 库存扣减的工程落地细节与避坑记录

思路讲完了，最后落地的环节才是真正的修罗场。这里我按自己的实战经验，整理几个最常见的坑和对应的工程细则。

5.1 幂等与重试的正确姿势

线上接口没有“一定成功”这回事。用户点了下单，网络超时了，他再点一次，如果不做幂等，库存就被重复占用。前面我提过用“业务单号唯一索引”来保证幂等，但在代码层面也要养成一个习惯：凡是写操作接口，入口处先做幂等校验。

我的实践是在订单服务里维护一张幂等表，核心字段包括幂等键、请求参数哈希、处理状态、处理结果。第一次请求插入状态为“处理中”，第二次请求来了发现同一个幂等键已存在，直接返回第一次的处理结果。库存服务内部同样有这套机制，只是把“幂等键”换成了“业务单号+操作类型”。

重试也有讲究。下游调用库存服务失败时，不能无脑重试，要区分是网络异常、超时还是业务异常。业务异常（比如库存不足）重试一万次也是失败，还不如直接返回友好提示。网络异常和超时则要设置重试次数上限，并采用指数退避，避免瞬间重试风暴把下游打挂。

5.2 超卖、少卖与虚假超卖的甄别

这三个词听着像一回事，其实是三种完全不同的病：

• 超卖：实际卖出的数量超过了库存总数量。通常是对账时发现已售+占用+可用不等于总库存，或者库存表出现了负数。
• 少卖：库存没少，但订单状态显示已支付，用户就是收不到货。通常是确认核销环节丢了消息。
• 虚假超卖：从库存数字看没超卖，但用户无法正常购买。分桶不均衡、本地预占未释放、状态机状态卡死都会导致这种情况。

排查这些问题的第一件事，不是看代码，而是看流水。完整的库存流水能把每一次变动的时间、数量、来源系统都串起来，哪个环节断开了，一目了然。这也是我为什么在前面强调流水表字段要尽量完整，宁可多存几个冗余字段，也别在排查问题时缺胳膊少腿。

5.3 关于性能压测的两点经验

库存系统的压测不能只测“所有请求都成功”的快乐路径，更要测“部分失败”的痛苦路径。我会在压测脚本里故意注入一定比例的下游超时和随机异常，观察库存系统的自愈能力。比如扣减成功但响应超时，调用方重试后会不会造成重复扣减；预占成功后数据库扣减失败，Redis会不会自动回补。

另外，压测时一定要盯紧数据库的行锁等待和死锁率。很多库存系统的性能瓶颈不在SQL本身，而在并发更新同一行时锁等待。行锁等待一多，即使CPU和内存都很空闲，接口的RT照样飙升。

6. 几个高频问题的排查思路

这些是我在实际线上支援时经常被问到的场景，整理成一个快速参考表，希望对你有用。

6.1 问题速查表

6.2 一个实战复盘

印象最深的一次线上事故，是某个SKU在活动结束后，可用库存显示为负数。查了半天，发现是订单超时释放和用户支付确认这两个动作在并发执行时出现了竞态。理论上资源层有行锁保护，不会出现负库存，但我们的确认核销SQL里，少了locked_stock >= quantity这个判断，导致一个已经被释放的锁定库存被二次核销，账本直接被打穿。

这个事故让我定下一条铁律：所有库存表的UPDATE操作，哪怕是看起来绝对安全的内部调用，也必须带条件判断，必须返回受影响行数并校验。不要相信任何“肯定不会有问题”的代码路径。 这条经验，后来在好几次大促复盘里帮我避免了同样的坑。

写在最后

库存扣减这个话题，说起来是“扣个数字”，但真正把它做好，靠的是对业务语义的深刻理解和对分布式系统各种失败场景的敬畏。流行的八股方案是很好的敲门砖，但不能停留在“背会了就能面试”的程度，要往深处想一层：这个方案的边界在哪里，哪个节点可能出问题，出了问题之后我怎么最快恢复。

我现在的库存系统已经是“状态机 + 库存流水 + 异步对账 + 热点分桶 + Redis预占”的组合形态。它比最初的单表乐观锁方案复杂不少，但换来的是一致性可追溯、性能可扩展、问题可排查。如果你正在设计或重构库存模块，建议不要一上来就追求最复杂的方案，先把手上的核心链路（下单占用、支付确认、超时释放）用状态机模型跑通，再逐步叠加流水、对账和分桶优化。

最后分享一个自己在踩过多次坑之后养成的小习惯：每次上线库存相关需求前，我会写一个“至少三个失败场景”的清单，覆盖超时、重复、部分失败这三类最常见的问题，并且逐条确认系统在遇到这些情况时不会产生脏数据。这个习惯，帮我挡掉了好几次线上故障。希望你也能从这套思路上获得一些启发。