《数据库存：架构师操作手册：订单取消中的并发扣减怎么落地》真正要解决的，不是“取消订单后把库存加一”这么简单，而是要在取消、支付、发货、重试和消息乱序同时发生时，保证库存只被正确释放一次。我的判断是：订单取消中的库存回补，必须由订单状态机、数据库条件更新、幂等流水和补偿对账共同完成，单独依赖数据库锁、Redis 或消息队列都不够。

一、先讲核心结论：取消订单不是加库存，而是执行一次受约束的状态转换

1. 先定义四条不能被破坏的规则

在设计任何 SQL、接口或消息之前，我通常会先写出系统不变量。不变量就是无论并发多高、消息重试多少次，都不能被破坏的业务规则。

• 一个订单明细只能成功释放它实际占用过的库存。
• 同一个库存释放事件最多生效一次。
• 订单只有从允许取消的状态成功转换为已取消，才有资格触发库存释放。
• 支付成功、发货、取消之间不能同时生效，必须由状态条件更新裁决。

这四条规则比“使用乐观锁还是悲观锁”更重要。因为锁只解决一部分并发访问问题，而不能回答“这次回补是否已经执行过”“这个订单是否真的占用过库存”“取消与支付谁应该成功”等业务问题。

2. 推荐的最小闭环

对于单体应用或订单服务、库存服务共用一个数据库的系统，我建议先落地一套可验证的最小闭环：

1. 订单取消接口使用条件更新，只有允许取消的订单才能变成已取消。
2. 库存操作建立独立幂等键，不使用请求流水号替代业务操作号。
3. 库存表保存当前库存，库存流水表保存每一次加减及操作结果。
4. 库存扣减与释放使用带业务条件的原子 SQL。
5. 跨服务场景通过本地事务加可靠消息实现最终一致。
6. 使用定时对账发现“订单已取消但库存未释放”等异常。

这套方案不一定是吞吐量最高的方案，但它有一个很大的优势：每一次库存变化都可以解释、重放和核对。对于订单系统来说，可解释性通常比单次压测中多出的几个百分点吞吐更重要。

3. 先确定库存模型，再写回补 SQL

订单取消时到底更新哪一个库存字段，取决于下单时扣减的是什么。常见模型至少有三种。

如果团队连“扣减库存”这一句话具体指哪个字段都没有统一，后面的事务、缓存和消息设计都会产生歧义。我的建议是，在数据库字段注释、接口文档和库存流水中明确写出库存语义，禁止只使用一个含义模糊的 stock 字段承载所有状态。

二、背景和真实场景：最危险的不是高并发，而是状态竞争

1. 一个常见的线上故障时序

假设 SKU-A 初始可售库存为 10。用户下单时占用 1 件，数据库库存变成 9。随后订单超时取消，取消接口调用库存服务时发生网络超时。订单服务无法确认库存释放是否成功，于是客户端再次提交取消，定时任务也在几分钟后扫描到这笔订单。

如果三个入口都直接执行下面这条 SQL，最终库存可能从 9 变成 12：

UPDATE sku_stock
SET available_stock = available_stock + 1

WHERE sku_id = 'SKU-A';

数据库可能完全没有报错，事务也可能全部成功。问题不在数据库没有保证原子性，而在于系统把三次不同来源的请求都误认为是三次合法库存释放。

这类问题非常隐蔽。订单看起来是“取消成功”，库存也没有变成负数，应用日志甚至都是成功日志，只有在后续销售高峰、盘点或库存对账时，才会发现可售库存多出来了。

2. 取消与支付成功同时到达

更难处理的是取消和支付之间的竞争。订单处于待支付状态时，用户点击取消；与此同时，支付渠道的成功回调也到达订单服务。两个请求都读取到“待支付”，如果使用先查后改，两个请求都可能继续执行。

结果可能出现三种错误：

• 订单最终显示已取消，但支付已经成功，库存却被释放。
• 订单最终显示已支付，取消流程已经释放库存。
• 订单状态只有一个最终值，但两个副作用都已经执行。

第三种情况最危险，因为仅检查订单最终状态已经无法发现问题。正确做法是让状态转换本身具备竞争裁决能力，只有抢到合法状态转换的一方才能继续触发后续动作。

3. 取消与发货之间的竞争

订单取消并不只发生在待支付阶段。有些业务允许支付后取消，也有些系统在配货前允许撤销。此时库存的含义已经变化：商品可能已经进入拣货、锁定仓位或生成出库单。

