数据库存：数据库管理员数据视角：用并发扣减验证降低超卖风险

库存只剩 1 件时，两个请求几乎同时到达，应用日志却可能显示“两个请求都成功”。这类事故最容易被误判为“数据库更新太慢”或“锁没有加好”，但我在排查库存异常时更常见的根因是：库存判断、扣减结果、订单状态和重试行为没有被放进同一套可验证的数据链路里。防止超卖的关键不是找到一条看起来正确的 SQL，而是让每一次扣减都具备条件、结果、流水和补偿依据。

本文从数据库管理员和数据可靠性的角度，拆解并发扣减为什么会失效，说明条件更新、受影响行数、事务、幂等、库存流水和对账之间如何协作，并给出一套可以在 MySQL 等关系型数据库中复现和验证的方案。文中的压测数字会明确标注为情景模拟或建议基准，不把未经环境验证的数据包装成真实线上结论。

一、先讲核心结论：扣库存成功，不等于业务交易成功

1. 真正要保证的是三个数据关系

库存超卖表面上表现为库存变成负数，或者订单数量超过可售库存。但从数据库角度看，至少有三个关系需要同时成立。

• 数量关系：有效扣减总量不能超过可售库存加上有效回补量。
• 状态关系：订单状态必须能够解释库存扣减是否仍然有效。
• 追溯关系：每一次库存变化都应该能够关联到请求号、订单号或补偿任务。

如果系统只保证第一条，仍然可能出现“库存没有负数，但同一个用户被扣了两次”的问题。如果只保证订单状态，又没有库存流水，就很难判断是重复请求、支付重试还是人工回补导致了库存偏差。

2. 一条条件更新可以解决什么

最基础的并发扣减可以写成下面这样：

UPDATE product_stock
SET stock = stock - 1,

updated_at = CURRENT_TIMESTAMP

WHERE product_id = ?

AND stock > 0;

这条语句把“库存是否大于 0”和“库存减 1”放到了同一次数据库更新中。对于同一个商品库存行，数据库会按照并发控制规则处理竞争，后到的事务不会基于已经失效的库存条件继续扣减。

但是，这条 SQL 只解决了一个问题：在条件成立时进行一次原子扣减。它没有自动解决订单重复、支付失败、库存回补、跨服务事务、消息重复和实物库存不一致。

3. 受影响行数是比接口返回值更可靠的第一道信号

执行条件更新后，应用必须读取数据库驱动返回的受影响行数，而不是只判断 SQL 是否执行成功。

• 受影响行数为 1：商品记录存在，且本次满足库存条件并完成扣减。
• 受影响行数为 0：可能是库存不足，也可能是商品不存在，或者条件未满足。
• 执行抛出异常：本次操作没有得到可确认的业务结果，需要根据事务状态和请求号决定是否查询、重试或补偿。

这里有一个经常被忽略的边界：不同数据库驱动和客户端配置对“受影响行数”的定义可能存在差异，特别是更新前后值相同、客户端启用特定兼容模式时，返回值解释可能不同。因此，正式上线前必须使用目标数据库版本、目标驱动和真实 SQL 做一次验证。

二、背景和真实场景：为什么“先查再扣”在并发下会失去控制

1. 库存为 1 时最容易看清竞态

假设商品 A 的库存初始值为 1，应用采用以下逻辑：

1. 查询商品 A 的库存。
2. 如果库存大于 0，则在应用层判断可以购买。
3. 执行库存减 1。
4. 创建订单并返回成功。

现在请求 A 和请求 B 同时到达。在没有锁定读取或其他并发控制的情况下，两次查询都可能读到库存 1。两个请求都会通过应用层判断，然后分别执行扣减。即使数据库最终把库存更新成了 -1，系统也已经产生了两个“可以购买”的业务决策。

问题不在于数据库不会串行执行单行写入，而在于“读取库存”和“执行扣减”之间存在一个时间窗口。数据库可以保证每条 UPDATE 的执行秩序，却无法替应用层撤销已经基于旧读数做出的订单决策。

2. 普通写法的风险不只是一种

我通常会把库存异常分成四类，而不是统称为“超卖”。不同类型的异常，修复方式完全不同。

3. 线上“库存超卖”有时并不是数据库库存超卖

有一次排查类似问题时，最初看到的是商品页面仍显示“有货”，但下单失败率突然升高。进一步对账后发现，数据库库存没有负数，扣减流水也没有超过可售量，真正的问题是缓存中的库存没有及时失效，页面读到了旧值。

这说明“用户看到可以买”和“数据库允许扣减”是两个不同的环节。缓存展示旧库存会造成用户体验问题，但只要最终扣减使用了带条件的数据库更新，通常不会直接造成库存数量超卖。反过来，如果应用相信缓存判断并直接写数据库，就可能把展示层的不一致扩大成交易层的不一致。

