库存只剩 1 件时，两个请求同时完成“查询库存”和“创建订单”，并不意味着数据库会自动替你做出正确判断。真正容易出问题的地方，往往不是 stock - 1 这条减法，而是库存判断、订单幂等、支付超时、消息重试和库存回补之间没有形成一个完整闭环。本文从后端工程实践出发，拆解数据库库存扣减怎样逐步实现，降低超卖、重复扣减和库存账实不符的风险。

数据库存：后端工程师最佳实践：库存扣减怎样稳步实现降低超卖风险

一、先讲核心结论：库存扣减的第一步不是加分布式锁

1. 单库库存扣减，优先从一条正确的 SQL 开始

对于普通电商下单、团购、预约和门店库存等场景，我不会一开始就推荐分布式锁、缓存预扣或复杂的消息编排。只要库存最终落在同一个关系型数据库中，最先应该解决的是：把“库存是否充足”和“库存减一”合并为数据库能够原子执行的条件更新。

UPDATE sku_stock
SET available_stock = available_stock - 1,

sold_stock = sold_stock + 1,

updated_at = CURRENT_TIMESTAMP

WHERE sku_id = ?

AND available_stock >= 1;

执行后必须检查受影响行数。受影响行数为 1，才代表本次扣减真正成功；受影响行数为 0，可能表示库存不足、SKU 不存在，或者更新条件没有满足。仅仅判断 SQL 没有报错，不能说明库存已经扣减成功。

这条 SQL 能解决的是“库存不能在并发下被扣成负数”。它不能自动解决同一个订单重复提交、支付失败后库存释放、消费者重复消费以及数据库写入成功但响应超时等问题。因此，条件更新只是库存系统的底座，不是完整方案。

2. 并发控制和幂等控制，解决的是两类不同问题

库存系统经常把并发和重复混在一起处理，最后误以为“加锁之后就安全了”。实际上，并发控制解决的是多个请求在同一时间修改同一份库存；幂等控制解决的是同一个业务动作因为重试、重复点击或消息重复投递而执行多次。

我的判断标准是：先确认本次操作是否唯一，再确认它能否在并发下正确执行，最后才讨论吞吐量是否需要缓存和异步化。顺序反过来，系统往往会先获得高吞吐，随后获得一堆难以对账的库存差异。

3. 架构应该按流量逐级升级，而不是按技术名词堆叠

低并发普通下单场景，通常可以从“条件更新加事务加幂等”开始；当一个热点 SKU 的请求量明显超过数据库单行更新的承载能力，再考虑 Redis 入口预扣、消息队列削峰和异步落库。更大规模的系统，还要面对分片库存、分仓分配、库存中心和跨区域一致性。

我不建议把“Redis 预扣库存”当成数据库方案的自然升级。它实际上改变了库存的权威来源和异常处理方式，系统需要增加预扣失败补偿、订单超时释放、消息重试去重和定期对账。性能提升不是免费获得的，通常是用系统复杂度和运维成本换来的。

二、背景和真实场景：为什么“先查再扣”会导致超卖

1. 一个库存为 1 的并发反例

假设商品表中有一条库存记录，SKU 为 1001，可售库存为 1。接口收到请求后，先执行查询，再由应用程序判断库存是否大于 0，最后执行普通更新。这是许多初版系统最容易采用的流程。

SELECT available_stock
FROM sku_stock

WHERE sku_id = 1001;

UPDATE sku_stock
SET available_stock = available_stock - 1

WHERE sku_id = 1001;

请求 A 和请求 B 可能在几乎相同的时间读取到库存 1。A 判断库存充足，B 也判断库存充足。即使数据库对两次更新加了行锁，两次更新仍然可能依次执行，最终库存变成负数，或者在缺少条件保护时，两份订单都被认为是成功订单。

这里的关键不是数据库有没有锁，而是库存充足这个判断没有和扣减动作绑定在同一条原子更新中。应用层看到的库存只是某一个时间点的快照，不能把这个快照当成后续扣减的永久许可。

2. 查询库存仍然有用，但不能作为最终扣减依据

