Java秒杀防超卖技巧：Redis减库存+数据库乐观锁

本文深入剖析了高并发秒杀场景下防止商品超卖的核心技术方案，强调必须结合Redis原子性操作（DECRBY+Lua脚本）与MySQL乐观锁（WHERE stock > 0 + ROW_COUNT校验）构建双重防护体系，并系统指出常见误区——如禁用GET+SET引发竞态、避免盲目INCR回滚、杜绝依赖Redis过期自动清理、重视全链路日志与对账机制等，直击生产环境真实痛点，帮助开发者从“能跑通”迈向“稳可靠”。

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学习网公众号！