数据库存：产品技术团队避坑版教程：并发扣减从准备到复盘

库存只剩 1 件，两个请求却都返回了“下单成功”，这类事故并不一定是数据库性能不够，更常见的原因是团队把“查库存”和“扣库存”拆成了两个动作，却没有定义重试、超时、回补和对账规则。《数据库存：产品技术团队避坑版教程：并发扣减从准备到复盘》不只讨论一条 UPDATE 语句，而是从需求准备、方案选型、事务边界、并发压测、异常补偿到线上复盘，完整拆解一套产品和技术团队都能执行的扣减方法。

我在参与库存、优惠券、账户额度和限量商品类项目评审时，反复看到一个现象：开发能证明“这条 SQL 在单线程下是对的”，但没有人能回答“同一个请求重试三次时到底扣几次”“订单创建成功但扣减事务提交失败时怎么办”“最终库存和库存流水对不上由谁修正”。真正的并发扣减能力，不是会不会加锁，而是系统能否在竞争、失败和重复发生之后仍然保持可解释、可恢复、可对账。

一、先讲核心结论：并发扣减首先是业务协议，不是数据库技巧

1. 先把“扣减成功”定义清楚

很多团队把扣减接口返回成功，直接等同于库存扣减成功。但在真实交易链路中，至少存在四个不同状态：请求被服务接收、数据库扣减成功、订单记录创建成功、用户最终获得履约资格。它们可能在同一事务中完成，也可能分散在多个服务和多个事务中。

如果产品需求只写“用户下单后扣库存”，开发就必须自行猜测扣减时机。是提交订单时扣，还是支付成功后扣？未支付订单是否占用库存？订单关闭后多久释放？退款是否回补？这些问题没有答案，技术上再严密的锁也只能保证一个局部动作，无法保证业务结果。

我建议把“扣减成功”定义为一组可验收的业务条件，而不是一个接口布尔值。至少要明确以下内容：

• 可用库存不会被扣成负数；
• 同一个业务动作重复提交，不会重复扣减；
• 库存不足时，系统不会生成“库存已确认”的订单；
• 订单取消、支付失败或超时关闭时，回补动作可以安全重试；
• 库存表、订单表和库存流水能够按业务单号互相核对；
• 发生异常时，团队能区分真实扣减、重复请求、失败重试和人工修正。

2. 一条原子 SQL 只能解决一个局部问题

最基础、也最容易落地的防超卖方式，是将“库存大于零”的判断和扣减放进同一个数据库更新条件中：

UPDATE inventory
SET available_stock = available_stock - 1,

updated_at = CURRENT_TIMESTAMP

WHERE sku_id = ?

AND available_stock > 0;

这条语句的关键不在于写法简短，而在于它把判断和修改交给数据库作为一个原子更新处理。并发请求竞争同一条库存记录时，只有满足条件且成功获得更新机会的请求，才能让受影响行数变为 1；库存耗尽后，后续请求的受影响行数应为 0。

但这条 SQL 并没有自动解决以下问题：同一个订单重复调用两次怎么办？更新成功后订单写入失败怎么办？数据库响应超时，但实际事务已经提交怎么办？库存回补是否可能执行两次？因此，原子更新是并发扣减的底座，不是完整库存系统。

3. 产品和技术团队要共同验收五个结果

技术团队通常关注锁等待、吞吐量和错误率，产品团队更关注用户能不能下单、订单状态是否可信。两组指标需要合并，否则压测可能显示接口很快，但业务最终结果仍然错误。

二、背景和真实场景：为什么库存扣减会比想象中复杂

1. 典型交易链路中至少有三种库存状态

在商品交易中，团队常把库存字段设计成一个 stock，但产品语义通常至少包含“物理库存”“可售库存”和“已预占库存”。物理库存是仓库或供应链层面的数量，可售库存是当前允许用户购买的数量，预占库存则表示已经被订单暂时锁定但尚未完成最终履约确认。

如果业务采用下单即扣减，订单创建和库存减少可能在同一个事务里完成，用户体验简单，但支付失败或订单关闭后必须回补。如果采用下单预占、支付后实扣，系统要维护预占时长、支付确认、超时释放和重复回补，状态更多，但对库存真实性的控制可能更符合履约流程。

2. 三个最容易被忽略的并发来源

第一个来源是用户重复操作。移动网络抖动时，用户点击一次后没有立即看到结果，可能再次点击；客户端为了改善体验，也可能自动重试。服务端如果只依据请求到达次数扣减，就会把一次业务意图当成多次库存动作。

第二个来源是基础设施重试。网关、服务治理组件、消息消费者和定时任务都有可能重试。尤其是“服务端已经提交，但响应没有返回”的情况，调用方无法确定第一次是否成功，第二次请求必须依赖幂等键，而不能依赖“用户应该不会重复点”。

第三个来源是补偿任务。库存扣减失败后，团队往往增加一个定时扫描任务；订单关闭后又增加一个释放任务；支付回调失败后再增加一个补偿任务。如果这些任务没有统一状态机，就可能出现多条链路同时回补同一笔库存。

3. 热点行才是数据库扣减的真正压力点

