先讲核心结论：超卖排查不是查库存，而是重建证据链

1. 当前库存只能说明结果，不能直接证明原因

库存主表通常只保留某个 SKU 的最新数量。例如，事故发生后看到 `quantity = 0`，最多只能说明当前可扣减数量为零。它无法独立回答：库存初始是多少、有哪些请求同时读取过它、哪些扣减真正提交、哪些事务后来回滚、是否有重复消费、是否发生过取消回补。

因此，排查库存超卖时，我不会先从“要不要加分布式锁”开始，而是先把四类记录放进同一条时间轴：库存主表、库存流水、订单明细、请求与消息日志。只有当这四类记录能够互相解释，根因判断才有可信度。

判断超卖的最小证据集通常包括以下内容：

• 事故 SKU、仓库或库存分片标识；
• 事故前后至少一个完整业务窗口的库存流水；
• 每笔相关订单的创建、取消、支付和履约状态；
• 请求 ID、订单号、幂等键和服务实例；
• 库存扣减 SQL 的执行结果与事务提交结果；
• 消息投递、消费、确认和重试记录。

如果缺少其中任意一类证据，结论就可能停留在“看起来像并发问题”。“像”不能作为修复依据，尤其不能据此直接修改生产库存。

2. 先区分“超卖”与“库存口径不一致”

很多事故复盘一开始就把“库存少了”定义成超卖，实际上系统里可能同时存在物理库存、可售库存、锁定库存、已支付未出库库存和仓库可用库存。一个订单成功但仓库没有货，可能是数据库扣减错误，也可能是可售库存计算没有扣除已经锁定的数量。

我建议先写出系统中的库存公式，再开始查数据。一个常见的简化模型是：

可售库存 = 物理库存 – 已锁定库存 – 已确认销售未出库库存 + 可释放库存

这个公式不是通用事实，必须以实际业务定义为准。尤其要确认“锁定”在什么时点生效、支付超时后何时释放、取消订单是否允许重复回补，以及仓库系统是否拥有最终库存裁决权。

3. 根因要分成三层，不能把现象当结论

一份合格的复盘至少应该区分现象、直接原因和系统性根因。例如，“库存变成负数”是现象；“两个并发请求都读到库存 1”是直接原因；“更新语句没有带库存条件，且应用层没有检查受影响行数”才更接近技术根因；“库存流水缺少请求标识，监控也没有发现订单库存差异”则是系统性原因。

修复直接原因只能让本次事故不再原样发生，修复系统性原因才能让下一次异常更容易被发现和解释。

一、背景和真实场景：库存超卖通常发生在“看似正常”的交易链路里

1. 一个库存为 1 的并发下单场景

假设 SKU-A 的可售库存为 1。用户甲和用户乙几乎同时点击购买，两个请求分别到达订单服务。服务先执行查询，再在应用层判断库存是否充足，最后将计算后的结果写回数据库。

如果两个请求都在更新前读取到 1，代码可能形成这样的过程：

此时数据库库存可能仍然显示为 0，而不是 -1。也就是说，没有负库存不代表没有超卖。如果两个订单都占用了同一件库存，库存主表只是把并发冲突隐藏在最终值里。

2. 为什么订单服务、库存服务和支付服务会互相“看起来都没错”

库存超卖经常不是单个服务报错，而是多个服务各自完成了一部分正确动作。订单服务创建了订单，库存服务返回了成功，支付服务也收到了待支付订单，消息服务还完成了投递。问题在于，这些动作未必处于同一个事务里，也未必使用同一个幂等键。

例如，库存扣减已经提交，但订单服务在返回前发生超时。调用方重试后，订单服务可能重新发起一次扣减。如果库存服务只按请求次数处理，而不是按业务单号或幂等键判断，那么第一次成功和第二次重试都可能被当成独立操作。

反过来，也可能出现订单创建成功但库存扣减失败。如果业务代码没有检查更新影响行数，仍然把订单状态推进为“锁定成功”，最终表现为订单比库存多。

3. 真实排查中最有价值的不是错误日志，而是成功日志

错误日志通常只记录“库存不足”或“事务异常”，但超卖请求往往没有报错。它们恰恰是以成功状态穿过系统的。因此，我会优先检查所有成功扣减记录，包括成功响应时间、业务单号、扣减前后值、影响行数和事务提交时间。

