库存扣减需分层防护：用乐观锁或Redis原子操作防超卖，预占库存分离状态，Redis+MySQL最终一致，Seata/TCC保障强一致，辅以日志、快照、告警等兜底与可观测措施。
Java仓储管理系统做库存扣减，核心是保证“高并发下不超卖、不重复扣减、数据最终一致”。光靠数据库UPDATE语句远远不够，必须结合业务场景设计分层防护机制。
库存扣减不能只靠数据库UPDATE
直接执行 UPDATE product SET stock = stock - 1 WHERE id = ? AND stock > 0 看似简单，但在并发请求下容易因数据库行锁粒度、事务隔离级别或网络重试导致问题。比如：两个线程同时读到stock=1，都判断通过，最终扣成-1。
解决思路是把“检查+扣减”变成原子操作：
- 用数据库乐观锁（version字段或stock条件更新）配合失败重试
- 对热点商品加分布式锁（如Redis Lua脚本实现的原子decr），避免大量请求阻塞在DB层
- 将库存预占（预扣减）和实际出库分离，引入“可用库存”“预占库存”“已出库库存”状态字段
基于Redis + MySQL的最终一致性方案
适合中高并发、允许短时间（秒级）库存不一致的场景。关键不是“实时强一致”，而是“快速响应 + 可回滚 + 可对账”。
立即学习“Java免费学习笔记（深入）”；
典型流程：
- 下单时先查Redis缓存中的可用库存（用
DECR命令扣减，返回值≤0则拒绝） - Redis扣成功后，异步落库：发MQ消息写MySQL，更新product表和订单明细
- 若落库失败（如DB挂了），通过定时任务扫描Redis中“已扣未落库”的订单ID，补偿入库或自动回滚Redis库存
- 每天凌晨用MySQL做全量对账，修复异常差异
分布式事务保障库存与订单强一致
对金融级要求高的系统（如医药、精密配件），需保证库存扣减和订单创建100%同时成功或失败。
推荐组合：
- Seata AT模式：在service层用
@GlobalTransactional包裹库存服务和订单服务，由Seata代理SQL生成undo_log，自动回滚 - TCC模式（更可控）：定义Try（冻结库存）、Confirm（扣减）、Cancel（解冻）三个接口，业务自己控制资源预留与释放逻辑
- 注意：TCC对代码侵入大，但无中间件依赖；AT模式依赖数据库支持，且需注意长事务导致的全局锁问题
库存扣减的兜底与可观测性设计
再完善的方案也要面对极端情况——网络分区、Redis雪崩、MQ堆积、DB主从延迟。所以必须有兜底能力：
- 所有库存变更操作记录完整日志（含traceId、商品ID、操作前/后库存、操作人、时间戳）
- 提供“库存快照”查询接口，支持按小时拉取历史库存变化趋势
- 设置库存阈值告警（如可用库存＜50时短信通知运营），并支持人工干预（紧急补货、临时下架）
- 前端下单页显示“库存仅剩X件”，该数字应来自Redis缓存而非实时查DB，避免压垮数据库
基本上就这些。库存不是单纯的技术问题，而是业务规则、技术选型和运维能力的综合体现。不复杂但容易忽略的是：每次扣减都要回答三个问题——谁扣的？为什么扣？扣完能反悔吗？想清楚这三点，方案自然就稳了。
