Redis分布式鎖，你用對(duì)了嗎？

PART1.分布式鎖是什么？

我們的手機(jī)有鎖、車(chē)有鎖、家門(mén)有鎖、貴重物品會(huì)鎖進(jìn)保險(xiǎn)箱。可以說(shuō)，鎖在我們生活中無(wú)處不在，時(shí)刻保護(hù)著我們的人身財(cái)產(chǎn)安全。

在計(jì)算機(jī)領(lǐng)域也一樣，鎖可以理解為針對(duì)某項(xiàng)資源使用權(quán)限的管理，它通常用來(lái)控制共享資源，比如一個(gè)進(jìn)程內(nèi)有多個(gè)線程競(jìng)爭(zhēng)一個(gè)數(shù)據(jù)的使用權(quán)限，解決方式之一就是加鎖。

那分布式鎖是什么呢？

顧名思義，分布式鎖就是分布式場(chǎng)景下的鎖，比如多臺(tái)不同機(jī)器上的進(jìn)程，去競(jìng)爭(zhēng)同一項(xiàng)資源，就是分布式鎖。

PART2.分布式鎖有哪些特性？

具備哪些特性的分布式鎖才是一個(gè)優(yōu)秀的分布式鎖？牛牛認(rèn)為要從如下幾方面來(lái)看：

• 互斥性：鎖的目的是獲取資源的使用權(quán)，所以只讓一個(gè)競(jìng)爭(zhēng)者持有鎖，這一點(diǎn)要盡可能保證；
  
  
• 安全性：避免死鎖情況發(fā)生。當(dāng)一個(gè)競(jìng)爭(zhēng)者在持有鎖期間內(nèi)，由于意外崩潰而導(dǎo)致未能主動(dòng)解鎖，其持有的鎖也能夠被正常釋放，并保證后續(xù)其它競(jìng)爭(zhēng)者也能加鎖；
  
  
• 對(duì)稱性：同一個(gè)鎖，加鎖和解鎖必須是同一個(gè)競(jìng)爭(zhēng)者。不能把其他競(jìng)爭(zhēng)者持有的鎖給釋放了，這又稱為鎖的可重入性。
  
  
• 可靠性：需要有一定程度的異常處理能力、容災(zāi)能力。

PART3.分布式鎖的常用實(shí)現(xiàn)方式

分布式鎖，一般會(huì)依托第三方組件來(lái)實(shí)現(xiàn)，而利用Redis實(shí)現(xiàn)則是工作中應(yīng)用最多的一種。

今天，就讓我們從最基礎(chǔ)的步驟開(kāi)始，依照分布式鎖的特性，層層遞進(jìn)，步步完善，將它優(yōu)化到最優(yōu)，讓大家完整地了解如何用Redis來(lái)實(shí)現(xiàn)一個(gè)分布式鎖。

最簡(jiǎn)化版本

首先，當(dāng)然是搭建一個(gè)最簡(jiǎn)單的實(shí)現(xiàn)方式，直接用Redis的setnx命令，這個(gè)命令的語(yǔ)法是：

setnx key value

如果key不存在，則會(huì)將key設(shè)置為value，并返回1；如果key存在，不會(huì)有任務(wù)影響，返回0。

基于這個(gè)特性，我們就可以用setnx實(shí)現(xiàn)加鎖的目的：通過(guò)setnx加鎖，加鎖之后其他服務(wù)無(wú)法加鎖，用完之后，再通過(guò)delete解鎖，深藏功與名。

支持過(guò)期時(shí)間

最簡(jiǎn)化版本有一個(gè)問(wèn)題：如果獲取鎖的服務(wù)掛掉了，那么鎖就一直得不到釋放，就像石沉大海，杳無(wú)音信。所以，我們需要一個(gè)超時(shí)來(lái)兜底。

Redis中有expire命令，用來(lái)設(shè)置一個(gè)key的超時(shí)時(shí)間。但是setnx和expire不具備原子性，如果setnx獲取鎖之后，服務(wù)掛掉，依舊是泥牛入海。

很自然，我們會(huì)想到，set和expire，有沒(méi)有原子操作？

當(dāng)然有，Redis早就考慮到了這種場(chǎng)景，推出了如下執(zhí)行語(yǔ)句：

set key value nx ex seconds

nx表示具備setnx特定，ex表示增加了過(guò)期時(shí)間，最后一個(gè)參數(shù)就是過(guò)期時(shí)間的值。

能夠支持過(guò)期時(shí)間，目前這個(gè)鎖基本上是能用了。

但是存在一個(gè)問(wèn)題：會(huì)存在服務(wù)A釋放掉服務(wù)B的鎖的可能。

加上owner

我們來(lái)試想一下如下場(chǎng)景：服務(wù)A獲取了鎖，由于業(yè)務(wù)流程比較長(zhǎng)，或者網(wǎng)絡(luò)延遲、GC卡頓等原因，導(dǎo)致鎖過(guò)期，而業(yè)務(wù)還會(huì)繼續(xù)進(jìn)行。這時(shí)候，業(yè)務(wù)B已經(jīng)拿到了鎖，準(zhǔn)備去執(zhí)行，這個(gè)時(shí)候服務(wù)A恢復(fù)過(guò)來(lái)并做完了業(yè)務(wù)，就會(huì)釋放鎖，而B(niǎo)卻還在繼續(xù)執(zhí)行。

