数据库存：数据库管理员实战复盘：高并发秒杀中库存超卖的定位步骤

一次秒杀事故里，后台显示库存已经归零，支付订单却比初始库存多出 37 笔；更反常的是，数据库没有报错，CPU、内存和磁盘 I/O 也都没有打满。后来我把问题定位到一个只有两行代码的库存扣减逻辑：应用先查询库存，再在应用层判断是否足够，最后执行更新。并发请求把“查询”和“更新”之间的时间窗口放大后，多个请求都拿到了同一个可售库存值。

这类超卖问题最容易被误判为“数据库扛不住了”，但真正的核心通常不是数据库性能，而是库存状态的读取、判断、扣减、订单确认之间缺少一个不可打断的状态转换。本文按照一次匿名化的生产事故复盘，说明我如何从订单数量、数据库日志、事务行为、锁等待和消息链路逐层定位问题，并给出不同架构下的修复取舍。

一、先讲核心结论：库存超卖首先是状态一致性问题

1. 先判断“卖多了”到底发生在哪一层

库存超卖并不只代表数据库中的库存字段变成了负数。在线上系统里，至少存在四种不同的“超卖”表现：可售库存被扣成负数、订单创建数量超过可售库存、支付成功数量超过实际可履约数量、库存账与仓库实物账不一致。

这四种情况的根因和处理方式并不相同。如果只看商品表中的 stock 字段，很可能会错过真正的问题。例如数据库里库存仍然是 0，但订单表中出现了超过库存数量的待支付订单，这说明系统可能采用了“预占库存”模型，问题发生在预占记录、订单取消回补或支付超时释放环节。

我在事故初期会先问一句：“超卖的数量，是由哪一张表、哪一个状态、哪一条流水定义出来的？”如果团队连“卖出数量”的口径都没有统一，直接加锁或扩容往往只是把问题推迟到下一次高峰。

2. 最可靠的修复不是“加一层判断”，而是让扣减具备原子性

库存扣减至少需要满足三个条件：扣减动作不可被并发请求拆开观察；库存不足时数据库必须拒绝更新；同一个业务请求重复到达时不能重复扣减。对应到数据库层，最基础的安全写法是带条件的原子更新。

UPDATE sku_stock
SET available_stock = available_stock - #{quantity},

version = version + 1,

updated_at = CURRENT_TIMESTAMP

WHERE sku_id = #{skuId}

AND available_stock >= #{quantity};

执行后必须检查受影响行数。受影响行数为 1，才代表本次扣减成功；受影响行数为 0，可能是库存不足、商品不存在、版本不匹配，或事务隔离和条件设计存在问题。不能因为 SQL 执行没有异常，就认为库存扣减成功。

如果库存扣减成功后还要创建订单，单条 SQL 仍然不够。扣减、预占流水、订单创建至少需要明确事务边界；如果订单和库存分属不同数据库，还需要使用可靠消息、事务消息或可补偿的状态机，而不是依赖一个跨库事务“看起来成功”。

3. 定位顺序应当从业务事实倒推，而不是从监控面板猜

我通常采用“事实确认，时间线还原，SQL 验证，并发复现，链路补偿”的顺序。先确认到底多了多少单，再将请求、数据库更新、消息投递、支付和回补事件按时间排序，随后检查实际执行的 SQL，最后用同样的并发模式在隔离环境复现。

二、背景和真实场景：一次秒杀库存事故是怎样发生的

1. 事故场景和业务规则

本次复盘对象是一款限量商品，数据库初始可售库存为 1,000 件。业务规则是每个用户最多购买 1 件，订单创建后 15 分钟内未支付自动关闭，关闭后释放预占库存。系统由网关、秒杀服务、订单服务、库存库、支付服务和仓储系统组成。

系统上线前的压测结果并不差：普通下单接口能够稳定承受每秒约 2,000 次请求，数据库连接池没有明显耗尽，接口平均响应时间约 80 毫秒。问题在于，普通下单压测使用了大量不同商品和较低热点集中度，而真实秒杀中 80% 以上请求集中访问同一个 SKU。

事故发生时，网关在 10 秒内接收约 120 万次请求。经过限流、验证码和用户校验后，进入库存判断的请求约 4.86 万次。最终创建订单 1,037 笔，数据库中的可售库存为 0，支付成功 1,018 笔。