页面展示库存、购物车提示、商品详情页的“仅剩少量”提醒，都可以读取缓存或数据库中的库存值。这类查询的目标是改善用户体验，允许存在短暂延迟。

真正影响交易结果的库存判断必须发生在写操作中。即使前端已经显示“有货”，提交订单时仍然要重新执行带条件的扣减。展示库存可以是近似值，交易库存必须是受数据库约束保护的结果。

3. 库存模型不同，扣减时点也不同

“下单就扣库存”和“支付成功才扣库存”没有绝对的优劣，关键在于业务承诺。秒杀商品通常需要下单时锁定库存，否则用户支付成功后可能发现商品已售罄；普通现货商品则可能采用下单锁定、支付超时释放的模式。

三、常见误区：看似加固，实际仍然留下漏洞

1. 误区一：加了事务，就不会超卖

事务可以保证一组数据库操作要么全部提交，要么全部回滚，但它不会自动把两个并发事务变成一个事务。两个事务都可以独立读取到库存充足，然后按照各自的执行路径修改数据。

如果事务中使用的是“先查询，再普通更新”，事务只是把两步操作放进了同一个事务边界，却没有消除应用判断与数据库写操作之间的竞争窗口。要解决这个问题，仍然需要条件更新、行锁或者版本校验。

BEGIN;
SELECT available_stock

FROM sku_stock

WHERE sku_id = ?

FOR UPDATE;

-- 在事务内判断库存

UPDATE sku_stock

SET available_stock = available_stock - 1

WHERE sku_id = ?;

INSERT INTO order_stock_flow(order_id, sku_id, action, quantity)

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

COMMIT;

上面的悲观锁方案可以成立，但前提是查询、判断、更新和流水写入都在同一事务中，且事务期间不调用支付、物流或其他外部服务。否则锁持有时间会被外部网络延迟放大。

2. 误区二：加分布式锁就能保证库存一致

分布式锁解决的是多个服务实例之间的临界区互斥，不等于库存、订单和消息已经形成一致状态。锁可能在业务执行中途过期，客户端可能拿到锁后发生网络隔离，释放锁的操作也可能因为异常而失败。

更重要的是，如果库存最终写入数据库，数据库本身仍然需要条件约束。把所有正确性都寄托在外部锁上，会让数据库失去最后一道防线。对于单个 SKU 的简单减库存操作，带条件更新通常比“先获取分布式锁，再查询库存，再更新数据库”更直接。

3. 误区三：Redis 中减库存，数据库只负责同步

Redis 的原子递减可以快速处理热点请求，但它把系统从单一数据源变成了两个库存状态源。Redis 扣减成功后，如果订单创建失败，库存就需要回补；如果服务在 Redis 扣减后宕机，系统还要知道这次预扣是否已经进入订单流程。

我在评估这类方案时，会要求团队先回答三个问题：哪一个组件是库存最终权威来源？预扣成功但订单失败如何释放？Redis 和数据库出现差异时谁来发现、谁来修复？如果三个问题没有明确答案，提前引入缓存只会把一个可复现的数据库问题变成难以定位的分布式问题。

4. 误区四：用库存不小于零证明系统没有业务错误

库存不为负，只能证明某个库存字段没有低于零。它不能证明同一个订单没有扣两次，也不能证明取消订单后库存一定回补，更不能证明仓库实际可发货数量与系统库存一致。

例如，同一个订单因为接口超时被客户端重试两次，两个请求分别扣减了库存 1 件和 1 件，但数据库中的库存仍然是非负的。此时系统没有发生“负库存超卖”，却发生了库存少了 1 件、订单多扣 1 件的业务错误。

5. 误区五：无限重试乐观锁冲突

乐观锁失败后重试，在低冲突场景下很有效；但热点 SKU 上，大量请求可能不断读取旧版本、更新失败、再次读取和重试，最终形成数据库压力放大。重试次数越多，不代表成功率一定越高。

比较稳妥的做法是设置有限重试次数，并在连续冲突后快速失败或转入排队流程。对用户而言，“库存竞争激烈，请稍后重试”通常比接口长时间等待更可控；对系统而言，快速失败可以保护数据库连接池。

