只能用分佈式鎖，也能搞定每秒上千訂單的高併發優化？

今天給你們聊一個有意思的話題： 每秒上千訂單場景下，如何對分佈式鎖的併發能力進行優化？

背景引入

首先，咱們一塊兒來看看這個問題的背景？

前段時間有個朋友在外面面試，而後有一天找我聊說：有一個國內不錯的電商公司，面試官給他出了一個場景題：

假以下單時，用分佈式鎖來防止庫存超賣，可是是每秒上千訂單的高併發場景，如何對分佈式鎖進行高併發優化來應對這個場景？

他說他當時沒答上來，由於沒作過沒什麼思路。其實我當時聽到這個面試題內心也以爲有點意思，由於若是是我來面試候選人的話，應該會給的範圍更大一些。

好比讓面試的同窗聊一聊電商高併發秒殺場景下的庫存超賣解決方案，各類方案的優缺點以及實踐，進而聊到分佈式鎖這個話題。

由於庫存超賣問題是有不少種技術解決方案的，好比悲觀鎖，分佈式鎖，樂觀鎖，隊列串行化，Redis原子操做，等等吧。

可是既然那個面試官兄弟限定死了用分佈式鎖來解決庫存超賣，我估計就是想問一個點：在高併發場景下如何優化分佈式鎖的併發性能。

我以爲，面試官提問的角度仍是能夠接受的，由於在實際落地生產的時候，分佈式鎖這個東西保證了數據的準確性，可是他自然併發能力有點弱。

恰好我以前在本身項目的其餘場景下，確實是作太高併發場景下的分佈式鎖優化方案，所以正好是藉着這個朋友的面試題，把分佈式鎖的高併發優化思路，給你們來聊一聊。

庫存超賣現象是怎麼產生的？

先來看看若是不用分佈式鎖，所謂的電商庫存超賣是啥意思？你們看看下面的圖：

這個圖，其實很清晰了，假設訂單系統部署兩臺機器上，不一樣的用戶都要同時買10臺iphone，分別發了一個請求給訂單系統。接着每一個訂單系統實例都去數據庫裏查了一下，當前iphone庫存是12臺。

倆大兄弟一看，樂了，12臺庫存大於了要買的10臺數量啊！因而乎，每一個訂單系統實例都發送SQL到數據庫裏下單，而後扣減了10個庫存，其中一個將庫存從12臺扣減爲2臺，另一個將庫存從2臺扣減爲-8臺。

如今完了，庫存出現了負數！淚奔啊，沒有20臺iphone發給兩個用戶啊！這可如何是好。

用分佈式鎖如何解決庫存超賣問題？

咱們用分佈式鎖如何解決庫存超賣問題呢？其實很簡單，回憶一下上次咱們說的那個分佈式鎖的實現原理：

同一個鎖key，同一時間只能有一個客戶端拿到鎖，其餘客戶端會陷入無限的等待來嘗試獲取那個鎖，只有獲取到鎖的客戶端才能執行下面的業務邏輯。

代碼大概就是上面那個樣子，如今咱們來分析一下，爲啥這樣作能夠避免庫存超賣？

你們能夠順着上面的那個步驟序號看一遍，立刻就明白了。從上圖能夠看到，只有一個訂單系統實例能夠成功加分佈式鎖，而後只有他一個實例能夠查庫存、判斷庫存是否充足、下單扣減庫存，接着釋放鎖。

釋放鎖以後，另一個訂單系統實例才能加鎖，接着查庫存，一下發現庫存只有2臺了，庫存不足，沒法購買，下單失敗。不會將庫存扣減爲-8的。

有沒有其餘方案能夠解決庫存超賣問題？

固然有啊！好比悲觀鎖，分佈式鎖，樂觀鎖，隊列串行化，異步隊列分散，Redis原子操做，等等，不少方案，咱們對庫存超賣有本身的一整套優化機制。

可是前面說過了，這篇文章就聊一個分佈式鎖的併發優化，不是聊庫存超賣的解決方案，庫存超賣只是一個業務場景而已。

分佈式鎖的方案在高併發場景下

好，如今咱們來看看，分佈式鎖的方案在高併發場景下有什麼問題？

問題很大啊！兄弟，不知道你看出來了沒有。分佈式鎖一旦加了以後，對同一個商品的下單請求，會致使全部客戶端都必須對同一個商品的庫存鎖key進行加鎖。

好比，對iphone這個商品的下單，都必對「iphone_stock」這個鎖key來加鎖。這樣會致使對同一個商品的下單請求，就必須串行化，一個接一個的處理。你們再回去對照上面的圖反覆看一下，應該能想明白這個問題。

假設加鎖以後，釋放鎖以前，查庫存 -> 建立訂單 -> 扣減庫存，這個過程性能很高吧，算他全過程20毫秒，這應該不錯了。

那麼1秒是1000毫秒，只能容納50個對這個商品的請求依次串行完成處理。好比一秒鐘來50個請求，都是對iphone下單的，那麼每一個請求處理20毫秒，一個一個來，最後1000毫秒正好處理完50個請求。

你們看一眼下面的圖，加深一下感受。

因此看到這裏，你們起碼也明白了，簡單的使用分佈式鎖來處理庫存超賣問題，存在什麼缺陷。