因此，我在事故判断时会先问一句：所谓超卖，是库存字段真的被扣过量，还是前端展示、订单状态、仓储实物和数据库中的某一层没有对齐？

三、常见误区：不是加锁越多越安全，也不是用了事务就万事大吉

1. 误区一：把“先查询再更新”误认为原子操作

下面的写法非常常见：

SELECT stock
FROM product_stock

WHERE product_id = ?;

-- 应用层判断 stock > 0 后执行

UPDATE product_stock

SET stock = stock - 1

WHERE product_id = ?;

即使两条语句都在一个事务中，也不能仅凭“放进事务”就断定它安全。普通 SELECT 通常是快照读取，读取到的值和后续 UPDATE 之间可能存在并发变化。只有当读取采用明确的锁定方式，并且事务范围、隔离级别和异常回滚都符合预期时，才有可能建立更强的控制。

更简单、更容易审计的做法，通常是直接使用条件更新，把业务约束放进 WHERE 条件，而不是让应用先读一个数字再自行判断。

2. 误区二：加了悲观锁，订单就不会重复

悲观锁可以让多个事务在同一库存行上排队，但它只控制同一时刻的并发访问，不会自动识别“这已经是同一个业务请求”。如果客户端因为网络超时重试，第二次请求仍然可能在锁释放后再次扣减。

因此，锁解决的是并发访问顺序，幂等解决的是同一业务意图是否只能生效一次。把两者混为一谈，是库存系统中很典型的设计错误。

3. 误区三：更新成功就代表下单成功

库存 UPDATE 返回 1，只能说明库存扣减动作已经被数据库接受。之后可能发生订单插入失败、支付服务超时、消息投递失败或事务回滚。如果系统已经把“扣减成功”直接当作“交易成功”，就会留下库存被占用却没有有效订单的孤儿扣减。

更严谨的状态应该至少区分：

• 扣减已申请，但事务尚未提交。
• 扣减已提交，订单待支付。
• 订单支付成功，库存保持占用。
• 订单取消或支付失败，库存待释放。
• 补偿已完成，库存流水和订单状态重新对齐。

4. 误区四：库存字段不为负，就说明没有超卖

如果库存初始为 100，系统错误地为 101 个订单分配了购买资格，但库存字段通过其他逻辑被截断为 0，那么数据库里可能没有出现负数，业务上却已经超卖。库存下限约束只能阻止某一类非法状态，不能证明有效订单数量没有超过可售量。

判断超卖应该同时计算库存余额、扣减流水、回补流水和有效订单数量，至少形成下面的核对关系：

理论库存余额
= 初始库存

有效扣减总量

+ 有效回补总量

其他明确的库存变更

有效订单占用量

<= 可售库存 + 已确认的补货或调拨量

5. 误区五：直接上缓存或消息队列就能解决数据库问题

缓存和消息队列可以削峰、降低数据库热点压力，但会引入新的状态边界。缓存预扣成功后，数据库写入可能失败；消息可能重复投递；消费者可能在处理订单后宕机；补偿消息也可能延迟。

我更倾向于把缓存和队列视为吞吐量优化组件，而不是最终正确性组件。最终库存、订单状态和库存流水仍然需要有一个可查询、可重放、可对账的权威数据来源。

四、专业判断逻辑：先确定一致性边界，再决定用哪种扣减方式

1. 第一步：定义库存数字到底代表什么

很多库存争议，根本原因不是 SQL，而是字段语义不清。同一张表里的 stock 可能被不同团队理解为采购库存、仓库实物库存、可销售库存、已锁定库存或可用余额。

我建议至少区分以下概念：

如果支付未完成的订单会占用库存，那么“扣减成功”未必表示库存已经永久消耗，而是从可售库存转移到了锁定库存。此时回补不是简单执行 stock = stock + 1，而是将订单占用状态和库存状态一起改变。

2. 第二步：判断扣减是否需要强一致

不是所有库存都需要同样严格的并发控制。商品限量销售、票务座位、药品现货和活动名额通常需要强约束，因为多分配一件就无法履约。普通促销赠品或可替代商品，可能允许短暂的最终一致。

判断时可以问四个问题：

1. 库存被多分配后，是否一定无法履约？
2. 是否允许人工改配、延期发货或替代品履约？
3. 用户能否接受下单后被取消或退款？
4. 库存数据是否由一个数据库统一维护，还是跨多个仓库和服务？

如果答案指向“不能多分配、不能事后取消”，就应优先采用数据库条件更新或强事务控制，再考虑缓存和队列优化性能。不要先追求吞吐量，再补做正确性。

3. 第三步：划清事务边界

在同一个数据库中，如果库存表和订单表属于同一业务事务，可以考虑在一个事务里完成幂等记录、库存扣减和订单创建。关键不是事务越大越好，而是要让事务只包含必须原子完成的步骤。

一个较清晰的事务顺序可以是：

