各位读者好，最近笔者学了很多东西，其实都想跟大家进行分享，奈何需要将所学习的知识整理出来需要耗费大量的时间，包括总结，或各种图形以及写代码示例，所以可能更新的速度会比较慢。但大家放心，只要有时间我就会将自己学习的内容总结出来供大家一起学习讨论，有总结的不对的地方大家随时都可以批评指正，毕竟我说的也不全都是对的，希望大家耐心等待。如果你喜欢读者的内容，可以点个关注时刻了解我的动态，同时也欢迎各位小伙伴转发和分享。
前期概述
最近想就秒杀系统做一个梳理和总结，从0到1搭建一个简易的秒杀系统，说实在的，也就经常会听到秒杀系统，笔者还没有真正的自己去搭建过一个秒杀系统，相信很多人跟我一样。所以为了不只是停在听说阶段，我们说干就干，自己搭建一个建议的秒杀系统。我会在里面讲解那些需要注意的地方以及涉及秒杀系统我们需要注意的问题，帮助大家快速了解秒杀系统的难点。同时后期也会将书写的代码给出来链接，供大家下载，代码我会尽量精简干练，供大家学习参考，并且依据参考可以迅速上手实际的项目，后期想要增加更多的功能也可以直接在项目上进行更改即可。
我会分几个阶段进行讲解，尽量做到通俗易懂，以下是我的规划内容（大家看的时候注意顺序）：
- 教你从0到1搭建秒杀系统-防超卖.
- 教你从0到1搭建秒杀系统-限流.
- 教你从0到1搭建秒杀系统-抢购接口隐藏 与单用户限制频率.
- 教你从0到1搭建秒杀系统-缓存与数据库双写一致.
- 教你从0到1搭建秒杀系统-Canal快速入门（番外篇）.
- 教你从0到1搭建秒杀系统-订单异步处理.
秒杀系统简介
本文要讲的就是第一个问题：防超卖。在进行正式问题开始分析之前，我们还是啰嗦的简单介绍一下什么是秒杀系统。相信其实有很多人都知道秒杀，像淘宝，京东等等这些里面的商户一到节日，像什么双11，双12都会整一些活动，免不了有秒杀的活动，在特定的时间范围进行抢购，平时需要几百的东西可能这会只要几十块钱。其实秒杀系统真的有好多，网上对他更专业的定义也有很多，我在这里就只是简单介绍一下，其他的我就不赘述，毕竟这不是
我们要讲解的重点。我们可以将秒杀系统归属为一些场景：
- 电商抢购限量的商品
- 12306春节抢票
- …
这些每一个功能都可以叫做秒杀系统。作为秒杀系统，用户在进行操作了以后，大家有没有想过最终是怎么秒杀成功或者秒杀失败的呢？可能有的人会有这样的疑惑，在这里不管你是想要设计秒杀系统的人还是想要搞清楚你作为买家最终是怎么成功秒杀或者失败的，相信你看了这几篇文章以后都可以说出个所以然来。这整体的处理逻辑可以抽象成以下几个步骤：
- 用户选定商品下单
- 校验库存
- 扣库存
- 创建用户订单
- 用户支付等
- 后续步骤…
我说的只是一种秒杀系统的设计方案，其实对于不同的场景，有的公司设计的秒杀系统可能步骤有所不同，有的可能最终才会扣库存。其实不管怎么操作，这些基本的步骤都是需要的，在这里我就以我上面写出的步骤逻辑进行讲解。
也许你看到这里有一个疑惑，这整体就是个用户买商品的流程而已啊，为啥要说它是个专门的系统呢？如果你的项目流量非常小，完全不用担心有并发的购买请求，那么做这样一个系统的确意义不大。但如果你的系统要像12306那样，接受高并发访问和下单的考验，那么你就需要一套完整的流程保护措施，来保证你系统在用户流量高峰期不会被搞挂了。
防超卖
好了，废话不多说，我们接下来从防止超卖开始直接搭建项目进行实际操作。这里只是搭建简易的秒杀系统，我们采用最传统的Spring MVC+Mybaits的结构。
建立数据库表结构
说了是简易的秒杀系统，所以我们先来张最最最简易的结构表，等未来我们需要解决更多的系统问题，再扩展表结构。我们定义两张表，一张库存表stock，一张订单表stock_order，相关SQL如下：
-- ----------------------------
-- 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;
项目结构
怎么创建一个项目我这里就不一步步带大家去创建了，这里给大家展示一下项目的整体结构图：
典型的MCV模式。
项目代码
Controller层代码，提供一个HTTP接口，参数为商品的Id：
@RequestMapping("/createWrongOrder/{sid}")
@ResponseBody
public String createWrongOrder(@PathVariable int 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/） 这个并发请求工具来模拟大量用户同时请求购买接口的场景。我们在表里添加一个Iphone，库存100。在JMeter里启动1000个线程，无延迟同时访问接口，模拟1000个人，抢购100个产品的场景。点击启动：
最后执行完以后，我们查询数据如下：
卖出了56个，库存减少了56个，但是每个请求都处理了，创建了1000个订单。这显然是不对的。我们需要的是卖出100个，不多也不少才能保证我们的收益。由此看来之前的设计是有问题的。既然没有卖出去那么多就不应该创建那么多的订单。
为了解决上面的超卖问题，我们可以在Service层给更新表添加一个事务，这样每个线程更新请求的时候都会先去锁表的这一行（悲观锁），更新完库存后再释放锁。可这样就太慢了。我们需要乐观锁，个最简单的办法就是，给每个商品库存一个版本号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中updateByOptimistic方法的代码如下：
<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变了，则不更新数据库，返回抢购失败。
修改之后，我们跟之前一样再重新发起请求（首先清空之前的数据，将库存格式化重新设置为100，卖出为0）：
可以看到，最终卖出去了45个，version更新为了45，同时创建了45个订单，此时没有超卖，不会创建多余的订单了。
由于并发访问的原因，很多线程更新库存失败了，所以在我们这种设计下，1000个人真要是同时发起购买，只有39个幸运儿能够买到东西，我们虽然防止了超卖。但是实际上需要卖出100个商品，那剩余的没有卖出去的话就会造成利益的减少，这样也是不可以的。那么怎么保证在不超卖的同时还可以卖出给定数量的商品呢？我们在下一篇文章中跟大家讲解。
猜你感兴趣：
教你从0到1搭建秒杀系统-防超卖
教你从0到1搭建秒杀系统-限流
教你从0到1搭建秒杀系统-抢购接口隐藏与单用户限制频率
教你从0到1搭建秒杀系统-缓存与数据库双写一致
教你从0到1搭建秒杀系统-Canal快速入门（番外篇）
教你从0到1搭建秒杀系统-订单异步处理
更多文章请点击：更多…
参考文章：
https://cloud.tencent.com/developer/article/148805
https://juejin.im/post/5dd09f5af265da0be72aacbd
https://crossoverjie.top/%2F2018%2F05%2F07%2Fssm%2FSSM18-seconds-kill%2F
1414
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
