1.秒杀-初始版本

1.业务简单描述

核心业务逻辑：
用户登录进入秒杀商品页面，可以查看商品信息；点击秒杀，判断秒杀开始了吗->判断库存->判断是否重复秒杀，在一个事务中，执行减库存，入订单表两个操作；将秒杀结果反馈给用户。

其他附加功能：
登录校验，所有操作必须要求登录
在最初版本上不断优化，并使用jmeter进行压力测试

表结构：

商品表

订单表

用户表

2.最初版本

2.1查看所有商品

代码说明

/**
 * 查看所有商品
 */
@GetMapping(value="/goods1")
public String findAllGoods1(Model model){
    List 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，这表现很难让人满意啊。
优化点
看似中规中矩的代码，为什么如此不堪重负呢？

1. 每次请求都会从商品表查出所有商品，数据库难以承载高并发。
2. 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，这性能也很差啊。
优化点

1. 首先是要解决同步问题，避免超卖和重复秒杀
2. 和商品详情页面一样，秒杀时数据库操作太多了，导致性能很差
3. 所有请求像洪水一样，瞬间涌入该接口，请求太过集中，实在处理不过来，要限流，削峰才行

后续也将从这三个方面进行优化。

附：所有代码在github上。