1. 根据业务请求号检查是否已经处理。
2. 插入或占用幂等记录。
3. 执行带库存条件的扣减。
4. 检查受影响行数。
5. 创建订单和库存流水。
6. 提交事务。

如果库存、订单和支付分布在不同服务，就不应假设一个本地事务能够覆盖全部操作。这时需要使用事务消息、可靠事件表、状态机或补偿任务，把“最终一定能对账”作为设计目标。

4. 第四步：确认数据库真的走了正确的访问路径

条件更新的正确性和性能都依赖商品定位条件。如果 product_id 没有唯一索引，数据库可能扫描大量记录，锁竞争范围和响应时间都会扩大。

EXPLAIN UPDATE product_stock
SET stock = stock - 1

WHERE product_id = 10001

AND stock > 0;

检查执行计划时，我不会只看“有没有索引”，还会看预估扫描行数、实际执行时间、是否发生隐式类型转换，以及库存表是否存在重复商品记录。商品 ID 应该具备明确的唯一性，否则“更新了 1 行”也可能无法代表唯一商品被安全扣减。

5. 第五步：把数据库结果转换为明确的业务状态

应用层不能只返回一个布尔值。至少需要区分库存不足、商品不存在、重复请求、数据库异常和结果未知。

五、具体实现案例：从条件扣减到库存流水验证

1. 先建立能解释数据的表结构

下面是一套简化的 MySQL 表结构。它不是完整电商模型，但足以用于验证库存扣减、幂等和审计。

CREATE TABLE product_stock (
product_id BIGINT NOT NULL,
stock INT NOT NULL,
locked_stock INT NOT NULL DEFAULT 0,
version BIGINT NOT NULL DEFAULT 0,
updated_at DATETIME NOT NULL,
PRIMARY KEY (product_id),
CONSTRAINT chk_stock_nonnegative CHECK (stock >= 0),
CONSTRAINT chk_locked_stock_nonnegative CHECK (locked_stock >= 0)
) ENGINE=InnoDB;
CREATE TABLE inventory_transaction (
id BIGINT NOT NULL AUTO_INCREMENT,
request_id VARCHAR(64) NOT NULL,
order_id VARCHAR(64) NOT NULL,
product_id BIGINT NOT NULL,
transaction_type VARCHAR(32) NOT NULL,
quantity INT NOT NULL,
before_stock INT NOT NULL,
after_stock INT NOT NULL,
created_at DATETIME NOT NULL,
PRIMARY KEY (id),
UNIQUE KEY uk_inventory_request_type (request_id, transaction_type),
KEY idx_inventory_product_time (product_id, created_at)
) ENGINE=InnoDB;
CREATE TABLE order_info (
order_id VARCHAR(64) NOT NULL,
request_id VARCHAR(64) NOT NULL,
product_id BIGINT NOT NULL,
quantity INT NOT NULL,
order_status VARCHAR(32) NOT NULL,
created_at DATETIME NOT NULL,
PRIMARY KEY (order_id),
UNIQUE KEY uk_order_request (request_id)
) ENGINE=InnoDB;

这里有三个设计重点。第一，库存表的主键直接定位商品。第二，库存流水保存变更前后库存，使异常排查不必依赖应用日志。第三，订单和流水都保存 request_id，让重试、回调和异步消费可以回到同一个业务意图。

需要说明的是，MySQL 对 CHECK 约束的实际行为与版本有关，发布前应确认目标版本是否真正执行该约束。即使数据库能够阻止负库存，也不要把 CHECK 当成并发扣减方案，它只是最后一道数据边界。

2. 用事务完成一次扣减和订单创建

在订单和库存位于同一个数据库的情况下，可以使用类似下面的事务逻辑。示例重点是顺序和判定，不绑定某种编程语言。

START TRANSACTION;
-- 先根据 request_id 判断是否已经处理

SELECT order_id, order_status

FROM order_info

WHERE request_id = ?

FOR UPDATE;

-- 如果已经存在，则返回已有订单结果，不再执行扣减

-- 读取扣减前库存，用于库存流水

SELECT stock

FROM product_stock

WHERE product_id = ?

FOR UPDATE;

-- 原子扣减

UPDATE product_stock

SET stock = stock - ?,

version = version + 1,

updated_at = CURRENT_TIMESTAMP

WHERE product_id = ?

AND stock >= ?;

-- 必须检查受影响行数

-- affected_rows = 1 才允许继续创建订单

INSERT INTO order_info (

order_id, request_id, product_id, quantity,

order_status, created_at

) VALUES (?, ?, ?, ?, 'PENDING_PAYMENT', CURRENT_TIMESTAMP);

INSERT INTO inventory_transaction (

request_id, order_id, product_id, transaction_type,

quantity, before_stock, after_stock, created_at

) VALUES (?, ?, ?, 'DEDUCT', ?, ?, ?, CURRENT_TIMESTAMP);

COMMIT;

