本文授權(quán)轉(zhuǎn)自石杉的架構(gòu)筆記

背景引入

首先，我們一起來(lái)看看這個(gè)問(wèn)題的背景？

前段時(shí)間有個(gè)朋友在外面面試，然后有一天找我聊說(shuō)：有一個(gè)國(guó)內(nèi)不錯(cuò)的電商公司，面試官給他出了一個(gè)場(chǎng)景題：

假如下單時(shí)，用分布式鎖來(lái)防止庫(kù)存超賣(mài)，但是是每秒上千訂單的高并發(fā)場(chǎng)景，如何對(duì)分布式鎖進(jìn)行高并發(fā)優(yōu)化來(lái)應(yīng)對(duì)這個(gè)場(chǎng)景？

他說(shuō)他當(dāng)時(shí)沒(méi)答上來(lái)，因?yàn)闆](méi)做過(guò)沒(méi)什么思路。其實(shí)我當(dāng)時(shí)聽(tīng)到這個(gè)面試題心里也覺(jué)得有點(diǎn)意思，因?yàn)槿绻俏襾?lái)面試候選人的話，應(yīng)該會(huì)給的范圍更大一些。

比如讓面試的同學(xué)聊一聊電商高并發(fā)秒殺場(chǎng)景下的庫(kù)存超賣(mài)解決方案，各種方案的優(yōu)缺點(diǎn)以及實(shí)踐，進(jìn)而聊到分布式鎖這個(gè)話題。

因?yàn)閹?kù)存超賣(mài)問(wèn)題是有很多種技術(shù)解決方案的，比如悲觀鎖，分布式鎖，樂(lè)觀鎖，隊(duì)列串行化，Redis原子操作，等等吧。

但是既然那個(gè)面試官兄弟限定死了用分布式鎖來(lái)解決庫(kù)存超賣(mài)，我估計(jì)就是想問(wèn)一個(gè)點(diǎn)：在高并發(fā)場(chǎng)景下如何優(yōu)化分布式鎖的并發(fā)性能

我覺(jué)得，面試官提問(wèn)的角度還是可以接受的，因?yàn)樵趯?shí)際落地生產(chǎn)的時(shí)候，分布式鎖這個(gè)東西保證了數(shù)據(jù)的準(zhǔn)確性，但是他天然并發(fā)能力有點(diǎn)弱。

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

庫(kù)存超賣(mài)現(xiàn)象是怎么產(chǎn)生的？

先來(lái)看看如果不用分布式鎖，所謂的電商庫(kù)存超賣(mài)是啥意思？大家看看下面的圖：

這個(gè)圖，其實(shí)很清晰了，假設(shè)訂單系統(tǒng)部署兩臺(tái)機(jī)器上，不同的用戶都要同時(shí)買(mǎi)10臺(tái)iphone，分別發(fā)了一個(gè)請(qǐng)求給訂單系統(tǒng)。接著每個(gè)訂單系統(tǒng)實(shí)例都去數(shù)據(jù)庫(kù)里查了一下，當(dāng)前iphone庫(kù)存是12臺(tái)。

倆大兄弟一看，樂(lè)了，12臺(tái)庫(kù)存大于了要買(mǎi)的10臺(tái)數(shù)量??！于是乎，每個(gè)訂單系統(tǒng)實(shí)例都發(fā)送SQL到數(shù)據(jù)庫(kù)里下單，然后扣減了10個(gè)庫(kù)存，其中一個(gè)將庫(kù)存從12臺(tái)扣減為2臺(tái)，另外一個(gè)將庫(kù)存從2臺(tái)扣減為-8臺(tái)。

現(xiàn)在完了，庫(kù)存出現(xiàn)了負(fù)數(shù)！淚奔啊，沒(méi)有20臺(tái)iphone發(fā)給兩個(gè)用戶?。∵@可如何是好。

用分布式鎖如何解決庫(kù)存超賣(mài)問(wèn)題？

