1.引言

高并發場景在現場的日常工作中很常見，特別是在互聯網公司中，這篇文章就來通過秒殺商品來模擬高并發的場景。文章末尾會附上文章的所有代碼、腳本和測試用例。

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

模擬工具： Jmeter

模擬場景： 減庫存->創建訂單->模擬支付

2.商品秒殺-超賣

在開發中，對于下面的代碼，可能很熟悉：在Service里面加上@Transactional事務注解和Lock鎖

控制層：Controller

@ApiOperation(value="秒殺實現方式——Lock加鎖")
@PostMapping("/start/lock")
publicResultstartLock(longskgId){
try{
log.info("開始秒殺方式一...");
finallonguserId=(int)(newRandom().nextDouble()*(99999-10000+1))+10000;
Resultresult=secondKillService.startSecondKillByLock(skgId,userId);
if(result!=null){
log.info("用戶:{}--{}",userId,result.get("msg"));
}else{
log.info("用戶:{}--{}",userId,"哎呦喂，人也太多了，請稍后！");
}
}catch(Exceptione){
e.printStackTrace();
}finally{

}
returnResult.ok();
}

業務層：Service

@Override
@Transactional(rollbackFor=Exception.class)
publicResultstartSecondKillByLock(longskgId,longuserId){
lock.lock();
try{
//校驗庫存
SecondKillsecondKill=secondKillMapper.selectById(skgId);
Integernumber=secondKill.getNumber();
if(number>0){
//扣庫存
secondKill.setNumber(number-1);
secondKillMapper.updateById(secondKill);
//創建訂單
SuccessKilledkilled=newSuccessKilled();
killed.setSeckillId(skgId);
killed.setUserId(userId);
killed.setState((short)0);
killed.setCreateTime(newTimestamp(System.currentTimeMillis()));
successKilledMapper.insert(killed);

//模擬支付
Paymentpayment=newPayment();
payment.setSeckillId(skgId);
payment.setSeckillId(skgId);
payment.setUserId(userId);
payment.setMoney(40);
payment.setState((short)1);
payment.setCreateTime(newTimestamp(System.currentTimeMillis()));
paymentMapper.insert(payment);
}else{
returnResult.error(SecondKillStateEnum.END);
}
}catch(Exceptione){
thrownewScorpiosException("異常了個乖乖");
}finally{
lock.unlock();
}
returnResult.ok(SecondKillStateEnum.SUCCESS);
}

對于上面的代碼應該沒啥問題吧，業務方法上加事務，在處理業務的時候加鎖。

但上面這樣寫法是有問題的，會出現超賣的情況，看下測試結果：模擬1000個并發，搶100商品

這里在業務方法開始加了鎖，在業務方法結束后釋放了鎖。但這里的事務提交卻不是這樣的，有可能在事務提交之前，就已經把鎖釋放了，這樣會導致商品超賣現象。所以加鎖的時機很重要！

3. 解決商品超賣

對于上面超賣現象，主要問題出現在事務中鎖釋放的時機，事務未提交之前，鎖已經釋放。（事務提交是在整個方法執行完）。如何解決這個問題呢，就是把加鎖步驟提前

可以在controller層進行加鎖

可以使用Aop在業務方法執行之前進行加鎖

3.1 方式一（改進版加鎖）

@ApiOperation(value="秒殺實現方式——Lock加鎖")
@PostMapping("/start/lock")
publicResultstartLock(longskgId){
//在此處加鎖
lock.lock();
try{
log.info("開始秒殺方式一...");
finallonguserId=(int)(newRandom().nextDouble()*(99999-10000+1))+10000;
Resultresult=secondKillService.startSecondKillByLock(skgId,userId);
if(result!=null){
log.info("用戶:{}--{}",userId,result.get("msg"));
}else{
log.info("用戶:{}--{}",userId,"哎呦喂，人也太多了，請稍后！");
}
}catch(Exceptione){
e.printStackTrace();
}finally{
//在此處釋放鎖
lock.unlock();
}
returnResult.ok();
}

上面這樣的加鎖就可以解決事務未提交之前，鎖釋放的問題，可以分三種情況進行壓力測試：