这里最有价值的观察是：数据库并没有出现慢查询洪峰，反而因为库存查询很简单，查询响应时间保持在毫秒级。真正危险的不是单次查询慢，而是许多请求在极短时间内读到了同一个旧库存快照，然后同时进入扣减流程。

2. 事故时间线

事故时间线说明一个经常被忽略的事实：库存归零并不意味着库存安全。库存归零可能只是某个缓存值、某个展示字段或某次更新的结果。只有把订单、库存变更、支付和履约放在同一条事件链上，才能判断系统到底在哪个节点越过了库存边界。

3. 原始库存代码为什么看起来“没有问题”

事故版本的逻辑大致如下。代码先查询库存，判断库存是否大于零，再调用更新接口。单线程执行时，这段代码完全符合业务直觉；低并发时，也通常不会暴露问题。

Stock stock = stockRepository.findBySkuId(skuId);
if (stock.getAvailableStock() <= 0) {

throw new SoldOutException();

}

stockRepository.decrease(skuId);

orderRepository.create(userId, skuId);

问题在于，findBySkuId 和 decrease 是两个独立数据库操作。假设库存还剩 1 件，请求 A 和请求 B 都可能在扣减前读到 1。A 判断通过，B 也判断通过；如果更新语句没有携带 available_stock >= 1 条件，两个请求都可能成功写入订单。

即便更新语句本身使用了“库存减一”，如果数据库字段允许负数，最终结果也可能是库存为 -1。此时数据库只是忠实执行了两次合法更新，并不知道业务上只能卖 1 件。

三、常见误区：为什么很多排查会走偏

1. 误区一：看到数据库 CPU 不高，就排除数据库问题

数据库的 CPU 使用率低，不代表事务设计正确。库存超卖往往是一个逻辑竞态条件，消耗的不是大量计算资源，而是多个事务之间错误地交错执行。两个请求各执行一次简单查询，CPU 可能只有 30%，但它们仍然可以共同制造一次超卖。

我见过一次排查中，团队把“数据库没有慢查询”当成库存安全的证据。后来对照事务日志发现，库存查询、库存更新、订单创建分别位于不同事务中，应用层还存在一次失败重试。数据库性能没有问题，问题是业务把一个应该连续完成的状态转换拆成了多个可独立成功的步骤。

2. 误区二：给查询加锁，就认为库存不会超卖

常见修复是把查询改为 SELECT ... FOR UPDATE。这在明确事务边界、同一事务内完成扣减和订单预占时可能有效，但如果查询结束后事务已经提交，锁就释放了，后面的更新仍然不受保护。

-- 只有在同一事务内执行后续扣减时，行锁才有保护意义
BEGIN;

SELECT available_stock

FROM sku_stock

WHERE sku_id = 10001

FOR UPDATE;

UPDATE sku_stock

SET available_stock = available_stock - 1

WHERE sku_id = 10001;

INSERT INTO stock_reservation

(request_id, sku_id, quantity, status)

VALUES

('req-20260919-0001', 10001, 1, 'RESERVED');

COMMIT;

这段写法的代价是热点 SKU 会形成锁竞争。它适合库存量较大、请求量可控、订单和库存位于同一个事务边界内的场景，不适合未经限流就把几十万请求全部压到同一行。

3. 误区三：把 Redis 原子扣减当成完整库存方案

缓存中的原子递减可以快速挡住大部分请求，但它只解决了“缓存计数不能同时被两个请求错误修改”的问题，并没有自动解决数据库落库失败、服务重启、消息重复、订单取消回补和缓存重建。

如果缓存扣减成功，数据库写订单失败，库存就会暂时少一件；如果消息重复消费，数据库可能再次扣减；如果缓存重启后用错误的数据库字段重建，库存还可能被恢复到已经售出的数量。因此，缓存原子操作必须配合扣减流水、请求幂等键和对账任务。

4. 误区四：只依赖唯一索引限制“一人一单”

在订单表增加 UNIQUE(user_id, sku_id) 可以阻止同一用户创建两笔相同商品订单，但它不能保证不同用户之间不超卖。唯一索引解决的是重复订单，不是总库存边界。