库存表中有很多 SKU，并不代表数据库压力会平均分布。日常流量可能集中在少数热门商品上，所有请求都更新同一行。此时瓶颈不是 SQL 文本长度，也不一定是数据库总连接数，而是同一行记录的锁竞争、事务排队和后续日志写入。

这也是为什么“数据库能处理很多查询”不能直接推导出“数据库能处理很多库存扣减”。普通查询可以分散到不同数据页和不同索引范围，热点扣减却要求大量请求连续修改同一条记录，最终会受到串行化竞争的限制。

三、常见误区：看起来合理的实现为什么仍然会出事故

1. 误区一：先查库存，再在代码里判断

最典型的伪代码是先查询库存，如果结果大于零，再执行扣减。单线程测试时，这段逻辑完全正常；并发执行时，多个请求可能在同一时间读到库存为 1，然后都进入扣减分支。

stock = SELECT available_stock
FROM inventory

WHERE sku_id = ?;

if stock > 0:

UPDATE inventory

SET available_stock = available_stock - 1

WHERE sku_id = ?;

即便数据库在更新时不会允许库存变成负数，这段代码仍然可能出现“业务成功数”和“实际库存变化数”不一致。更危险的是，应用层可能在更新前就创建订单，或者无论更新受影响行数是多少都返回成功，导致用户拿到错误的下单结果。

如果业务确实需要先查询库存用于展示，查询可以保留；但展示库存和最终扣减不能共用“查询结果作为授权凭证”。真正的扣减资格，必须在最终写操作中重新判断。

2. 误区二：只看 SQL 执行成功，不看受影响行数

数据库驱动返回“语句执行成功”，往往只代表 SQL 没有语法错误或连接异常，不代表满足了库存条件。对于带有 available_stock > 0 的更新，库存不足时语句也可能正常执行，只是受影响行数为 0。

服务层必须根据受影响行数区分结果。受影响行数为 1，才表示本次扣减真正改变了库存；为 0 时，需要进一步判断是库存不足、SKU 不存在、商品已下架，还是数据库驱动对匹配行和实际变更行的统计方式存在差异。

affectedRows = executeUpdate(
"UPDATE inventory " +

"SET available_stock = available_stock - ? " +

"WHERE sku_id = ? AND available_stock >= ?",

quantity, skuId, quantity

);

if affectedRows == 1:

return StockResult.SUCCESS;

if affectedRows == 0:

return StockResult.NOT_ENOUGH_STOCK;

throw new InventorySystemException("unexpected affected rows");

生产实现中还应对 quantity 做正数校验，并限制单次最大扣减量。否则，一个异常参数就可能把库存减少过多，或者利用负数数量实现反向增加库存。

3. 误区三：加了分布式锁，就不需要幂等

锁解决的是多个执行者在某个时间窗口内的互斥问题，幂等解决的是同一个业务动作被执行多次时结果是否保持一致。一个请求拿到锁后执行成功，客户端因为超时再次发起请求，第二次仍然可能在新的锁持有周期内再次扣减。

因此，锁和幂等不是替代关系。正确顺序通常是先识别业务动作，再进行库存竞争；否则即使锁能保证“同一时刻只有一个请求执行”，也无法保证“同一笔订单一生只扣一次”。

4. 误区四：把数据库事务范围做得越大越安全

事务范围越大，表面上覆盖的操作越多，但锁持有时间也会变长。若一个事务同时调用营销、会员、支付或外部履约服务，任何下游延迟都会延长库存行的锁持有时间，最终把外部服务的不稳定传导到数据库。

我更倾向于把事务边界压缩到本地数据库能可靠完成的动作：幂等记录、库存变化、库存流水和必要的订单状态变化可以放在一个本地事务中；外部服务调用则通过状态机、可靠事件或补偿任务衔接，而不是让数据库事务一直等待网络返回。

5. 误区五：压测只发请求，不核对最终状态

接口平均响应时间很漂亮，并不能证明库存正确。压测工具可能把 HTTP 200 当成成功，但服务内部可能返回了库存不足、重复请求或待处理状态；也可能数据库最终库存正确，却缺少订单或流水，导致后续无法履约和对账。

库存压测必须在请求结束后执行状态核对。至少要把初始库存、成功扣减数、合法回补数、最终库存、成功订单数和库存流水数放到同一张对账表中。

四、专业判断逻辑：先判断一致性，再决定是否引入复杂组件

1. 用四个问题确定技术方案边界

我在方案评审时不会先问“要不要上缓存”或“要不要加分布式锁”，而是先问四个问题。第一个问题是库存是否必须强一致；第二个问题是扣减是否允许排队；第三个问题是失败后能否延迟处理；第四个问题是业务是否具备明确的补偿和对账能力。

如果库存关系到账户余额、授信额度或不可超卖的稀缺资源，强一致和可审计优先级高于极限吞吐。如果库存是可替代商品，业务允许短时间延迟确认，那么可以使用队列削峰或缓存前置，但必须接受异步状态和补偿成本。

2. 先评估流量集中度，而不是只看总 QPS

总请求量只能告诉你系统整体有多忙，无法告诉你是否存在热点。假设每秒有 2000 个库存请求，如果平均分布在 2 万个 SKU 上，单个 SKU 的竞争可能很低；如果其中 80% 集中在 3 个 SKU 上，数据库面对的是几个高频更新热点。

