“上架100台手机，订单却显示卖出120台”——这是某电商团队在去年双11的真实事故。技术负责人老张熬了三个通宵，才从投诉和赔偿的泥潭里爬出来。
高并发下的库存超卖，就像一场没有硝烟的战争。每秒数万次请求涌向系统，数据库在颤抖，Redis在尖叫，程序员在崩溃。但别慌！经过多年实战，我们总结出七种武器，帮你构建坚不可摧的库存防线。
七大防御体系：从青铜到王者的进阶之路方法1：数据库的“铁锁横江”——悲观锁与乐观锁场景：适合中小流量场景（QPS<1000）
悲观锁（SELECT FOR UPDATE）： 像保镖一样提前锁定数据，确保同一时刻只有一个线程能修改库存。但代价是性能腰斩，10个并发就可能让响应时间突破1秒。// 示例：MySQL行级锁@Transactionalpublic boolean deductStock(Long productId, int quantity) { // 1. 加锁查询 Product product = productMapper.selectForUpdate(productId); if (product.getStock() >= quantity) { // 2. 扣减库存 productMapper.updateStock(productId, product.getStock() - quantity); return true; } return false;}乐观锁（Version机制）： 用版本号实现“无锁化”竞争。假设冲突少，先查后改，若版本号不匹配则重试。实测在库存充足时，性能比悲观锁高3倍。// 示例：版本号CAS更新UPDATE product SET stock = stock - 1, version = version + 1 WHERE id = #{productId} AND version = #{oldVersion}避坑指南：
悲观锁易导致死锁，需设置超时时间（如innodb_lock_wait_timeout=5s）乐观锁重试次数建议≤3次，避免雪崩方法2：Redis的“原子剑法”——INCR/DECR与Lua脚本场景：适合秒杀级流量（QPS≥1万）
原子操作： Redis的DECR命令天生线程安全，1秒可处理10万次扣减。// 示例：扣减库存（返回剩余库存）Long stock = redisTemplate.opsForValue().decrement("product:1001:stock");if (stock != null && stock >= 0) { // 扣减成功} else { // 库存不足，回滚 redisTemplate.opsForValue().increment("product:1001:stock");}Lua脚本： 打包多个操作为原子执行，避免网络延迟导致的数据不一致。-- 示例：Lua实现库存扣减local stock = tonumber(redis.call('GET', KEYS[1]))if stock >= tonumber(ARGV[1]) then redis.call('DECRBY', KEYS[1], ARGV[1]) return 1 -- 成功else return 0 -- 失败end性能实测：单节点Redis可达5万QPS，集群模式下轻松突破50万QPS。
方法3：分布式锁的“天罗地网”——Redisson与分段锁场景：分布式环境下的库存抢占
Redisson锁： 用Redis实现分布式锁，避免集群环境下超卖。RLock lock = redissonClient.getLock("product:1001:lock");try { if (lock.tryLock(1, 10, TimeUnit.SECONDS)) { // 执行库存扣减 }} finally { lock.unlock();}分段锁优化： 把1000库存拆成10个段（如stock_1~stock_10），并发提升10倍。方法4：消息队列的“化骨绵掌”——削峰填谷术场景：流量洪峰下的系统保护
RabbitMQ/Kafka异步处理： 将扣减请求存入队列，后台匀速消费。某电商用此方案扛住百万QPS。// 示例：订单入队rabbitTemplate.convertAndSend("order_queue", order);// 消费者@RabbitListener(queues = "order_queue")public void processOrder(Order order) { stockService.deductStock(order.getProductId());}效果对比：同步接口RT从200ms降至20ms，系统吞吐量提升5倍。
方法5：库存的“影分身术”——预扣与虚拟库存预扣库存： 用户下单时先扣“虚拟库存”，支付成功再扣真实库存。15分钟未支付则自动释放。分层缓存： JVM本地缓存+Redis集群+数据库，三层防护减少穿透。方法6：熔断与降级的“金钟罩”Sentinel熔断： 当库存服务响应超时≥500ms，自动熔断10秒，避免级联故障。降级策略： 库存不足时返回“排队中”，前端轮询查询状态，避免用户反复提交。方法7：监控的“火眼金睛”——实时预警系统指标监控： Grafana监控库存变化、扣减成功率、Redis连接池状态。自动化补偿： 用Binlog监听库存变更，异常时自动回补。如何选择适合你的方法？场景
推荐方案
适用流量
低频活动（如团购）
数据库乐观锁
QPS<1k
日常秒杀
Redis+Lua脚本
QPS<10万
顶流秒杀（如双11）
分段锁+消息队列+熔断
QPS≥50万
那些年我们踩过的坑缓存击穿：某次大促因缓存未预热，直接击穿数据库，导致15分钟服务不可用锁超时：分布式锁未设置超时，系统宕机后库存永远锁死ABA问题：版本号重用导致扣减错乱，改用时间戳后解决库存超卖防御没有银弹，只有最适合场景的组合拳。从数据库锁到Redis原子操作，从分段锁到AI预测，每一次技术升级都是血与火的淬炼。记住：最好的方案，永远是经历过生产环境考验的方案。