如果取消接口只判断订单是否“未完成”，而没有识别“配货中”“已生成出库单”等中间状态，就可能出现库存释放了，但仓库仍然按照原出库单发货的情况。库存问题最终会表现为仓储账实不符，而不是一条明显的 SQL 错误。

4. 为什么“订单取消成功”不等于“库存已经恢复

在同库事务中，可以把订单状态更新和库存回补放在一次事务中，二者提交结果一致。但在订单服务和库存服务拆分后，取消接口往往只能先完成订单状态转换，再发送库存释放事件。

因此，系统需要区分至少三个结果：

如果接口只返回一个模糊的“操作成功”，前端、客服、运维和补偿任务都会误判。异步系统尤其需要把业务状态和库存处理状态分别建模。

三、常见误区：看似加了并发控制，实际上没有解决重复副作用

1. 误区一：先查询库存，再决定是否更新

下面的逻辑在低并发测试中通常表现正常：

SELECT available_stock
FROM sku_stock

WHERE sku_id = :sku_id;

if available_stock >= quantity:

UPDATE sku_stock

SET available_stock = available_stock - quantity

WHERE sku_id = :sku_id;

问题是，查询结果只是某一个时间点的快照。多个事务可能同时读取到同一个库存值，然后相继执行无条件更新。即使数据库隔离级别较高，也不建议把正确性寄托在应用层的“查询后判断”上。

扣减应该把业务条件放进更新语句，回补也应该把释放资格和数量上限纳入事务判断。

2. 误区二：给接口加分布式锁就可以防重复

分布式锁可以让同一订单的多个请求尽量串行，但它并不自动解决以下问题：

• 锁过期后，旧请求仍然继续执行。
• 服务进程宕机后，锁释放与事务提交状态可能不一致。
• 消息消费端没有拿到同一把锁，仍然可能重复回补。
• 不同入口使用了不同的锁键，实际没有形成互斥。
• 锁成功不代表订单状态满足业务条件。

我更倾向把分布式锁视为“降低竞争噪声”的工具，而不是正确性边界。正确性仍然应该由数据库唯一约束、条件更新和业务流水保证。

3. 误区三：消息队列设置了重试，就不会丢库存释放

消息队列能解决削峰和解耦，但通常不能保证业务层面的恰好执行一次。消费者可能已经完成数据库提交，却在确认消息前宕机，于是同一消息再次投递。

如果消费端每次收到消息都直接加库存，消息可靠性越高，重复加库存的风险反而越大。正确的消费逻辑应该是：先校验幂等记录，再校验订单明细占用状态，然后执行一次库存操作并落流水。

4. 误区四：只记录当前库存，不记录库存流水

当前库存只能回答“现在是多少”，无法回答“为什么是这个数”。当发生库存漂移时，工程师需要知道某个订单是否扣过、是否释放过、释放了几次、是哪一次重试导致异常。

没有流水表时，排查只能依赖应用日志。日志可能被采样、过期、丢失或跨服务分散保存，无法作为稳定的业务账本。库存流水不一定要永久保存所有详细上下文，但至少应该保留订单明细、操作类型、数量、前后库存和幂等键。

5. 误区五：把缓存中的库存当成唯一事实来源

缓存适合承接热点访问，但订单取消后的库存释放通常需要可追溯和可校验。缓存更新成功、数据库更新失败，或者数据库成功、缓存刷新失败，都会产生短暂或长期不一致。

系统必须明确“谁是权威库存”。如果数据库是权威，就要设计缓存失效、刷新和异常重建流程；如果采用缓存预扣，则必须有数据库落账、超时回查和对账机制。不能只因为缓存里的数字变化很快，就把它当作库存账本。

四、专业判断逻辑：先决定一致性边界，再决定技术组件

1. 第一个判断：订单和库存是否在同一个数据库事务内

这是架构设计的第一道分叉。如果订单表、订单明细、库存表和库存流水在同一个数据库实例中，最简单可靠的办法通常是本地事务。不要在还没有明确性能瓶颈之前，过早引入复杂的分布式事务。

一个典型的同库事务流程是：

1. 读取并锁定订单明细或通过条件更新确认订单可取消。
2. 插入库存释放幂等记录，利用唯一键判断是否首次处理。
3. 条件更新库存表。
4. 写入库存流水。
5. 提交事务。

如果其中任意一步失败，整个事务回滚。这样订单状态和库存释放可以在同一个提交点完成。

但同库事务也不是无限扩展的方案。订单包含多个 SKU、库存行分散在多个分片、事务持锁时间过长时，锁竞争会明显增加。此时需要重新评估明细拆分、操作顺序和异步释放。

2. 第二个判断：库存释放是否必须在取消接口返回前完成