因此压测模型必须包含真实的 SKU 分布。至少准备均匀分布、长尾分布和极端热点三组流量。只用平均分布压测，通常会高估数据库库存表的实际承载能力。

场景 A：1000 个 SKU，随机均匀访问
场景 B：20% 热门 SKU 承担 80% 请求

场景 C：1 个 SKU 承担 70% 请求，库存仅为 100 件

3. 先做原子更新，再根据证据升级架构

对于库存规模适中、扣减逻辑简单、数据库已经具备高可用能力的系统，我通常建议先用数据库原子更新建立正确性基线。原因很现实：方案简单、状态集中、排查路径短，出现异常时更容易还原完整事实。

只有当压测或线上监控明确显示热点行锁等待、数据库日志写入、连接池排队或事务提交延迟已经成为瓶颈时，才进入缓存前置、库存分片或消息队列削峰的架构讨论。不要为了“高并发”三个字，提前引入多个一致性来源。

4. 判断一个方案，必须同时看收益和新增故障面

缓存可以减少数据库压力，但会新增缓存与数据库不同步、缓存丢失、回写失败和库存初始化错误等问题。消息队列可以削峰，但会新增消息重复、消费积压、消费顺序、死信处理和用户等待等问题。分布式锁可以减少并发冲突，但会新增续期、误释放、锁服务故障和锁粒度失控等问题。

所以方案评审不能只写“预期提升性能”，还应写出“新增哪些故障场景、谁负责监控、如何重试、如何回滚、如何人工处理”。这份故障面清单，往往比架构图更能体现方案成熟度。

五、数据库原子扣减的落地实现：从表结构到事务边界

1. 库存表不要只保存一个数字

最小可用的库存表至少应包含业务主键、可用库存、预占库存、更新时间和版本信息。字段不一定全部参与扣减，但它们有助于区分不同库存状态，并支持后续对账和故障定位。

CREATE TABLE inventory (
id BIGINT PRIMARY KEY,
sku_id BIGINT NOT NULL,
warehouse_id BIGINT NOT NULL,
available_stock INT NOT NULL,
reserved_stock 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),
CHECK (available_stock >= 0),
CHECK (reserved_stock >= 0)
);

是否使用数据库层面的 CHECK 约束，要结合数据库版本和团队实际运行环境确认。即使数据库支持约束，也不能替代更新条件，因为约束通常是在写入结果层面阻止非法值，而业务需要在库存不足时给出明确的业务响应。

如果同一 SKU 分布在多个仓库，还要先定义扣减策略。是指定仓库扣，还是按仓库优先级扣？如果允许拆单，库存扣减可能涉及多行记录，事务边界和失败回滚会比单仓库场景复杂很多。

2. 库存流水是排查事故的时间线

库存表告诉我们“现在有多少”，库存流水告诉我们“为什么变成这样”。没有流水，事故发生后只能通过订单日志、应用日志和人工猜测拼接事实；而日志可能被采样、过期或分散在不同服务中。

一条库存流水建议至少记录以下信息：

• 流水号和业务幂等号；
• SKU、仓库和库存类型；
• 操作类型，例如扣减、预占、释放、回补或人工调整；
• 变更前数量、变更数量和变更后数量；
• 关联订单号、支付单号或售后单号；
• 操作结果、失败原因和操作来源；
• 创建时间、服务实例和必要的追踪标识。

我建议把库存流水设计成追加记录，而不是反复覆盖一条“最近操作”。追加式流水更适合审计、重放和对账；人工修正也应记录原因和审批人，不能直接在库存表里执行一条看不出来源的加减 SQL。

3. 幂等记录必须和扣减动作有明确关系

一个常见设计是建立库存操作表，用业务幂等号做唯一约束。请求进入时先尝试写入操作记录；如果已经存在且状态为成功，就直接返回原结果；如果状态为处理中，则根据业务策略查询或等待；如果状态为失败，则只有明确允许重试时才重新执行。

CREATE TABLE inventory_operation (
id BIGINT PRIMARY KEY,
idempotency_key VARCHAR(128) NOT NULL,
order_id VARCHAR(64) NOT NULL,
sku_id BIGINT NOT NULL,
quantity INT NOT NULL,
operation_type VARCHAR(32) NOT NULL,
status VARCHAR(32) NOT NULL,
result_code VARCHAR(64),
created_at TIMESTAMP NOT NULL,
updated_at TIMESTAMP NOT NULL,
UNIQUE KEY uk_idempotency_key (idempotency_key)
);

幂等键必须对应“业务动作”，而不是简单使用用户编号。一个用户可能购买多个订单，同一订单也可能包含多个 SKU。较稳妥的做法是使用订单行号、扣减动作号或由业务方生成的唯一请求号，确保粒度既不会误合并，也不会被重复拆分。

4. 一个可审计的本地事务流程

在单数据库、同步扣减的场景中，可以把幂等记录、库存更新、流水写入和订单状态变更放入同一个本地事务。流程大致如下：

1. 校验请求号、SKU、扣减数量和商品状态；
2. 根据幂等键查询是否已有处理结果；
3. 没有记录时插入“处理中”操作记录；
4. 执行带库存条件的原子更新；
5. 检查受影响行数，区分成功和库存不足；
6. 写入库存流水和订单库存状态；
7. 将幂等记录更新为成功或失败；
8. 提交事务并返回可查询的业务结果。

