• 1.引言

• 2.商品秒杀-超卖

• 3.解决商品超卖

• 3.1 方式一（改进版加锁）

• 3.2 方式二（AOP版加锁）

• 3.3 方式三（悲观锁一）

• 3.4 方式四（悲观锁二）

• 3.5 方式五（乐观锁）

• 3.6 方式六（阻塞队列）

• 3.7.方式七（Disruptor队列）

1. 小结

1.引言

高并发场景在现场的日常工作中很常见，特别是在互联网公司中，这篇文章就来通过秒杀商品来模拟高并发的场景。文章末尾会附上文章的所有代码、脚本和测试用例。

• 本文环境：SpringBoot 2.5.7 + MySQL 8.0 X + MybatisPlus + Swagger2.9.2

• 模拟工具：Jmeter

• 模拟场景：减库存->创建订单->模拟支付

2.商品秒杀-超卖

在开发中，对于下面的代码，可能很熟悉：在Service里面加上@Transactional事务注解和Lock锁

控制层：Controller

业务层：Service

对于上面的代码应该没啥问题吧，业务方法上加事务，在处理业务的时候加锁。

但上面这样写法是有问题的，会出现超卖的情况，看下测试结果：模拟1000个并发，抢100商品

这里在业务方法开始加了锁，在业务方法结束后释放了锁。但这里的事务提交却不是这样的，有可能在事务提交之前，就已经把锁释放了，这样会导致商品超卖现象。所以加锁的时机很重要！

3. 解决商品超卖

对于上面超卖现象，主要问题出现在事务中锁释放的时机，事务未提交之前，锁已经释放。（事务提交是在整个方法执行完）。如何解决这个问题呢，就是把加锁步骤提前

• 可以在controller层进行加锁

• 可以使用Aop在业务方法执行之前进行加锁

3.1 方式一（改进版加锁）

上面这样的加锁就可以解决事务未提交之前，锁释放的问题，可以分三种情况进行压力测试：

• 并发数1000，商品100

• 并发数1000，商品1000

• 并发数2000，商品1000

对于并发量大于商品数的情况，商品秒杀一般不会出现少卖的请况，但对于并发数小于等于商品数的时候可能会出现商品少卖情况，这也很好理解。

对于没有问题的情况就不贴图了，因为有很多种方式，贴图会太多

3.2 方式二（AOP版加锁）

对于上面在控制层进行加锁的方式，可能显得不优雅，那就还有另一种方式进行在事务之前加锁，那就是AOP

自定义AOP注解

在业务方法上添加AOP注解

控制层：

这种方式在对锁的使用上，更高阶、更美观！

3.3 方式三（悲观锁一）

除了上面在业务代码层面加锁外，还可以使用数据库自带的锁进行并发控制。

悲观锁，什么是悲观锁呢？通俗的说，在做任何事情之前，都要进行加锁确认。这种数据库级加锁操作效率较低。

使用for update一定要加上事务，当事务处理完后，for update才会将行级锁解除

如果请求数和秒杀商品数量一致，会出现少卖

业务逻辑

Dao层

上面是利用for update进行对查询数据加锁，加的是行锁

3.4 方式四（悲观锁二）

悲观锁的第二种方式就是利用update更新命令来加表锁

Dao层

3.5 方式五（乐观锁）

乐观锁，顾名思义，就是对操作结果很乐观，通过利用version字段来判断数据是否被修改

乐观锁，不进行库存数量的校验，直接做库存扣减

这里使用的乐观锁会出现大量的数据更新异常（抛异常就会导致购买失败）、如果配置的抢购人数比较少、比如120:100(人数:商品) 会出现少买的情况，不推荐使用乐观锁。

乐观锁会出现大量的数据更新异常（抛异常就会导致购买失败），会出现少买的情况，不推荐使用乐观锁

3.6 方式六（阻塞队列）

利用阻塞队类，也可以解决高并发问题。其思想就是把接收到的请求按顺序存放到队列中，消费者线程逐一从队列里取数据进行处理，看下具体代码。

阻塞队列：这里使用静态内部类的方式来实现单例模式，在并发条件下不会出现问题。

注意：在业务层和AOP方法中，不能抛出任何异常， throw new RuntimeException()这些抛异常代码要注释掉。因为一旦程序抛出异常就会停止，导致消费秒杀队列进程终止！

使用阻塞队列来实现秒杀，有几点要注意：

• 消费秒杀队列中调用业务方法加锁与不加锁情况一样，也就是seckillService.startSecondKillByAop()、seckillService.startSecondKillByLock()方法结果一样，这也很好理解

• 当队列长度与商品数量一致时，会出现少卖的现象，可以调大数值

• 下面是队列长度1000，商品数量1000，并发数2000情况下出现的少卖

3.7.方式七（Disruptor队列）

Disruptor是个高性能队列，研发的初衷是解决内存队列的延迟问题，在性能测试中发现竟然与I/O操作处于同样的数量级，基于Disruptor开发的系统单线程能支撑每秒600万订单。

经过测试，发现使用Disruptor队列队列，与自定义队列有着同样的问题，也会出现超卖的情况，但效率有所提高。

4. 小结

对于上面七种实现并发的方式，做一下总结：

• 一、二方式是在代码中利用锁和事务的方式解决了并发问题，主要解决的是锁要加载事务之前

• 三、四、五方式主要是数据库的锁来解决并发问题，方式三是利用for upate对表加行锁，方式四是利用update来对表加锁，方式五是通过增加version字段来控制数据库的更新操作，方式五的效果最差

• 六、七方式是通过队列来解决并发问题，这里需要特别注意的是，在代码中不能通过throw抛异常，否则消费线程会终止，而且由于进队和出队存在时间间隙，会导致商品少卖

上面所有的情况都经过代码测试，测试分一下三种情况：

• 并发数1000，商品数100

• 并发数1000，商品数1000

• 并发数2000，商品数1000