背景引入

首先，我們一起來看看這個問題的背景？

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

假如下單時，用分布式鎖來防止庫存超賣，但是是每秒上千訂單的高并發(fā)場景，如何對分布式鎖進行高并發(fā)優(yōu)化來應對這個場景？

他說他當時沒答上來，因為沒做過沒什么思路。其實我當時聽到這個面試題心里也覺得有點意思，因為如果是我來面試候選人的話，應該會給的范圍更大一些。

比如，讓面試的同學聊一聊電商高并發(fā)秒殺場景下的庫存超賣解決方案，各種方案的優(yōu)缺點以及實踐，進而聊到分布式鎖這個話題。

因為庫存超賣問題是有很多種技術解決方案的，比如悲觀鎖，分布式鎖，樂觀鎖，隊列串行化，Redis原子操作，等等吧。

但是既然那個面試官兄弟限定死了用分布式鎖來解決庫存超賣，我估計就是想問一個點：在高并發(fā)場景下如何優(yōu)化分布式鎖的并發(fā)性能。

我覺得，面試官提問的角度還是可以接受的，因為在實際落地生產的時候，分布式鎖這個東西保證了數(shù)據(jù)的準確性，但是他天然并發(fā)能力有點弱。

剛好我之前在自己項目的其他場景下，確實是做過高并發(fā)場景下的分布式鎖優(yōu)化方案，因此正好是借著這個朋友的面試題，把分布式鎖的高并發(fā)優(yōu)化思路，給大家來聊一聊。

庫存超賣現(xiàn)象是怎么產生的？

先來看看如果不用分布式鎖，所謂的電商庫存超賣是啥意思？大家看看下面的圖：

這個圖，其實很清晰了，假設訂單系統(tǒng)部署兩臺機器上，不同的用戶都要同時買10臺iphone，分別發(fā)了一個請求給訂單系統(tǒng)。

接著每個訂單系統(tǒng)實例都去數(shù)據(jù)庫里查了一下，當前iphone庫存是12臺。

倆大兄弟一看，樂了，12臺庫存大于了要買的10臺數(shù)量啊！

于是乎，每個訂單系統(tǒng)實例都發(fā)送SQL到數(shù)據(jù)庫里下單，然后扣減了10個庫存，其中一個將庫存從12臺扣減為2臺，另外一個將庫存從2臺扣減為-8臺。

現(xiàn)在完了，庫存出現(xiàn)了負數(shù)！淚奔啊，沒有20臺iphone發(fā)給兩個用戶啊！這可如何是好。

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

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

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

代碼大概就是上面那個樣子，現(xiàn)在我們來分析一下，為啥這樣做可以避免庫存超賣？

大家可以順著上面的那個步驟序號看一遍，馬上就明白了。

從上圖可以看到，只有一個訂單系統(tǒng)實例可以成功加分布式鎖，然后只有他一個實例可以查庫存、判斷庫存是否充足、下單扣減庫存，接著釋放鎖。

釋放鎖之后，另外一個訂單系統(tǒng)實例才能加鎖，接著查庫存，一下發(fā)現(xiàn)庫存只有2臺了，庫存不足，無法購買，下單失敗。不會將庫存扣減為-8的。

有沒有其他方案可以解決庫存超賣問題？

當然有啊！比如悲觀鎖，分布式鎖，樂觀鎖，隊列串行化，異步隊列分散，Redis原子操作，等等，很多方案，我們對庫存超賣有自己的一整套優(yōu)化機制。

但是前面說過了，這篇文章就聊一個分布式鎖的并發(fā)優(yōu)化，不是聊庫存超賣的解決方案，所以庫存超賣只是一個業(yè)務場景而已。

以后有機會筆者會寫一篇文章，講講電商庫存超賣問題的解決方案，這篇文章先focus在一個分布式鎖并發(fā)優(yōu)化上，希望大家明白這個用意和背景，避免有的兄弟沒看清楚又吐槽。

好，現(xiàn)在我們來看看，分布式鎖的方案在高并發(fā)場景下有什么問題？

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

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

大家再回去對照上面的圖反復看一下，應該能想明白這個問題。

假設加鎖之后，釋放鎖之前，查庫存 -> 創(chuàng)建訂單 -> 扣減庫存，這個過程性能很高吧，算他全過程20毫秒，這應該不錯了。

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

比如一秒鐘來50個請求，都是對iphone下單的，那么每個請求處理20毫秒，一個一個來，最后1000毫秒正好處理完50個請求。

大家看一眼下面的圖，加深一下感覺。

所以看到這里，大家起碼也明白了，簡單的使用分布式鎖來處理庫存超賣問題，存在什么缺陷。

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

這種方案，要是應對那種低并發(fā)、無秒殺場景的普通小電商系統(tǒng)，可能還可以接受。

因為如果并發(fā)量很低，每秒就不到10個請求，沒有瞬時高并發(fā)秒殺單個商品的場景的話，其實也很少會對同一個商品在一秒內瞬間下1000個訂單，因為小電商系統(tǒng)沒那場景。

如何對分布式鎖進行高并發(fā)優(yōu)化？

好了，終于引入正題了，那么現(xiàn)在怎么辦呢？

面試官說，我現(xiàn)在就卡死，庫存超賣就是用分布式鎖來解決，而且一秒對一個iphone下上千訂單，怎么優(yōu)化？

現(xiàn)在按照剛才的計算，你一秒鐘只能處理針對iphone的50個訂單。

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

