Java秒杀防超卖：Redis减库存+乐观锁实战

本文深入剖析了Java秒杀场景中防超卖的核心实战策略，强调必须以Redis的DECRBY原子操作替代存在严重竞态风险的GET+SET组合，并通过EXISTS校验、负值拦截、Lua脚本封装确保预减库存的强一致性；同时指出数据库层必须依赖WHERE stock > 0的乐观锁更新与ROW_COUNT()校验实现最终兜底，严禁依赖INCRBY回滚或过期自动清理；文章还系统覆盖了前缀版本化、分库分表路由、Redis-Mysql对账、全链路日志追踪及本地缓存同步等关键细节，直击高并发下状态丢失、数据不一致等真实痛点，为构建稳定可靠的秒杀系统提供了可落地、经验证的完整技术闭环。

Redis预减库存为什么必须用DECRBY而不是GET+SET

因为并发下GET+SET存在竞态条件：两个线程同时读到库存10，都判断“够卖”，然后各自SET成9，实际只卖出了1件却扣了2次库存。DECRBY是原子操作，天然防超卖。

实操建议：

• DECRBY前先用EXISTS确认商品key存在，避免误减不存在的商品库存（比如活动未开启时key还没写入）
• 返回值为负数时，说明已超卖，必须立即拒绝请求——不要等DB层再校验
• 别用INCR回滚库存：秒杀失败时，应由业务逻辑决定是否归还（比如超时未支付才归还），不能无脑INCRBY
• 库存key建议带业务前缀和版本号，例如seckill:stock:v2:10086，方便灰度和清空

MySQL乐观锁更新订单时WHERE条件必须包含库存字段

只靠id或order_no做WHERE条件没法防超卖，因为库存已在Redis扣减，DB里还是旧值。必须让UPDATE语句本身承担最终库存校验责任。

实操建议：

• SQL要写成：UPDATE item SET stock = stock - 1 WHERE id = ? AND stock > 0，不能省略AND stock > 0
• 执行后检查ROW_COUNT()是否为1；为0说明DB里库存已不足，此时需回滚Redis（谨慎！见下一条）
• 不建议在UPDATE失败后自动INCRBY Redis库存——可能因网络重试导致重复回补，应由独立的补偿任务处理
• 如果DB用的是分库分表，确保WHERE条件能路由到正确分片，否则可能漏校验

Redis和MySQL库存不一致时怎么快速定位

不一致通常不是“谁错了”，而是“谁慢了”：Redis预减成功但DB写入失败（如唯一索引冲突、连接超时），或DB回滚后没通知Redis。

实操建议：

• 上线前必须有对账脚本，定时比对seckill:stock:*和item.stock，输出差值大于阈值的item_id
• 关键日志必须打全：Redis操作的返回值、DB UPDATE的ROW_COUNT()、事务是否提交，三者缺一不可
• 不要依赖Redis过期自动清理库存——秒杀结束应主动SET库存为初始值，否则下次活动会继承错误值
• 本地缓存（如Caffeine）如果存了库存，必须监听DB变更事件同步失效，否则会掩盖不一致

高并发下Redis Lua脚本比多次网络调用更可靠

网络往返耗时不稳定，三个独立命令（EXISTS→DECRBY→GET）在万级QPS下极易出现中间状态被其他请求干扰。

实操建议：

• 把库存校验+扣减+剩余查询封装进一个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”时，你能立刻判断出是哪个环节丢了状态，而不是重启服务再碰运气。

今天关于《Java秒杀防超卖：Redis减库存+乐观锁实战》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！