在真實(shí)的分布式場(chǎng)景中，可能存在幾十個(gè)競(jìng)爭(zhēng)者，那么上述情況發(fā)生概率就很高，導(dǎo)致同一份資源頻繁被不同競(jìng)爭(zhēng)者同時(shí)訪問(wèn)，分布式鎖也就失去了意義。

基于這個(gè)場(chǎng)景，我們可以發(fā)現(xiàn)，問(wèn)題關(guān)鍵在于，競(jìng)爭(zhēng)者可以釋放其他人的鎖。那么在異常情況下，就會(huì)出現(xiàn)問(wèn)題，所以我們可以進(jìn)一步給出解決方案：分布式鎖需要滿足誰(shuí)申請(qǐng)誰(shuí)釋放原則，不能釋放別人的鎖，也就是說(shuō)，分布式鎖，是要有歸屬的。

引入Lua

加入owner后的版本可以稱得上是完善了嗎？還有沒(méi)有什么隱患呢？

牛牛也不賣(mài)關(guān)子了，到這一步其實(shí)還存在一個(gè)小問(wèn)題，我們完整的流程是競(jìng)爭(zhēng)者獲取鎖執(zhí)行任務(wù)，執(zhí)行完畢后檢查鎖是不是自己的，最后進(jìn)行釋放。

流程一梳理，你們肯定明白了，執(zhí)行完畢后，檢查鎖，再釋放，這些操作不是原子化的。

可能鎖獲取時(shí)還是自己的，刪除時(shí)卻已經(jīng)是別人的了。這可怎么辦呢？

Redis可沒(méi)有直接提供這種場(chǎng)景原子化的操作啊。遇事不要慌，仔細(xì)想一想，Redis是不是還有個(gè)特性，專門(mén)整合原子操作，對(duì)，就是它——Lua。

Redis?Lua，可以說(shuō)是專門(mén)為解決原子問(wèn)題而生。

有了Lua的特性，Redis才真正在分布式鎖、秒殺等場(chǎng)景，有了用武之地，下面便是改造之后的流程：

其實(shí)到了這一步，分布式鎖的前三個(gè)特性：對(duì)稱性、安全性、可靠性，就滿足了。可以說(shuō)是一個(gè)可用的分布式鎖了，能滿足大多數(shù)場(chǎng)景的需要。

PART4.可靠性如何保證

分布式鎖的四大特性還剩下可靠性沒(méi)有解決。

針對(duì)一些異常場(chǎng)景，包括Redis掛掉了、業(yè)務(wù)執(zhí)行時(shí)間過(guò)長(zhǎng)、網(wǎng)絡(luò)波動(dòng)等情況，我們來(lái)一起分析如何處理。

容災(zāi)考慮

前面我們談及的內(nèi)容，基本是基于單機(jī)考慮的，如果Redis掛掉了，那鎖就不能獲取了。這個(gè)問(wèn)題該如何解決呢？

一般來(lái)說(shuō)，有兩種方法：主從容災(zāi)和多級(jí)部署。

主從容災(zāi)

最簡(jiǎn)單的一種方式，就是為Redis配置從節(jié)點(diǎn)，當(dāng)主節(jié)點(diǎn)掛了，用從節(jié)點(diǎn)頂包。

但是主從切換，需要人工參與，會(huì)提高人力成本。不過(guò)Redis已經(jīng)有成熟的解決方案，也就是哨兵模式，可以靈活自動(dòng)切換，不再需要人工介入。

通過(guò)增加從節(jié)點(diǎn)的方式，雖然一定程度解決了單點(diǎn)的容災(zāi)問(wèn)題，但并不是盡善盡美的，由于同步有時(shí)延，Slave可能會(huì)損失掉部分?jǐn)?shù)據(jù)，分布式鎖可能失效，這就會(huì)發(fā)生短暫的多機(jī)獲取到執(zhí)行權(quán)限。

有沒(méi)有更可靠的辦法呢？

多機(jī)部署

如果對(duì)一致性的要求高一些，可以嘗試多機(jī)部署，比如Redis的RedLock，大概的思路就是多個(gè)機(jī)器，通常是奇數(shù)個(gè)，達(dá)到一半以上同意加鎖才算加鎖成功，這樣，可靠性會(huì)向ETCD靠近。

現(xiàn)在假設(shè)有5個(gè)Redis主節(jié)點(diǎn)，基本保證它們不會(huì)同時(shí)宕掉，獲取鎖和釋放鎖的過(guò)程中，客戶端會(huì)執(zhí)行以下操作：

1.向5個(gè)Redis申請(qǐng)加鎖；

2.只要超過(guò)一半，也就是3個(gè)Redis返回成功，那么就是獲取到了鎖。如果超過(guò)一半失敗，需要向每個(gè)Redis發(fā)送解鎖命令；