如果业务要求用户点击取消后立即可以看到库存恢复，或者下一个用户必须马上抢到释放出来的库存，就需要更强的同步确认。否则，取消请求可以先返回“订单已取消，库存释放处理中”，通过消息异步完成。

这里有一个容易被忽略的取舍：异步释放并不是免费获得高性能，而是用库存可售延迟换取服务解耦和吞吐缓冲。如果业务不能接受释放延迟，就不应该仅因为“消息队列更先进”而强行异步。

3. 第三个判断：幂等粒度是订单级还是明细级

对于单 SKU、整单取消的简单订单，order_id + operation_type 可能足够。但在多商品订单中，整单取消可能部分成功，或者其中一个 SKU 已经发货，另一个 SKU 仍可取消。这时订单级幂等键过粗，会导致一个明细失败后整单无法重试。

更稳妥的粒度通常是：

idempotency_key =
order_id + order_line_id + inventory_operation + operation_version

如果支持分批退款、部分取消或多次补发，必须增加操作版本或业务事件号。幂等键不是越简单越好，而是要准确描述“一次不可重复的业务动作”。

4. 第四个判断：是否需要冻结库存操作顺序

消息乱序并不总是需要全局排序。关键要看事件之间是否存在因果关系。例如同一订单明细的“扣减成功”必须先于“释放库存”，但不同订单之间通常不需要排序。

我的建议是：

• 以订单明细或库存操作对象作为局部顺序键。
• 不对所有 SKU 使用全局锁或全局队列。
• 在消费端通过业务版本号拒绝过期事件。
• 对无法判断先后关系的事件，进入查询订单状态和人工补偿分支。

局部有序通常比全局有序更适合库存系统。全局有序会把无关 SKU 的操作绑在一起，增加消息积压和故障影响范围。

5. 第五个判断：数据库锁的目标是什么

悲观锁适合保护短事务内的关键行，乐观锁适合冲突不是特别频繁、失败后可以快速重试的场景，条件更新适合把单行不变量直接交给数据库判断。

在库存扣减和回补中，我通常优先考虑“条件更新加影响行数判断”，而不是先读取后加锁。原因是库存充足、释放上限和状态条件本身都可以写入 SQL，减少应用层暴露的竞态窗口。

五、数据库如何落地：表结构、事务和 SQL 不能只停留在概念

1. 库存表不要只保留一个模糊字段

下面是一种适合预占库存模型的简化结构。实际项目可能还要增加仓库、渠道、批次、租户和库存版本等字段。

CREATE TABLE sku_stock (
sku_id VARCHAR(64) PRIMARY KEY,

available_stock BIGINT NOT NULL DEFAULT 0,

reserved_stock BIGINT NOT NULL DEFAULT 0,

sold_stock BIGINT NOT NULL DEFAULT 0,

version BIGINT NOT NULL DEFAULT 0,

updated_at TIMESTAMP NOT NULL

);

字段之间还应有业务不变量。例如可售库存、预占库存和已售库存不能出现负数；如果系统还维护物理库存，则需要定义它们之间的关系，而不是依靠运维人员凭经验解释。

2. 订单明细要记录实际占用量

库存释放不能根据订单商品数量临时推算，因为订单可能发生拆单、部分取消、库存不足、改价或部分发货。订单明细至少需要记录“实际占用数量”，并区分已释放数量。

CREATE TABLE order_line (
id                  BIGINT PRIMARY KEY,
order_id            VARCHAR(64) NOT NULL,
sku_id              VARCHAR(64) NOT NULL,
ordered_quantity    BIGINT NOT NULL,
reserved_quantity   BIGINT NOT NULL DEFAULT 0,
released_quantity   BIGINT NOT NULL DEFAULT 0,
fulfilled_quantity  BIGINT NOT NULL DEFAULT 0,
status              VARCHAR(32) NOT NULL,
version             BIGINT NOT NULL DEFAULT 0,
UNIQUE KEY uk_order_line (order_id, id)
);

释放数量必须受到“实际占用量减已释放量”的约束。如果只依据 ordered_quantity 回补，部分发货和部分释放场景很容易产生库存虚增。

3. 幂等流水表要使用数据库唯一约束

CREATE TABLE inventory_operation (
idempotency_key VARCHAR(160) PRIMARY KEY,

order_id VARCHAR(64) NOT NULL,

order_line_id BIGINT NOT NULL,

sku_id VARCHAR(64) NOT NULL,

operation_type VARCHAR(32) NOT NULL,

quantity BIGINT NOT NULL,

status VARCHAR(32) NOT NULL,

before_available BIGINT,

after_available BIGINT,

error_code VARCHAR(64),

created_at TIMESTAMP NOT NULL,

updated_at TIMESTAMP NOT NULL,

UNIQUE KEY uk_line_operation

(order_line_id, operation_type, idempotency_key)

);

