1.业务简单描述
核心业务逻辑：
用户登录进入秒杀商品页面，可以查看商品信息；点击秒杀，判断秒杀开始了吗->判断库存->判断是否重复秒杀，在一个事务中，执行减库存，入订单表两个操作；将秒杀结果反馈给用户。
其他附加功能：
登录校验，所有操作必须要求登录
在最初版本上不断优化，并使用jmeter进行压力测试
表结构：
商品表
订单表
用户表
2.最初版本
2.1查看所有商品
代码说明
/**
* 查看所有商品
*/
@GetMapping(value="/goods1")
public String findAllGoods1(Model model){
List<Goods> goods = goodsService.findAllGoods();
model.addAttribute("goods",goods);
//设置秒杀开始时间 当前时间使用客户端自己的时间
model.addAttribute("targetTime",Constant.BARGAIN_DASH_START_TIME);
return "goods";
}
get请求，从数据库查出所有商品，视图使用thymeleaf，看起来中规中矩。
压测结果
使用jmeter压测一下，看看结果。
未优化的商品列表
5000个线程，立即创建并发起请求，我们看到执行时间为5分35秒，吞吐量为14.9/s，这表现很难让人满意啊。
优化点
看似中规中矩的代码，为什么如此不堪重负呢？
- 每次请求都会从商品表查出所有商品，数据库难以承载高并发。
- thymeleaf其实是服务端的渲染技术，和jsp类似，每个请求都要渲染视图，服务器压力山大。
所以后面就要从这两个方面进行优化处理了。
2.2 秒杀
代码说明
@RequestMapping("/bargainsDash1/{goodsId}")
@ResponseBody
public Object bargainsDash1(@PathVariable("goodsId") int goodsId,User user) {
try {
//获取当前用户id
int userId = user.getId();
//判断秒杀是否开始，因为浏览器倒计时使用的是客户端时间，即使浏览器使用服务端时间进行倒计时，也不能保证绝对没有误差，所以最好还是判断一下
if(System.currentTimeMillis() < Constant.BARGAIN_DASH_START_TIME) {
return Result.fail("秒杀还未开始呢");
}
//判断秒杀商品的库存，如果已经没了，返回 秒杀结束
int stock = goodsService.getStockById(goodsId);
if(stock <= 0) {
return Result.fail("慢了一步，商品已售完");
}
//判断订单表是否已经有记录了，防止重复秒杀
int count = orderService.countOrder1(userId, goodsId);
if(count > 0) {
return Result.fail("请勿重复秒杀，把机会留给其他人吧");
}
//执行秒杀（在一个事务中 1.减库存 2.入订单表）
bargainsDashService.bargainsDash1(userId, goodsId);
//返回订单信息
return Result.success(orderService.findOrderByUser(userId));
}catch(Exception e) {
logger.error("秒杀失败",e);
return Result.fail("服务器开小差了，秒杀失败");
}
}
/**
* 执行秒杀（在一个事务中 1.减库存 2.入订单表）
* @param userId
* @param goodsId
*/
@Transactional
public void bargainsDash1(int userId,int goodsId) {
//减库存
int result = goodsService.reduceStock(goodsId);
//入订单表,这里要真的把库存减一了，才入订单（排除库存已经为0，但因为并没有异常，不会回滚，将会继续执行入库的情况）
if(result ==1) {
orderService.insertOrder(userId, goodsId);
}
}
拦截器判断是否登录->判断秒杀开始了吗？->判断库存->判断是否重复秒杀->在一个事务中减库存，入订单表。看起来没啥问题，不过在多线程下，因为没有做任何同步处理，所以可能会有超卖和重复秒杀的问题。
压测结果
未优化的秒杀
这是解决了同步问题之后，进行的压测。可以看到执行时间为7分18秒，吞吐量为11.4/s，这性能也很差啊。
优化点
- 首先是要解决同步问题，避免超卖和重复秒杀
- 和商品详情页面一样，秒杀时数据库操作太多了，导致性能很差
- 所有请求像洪水一样，瞬间涌入该接口，请求太过集中，实在处理不过来，要限流，削峰才行
后续也将从这三个方面进行优化。
附：所有代码在github上。