如果系统只记录异常，不记录成功扣减的上下文，排查就会陷入猜测。一个可追溯的库存流水至少应该能回答：谁在什么时候，以什么业务动作，针对哪个 SKU，改变了多少库存，改变前后分别是多少。

二、常见误区：为什么很多“修复”只能让问题暂时消失

1. 误区一：看到负库存，就认定是并发竞争

并发是常见原因，但不是唯一原因。负库存也可能由取消回补重复、人工修数覆盖、库存初始化错误、批量导入重复执行或补偿任务反复重试造成。

判断并发需要证据。至少要确认相关扣减是否在同一个 SKU 上高度重叠、是否读取到相同旧值、是否存在锁等待、是否在同一时间窗口内发生多个独立订单。如果只有一条扣减流水，却出现库存少了一件，那么“并发扣减”就不是首选解释。

2. 误区二：使用事务就不会超卖

事务保证的是一组数据库操作的原子性和隔离性，但它不会自动修复错误的业务逻辑。如果两个事务都先读取库存 1，再按照旧值更新库存，事务本身可能正常提交，却仍然产生业务层面的重复占用。

还需要检查事务边界：库存读取和更新是否在同一事务中，订单创建是否在事务之外，消息发送发生在提交前还是提交后，异常重试是否重复执行了事务。代码中出现事务注解，只能说明开发者表达了意图，不能证明运行时边界符合预期。

3. 误区三：把加锁当成万能答案

数据库行锁、分布式锁和应用内锁解决的问题并不完全相同。数据库行锁能够约束同一数据库行上的并发写入，但如果库存扣减在缓存中完成，数据库锁可能根本没有覆盖关键路径。

分布式锁也有自己的边界：锁的租期可能短于业务处理时间，网络抖动可能造成锁状态判断不一致，锁释放失败可能引发后续请求堆积。即使锁完全有效，重复请求、消息重放和取消回补仍然需要幂等控制。

4. 误区四：只看 SQL 执行成功，不看影响行数

“SQL 没抛异常”不等于“库存扣减成功”。带条件更新在库存不足时可能正常执行，只是影响行数为 0。如果 DAO 层忽略这个返回值，上层仍然创建订单，就会产生库存和订单数量不一致。

库存扣减接口应该明确区分三种结果：成功扣减、库存条件不满足、系统执行失败。把后两者都当成“接口异常”或都当成“成功”，都会让后续处理失去依据。

5. 误区五：用缓存中的数量证明数据库有问题

缓存数量适合承担高并发场景下的快速判断，但它不一定是最终事实。缓存更新可能延迟、丢失、重复执行或在回源时读到只读副本。排查时要先确认每个库存口径的权威级别，而不是直接拿 Redis、数据库和仓库系统的数字互相比较。

6. 误区六：事故发生后直接手工改库存

直接把库存改回一个“看起来正确”的数字，会破坏最重要的历史证据。后续再查时，无法区分正常扣减、事故扣减和人工修数，也可能让对账任务把人工修数误判为新一笔库存变更。

正确做法是先导出相关表和日志，再通过有业务原因的调整单进行修复。调整单应记录操作人、审批人、原值、目标值、原因、关联事故编号和执行时间。

三、专业判断逻辑：从现象到根因要经过哪些验证

1. 第一步：先冻结事故窗口和库存口径

我通常会先划定事故窗口，例如从第一笔异常订单前 30 分钟开始，到最后一笔补偿完成后 30 分钟结束。窗口不能只覆盖用户投诉时间，因为重复请求、异步消费和补偿任务往往在更晚时间发生。

同时要冻结三个定义：SKU 的范围、库存字段的含义、订单的有效状态。比如“成功订单”到底包括待支付订单、支付成功订单，还是已经进入履约的订单。如果口径不统一，统计出的超卖数量会随着查询条件变化。

2. 第二步：建立不变量，而不是只找异常行

库存系统最适合用不变量进行验证。所谓不变量，就是无论请求如何并发、消息如何重试，都不应该被破坏的关系。

• 同一业务幂等键不能产生两次有效扣减；
• 成功占用数量不能超过可售库存；
• 每一笔库存变更都必须关联业务原因；
• 库存流水的后一条变更前值，应能与前一条变更后值衔接；
• 取消或退款产生的回补，不得超过此前真实扣减数量；
• 订单状态推进失败时，不得留下无法解释的库存变化。

相比“找一条异常记录”，不变量更适合批量发现问题，也更适合变成定时对账和线上告警。