更麻烦的是，如果应用把唯一键冲突当作普通异常并自动重试，可能在库存已经扣减成功的情况下重复创建订单。设计时必须定义：唯一键冲突是否触发库存回补，回补是否可重复，回补流水怎样关联原始请求。

5. 误区五：用数据库事务包住所有远程调用

有些团队会把支付、优惠券、积分和库存都放进一个长事务，试图用一个事务解决一致性。远程调用一旦变慢，数据库行锁就会持续占用；秒杀热点集中在同一个 SKU 时，锁等待会迅速放大，最终从超卖问题转变为数据库连接池耗尽。

库存事务应该尽量短。数据库只负责自己边界内可以保证的状态变化，跨服务一致性通过状态机和可靠事件推进。事务越长，不代表一致性越强；如果事务包含不可控的网络调用，通常只代表故障半径更大。

6. 误区六：只修复数据库，不修复流量入口

即使原子扣减已经正确，几十万请求仍然全部打到同一行，也会制造大量锁等待、超时和重试。最终虽然不会超卖，却可能出现大量用户收到“系统繁忙”，数据库连接池被占满，消息队列积压，支付状态无法及时更新。

正确做法是把库存安全和流量治理分开：数据库保证最后一道边界，网关、令牌桶、队列、缓存和前端按钮防抖负责减少无意义的竞争。安全扣减解决“不能卖多”，流量治理解决“不要让所有人都争同一把锁”。

四、专业判断逻辑：如何逐层定位库存超卖

1. 第一步：冻结现场，先做止损而不是先改代码

事故确认后，我会先停止继续放大问题的入口。优先级通常是暂停活动、关闭库存扣减接口、停止支付成功后的自动履约确认，必要时临时把库存设置为不可售。不要一开始就直接修改库存字段，因为人工改数会破坏原始证据。

止损操作必须留下操作时间、操作者、影响范围和回滚方式。尤其要记录当时数据库中的库存、预占数、订单数、支付成功数和仓储可用数。后续对账需要依赖这些快照，不能只凭事故群里的口头结论。

• 保留应用日志、数据库审计日志、慢查询日志和消息消费日志。
• 记录所有正在处理的订单、支付回调和库存回补任务。
• 暂停自动重试，避免同一失败请求在排查期间继续扩大扣减。
• 对问题 SKU 建立临时人工审核，暂缓自动履约。
• 单独保存缓存中的库存值，不能让缓存重建覆盖现场数据。

2. 第二步：建立库存守恒公式

库存问题最怕“每个系统都有一个数字”。我会先把各个数字放进同一条守恒公式中：

初始库存 = 已售库存 + 有效预占库存 + 可售库存 + 已取消待回补差额 + 异常差额

实际项目中，已售库存通常来自支付成功或订单确认，预占库存来自有效库存流水，取消待回补差额来自关闭订单。异常差额不是一个可以长期接受的业务项，但事故定位阶段必须把它单独列出，否则所有无法解释的数量都会被隐含在“库存字段”里。

以本次案例为例，初始库存 1,000 件，支付成功订单 1,018 笔，待支付有效预占 19 件，数据库可售库存 0 件。即使不考虑取消回补，守恒公式已经出现至少 37 件的异常差额。这个数字与订单表中多出的 37 笔相互印证，说明问题不是单纯的仓储数据延迟。

3. 第三步：按请求号重建单次业务路径

没有请求号，日志只能证明系统很忙，不能证明哪个请求造成了超卖。库存扣减接口至少应携带全链路请求号、用户编号、订单号、SKU 编号、扣减数量和重试次数。

我会随机抽取三类记录：成功订单、支付成功但库存异常订单、库存扣减失败订单。然后检查每条记录是否能串起“请求进入，库存判断，库存更新，流水写入，订单创建，支付确认，履约确认”的完整路径。

这一步经常会发现两个隐藏问题。第一，库存扣减成功日志只是应用在执行 SQL 前打印的，不代表数据库真的更新成功；第二，同一个订单号被多个线程处理，但日志只打印了用户编号，导致重复消费无法识别。

4. 第四步：检查实际 SQL，而不是只看 ORM 方法名

业务代码里的 decreaseStock() 可能对应一条带条件更新，也可能只是先查后改。定位时必须拿到最终发送给数据库的 SQL、绑定参数、事务编号和受影响行数。

