秒杀：少卖问题（图解+秒懂+史上最全）

1. 秒杀场景下的少卖问题是什么想象一下双11零点你蹲在手机前疯狂点击立即购买结果系统提示库存不足。但转头发现商品还在架上——这就是典型的少卖问题实际成交订单数小于真实库存量。与超卖卖爆库存相反少卖是该卖的没卖出去。我去年参与某电商平台秒杀系统优化时曾遇到一个诡异案例2000件特价商品最终只卖出1800件但后台显示有300多个未支付订单卡在系统中。技术总监当场黑脸这相当于白白浪费了200个获客机会少卖的核心矛盾在于系统暂时冻结的库存未能有效释放。常见于以下场景用户下单后未支付购物车遗忘/比价犹豫支付流程异常中断银行卡限额/网络抖动系统故障导致库存未回滚服务崩溃/消息丢失2. 少卖的三大技术诱因附真实案例2.1 订单支付超时未释放库存某母婴平台秒杀活动曾出现30%用户下单后未在15分钟内完成支付导致库存冻结。技术团队发现支付流程存在致命缺陷// 错误示例支付超时后未主动释放库存 public void processPayment(Order order) { if (order.getStatus() UNPAID) { // 设置30分钟支付超时 paymentService.startTimeoutTimer(order.getId(), 30, TimeUnit.MINUTES); // 但未注册超时回调 } }优化方案引入延迟消息双重保障# 正确做法支付系统库存系统的双保险 def create_order(): # 1. 预扣库存 reduce_redis_stock() # 2. 同时发送两条延迟消息冗余设计 mq.send_delay_message( topicorder_timeout, delay30min, bodyorder_id ) # 3. 数据库事务记录预扣状态 db.execute( INSERT INTO order_stock_hold (order_id, sku_id, hold_status) VALUES (%s, %s, HOLDING) , [order_id, sku_id])2.2 分布式事务中的库存回滚失败某次大促期间我们监控到MySQL主从延迟高达5秒。当支付回调触发库存扣减时从库仍读到旧数据导致如下惨剧[时序图] 1. 事务Abegin; 2. 事务Aupdate stock set countcount-1 where sku_id1001; 3. 事务Bbegin; 4. 事务Bselect count from stock where sku_id1001; -- 从库读到未扣减的值 5. 事务Acommit; -- 主库完成扣减解决方案最终一致性补偿机制// 使用本地消息表确保可靠性 Transactional public void confirmOrder(Long orderId) { // 1. 更新订单状态 orderDao.updateStatus(orderId, PAID); // 2. 插入本地消息记录 localMessageDao.insert( new Message(stock_deduction, orderId) ); // 3. 异步任务扫描消息表进行库存扣减 asyncTask.triggerStockDeduction(orderId); }2.3 缓存与数据库不一致某次秒杀中Redis显示库存为0但实际数据库仍有库存。问题出在# 缓存更新伪代码 def deduct_stock(): redis.decr(stock:1001) # STEP1: Redis扣减成功 raise Exception(DB connection failed) # STEP2: DB操作失败 # 结果Redis计数真实库存根治方案库存预扣与最终扣减分离[新架构流程] 1. 用户下单 → 预扣Redis库存立即生效 2. 异步队列 → 真实扣减DB库存 3. 定时任务 → 核对Redis与DB差异 4. 补偿机制 → 自动修正不一致数据3. 五套解决方案实战对比3.1 延迟消息补偿方案推荐实施步骤订单创建时发送两条延迟消息15分钟延迟检查支付状态30分钟延迟最终兜底检查消息处理器逻辑def check_order_payment(msg): order order_service.get(msg.order_id) if order.status UNPAID: # 释放库存 stock_service.release(order.sku_id) # 关闭订单 order_service.cancel(order.id)优点实现简单RocketMQ/Kafka原生支持延迟消息缺点需要处理消息重复消费需幂等设计3.2 定时任务扫描方案配置示例XXL-JOB-- 每5分钟执行一次的SQL UPDATE stock s JOIN order_stock_hold h ON s.sku_id h.sku_id JOIN orders o ON h.order_id o.id SET s.count s.count h.quantity, h.hold_status RELEASED WHERE o.status CANCELLED AND h.hold_status HOLDING参数建议执行频率高峰期间1分钟/次平时5分钟/次分页查询每次处理1000条避免长事务补偿机制失败记录加入死信队列3.3 库存预扣与最终扣减分离架构设计[库存状态机] 预扣阶段Redis → 已锁定 支付成功DB → 已扣减 支付超时Job → 已释放代码实现public class StockManager { // 预扣库存Redis原子操作 public boolean preDeduct(String sku, int qty) { return redisTemplate.execute(STOCK_SCRIPT, Collections.singletonList(stock: sku), String.valueOf(qty)); } // 最终扣减DB事务 Transactional public void realDeduct(Long orderId) { Order order orderDao.findById(orderId); stockDao.reduce(order.getSkuId(), order.getQty()); } }3.4 异步下单同步支付方案流程对比传统流程 下单 → 扣库存 → 支付 → 完成 改进流程 快速下单 → 支付 → 真实扣库存 → 完成 ↑ 10秒倒计时优势用户感知不到库存检查支付后才真实占用库存3.5 动态库存水位控制智能调节算法def calculate_release_quantity(): # 基于历史数据动态调整 avg_pay_time stats.get_avg_pay_time() current_unpaid order.count_unpaid_last_30min() # 提前释放部分库存 release_qty min( current_unpaid * 0.3, # 保守比例 redis.get(stock:reserve) ) redis.incr(stock:available, release_qty) redis.decr(stock:reserve, release_qty)4. 混合架构实战某电商秒杀系统改造去年我们为某服饰电商设计的混合方案技术组合预扣库存Redis Lua脚本最终一致RocketMQ事务消息异常处理Sentry告警 人工控制台关键代码片段-- stock.lua 库存操作脚本 local key KEYS[1] local change tonumber(ARGV[1]) local hold_ttl tonumber(ARGV[2]) local current redis.call(GET, key) if not current then return -1 -- 无库存记录 end if change current 0 then return -2 -- 库存不足 end redis.call(INCRBY, key, change) if hold_ttl 0 then redis.call(EXPIRE, key, hold_ttl) end return redis.call(GET, key) -- 返回最新值效果指标少卖率从8.7%降至0.3%峰值QPS提升5倍运维人力节省60%5. 避坑指南少卖问题预防清单监控必做项Redis/DB库存差异报警订单状态停留时间监控消息队列积压预警参数调优建议支付超时时间日用百货30分钟、生鲜10分钟库存冻结时间 支付超时时间 5分钟缓冲压测注意事项模拟20%订单不支付的情况强制重启服务测试恢复机制网络分区测试脑裂场景兜底方案-- 紧急库存释放SQL手动执行 UPDATE products p SET p.stock p.stock ( SELECT SUM(quantity) FROM order_stock_hold h JOIN orders o ON h.order_id o.id WHERE h.sku_id p.sku_id AND o.status CANCELLED ) WHERE p.sku_id IN (SKU123,SKU456);在秒杀这类极限场景中少卖问题就像隐形的利润黑洞。经过多个项目实战我认为**预扣隔离延迟释放实时核对**的三重保障最为可靠。最近一次大促中这套方案成功避免了价值230万的潜在损失。