把數(shù)據(jù)分成很多個段，每個段是一個單獨的鎖，所以多個線程過來并發(fā)修改數(shù)據(jù)的時候，可以并發(fā)的修改不同段的數(shù)據(jù)。不至于說，同一時間只能有一個線程獨占修改ConcurrentHashMap中的數(shù)據(jù)。

另外，Java 8中新增了一個LongAdder類，也是針對Java 7以前的AtomicLong進行的優(yōu)化，解決的是CAS類操作在高并發(fā)場景下，使用樂觀鎖思路，會導致大量線程長時間重復循環(huán)。

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

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

但是庫存超賣這個業(yè)務場景不錯，很容易理解，所以我們就用這個場景來說一下。大家看看下面的圖：

其實這就是分段加鎖。你想，假如你現(xiàn)在iphone有1000個庫存，那么你完全可以給拆成20個庫存段，要是你愿意，可以在數(shù)據(jù)庫的表里建20個庫存字段，比如stock_01，stock_02，類似這樣的，也可以在redis之類的地方放20個庫存key。

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

接著，每秒1000個請求過來了，好！此時其實可以是自己寫一個簡單的隨機算法，每個請求都是隨機在20個分段庫存里，選擇一個進行加鎖。

bingo！這樣就好了，同時可以有最多20個下單請求一起執(zhí)行，每個下單請求鎖了一個庫存分段，然后在業(yè)務邏輯里面，就對數(shù)據(jù)庫或者是Redis中的那個分段庫存進行操作即可，包括查庫存 -> 判斷庫存是否充足 -> 扣減庫存。

這相當于什么呢？相當于一個20毫秒，可以并發(fā)處理掉20個下單請求，那么1秒，也就可以依次處理掉20 * 50 = 1000個對iphone的下單請求了。

一旦對某個數(shù)據(jù)做了分段處理之后，有一個坑大家一定要注意：就是如果某個下單請求，咔嚓加鎖，然后發(fā)現(xiàn)這個分段庫存里的庫存不足了，此時咋辦？

這時你得自動釋放鎖，然后立馬換下一個分段庫存，再次嘗試加鎖后嘗試處理。這個過程一定要實現(xiàn)。

分布式鎖并發(fā)優(yōu)化方案有沒有什么不足？

不足肯定是有的，最大的不足，大家發(fā)現(xiàn)沒有，很不方便啊！實現(xiàn)太復雜了。

• 首先，你得對一個數(shù)據(jù)分段存儲，一個庫存字段本來好好的，現(xiàn)在要分為20個分段庫存字段。
• 其次，你在每次處理庫存的時候，還得自己寫隨機算法，隨機挑選一個分段來處理。
• 最后，如果某個分段中的數(shù)據(jù)不足了，你還得自動切換到下一個分段數(shù)據(jù)去處理。

這個過程都是要手動寫代碼實現(xiàn)的，還是有點工作量，挺麻煩的。

不過我們確實在一些業(yè)務場景里，因為用到了分布式鎖，然后又必須要進行鎖并發(fā)的優(yōu)化，又進一步用到了分段加鎖的技術方案，效果當然是很好的了，一下子并發(fā)性能可以增長幾十倍。

該優(yōu)化方案的后續(xù)改進。

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

再次強調，我們這里的庫存超賣場景，僅僅只是作為演示場景而已，以后有機會，再單獨聊聊高并發(fā)秒殺系統(tǒng)架構下的庫存超賣的其他解決方案。

上篇文章的補充說明

本文最后做個說明，筆者收到一些朋友留言，說有朋友在技術群里看到上篇文章之后，吐槽了一通上一篇文章《?Redis 分布式鎖，沒它真不行！?》，說是那個Redis分布式鎖的實現(xiàn)原理把人給帶歪了。

在這兒得鄭重說明一下，上篇文章，明確說明了是Redisson那個開源框架對Redis鎖的實現(xiàn)原理，并不是我個人YY出來的那一套原理。

實際上Redisson作為一款優(yōu)秀的開源框架，我覺得他整體對分布式鎖的實現(xiàn)是OK的，雖然有一些缺陷，但是生產環(huán)境可用。

另外，有的兄弟可能覺得那個跟Redis官網(wǎng)作者給出的分布式鎖實現(xiàn)思路不同，所以就吐槽，說要遵循Redis官網(wǎng)中的作者的分布式鎖實現(xiàn)思路。

其實我必須指出，Redis官網(wǎng)中給出的僅僅是Redis分布式鎖的實現(xiàn)思路而已，記住，那是思路！思路跟落地生產環(huán)境的技術方案之間是有差距的。

比如說Redis官網(wǎng)給出的分布式鎖實現(xiàn)思路，并沒有給出到分布式鎖的自動續(xù)期機制、鎖的互斥自等待機制、鎖的可重入加鎖與釋放鎖的機制。但是Redisson框架對分布式鎖的實現(xiàn)是實現(xiàn)了一整套機制的。

所以重復一遍，那僅僅是思路，如果你愿意，你完全可以基于Redis官網(wǎng)的思路自己實現(xiàn)一套生產級的分布式鎖出來。

另外Redis官網(wǎng)給出的RedLock算法，一直是我個人并不推崇在生產使用的。

因為那套算法中可能存在一些邏輯問題，在國外是引發(fā)了爭議的，連Redis作者自己都在官網(wǎng)中給出了因為他的RedLock算法而引發(fā)爭議的文章，當然他自己是不太同意的。

但是這個事兒，就搞成公說公有理，婆說婆有理了。具體請參加官網(wǎng)原文：

Martin Kleppmann analyzed Redlock here. I disagree with the analysis and posted my reply to his analysis here。