我們用分布式鎖如何解決庫(kù)存超賣(mài)問(wèn)題呢？其實(shí)很簡(jiǎn)單，回憶一下上次我們說(shuō)的那個(gè)分布式鎖的實(shí)現(xiàn)原理：

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

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

大家可以順著上面的那個(gè)步驟序號(hào)看一遍，馬上就明白了。從上圖可以看到，只有一個(gè)訂單系統(tǒng)實(shí)例可以成功加分布式鎖，然后只有他一個(gè)實(shí)例可以查庫(kù)存、判斷庫(kù)存是否充足、下單扣減庫(kù)存，接著釋放鎖。

釋放鎖之后，另外一個(gè)訂單系統(tǒng)實(shí)例才能加鎖，接著查庫(kù)存，一下發(fā)現(xiàn)庫(kù)存只有2臺(tái)了，庫(kù)存不足，無(wú)法購(gòu)買(mǎi)，下單失敗。不會(huì)將庫(kù)存扣減為-8的。

有沒(méi)有其他方案可以解決庫(kù)存超賣(mài)問(wèn)題？

當(dāng)然有??！比如悲觀鎖，分布式鎖，樂(lè)觀鎖，隊(duì)列串行化，異步隊(duì)列分散，Redis原子操作，等等，很多方案，我們對(duì)庫(kù)存超賣(mài)有自己的一整套優(yōu)化機(jī)制。

但是前面說(shuō)過(guò)了，這篇文章就聊一個(gè)分布式鎖的并發(fā)優(yōu)化，不是聊庫(kù)存超賣(mài)的解決方案，庫(kù)存超賣(mài)只是一個(gè)業(yè)務(wù)場(chǎng)景而已。

分布式鎖的方案在高并發(fā)場(chǎng)景下

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

問(wèn)題很大??！兄弟，不知道你看出來(lái)了沒(méi)有。分布式鎖一旦加了之后，對(duì)同一個(gè)商品的下單請(qǐng)求，會(huì)導(dǎo)致所有客戶端都必須對(duì)同一個(gè)商品的庫(kù)存鎖key進(jìn)行加鎖

比如，對(duì)iphone這個(gè)商品的下單，都必對(duì)“iphone_stock”這個(gè)鎖key來(lái)加鎖。這樣會(huì)導(dǎo)致對(duì)同一個(gè)商品的下單請(qǐng)求，就必須串行化，一個(gè)接一個(gè)的處理。大家再回去對(duì)照上面的圖反復(fù)看一下，應(yīng)該能想明白這個(gè)問(wèn)題。

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

那么1秒是1000毫秒，只能容納50個(gè)對(duì)這個(gè)商品的請(qǐng)求依次串行完成處理。比如一秒鐘來(lái)50個(gè)請(qǐng)求，都是對(duì)iphone下單的，那么每個(gè)請(qǐng)求處理20毫秒，一個(gè)一個(gè)來(lái)，最后1000毫秒正好處理完50個(gè)請(qǐng)求。

大家看一眼下面的圖，加深一下感覺(jué)。

所以看到這里，大家起碼也明白了，簡(jiǎn)單的使用分布式鎖來(lái)處理庫(kù)存超賣(mài)問(wèn)題，存在什么缺陷。

缺陷就是同一個(gè)商品多用戶同時(shí)下單的時(shí)候，會(huì)基于分布式鎖串行化處理，導(dǎo)致沒(méi)法同時(shí)處理同一個(gè)商品的大量下單的請(qǐng)求。

這種方案，要是應(yīng)對(duì)那種低并發(fā)、無(wú)秒殺場(chǎng)景的普通小電商系統(tǒng)，可能還可以接受。因?yàn)槿绻l(fā)量很低，每秒就不到10個(gè)請(qǐng)求，沒(méi)有瞬時(shí)高并發(fā)秒殺單個(gè)商品的場(chǎng)景的話，其實(shí)也很少會(huì)對(duì)同一個(gè)商品在一秒內(nèi)瞬間下1000個(gè)訂單，因?yàn)樾‰娚滔到y(tǒng)沒(méi)那場(chǎng)景。

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

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

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

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

