今天我們聊聊分布式鎖。

1. 分布式鎖是什么？

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

在計(jì)算機(jī)領(lǐng)域也一樣，鎖可以理解為針對(duì)某項(xiàng)資源使用權(quán)限的管理，它通常用來控制共享資源，比如一個(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)資源，就是分布式鎖。

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

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

互斥性：鎖的目的是獲取資源的使用權(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)能力。

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

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

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

3.1 最簡(jiǎn)化版本

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

setnx key value

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

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

3.2 支持過期時(shí)間

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

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

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

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

set key value nx ex seconds

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

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

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

3.3 加上owner

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

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

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

3.4 引入 Lua

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

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

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

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

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

Redis+Lua，可以說是專門為解決原子問題而生。

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

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

4. 可靠性如何保證

分布式鎖的四大特性還剩下可靠性沒有解決。

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

4.1 容災(zāi)考慮

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

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

主從容災(zāi)

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

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

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

有沒有更可靠的辦法呢？

多機(jī)部署

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

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

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

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

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

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

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

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

4.2 可靠性深究

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

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

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

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

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

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

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

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

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

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

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

如果競(jìng)爭(zhēng)者 A，獲得了 RedLock，在 5 臺(tái)分布式機(jī)器上都加上鎖。為了方便分析，我們直接假設(shè) 5 臺(tái)機(jī)器都發(fā)生了時(shí)鐘漂移，鎖瞬間過期了。這時(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ì)可以省卻很多麻煩。

5. 復(fù)盤

我們圍繞互斥性、安全性、對(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í)際開發(fā)中做出正確的決策。

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

責(zé)任編輯：haq