主键或唯一键的作用不是为了“方便查询”，而是把重复执行的判断下沉到数据库。应用层先查再插仍然可能发生并发竞态，因此推荐直接插入，捕获唯一键冲突后读取历史处理结果。

4. 下单扣减应使用条件更新

UPDATE sku_stock
SET available_stock = available_stock - :quantity,

reserved_stock = reserved_stock + :quantity,

version = version + 1,

updated_at = CURRENT_TIMESTAMP

WHERE sku_id = :sku_id

AND available_stock >= :quantity;

执行后检查影响行数。影响行数为 1，表示该 SKU 的库存条件满足并完成扣减；影响行数为 0，表示库存不足、SKU 不存在或条件没有满足。不要先查库存再根据查询结果进行无条件更新。

5. 取消释放要同时修改明细和库存

在同库事务中，先用条件更新确认订单或订单明细具备释放资格，再插入幂等记录，最后更新库存。对于高并发系统，操作顺序必须固定，例如所有事务都先锁订单明细，再锁 SKU 库存，避免不同代码路径以相反顺序持锁。

BEGIN;
UPDATE order_line

SET released_quantity = released_quantity + :quantity,

status = 'RELEASED',

version = version + 1

WHERE id = :order_line_id

AND reserved_quantity – released_quantity >= :quantity

AND status IN ('RESERVED', 'CANCEL_PENDING');

— 检查影响行数必须为 1

UPDATE sku_stock
SET available_stock = available_stock + :quantity,
reserved_stock = reserved_stock - :quantity,
version = version + 1,
updated_at = CURRENT_TIMESTAMP
WHERE sku_id = :sku_id
AND reserved_stock >= :quantity;

— 检查影响行数必须为 1

— 同时写入 inventory_operation 与库存流水

COMMIT;

示例中的字段和状态是简化模型，重点在于三个条件：订单明细仍有未释放的预占量、释放数量不能超过预占量、库存中的预占量足以减少。生产系统还要结合仓库和履约状态调整。

6. 订单状态更新必须使用条件

UPDATE orders
SET status = 'CANCELLED',
cancel_reason = :reason,
cancelled_at = CURRENT_TIMESTAMP,
version = version + 1
WHERE order_id = :order_id
AND status IN ('PENDING_PAYMENT', 'RESERVED');

影响行数为 1 时，当前请求取得了取消资格。影响行数为 0 时，不能直接返回“取消成功”，而应重新查询订单状态，区分已经取消、已经支付、已经发货和订单不存在等情况。

在状态转换成功后再触发库存释放，可以避免取消请求在没有取得业务资格的情况下产生库存副作用。

六、幂等设计：一次业务动作，必须有一个唯一身份

1. 为什么请求 ID 不是可靠的幂等键

客户端重试时可能生成新的请求 ID，服务端超时重试也可能产生新的链路 ID，消息重投还会携带新的投递标识。如果系统用请求 ID 判断重复，实际上只能防止同一次网络请求重复，无法防止同一个业务动作被多个入口重复触发。

库存释放的幂等键应该表达业务事实，例如“订单明细 1001 的取消释放第 1 版”。请求 ID、链路 ID 和消息 ID可以作为审计字段，但不应取代业务幂等键。

2. 幂等键设计的三个层次

• 整单取消：适合一旦取消就整体释放、没有部分履约的订单。
• 订单明细取消：适合多 SKU、部分取消和部分发货场景。
• 库存事件版本：适合同一明细可能发生预占、释放、重新预占和补偿等多次动作。

越细的幂等粒度，处理复杂业务的能力越强，但查询、索引和对账成本也会增加。不要在业务仍然简单时设计过度复杂的事件模型，也不要在已经支持部分取消的系统中坚持使用整单唯一键。

3. 消费端的正确处理顺序

以“订单取消释放库存”消息为例，消费端不应收到消息后直接执行加库存。建议按照以下步骤处理：

1. 校验事件版本、订单明细号、SKU 和释放数量。
2. 尝试插入幂等操作记录。
3. 如果已存在成功记录，直接返回历史结果。
4. 如果记录处于处理中，查询并判断是否超过处理超时时间。
5. 重新读取订单明细和当前占用量。
6. 在事务中执行库存更新、明细更新和流水记录。
7. 更新幂等记录为成功或明确失败。

