【秒杀系统】从零开始打造简易秒杀系统（一）：防止超卖

前言

大家好，好久不发文章了。（快一个月了- -）最近有很多学习的新知识想和大家分享，但无奈最近项目蛮忙的，很多文章写了一半搁置在了笔记里，待以后慢慢补充发布。

本文主要是通过实际代码讲解，帮助你一步步搭建一个简易的秒杀系统。从而快速的了解秒杀系统的主要难点，并且迅速上手实际项目。

我对秒杀系统文章的规划：

• 从零开始打造简易秒杀系统：乐观锁防止超卖
• 从零开始打造简易秒杀系统：令牌桶限流
• 从零开始打造简易秒杀系统：Redis 缓存
• 从零开始打造简易秒杀系统：消息队列异步处理订单
• ...

欢迎关注我的公众号：后端技术漫谈（二维码见底部）

秒杀系统

秒杀系统介绍

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

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

• 电商抢购限量商品
• 卖周董演唱会的门票
• 火车票抢座
• ...

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

• 用户选定商品下单
• 校验库存
• 扣库存
• 创建用户订单
• 用户支付等后续步骤...

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

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

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

但如果你的系统要像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

关注我

我是一名后端开发工程师。

主要关注后端开发，数据安全，物联网，边缘计算方向，欢迎交流。

各大平台都可以找到我

• 微信公众号：后端技术漫谈
• Github：@qqxx6661
• CSDN：@Rude3knife
• 知乎：@后端技术漫谈
• 简书：@蛮三刀把刀
• 掘金：@蛮三刀把刀

原创博客主要内容

• 后端开发技术
• Java面试知识点
• 设计模式/数据结构
• LeetCode/剑指offer 算法题解析
• SpringBoot/SpringCloud入门实战系列
• 数据分析/数据爬虫
• 逸闻趣事/好书分享/个人生活

个人公众号：后端技术漫谈

如果文章对你有帮助，不妨收藏，转发，在看起来~