实际实现时，需要避免在同一个事务里长时间调用支付、物流或其他远程服务。远程调用一旦放在数据库事务内部，锁持有时间会随着网络延迟变长，热点商品更容易产生锁等待和死锁。

3. “先锁定读取再条件更新”是否重复

示例中同时出现了锁定读取和条件更新，初学者可能会认为这两步重复。它们承担的作用并不完全相同。

• 锁定读取用于获得扣减前库存，便于写入准确的 before_stock 和 after_stock。
• 条件更新用于把库存下限作为数据库更新条件再次确认。
• 唯一请求号用于防止同一业务请求重复生效。

如果库存流水不要求记录扣减前后值，也可以简化为直接条件 UPDATE，再根据明确的业务逻辑写入流水。但如果选择简化，就要确认流水记录能够通过其他方式可靠地获得变更结果，不能因为少了一次查询就失去审计能力。

4. 高并发下更适合用增量流水还是快照流水

库存流水有两种常见记录方式。增量流水只记录本次增加或减少多少，存储成本低，但排查时需要按时间顺序聚合。快照流水同时记录变更前和变更后库存，审计直观，但必须保证读取和写入处于正确的事务边界。

5. 用数据查询验证库存是否真的安全

下面这些查询不能替代完整测试，但适合做日常巡检和事故初筛。

-- 检查负库存
SELECT product_id, stock, updated_at

FROM product_stock

WHERE stock < 0;

-- 检查同一请求是否产生重复扣减

SELECT request_id, COUNT(*) AS deduct_count

FROM inventory_transaction

WHERE transaction_type = 'DEDUCT'

GROUP BY request_id

HAVING COUNT(*) > 1;

-- 检查订单和库存扣减数量是否不一致

SELECT

o.product_id,

SUM(o.quantity) AS order_quantity,

SUM(t.quantity) AS deduct_quantity

FROM order_info o

LEFT JOIN inventory_transaction t

ON o.order_id = t.order_id

AND t.transaction_type = 'DEDUCT'

WHERE o.order_status IN ('PAID', 'FULFILLED')

GROUP BY o.product_id

HAVING SUM(o.quantity) <> COALESCE(SUM(t.quantity), 0);

第三条查询在真实环境中还需要处理取消订单、拆单、合单、退货和多商品订单。它的价值不在于直接给出最终答案，而在于帮助我们发现“订单状态和库存事件无法解释”的数据行。

六、具体数据观察：如何设计一次可复现的并发验证

1. 不要只看接口成功率

很多压测报告只记录响应时间和 HTTP 状态码，这对库存系统是不够的。接口返回 200，不代表扣减成功；接口超时，也不代表数据库事务一定回滚。

一次合格的库存并发测试，至少应同时记录：

• 初始库存数量。
• 并发请求总数。
• 成功扣减次数。
• 库存不足次数。
• 数据库异常次数。
• 重复请求数量。
• 最终库存余额。
• 库存流水总量及重复流水数量。
• 订单状态分布。
• 锁等待和死锁次数。

只有把这些数据放在一起，才能判断一个方案是“正确但慢”“很快但错账”，还是“当前正确，继续扩容后会被热点行拖垮”。

2. 一个库存为 1 的最小验证用例

我建议先从最小场景开始，而不是一上来就模拟复杂促销。将商品库存设为 1，同时发起 2 个独立请求，并人为增加应用层读取和写入之间的延迟。这样可以放大竞态窗口，快速观察普通方案与条件更新方案的差异。

-- 测试前
UPDATE product_stock

SET stock = 1,

version = 0

WHERE product_id = 10001;

-- 并发请求的目标

-- request_id = req-A, quantity = 1

-- request_id = req-B, quantity = 1

-- 测试后检查

SELECT product_id, stock, version

FROM product_stock

WHERE product_id = 10001;

SELECT request_id, order_id, transaction_type, quantity

FROM inventory_transaction

WHERE product_id = 10001

ORDER BY id;

预期结果不是“两个请求都返回成功”，而是最多一个请求完成有效扣减。另一个请求应该得到库存不足、幂等已处理或明确的异常状态。最终库存不能低于 0，成功扣减流水数量不能超过初始可售库存。

3. 建议基准与模拟观察

下面是一组用于方案评审的情景模拟，不是某个真实系统的线上统计。假设库存为 10,000 件，并发请求 20,000 次，每次请求购买 1 件，数据库为单主实例，商品库存集中在一行，未引入缓存和队列。

这组模拟说明了一个重要事实：条件 UPDATE 的首要价值是建立正确性下限，而不是承诺最高吞吐量。当 20,000 个请求争抢同一库存行时，数据库需要排队并发写入；如果业务流量远高于单行处理能力，下一步应该优化热点分布，而不是继续堆叠更复杂的锁。

4. 观察数据库锁竞争，而不是凭感觉判断性能

