别再死记硬背了：手写实现Inventory库存扣减，3步解决并发超卖痛点

看了一堆教程还是不会写项目？别怪自己笨，是那些只讲CRUD的教程害了你。真正的后端核心，不在于你会调用多少API，而在于你能不能手写实现一个高并发下依然稳定的业务逻辑。今天我们就拿电商系统里最经典的 inventory 模块开刀，不整虚的，直接拆解底层原理，让你从“调包侠”进化为能解决生产事故的老手。

一句话原理：库存不是数字，是状态机

很多人以为库存就是个数据库里的 int 字段，扣减就是 stock = stock - 1。大错特错。在分布式系统中，inventory 的本质是一个受控的状态流转过程。它必须保证在任意时刻，已锁定库存与剩余可售库存之和等于总库存。

这就好比你去银行取钱，柜员不会直接看你余额够不够，而是先挂起这笔钱（锁定），确认无误后再从账户划走（扣减）。如果两个人同时取钱，且余额只够一个人取，系统必须决定谁成功、谁失败，绝不能让两个人都取走钱（超卖），也不能让钱凭空消失（少卖）。

手写实现 的核心难点，不在于SQL怎么写，而在于如何在这个“锁定-确认-释放”的流程中，处理好并发冲突。Stack Overflow 上有无数关于 SELECT FOR UPDATE 导致死锁的提问，根源就在于大家没搞懂数据库行锁的粒度与范围。

类比解释：食堂打饭与“占座”机制

想象一下学校食堂打饭的场景。

普通做法（直接扣减）：你看到剩1份红烧肉，直接去夹。同时另一个同学也看到了，他也去夹。结果两人都没夹到，或者一个人夹走了，另一个人空手，甚至打饭阿姨崩溃了。这就是超卖。
乐观锁做法：你看到剩1份，先在心里默念“我要了”（版本号+1）。当你真正去夹的时候，发现版本号变了（别人先动了），你就放弃，重试或报错。
悲观锁做法（Inventory核心）：你走过去，跟阿姨说“我要买这份红烧肉”。阿姨立刻给你打个牌子（加锁），这时候别人看这份肉，虽然还在盘子里，但阿姨已经不允许别人碰了。你付钱（确认扣减）后，阿姨才真正把肉从盘子里拿走（物理删除或更新）。如果付钱超时，牌子收回，肉重新可售（回滚）。

在 inventory 系统中，悲观锁 是保证数据强一致性的最后防线，但它性能差；乐观锁 性能高，但重试逻辑复杂。手写实现的关键，就是根据业务QPS选择合适的锁策略，或者混合使用。

源码解析：从 SQL 到 Java 的底层映射

我们来看一段典型的 inventory 扣减伪代码。这里为了清晰，我们用 Java 表达核心逻辑，但底层原理适用于任何语言。

@Transactional
public void deductInventory(String skuId, int count) {// 1. 查询当前库存状态（加锁）// 关键点：FOR UPDATE 会锁定这一行记录，其他事务无法修改，只能等待Inventory inventory = inventoryMapper.selectForUpdate(skuId);if (inventory == null || inventory.getStock() < count) {throw new BusinessException("库存不足");}// 2. 内存中计算新库存int newStock = inventory.getStock() - count;// 3. 更新数据库// 关键点：WHERE 条件带上 version，实现乐观锁兜底（虽然上面已加锁，但双保险更稳）int updatedRows = inventoryMapper.updateStock(skuId, newStock, inventory.getVersion() // 版本号);if (updatedRows == 0) {throw new BusinessException("并发冲突，请重试");}
}

逐行拆解：

selectForUpdate：这是 inventory 模块的灵魂。它触发了数据库的行级排他锁（X Lock）。在高并发下，所有请求会在这里排队。如果队列太长，数据库连接池会被耗尽，这就是为什么很多大厂的库存服务会引入 Redis 做前置过滤。
version 字段：虽然 FOR UPDATE 已经加了锁，但在某些非严格事务隔离级别下，或者为了防御代码Bug，带上版本号更新是一种手写实现 的稳健习惯。它确保了即使锁失效，数据也不会被错误覆盖。
Stack Overflow 上的一个高赞回答指出：在 MySQL InnoDB 引擎下，UPDATE ... WHERE id = ? AND stock >= ? 这种写法比先查后改性能更好，因为它减少了事务持锁的时间。但在复杂业务中，先查后改能提供更友好的错误提示。

流程描述：库存扣减的完整生命周期

一个健壮的 inventory 服务，其生命周期不仅仅是扣减，还包括预占、确认和回滚。以下是标准的流程描述：

预占阶段（Lock）：
- 用户点击“提交订单”。
- 系统调用 inventory 服务，尝试锁定库存。
- 数据库执行 SELECT FOR UPDATE，锁定 SKU 行。
- 更新 locked_stock 字段增加，available_stock 减少。
- 返回锁定的订单ID和过期时间（例如30分钟）。
确认阶段（Confirm）：
- 用户支付成功。
- 支付回调通知 inventory 服务。
- 系统根据订单ID，将 locked_stock 转为已消耗，available_stock 保持不变（因为之前已经减了）。
- 释放锁。
回滚阶段（Release）：
- 用户超时未支付，或支付失败。
- 定时任务扫描过期锁。
- 系统释放锁，locked_stock 减少，available_stock 增加。
- 库存恢复可售状态。

避坑指南：

锁粒度：尽量锁行，不要锁表。锁表会导致整个库存系统不可用。
超时释放：必须有定时任务或消息队列延时消息来处理未支付的锁。否则，用户不付款，库存就永远被占着，导致超卖的反面——少卖。
幂等性：支付回调可能会重复发送，inventory 服务必须保证同一个订单只能扣减一次。通常通过 order_id 作为唯一索引来保证。

实战验证：如何测试你的 Inventory 实现

光说不练假把式。如何验证你的 inventory 手写实现是否扛得住高并发？

JMeter 压测：
- 准备一个 SKU，库存设为 100。
- 发起 500 个并发请求，每个请求扣减 1 件。
- 预期结果：成功 100 次，失败 400 次，最终库存为 0，无负数。
- 常见错误：库存变成 -1（超卖），或者成功次数少于 100（少卖，说明锁竞争过于激烈导致大量超时）。
混沌工程：
- 在扣减过程中，人为杀死数据库连接。
- 验证事务是否自动回滚，库存是否恢复。
- 验证定时任务是否能在数据库恢复后，正确释放之前未完成的锁。
监控告警：
- 监控 locked_stock 和 available_stock 的差值。如果长时间没有变化，说明可能存在死锁或内存泄漏。
- 监控 SELECT FOR UPDATE 的等待时间。如果 P99 延迟超过 50ms，说明数据库瓶颈明显，需要考虑引入 Redis 预扣减。