“上一篇文章我們聊了聊Redisson這個(gè)開源框架對(duì)Redis分布式鎖的實(shí)現(xiàn)原理蹭劈，如果有不了解的兄弟可以看一下：拜托缔俄，面試請(qǐng)不要再問我Redis分布式鎖的實(shí)現(xiàn)原理弛秋。

今天就給大家聊一個(gè)有意思的話題：每秒上千訂單場景下，如何對(duì)分布式鎖的并發(fā)能力進(jìn)行優(yōu)化俐载？

背景引入

首先铐懊，我們一起來看看這個(gè)問題的背景？

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

假如下單時(shí)，用分布式鎖來防止庫存超賣贼急，但是是每秒上千訂單的高并發(fā)場景茅茂，如何對(duì)分布式鎖進(jìn)行高并發(fā)優(yōu)化來應(yīng)對(duì)這個(gè)場景捏萍？

他說他當(dāng)時(shí)沒答上來，因?yàn)闆]做過沒什么思路空闲。其實(shí)我當(dāng)時(shí)聽到這個(gè)面試題心里也覺得有點(diǎn)意思令杈，因?yàn)槿绻俏襾砻嬖嚭蜻x人的話，應(yīng)該會(huì)給的范圍更大一些碴倾。

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

因?yàn)閹齑娉u問題是有很多種技術(shù)解決方案的，比如悲觀鎖僧须，分布式鎖纲刀，樂觀鎖，隊(duì)列串行化担平，Redis原子操作示绊，等等吧。

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

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

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

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

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

網(wǎng)絡(luò)異常

取消

重新上傳

這個(gè)圖盗尸，其實(shí)很清晰了，假設(shè)訂單系統(tǒng)部署兩臺(tái)機(jī)器上帽撑，不同的用戶都要同時(shí)買10臺(tái)iphone泼各，分別發(fā)了一個(gè)請(qǐng)求給訂單系統(tǒng)。

接著每個(gè)訂單系統(tǒng)實(shí)例都去數(shù)據(jù)庫里查了一下亏拉，當(dāng)前iphone庫存是12臺(tái)扣蜻。

倆大兄弟一看逆巍，樂了，12臺(tái)庫存大于了要買的10臺(tái)數(shù)量懊埂锐极！

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

現(xiàn)在完了翎迁，庫存出現(xiàn)了負(fù)數(shù)！淚奔啊责嚷，沒有20臺(tái)iphone發(fā)給兩個(gè)用戶霸蕖！這可如何是好罕拂。

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

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

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

網(wǎng)絡(luò)異常

取消

重新上傳

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

網(wǎng)絡(luò)異常

取消

重新上傳

大家可以順著上面的那個(gè)步驟序號(hào)看一遍，馬上就明白了凉泄。

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

釋放鎖之后教藻，另外一個(gè)訂單系統(tǒng)實(shí)例才能加鎖，接著查庫存右锨，一下發(fā)現(xiàn)庫存只有2臺(tái)了括堤，庫存不足，無法購買，下單失敗痊臭。不會(huì)將庫存扣減為-8的哮肚。

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

當(dāng)然有肮愠住每界！比如悲觀鎖夫椭，分布式鎖咽块，樂觀鎖锭碳，隊(duì)列串行化，異步隊(duì)列分散分唾，Redis原子操作抗碰，等等，很多方案绽乔，我們對(duì)庫存超賣有自己的一整套優(yōu)化機(jī)制弧蝇。

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

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

而且建議大家即使對(duì)文章里的內(nèi)容有異議，公眾號(hào)后臺(tái)給我留言跟我討論一下删顶，技術(shù)竖螃，就是要多交流，打開思路逗余，碰撞思維特咆。

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

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

問題很大笆癖浮关摇！兄弟，不知道你看出來了沒有碾阁。分布式鎖一旦加了之后输虱，對(duì)同一個(gè)商品的下單請(qǐng)求，會(huì)導(dǎo)致所有客戶端都必須對(duì)同一個(gè)商品的庫存鎖key進(jìn)行加鎖脂凶。

比如宪睹，對(duì)iphone這個(gè)商品的下單愁茁，都必對(duì)“iphone_stock”這個(gè)鎖key來加鎖。這樣會(huì)導(dǎo)致對(duì)同一個(gè)商品的下單請(qǐng)求亭病，就必須串行化鹅很，一個(gè)接一個(gè)的處理。

大家再回去對(duì)照上面的圖反復(fù)看一下罪帖，應(yīng)該能想明白這個(gè)問題促煮。

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

