声明:部分内容截取自大厂防止超卖的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)另外,如果消息队列的消费者(也就是处理请求的服务器或者线程)在处理某个请求时出现了错误,导致这个请求未能被成功处理,那么这个请求也可能被丢弃,从而出现"少卖"的情况。
因此,解决"少卖"问题需要考虑两个方面:一方面,需要合理设置消息队列的长度,以便可以处理尽可能多的并发请求;另一方面,需要提高消息的消费成功率,例如,可以通过错误重试机制来处理消费失败的消息。