高并发下如何防止商品超卖少卖

主要问题本质⚠️

超卖 / 少卖的根源都是 "读 - 改 - 写" 非原子操作导致的竞态条件：

• 从超卖🛑来看。多个线程同时读到相同库存，都执行扣减，最终库存为负
  • 库存扣成负数，实际没货了程序却还接单，最常见的致命问题。
• 少卖📉这方面，扣减成功但订单失败 / 订单成功但扣减失败。导致库存与订单数不一致
  • 明明有库存，程序却误判售罄拒绝使用者，白白损失销量。通常是并发竞争失败或库存同步延迟导致。

分层方法

数据库层基础方案

适合初创项目或低流量场景。纯数据库实现，无额外依赖。

直接扣减法

利用 MySQL 单条 UPDATE 语句的原子性，从根源杜绝超卖：

-- 主要SQL：只有库存>0时才执行扣减
UPDATE goods
SET stock = stock - #{quantity}
WHERE id = #{goodsId} AND stock> 0;

• 说到优点，最简单、无并发问题、性能比更好乐观锁
• 注意这方面，必须通过受影响行数判断是否扣减成功。不能先查再改

乐观锁

-- 先查版本号
SELECT version FROM goods WHERE id = #{goodsId};-- 扣减时校验版本号
UPDATE goods
SET stock = stock - #{quantity},version = version + 1
WHERE id = #{goodsId} AND version = #{oldVersion} AND stock>= #{quantity};

• 从缺点来看，高并发下大量请求失败，使用者体验差。不适合秒杀场景

悲观锁

BEGIN;SELECT stock FROM goods WHERE id = #{goodsId} FOR UPDATE;UPDATE goods SET stock = stock - #{quantity} WHERE id = #{goodsId};COMMIT，

缺点这方面。串行执行，性能极差，容易死锁，不推荐。怎么说呢，

分布式锁方案

适合中等并发场景。通过分布式锁将并行请求串行化。其实，

• 推荐实现：Redisson 的可重入锁
• 主要流程：
1. User 下单 → 尝试获取商品级分布式锁； 获取成功 → 查库存 → 扣减 → 创建订单 → 释放锁； 获取失败 → 返回 “抢购失败”。
2. 缺点的观点是。本质还是串行，并发上限低，无法支撑秒杀级流量。说起来，

Redis 预扣减 + 最终一致性

主要流程图：

关键细节：

1. Redis 扣减必须用 Lua 脚本 : 保证 “判断库存 – 扣减库存” 原子性。

-- 主要 Lua 脚本
local stock = redis.call
if not stock or tonumber 

1. 库存预热 : 活动开始前将商品库存同步到 Redis。
2. 防缓存穿透 : 不存在的商品直接返回，不打 DB。
3. 库存回滚 : 用 RocketMQ 延迟队列处理超时未支付订单。

这套方案如何解决两个主要问题：

• 防超卖 ✅ ： A Lua 脚本在 Redis 单线程环境中一次性完成 “判断+扣除”。即使最终一件也只能被一个请求成功，其它请求走 else 分支。.
• 防少卖 🔒 ： A 正确判断后只会执行一次 decrby。只要 Redis 有足够数量，就一定能成功。不会出现“库存在那但抢不到”的冲突，提高通过率和销量。.

再看"进阶保障。应对异常彻底堵上少卖漏洞 🧰"

"Redis 虽然快，但如果后续链路不完善，也可能出现少卖。" "

关键模块
监控报警/熔断器	每分钟做一次对账，如果出现不一致立即报警并自动同步修复；当发现 Redis 缺货而 DB 有货时立即回补；如果发现 DB 缺货而 Redis 有货。则强制清空缓存标记售罄状态，以免误报。
前端限流+网关限流	对每个 IP 与每个 UID 做动态限流。当检测到短时间内频繁下单时主动返回错误码“请稍后再试”，避免恶意刷单导致占用大量仓储。
幂等校验	在业务服务层还有 Redis 层均加入唯一签名校验，当同一笔订单被重复触达多次时只允许第一次真正执行一次扣减与生成记录；其余次数直接返回重复提交提示，从根源消除因多次点击造成的“假售罄”。

   落地实战案例    ⚠️请勿忽略此环节！怎么说呢，⚠️ 请务必在生产环境上线前配置上述监控报警与自愈脚本。否则即便你已做到业务层逻辑完美，也可能因为偶尔网络抖动或硬件故障导致“一瞬间”数据漂移，引起大规模短缺或超卖。如需进一步协助，请联系运维团队或阅读我们内部《Redis 异步事件驱动架构》文档。按理说，—END— —END— —END—

"

---

防少卖兜底保障机制 🚨

• MQ 重试机制：OrderService 在数据库更新失败时会自动重试三次；若仍失败则放入死信队列人工干预。
• 死信队列：OrderDeadLetterConsumer 会定期扫描未确认状态。将未支付且已超过有效期的订单标记为取消，并回滚对应 Redis 库存。
• 每日对账程序：DailyReconciliationJob 每日凌晨跑全量比对。“订单支付数 == DB 库存扣除数”，若发现偏差则以 DB 为准强制同步回 Redis 或写入日志供人工修正。
• Redis 库存兜底： 当 Redis 库存临界值接近零且检测到可能的数据丢失时会 查询 MySQL 并做二次校验，以避免因网络抖动导致误报“售罄”。

---

---

---

---

---

---