如果插入幂等记录成功，但后续数据库更新失败，不能简单删除幂等记录后无限重试。更稳妥的方式是把记录置为失败或待重试，并保存错误类型，避免临时故障和业务拒绝被混为一谈。

4. “已处理”和“处理成功”不是一回事

幂等表至少建议区分处理中、成功、失败和不可重试失败。比如数据库连接短暂中断属于可重试错误，订单已经发货属于不可重试业务错误，重复事件属于已处理结果。

七、消息队列、事务消息与补偿：跨服务一致性怎么落地

1. 本地事务加可靠消息是常见折中

订单服务完成取消状态转换时，可以在同一个本地事务中写入业务事件表。后台投递程序持续扫描未发送或发送失败的事件，将取消释放事件投递给库存服务。

CREATE TABLE outbox_event (
event_id VARCHAR(64) PRIMARY KEY,

aggregate_id VARCHAR(64) NOT NULL,

event_type VARCHAR(64) NOT NULL,

payload JSON NOT NULL,

status VARCHAR(32) NOT NULL,

retry_count INT NOT NULL DEFAULT 0,

next_retry_at TIMESTAMP,

created_at TIMESTAMP NOT NULL,

updated_at TIMESTAMP NOT NULL

);

订单状态和事件表在同一事务中提交，因此不会出现“订单已经取消，但服务进程在写消息前宕机，事件完全不存在”的情况。事件投递可能重复，但库存消费端通过幂等键处理即可。

2. 事务消息不是幂等的替代品

某些消息系统提供事务消息或半消息机制，可以降低消息丢失概率，但它仍然不能替代消费端幂等。消息可能因为网络重试再次到达，消费者也可能在业务处理后确认失败。

我在评审这类方案时，会把问题拆成两张表：

3. 重试策略要区分错误类型

数据库连接中断、锁等待超时、临时网络故障，通常可以重试；订单已经发货、订单明细不存在、释放数量超过占用量，则更可能是业务数据问题，盲目重试只会制造更多噪声。

建议采用指数退避，例如第一次 1 秒、第二次 5 秒、第三次 30 秒，之后进入延迟队列或死信队列。具体时间要结合库存释放时效和峰值流量设定，不能直接照搬。

4. 补偿任务必须以事实为依据

补偿任务不能看到“订单已取消”就直接加库存。它至少要核对订单明细、库存操作流水和当前释放数量。如果已经存在成功释放记录，只补齐缺失的事件状态，不再次修改库存。

补偿操作也要生成独立操作记录，并标注来源为自动补偿。这样后续审计可以区分用户取消、消息重试、定时补偿和人工调整。

八、具体案例与数据观察：如何从一次库存漂移定位到根因

1. 一个可复盘的订单案例

下面用一个典型电商订单做推演。订单 O20260916001 包含 SKU-A 2 件，下单时成功预占 2 件。订单服务在超时取消时先把订单改为已取消，再向库存服务发送释放事件。

由于库存服务处理成功后网络连接中断，订单服务没有收到确认。客户端再次提交取消，超时扫描任务也在稍后发现订单已取消，于是分别产生两条释放请求。

这个案例中，错误实现最终多释放了 4 件，但订单页面仍然只是“已取消”。如果系统只监控订单状态和接口成功率，很难快速发现异常。只有把库存流水和订单明细释放数量放在一起对账，才能确认重复副作用。

2. 对账公式比接口日志更可靠

对于预占库存模型，可以建立以下基础核对关系：

当前预占库存
= 成功预占总量

成功释放总量

已转实扣总量

当前可售库存

= 初始可售库存

+ 成功释放总量

成功预占总量

+ 其他合法调整量

这里的“成功”必须来自库存流水或操作表，而不是接口访问日志。接口日志只能说明“请求曾经到达”，不能说明事务是否提交，更不能说明这次业务动作是否已经被其他请求执行过。

3. 建议观察的生产指标

在实际监控中，我不会只看库存负数。库存虚增往往比库存扣成负数更难发现，因此建议同时监控释放总量、预占总量和库存变更流水。

• 订单取消成功数与库存释放成功数的差值。
• 订单明细预占量与已释放量的差值。
• 同一幂等键出现多次消费的次数。
• 库存释放事件从创建到成功的 P50、P95、P99 延迟。
• 库存释放失败中可重试与不可重试的比例。
• 实际库存与理论库存的差异数量。
• 同一 SKU 在短时间内异常增长的幅度。

4. 一组示意压测观察

下面是一组用于设计评审的情景模拟，不是某个企业的生产数据。假设 1,000 个并发请求同时取消 100 个订单，其中每个订单可能被客户端、服务重试和定时任务重复触发。

