作者介紹

現(xiàn)在面試都會(huì)聊聊分布式系統(tǒng)，通常面試官都會(huì)從服務(wù)框架（Spring Cloud,、Dubbo）,，一路聊到分布式事務(wù)、分布式鎖,、ZooKeeper等知識(shí),。今天就來(lái)聊聊分布式鎖這塊的知識(shí),，先具體的來(lái)看看Redis分布式鎖的實(shí)現(xiàn)原理。

如果在公司里落地生產(chǎn)環(huán)境用分布式鎖的時(shí)候,，一定是會(huì)用開(kāi)源類(lèi)庫(kù)的,，比如Redis分布式鎖，一般就是用Redisson框架就好了,，非常的簡(jiǎn)便易用,。感興趣可以去Redisson官網(wǎng)看看如何在項(xiàng)目中引入Redisson的依賴，然后基于Redis實(shí)現(xiàn)分布式鎖的加鎖與釋放鎖,。

一段簡(jiǎn)單的使用代碼片段,，先直觀的感受一下：

是不是感覺(jué)簡(jiǎn)單的不行,！此外，還支持Redis單實(shí)例,、Redis哨兵,、Redis Cluster、redis master-slave等各種部署架構(gòu),，都可以完美實(shí)現(xiàn)。

一,、Redisson實(shí)現(xiàn)Redis分布式鎖的底層原理

現(xiàn)在通過(guò)一張手繪圖,，說(shuō)說(shuō)Redisson這個(gè)開(kāi)源框架對(duì)Redis分布式鎖的實(shí)現(xiàn)原理。

1、加鎖機(jī)制

看上面那張圖,，現(xiàn)在某個(gè)客戶端要加鎖,。如果該客戶端面對(duì)的是一個(gè)Redis Cluster集群，他首先會(huì)根據(jù)Hash節(jié)點(diǎn)選擇一臺(tái)機(jī)器,。

注：僅僅只是選擇一臺(tái)機(jī)器,！然后發(fā)送一段Lua腳本到Redis上，那段Lua腳本如下所示：

為啥要用Lua腳本呢？因?yàn)橐淮筵鐝?fù)雜的業(yè)務(wù)邏輯,，可以通過(guò)封裝在Lua腳本中發(fā)送給Redis,，保證這段復(fù)雜業(yè)務(wù)邏輯執(zhí)行的原子性。

那么,，這段Lua腳本是什么意思呢,？這里KEYS[1]代表的是你加鎖的那個(gè)Key,，比如說(shuō)：RLock lock = redisson.getLock('myLock')；這里你自己設(shè)置了加鎖的那個(gè)鎖Key就是“myLock”,。

• ARGV[1]代表的就是鎖Key的默認(rèn)生存時(shí)間,，默認(rèn)30秒。

• ARGV[2]代表的是加鎖的客戶端的ID,，類(lèi)似于下面這樣的：8743c9c0-0795-4907-87fd-6c719a6b4586:1,。

第一段if判斷語(yǔ)句，就是用“exists myLock”命令判斷一下,，如果你要加鎖的那個(gè)鎖Key不存在的話,，你就進(jìn)行加鎖。如何加鎖呢,？很簡(jiǎn)單,，用下面的命令：hset myLock。

8743c9c0-0795-4907-87fd-6c719a6b4586:11,，通過(guò)這個(gè)命令設(shè)置一個(gè)Hash數(shù)據(jù)結(jié)構(gòu),，這行命令執(zhí)行后，會(huì)出現(xiàn)一個(gè)類(lèi)似下面的數(shù)據(jù)結(jié)構(gòu)：

上述內(nèi)容就代表“8743c9c0-0795-4907-87fd-6c719a6b4586:1”這個(gè)客戶端，已經(jīng)對(duì)“myLock”這個(gè)鎖Key完成了加鎖,。

接著會(huì)執(zhí)行“pexpiremyLock 30000”命令,，設(shè)置myLock這個(gè)鎖Key的生存時(shí)間是30秒，加鎖完成,。

2,、鎖互斥機(jī)制

這個(gè)時(shí)候，如果客戶端2來(lái)嘗試加鎖,，執(zhí)行了同樣的一段Lua腳本,，會(huì)怎樣？

第一個(gè)if判斷會(huì)執(zhí)行“exists myLock”,，發(fā)現(xiàn)myLock這個(gè)鎖Key已經(jīng)存在了,。

第二個(gè)if判斷，判斷myLock鎖Key的Hash數(shù)據(jù)結(jié)構(gòu)中,，是否包含客戶端2的ID,，但是明顯不是的,，因?yàn)槟抢锇氖强蛻舳?的ID,。

