高并发下如何防止商品超卖？
前言"快看我们的秒杀系统！库存显示-500了！"
3年前的这个电话让我记忆犹新。
当时某电商大促，我们自认为完美的分布式架构，在0点整瞬间被击穿。
数据库连接池耗尽，库存表出现负数，客服电话被打爆...
今天这篇文章跟大家一起聊聊商品超卖的问题，希望对你会有所帮助。
1 为什么会发生超卖？
首先我们一起看看为什么会发送超卖？
1.1 数据库的"最后防线"漏洞
我们用下面的列子，给大家介绍一下商品超卖是如何发生的。
public boolean buy(int goodsId) {
// 1. 查询库存
int stock = getStockFromDatabase(goodsId);
if (stock > 0) {
// 2. 扣减库存
updateStock(goodsId, stock - 1);
return true;
}
return false;
}在并发场景下可能变成下图这样的：
请求1和请求2都将库存更新成9。
根本原因：数据库的查询和更新操作，不是原子性校验，多个事务可能同时通过stock>0的条件检查。
1.2 超卖的本质
商品超卖的本质是：多个请求同时穿透缓存，同一时刻读取到相同库存值，最终在数据库层发生覆盖。
就像100个人同时看上一件衣服，都去试衣间前看了眼牌子，出来时都觉得自己应该拿到那件衣服。
2 防止超卖的方案
2.1 数据库乐观锁
数据库乐观锁的核心原理是通过版本号控制并发。
例如下面这样的：
UPDATE product
SET stock = stock -1, version=version+1
WHERE id=123 AND version=#{currentVersion};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;
}基于数据库乐观锁方案的架构图如下：
优缺点分析：
优点缺点无需额外中间件高并发时DB压力大实现简单可能出现大量更新失败适用场景：日订单量1万以下的中小系统。
2.2 Redis原子操作
Redis原子操作的核心原理是使用：Redis + Lua脚本。
核心代码如下：
// Lua脚本保证原子性
String lua = "if redis.call('get', KEYS >= ARGV then " +
"return redis.call('decrby', KEYS, 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;
}该方案的架构图如下：
性能对比：
<ul>单节点QPS：数据库方案500 vs Redis方案8万
响应时间：
页:
[1]