声明：部分内容截取自大厂防止超卖的7种实现，很受用！
1. 商品秒杀-超卖
1.1 超卖现象说明
在开发中，对于下面的代码，可能很熟悉：在Service里面加上@Transactional事务注解和Lock锁。
控制层：Controller
@ApiOperation(value="秒杀实现方式——Lock加锁")
@PostMapping("/start/lock")
public Result startLock(long skgId){
try {
log.info("开始秒杀方式一...");
final long userId = (int) (new Random().nextDouble() * (99999 - 10000 + 1)) + 10000;
Result result = secondKillService.startSecondKillByLock(skgId, userId);
if(result != null){
log.info("用户:{}--{}", userId, result.get("msg"));
}else{
log.info("用户:{}--{}", userId, "哎呦喂，人也太多了，请稍后！");
}
} catch (Exception e) {
e.printStackTrace();
} finally {
}
return Result.ok();
}
业务层：Service
@Override
@Transactional(rollbackFor = Exception.class)
public Result startSecondKillByLock(long skgId, long userId) {
lock.lock();
try {
// 校验库存
SecondKill secondKill = secondKillMapper.selectById(skgId);
Integer number = secondKill.getNumber();
if (number > 0) {
// 扣库存
secondKill.setNumber(number - 1);
secondKillMapper.updateById(secondKill);
// 创建订单
SuccessKilled killed = new SuccessKilled();
killed.setSeckillId(skgId);
killed.setUserId(userId);
killed.setState((short) 0);
killed.setCreateTime(new Timestamp(System.currentTimeMillis()));
successKilledMapper.insert(killed);
// 模拟支付
Payment payment = new Payment();
payment.setSeckillId(skgId);
payment.setSeckillId(skgId);
payment.setUserId(userId);
payment.setMoney(40);
payment.setState((short) 1);
payment.setCreateTime(new Timestamp(System.currentTimeMillis()));
paymentMapper.insert(payment);
} else {
return Result.error(SecondKillStateEnum.END);
}
} catch (Exception e) {
throw new ScorpiosException("异常了个乖乖");
} finally {
lock.unlock();
}
return Result.ok(SecondKillStateEnum.SUCCESS);
}
对于上面的代码应该没啥问题吧，业务方法上加事务，在处理业务的时候加锁。
但上面这样写法是有问题的，会出现超卖的情况，看下测试结果：模拟1000个并发，抢100商品。
1.2 超卖原因
这里在业务方法开始加了锁，在业务方法结束后释放了锁。但这里的事务提交却不是这样的，有可能在事务提交之前，就已经把锁释放了，这样会导致商品超卖现象。所以加锁的时机很重要！
1.3 Q&A
1.3.1 为什么又要开启事务，又要加锁？
事务主要是为了保证数据的一致性。在秒杀场景中，可能会涉及到减库存、增加销量、生成订单等一系列操作，这些操作要么都成功，要么都失败，这就需要用到事务来保证。加锁则是为了解决并发问题，防止同一时间有多个线程操作同一资源导致的数据不一致。
1.3.2 为什么锁提前释放会导致事物执行不正确？
锁的作用是为了保证在同一时间只有一个线程能操作某一资源。如果在事务提交之前就释放了锁，那么在事务提交的那一刹那，其他线程可能会开始操作这个资源，导致数据不一致(比如读数据时可能读取到mvcc的旧版本数据)。这就是所谓的“临界区竞态条件”。
1.3.3 执行上面的代码，为什么1000个线程执行锁中的代码，最后商品库存从100减到了0而不是负数？但是订单数超过100？
商品库存从100减到0而不是负数，是因为在代码中应该有检查库存数量的逻辑，如果库存为0，那么就不再进行减库存的操作。订单数超过100，则可能是因为锁提前释放，或者在减库存操作与生成订单操作之间存在时间差，在这个时间差内，其他线程可能已经进入，从而导致生成了超出库存数量的订单。这种现象在高并发情况下常常发生，被称为“超卖”。
2 解决商品超卖方案一：业务上加锁
对于上面超卖现象，主要问题出现在事务中锁释放的时机，事务未提交之前，锁已经释放。（事务提交是在整个方法执行完）。如何解决这个问题呢，就是把加锁步骤提前
-
可以在controller层进行加锁
-
可以使用Aop在业务方法执行之前进行加锁
2.1 方式一:在controller层进行加锁
将锁的粒度加大到足以包含整个事务的执行和撤销。
@ApiOperation(value="秒杀实现方式——Lock加锁")
@PostMapping("/start/lock")
public Result startLock(long skgId){
// 在此处加锁
lock.lock();
try {
log.info("开始秒杀方式一...");
final long userId = (int) (new Random().nextDouble() * (99999 - 10000 + 1)) + 10000;
Result result = secondKillService.startSecondKillByLock(skgId, userId);
if(result != null){
log.info("用户:{}--{}", userId, result.get("msg"));
}else{
log.info("用户:{}--{}", userId, "哎呦喂，人也太多了，请稍后！");
}
} catch (Exception e) {
e.printStackTrace();
} finally {
// 在此处释放锁
lock.unlock();
}
return Result.ok();
}
2.2 改进版本二：可以使用Aop在业务方法执行之前进行加锁
上面这样的加锁就可以解决事务未提交之前，锁释放的问题，可以分三种情况进行压力测试：
- 并发数1000，商品100
- 并发数1000，商品1000
- 并发数2000，商品1000
对于没有问题的情况就不贴图了，因为有很多种方式，贴图会太多
2.3 缺陷分析
以上两种方法都能够有效防止超卖现象，但是会出现少卖现象：
对于并发量大于商品数的情况，商品秒杀一般不会出现少卖的请况。但对于并发数小于等于商品数的时候可能会出现商品少卖情况
2.3.1 什么是少卖问题？
"但对于并发数小于等于商品数的时候可能会出现商品少卖情况“， 这句话的意思是在并发量小于或等于商品数量时，如果因为锁的存在，导致部分线程未能及时获取到锁进入执行，可能会出现商品"少卖"的现象。这里的"少卖"实际上是指商品库存未完全秒杀清空。
一句话定义：实际成功处理的请求数量小于原本的请求数量，从而导致实际销售的商品数量小于预期
2.3.2 这里的并发数是指实际的请求数嘛
是的，这里的并发数通常是指实际的请求数量，也就是同时对服务器发起请求的数量。
2.3.3 50个请求想秒杀100件商品，最后都执行成功，这是少卖嘛
对于50个请求秒杀100件商品，如果最后都执行成功，那么这不算是"少卖"。因为每个请求都被成功处理了，商品的销售也达到了预期的数量。
2.3.4 你说的少卖是指本来有50个请求想秒杀100件，但只有49个执行成功嘛？
你理解得准确。"少卖"一般指的是，实际成功处理的请求数量小于原本的请求数量，从而导致实际销售的商品数量小于预期。比如你所说的，本来有50个请求想秒杀100件商品，但只有49个执行成功，那么就可以说出现了"少卖"现象。
确实，在某些情况下，如果处理请求的速度过慢或者请求的等待超时时间设置得过短，可能会导致部分请求因为在规定时间内未能获得锁而被取消，从而导致"少卖"。这就需要根据实际情况去调整系统的设计和参数，以尽可能地保证业务的正常运行。
2.3.5 为什么会出现少卖呢？
当线程获取不到锁时，它不会一直等待，而是会有一个设定的超时时间。如果在超时时间内依然获取不到锁，那么线程就会放弃执行，从而可能会导致实际销售的商品数量少于库存，即出现"少卖"的情况。
这样的情况往往发生在服务器处理能力达到极限，或者网络环境差，导致部分请求处理速度变慢，从而使得部分线程在规定的超时时间内未能获得锁，最终导致"少卖"的现象。
总结一下，秒杀场景下的超卖和少卖问题，主要是由于并发控制（即锁）和事务处理机制之间的冲突造成的。解决这类问题，需要我们对并发编程和数据库事务的理解和技巧，以及根据具体的业务场景和需求来设计和优化系统。
2.3.6 为什么在请求数不多时会出现少卖？
"少卖"情况出现在等于或稍大于商品数量的请求打进来时，主要是因为在高并发情况下，很可能会有部分线程因为等待锁的时间过长而超时，导致这部分线程未能成功执行购买操作，从而导致"少卖"现象。
在这种场景下，假设有100个商品，有101个请求。当所有的请求都到达时，第一个请求会立即获得锁并开始处理，而其余100个请求则需要等待。如果锁的持有时间过长，或者等待的线程数过多，可能会导致部分线程在等待锁的时间超过其设定的超时时间，这部分线程因此未能执行购买操作。
特别是在高并发的情况下，大量的线程同时请求同一资源，可能会出现线程排队等待锁的情况。如果每个线程获取锁的时间过长，可能会导致线程等待时间超过超时阈值，从而终止线程，进而导致"少卖"。
因此，为了避免这种情况，可以考虑优化锁的持有时间，比如尽可能减少在持有锁时执行的操作，或者考虑使用更适合高并发场景的并发控制策略，如乐观锁等。
2.3.7 并发数远远大于商品数时，为什么就不会出现少卖，比如大部分线程等待时间超时后取消执行？
并发数远远大于商品数时，理论上不会出现少卖的情况，因为总是有足够多的请求在等待（或者总是有后续的新请求打进来，而这些新的请求距离超时还有足够时间），只要有一个请求完成（无论是成功秒杀还是因为库存不足而失败），就会有新的请求得以执行。所以，即使有大量请求因为等待超时而取消，总体上仍有足够的请求能够完成所有的商品秒杀。当然，这是在理想情况下，实际情况可能受到服务器处理能力、网络环境等多种因素的影响。
2.3.8 在等于或者稍微大于商品数量的请求打进来时，这并不算高并发场景吧
你是对的，"高并发"这个词通常是相对的，具体取决于你的系统和应用的特点。例如，如果你的系统的处理能力很高，那么，即使有大量的请求同时到来，也不会认为这是高并发。反之，如果你的系统的处理能力很低，那么，即使只有几个请求同时到来，也可能会认为这是高并发。
在你的例子中，如果请求的数量等于或稍微大于商品的数量，那么，这个场景是否是高并发，主要取决于你的系统和代码的设计。例如，如果你的代码在处理每个请求时都需要花费很长时间，那么，即使请求的数量不大，也可能会出现并发问题。反之，如果你的代码可以非常快速地处理每个请求，那么，即使请求的数量较大，也可能不会出现并发问题。
因此，关键是要理解你的系统的特点和限制，然后根据这些特点和限制来选择合适的并发控制策略。对于你的具体例子，如果你发现有"少卖"的问题，那么，可能需要考虑优化你的代码，或者选择更合适的并发控制策略。
2.3.9 我也可以理解为数据库中可能会出现其他的高并发访问操作，影响了秒杀的操作导致超时少卖
是的，你的理解是正确的。数据库是多个服务和应用共享的资源，因此，即使在请求量等于或稍大于商品数量的情况下，如果数据库同时还在处理其他高并发的访问操作，也可能对秒杀操作产生影响，导致部分请求超时，进而出现"少卖"现象。
数据库的处理能力是有限的，当并发的读/写请求超过其处理能力时，就会形成请求队列，等待数据库处理。这种情况下，如果秒杀操作的请求等待时间过长，就可能超时，从而未能成功购买，导致"少卖"。
因此，在设计和实现秒杀等需要高并发处理的系统时，我们需要全面考虑整个系统的性能，包括数据库的并发处理能力，网络的带宽和延迟，以及服务端程序的处理能力等等。只有这样，才能有效地防止"少卖"等问题的发生。
2.3.10 如何避免少卖？
- 缩小锁的粒度
- 缩小事务的粒度
- 尽量减小执行业务时锁消耗的时间
- 适度增加锁的超时时间，例如，在MySQL中，可以使用innodb_lock_wait_timeout参数来设置等待锁的超时时间。
3 解决超卖问题方案二：数据库层面加锁
3.1 悲观锁
除了上面在业务代码层面加锁外，还可以使用数据库自带的锁进行并发控制。
悲观锁，什么是悲观锁呢？通俗的说，在做任何事情之前，都要进行加锁确认。这种数据库级加锁操作效率较低。
使用for update一定要加上事务，当事务处理完后，for update才会将行级锁解除
如果请求数和秒杀商品数量一致，会出现少卖
@ApiOperation(value="秒杀实现方式三——悲观锁")
@PostMapping("/start/pes/lock/one")
public Result startPesLockOne(long skgId){
try {
log.info("开始秒杀方式三...");
final long userId = (int) (new Random().nextDouble() * (99999 - 10000 + 1)) + 10000;
Result result = secondKillService.startSecondKillByUpdate(skgId, userId);
if(result != null){
log.info("用户:{}--{}", userId, result.get("msg"));
}else{
log.info("用户:{}--{}", userId, "哎呦喂，人也太多了，请稍后！");
}
} catch (Exception e) {
e.printStackTrace();
}
return Result.ok();
}
业务逻辑
@Override
@Transactional(rollbackFor = Exception.class)
public Result startSecondKillByUpdate(long skgId, long userId) {
try {
// 校验库存-悲观锁
SecondKill secondKill = secondKillMapper.querySecondKillForUpdate(skgId);
Integer number = secondKill.getNumber();
if (number > 0) {
//扣库存
secondKill.setNumber(number - 1);
secondKillMapper.updateById(secondKill);
//创建订单
SuccessKilled killed = new SuccessKilled();
killed.setSeckillId(skgId);
killed.setUserId(userId);
killed.setState((short) 0);
killed.setCreateTime(new Timestamp(System.currentTimeMillis()));
successKilledMapper.insert(killed);
//支付
Payment payment = new Payment();
payment.setSeckillId(skgId);
payment.setSeckillId(skgId);
payment.setUserId(userId);
payment.setMoney(40);
payment.setState((short) 1);
payment.setCreateTime(new Timestamp(System.currentTimeMillis()));
paymentMapper.insert(payment);
} else {
return Result.error(SecondKillStateEnum.END);
}
} catch (Exception e) {
throw new ScorpiosException("异常了个乖乖");
} finally {
}
return Result.ok(SecondKillStateEnum.SUCCESS);
}
Dao层
@Repository
public interface SecondKillMapper extends BaseMapper<SecondKill> {
/**
* 将此行数据进行加锁，当整个方法将事务提交后，才会解锁
* @param skgId
* @return
*/
@Select(value = "SELECT * FROM seckill WHERE seckill_id=#{skgId} FOR UPDATE")
SecondKill querySecondKillForUpdate(@Param("skgId") Long skgId);
}
上面是利用for update进行对查询数据加锁，加的是行锁。
3.2 悲观锁二
悲观锁的第二种方式就是利用update更新命令来加表锁
/**
* UPDATE锁表
* @param skgId 商品id
* @param userId 用户id
* @return
*/
@Override
@Transactional(rollbackFor = Exception.class)
public Result startSecondKillByUpdateTwo(long skgId, long userId) {
try {
// 不校验，直接扣库存更新
int result = secondKillMapper.updateSecondKillById(skgId);
if (result > 0) {
//创建订单
SuccessKilled killed = new SuccessKilled();
killed.setSeckillId(skgId);
killed.setUserId(userId);
killed.setState((short) 0);
killed.setCreateTime(new Timestamp(System.currentTimeMillis()));
successKilledMapper.insert(killed);
//支付
Payment payment = new Payment();
payment.setSeckillId(skgId);
payment.setSeckillId(skgId);
payment.setUserId(userId);
payment.setMoney(40);
payment.setState((short) 1);
payment.setCreateTime(new Timestamp(System.currentTimeMillis()));
paymentMapper.insert(payment);
} else {
return Result.error(SecondKillStateEnum.END);
}
} catch (Exception e) {
throw new ScorpiosException("异常了个乖乖");
} finally {
}
return Result.ok(SecondKillStateEnum.SUCCESS);
}
Dao层
@Repository
public interface SecondKillMapper extends BaseMapper<SecondKill> {
/**
* 将此行数据进行加锁，当整个方法将事务提交后，才会解锁
* @param skgId
* @return
*/
@Select(value = "SELECT * FROM seckill WHERE seckill_id=#{skgId} FOR UPDATE")
SecondKill querySecondKillForUpdate(@Param("skgId") Long skgId);
@Update(value = "UPDATE seckill SET number=number-1 WHERE seckill_id=#{skgId} AND number > 0")
int updateSecondKillById(@Param("skgId") long skgId);
}
3.3 乐观锁
乐观锁，顾名思义，就是对操作结果很乐观，通过利用version字段来判断数据是否被修改。
乐观锁，不进行库存数量的校验，直接做库存扣减。
这里使用的乐观锁会出现大量的数据更新异常（抛异常就会导致购买失败）、如果配置的抢购人数比较少、比如120:100(人数:商品) 会出现少买的情况，不推荐使用乐观锁。
@ApiOperation(value="秒杀实现方式五——乐观锁")
@PostMapping("/start/opt/lock")
public Result startOptLock(long skgId){
try {
log.info("开始秒杀方式五...");
final long userId = (int) (new Random().nextDouble() * (99999 - 10000 + 1)) + 10000;
// 参数添加了购买数量
Result result = secondKillService.startSecondKillByPesLock(skgId, userId,1);
if(result != null){
log.info("用户:{}--{}", userId, result.get("msg"));
}else{
log.info("用户:{}--{}", userId, "哎呦喂，人也太多了，请稍后！");
}
} catch (Exception e) {
e.printStackTrace();
}
return Result.ok();
}
@Override
@Transactional(rollbackFor = Exception.class)
public Result startSecondKillByPesLock(long skgId, long userId, int number) {
// 乐观锁，不进行库存数量的校验，直接
try {
SecondKill kill = secondKillMapper.selectById(skgId);
// 剩余的数量应该要大于等于秒杀的数量
if(kill.getNumber() >= number) {
int result = secondKillMapper.updateSecondKillByVersion(number,skgId,kill.getVersion());
if (result > 0) {
//创建订单
SuccessKilled killed = new SuccessKilled();
killed.setSeckillId(skgId);
killed.setUserId(userId);
killed.setState((short) 0);
killed.setCreateTime(new Timestamp(System.currentTimeMillis()));
successKilledMapper.insert(killed);
//支付
Payment payment = new Payment();
payment.setSeckillId(skgId);
payment.setSeckillId(skgId);
payment.setUserId(userId);
payment.setMoney(40);
payment.setState((short) 1);
payment.setCreateTime(new Timestamp(System.currentTimeMillis()));
paymentMapper.insert(payment);
} else {
return Result.error(SecondKillStateEnum.END);
}
}
} catch (Exception e) {
throw new ScorpiosException("异常了个乖乖");
} finally {
}
return Result.ok(SecondKillStateEnum.SUCCESS);
}
@Repository
public interface SecondKillMapper extends BaseMapper<SecondKill> {
/**
* 将此行数据进行加锁，当整个方法将事务提交后，才会解锁
* @param skgId
* @return
*/
@Select(value = "SELECT * FROM seckill WHERE seckill_id=#{skgId} FOR UPDATE")
SecondKill querySecondKillForUpdate(@Param("skgId") Long skgId);
@Update(value = "UPDATE seckill SET number=number-1 WHERE seckill_id=#{skgId} AND number > 0")
int updateSecondKillById(@Param("skgId") long skgId);
@Update(value = "UPDATE seckill SET number=number-#{number},version=version+1 WHERE seckill_id=#{skgId} AND version = #{version}")
int updateSecondKillByVersion(@Param("number") int number, @Param("skgId") long skgId, @Param("version")int version);
乐观锁会出现大量的数据更新异常（抛异常就会导致购买失败），会出现少买的情况，不推荐使用乐观锁。
3.4 悲观锁和乐观锁的区别
3.4.1 为什么悲观锁改为了乐观锁能提升性能，性能提升指什么方面，是时间还是吞吐量?
悲观锁在操作前就锁定数据，这导致任何时候只有一个线程在操作数据，其他线程都在等待，这会导致大量的时间花在了等待上。乐观锁则相反，它假设冲突很少发生，因此在需要更新数据时才检查是否有其他线程已经更新了这个数据。乐观锁的这种特性使得在数据冲突较少的情况下能提升并发性能，也就是说，可以在单位时间内处理更多的请求，即提高了系统的吞吐量。
3.4.2 乐观锁能提升吞吐量，具体是指qps吗？这有什么好处吗，是能提升响应速度吗？
是的，乐观锁能提升系统的吞吐量，这里的吞吐量可以理解为单位时间内处理的请求数量，即QPS (Queries Per Second)。在并发不高或者写冲突不严重的场景下，乐观锁可以大大提高系统的吞吐量，因为它只在更新数据时检查版本冲突，减少了锁的开销。这样的好处是能让系统在单位时间内处理更多的请求，对于用户来说，可能会感觉到响应更快， 但是如果并发很高，写冲突严重，乐观锁就可能会导致大量的更新失败，此时系统的响应速度可能会降低。
3.4.3 使用乐观锁会导致什么问题呢？
乐观锁最大的问题是在数据竞争激烈的情况下，可能导致大量的更新操作失败。因为每次更新都需要检查版本，如果版本不一致，更新就会失败。此外，如果一直重试也得不到正确的结果，可能会导致线程饥饿。
3.4.4 使用乐观锁在高并发场景下，可能会出现大量的数据更新异常，那悲观锁呢
使用悲观锁在高并发场景下，由于它在操作开始时就锁定资源，所以不会出现乐观锁那样的数据更新异常（即并发修改导致的版本冲突）。但是，悲观锁可能导致大量的线程在等待获取锁，如果等待时间过长，可能导致请求超时，从而影响系统的吞吐量和响应速度。****
4 方案四：消息队列
4.1 阻塞队列
利用阻塞队类，也可以解决高并发问题。其思想就是把接收到的请求按顺序存放到队列中，消费者线程逐一从队列里取数据进行处理，看下具体代码。
阻塞队列：这里使用静态内部类的方式来实现单例模式，在并发条件下不会出现问题。
// 秒杀队列(固定长度为100)
public class SecondKillQueue {
// 队列大小
static final int QUEUE_MAX_SIZE = 100;
// 用于多线程间下单的队列
static BlockingQueue<SuccessKilled> blockingQueue = new LinkedBlockingQueue<SuccessKilled>(QUEUE_MAX_SIZE);
// 使用静态内部类，实现单例模式
private SecondKillQueue(){
};
private static class SingletonHolder{
// 静态初始化器，由JVM来保证线程安全
private static SecondKillQueue queue = new SecondKillQueue();
}
/**
* 单例队列
* @return
*/
public static SecondKillQueue getSkillQueue(){
return SingletonHolder.queue;
}
/**
* 生产入队
* @param kill
* @throws InterruptedException
* add(e) 队列未满时，返回true；队列满则抛出IllegalStateException(“Queue full”)异常——AbstractQueue
* put(e) 队列未满时，直接插入没有返回值；队列满时会阻塞等待，一直等到队列未满时再插入。
* offer(e) 队列未满时，返回true；队列满时返回false。非阻塞立即返回。
* offer(e, time, unit) 设定等待的时间，如果在指定时间内还不能往队列中插入数据则返回false，插入成功返回true。
*/
public Boolean produce(SuccessKilled kill) {
return blockingQueue.offer(kill);
}
/**
* 消费出队
* poll() 获取并移除队首元素，在指定的时间内去轮询队列看有没有首元素有则返回，否者超时后返回null
* take() 与带超时时间的poll类似不同在于take时候如果当前队列空了它会一直等待其他线程调用notEmpty.signal()才会被唤醒
*/
public SuccessKilled consume() throws InterruptedException {
return blockingQueue.take();
}
/**
* 获取队列大小
* @return
*/
public int size() {
return blockingQueue.size();
}
}
消费秒杀队列：实现ApplicationRunner接口
// 消费秒杀队列
@Slf4j
@Component
public class TaskRunner implements ApplicationRunner{
@Autowired
private SecondKillService seckillService;
@Override
public void run(ApplicationArguments var){
new Thread(() -> {
log.info("队列启动成功");
while(true){
try {
// 进程内队列
SuccessKilled kill = SecondKillQueue.getSkillQueue().consume();
if(kill != null){
Result result = seckillService.startSecondKillByAop(kill.getSeckillId(), kill.getUserId());
if(result != null && result.equals(Result.ok(SecondKillStateEnum.SUCCESS))){
log.info("TaskRunner,result:{}",result);
log.info("TaskRunner从消息队列取出用户，用户:{}{}",kill.getUserId(),"秒杀成功");
}
}
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}).start();
}
}
@ApiOperation(value="秒杀实现方式六——消息队列")
@PostMapping("/start/queue")
public Result startQueue(long skgId){
try {
log.info("开始秒杀方式六...");
final long userId = (int) (new Random().nextDouble() * (99999 - 10000 + 1)) + 10000;
SuccessKilled kill = new SuccessKilled();
kill.setSeckillId(skgId);
kill.setUserId(userId);
Boolean flag = SecondKillQueue.getSkillQueue().produce(kill);
// 虽然进入了队列，但是不一定能秒杀成功 进队出队有时间间隙
if(flag){
log.info("用户:{}{}",kill.getUserId(),"秒杀成功");
}else{
log.info("用户:{}{}",userId,"秒杀失败");
}
} catch (Exception e) {
e.printStackTrace();
}
return Result.ok();
}
注意：在业务层和AOP方法中，不能抛出任何异常， throw new
RuntimeException()这些抛异常代码要注释掉。因为一旦程序抛出异常就会停止，导致消费秒杀队列进程终止！
使用阻塞队列来实现秒杀，有几点要注意：
- 消费秒杀队列中调用业务方法加锁与不加锁情况一样，也就是seckillService.startSecondKillByAop()、seckillService.startSecondKillByLock()方法结果一样，这也很好理解
- 当队列长度与商品数量一致时，会出现少卖的现象，可以调大数值
- 下面是队列长度1000，商品数量1000，并发数2000情况下出现的少卖
4.2 Q&A
4.2.1 消息队列出现少卖现象的原因
是的，你的理解是准确的。"少卖"在这个上下文中，不仅指的是队列溢出导致的请求无法被处理的情况，也包括了消息被消费失败后被丢弃的情况。
（1）当系统采用固定长度的消息队列来处理秒杀请求时，一旦请求并发量超过了队列的长度，那么超出部分的请求将无法被处理，从而出现"少卖"的情况。
（2）另外，如果消息队列的消费者（也就是处理请求的服务器或者线程）在处理某个请求时出现了错误，导致这个请求未能被成功处理，那么这个请求也可能被丢弃，从而出现"少卖"的情况。
因此，解决"少卖"问题需要考虑两个方面：一方面，需要合理设置消息队列的长度，以便可以处理尽可能多的并发请求；另一方面，需要提高消息的消费成功率，例如，可以通过错误重试机制来处理消费失败的消息。