四、专业判断逻辑：先定义一致性边界，再选择技术方案

1. 第一步：明确“库存”到底包含哪些状态

只用一个 stock 字段，往往无法表达订单生命周期。更清晰的模型至少应该区分可售库存、锁定库存和已售库存。

available_stock 可售库存
reserved_stock 锁定库存

sold_stock 已售库存

常见状态变化可以表示为：下单时 available_stock - 1、reserved_stock + 1；支付成功时 reserved_stock - 1、sold_stock + 1；订单取消或支付超时时 reserved_stock - 1、available_stock + 1。

如果业务采用下单即确认销售，也可以不维护锁定库存，但仍建议保留库存流水。库存字段描述“现在有多少”，流水描述“为什么变成这样”，两者职责不同。

2. 第二步：定义一次扣减的业务唯一键

库存扣减必须能够回答“这次操作是否已经执行过”。常见唯一键包括订单号、订单号加 SKU、请求流水号和业务事件编号。

我通常会把业务唯一键写进库存流水表，并用唯一索引做数据库级保护。应用层幂等判断用于减少重复处理，唯一索引用于防止并发下两个请求同时通过应用判断。

CREATE TABLE inventory_flow (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
flow_no VARCHAR(64) NOT NULL,
order_id VARCHAR(64) NOT NULL,
sku_id BIGINT NOT NULL,
action VARCHAR(16) NOT NULL,
quantity INT NOT NULL,
created_at DATETIME NOT NULL,
UNIQUE KEY uk_flow_no (flow_no),
UNIQUE KEY uk_order_sku_action (order_id, sku_id, action)
);

唯一约束要结合业务动作设计。扣减和释放不是同一个动作，因此不能简单地把订单号和 SKU 作为所有流水的唯一键，否则一次扣减后就无法记录合法的释放动作。

3. 第三步：选择最小一致性单元

如果订单表、库存表和库存流水表在同一个数据库中，通常可以把它们放在同一个本地事务里。事务中只做数据库操作，不调用外部接口，提交后再通过可靠事件通知其他服务。

如果订单和库存位于不同服务，就不能再假设一个本地事务可以覆盖两边。此时要明确采用哪种模式：库存先锁定、订单异步创建；订单先创建、库存异步确认；或者通过可靠消息、状态机和补偿机制最终收敛。

4. 第四步：评估热点程度，而不是只看总请求量

库存系统的瓶颈经常由“单个热门 SKU 的并发集中度”决定，而不是由全天总请求量决定。一天有几百万请求，如果均匀分散到几十万 SKU，数据库可能运行正常；一个爆款 SKU 在几秒内接收数十万请求，即使总订单量并不高，也可能把单行记录变成热点。

因此，我会重点观察四个数据：单 SKU 每秒请求数、条件更新冲突率、数据库行锁等待时间和库存接口 P99 延迟。只有这些指标共同显示单库方案接近边界，才有必要引入缓存预扣或排队。

五、具体实现：从数据库条件更新到事务闭环

1. 最小可行方案：条件扣减加受影响行数判断

在单库场景中，最小实现可以只有库存表、订单表和库存流水表。接口接收到请求后，先校验 SKU、购买数量和用户权限，再执行带条件的库存更新。更新成功后创建订单和扣减流水；任何一步失败，都要回滚库存更新。

BEGIN;
UPDATE sku_stock

SET available_stock = available_stock – ?,

reserved_stock = reserved_stock + ?,

updated_at = CURRENT_TIMESTAMP

WHERE sku_id = ?

AND available_stock >= ?;

— 检查 affected_rows

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

INSERT INTO inventory_flow
(flow_no, order_id, sku_id, action, quantity, created_at)
VALUES
(?, ?, ?, 'RESERVE', ?, CURRENT_TIMESTAMP);
INSERT INTO orders
(order_id, user_id, status, created_at)
VALUES
(?, ?, 'PENDING_PAYMENT', CURRENT_TIMESTAMP);
COMMIT;