这里有一个容易忽略的细节：如果先插入幂等记录，再执行库存更新，库存更新失败时，幂等记录不能简单永久保留为“处理中”。它需要被标记为明确失败，或者在事务回滚后由下一次请求重新建立。否则，后续重试可能误判为“已有请求正在处理”，造成订单一直无法推进。

5. 事务边界不要跨越不可控的外部调用

库存事务里不应直接等待支付、物流、营销权益或第三方接口。外部调用的响应时间和可用性不由库存服务控制，放在数据库事务中会让锁持有时间不可预测。

更合理的做法是：本地事务完成库存变化和状态记录，提交后发布业务事件；下游根据事件推进订单或履约状态；如果事件发布失败，使用可靠事件表、事务消息或定时补偿保证最终可达。这里的具体组件可以不同，但原则相同：不要把远程网络调用塞进本地行锁的保护区间。

六、四类方案怎么选：数据库、乐观锁、缓存和队列的真实取舍

1. 数据库原子更新：默认优先验证的基础方案

数据库原子更新适合库存记录相对集中、扣减规则不复杂、业务要求强一致且团队希望控制系统复杂度的场景。它的优势是库存、流水和订单状态可以在同一个数据源内核对，排查路径短，回滚和备份机制也比较成熟。

它的短板也很明确：热门 SKU 会形成热点行，所有请求必须竞争同一条记录；如果扣减成功后还要同步写很多关联表，事务时间会增加；如果库存分布在多个仓库，跨行扣减可能扩大锁范围。

选择这个方案时，不要只压测平均流量。应重点关注单个热点 SKU 的每秒请求量、P95 和 P99 延迟、锁等待时间、事务回滚率以及数据库日志写入压力。

2. 乐观锁：冲突可接受时再使用

乐观锁通常通过版本号或旧库存值判断记录是否被其他请求修改。例如读取版本为 10，更新时要求版本仍为 10，并在成功后改成 11。更新失败后，应用可以重新读取并重试。

UPDATE inventory
SET available_stock = available_stock - ?,

version = version + 1,

updated_at = CURRENT_TIMESTAMP

WHERE sku_id = ?

AND version = ?

AND available_stock >= ?;

乐观锁并不意味着没有锁，而是把冲突检测放到更新条件中。它适合冲突比例可控、失败能够快速返回或有限重试的场景。若所有请求都集中竞争一件热门商品，失败重试可能形成“重试风暴”，反而加重数据库压力。

我通常会给乐观锁设置严格的重试上限，例如最多重试一到两次，并区分“库存不足”和“版本冲突”。库存不足没有重试意义，版本冲突可以短暂重试，但连续失败应快速返回或进入排队流程。

3. 缓存前置扣减：性能提升背后的一致性账单

缓存前置的价值，是让高频库存竞争先在内存层完成，减少数据库热点行压力。但缓存扣减成功并不等于订单已经成立，也不等于数据库最终一定能完成落库。

采用缓存前置时，需要回答以下问题：

• 缓存库存如何初始化，初始化失败是否允许售卖；
• 缓存节点故障后，库存是否能够恢复；
• 缓存扣减成功、订单创建失败时，如何释放库存；
• 数据库扣减失败时，缓存数量如何回滚；
• 缓存与数据库数量不一致时，以谁为准；
• 人工修正后，如何避免旧缓存覆盖新库存。

如果团队没有库存流水、补偿任务和对账机制，直接使用缓存前置往往只是把“数据库锁竞争”换成“缓存和数据库不一致”。对于余额、授信等不可容忍差错的场景，更不能仅因为缓存吞吐量高就直接采用。

4. 消息队列削峰：用延迟换稳定性

消息队列适合流量瞬间涌入、业务允许排队确认的场景。请求先登记业务动作并进入队列，消费者按照可控速度执行扣减，能够降低数据库瞬时压力。

但队列会改变用户体验。用户提交后可能得到“排队中”，而不是立即得到“库存确认”。产品必须设计处理中、成功、库存不足、系统异常等状态，并提供查询入口。否则技术团队虽然削平了峰值，用户却会因为看不到结果而重复提交，重新制造幂等压力。

消费者必须具备幂等能力。消息至少一次投递是常见现实，不能把“消息只消费一次”作为默认前提。每条消息应携带业务幂等号，消费前后都要记录状态；如果处理成功但确认消息失败，下一次重复消费必须能够识别已完成结果。

七、一个可执行的并发扣减案例：初始库存100件，500个请求同时到达

1. 测试场景与验收假设

下面使用一个情景模拟案例说明验证方法：某限量商品初始库存为 100 件，压测工具在 5 秒内发起 500 次扣减请求，每个请求扣减 1 件，其中 50 个请求使用重复幂等号，剩余请求具有独立业务号。

这个案例不是某家企业的线上事故数据，而是根据库存扣减测试中常见的竞争关系构造的样本。它的目的不是宣称某个固定吞吐量，而是展示产品和技术团队应该如何定义输入、观察过程并核对最终结果。