所以,，客戶端2會(huì)獲取到pttl myLock返回的一個(gè)數(shù)字,，這個(gè)數(shù)字代表了myLock這個(gè)鎖Key的剩余生存時(shí)間,。比如還剩15000毫秒的生存時(shí)間,。此時(shí)客戶端2會(huì)進(jìn)入一個(gè)while循環(huán),，不停的嘗試加鎖,。

3、watch dog自動(dòng)延期機(jī)制

客戶端1加鎖的鎖Key默認(rèn)生存時(shí)間才30秒,，如果超過(guò)了30秒,，客戶端1還想一直持有這把鎖，怎么辦呢,？

只要客戶端1加鎖成功,，就會(huì)啟動(dòng)一個(gè)watchdog看門(mén)狗，這個(gè)后臺(tái)線程,，會(huì)每隔10秒檢查一下,，如果客戶端1還持有鎖Key，就會(huì)不斷的延長(zhǎng)鎖Key的生存時(shí)間,。

4,、可重入加鎖機(jī)制

那如果客戶端1都已經(jīng)持有了這把鎖了，結(jié)果可重入的加鎖會(huì)怎么樣呢,？如下代碼：

分析一下上面那段Lua腳本,。第一個(gè)if判斷肯定不成立,，“exists myLock”會(huì)顯示鎖Key已經(jīng)存在了。

第二個(gè)if判斷會(huì)成立,，因?yàn)閙yLock的Hash數(shù)據(jù)結(jié)構(gòu)中包含的那個(gè)ID,，就是客戶端1的那個(gè)ID，也就是“8743c9c0-0795-4907-87fd-6c719a6b4586:1”,。

此時(shí)就會(huì)執(zhí)行可重入加鎖的邏輯,，incrby myLock 8743c9c0-0795-4907-87fd-6c71a6b4586:11,，通過(guò)這個(gè)命令,，對(duì)客戶端1的加鎖次數(shù)，累加1,。

此時(shí)myLock數(shù)據(jù)結(jié)構(gòu)變?yōu)橄旅孢@樣：

myLock的Hash數(shù)據(jù)結(jié)構(gòu)中的那個(gè)客戶端ID,，就對(duì)應(yīng)著加鎖的次數(shù),。

5、釋放鎖機(jī)制

如果執(zhí)行l(wèi)ock.unlock,，就可以釋放分布式鎖,，此時(shí)的業(yè)務(wù)邏輯也是非常簡(jiǎn)單的。就是每次都對(duì)myLock數(shù)據(jù)結(jié)構(gòu)中的那個(gè)加鎖次數(shù)減1。

如果發(fā)現(xiàn)加鎖次數(shù)是0了,，說(shuō)明這個(gè)客戶端已經(jīng)不再持有鎖了,，此時(shí)就會(huì)用：“del myLock”命令，從Redis里刪除這個(gè)Key,。

而另外的客戶端2就可以嘗試完成加鎖了,。這就是所謂的分布式鎖的開(kāi)源Redisson框架的實(shí)現(xiàn)機(jī)制。

一般我們?cè)谏a(chǎn)系統(tǒng)中,，可以用Redisson框架提供的這個(gè)類(lèi)庫(kù)來(lái)基于Redis進(jìn)行分布式鎖的加鎖與釋放鎖,。

6、上述Redis分布式鎖的缺點(diǎn)

上面那種方案最大的問(wèn)題,，就是如果你對(duì)某個(gè)Redis Master實(shí)例,，寫(xiě)入了myLock這種鎖Key的Value，此時(shí)會(huì)異步復(fù)制給對(duì)應(yīng)的Master Slave實(shí)例,。

但是這個(gè)過(guò)程中一旦發(fā)生Redis Master宕機(jī),，主備切換，Redis Slave變?yōu)榱薘edis Master,。

會(huì)導(dǎo)致客戶端2嘗試加鎖時(shí),，在新的Redis Master上完成加鎖，客戶端1也以為自己成功加鎖,。

此時(shí)就會(huì)導(dǎo)致多個(gè)客戶端對(duì)一個(gè)分布式鎖完成了加鎖,。這時(shí)系統(tǒng)在業(yè)務(wù)語(yǔ)義上一定會(huì)出現(xiàn)問(wèn)題，導(dǎo)致各種臟數(shù)據(jù)的產(chǎn)生,。

所以這個(gè)就是Redis Cluster,，或者是redis master-slave架構(gòu)的主從異步復(fù)制導(dǎo)致的Redis分布式鎖的最大缺陷：在Redis Master實(shí)例宕機(jī)的時(shí)候，可能導(dǎo)致多個(gè)客戶端同時(shí)完成加鎖,。

