大厂防止超卖的7种实现，很受用！ | 鹿晓鹏的个人日常分享

type

status

date

slug

summary

1. 商品秒杀-超卖

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

控制层：Controller

业务层：Service

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

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

图片

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

2. 解决商品超卖

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

可以在controller层进行加锁

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

2.1 方式一（改进版加锁）

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

并发数1000，商品100

并发数1000，商品1000

并发数2000，商品1000

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

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

图片

2.2 方式二（AOP版加锁）

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

自定义AOP注解

定义切面类

在业务方法上添加AOP注解

控制层：

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

2.3 方式三（悲观锁一）

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

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

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

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

业务逻辑

Dao层

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

2.4 方式四（悲观锁二）

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

Dao层

2.5 方式五（乐观锁）

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

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

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

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

2.6 方式六（阻塞队列）

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

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

消费秒杀队列：实现ApplicationRunner接口

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

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

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

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

图片

2.7.方式七（Disruptor队列）

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

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

3. 小结

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

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

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

六、七方式是通过队列来解决并发问题，这里需要特别注意的8 个线程池最佳实践和坑！使用不当直接生产事故！！是，在代码中不能通过throw抛异常，否则消费线程会终止，而且由于进队和出队存在时间间隙，会导致商品少卖