在 MySQL InnoDB 中，应结合慢查询日志、性能监控和事务状态观察锁等待。可以从下面几类信息入手：

• 锁等待事务数量和持续时间。
• 同一 product_id 的更新耗时分布。
• 死锁发生频率和涉及的 SQL 顺序。
• 数据库连接池是否被等待中的事务占满。
• 库存不足请求是否因为真正缺货，还是因为超时和重试放大。

数据库管理员不应只提供一个平均响应时间。库存热点通常呈现长尾特征，平均值可能是 20 毫秒，但 P99 已经达到数秒。对于下单链路，P99 的锁等待往往比平均值更能解释用户感受到的失败。

5. 把重复请求加入测试，才能验证幂等

第二组测试应让同一个 request_id 连续发送多次，同时让不同 request_id 竞争同一个商品。预期是同一个请求无论发送 1 次还是 5 次，都只能产生一条有效扣减流水；不同请求则按照库存余量竞争。

SELECT request_id, transaction_type, COUNT(*) AS row_count
FROM inventory_transaction

WHERE product_id = 10001

GROUP BY request_id, transaction_type

HAVING COUNT(*) > 1;

如果这条查询返回了重复扣减记录，说明系统的幂等机制没有真正落在数据库约束上，或者补偿逻辑使用了不同的请求标识。仅依赖应用代码中的“先查询是否存在，再插入”仍然可能出现并发竞态，关键幂等键应尽量交给唯一索引兜底。

七、不同业务情况下的行动建议：先解决当前最危险的问题

1. 普通商品、并发量可控：优先使用条件更新

如果商品库存集中在一个关系型数据库，单个商品的并发量可控，且订单和库存可以放在同一事务中，我建议优先采用条件 UPDATE、唯一幂等键和库存流水。这个方案结构清楚，故障排查成本低，也不需要先引入缓存和消息队列。

最低落地要求包括：

• 库存扣减使用 stock >= quantity 条件。
• 商品 ID 使用主键或唯一索引定位。
• 根据受影响行数确认扣减结果。
• 订单请求号具备唯一约束。
• 扣减、订单和流水在同一事务中完成，或有明确补偿机制。

如果团队目前仍采用“查询库存后在代码里判断”，最优先的改动不是优化 SQL 格式，而是把库存条件移动到 UPDATE 中，并补上失败结果处理。

2. 需要锁定库存一段时间：采用冻结、解冻和消耗三态模型

对于支付未完成前需要保留库存的业务，不建议把所有流程都叫“扣减”。更清晰的方式是把库存动作拆成冻结、解冻和最终消耗。

-- 冻结库存
UPDATE product_stock

SET stock = stock - ?,

locked_stock = locked_stock + ?,

version = version + 1

WHERE product_id = ?

AND stock >= ?;

-- 支付成功，锁定库存转为已消耗

UPDATE product_stock

SET locked_stock = locked_stock - ?

WHERE product_id = ?

AND locked_stock >= ?;

-- 订单取消，释放锁定库存

UPDATE product_stock

SET stock = stock + ?,

locked_stock = locked_stock - ?

WHERE product_id = ?

AND locked_stock >= ?;

三态模型的价值在于，库存余额能够解释订单生命周期。支付失败不是“扣减失败”，而是“冻结成功后需要解冻”。如果所有动作都只修改一个 stock 字段，后续很难区分销售消耗和超时释放。

3. 热点商品、瞬时流量很高：缓存或队列只放在入口层

当单个商品成为绝对热点，所有请求竞争同一数据库行，条件更新仍可能成为瓶颈。这时可以在入口使用缓存原子扣减、库存令牌或消息队列削峰。

但我建议保留以下底线：

• 缓存扣减必须携带唯一业务请求号。
• 成功预扣后必须有可靠事件落库。
• 落库失败要能重试，重试要幂等。
• 缓存余额、数据库库存和订单占用量要定期对账。
• 缓存故障时应有降级策略，而不是无限等待。

如果业务不允许“预扣后再取消”，就要谨慎评估缓存方案。缓存的高吞吐优势通常伴随更复杂的补偿链路，不能只对比接口耗时。

4. 多仓库或多库存池：先确定分配规则

多仓库场景下，库存超卖可能发生在库存池之间，而不是单一商品行。比如总库存为 100 件，但华东仓和华南仓分别被不同服务独立扣减，汇总层没有统一协调，最终总量可能被多次分配。

这时需要先确定库存归属：

1. 订单下单时就锁定具体仓库。
2. 由统一库存服务维护总可售量，再异步分配到仓库。
3. 各仓独立销售，汇总层只做展示，不共享可售额度。

没有清晰的库存池边界时，单条 SQL 无法解决跨仓库的业务竞争。数据库管理员应推动业务方明确“哪张表、哪一个字段、哪一个服务是可售库存的权威来源”。

5. 使用数据分析工具做对账：让异常从日志里走出来

