为什么你的库存总被“薅秃”？

“上架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监听库存变更，异常时自动回补。

如何选择适合你的方法？

那些年我们踩过的坑

1. 缓存击穿：某次大促因缓存未预热，直接击穿数据库，导致15分钟服务不可用
2. 锁超时：分布式锁未设置超时，系统宕机后库存永远锁死
3. ABA问题：版本号重用导致扣减错乱，改用时间戳后解决

库存超卖防御没有银弹，只有最适合场景的组合拳。从数据库锁到Redis原子操作，从分段锁到AI预测，每一次技术升级都是血与火的淬炼。记住：最好的方案，永远是经历过生产环境考验的方案。