3. 第三步：重放库存流水，检查数量是否连续

假设库存流水表包含 `before_quantity`、`change_quantity` 和 `after_quantity`，就可以检查相邻记录是否连续。以下 SQL 是通用排查模板，字段名和窗口函数语法需要根据实际数据库调整。

SELECT
sku_id,

id,

created_at,

before_quantity,

change_quantity,

after_quantity,

LAG(after_quantity) OVER (

PARTITION BY sku_id

ORDER BY created_at, id

) AS previous_after_quantity

FROM stock_change_log

WHERE sku_id = 'SKU-A'

AND created_at >= '2026-09-16 09:30:00'

AND created_at <  '2026-09-16 10:30:00'

ORDER BY created_at, id;

查询结果中，如果当前记录的 `before_quantity` 不等于上一条记录的 `after_quantity`，不要马上认定数据损坏。还要继续确认中间是否有人工调整、批量任务、分片切换或未接入流水的旧代码。

4. 第四步：检查扣减是否是原子条件更新

安全的数据库扣减通常会把“库存是否足够”和“库存减少”放在同一条更新语句中：

UPDATE stock
SET quantity = quantity - 1,

updated_at = CURRENT_TIMESTAMP

WHERE sku_id = 'SKU-A'

AND quantity >= 1;

但这条 SQL 还不够。调用方必须检查受影响行数：影响 1 行表示条件满足并完成扣减，影响 0 行表示库存不足或 SKU 不存在。两者都不应继续创建成功订单。

int affectedRows = stockDao.decrease(skuId, quantity);
if (affectedRows == 1) {

// 继续创建库存锁定记录或推进订单状态

} else if (affectedRows == 0) {

// 返回库存不足，不能继续推进成功状态

} else {

// 按系统异常处理，并记录完整请求上下文

}

如果实际系统采用“先查再改”，需要进一步查明更新语句是否带有旧版本号或旧库存条件。下面这种写法可以通过版本号检测并发修改：

UPDATE stock
SET quantity = quantity - 1,

version = version + 1

WHERE sku_id = 'SKU-A'

AND quantity >= 1

AND version = 18;

乐观锁失败时，影响行数为 0。它并不意味着应该无限重试。对于秒杀或高峰交易，盲目重试可能放大数据库压力，甚至在幂等失效时造成重复业务动作。

5. 第五步：把事务提交和业务响应放到同一条时间线上

在很多系统中，库存更新成功后，服务还要创建订单、发送消息和返回响应。必须确认每个动作的先后关系。尤其要注意：数据库事务提交成功的时间，可能晚于应用日志打印“扣减成功”的时间。

如果服务在提交前打印成功日志，随后事务回滚，日志就会制造假成功；如果数据库提交成功后服务响应超时，调用方重试又没有使用同一个幂等键，就可能产生真实的重复扣减。

我会重点对照以下时间点：

• 请求进入时间；
• 首次读取库存时间；
• 扣减 SQL 发出时间；
• 数据库返回影响行数时间；
• 事务提交完成时间；
• 订单状态变更时间；
• 消息发送和消费时间；
• 客户端或上游服务发起重试的时间。

6. 第六步：用证据排除，而不是用经验猜测

四、具体案例：如何从库存流水还原一场“库存正常但订单超卖”的事故

1. 案例背景与数据口径

下面使用一组脱敏后的模拟数据说明排查过程，不代表任何特定企业的生产事故。商品 SKU-A 初始可售库存为 5，事故窗口为 10:00:00 到 10:00:01。系统采用订单服务加库存服务的分层架构，库存扣减通过数据库完成，支付前订单处于“待支付”状态。

业务团队最初反馈的是：“库存已经显示为 0，但后台有 6 个订单成功锁定。”开发团队第一反应是缓存延迟，但查询数据库后发现没有负库存，库存流水也只有 5 条扣减记录。

这里出现了第一个关键判断：如果初始库存是 5，成功锁定订单是 6，而数据库只记录 5 次扣减，问题不一定是数据库少扣，也可能是订单状态多推进了一次。

2. 先看订单和库存的数量对比

如果只看支付成功订单，可能会认为没有超卖，因为支付成功数小于库存。但库存锁定发生在支付前，待支付订单仍然占用了可售库存。这里必须按业务定义统计“有效锁定订单”，不能用最终支付结果掩盖下单阶段的库存错误。

3. 再看六笔订单的时间线