并發數1000，商品100

并發數1000，商品1000

并發數2000，商品1000

對于并發量大于商品數的情況，商品秒殺一般不會出現少賣的請況，但對于并發數小于等于商品數的時候可能會出現商品少賣情況，這也很好理解。

對于沒有問題的情況就不貼圖了，因為有很多種方式，貼圖會太多

3.2 方式二（AOP版加鎖）

對于上面在控制層進行加鎖的方式，可能顯得不優雅，那就還有另一種方式進行在事務之前加鎖，那就是AOP

自定義AOP注解

@Target({ElementType.PARAMETER,ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public@interfaceServiceLock{
Stringdescription()default"";
}

定義切面類

@Slf4j
@Component
@Scope
@Aspect
@Order(1)//order越小越是最先執行，但更重要的是最先執行的最后結束
publicclassLockAspect{
/**
*思考：為什么不用synchronized
*service默認是單例的，并發下lock只有一個實例
*/
privatestaticLocklock=newReentrantLock(true);//互斥鎖參數默認false，不公平鎖

//Service層切點用于記錄錯誤日志
@Pointcut("@annotation(com.scorpios.secondkill.aop.ServiceLock)")
publicvoidlockAspect(){

}

@Around("lockAspect()")
publicObjectaround(ProceedingJoinPointjoinPoint){
lock.lock();
Objectobj=null;
try{
obj=joinPoint.proceed();
}catch(Throwablee){
e.printStackTrace();
thrownewRuntimeException();
}finally{
lock.unlock();
}
returnobj;
}
}

在業務方法上添加AOP注解

@Override
@ServiceLock//使用Aop進行加鎖
@Transactional(rollbackFor=Exception.class)
publicResultstartSecondKillByAop(longskgId,longuserId){

try{
//校驗庫存
SecondKillsecondKill=secondKillMapper.selectById(skgId);
Integernumber=secondKill.getNumber();
if(number>0){
//扣庫存
secondKill.setNumber(number-1);
secondKillMapper.updateById(secondKill);
//創建訂單
SuccessKilledkilled=newSuccessKilled();
killed.setSeckillId(skgId);
killed.setUserId(userId);
killed.setState((short)0);
killed.setCreateTime(newTimestamp(System.currentTimeMillis()));
successKilledMapper.insert(killed);

//支付
Paymentpayment=newPayment();
payment.setSeckillId(skgId);
payment.setSeckillId(skgId);
payment.setUserId(userId);
payment.setMoney(40);
payment.setState((short)1);
payment.setCreateTime(newTimestamp(System.currentTimeMillis()));
paymentMapper.insert(payment);
}else{
returnResult.error(SecondKillStateEnum.END);
}
}catch(Exceptione){
thrownewScorpiosException("異常了個乖乖");
}
returnResult.ok(SecondKillStateEnum.SUCCESS);
}

控制層：

@ApiOperation(value="秒殺實現方式二——Aop加鎖")
@PostMapping("/start/aop")
publicResultstartAop(longskgId){
try{
log.info("開始秒殺方式二...");
finallonguserId=(int)(newRandom().nextDouble()*(99999-10000+1))+10000;
Resultresult=secondKillService.startSecondKillByAop(skgId,userId);
if(result!=null){
log.info("用戶:{}--{}",userId,result.get("msg"));
}else{
log.info("用戶:{}--{}",userId,"哎呦喂，人也太多了，請稍后！");
}
}catch(Exceptione){
e.printStackTrace();
}
returnResult.ok();
}

這種方式在對鎖的使用上，更高階、更美觀！

3.3 方式三（悲觀鎖一）

除了上面在業務代碼層面加鎖外，還可以使用數據庫自帶的鎖進行并發控制。

悲觀鎖，什么是悲觀鎖呢？通俗的說，在做任何事情之前，都要進行加鎖確認。這種數據庫級加鎖操作效率較低。

使用for update一定要加上事務，當事務處理完后，for update才會將行級鎖解除

如果請求數和秒殺商品數量一致，會出現少賣

@ApiOperation(value="秒殺實現方式三——悲觀鎖")
@PostMapping("/start/pes/lock/one")
publicResultstartPesLockOne(longskgId){
try{
log.info("開始秒殺方式三...");
finallonguserId=(int)(newRandom().nextDouble()*(99999-10000+1))+10000;
Resultresult=secondKillService.startSecondKillByUpdate(skgId,userId);
if(result!=null){
log.info("用戶:{}--{}",userId,result.get("msg"));
}else{
log.info("用戶:{}--{}",userId,"哎呦喂，人也太多了，請稍后！");
}
}catch(Exceptione){
e.printStackTrace();
}
returnResult.ok();
}

業務邏輯

@Override
@Transactional(rollbackFor=Exception.class)
publicResultstartSecondKillByUpdate(longskgId,longuserId){
try{
//校驗庫存-悲觀鎖
SecondKillsecondKill=secondKillMapper.querySecondKillForUpdate(skgId);
Integernumber=secondKill.getNumber();
if(number>0){
//扣庫存
secondKill.setNumber(number-1);
secondKillMapper.updateById(secondKill);
//創建訂單
SuccessKilledkilled=newSuccessKilled();
killed.setSeckillId(skgId);
killed.setUserId(userId);
killed.setState((short)0);
killed.setCreateTime(newTimestamp(System.currentTimeMillis()));
successKilledMapper.insert(killed);

//支付
Paymentpayment=newPayment();
payment.setSeckillId(skgId);
payment.setSeckillId(skgId);
payment.setUserId(userId);
payment.setMoney(40);
payment.setState((short)1);
payment.setCreateTime(newTimestamp(System.currentTimeMillis()));
paymentMapper.insert(payment);
}else{
returnResult.error(SecondKillStateEnum.END);
}
}catch(Exceptione){
thrownewScorpiosException("異常了個乖乖");
}finally{
}
returnResult.ok(SecondKillStateEnum.SUCCESS);
}

Dao層

@Repository
publicinterfaceSecondKillMapperextendsBaseMapper{

/**
*將此行數據進行加鎖，當整個方法將事務提交后，才會解鎖
*@paramskgId
*@return
*/
@Select(value="SELECT*FROMseckillWHEREseckill_id=#{skgId}FORUPDATE")
SecondKillquerySecondKillForUpdate(@Param("skgId")LongskgId);

}

上面是利用for update進行對查詢數據加鎖，加的是行鎖

3.4 方式四（悲觀鎖二）

悲觀鎖的第二種方式就是利用update更新命令來加表鎖

/**
*UPDATE鎖表
*@paramskgId商品id
*@paramuserId用戶id
*@return
*/
@Override
@Transactional(rollbackFor=Exception.class)
publicResultstartSecondKillByUpdateTwo(longskgId,longuserId){
try{

//不校驗，直接扣庫存更新
intresult=secondKillMapper.updateSecondKillById(skgId);
if(result>0){
//創建訂單
SuccessKilledkilled=newSuccessKilled();
killed.setSeckillId(skgId);
killed.setUserId(userId);
killed.setState((short)0);
killed.setCreateTime(newTimestamp(System.currentTimeMillis()));
successKilledMapper.insert(killed);

//支付
Paymentpayment=newPayment();
payment.setSeckillId(skgId);
payment.setSeckillId(skgId);
payment.setUserId(userId);
payment.setMoney(40);
payment.setState((short)1);
payment.setCreateTime(newTimestamp(System.currentTimeMillis()));
paymentMapper.insert(payment);
}else{
returnResult.error(SecondKillStateEnum.END);
}
}catch(Exceptione){
thrownewScorpiosException("異常了個乖乖");
}finally{
}
returnResult.ok(SecondKillStateEnum.SUCCESS);
}

Dao層

@Repository
publicinterfaceSecondKillMapperextendsBaseMapper{

/**
*將此行數據進行加鎖，當整個方法將事務提交后，才會解鎖
*@paramskgId
*@return
*/
@Select(value="SELECT*FROMseckillWHEREseckill_id=#{skgId}FORUPDATE")
SecondKillquerySecondKillForUpdate(@Param("skgId")LongskgId);

@Update(value="UPDATEseckillSETnumber=number-1WHEREseckill_id=#{skgId}ANDnumber>0")
intupdateSecondKillById(@Param("skgId")longskgId);
}

3.5 方式五（樂觀鎖）

樂觀鎖，顧名思義，就是對操作結果很樂觀，通過利用version字段來判斷數據是否被修改

樂觀鎖，不進行庫存數量的校驗，直接做庫存扣減

這里使用的樂觀鎖會出現大量的數據更新異常（拋異常就會導致購買失敗）、如果配置的搶購人數比較少、比如120:100(人數:商品) 會出現少買的情況，不推薦使用樂觀鎖。

@ApiOperation(value="秒殺實現方式五——樂觀鎖")
@PostMapping("/start/opt/lock")
publicResultstartOptLock(longskgId){
try{
log.info("開始秒殺方式五...");
finallonguserId=(int)(newRandom().nextDouble()*(99999-10000+1))+10000;
//參數添加了購買數量
Resultresult=secondKillService.startSecondKillByPesLock(skgId,userId,1);
if(result!=null){
log.info("用戶:{}--{}",userId,result.get("msg"));
}else{
log.info("用戶:{}--{}",userId,"哎呦喂，人也太多了，請稍后！");
}
}catch(Exceptione){
e.printStackTrace();
}
returnResult.ok();
}
@Override
@Transactional(rollbackFor=Exception.class)
publicResultstartSecondKillByPesLock(longskgId,longuserId,intnumber){

//樂觀鎖，不進行庫存數量的校驗，直接
try{
SecondKillkill=secondKillMapper.selectById(skgId);
//剩余的數量應該要大于等于秒殺的數量
if(kill.getNumber()>=number){
intresult=secondKillMapper.updateSecondKillByVersion(number,skgId,kill.getVersion());
if(result>0){
//創建訂單
SuccessKilledkilled=newSuccessKilled();
killed.setSeckillId(skgId);
killed.setUserId(userId);
killed.setState((short)0);
killed.setCreateTime(newTimestamp(System.currentTimeMillis()));
successKilledMapper.insert(killed);

//支付
Paymentpayment=newPayment();
payment.setSeckillId(skgId);
payment.setSeckillId(skgId);
payment.setUserId(userId);
payment.setMoney(40);
payment.setState((short)1);
payment.setCreateTime(newTimestamp(System.currentTimeMillis()));
paymentMapper.insert(payment);
}else{
returnResult.error(SecondKillStateEnum.END);
}
}
}catch(Exceptione){
thrownewScorpiosException("異常了個乖乖");
}finally{
}
returnResult.ok(SecondKillStateEnum.SUCCESS);
}
@Repository
publicinterfaceSecondKillMapperextendsBaseMapper{

/**
*將此行數據進行加鎖，當整個方法將事務提交后，才會解鎖
*@paramskgId
*@return
*/
@Select(value="SELECT*FROMseckillWHEREseckill_id=#{skgId}FORUPDATE")
SecondKillquerySecondKillForUpdate(@Param("skgId")LongskgId);

@Update(value="UPDATEseckillSETnumber=number-1WHEREseckill_id=#{skgId}ANDnumber>0")
intupdateSecondKillById(@Param("skgId")longskgId);

@Update(value="UPDATEseckillSETnumber=number-#{number},version=version+1WHEREseckill_id=#{skgId}ANDversion=#{version}")
intupdateSecondKillByVersion(@Param("number")intnumber,@Param("skgId")longskgId,@Param("version")intversion);
}

樂觀鎖會出現大量的數據更新異常（拋異常就會導致購買失敗），會出現少買的情況，不推薦使用樂觀鎖

3.6 方式六（阻塞隊列）

利用阻塞隊類，也可以解決高并發問題。其思想就是把接收到的請求按順序存放到隊列中，消費者線程逐一從隊列里取數據進行處理，看下具體代碼。

阻塞隊列：這里使用靜態內部類的方式來實現單例模式，在并發條件下不會出現問題。

//秒殺隊列(固定長度為100)
publicclassSecondKillQueue{

//隊列大小
staticfinalintQUEUE_MAX_SIZE=100;

//用于多線程間下單的隊列
staticBlockingQueueblockingQueue=newLinkedBlockingQueue(QUEUE_MAX_SIZE);

//使用靜態內部類，實現單例模式
privateSecondKillQueue(){};

privatestaticclassSingletonHolder{
//靜態初始化器，由JVM來保證線程安全
privatestaticSecondKillQueuequeue=newSecondKillQueue();
}

/**
*單例隊列
*@return
*/
publicstaticSecondKillQueuegetSkillQueue(){
returnSingletonHolder.queue;
}

/**
*生產入隊
*@paramkill
*@throwsInterruptedException
*add(e)隊列未滿時，返回true；隊列滿則拋出IllegalStateException(“Queuefull”)異常——AbstractQueue
*put(e)隊列未滿時，直接插入沒有返回值；隊列滿時會阻塞等待，一直等到隊列未滿時再插入。
*offer(e)隊列未滿時，返回true；隊列滿時返回false。非阻塞立即返回。
*offer(e,time,unit)設定等待的時間，如果在指定時間內還不能往隊列中插入數據則返回false，插入成功返回true。
*/
publicBooleanproduce(SuccessKilledkill){
returnblockingQueue.offer(kill);
}
/**
*消費出隊
*poll()獲取并移除隊首元素，在指定的時間內去輪詢隊列看有沒有首元素有則返回，否者超時后返回null
*take()與帶超時時間的poll類似不同在于take時候如果當前隊列空了它會一直等待其他線程調用notEmpty.signal()才會被喚醒
*/
publicSuccessKilledconsume()throwsInterruptedException{
returnblockingQueue.take();
}

/**
*獲取隊列大小
*@return
*/
publicintsize(){
returnblockingQueue.size();
}
}

消費秒殺隊列：實現ApplicationRunner接口

//消費秒殺隊列
@Slf4j
@Component
publicclassTaskRunnerimplementsApplicationRunner{

@Autowired
privateSecondKillServiceseckillService;

@Override
publicvoidrun(ApplicationArgumentsvar){
newThread(()->{
log.info("隊列啟動成功");
while(true){
try{
//進程內隊列
SuccessKilledkill=SecondKillQueue.getSkillQueue().consume();
if(kill!=null){
Resultresult=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(InterruptedExceptione){
e.printStackTrace();
}
}
}).start();
}
}
@ApiOperation(value="秒殺實現方式六——消息隊列")
@PostMapping("/start/queue")
publicResultstartQueue(longskgId){
try{
log.info("開始秒殺方式六...");
finallonguserId=(int)(newRandom().nextDouble()*(99999-10000+1))+10000;
SuccessKilledkill=newSuccessKilled();
kill.setSeckillId(skgId);
kill.setUserId(userId);
Booleanflag=SecondKillQueue.getSkillQueue().produce(kill);
//雖然進入了隊列，但是不一定能秒殺成功進隊出隊有時間間隙
if(flag){
log.info("用戶:{}{}",kill.getUserId(),"秒殺成功");
}else{
log.info("用戶:{}{}",userId,"秒殺失敗");
}
}catch(Exceptione){
e.printStackTrace();
}
returnResult.ok();
}

注意：在業務層和AOP方法中，不能拋出任何異常， throw new RuntimeException()這些拋異常代碼要注釋掉。因為一旦程序拋出異常就會停止，導致消費秒殺隊列進程終止！

使用阻塞隊列來實現秒殺，有幾點要注意：

消費秒殺隊列中調用業務方法加鎖與不加鎖情況一樣，也就是seckillService.startSecondKillByAop()、seckillService.startSecondKillByLock()方法結果一樣，這也很好理解

當隊列長度與商品數量一致時，會出現少賣的現象，可以調大數值

下面是隊列長度1000，商品數量1000，并發數2000情況下出現的少賣

3.7.方式七（Disruptor隊列）

Disruptor是個高性能隊列，研發的初衷是解決內存隊列的延遲問題，在性能測試中發現竟然與I/O操作處于同樣的數量級，基于Disruptor開發的系統單線程能支撐每秒600萬訂單。

//事件生成工廠（用來初始化預分配事件對象）
publicclassSecondKillEventFactoryimplementsEventFactory{

@Override
publicSecondKillEventnewInstance(){
returnnewSecondKillEvent();
}
}
//事件對象（秒殺事件）
publicclassSecondKillEventimplementsSerializable{
privatestaticfinallongserialVersionUID=1L;
privatelongseckillId;
privatelonguserId;

//set/get方法略

}
//使用translator方式生產者
publicclassSecondKillEventProducer{

privatefinalstaticEventTranslatorVarargtranslator=(seckillEvent,seq,objs)->{
seckillEvent.setSeckillId((Long)objs[0]);
seckillEvent.setUserId((Long)objs[1]);
};

privatefinalRingBufferringBuffer;

publicSecondKillEventProducer(RingBufferringBuffer){
this.ringBuffer=ringBuffer;
}

publicvoidsecondKill(longseckillId,longuserId){
this.ringBuffer.publishEvent(translator,seckillId,userId);
}
}
//消費者(秒殺處理器)
@Slf4j
publicclassSecondKillEventConsumerimplementsEventHandler{


privateSecondKillServicesecondKillService=(SecondKillService)SpringUtil.getBean("secondKillService");

@Override
publicvoidonEvent(SecondKillEventseckillEvent,longseq,booleanbool){
Resultresult=secondKillService.startSecondKillByAop(seckillEvent.getSeckillId(),seckillEvent.getUserId());
if(result.equals(Result.ok(SecondKillStateEnum.SUCCESS))){
log.info("用戶:{}{}",seckillEvent.getUserId(),"秒殺成功");
}
}
}
publicclassDisruptorUtil{

staticDisruptordisruptor;

static{
SecondKillEventFactoryfactory=newSecondKillEventFactory();
intringBufferSize=1024;
ThreadFactorythreadFactory=runnable->newThread(runnable);
disruptor=newDisruptor<>(factory,ringBufferSize,threadFactory);
disruptor.handleEventsWith(newSecondKillEventConsumer());
disruptor.start();
}

publicstaticvoidproducer(SecondKillEventkill){
RingBufferringBuffer=disruptor.getRingBuffer();
SecondKillEventProducerproducer=newSecondKillEventProducer(ringBuffer);
producer.secondKill(kill.getSeckillId(),kill.getUserId());
}
}
@ApiOperation(value="秒殺實現方式七——Disruptor隊列")
@PostMapping("/start/disruptor")
publicResultstartDisruptor(longskgId){
try{
log.info("開始秒殺方式七...");
finallonguserId=(int)(newRandom().nextDouble()*(99999-10000+1))+10000;
SecondKillEventkill=newSecondKillEvent();
kill.setSeckillId(skgId);
kill.setUserId(userId);
DisruptorUtil.producer(kill);
}catch(Exceptione){
e.printStackTrace();
}
returnResult.ok();
}

經過測試，發現使用Disruptor隊列隊列，與自定義隊列有著同樣的問題，也會出現超賣的情況，但效率有所提高。

4. 小結

對于上面七種實現并發的方式，做一下總結：

一、二方式是在代碼中利用鎖和事務的方式解決了并發問題，主要解決的是鎖要加載事務之前

三、四、五方式主要是數據庫的鎖來解決并發問題，方式三是利用for upate對表加行鎖，方式四是利用update來對表加鎖，方式五是通過增加version字段來控制數據庫的更新操作，方式五的效果最差

六、七方式是通過隊列來解決并發問題，這里需要特別注意的是，在代碼中不能通過throw拋異常，否則消費線程會終止，而且由于進隊和出隊存在時間間隙，會導致商品少賣

上面所有的情況都經過代碼測試，測試分一下三種情況：

并發數1000，商品數100

并發數1000，商品數1000

并發數2000，商品數1000

思考：分布式情況下如何解決并發問題呢？下次繼續試驗。

審核編輯：劉清