大厂防止商品超卖的五种方案！

前言

"快看我们的大厂的种秒杀系统！库存显示-500了！防止方案"

3年前的商品这个电话让我记忆犹新。

当时某电商大促，超卖我们自认为完美的大厂的种分布式架构，在0点整瞬间被击穿。防止方案

数据库连接池耗尽，商品库存表出现负数，超卖客服电话被打爆...

1.为什么会发生超卖？大厂的种

首先我们一起看看为什么会发送超卖？

（1）数据库的"最后防线"漏洞

我们用下面的列子，给大家介绍一下商品超卖是防止方案如何发生的。

复制-- 危险的商品更新语句 UPDATE product SET stock = stock -1 WHERE id=123 AND stock>0;1.2.3.

上面这条看似安全的SQL，在并发场景下可能变成下图这样的超卖：

请求1和请求2都将库存更新成9。

根本原因：数据库的大厂的种更新操作不是原子性校验，多个事务可能同时通过stock>0的云服务器提供商防止方案条件检查。

（2）超卖的商品本质

商品超卖的本质是：多个请求同时穿透缓存，同一时刻读取到相同库存值，最终在数据库层发生覆盖。

就像100个人同时看上一件衣服，都去试衣间前看了眼牌子，出来时都觉得自己应该拿到那件衣服。

2.防止超卖的方案

（1）数据库乐观锁

数据库乐观锁的核心原理是通过版本号控制并发。

例如下面这样的：

复制UPDATE product SET stock = stock -1, version=version+1 WHERE id=123 AND version=#{currentVersion};1.2.3.

Java的实现代码如下：

复制@Transactional public boolean deductStock(Long productId) { Product product = productDao.selectForUpdate(productId); if (product.getStock() <= 0) return false; int affected = productDao.updateWithVersion( productId, product.getVersion(), product.getStock()-1 ); return affected > 0; }1.2.3.4.5.6.7.8.9.10.11.12.

基于数据库乐观锁方案的架构图如下：

优缺点分析：

优点

缺点

无需额外中间件

高并发时DB压力大

实现简单

可能出现大量更新失败

适用场景：日订单量1万以下的中小系统。

（2）Redis原子操作

Redis原子操作的核心原理是使用：Redis + Lua脚本。

核心代码如下：

复制// Lua脚本保证原子性 String lua = "if redis.call(get, KEYS >= ARGV[1] then " + "return redis.call(decrby, KEYS[1], ARGV " + "else return -1 end"; public boolean preDeduct(String itemId, int count) { RedisScript<Long> script = new DefaultRedisScript<>(lua, Long.class); Long result = redisTemplate.execute(script, Collections.singletonList(itemId), count); return result != null && result >= 0; }1.2.3.4.5.6.7.8.9.10.11.

该方案的架构图如下：

性能对比：

单节点QPS：数据库方案500 vs Redis方案8万响应时间：<1ms vs 50ms+

（3）分布式锁

目前最常用的分布式锁的方案是Redisson。

下面是Redisson的站群服务器实现：

复制RLock lock = redisson.getLock("stock_lock:"+productId); try { if (lock.tryLock(1, 10, TimeUnit.SECONDS)) { // 执行库存操作 } } finally { lock.unlock(); }1.2.3.4.5.6.7.8. 注意事项锁粒度要细化到商品级别必须设置等待时间和自动释放配合异步队列使用效果更佳

该方案的架构图如下：

（4）消息队列削峰

可以使用 RocketMQ的事务消息。

核心代码如下：

复制// RocketMQ事务消息示例 TransactionMQProducer producer = new TransactionMQProducer("stock_group"); producer.setExecutor(new TransactionListener() { @Override public LocalTransactionState executeLocalTransaction(Message msg) { // 扣减数据库库存 return LocalTransactionState.COMMIT_MESSAGE; } });1.2.3.4.5.6.7.8.9.

该方案的架构图如下：

技术指标：

削峰能力：10万QPS → 2万TPS订单处理延迟：<1秒（正常时段）

（5）预扣库存

预扣库存是防止商品超卖的终极方案。

核心算法如下：

复制// Guava RateLimiter限流 RateLimiter limiter = RateLimiter.create(1000); // 每秒1000个令牌 public boolean preDeduct(Long itemId) { if (!limiter.tryAcquire()) return false; // 写入预扣库存表 preStockDao.insert(itemId, userId); return true; }1.2.3.4.5.6.7.8.9.10.

该方案的架构图如下：

性能数据：

百万级并发支撑能力库存准确率99.999%订单处理耗时200ms内

3.避坑指南

（1）缓存与数据库不一致

某次大促因缓存未及时失效，导致超卖1.2万单。

错误示例如下：

复制// 错误示例：先删缓存再写库 redisTemplate.delete("stock:"+productId); productDao.updateStock(productId, newStock); // 存在并发写入窗口1.2.3.

（2）未考虑库存回滚

秒杀取消后，忘记恢复库存，引发后续超卖。

正确做法是使用事务补偿。

例如下面这样的：

复制@Transactional public void cancelOrder(Order order) { stockDao.restock(order.getItemId(), order.getCount()); orderDao.delete(order.getId()); }1.2.3.4.5.

库存回滚和订单删除，在同一个事务中。

（3）锁粒度过大

锁粒度过大，全局限流导致10%的请求被误杀。

错误示例如下：

复制// 错误示例：全局限锁 RLock globalLock = redisson.getLock("global_stock_lock");1.2.

总结

其实在很多大厂中，一般会将防止商品超卖的多种方案组合使用。

架构图如下：

通过组合使用：

Redis做第一道防线（承受80%流量）分布式锁控制核心业务逻辑预扣库存+消息队列保证最终一致性

实战经验：某电商在2023年双11中：

Redis集群承载98%请求分布式锁拦截异常流量预扣库存保证最终准确性

系统平稳支撑了每秒12万次秒杀请求，0超卖事故发生！

记住：没有银弹方案，只有适合场景的组合拳！企商汇

本文地址：http://www.bzve.cn/news/63e3099906.html