标签：注意 request 创建 wrong 高峰 type ESS webp 请求
秒杀系统
秒杀系统相信网上已经介绍了很多了，我也不想黏贴很多定义过来了。
废话少说，秒杀系统主要应用在商品抢购的场景，比如：
电商抢购限量商品
卖周董演唱会的门票
火车票抢座
…
秒杀系统抽象来说就是以下几个步骤：
用户选定商品下单
校验库存
扣库存
创建用户订单
用户支付等后续步骤…
听起来就是个用户买商品的流程而已嘛，确实，所以我们为啥要说他是个专门的系统呢。。
如果你的项目流量非常小，完全不用担心有并发的购买请求，那么做这样一个系统意义不大。
但如果你的系统要像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;
代码中我们采用最传统的Spring MVC+Mybaits的结构
结构如下图：
提供一个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);
}
@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字段
我们修改代码：
/**
* 乐观锁更新库存
* @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);
}
@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不匹配") ;
}
}
<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
标签：注意 request 创建 wrong 高峰 type ESS webp 请求
原文地址：https://www.cnblogs.com/jljg/p/12522022.html