这里有一个经常被忽略的细节：扣减数量是变量时，条件必须写成 available_stock >= quantity，不能只写 available_stock > 0。否则一次购买 5 件的请求，可能在库存只有 2 件时仍然通过条件判断。

2. 批量购买时，必须锁定数量关系

假设用户一次购买 3 件，库存为 4，条件更新执行后库存应为 1。如果请求重试，不能再次扣减 3 件。因此，批量扣减和幂等记录必须在同一个业务边界内处理。

UPDATE sku_stock
SET available_stock = available_stock - :quantity,

reserved_stock = reserved_stock + :quantity

WHERE sku_id = :sku_id

AND available_stock >= :quantity;

如果一笔订单包含多个 SKU，事务还要考虑更新顺序。建议按照 SKU 编号或库存记录主键排序后依次更新，尽量让不同事务采用相同的锁顺序，从而减少死锁概率。

3. 什么时候使用悲观锁

如果扣减前需要读取多个字段进行复杂判断，例如检查批次有效期、门店可售范围、预留上限和用户购买限制，那么单条条件更新可能无法表达全部规则。这时可以在事务中使用 SELECT ... FOR UPDATE 锁定库存行。

BEGIN;
SELECT available_stock,

reserved_stock,

max_buy_per_user

FROM sku_stock

WHERE sku_id = ?

FOR UPDATE;

-- 在事务内完成库存、用户限购和批次规则判断

UPDATE sku_stock

SET available_stock = available_stock - ?,

reserved_stock = reserved_stock + ?

WHERE sku_id = ?;

COMMIT;

使用行锁时，要把事务设计得足够短。不要在锁住库存后调用支付接口、发送同步 HTTP 请求或等待人工风控结果。正确做法是先在事务内写入处理中状态，提交后再异步执行外部动作。

4. 什么时候使用乐观锁

乐观锁适合冲突相对可控，并且业务允许快速失败或有限重试的场景。版本号可以帮助系统判断库存记录是否被其他请求修改，但版本号本身不能识别“同一个订单是否已经扣过库存”。

UPDATE sku_stock
SET available_stock = available_stock - :quantity,

version = version + 1,

updated_at = CURRENT_TIMESTAMP

WHERE sku_id = :sku_id

AND version = :version

AND available_stock >= :quantity;

如果更新失败，服务可以重新读取版本并重试一次或两次。但对于热点 SKU，我更倾向于设置快速失败、请求排队或入口限流，而不是让大量请求持续重试数据库。

六、幂等、流水和状态机：真正决定库存能否长期稳定

1. 幂等键应该来自业务，而不是随机生成

如果每次重试都生成新的随机请求编号，服务端无法判断两次请求是否代表同一个业务动作。幂等键应在业务上稳定，例如订单号、客户端生成的业务流水号，或者“用户号加购物车提交号”。

接口可以要求客户端携带请求号，也可以由服务端在首次创建订单时生成订单号。关键是后续重试必须沿用同一个标识，并且服务端需要保存处理结果，而不是只保存“处理过”这个布尔值。

2. 库存流水不是日志，而是可对账事实

普通应用日志适合排查请求路径，但不适合作为库存账务依据。库存流水至少要记录业务流水号、订单号、SKU、动作类型、数量、操作前库存、操作后库存、来源事件和创建时间。

CREATE TABLE inventory_flow (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
flow_no VARCHAR(64) NOT NULL,
order_id VARCHAR(64) NOT NULL,
sku_id BIGINT NOT NULL,
action VARCHAR(16) NOT NULL,
quantity INT NOT NULL,
before_available INT NOT NULL,
after_available INT NOT NULL,
source_event VARCHAR(64) NOT NULL,
created_at DATETIME NOT NULL,
UNIQUE KEY uk_flow_no (flow_no),
KEY idx_order_id (order_id),
KEY idx_sku_created (sku_id, created_at)
);

操作前后库存字段有助于定位差异发生在哪一步，但不能替代数据库真实状态。对账时，应该结合库存初始值、扣减流水、释放流水、退款回补和人工调整记录进行核算。