• 初始可用库存：100 件；
• 请求总数：500 次；
• 独立业务动作：450 个；
• 重复幂等请求：50 次；
• 理论最大成功扣减数：100 次；
• 必须检查的结果：成功订单数、最终库存、流水数量、重复请求处理结果。

2. 错误实现可能出现什么结果

假设系统先查询库存，再在应用层判断，且没有检查更新受影响行数。多个请求可能在库存仍为 100 件时同时读取到可售状态，并在后续流程中创建订单。即使数据库最终库存被扣到 0，订单表里也可能存在超过 100 条“扣减成功”的记录。

更隐蔽的情况是，数据库库存没有负数，但业务成功订单数为 118。此时运营人员查看库存表会认为库存已经用完，开发人员也可能认为没有超卖，直到仓库发现实际可履约数量少于订单数量，事故才真正暴露。

3. 原子更新和幂等配合后的结果

如果服务先根据幂等号过滤 50 个重复请求，再使用带条件的原子更新，理论成功扣减数最多为 100。库存耗尽后，其他独立业务动作应返回库存不足或进入明确的排队状态，不应继续生成“已锁定库存”的订单。

压测结束后，团队应执行以下对账：

期初库存

成功扣减流水数量

+ 合法回补流水数量

= 期末可用库存

100

100

+ 0

= 0

如果库存表显示 0，但成功扣减流水只有 97 条，需要继续查找 3 件库存的去向；如果流水有 100 条但成功订单只有 98 条，需要检查订单写入或状态同步异常；如果成功订单有 100 条但幂等操作记录只有 98 条，则幂等记录设计或事务边界可能存在缺陷。

4. 如何把网络超时纳入测试

并发扣减测试不能只模拟“请求成功”和“请求失败”两种干净结果，还要人为制造服务端已提交、客户端未收到响应的情况。可以在数据库提交后延迟返回，或在响应返回前主动断开连接，观察客户端重试时是否产生重复扣减。

正确的验收结果应该是：第一次扣减已经成功时，第二次携带相同幂等号的请求返回第一次的处理结果；第一次事务确实失败时，第二次请求才可以继续执行；如果状态处于未知阶段，接口应返回可查询状态，而不是让客户端盲目重复创建订单。

5. 如何模拟补偿任务重复执行

可以让同一订单同时触发订单关闭事件、定时扫描任务和人工补偿接口，验证释放库存是否只执行一次。回补动作必须拥有独立的幂等号，例如“订单号加释放动作类型”，而不能只依赖订单当前状态。

如果订单已经完成释放，再次收到释放请求时，应返回“已处理”而不是再次增加可用库存。库存回补造成的超卖有时比扣减超卖更难察觉，因为库存表可能暂时看起来更充足，直到新的订单无法履约才暴露。

八、压测怎么做：从“能跑”转向“能证明没有错”

1. 压测前先准备可核对的测试数据

压测数据不能只准备一个商品和一个库存数字，还要准备订单、库存流水、幂等记录和回补任务的查询方式。每次测试最好使用独立批次号，便于在数据库中筛选本次测试产生的全部数据。

建议在测试开始前记录以下基线：

• 测试批次号；
• 每个 SKU 的期初库存；
• 每个仓库的期初可用和预占数量；
• 测试请求总数和独立业务号数量；
• 预期成功扣减上限；
• 是否包含支付失败、订单取消、重试和超时注入。

没有基线，就无法判断测试后的差异来自系统缺陷，还是测试环境原本就存在脏数据。压测前清理数据、压测后保留完整样本，比单纯提高并发线程数更重要。

2. 至少覆盖五种并发场景

第一种是库存充足场景，用于观察正常路径的吞吐量和延迟。第二种是库存刚好耗尽场景，用于验证最后一件或最后几件库存的竞争结果。第三种是请求远大于库存场景，用于验证库存不足后的错误处理和用户提示。

第四种是重复请求场景，同一个幂等号连续提交多次，观察是否只产生一次扣减。第五种是故障注入场景，在数据库提交、订单写入、消息发送和响应返回之间制造异常，验证系统能否查询状态并完成补偿。

3. 指标要分为性能指标和业务正确性指标

性能指标包括吞吐量、平均延迟、P95、P99、数据库连接池等待、锁等待和事务回滚率。业务正确性指标则包括成功扣减数、成功订单数、重复扣减数、超卖数、少卖数、回补次数和对账差异数。

两类指标不能互相替代。吞吐量高但超卖一次，可能已经无法接受；延迟稍高但所有库存变化可审计、可恢复，反而可能更适合余额和限量资源业务。

业务正确性校验：
超卖数量 = max(0, 成功扣减数量 – 可扣减库存 – 合法额外补入数量)

少卖差异 = 期初库存 – 成功扣减数量

+ 合法回补数量 – 期末库存

重复扣减数量 = 同一幂等号对应的有效扣减次数 – 1

4. 用目标流量模型替代“拍脑袋并发数”

压测并发数应该来自产品和运营提供的流量假设。例如，活动峰值每秒有多少用户进入商品页，多少人点击立即购买，多少请求集中在前 1 个 SKU，客户端和网关是否会自动重试。没有这些输入，直接设置 1 万并发只是一个看起来专业的数字。

