今天我們聊聊分布式鎖。

1. 分布式鎖是什么？

我們的手機有鎖、車有鎖、家門有鎖、貴重物品會鎖進保險箱?？梢哉f，鎖在我們生活中無處不在，時刻保護著我們的人身財產安全。

在計算機領域也一樣，鎖可以理解為針對某項資源使用權限的管理，它通常用來控制共享資源，比如一個進程內有多個線程競爭一個數據的使用權限，解決方式之一就是加鎖。

那分布式鎖是什么呢？

顧名思義，分布式鎖就是分布式場景下的鎖，比如多臺不同機器上的進程，去競爭同一項資源，就是分布式鎖。

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

具備哪些特性的分布式鎖才是一個優秀的分布式鎖？我認為要從如下幾方面來看：

互斥性：鎖的目的是獲取資源的使用權，所以只讓一個競爭者持有鎖，這一點要盡可能保證；

安全性：避免死鎖情況發生。當一個競爭者在持有鎖期間內，由于意外崩潰而導致未能主動解鎖，其持有的鎖也能夠被正常釋放，并保證后續其它競爭者也能加鎖；

對稱性：同一個鎖，加鎖和解鎖必須是同一個競爭者。不能把其他競爭者持有的鎖給釋放了，這又稱為鎖的可重入性；

可靠性：需要有一定程度的異常處理能力、容災能力。

3. 分布式鎖的常用實現方式

分布式鎖，一般會依托第三方組件來實現，而利用 Redis 實現則是工作中應用最多的一種。

今天，就讓我們從最基礎的步驟開始，依照分布式鎖的特性，層層遞進，步步完善，將它優化到最優，讓大家完整地了解如何用 Redis 來實現一個分布式鎖。

3.1 最簡化版本

首先，當然是搭建一個最簡單的實現方式，直接用 Redis 的 setnx 命令，這個命令的語法是：

setnx key value

如果 key 不存在，則會將 key 設置為 value，并返回 1；如果 key 存在，不會有任務影響，返回 0。

基于這個特性，我們就可以用 setnx 實現加鎖的目的：通過 setnx 加鎖，加鎖之后其他服務無法加鎖，用完之后，再通過 delete 解鎖，深藏功與名。

3.2 支持過期時間

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

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

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

當然有，Redis早就考慮到了這種場景，推出了如下執行語句：

set key value nx ex seconds

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

能夠支持過期時間，目前這個鎖基本上是能用了。

但是存在一個問題：會存在服務 A 釋放掉服務B的鎖的可能。

3.3 加上owner

我們來試想一下如下場景：服務 A 獲取了鎖，由于業務流程比較長，或者網絡延遲、 GC 卡頓等原因，導致鎖過期，而業務還會繼續進行。這時候，業務 B 已經拿到了鎖，準備去執行，這個時候服務 A 恢復過來并做完了業務，就會釋放鎖，而 B 卻還在繼續執行。

在真實的分布式場景中，可能存在幾十個競爭者，那么上述情況發生概率就很高，導致同一份資源頻繁被不同競爭者同時訪問，分布式鎖也就失去了意義。

基于這個場景，我們可以發現，問題關鍵在于，競爭者可以釋放其他人的鎖。那么在異常情況下，就會出現問題，所以我們可以進一步給出解決方案：分布式鎖需要滿足誰申請誰釋放原則，不能釋放別人的鎖，也就是說，分布式鎖，是要有歸屬的。

3.4 引入 Lua

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

我也不賣關子了，到這一步其實還存在一個小問題，我們完整的流程是競爭者獲取鎖執行任務，執行完畢后檢查鎖是不是自己的，最后進行釋放。

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

可能鎖獲取時還是自己的，刪除時卻已經是別人的了。這可怎么辦呢？

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

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

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

其實到了這一步，分布式鎖的前三個特性：對稱性、安全性、可靠性，就滿足了。可以說是一個可用的分布式鎖了，能滿足大多數場景的需要。

4. 可靠性如何保證

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

針對一些異常場景，包括Redis掛掉了、業務執行時間過長、網絡波動等情況，我們來一起分析如何處理。

4.1 容災考慮

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

一般來說，有兩種方法：主從容災和多級部署。

主從容災

最簡單的一種方式，就是為 Redis 配置從節點，當主節點掛了，用從節點頂包。

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

通過增加從節點的方式，雖然一定程度解決了單點的容災問題，但并不是盡善盡美的，由于同步有時延，Slave 可能會損失掉部分數據，分布式鎖可能失效，這就會發生短暫的多機獲取到執行權限。

有沒有更可靠的辦法呢？

多機部署

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

現在假設有 5 個 Redis 主節點，基本保證它們不會同時宕掉，獲取鎖和釋放鎖的過程中，客戶端會執行以下操作：

向 5 個 Redis 申請加鎖；

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

由于向 5 個 Redis 發送請求，會有一定時耗，所以鎖剩余持有時間，需要減去請求時間。這個可以作為判斷依據，如果剩余時間已經為 0，那么也是獲取鎖失敗；

使用完成之后，向 5 個 Redis 發送解鎖請求。

這種模式的好處在于，如果掛了 2 臺 Redis，整個集群還是可用的，給了運維更多時間來修復。

另外，多說一句，單點 Redis 的所有手段，這種多機模式都可以使用。比如為每個節點配置哨兵模式，由于加鎖是一半以上同意就成功，那么如果單個節點進行了主從切換，單個節點數據的丟失，就不會讓鎖失效了。這樣增強了可靠性。

4.2 可靠性深究

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

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

讓我們來看看 RedLock 在 NPC 下的表現。

N：Network Delay（網絡延遲）

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

P：Process Pause（進程暫停）

比如發生 GC，獲取鎖之后 GC 了，處于 GC 執行中，然后鎖超時。

其他鎖獲取，這種情況幾乎無解。這時候 GC 回來了，那么兩個進程就獲取到了同一個分布式鎖。

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

這里有兩個問題，首先你怎么知道 GC 回來了？這個可以在做業務之前，通過時間，進行一個粗略判斷，但也是很吃場景經驗的；第二，如果你判斷的時候是 OK 的，但是判斷完 GC 了呢？這點 RedLoc k是無法解決的。

C：Clock Drift（時鐘漂移）

如果競爭者 A，獲得了 RedLock，在 5 臺分布式機器上都加上鎖。為了方便分析，我們直接假設 5 臺機器都發生了時鐘漂移，鎖瞬間過期了。這時候競爭者 B 拿到了鎖，此時 A 和 B 拿到了相同的執行權限。

根據上述的分析，可以看出，RedLock 也不能扛住 NPC 的挑戰。因此，單單從分布式鎖本身出發，完全可靠是不可能的。要實現一個相對可靠的分布式鎖機制，還是需要和業務的配合，業務本身要冪等可重入，這樣的設計可以省卻很多麻煩。

5. 復盤

我們圍繞互斥性、安全性、對稱性層層遞進，實現了一個 Redis 分布式鎖，這樣的架構在大多數業務場景都是完全夠用的。

同時，我們也針對可靠性，探討了主從容災、Red Lock 等解決方案，并分析了 NPC 異常場景，了解到分布式鎖在什么情況會失去作用，這些知識在實際的業務中都非常實用，能夠在實際開發中做出正確的決策。

建議對分布式鎖不要強依賴，沒有絕對可靠的分布式鎖，分布式鎖需要與業務的聯動配合更加切實可行，脫離了業務，就是空中樓閣，不著實地。

責任編輯：haq