3. 用状态机处理订单生命周期

库存系统最怕“任何状态都能随意改”。例如一个已经支付的订单又被超时任务释放库存，或者一个已经释放库存的订单因为重复消息再次释放。状态机要限制合法迁移，库存动作也要与状态迁移绑定。

4. 回补动作同样需要幂等

许多团队在扣库存时设计了唯一流水，却在释放库存时直接执行 stock = stock + quantity。如果取消消息重复消费，库存就会被多次加回，最终出现虚高库存。

BEGIN;
INSERT INTO inventory_flow

(flow_no, order_id, sku_id, action, quantity, created_at)

VALUES

(?, ?, ?, 'RELEASE', ?, CURRENT_TIMESTAMP);

— 如果 flow_no 已存在，说明释放动作已经执行过

— 只有首次插入成功，才执行库存回补

UPDATE sku_stock
SET available_stock = available_stock + ?,
reserved_stock = reserved_stock - ?
WHERE sku_id = ?
AND reserved_stock >= ?;
COMMIT;

实际项目中还需要根据数据库方言处理“插入唯一流水后再更新库存”的事务逻辑。核心原则不变：释放库存不是简单的加法，而是一个具有唯一业务身份的状态变化。

七、Redis 预扣和消息队列：什么时候值得引入复杂架构

1. Redis 预扣解决的是入口压力

当大量请求集中购买同一个热点 SKU 时，数据库单行记录可能成为竞争热点。Redis 预扣可以在请求入口快速淘汰库存不足请求，并将成功请求送入后续订单流程，从而减少数据库直接承受的无效请求数量。

典型流程如下：

1. 请求先完成身份校验、商品校验和限购校验。
2. 通过原子脚本在缓存中扣减可预扣数量。
3. 预扣成功后生成订单意向或投递库存处理消息。
4. 消费者在数据库中创建订单、写入流水并完成最终状态确认。
5. 订单创建失败、消息投递失败或超时未支付时执行补偿。

缓存扣减必须使用原子操作。多个命令先读后写可能产生与数据库“先查再扣”相同的竞态问题。对于涉及预扣、记录请求号和设置过期时间的操作，通常需要使用脚本或其他原子执行机制。

2. Redis 预扣后的四类异常必须先设计

第一类是预扣成功但订单创建失败。这时需要记录预扣流水，并通过同步补偿或可靠消息将数量加回。不能只依赖接口返回失败，因为服务可能在返回前已经宕机。

第二类是数据库写入超时。数据库超时不等于写入一定失败。消费者重试前，要通过业务流水号查询是否已经成功，避免把“未知结果”当成失败再次执行。

第三类是消息重复消费。消息队列通常需要消费者具备幂等能力。消费成功后才确认消息，可能导致重复投递；先确认再写数据库，又可能导致消息丢失。因此，消费者必须依赖业务唯一键和状态机，而不是依赖消息只到达一次。

第四类是订单超时释放。释放任务需要扫描待支付订单，并使用条件更新限制状态转换，例如只有从“待支付”成功转换为“已取消”的订单，才允许执行库存释放。

UPDATE orders
SET status = 'CANCELLED',

cancelled_at = CURRENT_TIMESTAMP

WHERE order_id = ?

AND status = 'PENDING_PAYMENT'

AND expire_at <= CURRENT_TIMESTAMP;

只有当订单状态更新的受影响行数为 1 时，才执行释放库存。受影响行数为 0，说明订单可能已经支付、取消或被其他任务处理，不能继续回补。

3. Redis 和数据库之间必须有对账机制

缓存预扣系统不能只看实时接口成功率，还要定期比较缓存预扣记录、数据库库存流水和订单状态。对账任务不应直接粗暴地“以某一边覆盖另一边”，而应先生成差异清单，再根据订单状态和流水状态执行可审计的修复。

八、一个可落地的业务案例：从普通下单到热点商品抢购

1. 普通 SKU：单库事务已经足够

假设一家零售业务每天订单量约 8 万笔，SKU 数量约 20 万，绝大多数商品没有明显热点。高峰期订单接口每秒约 500 次，但单个 SKU 每秒请求通常不超过 20 次。