库存异常排查往往需要同时关联订单表、库存表、库存流水、支付记录和补偿记录。单靠数据库管理员临时写 SQL，容易形成一次性排查，无法持续发现问题。

以九数云这类数据分析工具为例，可以把数据库中的订单、库存流水和补偿任务同步到分析层，建立按商品、仓库、渠道和时间窗口切分的对账看板。这里的价值不是让分析工具参与扣库存，而是把以下异常变成可持续监控的指标：

• 订单成功但没有有效扣减流水。
• 扣减成功但订单在规定时间内没有创建。
• 同一 request_id 出现多条扣减流水。
• 库存表余额与流水推导余额不一致。
• 补偿任务超过 SLA 仍未完成。

如果使用九数云进行这类分析，仍要注意数据延迟和同步口径。分析层适合监控趋势、定位异常批次和生成日报，不适合替代交易数据库中的实时条件扣减。扣减发生在哪里，最终约束就应该在哪里生效；看板只能帮助我们更早发现偏差。

八、不同方案的取舍：正确性、吞吐量和运维成本不可能同时无限提高

1. 条件更新：最适合作为默认基线

条件更新的最大优点是边界清楚：库存不足时数据库不更新，应用通过受影响行数获取结果。它适合大多数普通库存和中等并发场景，尤其适合团队希望先降低系统复杂度的情况。

它的短板也很明确：热点商品的库存行会产生写竞争，所有请求最终都要争用同一个数据行。如果商品访问高度集中，即使 SQL 逻辑正确，响应时间也会因为排队升高。

2. 悲观锁：适合多步强一致，但要控制事务范围

悲观锁适合库存变更和订单写入必须强一致、并且业务步骤较少的场景。它的逻辑容易理解，数据库也能清楚地控制并发顺序。

代价是锁持有时间会受事务内其他操作影响。把远程接口、复杂计算或大批量写入放在锁内，都会扩大等待范围。使用悲观锁时，我会重点检查索引、事务访问顺序、超时时间和死锁重试策略。

3. 乐观锁：适合冲突可接受、业务能够重试的场景

乐观锁可以通过版本号避免覆盖更新：

UPDATE product_stock
SET stock = stock - ?,

version = version + 1

WHERE product_id = ?

AND stock >= ?

AND version = ?;

如果受影响行数为 0，可能是库存不足，也可能是版本已经变化。应用需要重新读取并决定是否重试。对于库存极少、竞争极强的商品，频繁重试可能把数据库压力进一步放大，因此乐观锁并不一定优于条件更新。

4. 缓存预扣：吞吐量高，但补偿体系必须成熟

缓存预扣适合大量请求在短时间内集中涌入，并且业务可以接受订单进入异步确认流程的场景。它能够把热点请求从数据库前移，降低数据库单行更新压力。

但缓存方案要额外承担数据恢复、主从切换、消息可靠投递、重复消费、超时释放和定期对账。对于没有稳定运维能力的团队，缓存预扣可能带来的故障复杂度高于它解决的性能问题。

5. 消息队列：适合削峰，不适合掩盖错误状态

队列能把瞬时请求转化为相对平滑的消费速度，但用户会面对“已提交、处理中、待确认”等异步状态。系统必须告诉用户哪些状态可以取消、哪些状态已经锁定库存、哪些状态最终会失败。

如果队列消费失败只依赖人工查看日志，库存系统就会形成新的黑盒。至少应具备消息唯一键、消费状态、失败原因、重试次数和死信处理。

九、失败处理和对账：真正的系统安全感来自可恢复

1. 先区分“明确失败”和“结果未知”

库存扣减失败不等于所有异常都可以直接重试。库存不足是明确失败，通常不应立即重试；数据库连接超时则可能处于结果未知状态，直接重试可能造成重复扣减。

结果未知时，正确顺序通常是：

1. 使用原 request_id 查询订单表和库存流水。
2. 确认事务是否已经提交。
3. 如果已有成功流水，返回原业务结果。
4. 如果没有成功流水，再根据错误类型决定是否重试。
5. 超过自动重试次数后进入补偿或人工队列。

这也是为什么 request_id 不能只存在于应用日志中。它必须进入订单、流水、消息和补偿记录，成为跨系统定位同一业务意图的关联键。

2. 回补库存也必须具备幂等性

很多系统在扣减时考虑了幂等，却在订单取消和支付失败回补时忽略了重复通知。支付服务可能重复发送失败回调，定时任务也可能再次扫描到同一个订单。如果每次都执行 stock = stock + quantity，就会出现库存虚增。

回补流水应使用独立的业务动作标识，例如 order_id + RELEASE。数据库唯一索引保证同一订单的同一类释放动作只能生效一次。

INSERT INTO inventory_transaction (
request_id, order_id, product_id, transaction_type,
quantity, before_stock, after_stock, created_at
) VALUES (?, ?, ?, 'RELEASE', ?, ?, ?, CURRENT_TIMESTAMP)
ON DUPLICATE KEY UPDATE
id = id;

