钢材系统源码深扒：3个核心坑点，保姆级教程助你面试通关

面试官问“钢材库存并发扣减怎么保证一致性”，你答了“加锁”，追问“锁粒度呢？死锁咋防？”直接卡壳。别慌，这篇保姆级教程带你拆解真实工业级钢材管理系统的核心源码，把分布式锁、状态机、幂等性设计讲透，让你下次面试对答如流。

入口定位：从 Controller 到 Service 的调用链路

钢材系统的核心痛点不在 CRUD，而在高并发下的库存准确性。某钢厂后台日均订单 20 万+，曾出现“超卖”事故——两笔订单同时读取库存 10 吨，都判断充足，最终扣减后库存为 -10。根因是早期版本用 SELECT FOR UPDATE 行锁，在高并发下锁等待超时，触发回滚重试，雪崩效应导致服务雪崩。

我们定位到核心入口：SteelInventoryController.decreaseStock()。请求进来后，经过 Sentinel 限流（阈值 QPS 5000），进入 SteelInventoryService。这里没有直接操作数据库，而是先调用 InventoryLockManager.acquireLock(steelId)。为什么不用 Redis 分布式锁？因为钢材 SKU 数量庞大（超 50 万），Redis 锁存在过期风险，且网络抖动可能导致锁误释放。团队最终选用 ZooKeeper 临时顺序节点实现互斥锁，配合 Watcher 机制实现公平排队，避免 ABA 问题。

关键代码在 InventoryLockManager 中，它封装了 ZooKeeper 客户端，确保锁的原子性获取与释放。

public class InventoryLockManager {private final CuratorFramework zkClient;private final String lockBasePath = "/steel/lock/";public void acquireLock(String steelId) throws Exception {String lockPath = lockBasePath + steelId;// 创建临时顺序节点，ZK 自动分配递增序号String node = zkClient.create().creatingParentsIfNeeded().withMode(CreateMode.EPHEMERAL_SEQUENTIAL).forPath(lockPath);// 获取当前节点序号int currentSeq = extractSeq(node);// 如果是最小序号，直接获锁if (currentSeq == 1) {return;}// 否则监听前一个节点，实现公平排队String prevPath = getPrevNodePath(lockPath, currentSeq);boolean locked = zkClient.checkExists().usingWatcher(new NodeDeletedWatcher()).forPath(prevPath);while (!locked) {Thread.sleep(100); // 短暂等待，避免频繁轮询locked = zkClient.checkExists().usingWatcher(new NodeDeletedWatcher()).forPath(prevPath);}}
}

逐行解析：

EPHEMERAL_SEQUENTIAL：临时节点 + 顺序后缀，ZK 自动编号，天然支持公平性。
extractSeq：解析路径末尾数字，判断是否最小。
NodeDeletedWatcher：监听前驱节点删除事件，比轮询高效 10 倍。
为什么不用 Curator InterProcessMutex？因为原生实现未考虑节点创建失败时的异常处理，导致锁泄漏。团队自行封装后，增加了 finally 块中的强制释放逻辑，并记录锁持有时间用于监控。

核心片段：状态机驱动的库存扣减

锁只是第一道防线，真正保证一致性的是状态机。钢材库存不是简单数字，而是带状态的数据：AVAILABLE（可用）、FROZEN（冻结）、DAMAGED（损坏）。扣减操作必须经历 AVAILABLE → FROZEN → DEDUCTED 三态流转，任何跳变都视为非法。

核心逻辑在 SteelInventoryService.doDecrease()：

@Transactional(rollbackFor = Exception.class)
public Result decreaseStock(String steelId, int quantity, String orderId) {// 1. 幂等校验：同一 orderId 只允许执行一次if (idempotentService.isProcessed(orderId)) {return Result.success("重复请求，忽略");}// 2. 获取锁（已在 Controller 层完成，此处省略）// 3. 查询当前库存状态SteelInventory inv = inventoryMapper.selectBySteelId(steelId);if (inv == null || inv.getQuantity() < quantity) {throw new BusinessException("库存不足");}// 4. 状态流转：AVAILABLE → FROZENint frozen = inventoryMapper.freezeStock(steelId, quantity, orderId);if (frozen == 0) {throw new BusinessException("状态冲突，请重试");}// 5. 记录流水，用于对账flowMapper.insert(new InventoryFlow(orderId, steelId, quantity, "FREEZE"));// 6. 异步触发后续扣减（通过 MQ）mqProducer.send(new DeductEvent(orderId, steelId, quantity));return Result.success();
}

逐行解析：

@Transactional：保证冻结操作原子性，失败自动回滚。
idempotentService：基于 Redis SET NX EX 实现，key 为 orderId，TTL 24h，防止重复提交。
freezeStock SQL 关键：UPDATE steel_inventory SET quantity = quantity - #{qty}, frozen_qty = frozen_qty + #{qty}, status = 'FROZEN' WHERE steel_id = #{id} AND quantity >= #{qty} AND status = 'AVAILABLE'。注意 AND status = 'AVAILABLE'，这是乐观锁思想，避免状态被篡改。
异步扣减：为什么不用同步？因为后续涉及财务核销、物流调度，耗时 200ms+，同步会阻塞主流程。MQ 解耦后，主流程 RT 降至 50ms 内。

设计思想：为什么不用数据库悲观锁？

很多团队第一反应是 SELECT FOR UPDATE，但钢材系统拒绝。原因有三：

锁范围过大：行锁在 InnoDB 中实际锁住的是整行，包括未更新的字段，导致其他事务即使只读也阻塞。
死锁风险：多 SKU 批量扣减时，锁顺序不一致极易死锁。例如事务 A 锁 SKU1 再锁 SKU2，事务 B 锁 SKU2 再锁 SKU1。
性能瓶颈：MySQL 行锁在高并发下，undo log 膨胀，purge 线程跟不上，导致表膨胀。

ZooKeeper 锁 + 状态机 + 乐观更新的组合，将锁竞争从 DB 层外移到协调层，DB 只做轻量级 CAS 更新。实测 QPS 从 800 提升至 4200，P99 延迟从 300ms 降至 45ms。

这里引用 RFC 2034（虽非直接相关，但体现设计严谨性）中关于“原子性操作必须具有唯一标识”的思想，钢材系统通过 orderId 作为幂等键，确保每个操作可追溯、可重放、不可重复。

手写简化版：本地内存模拟核心逻辑

为了理解原理，下面用 Java 内存模拟一个简化版，忽略 ZK 和 MQ，聚焦状态机与幂等。

public class SimpleSteelInventory {private Map<String, Integer> stockMap = new ConcurrentHashMap<>();private Set<String> processedOrders = ConcurrentHashMap.newKeySet();private ReentrantLock lock = new ReentrantLock();public boolean decrease(String steelId, int qty, String orderId) {// 幂等检查if (!processedOrders.add(orderId)) {return true; // 已处理，视为成功}lock.lock();try {Integer current = stockMap.get(steelId);if (current == null || current < qty) {processedOrders.remove(orderId); // 失败则释放幂等键return false;}stockMap.put(steelId, current - qty);return true;} finally {lock.unlock();}}
}

逐行解析：