重点检查以下内容：

• 更新语句是否包含 available_stock >= quantity 条件。
• 是否检查受影响行数，而不是只判断数据库调用是否抛异常。
• 库存数量是否使用整数类型，是否存在单位换算或浮点转换。
• 同一个请求是否可能执行两次更新。
• 更新库存和写库存流水是否在同一个事务中。
• 事务提交失败后，应用是否错误地返回了成功。
• SQL 重试是否具有幂等保护。

如果使用乐观锁，还要检查版本字段是否真的参与更新条件。正确的形式应类似下面的逻辑：只有读取时版本为 18、库存至少为 1 的那一行，才允许更新到版本 19。

UPDATE sku_stock
SET available_stock = available_stock - 1,

version = version + 1

WHERE sku_id = 10001

AND version = 18

AND available_stock >= 1;

如果返回 0 行，应用必须重新读取或直接返回库存不足，而不能把 0 行更新当作成功。乐观锁的核心不是“增加一个 version 字段”，而是把版本校验放进真正改变库存的那条 SQL 中。

5. 第五步：观察锁等待、死锁和事务持续时间

锁等待是判断“数据库安全但被打爆”与“数据库逻辑不安全”的重要证据。对于 MySQL，可以结合 performance_schema、InnoDB 锁等待视图、数据库错误日志和应用连接池指标进行观察；其他关系型数据库也应使用对应的活动会话和锁监控能力。

SELECT
waiting_pid,

blocking_pid,

waiting_query,

blocking_query

FROM sys.innodb_lock_waits
WHERE waiting_query IS NOT NULL;

需要注意的是，这段查询只能帮助发现一部分锁等待关系，具体字段和视图名称要根据数据库版本核对官方文档。线上排查时不要直接执行高开销诊断 SQL，更不能为了“看清楚”而开启全量审计，避免监控动作本身增加数据库负担。

我会重点关注四个时间：事务开始时间、库存行被锁定时间、订单写入完成时间、事务提交时间。如果锁定后还执行远程调用，事务持续时间通常会明显变长；如果事务很短但超卖仍然发生，则更应该怀疑事务边界断裂或扣减条件缺失。

6. 第六步：做最小化并发复现

线上事故不能只凭猜测修复。我会把库存表、订单表和核心代码抽成最小实验，只保留一个 SKU、一个库存字段和两个并发请求。先复现原始逻辑，再逐步替换为原子更新、悲观锁和乐观锁。

测试时要记录成功扣减数、成功订单数、库存最终值、失败请求数、锁等待时间和重复请求数。并发量不必一开始就上万，很多竞态在 20 到 100 个并发线程下就可以稳定复现。

-- 反例：查询与判断、扣减分离
SELECT available_stock

FROM sku_stock

WHERE sku_id = 10001;

-- 应用层判断后执行

UPDATE sku_stock

SET available_stock = available_stock - 1

WHERE sku_id = 10001;

-- 推荐的基础写法：把库存下限放到更新条件中
UPDATE sku_stock

SET available_stock = available_stock - 1

WHERE sku_id = 10001

AND available_stock >= 1;

复现结果如果显示“订单数大于成功扣减数”，说明订单创建动作没有绑定扣减结果；如果“成功扣减数等于订单数但仍超过初始库存”，说明扣减条件或回补流程有问题；如果“数据库扣减正确但支付成功超出履约数”，说明支付确认与库存预占之间存在跨系统时序漏洞。

五、案例数据观察：从 37 笔超卖反推故障链

1. 第一组证据：订单数量和库存流水对不上

事故后的第一张核对表显示，订单表中有效订单为 1,037 笔，但库存扣减流水只有 1,000 笔成功记录。乍看之下，似乎有 37 笔订单没有扣库存；进一步查询发现，这 37 笔订单都存在“库存检查通过”的应用日志，却没有对应的成功扣减流水。

这说明应用日志中的“库存检查通过”并不等于库存扣减成功。原代码先在服务层判断，然后尝试更新；更新失败后，由于返回值没有被检查，订单创建仍然继续执行。

这组数据带来的专业判断是：事故的第一根因不是“数据库把库存算错了”，而是订单服务把一个失败的库存扣减当成了成功前置条件。数据库最终保持 0，并不能掩盖订单服务已经绕过库存边界。