其實(shí)說(shuō)出來(lái)也很簡(jiǎn)單，相信很多人看過(guò)java里的ConcurrentHashMap的源碼和底層原理，應(yīng)該知道里面的核心思路，就是分段加鎖！

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

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

LongAdder中也是采用了類似的分段CAS操作，失敗則自動(dòng)遷移到下一個(gè)分段進(jìn)行CAS的思路。

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

但是庫(kù)存超賣(mài)這個(gè)業(yè)務(wù)場(chǎng)景不錯(cuò)，很容易理解，所以我們就用這個(gè)場(chǎng)景來(lái)說(shuō)一下。大家看看下面的圖：

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

總之，就是把你的1000件庫(kù)存給他拆開(kāi)，每個(gè)庫(kù)存段是50件庫(kù)存，比如stock_01對(duì)應(yīng)50件庫(kù)存，stock_02對(duì)應(yīng)50件庫(kù)存。

接著，每秒1000個(gè)請(qǐng)求過(guò)來(lái)了，好！此時(shí)其實(shí)可以是自己寫(xiě)一個(gè)簡(jiǎn)單的隨機(jī)算法，每個(gè)請(qǐng)求都是隨機(jī)在20個(gè)分段庫(kù)存里，選擇一個(gè)進(jìn)行加鎖。

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

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

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

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

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

不足肯定是有的，最大的不足，大家發(fā)現(xiàn)沒(méi)有，很不方便??！實(shí)現(xiàn)太復(fù)雜了。

• 首先，你得對(duì)一個(gè)數(shù)據(jù)分段存儲(chǔ)，一個(gè)庫(kù)存字段本來(lái)好好的，現(xiàn)在要分為20個(gè)分段庫(kù)存字段；

• 其次，你在每次處理庫(kù)存的時(shí)候，還得自己寫(xiě)隨機(jī)算法，隨機(jī)挑選一個(gè)分段來(lái)處理；

• 最后，如果某個(gè)分段中的數(shù)據(jù)不足了，你還得自動(dòng)切換到下一個(gè)分段數(shù)據(jù)去處理。

這個(gè)過(guò)程都是要手動(dòng)寫(xiě)代碼實(shí)現(xiàn)的，還是有點(diǎn)工作量，挺麻煩的。

不過(guò)我們確實(shí)在一些業(yè)務(wù)場(chǎng)景里，因?yàn)橛玫搅?a href="/tags/分布式" target="_blank">分布式鎖，然后又必須要進(jìn)行鎖并發(fā)的優(yōu)化，又進(jìn)一步用到了分段加鎖的技術(shù)方案，效果當(dāng)然是很好的了，一下子并發(fā)性能可以增長(zhǎng)幾十倍。

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

以我們本文所說(shuō)的庫(kù)存超賣(mài)場(chǎng)景為例，你要是這么玩，會(huì)把自己搞的很痛苦！

再次強(qiáng)調(diào)，我們這里的庫(kù)存超賣(mài)場(chǎng)景，僅僅只是作為演示場(chǎng)景而已，以后有機(jī)會(huì)，再單獨(dú)聊聊高并發(fā)秒殺系統(tǒng)架構(gòu)下的庫(kù)存超賣(mài)的其他解決方案。

作者：中華石杉，十余年BAT架構(gòu)經(jīng)驗(yàn)傾囊相授。個(gè)人微信公眾號(hào)：石杉的架構(gòu)筆記（ID：shishan100）

特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒(méi)關(guān)注的小伙伴，可以長(zhǎng)按關(guān)注一下：

長(zhǎng)按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠(chéng)摯感謝