第六笔订单是关键。库存扣减已经返回影响行数为 0，但订单仍然被推进到“锁定成功”。这说明数据库的条件更新可能是正确的，真正的错误发生在库存服务返回结果与订单服务状态推进之间。

进一步查看代码，发现库存服务把“库存不足”封装成普通业务响应，订单服务只判断接口调用没有抛异常，未检查响应中的 `success` 字段。于是，库存没有被多扣，订单却多成功了一笔。

4. 根因定性：不是单纯的数据库并发问题

这起案例中确实存在高并发，但高并发只是触发条件，不是完整根因。数据库条件更新保护了库存数量，订单服务错误处理返回值才是直接原因；库存和订单缺少统一的状态提交协议，则是系统性原因。

最终可以这样写复盘结论：

• 现象：5 件库存对应 6 笔有效锁定订单。
• 触发条件：高峰期间第 6 个请求到达，库存已经不足。
• 直接原因：库存更新影响行数为 0，但订单服务仍推进成功状态。
• 根本原因：跨服务调用只以“无异常”判断成功，没有将库存扣减结果作为强业务条件。
• 防复发措施：统一库存扣减结果枚举、增加订单状态前置校验、建立订单库存对账和告警。

5. 另一个反例：数据库库存也可能真的被重复扣减

为了避免把所有问题归为状态错误，再看另一种数据：库存初始为 2，库存流水出现两笔不同订单的扣减，每笔扣减前值都记录为 2，扣减后值都记录为 1，最终库存为 1，但两个订单都被标记为锁定成功。

这种记录说明两个请求很可能使用了同一个旧快照，后写入的数据覆盖了先写入的数据。库存主表没有减少到 0，是因为更新语句写入的是应用层计算结果，而不是数据库字段自身减 1。此时根因应指向查询后更新和缺少并发条件，而不是订单状态处理。

五、数据库历史追溯的具体实施：表、字段和 SQL 怎么设计

1. 库存主表只负责当前状态

库存主表应尽量保持职责单一，保存当前可查询状态和并发控制所需字段。常见字段包括 SKU、仓库、可售数量、锁定数量、版本号和更新时间。

CREATE TABLE stock (
id BIGINT PRIMARY KEY,
sku_id VARCHAR(64) NOT NULL,
warehouse_id VARCHAR(64) NOT NULL,
available_quantity INT NOT NULL,
locked_quantity INT NOT NULL DEFAULT 0,
version BIGINT NOT NULL DEFAULT 0,
updated_at TIMESTAMP NOT NULL,
UNIQUE KEY uk_sku_warehouse (sku_id, warehouse_id)
);

主表不应该承担全部审计职责。若每次变更只覆盖当前值，后续无法知道库存为什么变化。历史追溯必须依靠独立的库存流水表，或者依靠可靠的数据库变更日志与业务流水共同完成。

2. 库存流水必须保存“变更前”和“变更后”

只保存 `change_quantity = -1` 还不够。没有变更前值和变更后值，就无法检查流水是否连续，也无法快速识别覆盖写、重复回补和人工修数。

CREATE TABLE stock_change_log (
id BIGINT PRIMARY KEY,
sku_id VARCHAR(64) NOT NULL,
warehouse_id VARCHAR(64) NOT NULL,
before_quantity INT NOT NULL,
change_quantity INT NOT NULL,
after_quantity INT NOT NULL,
change_type VARCHAR(32) NOT NULL,
business_type VARCHAR(32) NOT NULL,
business_id VARCHAR(64) NOT NULL,
request_id VARCHAR(128),
idempotency_key VARCHAR(128),
operator VARCHAR(64),
created_at TIMESTAMP NOT NULL,
KEY idx_sku_time (sku_id, warehouse_id, created_at),
KEY idx_business (business_type, business_id),
KEY idx_idempotency (idempotency_key)
);

这里的 `business_id` 不能使用一个模糊的内部自增 ID，而应该能回到订单、取消单、退款单或库存调整单。`change_type` 也要有明确枚举，例如锁定、确认扣减、取消回补、退款回补、人工调整和初始化。

3. 幂等键必须具备数据库级约束

幂等不能只靠应用代码中的“先查后插”。两个并发请求可能同时查不到记录，然后同时插入。对关键动作，应该把幂等键设计成唯一约束，再结合插入结果判断谁获得了执行权。

CREATE UNIQUE INDEX uk_stock_idempotency
ON stock_change_log (business_type, idempotency_key);