2. 第二组证据：热点行没有被正确保护

数据库活动会话显示，库存查询在峰值期间大量返回相同的可售库存值。由于查询和更新之间没有事务锁，多个请求可以在几毫秒内完成相同判断。即使每个请求只占用很短时间，整体仍然形成了明显的并发窗口。

从数据库角度看，这些查询没有违反隔离级别的规则。默认隔离级别允许事务读取一个当时已经提交的值；数据库并不知道应用稍后会根据这个值创建订单，也没有义务替应用保证“读取后一定还能扣到”。因此，不能把标准隔离级别误认为业务层的库存锁。

3. 第三组证据：重试机制让少量竞态变成重复扣减

事故样本中有 11 个请求在接口超时后自动重试。第一次请求实际上已经完成库存更新，但响应在网络层丢失；重试请求没有携带幂等键，又重新执行了扣减。虽然这部分重复扣减没有全部形成重复订单，但它造成了库存流水和订单流水之间的短暂不一致。

因此，库存系统要同时防两类问题：并发竞争导致的“多人抢同一件”，以及请求重试导致的“同一个人或同一个请求重复扣”。前者需要原子条件更新或串行化，后者需要业务幂等。只做其中一项，事故仍可能复发。

4. 修复后的对照结果

我们在隔离环境中使用相同的初始库存和请求分布，对比三种方案。下表数据是样本推演，不是行业统一基准，重点用于展示方案之间的结构差异。

六、正确修复：从 SQL 原子性到业务状态机

1. 单库场景：优先使用带库存下限的条件更新

对于库存表和订单预占表位于同一个数据库、业务量中等且需要快速修复的场景，我通常优先采用条件原子更新。它改动小、验证清晰，能够直接把“不能减到负数”交给数据库执行。

BEGIN;
UPDATE sku_stock

SET available_stock = available_stock – 1,

version = version + 1

WHERE sku_id = 10001

AND available_stock >= 1;

— 应用读取 affected_rows

— affected_rows = 0 时回滚并返回库存不足

INSERT INTO stock_reservation
(request_id, user_id, sku_id, quantity, status)
VALUES
('req-20260919-0001', 90001, 10001, 1, 'RESERVED');
COMMIT;

这段逻辑还不完整，实际生产中应先根据请求号查询是否已经存在成功预占记录，并给 stock_reservation.request_id 建立唯一约束。否则客户端重试时，第二次请求仍可能再次进入扣减。

2. 同库订单创建：让“扣减成功”成为订单创建的必要条件

订单创建不能依赖应用日志，也不能依赖查询结果。它必须依赖库存更新的返回结果。伪代码中的关键是：只有 affected_rows = 1 才能继续写订单；所有其他情况都要明确转换成库存不足、重复请求或系统异常。

function reserveStock(requestId, userId, skuId, quantity):
existing = reservationRepository.findByRequestId(requestId)

if existing is not null:

return existing.result

affectedRows = stockRepository.decreaseIfEnough(skuId, quantity)

if affectedRows == 0:

return SOLD_OUT

try:

reservationRepository.insert(

requestId, userId, skuId, quantity, "RESERVED"

)

return SUCCESS

catch DuplicateKeyException:

compensationRepository.createOnce(

requestId, skuId, quantity, "NEED_RECHECK"

)

return RETRY_OR_RECONCILE

这里的异常补偿看起来比“失败就加回库存”麻烦，但这是有必要的。因为唯一键冲突可能意味着并发请求中另一条线程已经完成了预占，也可能意味着第一次请求部分成功后重试。没有原始请求号和流水状态，直接回补可能把真正成功的库存加回来。

3. 分库场景：使用预占状态，不要假装跨库操作是一个事务

库存库和订单库分开后，最稳妥的思路是把库存状态设计成可推进的状态机：可售、预占中、已预占、已支付、已释放、补偿中、异常待对账。每次状态转换都写入不可变流水，业务表中的当前状态只是查询加速字段。

一种常见路径是：库存服务原子预占成功，写入预占流水；通过可靠消息通知订单服务；订单服务创建待支付订单；订单服务返回订单号；支付成功后通知库存服务将预占转为已售；超时未支付则发送释放事件。