我建议至少准备三种模型：日常峰值、活动峰值和极端热点。每种模型都要写清持续时间、请求分布、库存规模、失败注入比例和验收阈值。短时间突刺与持续高峰对数据库的影响不同，不能用一次 10 秒测试代表整个活动周期。

九、上线前准备：产品、开发、测试和运维各自要交什么

1. 产品需要交付业务规则，而不是一句“不能超卖”

产品需求中应明确库存扣减时机、库存不足提示、订单超时规则、支付失败处理、取消订单回补、是否允许人工修正以及用户看到的处理中状态。每条规则都应有一个可测试的结果，不能只停留在自然语言描述。

例如，“订单未支付自动释放库存”至少要进一步写清：订单创建后多久释放、释放是否受支付回调竞态影响、释放失败是否重试、用户重新支付时是否重新确认库存。规则越具体，技术越容易建立状态机和验收用例。

2. 开发需要提交可解释的技术方案

开发方案至少应包括数据模型、关键 SQL、事务边界、幂等键、异常分类、重试规则、回补方式、监控指标和降级策略。不能只提交一张架构图，让评审者自行猜测失败后会发生什么。

关键 SQL 应说明受影响行数的业务含义；幂等表应说明状态转换；补偿任务应说明扫描条件和最大重试次数；对于缓存和队列，还要说明数据初始化、故障切换和对账口径。

3. 测试需要验证“状态组合”，而不是只验证接口返回

测试用例应同时查询订单表、库存表、流水表和幂等表。一个接口返回成功，不代表四张表的状态都正确；一个接口返回失败，也不代表数据库没有发生变化。

测试尤其要覆盖响应超时、服务重启、数据库连接断开、消息重复投递、补偿任务重复触发和人工重试。很多库存事故并不是正常路径无法执行，而是异常路径没有明确的最终状态。

4. 运维需要让异常可见、可止损、可追踪

上线前应配置库存负数告警、库存流水与订单差异告警、补偿失败告警、幂等冲突异常告警、数据库锁等待告警和消息积压告警。告警必须绑定处理人和处置步骤，否则只是把问题从系统里“显示出来”，没有形成止损能力。

高风险活动还应准备开关：暂停某个 SKU、暂停自动扣减、切换到排队模式、限制单用户购买量、关闭自动重试或启用人工审核。止损开关不一定优雅，但比事故扩大后直接改数据库更安全。

5. 上线验收清单

• 是否对扣减数量、SKU 和幂等号做服务端校验；
• 是否使用带库存条件的原子更新；
• 是否严格判断受影响行数；
• 是否有请求级和补偿级幂等机制；
• 是否保存库存流水和业务关联号；
• 是否区分库存不足、重复请求和系统异常；
• 是否避免在行锁事务中调用外部服务；
• 是否压测热点 SKU 和库存为 1 的场景；
• 是否验证客户端超时后的重试行为；
• 是否验证补偿任务重复执行；
• 是否有库存、订单、流水三方对账脚本；
• 是否有降级、暂停售卖和人工修正入口。

十、线上事故怎么复盘：不要只写“并发量太高”

1. 先记录事实，再讨论责任

事故复盘的第一步是锁定事实时间线：第一笔异常请求何时进入，库存何时发生变化，订单何时创建，哪个事务提交，哪次响应超时，补偿任务何时启动。没有时间线，团队很容易把猜测当成根因。

建议从日志、数据库流水、订单状态、消息记录和监控曲线中交叉还原。单一日志源可能丢失上下文，例如应用日志显示“扣减失败”，但库存流水显示事务其实已经提交，这通常意味着网络响应阶段发生了异常。

2. 把“超卖”拆成不同故障类型

库存超卖并不只有一种原因。先查后扣造成的是并发竞态；重复请求造成的是幂等缺失；回补两次造成的是补偿幂等缺失；缓存数量大于数据库造成的是多数据源不一致；订单成功但库存未扣造成的是事务边界或事件可靠性问题。

3. 根因要落到可验证的控制点

“并发量太高”通常只是触发条件，不是根因。更有价值的根因描述应该是：“库存扣减采用先查询后更新，更新语句没有库存条件，且服务未检查受影响行数；在 500 个并发请求竞争库存为 1 的场景下，接口层错误返回了多个成功结果。”这样的描述才能直接对应修复方案和回归测试。

同样，“补偿任务有 bug”也过于宽泛。应该继续追问：任务是否有执行记录？同一订单是否可能被多个实例同时扫描？状态更新和库存回补是否在同一事务中？任务超时后如何判断上一轮是否已成功？只有把问题落到控制点，复盘才不会停留在口号。

4. 改进措施必须有负责人和验收条件

复盘结尾常见的表述是“加强测试”“增加监控”“优化代码”。这些话方向没有错，但无法确认是否完成。改进项应写成可验收任务，例如“在库存扣减接口增加受影响行数断言，并补充库存为1、并发500、重复幂等号50个的自动化测试；测试结果要求超卖数为0、重复扣减数为0、三方对账差异为0”。

如果事故暴露的是架构边界问题，还应补充长期措施：是否需要拆分预占和实扣状态，是否需要可靠事件，是否需要库存对账平台，是否需要在活动前进行容量评估。短期修复保证不再复现，长期改进则降低同类问题再次出现的概率。