那么1秒是1000毫秒，只能容納50個(gè)對(duì)這個(gè)商品的請(qǐng)求依次串行完成處理炸客。

比如一秒鐘來50個(gè)請(qǐng)求疾棵，都是對(duì)iphone下單的，那么每個(gè)請(qǐng)求處理20毫秒嚷量，一個(gè)一個(gè)來陋桂，最后1000毫秒正好處理完50個(gè)請(qǐng)求。

大家看一眼下面的圖蝶溶，加深一下感覺嗜历。

>need-to-insert-img

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

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

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

因?yàn)槿绻l(fā)量很低窒典，每秒就不到10個(gè)請(qǐng)求，沒有瞬時(shí)高并發(fā)秒殺單個(gè)商品的場景的話稽莉，其實(shí)也很少會(huì)對(duì)同一個(gè)商品在一秒內(nèi)瞬間下1000個(gè)訂單瀑志，因?yàn)樾‰娚滔到y(tǒng)沒那場景。

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

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

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

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

其實(shí)說出來也很簡單湖饱，相信很多人看過java里的ConcurrentHashMap的源碼和底層原理，應(yīng)該知道里面的核心思路杀捻，就是分段加鎖井厌！

把數(shù)據(jù)分成很多個(gè)段，每個(gè)段是一個(gè)單獨(dú)的鎖致讥，所以多個(gè)線程過來并發(fā)修改數(shù)據(jù)的時(shí)候仅仆，可以并發(fā)的修改不同段的數(shù)據(jù)。不至于說垢袱，同一時(shí)間只能有一個(gè)線程獨(dú)占修改ConcurrentHashMap中的數(shù)據(jù)墓拜。

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

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

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

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

>need-to-insert-img

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

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

接著泣洞，每秒1000個(gè)請(qǐng)求過來了，好默色！此時(shí)其實(shí)可以是自己寫一個(gè)簡單的隨機(jī)算法球凰，每個(gè)請(qǐng)求都是隨機(jī)在20個(gè)分段庫存里，選擇一個(gè)進(jìn)行加鎖腿宰。

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

這相當(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è)分段庫存里的庫存不足了亿虽，此時(shí)咋辦？

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

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

不足肯定是有的攻走，最大的不足，大家發(fā)現(xiàn)沒有此再，很不方便拔袈А！實(shí)現(xiàn)太復(fù)雜了输拇。

首先摘符，你得對(duì)一個(gè)數(shù)據(jù)分段存儲(chǔ)，一個(gè)庫存字段本來好好的策吠，現(xiàn)在要分為20個(gè)分段庫存字段逛裤；

其次，你在每次處理庫存的時(shí)候猴抹，還得自己寫隨機(jī)算法带族，隨機(jī)挑選一個(gè)分段來處理；

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

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

不過我們確實(shí)在一些業(yè)務(wù)場景里薪介，因?yàn)橛玫搅朔植际芥i祠饺，然后又必須要進(jìn)行鎖并發(fā)的優(yōu)化，又進(jìn)一步用到了分段加鎖的技術(shù)方案汁政，效果當(dāng)然是很好的了道偷，一下子并發(fā)性能可以增長幾十倍。

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

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

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

上篇文章的補(bǔ)充說明

本文最后做個(gè)說明，筆者收到一些朋友留言誓禁，說有朋友在技術(shù)群里看到上篇文章之后懈息，吐槽了一通上一篇文章（拜托，面試請(qǐng)不要再問我Redis分布式鎖的實(shí)現(xiàn)原理）摹恰，說是那個(gè)Redis分布式鎖的實(shí)現(xiàn)原理把人給帶歪了辫继。

在這兒得鄭重說明一下怒见，上篇文章，明確說明了是Redisson那個(gè)開源框架對(duì)Redis鎖的實(shí)現(xiàn)原理姑宽，并不是我個(gè)人YY出來的那一套原理遣耍。

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

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

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

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

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

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

因?yàn)槟翘姿惴ㄖ锌赡艽嬖谝恍┻壿媶栴}争拐，在國外是引發(fā)了爭議的腋粥，連Redis作者自己都在官網(wǎng)中給出了因?yàn)樗腞edLock算法而引發(fā)爭議的文章，當(dāng)然他自己是不太同意的架曹。

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

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

因此下回有機(jī)會(huì)，我會(huì)通過大量手繪圖的形式绳慎，給大家寫一下Redis官方作者自己提出的RedLock分布式鎖的算法纵竖，以及該算法基于Redisson框架如何落地生產(chǎn)環(huán)境使用漠烧，到時(shí)大家可以再討論。