原文：每秒上千訂單場景下的分散式鎖高併發優化實踐！【石杉的架構筆記】

背景引入

電商公司:假如下單時，用分散式鎖來防止庫存超賣，但是是每秒上千訂單的高併發場景，如何對分散式鎖進行高併發優化來應對這個場景？

在實際落地生產的時候，分散式鎖這個東西保證了資料的準確性，但是他天然併發能力有點弱。

庫存超賣現象的產生

假設訂單系統部署兩臺機器上，不同的使用者都要同時買10臺iphone，分別發了一個請求給訂單系統。
每個訂單系統例項都傳送SQL到資料庫裡下單，然後扣減了10個庫存，其中一個將庫存從12臺扣減為2臺，另外一個將庫存從2臺扣減為-8臺。

用分散式鎖解決庫存超賣問題

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

避免超賣

只有一個訂單系統例項可以成功加分散式鎖，然後只有他一個例項可以（下單時）查庫存、判斷庫存是否充足、下單扣減庫存，接著釋放鎖。

釋放鎖之後，另外一個訂單系統例項才能加鎖，接著查庫存，一下發現庫存只有2臺了，庫存不足，無法購買，下單失敗。不會將庫存扣減為-8的。

分散式鎖在高併發場景下的問題

分散式鎖一旦加了之後，對同一個商品的下單請求，會導致所有客戶端都必須對同一個商品的庫存鎖key進行加鎖。

比如，對iphone這個商品的下單，都必對“iphone_stock”這個鎖key來加鎖。這樣會導致對同一個商品的下單請求，就必須序列化，一個接一個的處理。

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

那麼1秒是1000毫秒，只能容納50個對這個商品的請求依次序列完成處理。

缺陷：同一個商品多使用者同時下單的時候，會基於分散式鎖序列化處理，導致沒法同時處理同一個商品的大量下單的請求。

這種方案，要是應對那種低併發、無秒殺場景的普通小電商系統，可能還可以接受。

對分散式鎖進行高併發優化

其實說出來也很簡單，看過java裡的ConcurrentHashMap的原始碼和底層原理，應該知道里面的 核心思路： 分段加鎖！

把資料分成很多個段，每個段是一個單獨的鎖，所以多個執行緒過來併發修改資料的時候，可以併發的修改不同段的資料。不至於說，同一時間只能有一個執行緒獨佔修改ConcurrentHashMap中的資料。

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

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

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

但是庫存超賣這個業務場景不錯，很容易理解，所以我們就用這個場景來說一下。

分段加鎖思想。假如你現在iphone有1000個庫存，那麼你完全可以給拆成20個庫存段，要是你願意，可以在資料庫的表裡建20個庫存欄位，每個庫存段是50件庫存，比如stock_01對應50件庫存，stock_02對應50件庫存。類似這樣的，也可以在redis之類的地方放20個庫存key。

接著，1000個/s 請求，用一個簡單的隨機演算法，每個請求都是隨機在20個分段庫存裡，選擇一個進行加鎖。

每個下單請求鎖了一個庫存分段，然後在業務邏輯裡面，就對資料庫或者是Redis中的那個分段庫存進行操作即可，包括查庫存 -> 判斷庫存是否充足 -> 扣減庫存。

相當於一個20毫秒，可以併發處理掉20個下單請求，那麼1秒，也就可以依次處理掉20 * 50 = 1000個對iphone的下單請求了。

一旦對某個資料做了分段處理之後，有一個坑一定要注意：就是如果某個下單請求，咔嚓加鎖，然後發現這個分段庫存裡的庫存不足了，此時咋辦？
這時你得自動釋放鎖，然後立馬換下一個分段庫存，再次嘗試加鎖後嘗試處理。 這個過程一定要實現。

分散式鎖併發優化方案的不足

最大的不足，很不方便，實現太複雜。

• 首先，你得對一個資料分段儲存，一個庫存欄位本來好好的，現在要分為20個分段庫存欄位；
• 其次，你在每次處理庫存的時候，還得自己寫隨機演算法，隨機挑選一個分段來處理；
• 最後，如果某個分段中的資料不足了，你還得自動切換到下一個分段資料去處理。

這個過程都是要手動寫程式碼實現的，還是有點工作量，挺麻煩的。

不過我們確實在一些業務場景裡，因為用到了分散式鎖，然後又必須要進行鎖併發的優化，又進一步用到了分段加鎖的技術方案，效果當然是很好的了，一下子併發效能可以增長几十倍。

該優化方案的後續改進

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

再次強調，我們這裡的庫存超賣場景，僅僅只是作為演示場景而已，以後有機會，再單獨聊聊高併發秒殺系統架構下的庫存超賣的其他解決方案。