核心结论：库存扣减的终极方案不是“锁”，而是“幂等+锁”的组合

先直接说结论：在分布式高并发环境下，单纯依赖数据库乐观锁或Redis分布式锁，都无法解决库存扣减的所有问题。真正能扛住流量洪峰、保证数据最终一致性的方案，是“幂等设计”与“并发控制”的组合。 我经历了三个版本的库存系统重构，从最初的数据库乐观锁，到Redis原子操作，再到最终的“幂等凭证+缓存扣减+异步落库”架构，才真正理解了这个道理。

幂等设计的核心，不是防止并发，而是防止重复。它解决的是“请求被重复执行”的问题，而不是“多个请求同时执行”的问题。幂等与并发锁，是两套相互补充的防御体系。锁负责控制并发，幂等负责兜底，防止由于网络重试、消息重复、超时补偿等异常场景导致的库存扣减错误。

一、背景：库存扣减的核心矛盾与真实场景

1. 库存扣减为什么是电商系统的“心脏”

库存是电商的核心资产，扣减操作直接关联资金流和用户体验。一个库存超卖，轻则导致用户无法发货、投诉退款，重则引发公关危机和平台资损。在分布式环境下，库存扣减面临三个核心挑战：

• 高并发写冲突：秒杀、促销场景下，同一SKU可能被数万用户同时抢购，数据库行锁成为瓶颈。
• 数据一致性与性能的平衡：强一致性方案性能差，最终一致性方案又可能引入数据不一致窗口。
• 重复请求的防御：网络抖动、前端重试、消息队列重复投递等，都可能导致同一笔扣减请求被执行多次。

我曾经参与过一套日订单量超过200万的电商系统的库存重构。在重构前，系统采用简单的数据库乐观锁，日常订单还能勉强支撑，但一到618、双11等大促活动，库存扣减的失败率就会飙升到5%以上，导致大量订单无法生成，用户投诉率暴增。

2. 真实场景：从“超市货架”到“分布式战场”

让我用一个具体场景来说明：

假设你是一家大型连锁超市的在线购物平台，支持“门店自提”和“全国配送”两种模式。每个商品的库存数据，在Redis缓存中有快照，在MySQL数据库中也有记录。当用户下单时，系统需要：

1. 检查库存是否充足（Redis查询）。
2. 扣减库存（Redis或数据库操作）。
3. 生成订单。
4. 如果后续支付失败或订单取消，需要回补库存。

在这个流程中，任何一个环节出现问题，都可能导致库存数据不一致。例如：

• 网络抖动导致超时：用户点击“下单”按钮，前端发送请求，后端处理成功但响应超时，前端重试，导致同一订单被扣减两次库存。
• 消息队列重复消费：库存扣减完成后，异步发送消息给下游系统，消息队列重复投递，导致多次扣减。
• 分布式锁失效：在Redis分布式锁失效的情况下，多个线程同时执行扣减操作，导致超卖。

二、常见误区：你以为的“银弹”，其实都是“伪银弹”

1. 误区一：数据库乐观锁能解决一切并发问题

很多开发者在面对库存扣减时，第一反应就是使用数据库乐观锁。例如：

-- 扣减库存，使用版本号
UPDATE stock SET quantity = quantity - #{buyNum}, version = version + 1

WHERE sku_id = #{skuId} AND quantity >= #{buyNum} AND version = #{oldVersion};

这个方案确实能解决并发冲突问题，但存在两个致命缺陷：

• 性能瓶颈：在秒杀场景下，大量请求同时竞争同一行记录的行锁，数据库的吞吐量会急剧下降。我曾在压测中看到，5000并发请求下，MySQL的行锁等待时间超过200ms，QPS从2000暴跌到300。
• 无法解决重复问题：乐观锁只能防止“写冲突”，但无法防止“重复请求”。如果前端重试，同一笔订单被发送两次，第二次请求会使用不同的版本号，导致更新失败，但库存已经扣减了一次，造成数据库中有记录但库存未扣的假象。更糟糕的是，如果第一次请求成功，第二次请求失败，业务层可能认为扣减失败，导致用户无法正常下单。

2. 误区二：分布式锁是万能的

分布式锁（如Redisson）可以保证同一时刻只有一个线程对同一资源进行操作，但它同样存在一些棘手的问题：

