Redis预减库存必须用DECRBY而非GET+SET，因后者存在竞态条件导致超卖；DECRBY原子性防超卖，需配合EXISTS校验key存在、检查返回值是否为负、Lua脚本封装操作，并在DB层用WHERE stock>0二次校验。
Redis预减库存为什么必须用DECRBY而不是GET+SET
因为并发下GET+SET存在竞态条件：两个线程同时读到库存10，都判断“够卖”，然后各自SET成9，实际只卖出了1件却扣了2次库存。DECRBY是原子操作，天然防超卖。
实操建议：
立即学习“Java免费学习笔记（深入）”；
-
DECRBY前先用EXISTS确认商品key存在，避免误减不存在的商品库存（比如活动未开启时key还没写入） - 返回值为负数时，说明已超卖，必须立即拒绝请求——不要等DB层再校验
- 别用
INCR回滚库存：秒杀失败时，应由业务逻辑决定是否归还（比如超时未支付才归还），不能无脑INCRBY - 库存key建议带业务前缀和版本号，例如
seckill:stock:v2:10086，方便灰度和清空
MySQL乐观锁更新订单时WHERE条件必须包含库存字段
只靠id或order_no做WHERE条件没法防超卖，因为库存已在Redis扣减，DB里还是旧值。必须让UPDATE语句本身承担最终库存校验责任。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- SQL要写成：
UPDATE item SET stock = stock - 1 WHERE id = ? AND stock > 0，不能省略AND stock > 0 - 执行后检查
ROW_COUNT()是否为1；为0说明DB里库存已不足，此时需回滚Redis（谨慎！见下一条） - 不建议在UPDATE失败后自动
INCRBYRedis库存——可能因网络重试导致重复回补，应由独立的补偿任务处理 - 如果DB用的是分库分表，确保
WHERE条件能路由到正确分片，否则可能漏校验
Redis和MySQL库存不一致时怎么快速定位
不一致通常不是“谁错了”，而是“谁慢了”：Redis预减成功但DB写入失败（如唯一索引冲突、连接超时），或DB回滚后没通知Redis。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 上线前必须有对账脚本，定时比对
seckill:stock:*和item.stock，输出差值大于阈值的item_id - 关键日志必须打全：Redis操作的返回值、DB UPDATE的
ROW_COUNT()、事务是否提交，三者缺一不可 - 不要依赖Redis过期自动清理库存——秒杀结束应主动
SET库存为初始值，否则下次活动会继承错误值 - 本地缓存（如Caffeine）如果存了库存，必须监听DB变更事件同步失效，否则会掩盖不一致
高并发下Redis Lua脚本比多次网络调用更可靠
网络往返耗时不稳定，三个独立命令（EXISTS→DECRBY→GET）在万级QPS下极易出现中间状态被其他请求干扰。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 把库存校验+扣减+剩余查询封装进一个Lua脚本，用
EVAL一次性执行，保证原子性 - Lua里用
redis.call('DECRBY', KEYS[1], ARGV[1])，别用redis.pcall捕获异常——秒杀场景要快，失败就失败，不兜底 - 脚本里禁止调用
SLEEP或循环大量数据，否则会阻塞Redis主线程 - 脚本长度超过500字符时，改用
EVALSHA+SCRIPT LOAD预加载，减少传输开销
真正难的不是写对一行DECRBY，而是当Redis返回-1、DB返回0行、日志里出现“duplicate key”时，你能立刻判断出是哪个环节丢了状态，而不是重启服务再碰运气。