这个观察说明一个重要事实：正确性不是通过“完全不失败”实现的，而是通过“失败可识别、重复可拦截、结果可核对”实现的。

九、不同情况下的行动建议：不要用同一套方案覆盖所有业务

1. 单体系统、订单与库存同库

如果当前系统是单体应用，订单和库存表在同一个数据库中，而且取消请求量并不高，建议先使用本地事务、条件更新、明细级幂等表和库存流水。

不建议一开始就引入消息队列和分布式锁。组件越多，异常路径越长，团队需要维护的状态也越多。先把同库事务中的正确性闭环做出来，再用压测确认数据库是否真的成为瓶颈。

2. 订单服务和库存服务已经拆分

拆分后不能再假设一个本地事务可以覆盖所有动作。订单服务应在本地事务中完成订单状态转换和事件记录，库存服务消费事件并独立保证幂等。

订单取消接口可以返回“取消成功，库存释放处理中”，但必须提供查询能力，例如查询库存释放状态、事件状态和最终处理结果。否则异步化只是把用户能看到的错误变成后台不可见的错误。

3. 热点 SKU 在大促期间出现写入尖峰

热点 SKU 的竞争焦点通常集中在少数库存行上。单纯增加数据库连接数可能让锁等待更严重。此时可以考虑缓存预扣、分段库存、队列串行化或按库存分片，但每一种方案都要保留数据库落账和对账依据。

如果使用缓存预扣，取消释放还要处理缓存扣减和数据库回补之间的失败窗口。不能因为缓存中库存加回成功，就认为数据库账已经完成。

4. 支持部分取消、部分发货和多仓库存

这类系统必须以订单明细、仓库和库存批次为操作粒度。整单一个库存释放事件通常不够，因为不同明细可能处于不同履约状态。

建议把库存操作对象明确为：

order_id + order_line_id + warehouse_id + inventory_batch + operation_version

同时，取消规则必须由订单状态和履约状态共同决定。已生成出库单但尚未发货的订单，可能需要先撤销出库单，再释放仓库库存，而不是直接更新可售库存。

5. 业务允许短暂的库存释放延迟

如果用户不要求取消后立即看到库存恢复，可以选择可靠消息加补偿。这个方案更适合服务拆分和流量波动明显的系统，但要设定明确的最终一致性目标，例如正常情况下 1 秒内完成，异常情况下 5 分钟内进入补偿。

没有时效目标的“最终一致性”无法验收。研发只能说“最终会一致”，业务却无法判断什么时候应该告警。

十、缓存、分布式锁和数据库的职责边界

1. Redis 不应该成为无法核对的库存黑盒

Redis 可以承担热点库存判断、限流和快速扣减，但要明确它与数据库之间的关系。常见做法是缓存先扣、异步落库；这种设计的核心风险是缓存扣减成功而数据库落账失败。

因此至少要有：

• 缓存操作流水或事件记录。
• 数据库落账失败的重试队列。
• 缓存与数据库定期校准任务。
• 库存异常负数和异常增长告警。
• 缓存故障时的降级策略。

如果团队没有能力维护这些机制，宁可先采用数据库条件更新，也不要仅为了追求峰值吞吐使用缓存预扣。

2. 分布式锁的正确使用边界

分布式锁适合在热点操作中减少同一业务对象的同时竞争，例如短时间内同一个订单重复取消。但锁应当是优化手段，不能作为唯一正确性保障。

使用分布式锁时，需要明确：

• 锁键是订单、订单明细、SKU 还是仓库库存。
• 锁的持有时间是否覆盖数据库事务。
• 锁过期后旧请求是否可能继续提交。
• 锁续期失败时如何终止业务操作。
• 不同服务和定时任务是否使用完全一致的锁键。

如果锁的粒度是 SKU，所有订单取消都可能被同一件热点商品阻塞；如果锁的粒度是订单，则不同入口对同一订单的互斥较好，但无法解决多个订单同时扣减同一 SKU 的问题。锁粒度本身就是业务性能决策。

3. 数据库负责最终账务约束

数据库最适合保存当前库存、库存流水、幂等记录和订单明细占用量。它不一定要承受所有读流量，但应该具备拒绝非法状态的能力。

例如，库存表可以通过条件更新拒绝预占库存不足；明细表可以通过条件更新拒绝释放超过占用量；唯一索引可以拒绝同一操作重复写入。这些约束比应用日志中的“理论上不会发生”更可靠。

十一、压测与故障演练：只看 QPS，无法证明库存正确