二,、七張圖徹底講清楚ZooKeeper分布式鎖的實(shí)現(xiàn)原理

下面再聊一下ZooKeeper實(shí)現(xiàn)分布式鎖的原理。同理,，我是直接基于比較常用的Curator這個(gè)開(kāi)源框架,，聊一下這個(gè)框架對(duì)ZooKeeper（以下簡(jiǎn)稱ZK）分布式鎖的實(shí)現(xiàn),。

一般除了大公司是自行封裝分布式鎖框架之外，建議大家用這些開(kāi)源框架封裝好的分布式鎖實(shí)現(xiàn),，這是一個(gè)比較快捷省事的方式,。

ZooKeeper分布式鎖機(jī)制

看看多客戶端獲取及釋放ZK分布式鎖的整個(gè)流程及背后的原理。首先看看下圖,，如果現(xiàn)在有兩個(gè)客戶端一起要爭(zhēng)搶ZK上的一把分布式鎖,，會(huì)是個(gè)什么場(chǎng)景？

如果大家對(duì)ZK還不太了解的話，建議先自行百度一下,，簡(jiǎn)單了解點(diǎn)基本概念,，比如ZK有哪些節(jié)點(diǎn)類(lèi)型等等。

參見(jiàn)上圖,。ZK里有一把鎖,，這個(gè)鎖就是ZK上的一個(gè)節(jié)點(diǎn)。兩個(gè)客戶端都要來(lái)獲取這個(gè)鎖,，具體是怎么來(lái)獲取呢,？

假設(shè)客戶端A搶先一步，對(duì)ZK發(fā)起了加分布式鎖的請(qǐng)求,，這個(gè)加鎖請(qǐng)求是用到了ZK中的一個(gè)特殊的概念,，叫做“臨時(shí)順序節(jié)點(diǎn)”。簡(jiǎn)單來(lái)說(shuō),，就是直接在'my_lock'這個(gè)鎖節(jié)點(diǎn)下,，創(chuàng)建一個(gè)順序節(jié)點(diǎn)，這個(gè)順序節(jié)點(diǎn)有ZK內(nèi)部自行維護(hù)的一個(gè)節(jié)點(diǎn)序號(hào),。

• 比如第一個(gè)客戶端來(lái)搞一個(gè)順序節(jié)點(diǎn),，ZK內(nèi)部會(huì)給起個(gè)名字叫做：xxx-000001。

• 然后第二個(gè)客戶端來(lái)搞一個(gè)順序節(jié)點(diǎn),，ZK可能會(huì)起個(gè)名字叫做：xxx-000002,。

• 注意，最后一個(gè)數(shù)字都是依次遞增的,，從1開(kāi)始逐次遞增,。ZK會(huì)維護(hù)這個(gè)順序,。

所以這個(gè)時(shí)候,，假如說(shuō)客戶端A先發(fā)起請(qǐng)求，就會(huì)搞出來(lái)一個(gè)順序節(jié)點(diǎn),，大家看下圖,，Curator框架大概會(huì)弄成如下的樣子：

客戶端A發(fā)起一個(gè)加鎖請(qǐng)求,，先在要加鎖的node下搞一個(gè)臨時(shí)順序節(jié)點(diǎn),，這列長(zhǎng)名字都是Curator框架自己生成出來(lái)的。

然后,，那個(gè)最后一個(gè)數(shù)字是'1',。因?yàn)榭蛻舳薃是第一個(gè)發(fā)起請(qǐng)求的，所以給他搞出來(lái)的順序節(jié)點(diǎn)的序號(hào)是'1',。

接著客戶端A創(chuàng)建完一個(gè)順序節(jié)點(diǎn),。還沒(méi)完，他會(huì)查一下'my_lock'這個(gè)鎖節(jié)點(diǎn)下的所有子節(jié)點(diǎn),，并且這些子節(jié)點(diǎn)是按照序號(hào)排序的,，這個(gè)時(shí)候他大概會(huì)拿到這么一個(gè)集合：

接著客戶端A會(huì)走一個(gè)關(guān)鍵性的判斷：這個(gè)集合里創(chuàng)建的順序節(jié)點(diǎn),，是否排在首位？

如果是的話,，就可以加鎖,，因?yàn)槊髅魑揖褪堑谝粋€(gè)來(lái)創(chuàng)建順序節(jié)點(diǎn)的人，所以我就是第一個(gè)嘗試加分布式鎖的人??！