上面的写法只是展示幂等思路。不同数据库对重复键处理语法不同，正式实现时应结合事务隔离、返回值语义和异常处理进行验证，不能直接复制到所有数据库环境。

3. 对账要回答“差了多少”和“为什么差”

对账不是简单比较两张表的总数。有效的对账需要先统一时间窗口和状态口径，例如只统计已支付订单，还是包含待支付冻结订单；是否扣除退款；是否包含仓库盘点调整。

建议建立三类余额：

• 数据库当前余额：库存表此刻记录的 stock。
• 流水推导余额：期初余额加所有有效增减流水。
• 业务占用余额：根据订单状态计算出的有效占用量。

三者不一定在每个时刻完全相等，但任何差异都应该有明确定义。例如异步消息尚未消费造成的短暂差异必须有 SLA；如果超过 SLA 仍未收敛，就应该自动告警。

4. 建议建立异常优先级

十、数据库管理员的发布前检查清单

1. SQL 和表结构检查

• 库存扣减是否在 WHERE 条件中包含 stock >= quantity。
• 商品定位字段是否为主键或唯一索引。
• quantity 是否经过正数校验，是否存在整数溢出风险。
• 库存字段是否使用了足够的数值范围。
• 库存流水是否记录 request_id、order_id 和 transaction_type。
• 扣减和回补是否使用不同且可识别的业务动作。

尤其要检查 quantity 的输入边界。很多示例默认每次只买 1 件，但真实接口可能允许一次购买多件。如果 SQL 只写 stock > 0，而没有写 stock >= quantity，就可能在批量购买时出现库存被扣成负数或扣减数量不符合预期。

UPDATE product_stock
SET stock = stock - ?,

version = version + 1

WHERE product_id = ?

AND stock >= ?

AND ? > 0;

2. 事务和重试检查

• 事务中是否包含远程调用。
• 事务失败后是否会自动回滚。
• 提交结果未知时是否会先查询 request_id。
• 死锁重试是否使用同一个业务请求号。
• 重试是否可能重复插入订单或重复扣减。
• 连接池耗尽时是否会触发级联超时。

死锁重试尤其需要谨慎。数据库层面的死锁重试可以重新执行事务，但业务层不能重新生成一个新的 request_id，否则数据库无法识别这是同一笔业务重放。

3. 监控和数据质量检查

• 监控库存负数和库存异常跳变。
• 统计扣减成功但订单创建失败的数量。
• 统计订单成功但没有有效扣减流水的数量。
• 监控同一 request_id 的重复动作。
• 监控热点商品的锁等待、P95 和 P99 延迟。
• 监控补偿任务积压和超过 SLA 的记录。
• 按商品、仓库和渠道建立库存对账维度。

如果团队使用九数云这类分析工具做管理看板，建议把“实时交易状态”和“离线分析状态”明确分层。实时系统负责阻止错误发生，分析系统负责发现趋势、定位批次、比较渠道和追踪补偿结果。

4. 故障演练检查

没有故障演练的库存方案，往往只在正常路径上成立。至少应该模拟以下情况：

1. 库存扣减成功后，订单插入前应用进程宕机。
2. 订单提交成功后，客户端没有收到响应并重复请求。
3. 消息投递成功但消费端处理超时。
4. 支付失败回调重复到达。
5. 缓存预扣成功但数据库服务短暂不可用。
6. 数据库主从切换期间出现连接和提交结果未知。

每次演练都应记录最终库存、订单状态、流水数量、补偿耗时和人工介入次数。只有当系统能够在故障后自动收敛，方案才算具备真正的生产可用性。

十一、遇到不同问题时，应该怎样行动

1. 已经发现负库存：先止损，再修复

发现负库存后，不建议立即执行一条“加回去”的 SQL。第一步应冻结相关商品的销售入口，保留库存表、订单表、流水表、应用日志和消息记录，避免后续操作覆盖事故现场。

接着按照时间顺序重建库存变化：

1. 确认事故开始和结束时间。
2. 计算期初库存和期间所有库存事件。
3. 关联有效订单、取消订单和退款记录。
4. 识别重复请求和重复消费。
5. 区分数据库错误、业务定义错误和仓库实物差异。
6. 制定订单取消、替代履约或补发方案。

修复 SQL 应该来自确认后的差异，不应该直接根据当前负数猜一个回补数量。否则可能把数据库修正为非负，却让库存流水和订单关系更加混乱。

2. 没有负库存但订单多了：重点查业务资格分配

如果库存字段没有负数，而有效订单数量超过可售量，优先检查是否存在“预占资格”和“正式扣减”两套流程。常见问题是活动服务先发放购买资格，库存服务随后异步扣减；资格发放没有使用同一幂等键，导致两个订单都认为自己合法。