这条链路允许短暂的最终一致，但必须定义每个中间状态的超时和补偿方式。例如库存已经预占但订单创建失败，库存服务不能永久等待，而应由定时扫描任务根据请求号查询订单状态，决定释放或进入人工对账。

4. 消息重复和消息丢失要分开处理

消息重复消费的解决方式是消费幂等，通常通过业务事件号唯一索引、消费记录表或状态条件更新实现。消息丢失则需要发送端可靠投递、消息表、重试队列和死信处理。两者不能用同一个“失败重试”按钮笼统处理。

UPDATE stock_reservation
SET status = 'SOLD',

sold_at = CURRENT_TIMESTAMP

WHERE reservation_id = #{reservationId}

AND status = 'RESERVED';

这条状态更新的受影响行数同样重要。返回 1 表示状态从预占变为已售；返回 0 可能是重复消费、已经释放或记录不存在。消费端不应在返回 0 时盲目再次扣减，而应查询流水确认当前状态。

5. 缓存方案：必须建立可恢复的事实来源

如果使用缓存做前置库存扣减，我会要求至少具备四项能力：预扣请求唯一号、库存变更事件、数据库落库确认、缓存与数据库定期对账。缓存适合做快速拦截和削峰，但库存事实不能只存在一个无法审计的数值里。

缓存预扣成功后，应把请求号和扣减数量写入可靠事件。数据库落库成功后标记事件完成；落库失败则进入重试或补偿队列。缓存重建时只能依据已确认的库存台账，不应直接读取某个可能包含未完成预占的中间字段。

七、不同情况下的行动建议

1. 如果活动还未开始：先做安全基线

活动前不要只做接口 QPS 压测，还要做热点集中压测。测试数据至少包含一个 SKU 承受绝大多数请求的情景，并模拟客户端超时重试、消息重复、订单取消、支付回调延迟和数据库主从切换。

• 确认库存扣减 SQL 带有库存下限条件。
• 确认受影响行数会决定订单是否创建。
• 确认请求号、订单号、用户编号可以贯穿全部日志。
• 确认重复请求不会重复扣减。
• 确认订单取消和支付超时有明确回补状态。
• 确认缓存重启和消息积压时不会恢复错误库存。
• 确认数据库连接池、锁等待和消息堆积都有告警。

压测验收不应只有“接口成功率 99.9%”。我更关注四个硬指标：成功订单数不得超过初始可售库存；库存变更流水必须可解释；重复请求不得新增有效预占；压测结束后账面库存与事件流水能够对上。

2. 如果已经出现超卖：按资金影响优先止损

出现少量异常订单时，先冻结履约，不要先把库存字段加回去。因为加回库存可能让系统继续销售，或者把已经支付的订单再次放入可售池。应先区分待支付、已支付、已取消和已发货订单，再决定退款、换货或人工调拨。

如果已经有支付成功订单，处理顺序应是：保留支付凭证、停止自动履约确认、计算可履约数量、按业务规则确定优先级、批量通知异常用户、完成退款或替代方案，最后再修复账务和库存台账。

3. 如果库存量很小：不要把性能和安全混为一谈

库存只有几十件甚至几件时，系统最重要的不是把每个请求都处理成功，而是快速、明确地拒绝无法成交的请求。可以在入口先发放有限令牌，再由数据库做最终扣减；令牌数量应小于或等于可售库存，并考虑预留失败和回补。

对于一件库存的商品，任何允许多个请求同时进入“购买确认”阶段的设计都需要特别谨慎。此时队列串行化虽然牺牲响应速度，却能显著降低并发竞态和补偿复杂度。

4. 如果并发极高：先削峰，再保护数据库

极端热点场景下，我不会直接把数据库改成更大的规格作为第一方案。数据库扩容可以提升吞吐，但不能消除热点行的互斥关系。更有效的路径通常是前置限流、资格校验、令牌预发、消息队列削峰，再用数据库或库存服务做最终确认。

不过，队列也不是免费的。队列长度、消费速度和支付窗口必须匹配。例如订单必须在 30 秒内创建，如果队列积压 2 分钟，即使库存没有超卖，用户体验和支付有效性也已经失败。因此，削峰方案需要同时设计超时丢弃、队列满载和用户结果查询机制。