1. 必测的七类并发场景

1. 同一个订单同时提交两次取消。
2. 客户端超时后重新提交取消。
3. 取消请求与支付回调同时到达。
4. 取消请求与发货状态更新同时到达。
5. 释放消息重复投递。
6. 库存事务提交后，服务在返回前宕机。
7. 消息消费成功后，确认消息前消费者宕机。

第六和第七类尤其重要，因为它们模拟了最常见的“业务已成功，但调用方以为失败”的情况。客户端和消息系统都会在这种情况下重试，如果没有幂等保护，就会把一次正常故障放大为库存异常。

2. 压测后的正确性断言

压测结束后，不能只报告平均响应时间、吞吐量和错误率。库存系统的核心验收条件应包括：

• 库存不能出现负数。
• 释放总量不能超过实际预占总量。
• 每一条成功库存变化都存在可追溯流水。
• 每一个订单明细的释放量不超过占用量。
• 重复消息不产生新的库存变化。
• 订单最终状态与库存操作结果可以相互解释。
• 所有临时失败最终进入成功、明确失败或人工处理状态。

3. 故障注入比普通并发更有价值

普通压测主要验证系统在理想条件下的性能，故障注入则验证设计是否真正具备恢复能力。可以在以下位置主动制造失败：

• 订单状态提交后暂停消息投递。
• 库存更新提交后模拟接口超时。
• 插入幂等记录后强制消费者进程退出。
• 数据库锁等待超过阈值。
• 消息重复投递三次或五次。
• 取消事件晚于支付事件到达。

每次演练都要在最后执行一次全量或增量对账，确认系统不是“日志看起来成功”，而是库存账务真的闭环。

十二、不同方案的取舍：架构师要接受哪些代价

1. 本地事务的优势与边界

本地事务最大的优势是结果清晰，订单状态、明细释放和库存流水可以同时提交。研发成本低，排查路径短，适合单体系统和中等规模交易系统。

它的边界也很明确：一旦订单和库存分库、分服务或跨仓库，事务范围无法自然扩展。此时继续强行把所有操作同步串起来，可能导致长事务、连接占用和级联超时。

2. 可靠消息的优势与边界

可靠消息适合服务解耦、流量削峰和异步处理。订单服务不必一直等待库存服务完成，库存服务也可以根据自身吞吐消费。

它增加的代价包括消息积压、重复消费、乱序事件、死信处理、补偿任务和最终一致性查询。团队必须具备消息治理能力，否则系统只是从“数据库事务复杂”变成“后台状态复杂”。

3. 缓存预扣的优势与边界

缓存预扣适合热点 SKU 和高峰流量，但它通常把正确性问题从数据库前移到缓存、消息和落账链路。缓存中的数字变化很快，却不一定能解释库存为什么变化。

只有在团队已经具备库存事件账本、异步落账、缓存重建和对账能力时，缓存预扣才适合作为高峰优化方案。否则，数据库条件更新往往是更稳妥的起点。

4. 分布式锁的优势与边界

分布式锁接入直观，可以降低某个订单或热点 SKU 的竞争强度。但锁会带来等待、过期、续期、故障转移和死锁规避问题。

它适合优化并发，不适合承担库存账务的最终正确性。即使使用锁，也必须保留条件更新和幂等流水。

十三、上线前操作清单：按顺序检查，而不是靠经验上线

1. 数据模型检查

• 是否区分可售、预占、已售或其他库存状态。
• 订单明细是否记录实际预占量和已释放量。
• 库存流水是否能关联订单明细和业务事件。
• 幂等键是否覆盖部分取消、重试和补偿场景。
• 唯一索引是否与实际操作粒度一致。

2. SQL 与事务检查

• 扣减是否使用带库存条件的原子更新。
• 释放是否校验实际占用量和未释放量。
• 订单状态是否使用条件更新。
• 所有代码路径是否采用一致的加锁顺序。
• 是否检查每条更新语句的影响行数。
• 事务失败后是否可以安全重试。

3. 消息与补偿检查

• 订单状态变更和事件记录是否在同一事务中提交。
• 事件投递失败是否可以扫描和重试。
• 消费端是否可以处理重复消息。
• 是否区分临时错误和永久业务错误。
• 是否设置死信队列和人工处理入口。
• 补偿任务是否具备幂等性。

4. 监控与运营检查

• 是否监控库存负数和异常增长。
• 是否监控取消成功与释放成功的差值。
• 是否监控消息积压和释放延迟。
• 是否每日或按小时执行库存对账。
• 是否能根据订单号查询完整库存变更链路。
• 是否明确异常库存由谁冻结、谁复核、谁调整。