这类问题不能只修复库存表，还要核查订单创建入口、活动名额表、优惠券核销表和消息消费记录。最终需要确认“谁拥有分配资格”，并让这个资格本身具备唯一性。

3. 扣减成功但订单失败：选择回滚还是补偿

如果库存和订单在同一个数据库内，优先考虑让它们处在同一事务中，订单插入失败时库存扣减一起回滚。这样能减少补偿数量，但事务必须足够短。

如果两者跨服务，就要接受最终一致性。此时应记录库存扣减事件，订单服务消费后创建订单；如果订单创建失败，由补偿任务产生释放动作。补偿动作必须有状态、有重试次数、有最终告警，不能只依赖定时脚本悄悄执行。

4. 锁等待过高：先查热点和事务，再考虑换技术

锁等待高不等于数据库方案错误。先检查是否所有商品都集中更新同一行、是否存在无索引扫描、事务是否包含远程调用、是否因为客户端超时而重复发起请求。

只有在确认 SQL、索引、事务范围和重试策略都合理后，仍然无法满足峰值吞吐，才应该评估库存分段、令牌桶、缓存预扣或队列削峰。过早引入这些组件，可能把一个可定位的锁竞争问题变成多个难以对账的分布式状态问题。

5. 数据库和仓库实物不一致：不要把系统对账当成实物盘点

数据库对账只能证明系统内部的订单、库存和流水是否一致，不能证明仓库里真的有这么多货。仓库盘点、损耗、错发、退货未入库都会让实物库存与系统库存产生差异。

因此，完整库存治理应分为两层：系统内对账负责发现交易链路异常，仓储盘点负责确认实物差异。两者都需要记录调整原因和责任边界，不能用人工修改 stock 字段代替库存事件。

十二、最终建议：把“防超卖”改造成可验证的数据工程

1. 最小可行方案

如果现在只能做一轮改造，我建议按照以下顺序实施：

1. 将库存扣减改为带 stock >= quantity 条件的 UPDATE。
2. 检查受影响行数，并区分库存不足与数据库异常。
3. 给 request_id 或订单号增加唯一索引。
4. 建立库存扣减、回补和冻结流水。
5. 让订单状态可以解释库存是否仍被占用。
6. 增加负库存、重复流水和订单无流水巡检。
7. 用并发测试验证成功扣减数量和最终余额。

这套方案不一定让系统拥有最高吞吐量，但能先建立清晰的正确性底线。对于很多库存系统来说，先把“知道发生了什么”做好，比盲目追求更高 QPS 更重要。

2. 需要升级架构时的判断顺序

当系统出现性能瓶颈时，建议按以下顺序判断：

• 是否有无条件扣减或应用层先查后改。
• 是否缺少商品唯一索引。
• 是否存在远程调用占用数据库事务。
• 是否因为超时重试放大了写请求。
• 是否所有流量都集中在同一商品行。
• 是否可以通过库存分片或分段降低热点。
• 最后再评估缓存和消息队列带来的复杂度。

如果前四项还没有解决，直接上缓存或队列通常只是把问题往后推。高并发架构优化应该建立在正确性已经被测试和监控证明的基础上。

3. 我最看重的验收标准

一个库存方案是否可靠，我不会只看它能否在压测中跑出漂亮的吞吐量，而会看以下结果能否被复核：

• 库存余额永远不会因为并发扣减低于业务允许的下限。
• 同一业务请求重复发送不会产生多次有效扣减。
• 每个有效订单都能找到对应库存流水。
• 每个库存流水都能说明它服务于哪个订单或补偿动作。
• 数据库异常、消息重复和客户端超时后，系统能够查询并恢复到确定状态。
• 库存表、流水推导余额、订单占用量和仓库盘点结果的差异都有解释。

我的最终判断是：库存超卖不是一个“有没有加锁”的单点问题，而是一个需要被数据库、订单状态、幂等机制和对账系统共同证明的数据问题。条件更新是可靠起点，受影响行数是实时判定，库存流水是事后证据，幂等和补偿是故障恢复，对账则是长期验证。

下一步可以先选一个真实商品，记录初始库存，构造“库存为 1、并发请求为 2”的最小测试，再逐步加入重复请求、订单失败、支付回调重复和数据库超时场景。测试结束后不要只看接口响应，而要核对库存表、订单表、流水表和补偿记录。能把这四张表对上的方案，才是真正降低了超卖风险的方案。

UPDATE product_stock SET stock = stock - 1, updated_at = CURRENT_TIMESTAMP WHERE product_id = ?AND stock > 0;

INSERT INTO orders(order_id, user_id, status) VALUES (?, ?, 'PENDING');UPDATE product_stock SET stock = stock - 1 WHERE product_id = ?AND stock > 0;

CREATE UNIQUE INDEX uk_inventory_request ON inventory_transaction(request_id);

免费注册

咨询方案

扫码咨询方案