如果同一订单可能经历扣减和回补，不能简单地只用订单号作为唯一键。应区分动作类型，例如“订单扣减”和“订单取消回补”使用不同的业务类型，否则真实的回补动作可能被错误拦截。

4. 查询流水时要注意排序稳定性

只按照 `created_at` 排序可能产生误判。高并发场景下，多条记录可能拥有相同的时间戳，必须增加自增 ID、数据库事务序列或可靠事件序号，形成稳定排序。

SELECT
sku_id,

before_quantity,

change_quantity,

after_quantity,

business_type,

business_id,

request_id,

created_at
FROM stock_change_log
WHERE sku_id = 'SKU-A'
ORDER BY created_at ASC, id ASC;

如果系统跨多个数据库分片，单库自增 ID 不能直接代表全局先后顺序。此时应结合请求时间、链路时间、事务提交时间和消息偏移量，不要把不同机器上的日志时间简单拼接成绝对时序。

5. 只读副本不适合承担事故最终判断

读写分离环境中，订单刚创建成功，随后从只读副本查询可能暂时查不到对应库存流水。若排查人员把“副本没有记录”当成“扣减没有发生”，就可能得出错误结论。

事故窗口内的最终判断应优先使用主库、可靠变更日志或已确认完成同步的审计存储。只读副本可以用来扩大检索范围，但不应单独作为生产事实的唯一来源。

六、不同根因下的行动建议：不要用同一把锤子修所有问题

1. 如果确认是查询后更新

优先将扣减改为数据库原子条件更新，避免在应用层计算新库存。更新语句应直接对字段做减法，并且在 WHERE 条件中限制可用数量。

上线前必须验证三个点：

• 库存不足时影响行数是否为 0；
• 影响行数为 0 时订单是否不会推进成功状态；
• 并发压测时是否存在重复成功订单或负库存。

如果扣减数量可能大于 1，条件也要使用 `available_quantity >= quantity`，不能固定写成大于等于 1。批量扣减还要确认同一订单包含多个 SKU 时的事务边界和失败回滚行为。

2. 如果确认是乐观锁冲突

乐观锁适合冲突概率可控、允许失败后重新读取的场景。库存不足或版本冲突时，可以返回明确业务结果，让上层决定是否重试。

但我不建议对所有乐观锁失败都自动重试。对于热点 SKU，重试会把一次失败变成多次数据库请求。应设置重试次数上限、退避时间和总耗时上限，同时保证每次重试使用同一个幂等键。

3. 如果确认是重复请求或重复消费

首先确定业务动作的唯一身份。订单号、支付流水号、请求幂等键和消息 ID 不能混为一谈。客户端重试可能复用订单号，消息重投可能复用消息 ID，取消回补则应有独立的回补动作 ID。

建议在数据库层增加唯一约束，在应用层增加状态机校验，在消息消费层保存消费结果。三层中缺少任何一层，都可能在异常重试时留下重复动作。

4. 如果确认是取消或补偿重复回补

回补库存前，先检查原始扣减是否真实成功。不能因为订单状态是“已取消”，就无条件加库存。正确逻辑应确认该订单是否存在一笔有效扣减，且此前没有执行过同类型回补。

如果补偿任务采用“扫描超时订单再执行”，必须避免多个任务实例同时处理同一订单。可以使用任务领取状态、数据库行锁、唯一补偿单号或状态条件更新，但最终仍要依靠幂等约束兜底。

5. 如果确认是缓存与数据库不一致

先明确库存权威源，再设计同步机制。若数据库是最终权威，缓存只能作为快速拦截或预扣减层；若缓存承担原子扣减，必须设计数据库落库、失败补偿和对账机制。

缓存方案的性能优势不能替代业务正确性。尤其要关注缓存扣减成功、数据库落库失败、消息重复发送和服务节点重启这几类异常路径。

七、不同方案的取舍：正确性、性能和复杂度不能同时无限拉高

1. 数据库原子更新与悲观锁怎么选

我的判断是：如果业务规模还没有明确的数据库瓶颈，优先把数据库原子更新、幂等和流水做好，再考虑引入缓存预扣减。很多团队一开始就把库存搬到缓存，却没有补上流水和对账，结果只是把“数据库超卖”换成了“缓存与数据库无法解释”。

2. 同步扣减与消息最终一致怎么选