上线前最值得做的一件事，是随机抽取一批已取消订单，逐条核对订单状态、订单明细占用量、幂等记录、库存流水和当前库存变化。抽查不需要覆盖所有订单，但必须覆盖重复取消、支付后取消、部分取消和消息失败重试等异常类型。

十四、常见问题

1. 订单取消一定要同步回补库存吗？

不一定。是否同步取决于库存释放时效和业务承诺。如果取消后释放出的库存必须立即被其他用户购买，就应该同步确认或采用极低延迟的库存服务。如果允许短时间库存不可售，可以异步回补，但必须明确延迟目标和补偿机制。

2. 使用数据库行锁后，还需要幂等表吗？

需要。行锁只能控制同一时刻的并发访问，不能记录某个业务动作是否已经完成。事务提交后锁会释放，重复请求仍然可以再次获得锁并执行加库存。幂等表和唯一约束负责识别“这次动作以前是否成功”。

3. 取消时直接把可售库存加回去有什么问题？

如果下单时扣减的是可售库存，取消时确实可能需要加回可售库存。但仍然要校验订单是否实际占用过库存、是否已经释放过、是否部分发货，以及是否存在仓库和批次限制。没有这些条件的直接加法只适用于极其简单且风险可接受的场景。

4. 为什么库存流水不能只放在应用日志里？

应用日志用于排查调用过程，库存流水用于保存业务账务。日志可能采样、过期或分散在不同服务中，库存流水则应以数据库提交结果为准。发生库存漂移时，只有流水才能支持按订单、SKU、操作类型和时间范围重算。

5. 订单取消与支付回调谁应该优先？

没有脱离业务规则的统一答案。待支付超时取消和支付成功回调之间，通常由先成功完成状态条件更新的一方取得资格；如果支付已经成功，取消可能要进入退款流程；如果取消已经成功，支付回调则应进入关单、退款或人工处理分支。关键是不能让两个副作用都执行。

6. 消息消费失败后，删除幂等记录再重试可以吗？

不建议简单删除。应该根据失败发生的位置判断：如果库存事务已经提交，只是响应丢失，删除记录可能导致重复释放；如果事务尚未执行，可以把记录标记为可重试。幂等记录应保存处理状态和错误原因，方便恢复和审计。

7. 什么时候应该引入缓存预扣？

当数据库确实因为热点 SKU 写竞争成为瓶颈，并且团队能够建设异步落账、缓存重建、库存校准和故障降级机制时，再考虑缓存预扣。没有压测数据和对账能力时，缓存预扣很可能只是把数据库问题变成更难排查的数据一致性问题。

十五、总结：真正可靠的库存回补，是一套可证明的业务账

订单取消中的并发扣减，本质上是一次“库存释放资格”的竞争，而不是一次普通的数值加法。谁能取消订单、释放多少库存、释放是否已经发生过，都必须由明确的状态和数据约束决定。

如果系统规模较小，优先使用同库本地事务、条件更新、订单明细级幂等和库存流水；如果订单与库存已经拆分，采用本地事务加可靠事件表，再由库存服务消费并幂等处理；如果存在热点 SKU，再根据压测结果引入缓存预扣、分段库存或局部串行化。

我建议下一步按以下顺序执行：

1. 画出订单状态和库存状态的完整状态机，明确取消、支付、发货的冲突规则。
2. 给订单明细补充实际预占量、已释放量和履约量。
3. 把所有库存加减改为带条件的原子更新，并检查影响行数。
4. 建立明细级库存操作幂等键和唯一约束。
5. 补齐库存流水、事件表、重试、死信和对账任务。
6. 用重复取消、接口超时、消息重复和支付竞争场景做故障演练。

架构师最终要交付的不是一条“能把库存加回去”的 SQL，而是一套能够证明库存没有多还、少还、错还，并且在失败之后可以恢复的业务账本。当每一次库存变化都能对应一个合法订单状态、一个唯一业务事件和一条可追溯流水时，订单取消中的并发问题才算真正落地。

UPDATE orders SET status = 'CANCELLED', cancelled_at = NOW() WHERE order_id = :order_id AND status IN ('PENDING_PAYMENT', 'RESERVED');

UPDATE sku_stock SET available_stock = available_stock - :quantity, version = version + 1 WHERE sku_id = :sku_id AND available_stock >= :quantity;

UPDATE orders SET status = 'PAID', paid_at = NOW() WHERE order_id = :order_id AND status = 'PENDING_PAYMENT';

免费注册

咨询方案

扫码咨询方案