缺陷就是同一個商品多用戶同時下單的時候，會基於分佈式鎖串行化處理，致使無法同時處理同一個商品的大量下單的請求。

這種方案，要是應對那種低併發、無秒殺場景的普通小電商系統，可能還能夠接受。由於若是併發量很低，每秒就不到10個請求，沒有瞬時高併發秒殺單個商品的場景的話，其實也不多會對同一個商品在一秒內瞬間下1000個訂單，由於小電商系統沒那場景。

如何對分佈式鎖進行高併發優化？

好了，終於引入正題了，那麼如今怎麼辦呢？

面試官說，我如今就卡死，庫存超賣就是用分佈式鎖來解決，並且一秒對一個iphone下上千訂單，怎麼優化？

如今按照剛纔的計算，你一秒鐘只能處理針對iphone的50個訂單。

其實說出來也很簡單，相信不少人看過java裏的ConcurrentHashMap的源碼和底層原理，應該知道里面的核心思路，就是 分段加鎖！

把數據分紅不少個段，每一個段是一個單獨的鎖，因此多個線程過來併發修改數據的時候，能夠併發的修改不一樣段的數據。不至於說，同一時間只能有一個線程獨佔修改ConcurrentHashMap中的數據。

另外，Java 8中新增了一個LongAdder類，也是針對Java 7之前的AtomicLong進行的優化，解決的是CAS類操做在高併發場景下，使用樂觀鎖思路，會致使大量線程長時間重複循環。

LongAdder中也是採用了相似的分段CAS操做，失敗則自動遷移到下一個分段進行CAS的思路。

其實分佈式鎖的優化思路也是相似的，以前咱們是在另一個業務場景下落地了這個方案到生產中，不是在庫存超賣問題裏用的。

可是庫存超賣這個業務場景不錯，很容易理解，因此咱們就用這個場景來講一下。你們看看下面的圖：

其實這就是分段加鎖。你想，假如你如今iphone有1000個庫存，那麼你徹底能夠給拆成20個庫存段，要是你願意，能夠在數據庫的表裏建20個庫存字段，好比stock_01，stock_02，相似這樣的，也能夠在redis之類的地方放20個庫存key。

總之，就是把你的1000件庫存給他拆開，每一個庫存段是50件庫存，好比stock_01對應50件庫存，stock_02對應50件庫存。

接着，每秒1000個請求過來了，好！此時其實能夠是本身寫一個簡單的隨機算法，每一個請求都是隨機在20個分段庫存裏，選擇一個進行加鎖。

bingo！這樣就行了，同時能夠有最多20個下單請求一塊兒執行，每一個下單請求鎖了一個庫存分段，而後在業務邏輯裏面，就對數據庫或者是Redis中的那個分段庫存進行操做便可，包括查庫存 -> 判斷庫存是否充足 -> 扣減庫存。

這至關於什麼呢？至關於一個20毫秒，能夠併發處理掉20個下單請求，那麼1秒，也就能夠依次處理掉20 * 50  = 1000個對iphone的下單請求了。

一旦對某個數據作了分段處理以後，有一個坑你們必定要注意：就是若是某個下單請求，咔嚓加鎖，而後發現這個分段庫存裏的庫存不足了，此時咋辦？

這時你得自動釋放鎖，而後立馬換下一個分段庫存，再次嘗試加鎖後嘗試處理。這個過程必定要實現。

分佈式鎖併發優化方案有沒有什麼不足？

不足確定是有的，最大的不足，你們發現沒有，很不方便啊！實現太複雜了。

• 首先，你得對一個數據分段存儲，一個庫存字段原本好好的，如今要分爲20個分段庫存字段；
• 其次，你在每次處理庫存的時候，還得本身寫隨機算法，隨機挑選一個分段來處理；
• 最後，若是某個分段中的數據不足了，你還得自動切換到下一個分段數據去處理。

這個過程都是要手動寫代碼實現的，仍是有點工做量，挺麻煩的。

不過咱們確實在一些業務場景裏，由於用到了分佈式鎖，而後又必需要進行鎖併發的優化，又進一步用到了分段加鎖的技術方案，效果固然是很好的了，一會兒併發性能能夠增加幾十倍。

該優化方案的後續改進

以咱們本文所說的庫存超賣場景爲例，你要是這麼玩，會把本身搞的很痛苦！

再次強調，咱們這裏的庫存超賣場景，僅僅只是做爲演示場景而已，之後有機會，再單獨聊聊高併發秒殺系統架構下的庫存超賣的其餘解決方案。

推薦閱讀

字節跳動總結的設計模式 PDF 火了，完整版開放分享

刷Github時發現了一本阿里大神的算法筆記！標星70.5K

若是能聽懂這個網約車實戰，哪怕接私活你均可以月入40K

爲何阿里巴巴的程序員成長速度這麼快，看完他們的內部資料我懂了

程序員達到50W年薪所須要具有的知識體系。

關於【暴力遞歸算法】你所不知道的思路

看完三件事❤️

若是你以爲這篇內容對你還蠻有幫助，我想邀請你幫我三個小忙：

點贊，轉發，有大家的 『點贊和評論』，纔是我創造的動力。

關注公衆號 『 Java鬥帝 』，不按期分享原創知識。

同時能夠期待後續文章ing🚀