同步扣减的优点是结果明确，订单服务可以立即知道库存是否成功；缺点是高峰期请求会直接施加压力。消息最终一致可以削峰，但会引入延迟、重复消费、消息丢失和状态回查。

如果用户必须在下单页面立即得到“是否锁定成功”的答案，库存锁定通常不能完全依赖异步消息。可以采用同步锁定、异步确认或异步补偿，但必须明确“用户看到的成功”对应哪一个状态。

3. 强一致事务与最终一致补偿怎么选

同库订单和库存可以通过本地事务获得较强一致性，但跨服务、跨库后，事务范围会明显扩大。分布式事务能够减少部分中间状态，却会带来性能、运维和故障处理复杂度。

最终一致并不等于“不需要一致性设计”。如果选择消息补偿，至少要有可靠消息记录、消费幂等、失败重试、死信处理和定期对账。缺少这些组件时，最终一致只是延迟暴露问题。

八、修复上线前：如何验证不会把问题带到下一次大促

1. 用并发压测验证“库存为 1 时只能成功一次”

最小压测场景不是把 QPS 做到很高，而是把业务不变量压到最容易失败的边界：库存为 1，连续发起 100 个并发请求，每个请求使用唯一订单号，并随机模拟数据库响应延迟。

测试结果至少要统计：

• 库存扣减成功数；
• 订单锁定成功数；
• 重复幂等键数量；
• 库存流水条数；
• 库存不足响应数；
• 事务回滚数和重试次数。

正确结果不是“所有请求都返回成功”，而是库存为 1 时最多只有一个有效锁定，其他请求得到明确的库存不足或业务失败结果。

2. 用重复请求验证幂等

针对同一个订单号和同一个幂等键，连续发送多次请求，覆盖以下情况：第一次响应正常、第一次响应超时、第一次数据库提交成功但应用进程重启、第一次消息消费成功但确认失败。

理想结果是：多次请求最终只产生一笔有效库存动作，后续请求要么返回第一次结果，要么返回已处理状态，而不是再次扣减。

3. 用故障注入验证补偿链路

必须模拟数据库提交失败、消息发送失败、消息重复投递、消费者处理成功后进程崩溃、缓存短暂不可用和订单取消与扣减并发。故障注入的重点不是制造报错，而是确认异常后库存、订单和消息能否回到可解释状态。

如果系统允许出现短暂不一致，也要明确最大容忍时间。例如，锁定成功后 30 秒内必须完成订单状态确认，超过时间自动进入补偿队列，并能够通过订单号查到整个处理过程。

4. 把对账从事故工具变成日常机制

对账不应该只在发生投诉后执行。可以按 SKU、订单和业务动作建立多层校验。例如，每 5 分钟检查有效锁定订单与库存锁定数量的差异，每小时检查库存流水连续性，每天检查订单扣减和回补是否平衡。

告警阈值不要只设置成“出现负库存”。在负库存之前，往往已经出现重复业务单号、影响行数为 0 但订单推进成功、回补延迟增加和库存流水断档等早期信号。

九、不同情况下的排查清单：工程师下一步应该怎么做

1. 用户投诉“两个订单都买到了最后一件”

1. 确认两个订单是否都处于有效锁定或支付成功状态；
2. 核对事故前可售库存和锁定库存；
3. 按 SKU 和时间窗口导出全部库存流水；
4. 检查两笔订单是否关联同一个幂等键；
5. 查看两次扣减 SQL 是否带库存条件或版本号；
6. 核对影响行数和事务提交结果；
7. 确认是否存在缓存预扣减、消息重试或取消回补。

2. 数据库出现负库存

先不要直接修正数量。导出负库存形成前后的流水，识别第一条使数量小于零的变更，再判断它是正常扣减、重复扣减还是人工调整。

如果第一条负库存来自扣减，检查 SQL 条件是否缺失；如果来自回补后的再次扣减，检查回补是否提前释放了不可售库存；如果来自批量任务，检查任务是否重复运行或没有使用幂等标识。

3. 订单数量大于库存扣减数量

优先查订单状态推进逻辑，而不是先查数据库锁。特别要检查库存服务返回“库存不足”时，订单服务是否把非异常响应误认为成功。

还要确认订单是否存在重复创建、拆单、合单或虚拟商品混入统计。很多数量差异来自统计口径不一致，只有把订单明细按 SKU 展开后，才能判断是否真的多占用库存。

4. 库存扣减数量大于订单数量