十一、不同业务情况下的行动建议

1. 普通商品库存，流量中等且强一致

优先选择数据库原子更新加本地事务。库存表使用 SKU 和仓库的唯一键，更新语句带库存下限条件，服务检查受影响行数，库存流水和幂等记录一并落库。

此时不必急着引入缓存和消息队列。先通过真实流量模型压测热点 SKU，确认数据库连接池、锁等待和事务延迟。如果所有指标都在阈值内，简单方案往往比多组件架构更容易维护。

2. 限量商品，库存很少且竞争集中

库存为 1 或库存为几十件时，重点不是让所有请求都成功，而是确保最多只有合法数量的请求成功。应优先采用原子条件更新、严格幂等和快速失败。

产品可以考虑增加排队或抽签机制，减少数千个请求直接竞争数据库同一行。若仍采用同步接口，应对重复点击、客户端重试和网关自动重试进行限制，并在库存耗尽后尽快停止无意义请求。

3. 活动流量突刺，允许短暂延迟确认

如果业务允许用户看到“排队中”，可以评估消息队列削峰或分配令牌。此时必须设计状态查询接口，让用户通过订单号或请求号查询最终结果，而不是依靠前端不断重试。

队列方案上线前要压测消费者处理能力、消息积压、重复消费、消费失败和死信恢复。活动期间还要监控队列滞留时间，因为用户能否接受的不是单纯的消费速度，而是从提交到最终确认的整体等待时间。

4. 账户余额、授信额度等高风险扣减

余额和授信不是普通商品库存，技术选型应把可审计性、不可重复扣减和财务对账放在第一位。建议采用强一致数据库事务、唯一业务流水、严格状态机和日终对账，慎用只依赖缓存的扣减。

任何人工修正都应产生独立的调整流水，并保留审批原因。不要直接修改余额字段来“把数字改对”，因为这样虽然能暂时消除差异，却会破坏后续审计和责任追踪。

5. 多仓库、多批次或允许拆单的库存

这类业务首先要定义扣减顺序和失败策略。若一个订单需要从多个仓库扣减，单条原子 SQL 已经不能覆盖整个业务动作，必须考虑多行事务、库存锁定顺序、死锁重试和部分成功回滚。

如果允许拆单，可以把每个仓库库存动作设计为独立子操作，再由订单聚合状态判断整体结果；如果不允许部分成功，则需要在提交前完成可用性确认，或使用预占状态避免扣了一部分后无法完成剩余部分。

6. 库存只是展示数据，允许人工确认

某些预约、服务排班或非实物资源业务，系统中的数量更接近可预约名额，而不是严格的仓库实物。若业务允许人工确认，可以采用“申请成功、待确认”的状态，避免把短暂的数据库竞争直接映射成确定性的履约承诺。

但这并不意味着可以放弃幂等和流水。只要用户会收到“名额已占用”或“预约成功”的承诺，就必须能够解释这次占用何时产生、何时释放以及是否被其他请求重复使用。

十二、数据库存量系统怎么改：不推倒重来，也能逐步补齐

1. 第一步：先建立差异观测，不要立即改核心逻辑

老系统改库存时，最危险的做法是直接替换扣减代码，却没有留下改造前后的对照数据。建议先增加库存流水、请求号记录和三方对账任务，观察一段时间真实流量下的差异。

如果当前系统没有幂等号，可以先由网关或订单服务生成业务请求号，并把它透传到库存服务。即使暂时不改变扣减逻辑，也可以先统计重复请求比例、超时比例和补偿执行次数，为后续改造提供事实依据。

2. 第二步：把先查后扣替换成条件更新

这是收益较高、改动相对可控的一步。保留原有库存查询用于展示或提示，但真正扣减时改为带条件的原子更新，并检查受影响行数。

上线时可以先对部分 SKU 启用新逻辑，比较新旧路径的成功率、库存差异、延迟和锁等待。不要只根据接口错误率判断效果，因为旧逻辑可能返回成功但库存结果已经错误。

3. 第三步：补齐幂等和回补控制

在新逻辑稳定后，增加幂等操作表和唯一约束。对于已经存在的历史订单，需要先定义迁移策略：是按订单号生成幂等记录，还是只对新订单启用幂等。迁移过程中必须避免把同一历史扣减再次当成新动作。

回补也要单独治理。扣减幂等和回补幂等最好使用不同的动作类型，但共享明确的业务关联关系。这样既能防止重复释放，也能在对账时区分“原始扣减”和“后续回补”。

4. 第四步：根据热点数据决定是否拆分架构

只有当热点 SKU 的锁等待、连接池排队或数据库写入能力达到明确阈值时，才评估缓存、队列或库存分片。升级时应保留数据库作为最终可审计来源，或者明确新的权威来源及其对账机制。

架构升级不是替换组件，而是改变状态流转方式。上线前要重新定义用户状态、订单状态、库存状态、消息状态和补偿状态，并重新编写压测与故障演练用例。

5. 存量改造的灰度检查点

• 灰度前：完成历史数据对账，确认库存基线；
• 小流量阶段：观察重复请求、扣减差异和锁等待；
• 半量阶段：注入超时和服务重启，验证未知结果查询；
• 全量前：完成热点 SKU 极端压测和回滚演练；
• 全量后：保留旧逻辑只读对照或影子核对一段时间。

