3 种秒杀防超卖方案对比：悲观锁 vs 乐观锁 vs 分段缓存（附压测数据）

3 种秒杀防超卖方案对比悲观锁 vs 乐观锁 vs 分段缓存附压测数据1. 秒杀场景下的超卖挑战电商大促时一款热门商品往往会在几秒内吸引数万用户同时点击立即购买。当库存仅剩最后100件时系统如何确保不会卖出第101件这就是高并发场景下最棘手的超卖问题。超卖的本质是并发读写冲突。传统流程查询库存→创建订单→扣减库存在单线程下运行良好但面对每秒上万请求时会出现致命缺陷两个线程同时查询到库存为1都认为可售最终导致库存变为-1。我曾参与某家电品牌618大促因未做防超卖处理实际售出量超出库存37%直接损失超200万元。2. 核心解决方案技术对比2.1 悲观锁方案行级锁的强一致性实现原理BEGIN; SELECT stock FROM items WHERE id1001 FOR UPDATE; -- 获取排他锁 UPDATE items SET stockstock-1 WHERE id1001; COMMIT;关键指标维度数值平均RT35ms最大QPS1,200死锁发生率0.02%适用场景库存量少1,000件对一致性要求极高的金融类业务并发量在1,000 QPS以下典型案例某奢侈品电商采用SELECT FOR UPDATE方案在保证库存绝对准确的同时通过以下优化提升性能为商品ID建立聚簇索引设置锁超时时间innodb_lock_wait_timeout50ms使用SHOW ENGINE INNODB STATUS监控死锁2.2 乐观锁方案版本号控制的轻量级实践实现方案// 先查询当前版本号 Item item itemMapper.selectById(itemId); // 基于版本号更新 int affected itemMapper.updateStock( itemId, quantity, item.getVersion() ); if(affected 0) { throw new OptimisticLockException(); }压测数据对比并发用户数 | 悲观锁QPS | 乐观锁QPS ------------------------------- 500 | 800 | 3,200 1,000 | 1,200 | 5,800 5,000 | 死锁频发 | 12,000优化技巧采用CAS自旋重试机制重试3次后降级结合Redis缓存预热版本号使用WHERE stockquantity防负数2.3 分段缓存方案RedisLua的原子化实践架构设计用户请求 → Redis预减库存 → 消息队列 → DB持久化Lua脚本示例local key KEYS[1] local change tonumber(ARGV[1]) local stock tonumber(redis.call(GET, key)) if stock change then redis.call(DECRBY, key, change) return 1 -- 成功 end return 0 -- 失败性能基准测试Redis集群16分片支撑12万QPS消息队列处理延迟50ms库存误差率0.001%异常处理库存回补机制RocketMQ延迟消息检查未支付订单分布式锁防重Redisson实现秒级锁自动续期降级方案库存不足时直接返回已售罄3. 技术选型决策树根据业务特征选择方案的决策流程图graph TD A[库存量] --|10万| B[分段缓存] A --|1万| C{并发量} C --|5,000 QPS| D[乐观锁] C --|5,000 QPS| E[悲观锁] B -- F[是否需要强一致] F --|是| G[本地消息表] F --|否| H[最终一致]关键考量维度数据一致性金融级业务首选悲观锁并发量级万级以上必选分段方案库存规模大库存需配合缓存预热技术成本乐观锁改造成本最低4. 混合方案的最佳实践某头部电商的秒杀系统实现流量分层80%流量被CDN和页面静态化拦截剩余请求进入Redis集群校验分级校验def check_stock(user_id, item_id): # 第一层Redis原子递减 if not redis.decr(fstock:{item_id}): return False # 第二层数据库最终校验 try: with transaction.atomic(): item Item.objects.select_for_update().get(iditem_id) if item.stock 0: Order.create(user_id, item_id) return True except: redis.incr(fstock:{item_id}) # 回滚 return False性能数据峰值QPS24万下单成功率99.98%资损率0.0001%5. 避坑指南悲观锁常见问题死锁检测导致CPU飙升建议关闭innodb_deadlock_detect锁等待超时合理设置innodb_lock_wait_timeout全表锁风险必须确保走索引乐观锁注意事项版本号字段需加索引高并发下重试风暴需设置最大重试次数不适合长事务场景分段缓存陷阱缓存与DB不一致通过定时任务对账少卖问题设置库存缓冲池如预留5%Redis崩溃降级到数据库限流模式实际项目中我们曾遇到Redis集群脑裂导致库存多扣的问题。最终通过引入ZooKeeper监听机制在节点异常时自动触发库存回滚将故障恢复时间从15分钟缩短到30秒内。