优先检查重复消费、重试和库存流水中的业务单号。若同一订单出现两次有效扣减，应查询消息 ID、消费次数和消费者实例。若业务单号不同但用户和请求时间高度相近，则继续查客户端重复提交或网关重试。

5. 只有缓存库存异常，数据库正常

先确认缓存是否只是展示层数据。如果数据库是权威源，可以通过回源、失效重建和短期限流恢复；如果缓存承担了真实扣减，则必须追查缓存扣减与数据库落库之间的每一条消息和补偿记录。

6. 事故发生在大促或秒杀高峰

不要只增加数据库连接数。高峰场景的首要目标是保护库存不变量，其次才是提升吞吐。可以采用请求排队、热点 SKU 限流、缓存预校验和分片库存，但每层都要明确失败结果和回滚路径。

十、如何把这类事故转化为可持续的工程能力

1. 把库存流水设计成可重放事件

库存流水不是普通操作日志。普通日志只服务于人阅读，可重放流水则要求每条记录拥有确定的业务语义、数量变化和前后状态。只要给定初始库存，就应该能够按稳定顺序重建最终库存。

如果流水无法重放，说明至少存在一种情况：有库存写入绕过了流水、变更原因不完整、排序不稳定，或者事务中主表和流水表没有保持一致。这个问题需要在平时治理，而不是等到事故发生后补字段。

2. 把幂等键变成跨服务的共同语言

订单服务使用订单号、库存服务使用请求 ID、消息服务使用消息 ID，三者完全不同，会导致一次业务动作在不同服务看来变成三次动作。更好的方式是定义业务动作 ID，并允许各服务保留自己的技术流水 ID，同时建立映射关系。

这样，当应用超时重试时，库存服务可以识别“这是同一个扣减动作”；当消息重复投递时，消费者也可以判断“这条消息此前是否已经完成处理”。

3. 用指标观察“解释能力”，而不仅是性能

库存系统通常监控 QPS、响应时间和错误率，但这些指标不能说明事故是否可追溯。我建议增加以下指标：

• 库存流水关联业务单号覆盖率；
• 库存扣减结果被订单正确消费的比例；
• 重复幂等键拦截次数；
• 订单库存差异率；
• 库存流水断档数量；
• 补偿任务平均延迟和最大延迟；
• 人工库存调整占全部库存变更的比例。

这些指标不一定直接提升吞吐，却能显著降低事故定位时间。对交易系统来说，能在 10 分钟内解释异常，往往比单纯把平均响应时间从 20 毫秒优化到 15 毫秒更有价值。

4. 让复盘结论可以被自动验证

每一个根因都应该对应一个自动化校验。例如，根因是“影响行数未检查”，就增加订单成功状态与库存扣减成功记录的对账；根因是“重复消费”，就增加同一消息 ID 多次成功处理告警；根因是“流水缺失”，就增加主表变化与流水数量的定时比对。

如果复盘结论只能写在文档里，而不能转化成测试、监控或约束，那么下一次事故仍然会依赖某个工程师的个人经验。

十一、结尾：不要只修正库存数字，要修正系统的解释能力

库存超卖最值得警惕的不是某一次库存变成负数，而是系统无法解释库存为什么变化。没有库存流水，数据库只能告诉你现在剩多少；没有业务幂等键，日志无法判断一次请求是否被重复处理；没有事务和状态对齐，订单成功也不代表库存真的成功。

我处理这类问题时，最终都会回到三个问题：这次库存变化由哪个业务动作触发？这个动作是否只执行了一次？订单、库存和消息是否对这次动作拥有相同结论？只要三个问题都能用数据回答，超卖通常就能被定位；如果回答不了，继续堆加锁、缓存或消息队列，往往只是把问题推迟到更复杂的地方。

下一步可以按以下顺序执行：先确认库存口径，随后补齐库存流水的变更前后值、业务单号和幂等键；再检查扣减 SQL 是否原子、影响行数是否被正确处理；最后用并发、超时、重复消费和取消回补场景做故障验证，并把对账与告警纳入日常运行。

真正成熟的库存系统，不是保证任何时候都不会出现异常，而是在异常发生后，能够快速还原现场、准确区分责任边界，并用自动化约束阻止同一类错误再次发生。

UPDATE stock SET quantity = quantity - 1, updated_at = CURRENT_TIMESTAMP WHERE sku_id = ?AND quantity >= 1;

免费注册

咨询方案

扫码咨询方案