秒杀系统常见问题—库存超卖

Posted 2023-05-29 远猷

大家好！我是sum墨，一个一线的底层码农，平时喜欢研究和思考一些技术相关的问题并整理成文，限于本人水平，如果文章和代码有表述不当之处，还请不吝赐教。

以下是正文！

先看问题

首先上一串代码

public String buy(Long goodsId, Integer goodsNum) 
    //查询商品库存
    Goods goods = goodsMapper.selectById(goodsId);
    //如果当前库存为0，提示商品已经卖光了
    if (goods.getGoodsInventory() <= 0) 
        return "商品已经卖光了！";
    
    //如果当前购买数量大于库存，提示库存不足
    if (goodsNum > goods.getGoodsInventory()) 
        return "库存不足！";
    
    //更新库存
    goods.setGoodsInventory(goods.getGoodsInventory() - goodsNum);
    goodsMapper.updateById(goods);
    return "购买成功！";

我们看一下这串代码，逻辑用流程图表示如下：

从图上看，逻辑还是很清晰明了的，而且单测的话，也测试不出来什么bug。但是在秒杀场景下，问题可就大发了，100件商品可能卖出1000单，出现超卖问题，这下就真的需要杀个程序员祭天了。

问题分析

正常情况下，如果请求是一个一个接着来的话，这串代码也不会有问题，如下图：

不同的时刻不同的请求，每次拿到的商品库存都是更新过之后的，逻辑是ok的。

那为啥会出现超卖问题呢？
首先我们给这串代码增加一个场景：商品秒杀（非秒杀场景难以复现超卖问题）。
秒杀场景的特点如下：

• 高并发处理：秒杀场景下，可能会有大量的购物者同时涌入系统，因此需要具备高并发处理能力，保证系统能够承受高并发访问，并提供快速的响应。
• 快速响应：秒杀场景下，由于时间限制和竞争激烈，需要系统能够快速响应购物者的请求，否则可能会导致购买失败，影响购物者的购物体验。
• 分布式系统： 秒杀场景下，单台服务器扛不住请求高峰，分布式系统可以提高系统的容错能力和抗压能力，非常适合秒杀场景。

在这种场景下，请求不可能是一个接一个这种，而是成千上万个请求同时打过来，那么就会出现多个请求在同一时刻查询库存，如下图：

如果在同一时刻查询商品库存表，那么得到的商品库存也肯定是相同的，判断的逻辑也是相同的。

举个例子，现在商品的库存是10件，请求1买6件，请求2买5件，由于两次请求查询到的库存都是10，肯定是可以卖的。
但是真实情况是5+6=11>10，明显有问题好吧！这两笔请求必然有一笔失败才是对的！

那么，这种问题怎么解决呢？

问题解决

从上面例子来看，问题好像是由于我们每次拿到的库存都是一样的，才导致库存超卖问题，那是不是只要保证每次拿到的库存都是最新的话，这个问题不就迎刃而解了吗！

在说方案前，先把我的测试表结构贴出来：