十三、把监控做成业务控制台，而不是只看 CPU 和内存

1. 技术指标和业务指标必须关联

数据库 CPU 上升不一定代表库存已经出错，接口延迟下降也不一定代表扣减正确。监控应将技术指标和业务指标通过 SKU、订单号和批次号关联起来。

例如，某热门 SKU 的锁等待突然升高，同时库存不足率、客户端重试率和订单处理中比例也升高，这才说明用户行为和数据库竞争正在互相放大。单独看 CPU 或 QPS，很难判断真正的业务影响。

2. 建议设置四层告警

第一层是数据安全告警，例如库存为负、成功扣减超过初始库存、流水与库存差异超过阈值。第二层是业务链路告警，例如订单成功但库存状态缺失、支付成功但库存未确认。

第三层是执行过程告警，例如幂等冲突异常增长、补偿任务失败、消息积压和处理延迟。第四层是容量告警，例如热点行锁等待、数据库连接池耗尽、事务回滚率和 P99 延迟持续升高。

3. 告警必须对应止损动作

库存负数告警出现后，如果团队只能在群里讨论，而没有暂停售卖的开关，监控就没有真正的事故价值。每个高风险告警都应绑定一个操作手册：谁确认、先查什么、是否暂停 SKU、是否停止补偿、何时恢复售卖。

恢复售卖也不能只看接口恢复。必须先完成库存、订单和流水对账，确认异常订单如何处理，并确保新的扣减不会覆盖人工修正结果。

十四、最终取舍：可靠库存不是最复杂的库存

1. 什么时候应坚持简单方案

如果业务库存量中等、峰值流量可预测、库存必须强一致、团队缺少成熟的补偿和对账能力，那么数据库原子更新加幂等、流水和本地事务通常是更稳妥的起点。

简单方案的价值不只是开发快，更是出了问题后容易回答三个问题：哪一次请求改变了库存、这次变化关联了什么订单、如果要恢复应该执行哪一个幂等补偿动作。

2. 什么时候值得承担复杂度

当热点流量已经通过监控和压测证明数据库单行竞争无法满足目标，或者业务明确允许排队和延迟确认时，缓存前置、消息队列、库存分片才有引入价值。

引入复杂组件前，应先把新增成本写出来：数据同步、状态查询、重复消费、积压治理、故障切换、补偿任务、对账系统和运维值守。如果这些成本没有负责人，架构升级只是在未来制造更难定位的故障。

3. 什么时候应该拒绝“性能至上”

余额、授信、不可替代的稀缺资源、需要财务审计的扣减业务，不应仅凭吞吐量选择方案。此类系统更看重一次动作是否可证明、是否不可重复、是否能够恢复和审计。

如果一个方案能把接口延迟从 100 毫秒降到 10 毫秒，却让库存差异只能通过人工猜测修复，它未必是性能优化，可能只是把成本从接口等待转移到了财务、客服和履约团队。

4. 最小可靠方案应包含什么

无论最终使用哪种组件，我认为并发扣减至少应具备五个基本能力：

1. 原子性：库存判断和库存变化不能在并发窗口中分离；
2. 幂等性：同一业务动作重复执行，结果不能重复改变库存；
3. 可审计：每次变化都有业务流水和关联对象；
4. 可恢复：超时、失败和重复补偿都有明确处理路径；
5. 可验证：压测和线上监控都能对账并证明结果。

十五、下一步怎么做：用一天时间建立并发扣减基线

1. 先画出业务状态图

把待扣减、扣减成功、扣减失败、待确认、已释放、已关闭和异常待处理状态画出来，标注每个状态由谁触发、允许跳转到哪里、重复触发时返回什么结果。

2. 再补一条最小可验证 SQL

确认真正的库存变化使用带条件的原子更新，并在服务层检查受影响行数。不要先做复杂架构，先用库存为 1、并发 500、重复请求和响应超时四个场景验证基础正确性。

3. 建立三方对账脚本

按测试批次或活动批次，把订单、库存和流水导出到同一份结果中，核对期初库存、成功扣减、合法回补和期末库存。任何差异都要保留样本，不要直接删除脏数据后宣布测试通过。

4. 最后再决定是否升级架构

如果锁等待和热点延迟没有达到业务阈值，就先保持简单方案；如果确实达到瓶颈，再根据是否允许延迟确认，选择队列、缓存或库存分片。升级前先写故障面和补偿方案，升级后重新做全链路压测。

并发扣减最容易被误解的地方，是大家都在讨论“怎么让更多请求成功”，而库存系统真正要保证的是“只有合法数量的业务动作成功，并且每一次成功都能解释、能追踪、能恢复”。数据库原子更新解决的是竞争窗口，幂等解决的是重复动作，库存流水解决的是事实追溯，补偿和对账解决的是异常闭环。产品和技术团队只要按照这条边界逐层验证，就能在不盲目堆叠组件的前提下，把库存事故从不可控的线上惊喜，变成可测试、可监控、可复盘的工程问题。

CREATE UNIQUE INDEX uk_inventory_order ON inventory_deduction(order_id, deduction_type);

免费注册

咨询方案

扫码咨询方案