前言
"快看我们的秒杀系统!库存显示-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[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;
- }
复制代码 该方案的架构图如下:
性能对比:
<ul>单节点QPS:数据库方案500 vs Redis方案8万
响应时间: |