加鎖成功！看下圖,，再來(lái)直觀的感受一下整個(gè)過(guò)程：

接著假如說(shuō),，客戶端A都加完鎖了,，客戶端B過(guò)來(lái)想要加鎖了，這個(gè)時(shí)候他會(huì)干一樣的事兒：先是在'my_lock'這個(gè)鎖節(jié)點(diǎn)下創(chuàng)建一個(gè)臨時(shí)順序節(jié)點(diǎn),，此時(shí)名字會(huì)變成類(lèi)似于：

下圖：

客戶端B因?yàn)槭堑诙€(gè)來(lái)創(chuàng)建順序節(jié)點(diǎn)的，所以ZK內(nèi)部會(huì)維護(hù)序號(hào)為'2',。

接著客戶端B會(huì)走加鎖判斷邏輯,，查詢'my_lock'鎖節(jié)點(diǎn)下的所有子節(jié)點(diǎn)，按序號(hào)順序排列,，此時(shí)他看到的類(lèi)似于：

同時(shí)檢查自己創(chuàng)建的順序節(jié)點(diǎn)，是不是集合中的第一個(gè),？明顯不是啊,，此時(shí)第一個(gè)是客戶端A創(chuàng)建的那個(gè)順序節(jié)點(diǎn)，序號(hào)為'01'的那個(gè),。所以加鎖失?。?/p>

加鎖失敗了以后,，客戶端B就會(huì)通過(guò)ZK的API對(duì)他的順序節(jié)點(diǎn)的上一個(gè)順序節(jié)點(diǎn)加一個(gè)監(jiān)聽(tīng)器,。ZK天然就可以實(shí)現(xiàn)對(duì)某個(gè)節(jié)點(diǎn)的監(jiān)聽(tīng)。

如果大家還不知道ZK的基本用法,，可以百度查閱,，非常的簡(jiǎn)單?？蛻舳薆的順序節(jié)點(diǎn)是：

他的上一個(gè)順序節(jié)點(diǎn),，不就是下面這個(gè)嗎,？

即客戶端A創(chuàng)建的那個(gè)順序節(jié)點(diǎn),！所以，客戶端B會(huì)對(duì)：

這個(gè)節(jié)點(diǎn)加一個(gè)監(jiān)聽(tīng)器，監(jiān)聽(tīng)這個(gè)節(jié)點(diǎn)是否被刪除等變化,！大家看下圖：

接著,，客戶端A加鎖之后,，可能處理了一些代碼邏輯，然后就會(huì)釋放鎖,。那么,，釋放鎖是個(gè)什么過(guò)程呢？

其實(shí)就是把自己在ZK里創(chuàng)建的那個(gè)順序節(jié)點(diǎn),，也就是：

這個(gè)節(jié)點(diǎn)刪除,。刪除了那個(gè)節(jié)點(diǎn)之后,，ZK會(huì)負(fù)責(zé)通知監(jiān)聽(tīng)這個(gè)節(jié)點(diǎn)的監(jiān)聽(tīng)器，也就是客戶端B之前加的那個(gè)監(jiān)聽(tīng)器,，說(shuō)：你監(jiān)聽(tīng)的那個(gè)節(jié)點(diǎn)被刪除了,，有人釋放了鎖。

此時(shí)客戶端B的監(jiān)聽(tīng)器感知到了上一個(gè)順序節(jié)點(diǎn)被刪除，也就是排在他之前的某個(gè)客戶端釋放了鎖,。

此時(shí),，就會(huì)通知客戶端B重新嘗試去獲取鎖，也就是獲取'my_lock'節(jié)點(diǎn)下的子節(jié)點(diǎn)集合,，此時(shí)為：

集合里此時(shí)只有客戶端B創(chuàng)建的唯一的一個(gè)順序節(jié)點(diǎn)了,！然后呢,，客戶端B判斷自己居然是集合中的第一個(gè)順序節(jié)點(diǎn)，Bingo,！可以加鎖了,！直接完成加鎖，運(yùn)行后續(xù)的業(yè)務(wù)代碼即可,，運(yùn)行完了之后再次釋放鎖,。

其實(shí)如果有客戶端C,、客戶端D等N個(gè)客戶端爭(zhēng)搶一個(gè)ZK分布式鎖，原理都是類(lèi)似的：

• 大家都是上來(lái)直接創(chuàng)建一個(gè)鎖節(jié)點(diǎn)下的一個(gè)接一個(gè)的臨時(shí)順序節(jié)點(diǎn),。

• 如果自己不是第一個(gè)節(jié)點(diǎn),，就對(duì)自己上一個(gè)節(jié)點(diǎn)加監(jiān)聽(tīng)器。