• 性能开销：每次锁的获取和释放都需要网络通信，在高并发下会显著增加延迟。
• 死锁风险：如果持有锁的线程崩溃或发生网络分区，锁可能无法正常释放，导致其他线程永久阻塞。
• 粒度问题：锁的粒度过大，会导致大量请求排队等待，降低系统吞吐量；粒度过小，又会增加锁竞争的开销。
• 仍然无法解决重复问题：分布式锁只能保证同一时刻只有一个线程执行扣减，但如果前端因为超时重试，同一个请求会被执行两次，即使两次请求被锁串行化，也会导致两次扣减。

我曾在一次重构中，试图用分布式锁来解决所有问题，结果发现，锁本身引入的复杂度远大于它解决的问题。我们需要的是一个更根本的方案：幂等性。

3. 误区三：幂等设计就是“去重表”

很多人认为，幂等设计就是在数据库里建一张“去重表”，每次请求先查一下是否已经处理过。这种理解过于狭隘，而且在实际应用中存在很多坑：

• 性能隐患：每次请求都需要查询一次去重表，在高并发下会造成数据库压力。
• 数据一致性挑战：去重表的插入操作和业务操作不在同一个事务中，可能先去重表插入成功，但业务操作失败，导致正确请求被错误拦截。
• 状态管理缺失：“去重”只是幂等的一种形式，还需要考虑“幂等凭证”的过期、失效和状态变更。

真正的幂等设计，需要一套完整的机制，包括：幂等凭证的生成、校验、存储、过期、以及异常情况下的补偿。

三、专业判断逻辑：幂等设计的三个层次

1. 第一层：请求层幂等，防止重复请求

这是最基础的幂等，目的是防止前端或客户端因为网络问题而重试。实现方式通常是在请求头中携带一个唯一的幂等ID（Idempotency Key），后端在收到请求时，先检查该ID是否已经被处理过。

实现要点：

• 幂等ID的生成：客户端生成，格式可以是UUID，也可以是时间戳+机器ID+序列号的组合。需要保证全局唯一性。
• 幂等ID的存储：通常存储在Redis中，并设置过期时间（例如30分钟）。
• 幂等校验：后端在执行业务操作前，先查询Redis中是否存在该幂等ID。如果存在，直接返回之前的结果；如果不存在，则执行业务操作，并将结果存入Redis。

// 伪代码：幂等校验
@PostMapping("/order")

public Result createOrder(@RequestBody OrderRequest request, @RequestHeader("Idempotency-Key") String idempotencyKey) {

// 1. 检查幂等ID是否已存在

if (redisTemplate.hasKey("idempotent:" + idempotencyKey)) {

// 直接返回之前的结果

return Result.success(redisTemplate.opsForValue().get("idempotent:" + idempotencyKey));

}

// 2. 执行业务逻辑（库存扣减、订单创建等）

OrderResult result = orderService.createOrder(request);

// 3. 存储幂等结果

redisTemplate.opsForValue().set("idempotent:" + idempotencyKey, result, 30, TimeUnit.MINUTES);

return Result.success(result);

}

注意： 这个方案存在一个业务风险：如果第一次请求处理成功，但响应超时，客户端重试，第二次请求会直接返回第一次的结果，这可能导致用户以为订单未创建成功，从而重复下单。解决方案是：在幂等ID中绑定订单信息，如果第二次请求的订单信息与第一次不同，则拒绝处理。

2. 第二层：业务层幂等，防止重复扣减

这一层是专门针对库存扣减的幂等，目的是防止同一笔业务操作（如“下单扣减库存”）被执行多次。实现方式是在库存扣减操作中，引入一个唯一的业务流水号。

实现方案：

1. 生成业务流水号：在订单创建时生成一个全局唯一的流水号（例如：order_id + sku_id + 时间戳）。
2. 在库存扣减表中增加流水号字段：MySQL的库存扣减记录表增加一个`biz_serial_no`字段，并建立唯一索引。
3. 先插入，后更新：每次扣减库存时，先尝试向扣减记录表插入一条记录（包含流水号）。如果插入成功，则执行库存扣减操作；如果插入失败（唯一索引冲突），说明该流水号已经被处理过，直接返回成功。