3.由于向5個(gè)Redis發(fā)送請(qǐng)求，會(huì)有一定時(shí)耗，所以鎖剩余持有時(shí)間，需要減去請(qǐng)求時(shí)間。這個(gè)可以作為判斷依據(jù)，如果剩余時(shí)間已經(jīng)為0，那么也是獲取鎖失敗；

4.使用完成之后，向5個(gè)Redis發(fā)送解鎖請(qǐng)求。

這種模式的好處在于，如果掛了2臺(tái)Redis，整個(gè)集群還是可用的，給了運(yùn)維更多時(shí)間來(lái)修復(fù)。

另外，多說(shuō)一句，單點(diǎn)Redis的所有手段，這種多機(jī)模式都可以使用，比如為每個(gè)節(jié)點(diǎn)配置哨兵模式，由于加鎖是一半以上同意就成功，那么如果單個(gè)節(jié)點(diǎn)進(jìn)行了主從切換，單個(gè)節(jié)點(diǎn)數(shù)據(jù)的丟失，就不會(huì)讓鎖失效了。這樣增強(qiáng)了可靠性。

可靠性深究

是不是有RedLock，就一定能保證可靠的分布式鎖？

這里牛牛先說(shuō)結(jié)論：由于分布式系統(tǒng)中的三大困境（簡(jiǎn)稱NPC），所以沒(méi)有完全可靠的分布式鎖！

讓我們來(lái)看看RedLock在NPC下的表現(xiàn)。

N：Network Delay（網(wǎng)絡(luò)延遲）

當(dāng)分布式鎖獲得返回包的時(shí)間過(guò)長(zhǎng)，此時(shí)可能雖然加鎖成功，但是已經(jīng)時(shí)過(guò)境遷，鎖可能很快過(guò)期。RedLock算了做了些考量，也就是前面所說(shuō)的鎖剩余持有時(shí)間，需要減去請(qǐng)求時(shí)間，如此一來(lái)，就可以一定程度解決網(wǎng)絡(luò)延遲的問(wèn)題。

P：Process Pause（進(jìn)程暫停）

比如發(fā)生GC，獲取鎖之后GC了，處于GC執(zhí)行中，然后鎖超時(shí)。

其他鎖獲取，這種情況幾乎無(wú)解。這時(shí)候GC回來(lái)了，那么兩個(gè)進(jìn)程就獲取到了同一個(gè)分布式鎖。

也許你會(huì)說(shuō)，在GC回來(lái)之后，可以再去查一次啊？

這里有兩個(gè)問(wèn)題，首先你怎么知道GC回來(lái)了？這個(gè)可以在做業(yè)務(wù)之前，通過(guò)時(shí)間，進(jìn)行一個(gè)粗略判斷，但也是很吃場(chǎng)景經(jīng)驗(yàn)的；第二，如果你判斷的時(shí)候是ok的，但是判斷完GC了呢？這點(diǎn)RedLock是無(wú)法解決的。

C：Clock Drift（時(shí)鐘漂移）

如果競(jìng)爭(zhēng)者A，獲得了RedLock，在5臺(tái)分布式機(jī)器上都加上鎖。為了方便分析，我們直接假設(shè)5臺(tái)機(jī)器都發(fā)生了時(shí)鐘漂移，鎖瞬間過(guò)期了。這時(shí)候競(jìng)爭(zhēng)者B拿到了鎖，此時(shí)A和B拿到了相同的執(zhí)行權(quán)限。

根據(jù)上述的分析，可以看出，RedLock也不能扛住NPC的挑戰(zhàn)，因此，單單從分布式鎖本身出發(fā)，完全可靠是不可能的。要實(shí)現(xiàn)一個(gè)相對(duì)可靠的分布式鎖機(jī)制，還是需要和業(yè)務(wù)的配合，業(yè)務(wù)本身要冪等可重入，這樣的設(shè)計(jì)可以省卻很多麻煩。

PART5.復(fù)盤(pán)

我們圍繞互斥性、安全性、對(duì)稱性層層遞進(jìn)，實(shí)現(xiàn)了一個(gè)Redis分布式鎖，這樣的架構(gòu)在大多數(shù)業(yè)務(wù)場(chǎng)景都是完全夠用的。

同時(shí)，我們也針對(duì)可靠性，探討了主從容災(zāi)、Red Lock等解決方案，并分析了NPC異常場(chǎng)景，了解到分布式鎖在什么情況會(huì)失去作用，這些知識(shí)在實(shí)際的業(yè)務(wù)中都非常實(shí)用，能夠在實(shí)際開(kāi)發(fā)中做出正確的決策。

牛牛建議對(duì)分布式鎖不要強(qiáng)依賴，沒(méi)有絕對(duì)可靠的分布式鎖，分布式鎖需要與業(yè)務(wù)的聯(lián)動(dòng)配合更加切實(shí)可行，脫離了業(yè)務(wù)，就是空中樓閣，不著實(shí)地。

有道無(wú)術(shù)，術(shù)可成；有術(shù)無(wú)道，止于術(shù)

歡迎大家關(guān)注Java之道公眾號(hào)

好文章，我在看??