• 只要上一個(gè)節(jié)點(diǎn)釋放鎖,，自己就排到前面去了,，相當(dāng)于是一個(gè)排隊(duì)機(jī)制。

• 而且用臨時(shí)順序節(jié)點(diǎn)的另外一個(gè)用意就是,，如果某個(gè)客戶端創(chuàng)建臨時(shí)順序節(jié)點(diǎn)之后,，不小心自己宕機(jī)了也沒(méi)關(guān)系，ZK感知到那個(gè)客戶端宕機(jī),，會(huì)自動(dòng)刪除對(duì)應(yīng)的臨時(shí)順序節(jié)點(diǎn),，相當(dāng)于自動(dòng)釋放鎖，或者是自動(dòng)取消自己的排隊(duì),。

最后,，咱們來(lái)看下用Curator框架進(jìn)行加鎖和釋放鎖的一個(gè)過(guò)程：

其實(shí)用開(kāi)源框架就是方便,。這個(gè)Curator框架的ZK分布式鎖的加鎖和釋放鎖的實(shí)現(xiàn)原理,，就是上面我們說(shuō)的那樣子。

但是如果你要手動(dòng)實(shí)現(xiàn)一套那個(gè)代碼的話,，要考慮到各種細(xì)節(jié),，異常處理等等。所以大家如果考慮用ZK分布式鎖,，可以參考下本文的思路,。

三、每秒上千訂單場(chǎng)景下的分布式鎖高并發(fā)優(yōu)化實(shí)踐

接著聊一個(gè)有意思的話題：每秒上千訂單場(chǎng)景下,，如何對(duì)分布式鎖的并發(fā)能力進(jìn)行優(yō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)面試候選人的話,，給的范圍會(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ā)性能。

面試官提問(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)聊一聊,。

1,、庫(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),，大于了要買(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,？

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

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

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

代碼如上圖,，分析一下為什么這樣可以避免庫(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的,。

3、有沒(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)景而已。

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

現(xiàn)在我們來(lái)看看,，分布式鎖的方案在高并發(fā)場(chǎng)景下有什么問(wèn)題？分布式鎖一旦加了之后，對(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)求依次串行完成處理,。如一秒鐘50個(gè)請(qǐng)求,，都是對(duì)iPhone下單的，那么每個(gè)請(qǐng)求處理20毫秒,，逐個(gè)來(lái),，最后1000毫秒正好處理完50個(gè)請(qǐng)求。

大家看下圖,，加深印象,。

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

同一商品多用戶同時(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è)商品在1秒內(nèi)瞬間下1000個(gè)訂單,，因?yàn)樾‰娚滔到y(tǒng)沒(méi)那場(chǎng)景。

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

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

現(xiàn)在按照剛才的計(jì)算，你1秒鐘只能處理針對(duì)iPhone的50個(gè)訂單,。其實(shí)說(shuō)出來(lái)也很簡(jiǎn)單,，相信很多人看過(guò)Java里的Concurrent Hash Map的源碼和底層原理，應(yīng)該知道里面的核心思路,，就是分段加鎖,！

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

另外，Java8中新增了一個(gè)Long Adder類(lèi),，也是針對(duì)Java7以前的Atomic Long進(jìn)行的優(yōu)化,，解決的是CAS類(lèi)操作在高并發(fā)場(chǎng)景下，使用樂(lè)觀鎖思路,，會(huì)導(dǎo)致大量線程長(zhǎng)時(shí)間重復(fù)循環(huán),。Long Adder中也采用了類(lèi)似的分段CAS操作，失敗則自動(dòng)遷移到下一個(gè)分段進(jìn)行CAS的思路,。

其實(shí)分布式鎖的優(yōu)化思路也是類(lèi)似的,，之前我們是在另外一個(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ō)一下,。

大家看下圖：

這就是分段加鎖。假如現(xiàn)在iPhone有1000個(gè)庫(kù)存,，完全可以給拆成20個(gè)庫(kù)存段,。

要是你愿意，可以在數(shù)據(jù)庫(kù)的表里建20個(gè)庫(kù)存字段,，比如stock_01,，stock_02，類(lèi)似這樣的,，也可以在Redis之類(lèi)的地方放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í)可以自己寫(xiě)一個(gè)簡(jiǎn)單的隨機(jī)算法,，每個(gè)請(qǐng)求都是隨機(jī)在20個(gè)分段庫(kù)存里,，選擇一個(gè)進(jìn)行加鎖。

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

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

最大的不足是很不方便,，實(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)橛玫搅朔植际芥i,，然后又必須要進(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)景而已。