这个场景不需要为了“可能的秒杀”提前搭建复杂的库存中心。更稳妥的实现是库存表按 SKU 建立主键，订单和库存流水同库，使用条件更新、唯一流水号、本地事务和定时对账。数据库连接池、慢查询和锁等待做好监控后，系统维护成本较低。

建议流程如下：

1. 客户端提交订单号或请求幂等号。
2. 服务端检查该幂等号是否已经处理。
3. 在事务内执行带数量条件的库存扣减。
4. 写入订单和库存流水。
5. 提交事务后返回订单结果。
6. 支付超时后通过状态条件更新触发库存释放。

在这个案例中，Redis 可能仍然适合做页面缓存和限流，但不一定适合做库存权威来源。架构越简单，故障排查路径越短，库存差异也越容易通过数据库流水定位。

2. 热点 SKU：先限流，再考虑预扣

假设一款限量商品库存 500 件，活动开始后 5 秒内收到 10 万次请求。此时真正需要处理的不是“如何让 10 万次请求都进入数据库”，而是如何快速识别大多数注定失败的请求，并保护后端订单和库存链路。

可以采用分层方案：入口限流、用户和设备去重、缓存预扣、消息削峰、数据库最终落库。缓存中的预扣数量不能直接当成已售数量，只有数据库流水和订单状态完成后，才算完成最终确认。

对于这种场景，我会重点要求以下数据可追踪：

• 每一次预扣的请求号和用户号；
• 预扣成功后对应的消息编号；
• 消息是否被消费、消费次数和最后错误；
• 数据库流水的扣减状态；
• 订单是否支付、取消或超时；
• 释放动作是否已经完成。

3. 多仓库 SKU：不能只维护一个全局库存数

如果商品实际存放在多个仓库，库存扣减还要先决定由哪个仓库履约。一个全局库存数可能显示还有 10 件，但这 10 件分散在不同区域，用户所在地区未必能够使用。

此时库存扣减的业务顺序通常是：确定履约仓、锁定仓库库存、创建订单、等待支付、确认销售或释放锁定。仓库选择规则、仓间调拨和取消回补都需要单独建模，不能简单地把多仓库存相加后执行一条全局更新。

九、上线前的压测、监控和对账怎么做

1. 不要只压“成功下单”这一条链路

库存系统压测必须包含成功、库存不足、重复请求、超时和异常重试。只测成功路径，容易得到一个漂亮的吞吐量，却无法发现库存不足时的数据库压力、重复消费时的幂等漏洞以及支付超时后的回补问题。

最小测试矩阵可以包含以下场景：

• 库存为 1，并发请求数为 10、100 和 1000；
• 库存为 100，请求购买数量分别为 1、10 和 101；
• 同一个订单号重复提交 2 次、5 次和 20 次；
• 数据库更新成功但接口响应超时；
• 消息消费成功但确认响应丢失；
• 订单取消任务与支付回调同时到达；
• Redis 预扣成功后，订单服务立即重启；
• 库存流水写入成功但后续状态更新失败。

2. 重点观察四类指标

正确性指标包括负库存数量、重复扣减数量、重复释放数量、订单与流水不一致数量。任何一个指标出现非零，都应该触发告警或进入异常队列。

并发指标包括行锁等待时间、死锁次数、乐观锁冲突率和数据库连接池等待时间。这些指标能够判断系统是被数据库 CPU 限制，还是被热点行竞争限制。

链路指标包括消息生产失败率、消费重试次数、消息积压量、预扣转订单成功率和补偿任务失败数。它们用于判断问题发生在缓存、消息、订单还是数据库环节。

业务指标包括库存扣减成功率、支付转化率、超时订单比例、库存释放及时率和库存对账差异。技术指标正常，并不代表交易链路正常。

3. 对账公式要简单而明确

库存对账的核心不是生成复杂报表，而是建立可以反复验证的关系。以锁定库存模型为例，可以使用以下约束：

available_stock + reserved_stock + sold_stock
= initial_stock + inbound_quantity – adjustment_quantity;

