17370845950

库存扣减必须用数据库行锁，不能只靠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

字段设计示例：

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 + 时间范围查日志的接口，用于运营核对和问题排查

一个容易被忽略的点：库存调整（比如运营人工补货）必须走独立审批流，不能复用下单接口，否则权限和审计链路就断了。