八、方案取舍：没有一种库存架构适合所有业务

1. 带条件原子更新：适合快速修复和中等并发

这类方案的优点是边界清晰、改造成本低、数据库可以直接保证库存不低于零。它适用于商品库存和订单预占在同一数据库，业务流程较短，热点并发仍在数据库可承受范围内的场景。

它的短板是热点 SKU 仍然会集中竞争同一行。若入口没有限流，失败请求也会产生大量数据库访问。它还不能自动解决跨库订单、支付回调和取消回补，因此需要补充幂等和对账机制。

2. 悲观锁：适合强一致、流程短的单库事务

悲观锁的逻辑最容易被团队理解：先锁住库存行，再判断和扣减。对于后台调拨、低频采购或并发量有限的交易，它非常实用。

秒杀场景中，悲观锁的风险在于所有请求都等待同一行。锁等待会延长事务，事务延长又会占用连接，连接耗尽后请求开始重试，重试再次增加锁竞争，最后形成连锁放大。因此，采用悲观锁时必须设置合理的锁等待超时、连接池上限和失败快速返回策略。

3. 乐观锁：适合冲突可接受且可以重试的场景

乐观锁通过版本号检测并发修改，失败请求不持有长时间锁，适合热点程度中等、请求可以快速重试或转入队列的场景。它的关键指标不是“重试次数越多越好”，而是冲突率是否可控。

如果一个 SKU 的冲突率已经很高，乐观锁会把大量数据库更新变成失败重试。此时表面上没有锁等待，实际上数据库仍在处理大量无效写入。对于极热点 SKU，应优先考虑入口令牌或串行消费，而不是无限增加重试次数。

4. 缓存预扣加异步落库：适合极端流量和可接受最终一致的场景

缓存预扣的优势是响应快、削峰强，可以避免数十万请求直接冲击数据库。它适合库存活动规则简单、订单结果可以异步查询、团队具备消息和对账能力的业务。

它的代价是系统从一个一致性问题变成多个一致性问题：缓存与数据库、预扣与订单、订单与支付、支付与仓储之间都要有状态转换。没有完善的事件记录和补偿任务时，缓存方案可能比数据库方案更难排查。

5. 分片库存：适合极端热点，但需要防止分配偏差

把一个 SKU 的库存拆到多个库存桶或多个分片，可以降低单行竞争。请求先选择一个分片，再在分片内扣减，从而把热点分散开。但分片会带来新的问题：某些分片可能先被抢空，导致整体仍有库存却返回售罄；回补时也要知道原始分片。

分片策略应结合随机、轮询、用户哈希或库存桶权重。对于库存很少的商品，分片数量不能盲目增加，否则每个分片的库存过小，反而增加分配失败概率。

九、监控和对账：把超卖从事故变成可提前发现的异常

1. 必须监控业务不变量

技术指标只能告诉你数据库忙不忙，业务不变量才能告诉你库存是否安全。至少应监控以下关系：成功订单数不超过有效预占数；有效预占数不超过初始库存；库存流水净变更能够解释库存字段变化；支付成功数量不超过已确认可售数量。

这些指标不能只在活动结束后计算。秒杀期间可以每秒或每几秒做增量核对，对异常差额设置分级告警。例如差额达到 1 件先记录，达到 5 件暂停自动履约，达到支付成功订单的 0.1% 则触发活动熔断。

2. 监控锁等待和业务失败要结合看

如果数据库锁等待上升、库存不足返回率上升，但成功订单数没有超过库存，说明系统可能是安全但体验变差。此时应优化限流和队列，而不是放宽库存条件。

如果锁等待不高、订单创建成功率很高，但库存守恒出现差额，说明问题更可能是事务边界、失败结果处理或重复请求。把这两类情况混在一起，会让团队错误地通过增加数据库资源来修复逻辑漏洞。

3. 对账任务要能给出“差额原因”

低质量对账只输出“库存不一致”。高质量对账要进一步拆分：哪一笔订单没有预占、哪一笔预占没有订单、哪一笔支付没有已售流水、哪一笔取消没有释放、哪一笔消息重复消费。

对账结果最好形成可处理的异常队列，每条异常都有原始请求号、订单号、库存流水号、当前状态、最后更新时间和建议动作。人工只能处理少量高风险异常，不能依赖人工逐行比对几万条记录。