— 扣减记录表
CREATE TABLE stock_deduction_log (

id BIGINT AUTO_INCREMENT PRIMARY KEY,

biz_serial_no VARCHAR(128) NOT NULL UNIQUE, — 业务流水号，唯一索引

sku_id BIGINT NOT NULL,

deduction_quantity INT NOT NULL,

status VARCHAR(32) DEFAULT 'INIT', — INIT, SUCCESS, FAILED

created_time DATETIME DEFAULT CURRENT_TIMESTAMP

);

— 扣减库存（伪SQL）

BEGIN;

INSERT INTO stock_deduction_log (biz_serial_no, sku_id, deduction_quantity) VALUES (#{serialNo}, #{skuId}, #{buyNum});

— 如果插入成功，则执行扣减

UPDATE stock SET quantity = quantity - #{buyNum} WHERE sku_id = #{skuId} AND quantity >= #{buyNum};
UPDATE stock_deduction_log SET status = 'SUCCESS' WHERE biz_serial_no = #{serialNo};
COMMIT;

为什么这个方案有效？

• 唯一索引保证了同一笔业务流水不会被重复执行。
• 先插入后更新的顺序，保证了即使业务操作失败，也能通过流水号的状态进行补偿。
• 将流水号的设计与业务逻辑解耦，可以灵活应用于各种扣减场景。

3. 第三层：分布式幂等，在跨服务场景下的最终一致性保障

在微服务架构下，库存扣减可能涉及多个服务（如：订单服务、库存服务、支付服务）。此时，需要确保跨服务调用的幂等性。

实现方案： 采用“状态机 + 异步对账”的模式。

• 状态机：每个业务操作（如“订单创建”）都有一个状态机，负责记录该操作的状态（如：初始、处理中、成功、失败）。
• 异步对账：定时任务或消息队列，定期检查各服务之间的状态是否一致。如果发现不一致（如：订单已创建，但库存未扣减），则触发补偿操作。

我曾在某项目中，使用异步对账方案解决了一个棘手的问题：由于网络延迟，库存服务收到了扣减请求，但响应超时，订单服务认为扣减失败，取消了订单。但库存服务实际上已经扣减成功，导致库存凭空消失。通过异步对账，我们发现了这个不一致，并自动回补了库存。

四、具体案例与数据观察：我踩过的坑和最终方案

1. 项目背景：一个日订单量200万的电商平台

我曾经负责一个电商平台的库存系统重构，该平台日订单量超过200万，峰值QPS超过5000。在重构前，系统采用“数据库乐观锁+Redis缓存”的方案，但存在以下问题：

• 库存超卖：在秒杀活动期间，库存超卖率高达0.5%，每次活动都要赔付几十万元。
• 重复扣减：由于前端重试和消息队列重复消费，库存扣减的重复率约1%，导致大量订单无法发货。
• 性能瓶颈：数据库行锁严重，扣减接口的P99延迟超过500ms。

2. 重构方案：幂等+缓存+异步架构

我们最终采用了“业务层幂等 + Redis缓存扣减 + 异步落库”的方案，具体架构如下：

1. 请求层幂等：前端请求携带幂等ID，后端进行去重校验，防止重复请求。
2. 业务层幂等：在库存扣减操作中，使用业务流水号（订单ID+SKU ID）进行幂等校验。
3. Redis缓存扣减：使用Redis的Lua脚本，保证扣减操作的原子性。Lua脚本中同时检查库存是否充足，并扣减缓存。
4. 异步落库：扣减缓存成功后，发送异步消息到消息队列，由消费者将库存扣减记录写入MySQL。
5. 对账补偿：定时任务对比Redis缓存和MySQL数据库的库存数据，发现不一致时进行补偿。

— Lua脚本：原子扣减库存
local key = KEYS[1] — 库存key

local deduct = tonumber(ARGV[1]) — 扣减数量

local biz_serial = ARGV[2] — 业务流水号

— 1. 检查幂等性

local is_processed = redis.call('SISMEMBER', 'idempotent:set', biz_serial)

if is_processed == 1 then

return 0 — 已处理，直接返回成功

end

— 2. 检查库存

local stock = redis.call('GET', key)

if not stock or tonumber(stock) return -1 — 库存不足

end

— 3. 扣减库存

redis.call('DECRBY', key, deduct)

— 4. 记录幂等

redis.call('SADD', 'idempotent:set', biz_serial)

redis.call('EXPIRE', 'idempotent:set', 3600) — 设置过期时间

return 1 — 扣减成功

3. 数据对比：重构前后的效果

重构上线后，我们进行了为期一个月的监控，数据对比如下：

4. 关键教训：幂等不是万能的，但缺少幂等是万万不能的

在这次重构中，我深刻体会到：

• 幂等是库存系统的“最后一道防线”，它决定了系统的鲁棒性。
• 幂等与并发控制不是二选一，而是协作关系：锁负责“防冲突”，幂等负责“防重复”。
• 幂等方案需要与业务场景深度结合：没有一种通用的幂等方案，需要根据业务场景选择最合适的方案。
• 幂等设计需要考虑异常情况：如幂等凭证的过期、失效、以及业务操作失败后的补偿。

五、行动建议：不同情况下的方案选择与取舍

1. 方案选择决策树

根据前文的分析，我整理了一个方案选择决策树，帮助你快速找到最适合自己业务场景的方案：

1. 你的系统并发量高吗？
   • 否（QPS < 1000）→ 使用数据库乐观锁即可。
   • 是（QPS >= 1000）→ 进入下一步。
2. 你需要处理重复请求吗？
   • 否 → 使用Redis原子操作（Lua脚本）。
   • 是 → 进入下一步。
3. 你的业务场景是跨服务调用吗？
   • 否 → 使用“业务层幂等（业务流水号）+ Redis缓存扣减 + 异步落库”。
   • 是 → 使用“分布式幂等（状态机 + 异步对账）”。

2. 不同场景下的取舍

3. 几点建议

• 不要过度设计：如果你的业务场景并发量很低，并且不需要处理重复请求，直接使用数据库乐观锁即可。过度设计只会增加系统的复杂度和维护成本。
• 从简单方案开始：我建议先从“业务层幂等（业务流水号）”开始，这个方案实现简单，且能解决大部分的问题。在业务发展到一定规模后，再考虑引入更复杂的方案。
• 重视幂等凭证的存储和过期策略：幂等凭证存储在Redis中，需要设置合理的过期时间，避免内存泄漏。同时，要考虑幂等凭证失效后的处理方案。
• 建立完善的监控和告警：对库存扣减的成功率、失败率、重复率等指标进行监控，一旦发现异常，立即告警。
• 进行充分的压测：在方案上线前，一定要进行充分的压测，验证方案的性能和稳定性。

六、总结与下一步

库存扣减的幂等设计，不是一个简单的“去重”问题，而是一套完整的、与业务场景深度结合的架构方案。它要求我们不仅要理解并发控制，还要理解业务逻辑，以及网络、消息队列等中间件可能带来的异常。

我的独特观点是： 在库存系统设计中，应该将“幂等”作为核心原则，而不是“锁”的附属品。锁是战术，幂等是战略。一个好的架构，应该能够在锁失效的情况下，仍然保证数据的最终一致性。

下一步，你可以做什么？

1. 评估你的现状：检查你的库存系统是否存在重复扣减、超卖等问题。
2. 选择最适合你的方案：根据本文提供的决策树和取舍建议，选择最适合你业务场景的方案。
3. 从最小改动开始：建议先从“业务层幂等（业务流水号）”开始，逐步引入更复杂的方案。
4. 持续监控和优化：上线后，持续监控核心指标，发现问题及时优化。

最后，分享一个我在实践中总结的“金句”：不要试图用架构的复杂性，去解决一个本可以用流程解决的问题。在引入复杂方案前，先问问自己，是不是可以通过更简单的业务规则来实现。 例如，在秒杀场景中，提前让用户排队，限制每个用户的购买数量，也可以有效降低库存系统的压力。

INSERT IGNORE INTO stock_ops_log (uuid, order_id, sku_id, op_type, status, create_time) VALUES (:uuid, :orderId, :skuId, 'DEDUCT', 'INIT', NOW());

class StockDeductConsumer { @Autowired private StockDeductService deductService;

insert(new StockOpsLog(uuid, /*其他字段*/, StatusEnum.INIT));

免费注册

咨询方案

扫码咨询方案