库存扣减必须用数据库行锁，不能只靠Java同步；需用SELECT ... FOR UPDATE配合主键查询、READ COMMITTED隔离级别及UPDATE校验；采用预占+确认两阶段设计；Redis缓存须用Lua脚本保证原子性；所有变更须记明细日志且不可物理删除。
库存扣减必须用数据库行锁，不能只靠Java同步
高并发下单时，多个线程同时读取同一商品库存、判断足够后再更新，极易出现超卖。单纯用 synchronized 或 ReentrantLock 锁住 Java 方法没用——锁只在单 JVM 进程内有效，集群部署下完全失效。
- 正确做法是依赖数据库的
SELECT ... FOR UPDATE（InnoDB 行锁），确保读取+扣减原子性 - SQL 必须带上主键或唯一索引条件，否则会升级为表锁，拖垮性能
- 事务隔离级别至少为
READ COMMITTED，避免不可重复读干扰库存判断
UPDATE product_stock SET stock = stock - 1 WHERE product_id = ? AND stock >= 1;
执行后检查 updateCount 是否为 1：等于 0 表示库存不足或已被抢完，直接回滚事务。
库存预占（冻结）与最终确认要分两阶段
用户下单成功但未支付时，不能直接扣减可用库存，否则大量未支付订单会导致真实可售库存虚低。需要“预占 + 确认/释放”两阶段设计。
- 下单时：将库存从
available_stock减去，加到frozen_stock字段（两者和为总库存） - 支付成功：将
frozen_stock归零，locked_stock（已售）加对应数量 - 超时未支付：通过定时任务或延迟消息，把
frozen_stock加回available_stock
字段设计示例：
立即学习“Java免费学习笔记（深入）”；
CREATE TABLE product_stock ( product_id BIGINT PRIMARY KEY, total_stock INT NOT NULL, available_stock INT NOT NULL, frozen_stock INT NOT NULL DEFAULT 0, locked_stock INT NOT NULL DEFAULT 0 );
Redis 缓存库存需与 DB 强一致，不能简单 set/get
用 Redis 做库存缓存能扛住瞬时流量，但若只用 GET 判断再 DECR，仍可能超卖——因为 Redis 的 GET 和 DECR 不是原子操作。
- 必须用 Lua 脚本封装判断+扣减逻辑，保证原子性
- 脚本里要校验当前值 ≥ 1，且
DECR后结果 ≥ 0，失败返回负数 - DB 更新成功后，再用
DEL清除 Redis key，让下次读自动回源加载最新值（旁路缓存模式）
local stock = redis.call('GET', KEYS[1])
if not stock or tonumber(stock) < tonumber(ARGV[1]) then
return -1
end
return redis.call('DECRBY', KEYS[1], ARGV[1])库存变更必须记录明细，且不允许物理删除
库存数字出错时，没有明细日志就无法对账、追查源头。所有增减操作都要落库，且禁止 DELETE FROM stock_log。
- 建表含关键字段：
product_id、change_amount（正为补货，负为销售）、order_id（关联单据）、source_type（如 'ORDER_PAY' / 'REFUND' / 'ADJUST'） - 每次扣减前先插入日志，再更新库存主表；任一环节失败则整个事务回滚
- 提供按
product_id+ 时间范围查日志的接口，用于运营核对和问题排查
一个容易被忽略的点：库存调整（比如运营人工补货）必须走独立审批流，不能复用下单接口，否则权限和审计链路就断了。