十、事故后的整改清单和验证方法

1. 数据库层整改

• 为库存扣减增加库存下限条件，禁止无条件减库存。
• 确认库存字段使用足够范围的整数类型，并统一数量单位。
• 为库存变更建立不可变流水，记录请求号、订单号、前后值和变更原因。
• 为请求号、订单号和业务事件号建立适当的唯一约束。
• 限制库存事务长度，禁止在持有库存锁期间调用外部服务。
• 配置锁等待、死锁和连接池耗尽告警。

2. 应用层整改

• 库存更新必须检查受影响行数。
• 订单创建必须依赖库存扣减成功结果。
• 所有重试都必须携带幂等键。
• 明确区分库存不足、重复请求、系统异常和待对账状态。
• 日志中统一打印请求号、用户编号、SKU、订单号和事务结果。
• 不要用“库存检查通过”作为“库存扣减成功”的替代字段。

3. 消息和补偿层整改

• 发送消息时记录业务事件，不以接口返回成功代替消息持久化成功。
• 消费时使用状态条件更新或唯一消费记录保证幂等。
• 设置重试上限和死信队列，禁止无限重试库存事件。
• 为预占超时、订单创建失败、支付回调延迟和取消回补设计补偿任务。
• 补偿任务必须可重入，重复执行不能重复加库存。

4. 压测验收标准

修复后不要只复测正常成功路径。至少需要验证以下反例：

1. 库存为 1 时，100 个并发请求只能有 1 个成功预占。
2. 同一个请求重复提交 10 次，只产生 1 条有效预占。
3. 库存扣减成功但订单写入失败时，最终能够自动补偿或进入待对账。
4. 订单创建成功但支付回调重复到达时，不会重复转为已售。
5. 取消订单重复处理时，不会重复回补。
6. 消息重复消费、消息延迟和消息乱序时，状态仍能收敛。
7. 数据库主从延迟时，库存判断不会错误读取只读副本的旧值。
8. 应用超时但数据库已经提交时，重试不会再次扣减。

这里特别强调主从延迟。库存扣减前的判断如果读取只读副本，可能读到旧库存；即便最终更新走主库，应用也可能基于旧值做错误决策。库存写入前的关键判断，应避免依赖存在延迟的副本。

十一、结尾：真正要修复的是“库存事实的定义”

1. 我的最终判断

高并发秒杀中的库存超卖，表面上是一个数字错误，实质上是系统没有定义清楚哪一次状态变化才算“卖出”。有人把点击算成交，有人把订单算成交，有人把支付算成交，仓库又把出库算成交。只要这些定义没有通过状态机和流水连接起来，数据库再稳定也无法保证业务结果正确。

我在复盘库存事故时，不会先问“要不要加缓存”，而会先问四个问题：库存边界由谁最终守住；扣减成功由什么证据证明；重复请求如何返回同一个结果；异常状态由谁在什么时候收敛。能回答这四个问题，技术方案通常不会偏离太远。

2. 下一步应该怎么做

如果你正在准备一次秒杀活动，先用一个真实热点 SKU 做最小并发实验，验证带条件更新、受影响行数判断和请求幂等。不要一开始就搭建复杂的分布式库存平台，先把单库边界做正确。

如果系统已经采用缓存、队列或分库，下一步应绘制库存状态图，列出每个状态的进入条件、退出条件、超时时间和补偿动作。然后为每个状态配置可查询的流水和告警，而不是只保留一个当前库存数字。

最值得记住的一句话是：数据库不会替业务猜测“这件商品是否已经卖出”，它只会执行你写下的状态变化。库存安全的第一道防线是原子扣减，最后一道防线是可审计、可重放、可对账的库存流水。

SELECT stock FROM product WHERE sku_id = ?;应用层读取到 stock 大于 0 后，再执行以下更新。多个请求可能基于同一个旧库存判断继续往下走，尤其是在应用重试或订单创建与扣减不在同一事务时，风险会被进一步放大。
UPDATE product SET stock = stock - 1 WHERE sku_id = ?;更可靠的基础写法是把库存条件放进更新语句，并严格检查更新行数： UPDATE product SET stock = stock - 1 WHERE sku_id = ?

免费注册

咨询方案

扫码咨询方案