为什么你的库存总被“薅秃”？
“上架100台手机，订单却显示卖出120台”——这是某电商团队在去年双11的真实事故。技术负责人老张熬了三个通宵，才从投诉和赔偿的泥潭里爬出来。
高并发下的库存超卖，就像一场没有硝烟的战争。每秒数万次请求涌向系统，数据库在颤抖，Redis在尖叫，程序员在崩溃。但别慌！经过多年实战，我们总结出七种武器，帮你构建坚不可摧的库存防线。
七大防御体系：从青铜到王者的进阶之路
方法1：数据库的“铁锁横江”——悲观锁与乐观锁
场景：适合中小流量场景（QPS<1000）
- 悲观锁（SELECT FOR UPDATE）： 像保镖一样提前锁定数据，确保同一时刻只有一个线程能修改库存。但代价是性能腰斩，10个并发就可能让响应时间突破1秒。
// 示例：MySQL行级锁
@Transactional
public 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预测，每一次技术升级都是血与火的淬炼。记住：最好的方案，永远是经历过生产环境考验的方案。