CREATE TABLE `t_goods` (
  `id` bigint NOT NULL COMMENT \'物理主键\',
  `goods_name` varchar(64) DEFAULT NULL COMMENT \'商品名称\',
  `goods_pic` varchar(255) DEFAULT NULL COMMENT \'商品图片\',
  `goods_desc` varchar(255) DEFAULT NULL COMMENT \'商品描述信息\',
  `goods_inventory` int DEFAULT NULL COMMENT \'商品库存\',
  `goods_price` decimal(10,2) DEFAULT NULL COMMENT \'商品价格\',
  `create_time` datetime DEFAULT NULL COMMENT \'创建时间\',
  `update_time` datetime DEFAULT NULL COMMENT \'更新时间\',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

方法一、redis分布式锁

Redisson介绍

官方介绍：Redisson是一个基于Redis的Java驻留内存数据网格（In-Memory Data Grid）。它封装了Redis客户端API，并提供了一个分布式锁、分布式集合、分布式对象、分布式Map等常用的数据结构和服务。Redisson支持Java 6以上版本和Redis 2.6以上版本，并且采用编解码器和序列化器来支持任何对象类型。 Redisson还提供了一些高级功能，比如异步API和响应式流式API。它可以在分布式系统中被用来实现高可用性、高性能、高可扩展性的数据处理。

Redisson使用

引入

<!--使用redisson作为分布式锁-->
<dependency>
    <groupId>org.redisson</groupId>
    <artifactId>redisson</artifactId>
    <version>3.16.8</version>
</dependency>

注入对象

RedissonConfig.java

import org.redisson.Redisson;
import org.redisson.api.RedissonClient;
import org.redisson.config.Config;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class RedissonConfig 
    /**
     * 所有对Redisson的使用都是通过RedissonClient对象
     *
     * @return
     */
    @Bean(destroyMethod = "shutdown")
    public RedissonClient redissonClient() 
        // 创建配置 指定redis地址及节点信息
        Config config = new Config();
        config.useSingleServer().setAddress("redis://127.0.0.1:6379").setPassword("123456");

        // 根据config创建出RedissonClient实例
        RedissonClient redissonClient = Redisson.create(config);
        return redissonClient;

    

代码优化

public String buyRedisLock(Long goodsId, Integer goodsNum) 
    RLock lock = redissonClient.getLock("goods_buy");
    try 
        //加分布式锁
        lock.lock();
        //查询商品库存
        Goods goods = goodsMapper.selectById(goodsId);
        //如果当前库存为0，提示商品已经卖光了
        if (goods.getGoodsInventory() <= 0) 
                return "商品已经卖光了！";
        
        //如果当前购买数量大于库存，提示库存不足
        if (goodsNum > goods.getGoodsInventory()) 
                return "库存不足！";
        
        //更新库存
        goods.setGoodsInventory(goods.getGoodsInventory() - goodsNum);
        goodsMapper.updateById(goods);
        return "购买成功！";
     catch (Exception e) 
        log.error("秒杀失败");
     finally 
        lock.unlock();
    
    return "购买失败";

加上Redisson分布式锁之后，使得请求由异步变为同步，让购买操作一个一个进行，解决了库存超卖问题，但是会让用户等待的时间加长，影响了用户体验。

方法二、MySQL的行锁

行锁介绍

MySQL的行锁是一种针对行级别数据的锁，它可以锁定某个表中的某一行数据，以保证在锁定期间，其他事务无法修改该行数据，从而保证数据的一致性和完整性。
特点如下：

• MySQL的行锁只能在InnoDB存储引擎中使用。
• 行锁需要有索引才能实现，否则会自动锁定整张表。
• 可以通过使用“SELECT ... FOR UPDATE”和“SELECT ... LOCK IN SHARE MODE”语句来显式地使用行锁。

总之，行锁可以有效地保证数据的一致性和完整性，但是过多的行锁也会导致性能问题，因此在使用行锁时需要谨慎考虑，避免出现性能瓶颈。

那么回到库存超卖这个问题上来，我们可以在一开始查询商品库存的时候增加一个行锁，实现非常简单，也就是将

 //查询商品库存
Goods goods = goodsMapper.selectById(goodsId);

原始查询SQL
SELECT *
  FROM t_goods
  WHERE id = #goodsId

改写为
 SELECT *
  FROM t_goods
  WHERE id = #goodsId for update

那么被查询到的这行商品库存信息就会被锁住，其他请求想要读取这行数据时就需要等待当前请求结束了，这样就做到了每次查询库存都是最新的。不过同Redisson分布式锁一样，会让用户等待的时间加长，影响用户体验。

方法三、乐观锁

乐观锁机制类似java中的cas机制，在查询数据的时候不加锁，只有更新数据的时候才比对数据是否已经发生过改变，没有改变则执行更新操作，已经改变了则进行重试。

商品表增加version字段并初始化数据为0

`version` int(11) DEFAULT NULL COMMENT \'版本\'

将更新SQL修改如下

update t_goods
set goods_inventory = goods_inventory - #goodsNum,
     version         = version + 1
where id = #goodsId
and version = #version

Java代码修改如下

public String buyVersion(Long goodsId, Integer goodsNum) 
    //查询商品库存(该语句使用了行锁)
    Goods goods = goodsMapper.selectById(goodsId);
    //如果当前库存为0，提示商品已经卖光了
    if (goods.getGoodsInventory() <= 0) 
        return "商品已经卖光了！";
    
    if (goodsMapper.updateInventoryAndVersion(goodsId, goodsNum, goods.getVersion()) > 0) 
      return "购买成功！";
    
    return "库存不足！";

通过增加了版本号的控制，在扣减库存的时候在where条件进行版本号的比对。实现查询的是哪一条记录，那么就要求更新的是哪一条记录，在查询到更新的过程中版本号不能变动，否则更新失败。

方法四、where条件和unsigned 非负字段限制

前面的两种办法是通过每次都拿到最新的库存从而解决超卖问题，那换一种思路：保证在扣除库存的时候，库存一定大于购买量是不是也可以解决这个问题呢？
答案是可以的。回到上面的代码：

 //更新库存
goods.setGoodsInventory(goods.getGoodsInventory() - goodsNum);
goodsMapper.updateById(goods);

我们把库存的扣减写在了代码中，这样肯定是不行的，因为在分布式系统中我们获取到的库存可能都是一样的，应该把库存的扣减逻辑放到SQL中，即：

 update t_goods
 set goods_inventory = goods_inventory - #goodsNum
 where id = #goodsId

上面的SQL保证了每次获取的库存都是取数据库的库存，不过我们还需要加一个判断：保证库存大于购买量，即：

update t_goods
set goods_inventory = goods_inventory - #goodsNum
where id = #goodsId
AND (goods_inventory - #goodsNum) >= 0

那么上面那段Java代码也需修改一下：

public String buySqlUpdate(Long goodsId, Integer goodsNum) 
    //查询商品库存(该语句使用了行锁)
    Goods goods = goodsMapper.queryById(goodsId);
    //如果当前库存为0，提示商品已经卖光了
    if (goods.getGoodsInventory() <= 0) 
        return "商品已经卖光了！";
    
    //此处需要判断更新操作是否成功
    if (goodsMapper.updateInventory(goodsId, goodsNum) > 0) 
        return "购买成功！";
     
    return "库存不足！";

还有一种办法和where条件一样，就是unsigned 非负字段限制，把库存字段设置为unsigned 非负字段类型，那么在扣减时也不会出现扣成负数的情况。

总结一下

解决方案	优点	缺点
redis分布式锁	Redis分布式锁可以解决分布式场景下的锁问题，保证多个节点对同一资源的访问顺序和安全性，性能较高。	单点故障问题，如果Redis节点宕机，会导致锁失效。
MySQL的行锁	可以保证事务的隔离性，能够避免并发情况下的数据冲突问题。	性能较低，对数据库的性能影响较大，同时也存在死锁问题。
乐观锁	相对于悲观锁，乐观锁不会阻塞线程，性能较高。	需要额外的版本控制字段，且在高并发情况下容易出现并发冲突问题。
where条件和unsigned 非负字段限制	可以通过where条件和unsigned非负字段限制来保证库存不会超卖，简单易实现。	可能存在一定的安全隐患，如果某些操作没有正确限制，仍有可能导致库存超卖问题。同时，如果某些场景需要对库存进行多次更新操作，限制条件可能会导致操作失败，需要再次查询数据，对性能会产生影响。

方案有很多，用法结合实际业务来看，没有最优，只有更优。

全文至此结束，再会！

秒杀系统是如何防止超卖的？

秒杀系统

秒杀系统介绍

秒杀系统相信网上已经介绍了很多了，我也不想黏贴很多定义过来了。

废话少说，秒杀系统主要应用在商品抢购的场景，比如：

• 电商抢购限量商品

• 卖周董演唱会的门票

• 火车票抢座

• …

秒杀系统抽象来说就是以下几个步骤：

• 用户选定商品下单

• 校验库存

• 扣库存

• 创建用户订单

• 用户支付等后续步骤…

听起来就是个用户买商品的流程而已嘛，确实，所以我们为啥要说他是个专门的系统呢。。

为什么要做所谓的“系统”

如果你的项目流量非常小，完全不用担心有并发的购买请求，那么做这样一个系统意义不大。

但如果你的系统要像12306那样，接受高并发访问和下单的考验，那么你就需要一套完整的流程保护措施，来保证你系统在用户流量高峰期不会被搞挂了。（就像12306刚开始网络售票那几年一样）

这些措施有什么呢：

• 严格防止超卖：库存100件你卖了120件，等着辞职吧

• 防止黑产：防止不怀好意的人群通过各种技术手段把你本该下发给群众的利益全收入了囊中。

我们先从“防止超卖”开始吧

毕竟，你网页可以卡住，最多是大家没参与到活动，上网口吐芬芳，骂你一波。但是你要是卖多了，本该拿到商品的用户可就不乐意了，轻则投诉你，重则找漏洞起诉赔偿。让你吃不了兜着走。

不能再说下去了，我这篇文章可是打着实战文章的名头，为什么我老是要讲废话啊啊啊啊啊啊。

上代码。

说好的做“简易”的秒杀系统，所以我们只用最简单的SpringBoot项目

建立“简易”的数据库表结构

一开始我们先来张最最最简易的结构表，参考了crossoverjie的秒杀系统文章。

等未来我们需要解决更多的系统问题，再扩展表结构。

一张库存表stock，一张订单表stock_order

-- ----------------------------
-- Table structure for stock
-- ----------------------------
DROP TABLE IF EXISTS `stock`;
CREATE TABLE `stock` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(50) NOT NULL DEFAULT '' COMMENT '名称',
  `count` int(11) NOT NULL COMMENT '库存',
  `sale` int(11) NOT NULL COMMENT '已售',
  `version` int(11) NOT NULL COMMENT '乐观锁，版本号',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

-- ----------------------------
-- Table structure for stock_order
-- ----------------------------
DROP TABLE IF EXISTS `stock_order`;
CREATE TABLE `stock_order` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `sid` int(11) NOT NULL COMMENT '库存ID',
  `name` varchar(30) NOT NULL DEFAULT '' COMMENT '商品名称',
  `create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '创建时间',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

通过HTTP接口发起一次购买请求

代码中我们采用最传统的Spring MVC+Mybaits的结构

结构如下图：

Controller层代码

提供一个HTTP接口: 参数为商品的Id

@RequestMapping("/createWrongOrder/{sid}")
@ResponseBody
public String createWrongOrder(@PathVariable int sid) {
    LOGGER.info("购买物品编号sid=[{}]", sid);
    int id = 0;
    try {
        id = orderService.createWrongOrder(sid);
        LOGGER.info("创建订单id: [{}]", id);
    } catch (Exception e) {
        LOGGER.error("Exception", e);
    }
    return String.valueOf(id);
}

Service层代码

@Override
public int createWrongOrder(int sid) throws Exception {
    //校验库存
    Stock stock = checkStock(sid);
    //扣库存
    saleStock(stock);
    //创建订单
    int id = createOrder(stock);
    return id;
}

private Stock checkStock(int sid) {
    Stock stock = stockService.getStockById(sid);
    if (stock.getSale().equals(stock.getCount())) {
        throw new RuntimeException("库存不足");
    }
    return stock;
}

private int saleStock(Stock stock) {
    stock.setSale(stock.getSale() + 1);
    return stockService.updateStockById(stock);
}

private int createOrder(Stock stock) {
    StockOrder order = new StockOrder();
    order.setSid(stock.getId());
    order.setName(stock.getName());
    int id = orderMapper.insertSelective(order);
    return id;
}

发起并发购买请求

我们通过JMeter（https://jmeter.apache.org/） 这个并发请求工具来模拟大量用户同时请求购买接口的场景。

注意：POSTMAN并不支持并发请求，其请求是顺序的，而JMeter是多线程请求。希望以后PostMan能够支持吧，毕竟JMeter还在倔强的用Java UI框架。毕竟是亲儿子呢。

如何通过JMeter进行压力测试，请参考下文，讲的非常入门但详细，包教包会：

https://www.cnblogs.com/stulzq/p/8971531.html

我们在表里添加一个Iphone，库存100。（请忽略订单表里的数据，开始前我清空了）

在JMeter里启动1000个线程，无延迟同时访问接口。模拟1000个人，抢购100个产品的场景。点击启动：

你猜会卖出多少个呢，先想一想。。。

答案是：

卖出了14个，库存减少了14个，但是每个请求Spring都处理了，创建了1000个订单。

我这里该夸Spring强大的并发处理能力，还是该骂MySQL已经是个成熟的数据库，却都不会自己锁库存？

避免超卖问题：更新商品库存的版本号

为了解决上面的超卖问题，我们当然可以在Service层给更新表添加一个事务，这样每个线程更新请求的时候都会先去锁表的这一行（悲观锁），更新完库存后再释放锁。可这样就太慢了，1000个线程可等不及。

我们需要乐观锁。

一个最简单的办法就是，给每个商品库存一个版本号version字段

我们修改代码：

Controller层

/**
 * 乐观锁更新库存
 * @param sid
 * @return
 */
@RequestMapping("/createOptimisticOrder/{sid}")
@ResponseBody
public String createOptimisticOrder(@PathVariable int sid) {
    int id;
    try {
        id = orderService.createOptimisticOrder(sid);
        LOGGER.info("购买成功，剩余库存为: [{}]", id);
    } catch (Exception e) {
        LOGGER.error("购买失败：[{}]", e.getMessage());
        return "购买失败，库存不足";
    }
    return String.format("购买成功，剩余库存为：%d", id);
}

Service层

@Override
public int createOptimisticOrder(int sid) throws Exception {
    //校验库存
    Stock stock = checkStock(sid);
    //乐观锁更新库存
    saleStockOptimistic(stock);
    //创建订单
    int id = createOrder(stock);
    return stock.getCount() - (stock.getSale()+1);
}

private void saleStockOptimistic(Stock stock) {
    LOGGER.info("查询数据库，尝试更新库存");
    int count = stockService.updateStockByOptimistic(stock);
    if (count == 0){
        throw new RuntimeException("并发更新库存失败，version不匹配") ;
    }
}

Mapper

<update id="updateByOptimistic" parameterType="cn.monitor4all.miaoshadao.dao.Stock">
    update stock
    <set>
      sale = sale + 1,
      version = version + 1,
    </set>
    WHERE id = #{id,jdbcType=INTEGER}
    AND version = #{version,jdbcType=INTEGER}
  </update>

我们在实际减库存的SQL操作中，首先判断version是否是我们查询库存时候的version，如果是，扣减库存，成功抢购。如果发现version变了，则不更新数据库，返回抢购失败。

发起并发购买请求

这次，我们能成功吗？

再次打开JMeter，把库存恢复为100，清空订单表，发起1000次请求。

这次的结果是：

卖出去了39个，version更新为了39,同时创建了39个订单。我们没有超卖，可喜可贺。

由于并发访问的原因，很多线程更新库存失败了，所以在我们这种设计下，1000个人真要是同时发起购买，只有39个幸运儿能够买到东西，但是我们防止了超卖。

手速快未必好，还得看运气呀！

OK，今天先到这里，之后我们继续一步步完善这个简易的秒杀系统，它总有从树苗变成大树的那一天！

源码

我会随着文章的更新，一直同步更新项目代码，欢迎关注：

https://github.com/qqxx6661/miaosha

参考

• https://cloud.tencent.com/developer/article/1488059

• https://juejin.im/post/5dd09f5af265da0be72aacbd

• https://crossoverjie.top/%2F2018%2F05%2F07%2Fssm%2FSSM18-seconds-kill%2F

推荐阅读

---

欢迎关注，点个在看