• 1.引言

• 2.商品秒殺-超賣

• 3.解決商品超賣

• 3.1 方式一（改進(jìn)版加鎖）

• 3.2 方式二（AOP版加鎖）

• 3.3 方式三（悲觀鎖一）

• 3.4 方式四（悲觀鎖二）

• 3.5 方式五（樂觀鎖）

• 3.6 方式六（阻塞隊(duì)列）

• 3.7.方式七（Disruptor隊(duì)列）

1. 小結(jié)

1.引言

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

• 本文環(huán)境：SpringBoot 2.5.7 + MySQL 8.0 X + MybatisPlus + Swagger2.9.2

• 模擬工具：Jmeter

• 模擬場景：減庫存->創(chuàng)建訂單->模擬支付

2.商品秒殺-超賣

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

控制層：Controller

業(yè)務(wù)層：Service

對于上面的代碼應(yīng)該沒啥問題吧，業(yè)務(wù)方法上加事務(wù)，在處理業(yè)務(wù)的時候加鎖。

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

這里在業(yè)務(wù)方法開始加了鎖，在業(yè)務(wù)方法結(jié)束后釋放了鎖。但這里的事務(wù)提交卻不是這樣的，有可能在事務(wù)提交之前，就已經(jīng)把鎖釋放了，這樣會導(dǎo)致商品超賣現(xiàn)象。所以加鎖的時機(jī)很重要！

3. 解決商品超賣

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

• 可以在controller層進(jìn)行加鎖

• 可以使用Aop在業(yè)務(wù)方法執(zhí)行之前進(jìn)行加鎖

3.1 方式一（改進(jìn)版加鎖）

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

• 并發(fā)數(shù)1000，商品100

• 并發(fā)數(shù)1000，商品1000

• 并發(fā)數(shù)2000，商品1000

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

對于沒有問題的情況就不貼圖了，因?yàn)橛泻芏喾N方式，貼圖會太多

3.2 方式二（AOP版加鎖）

對于上面在控制層進(jìn)行加鎖的方式，可能顯得不優(yōu)雅，那就還有另一種方式進(jìn)行在事務(wù)之前加鎖，那就是AOP

自定義AOP注解

在業(yè)務(wù)方法上添加AOP注解

控制層：

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

3.3 方式三（悲觀鎖一）

除了上面在業(yè)務(wù)代碼層面加鎖外，還可以使用數(shù)據(jù)庫自帶的鎖進(jìn)行并發(fā)控制。

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

使用for update一定要加上事務(wù)，當(dāng)事務(wù)處理完后，for update才會將行級鎖解除

如果請求數(shù)和秒殺商品數(shù)量一致，會出現(xiàn)少賣

業(yè)務(wù)邏輯

Dao層

上面是利用for update進(jìn)行對查詢數(shù)據(jù)加鎖，加的是行鎖

3.4 方式四（悲觀鎖二）

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

Dao層

3.5 方式五（樂觀鎖）

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

樂觀鎖，不進(jìn)行庫存數(shù)量的校驗(yàn)，直接做庫存扣減

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

樂觀鎖會出現(xiàn)大量的數(shù)據(jù)更新異常（拋異常就會導(dǎo)致購買失?。?，會出現(xiàn)少買的情況，不推薦使用樂觀鎖

3.6 方式六（阻塞隊(duì)列）

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

阻塞隊(duì)列：這里使用靜態(tài)內(nèi)部類的方式來實(shí)現(xiàn)單例模式，在并發(fā)條件下不會出現(xiàn)問題。

注意：在業(yè)務(wù)層和AOP方法中，不能拋出任何異常， throw new RuntimeException()這些拋異常代碼要注釋掉。因?yàn)橐坏┏绦驋伋霎惓＞蜁Ｖ?，?dǎo)致消費(fèi)秒殺隊(duì)列進(jìn)程終止！

使用阻塞隊(duì)列來實(shí)現(xiàn)秒殺，有幾點(diǎn)要注意：

• 消費(fèi)秒殺隊(duì)列中調(diào)用業(yè)務(wù)方法加鎖與不加鎖情況一樣，也就是seckillService.startSecondKillByAop()、seckillService.startSecondKillByLock()方法結(jié)果一樣，這也很好理解

• 當(dāng)隊(duì)列長度與商品數(shù)量一致時，會出現(xiàn)少賣的現(xiàn)象，可以調(diào)大數(shù)值

• 下面是隊(duì)列長度1000，商品數(shù)量1000，并發(fā)數(shù)2000情況下出現(xiàn)的少賣

3.7.方式七（Disruptor隊(duì)列）

Disruptor是個高性能隊(duì)列，研發(fā)的初衷是解決內(nèi)存隊(duì)列的延遲問題，在性能測試中發(fā)現(xiàn)竟然與I/O操作處于同樣的數(shù)量級，基于Disruptor開發(fā)的系統(tǒng)單線程能支撐每秒600萬訂單。

經(jīng)過測試，發(fā)現(xiàn)使用Disruptor隊(duì)列隊(duì)列，與自定義隊(duì)列有著同樣的問題，也會出現(xiàn)超賣的情況，但效率有所提高。

4. 小結(jié)

對于上面七種實(shí)現(xiàn)并發(fā)的方式，做一下總結(jié)：

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

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

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

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

• 并發(fā)數(shù)1000，商品數(shù)100

• 并發(fā)數(shù)1000，商品數(shù)1000

• 并發(fā)數(shù)2000，商品數(shù)1000