进一步核查时，还要将扣减、释放、退款和人工调整分别统计。对于每个 SKU，系统应该能够根据流水重建库存变化，并定位某一笔差异具体发生在订单、消息还是补偿环节。

4. 监控告警应该能推动行动

“库存异常”是一个没有行动价值的告警。更好的告警应该包含 SKU、订单号、流水号、当前状态、最近一次事件、重试次数和建议处理动作。

十、不同业务情况下的行动建议和方案取舍

1. 普通电商下单：优先采用简单可靠的单库方案

如果订单量中等、热点不明显、订单和库存可以放在同一个数据库，建议采用条件更新、事务、唯一索引、库存流水和超时释放。先把异常流程做完整，再根据压测结果决定是否拆分服务。

这个方案的优点是数据路径短、排查容易、运维成本低。缺点是热点 SKU 会竞争数据库行，单库吞吐受限。只要业务流量尚未达到边界，不要为了架构“看起来先进”而主动增加缓存和消息依赖。

2. 高并发秒杀：入口治理比数据库优化更优先

秒杀场景中，大部分请求最终都会失败。如果让所有请求都经过订单服务、库存服务和数据库，任何一个环节都可能被无效流量拖垮。此时应先在入口做限流、验证码、用户去重和资格校验，再使用缓存原子预扣过滤库存不足请求。

秒杀方案的关键取舍是：接受订单结果异步确认，换取数据库压力下降。用户界面需要展示“排队中”“抢购成功”或“库存不足”，而不能把消息已投递直接包装成最终订单成功。

3. 需要复杂规则的库存：行锁比盲目乐观重试更稳

如果扣减前要判断批次、效期、门店、用户限购和组合库存，建议在同一事务内锁定必要记录，并严格控制事务时长。复杂规则下，盲目使用单条 SQL 往往难以表达完整约束，乐观锁大量重试也可能造成更高成本。

这种方案要重点治理死锁、锁等待和事务超时。多个 SKU 的更新顺序必须统一，事务中不能调用外部服务，失败后要有明确的重试和用户反馈策略。

4. 多服务库存：接受最终一致，但必须可追踪、可补偿

当库存、订单、支付和仓储分属不同服务时，很难依赖一个本地事务保证所有状态同时完成。此时可以采用事件驱动流程，但必须把处理中、成功、失败和待补偿状态持久化。

最终一致并不意味着“先写一边，另一边以后再说”。它意味着系统明确知道哪些状态尚未完成、由谁负责重试、重试多久、失败后如何人工介入，以及最终如何通过流水和对账确认收敛。

5. 库存价值高或合规要求高：宁可牺牲部分吞吐

药品、贵重物品、票务名额和强监管业务更关注可审计性，而不是单纯的峰值 QPS。这类系统应该保留完整库存流水、操作人、来源事件和状态变化记录，必要时采用更严格的串行化控制。

在这类场景中，快速失败、人工复核和库存冻结并不是系统能力不足，而是风险控制的一部分。宁可让少量用户稍后重试，也不要让错误库存进入履约环节。

十一、后端工程师可以直接使用的落地清单

1. 数据库设计检查

• 库存记录是否以 SKU 或仓库加 SKU 建立唯一约束。
• 扣减 SQL 是否包含库存数量条件。
• 购买数量是否经过正数、上限和整数校验。
• 更新语句是否能命中索引。
• 库存流水是否记录扣减、释放、退款和人工调整。
• 库存流水是否存在业务唯一键和数据库唯一索引。
• 可售、锁定和已售库存的定义是否写入设计文档。

2. 接口和幂等检查

• 是否要求调用方传递稳定的业务请求号。
• 重复请求是否返回原有业务结果。
• 数据库写入超时后，重试前是否能够查询最终状态。
• 网关和客户端是否存在无上限自动重试。
• 订单号、库存流水号和消息编号是否能够相互关联。

3. 事务和锁检查

• 事务中是否包含了订单、库存和流水的必要操作。
• 持有数据库锁期间是否调用外部服务。
• 多个 SKU 更新时是否采用统一锁顺序。
• 是否设置锁等待超时和死锁重试策略。
• 乐观锁是否设置最大重试次数。
• 失败后是快速失败、排队还是进入补偿队列，是否有明确规则。

4. 异步和补偿检查

• 消息生产失败时，是否能够重试或通过事务事件表补发。
• 消费者是否按照业务流水号实现幂等。
• 订单取消和支付超时是否会触发库存释放。
• 释放库存是否受订单状态转换结果约束。
• 补偿任务是否支持断点、重试和人工暂停。
• 缓存库存和数据库库存是否有定期对账。

5. 监控和压测检查

• 是否监控单 SKU 请求量，而不是只看全站平均 QPS。
• 是否监控库存更新成功率和失败率。
• 是否监控锁等待、死锁和连接池耗尽。
• 是否监控消息积压、重复消费和补偿失败。
• 是否能快速查询某个订单的完整库存链路。
• 压测后是否验证库存、订单和流水的最终数量关系。

十二、最终判断：稳步降低超卖风险，靠的是可验证的闭环

1. 先做正确，再做更快

库存扣减的最小正确路径是：带条件的原子更新、受影响行数判断、业务幂等、库存流水和明确的事务边界。这个路径不一定能承接所有秒杀流量，但它能够让系统在普通场景下拥有可解释、可测试、可对账的基础。

如果基础路径还没有处理重复请求和库存释放，就直接增加 Redis、消息队列和分布式锁，系统只会拥有更多状态和更多异常分支。技术组件数量增加，不等于一致性能力增加。

2. 把“库存成功”与“订单成功”分开表达

库存扣减成功，只代表系统为某个业务动作占用了数量；订单创建成功，代表订单数据已经落库；支付成功，代表交易状态完成。三者可能在同一事务中，也可能分属不同服务，但工程设计必须明确它们之间的关系。

只有把这些状态拆开，才能正确设计超时释放、支付回调、消息重试和库存对账。否则，任何一个“失败”都会变成需要人工猜测的灰色状态。

3. 下一步应该怎么做

如果你正在改造现有库存接口，可以按以下顺序推进：

1. 把“先查询再更新”改成带数量条件的原子更新。
2. 检查更新结果，禁止仅根据 SQL 执行无异常判断扣减成功。
3. 为订单、请求和库存流水建立稳定的幂等关系。
4. 给扣减和释放动作增加数据库唯一约束。
5. 梳理待支付、已支付、取消和退款状态，限制非法状态迁移。
6. 增加库存流水、超时释放和对账任务。
7. 对热点 SKU 做并发压测，观察锁等待、P99 延迟和冲突率。
8. 只有在数据库确实成为瓶颈时，再引入缓存预扣和消息削峰。

我对库存系统的核心判断是：真正稳的方案，不是承诺“绝对不会超卖”，而是让每一次扣减、释放、重试和异常都拥有唯一身份、明确状态和可追溯证据。当系统能够在库存不足、服务重启、消息重复、支付超时和数据库超时之后仍然完成对账与收敛，库存扣减才算真正从“能运行”进入“可长期运营”的阶段。

SELECT available_stock FROM sku_stock WHERE sku_id = 1001;

UPDATE sku_stock SET available_stock = available_stock - 1 WHERE sku_id = 1001;

UPDATE sku_stock SET available_stock = available_stock - 1, version = version + 1 WHERE sku_id = ?AND available_stock > 0;

SELECT available_stock, version FROM sku_stock WHERE sku_id = ?;
UPDATE sku_stock SET available_stock = available_stock - ?, version = version + 1 WHERE sku_id = ?AND version = ?AND available_stock >= ?;但乐观锁并不是免费方案。

SELECT available_stock FROM sku_stock WHERE sku_id = ?FOR UPDATE;-- 在事务内完成判断、扣减和流水写入 COMMIT;它的主要风险是锁等待和死锁。

UPDATE sku_stock SET available_stock = available_stock + ?WHERE sku_id = ?;COMMIT;

免费注册

咨询方案

扫码咨询方案