為什麼要用分散式鎖

我們先來看一個業務場景：

系統 A 是一個電商系統，目前是一臺機器部署，系統中有一個使用者下訂單的介面，但是使用者下訂單之前一定要去檢查一下庫存，確保庫存 足夠了才會給使用者下單。

由於系統有一定的併發，所以會預先將商品的庫存儲存在 redis 中，使用者下單的時候會更新 redis 的庫存。

此時系統架構如下：

但是這樣一來會產生一個問題：假如某個時刻，redis 裡面的某個商品庫存為 1，此時兩個請求同時到來，其中一個請求執行到上圖 的第 3 步，更新資料庫的庫存為 0，但是第 4 步還沒有執行。 而另外一個請求執行到了第 2 步，發現庫存還是 1，就繼續執行第 3 步。 這樣的結果，是導致賣出了 2 個商品，然而其實庫存只有 1 個。

很明顯不對啊！這就是典型的庫存超賣問題。

此時，我們很容易想到解決方案：用鎖把 2、3、4 步鎖住，讓他們執行完之後，另一個執行緒才能進來執行第 2 步。

按照上面的圖，在執行第 2 步時，使用 Java 提供的 synchronized 或者 ReentrantLock 來鎖住，然後在第 4 步執行完之後才釋放鎖。

這樣一來，2、3、4 這 3 個步驟就被 “鎖” 住了，多個執行緒之間只能序列化執行。

但是好景不長，整個系統的併發飆升，一臺機器扛不住了。現在要增加一臺機器，如下圖：

增加機器之後，系統變成上圖所示，我的天！

假設此時兩個使用者的請求同時到來，但是落在了不同的機器上，那麼這兩個請求是可以同時執行了，還是會出現庫存超賣的問題。

為什麼呢？因為上圖中的兩個 A 系統，執行在兩個不同的 JVM 裡面，他們加的鎖只對屬於自己 JVM 裡面的執行緒有效，對於其他 JVM 的執行緒是無 效的。 因此，這裡的問題是：Java 提供的原生鎖機制在多機部署場景下失效了

這是因為兩臺機器加的鎖不是同一個鎖 (兩個鎖在不同的 JVM 裡面)。

那麼，我們只要保證兩臺機器加的鎖是同一個鎖，問題不就解決了嗎？

此時，就該分散式鎖隆重登場了，分散式鎖的思路是： 在整個系統提供一個全域性、唯一的獲取鎖的 “東西”，然後每個系統在需要加鎖時，都去問這個 “東西” 拿到一把鎖，這樣不 同的系統拿到的就可以認為是同一把鎖。

至於這個 “東西”，可以是Redis、Zookeeper，也可以是資料庫。 文字描述不太直觀，我們來看下圖：

通過上面的分析，我們知道了庫存超賣場景在分散式部署系統的情況下使用 Java 原生的鎖機制無法保證執行緒安全，所以我們需要用到分佈 式鎖的方案。

那麼，如何實現分散式鎖呢？接著往下看！

基於 Redis 實現分散式鎖

上面分析為啥要使用分散式鎖了，這裡我們來具體看看分散式鎖落地的時候應該怎麼樣處理。

最常見的一種方案就是使用Redis 做分散式鎖。

使用 Redis 做分散式鎖的思路大概是這樣的：在 redis 中設定一個值表示加了鎖，然後釋放鎖的時候就把這個 key 刪除。

具體程式碼是這樣的：

// 獲取鎖
// NX是指如果key不存在就成功，key存在返回false，PX可以指定過期時間
SET anyLock unique_value NX PX 
30000
// 釋放鎖：通過執行一段lua指令碼
// 釋放鎖涉及到兩條指令，這兩條指令不是原子性的
// 需要用到redis的lua指令碼支援特性，redis執行lua指令碼是原子性的
if
	redis.call("get",KEYS[1])== ARGV[1] then   
	return redis.call("del",KEYS[1])
else   
	return 0
end

這種方式有幾大要點：

• 一定要用 SET key value NX PX milliseconds 命令。如果不用，先設定了值，再設定過期時間，這個不是原子性操作，有可能在設定過期時間之前宕機，會造成死鎖 (key 永久存在)

• value 要具有唯一性。這個是為了在解鎖的時候，需要驗證 value 是和加鎖的一致才刪除 key。

PS: 這裡還有一個問題：假設 A 獲取了鎖，過期時間 30s，此時 35s 之後，鎖已經自動釋放了，A 去釋放鎖，但是此時可能 B 獲取了鎖。A 客戶端 就不能刪除 B 的鎖了。

除了要考慮客戶端要怎麼實現分散式鎖之外，還需要考慮 redis 的部署問題。

redis 有 3 種部署方式：

• 單機模式
• master-slave + sentinel 選舉模式
• redis cluster 模式

使用 redis 做分散式鎖的缺點在於：如果採用單機部署模式，會存在單點問題，只要 redis 故障了。加鎖就不行了。

採用 master-slave 模式，加鎖的時候只對一個節點加鎖，即便通過 sentinel 做了高可用，但是如果 master 節點故障了，發生主從切換，此時就會有可能出現鎖丟失的問題。

基於以上的考慮，其實 redis 的作者也考慮到這個問題，他提出了一個 RedLock 的演算法，這個演算法的意思大概是這樣的：

假設 redis 的部署模式是 redis cluster，總共有 5 個 master 節點，通過以下步驟獲取一把鎖：

• 獲取當前時間戳，單位是毫秒
• 輪流嘗試在每個 master 節點上建立鎖，過期時間設定較短，一般就幾十毫秒
• 嘗試在大多數節點上建立一個鎖，比如 5 個節點就要求是 3 個節點（n / 2 +1）
• 客戶端計算建立好鎖的時間，如果建立鎖的時間小於超時時間，就算建立成功了
• 要是鎖建立失敗了，那麼就依次刪除這個鎖
• 只要別人建立了一把分散式鎖，你就得不斷輪詢去嘗試獲取鎖

但是這樣的這種演算法還是頗具爭議的，可能還會存在不少的問題，無法保證加鎖的過程一定正確。

另一種方式：Redisson

此外，實現 Redis 的分散式鎖，除了自己基於 redis client 原生 api 來實現之外，還可以使用開源框架：Redission

Redisson 是一個企業級的開源 Redis Client，也提供了分散式鎖的支援。我也非常推薦大家使用，為什麼呢？

回想一下上面說的，如果自己寫程式碼來通過 redis 設定一個值，是通過下面這個命令設定的。

SET anyLock unique_value NX PX 30000

這裡設定的超時時間是 30s，假如我超過 30s 都還沒有完成業務邏輯的情況下，key 會過期，其他執行緒有可能會獲取到鎖。

這樣一來的話，第一個執行緒還沒執行完業務邏輯，第二個執行緒進來了也會出現執行緒安全問題。所以我們還需要額外的去維護這個過期時間，太麻煩了～

我們來看看 redisson 是怎麼實現的？先感受一下使用 redission 的爽：

Config config = new Config();
config.useClusterServers()
.addNodeAddress("redis://192.168.31.101:7001")
.addNodeAddress("redis://192.168.31.101:7002")
.addNodeAddress("redis://192.168.31.101:7003")
.addNodeAddress("redis://192.168.31.102:7001")
.addNodeAddress("redis://192.168.31.102:7002")
.addNodeAddress("redis://192.168.31.102:7003");

RedissonClient redisson = Redisson.create(config);

RLock lock = redisson.getLock("anyLock");
lock.lock();
lock.unlock();

就是這麼簡單，我們只需要通過它的 api 中的 lock 和 unlock 即可完成分散式鎖，他幫我們考慮了很多細節：

• redisson 所有指令都通過 lua 指令碼執行，redis 支援 lua 指令碼原子性執行
• redisson 設定一個 key 的預設過期時間為 30s, 如果某個客戶端持有一個鎖超過了 30s 怎麼辦？

redisson 中有一個 watchdog 的概念，翻譯過來就是看門狗，它會在你獲取鎖之後，每隔 10 秒幫你把 key 的超時時間設為 30s

這樣的話，就算一直持有鎖也不會出現 key 過期了，其他執行緒獲取到鎖的問題了。

redisson 的 “看門狗” 邏輯保證了沒有死鎖發生 (如果機器宕機了，看門狗也就沒了。此時就不會延長 key 的過期時間，到了 30s 之後就會自動過期了，其他執行緒可以獲取到鎖)

這裡稍微貼出來其實現程式碼：

另外，redisson 還提供了對 redlock 演算法的支援，

它的用法也很簡單：

RedissonClient     redisson    = Redisson.create(config);
RLock lock1 = redisson.getFairLock("lock1");
RLock lock2 = redisson.getFairLock("lock2");
RLock lock3 = redisson.getFairLock("lock3");
RedissonRedLock     multiLock = new RedissonRedLock(lock1,lock2,lock3);
multiLock.lock();
multiLock.unlock();

小結

本節分析了使用 redis 作為分散式鎖的具體落地方案，以及其一些侷限性，然後介紹了一個 redis 的客戶端框架 redisson，這也是推薦大家使用的，比自己寫程式碼實現會少 care 很多細節。

基於 zookeeper 實現分散式鎖

常見的分散式鎖實現方案裡面，除了使用 redis 來實現之外，使用 zookeeper 也可以實現分散式鎖。

在介紹 zookeeper (下文用 zk 代替) 實現分散式鎖的機制之前，先粗略介紹一下 zk 是什麼東西：

Zookeeper 是一種提供配置管理、分散式協同以及命名的中心化服務。

zk 的模型是這樣的：zk 包含一系列的節點，叫做 znode，就好像檔案系統一樣每個 znode 表示一個目錄，然後 znode 有一些特性：

• 有序節點：假如當前有一個父節點為 /lock，我們可以在這個父節點下面建立子節點；zookeeper 提供了一個可選的有序特性，例如我們可以建立子節點 “/lock/node-” 並且指明有序，那麼 zookeeper 在生成子節點時會根據 當前的子節點數量自動新增整數序號。也就是說，如果是第一個建立的子節點，那麼生成的子節點為 /lock/node-0000000000，下一個節點則為 /lock/node-0000000001，依次類推。

• 臨時節點：客戶端可以建立一個臨時節點，在會話結束或者會話超時後，zookeeper 會自動刪除該節點。

• 事件監聽：在讀取資料時，我們可以同時對節點設定事件監聽，當節點資料或結構變化時，zookeeper 會通知客戶端。當前 zookeeper 有如下四種事件：

  • 節點建立
  • 節點刪除
  • 節點資料修改
  • 子節點變更

基於以上的一些 zk 的特性，我們很容易得出使用 zk 實現分散式鎖的落地方案：

1. 使用 zk 的臨時節點和有序節點，每個執行緒獲取鎖就是在 zk 建立一個臨時有序的節點，比如在 /lock/ 目錄下。
2. 建立節點成功後，獲取 /lock 目錄下的所有臨時節點，再判斷當前執行緒建立的節點是否是所有的節點的序號最小的節點
3. 如果當前執行緒建立的節點是所有節點序號最小的節點，則認為獲取鎖成功。
4. 如果當前執行緒建立的節點不是所有節點序號最小的節點，則對節點序號的前一個節點新增一個事件監聽。

比如當前執行緒獲取到的節點序號為 /lock/003, 然後所有的節點列表為 [/lock/001,/lock/002,/lock/003], 則對 /lock/002 這個節點 新增一個事件監聽器。

如果鎖釋放了，會喚醒下一個序號的節點，然後重新執行第 3 步，判斷是否自己的節點序號是最小。

比如 /lock/001 釋放了，/lock/002 監聽到事件，此時節點集合為 [/lock/002,/lock/003], 則 /lock/002 為最小序號節點，獲取到鎖。

整個過程如下：

具體的實現思路就是這樣，至於程式碼怎麼寫，這裡比較複雜就不貼出來了。

兩種方案的優缺點比較

學完了兩種分散式鎖的實現方案之後，本節需要討論的是 redis 和 zk 的實現方案中各自的優缺點。

對於 redis 的分散式鎖而言，它有以下缺點：

• 它獲取鎖的方式簡單粗暴，獲取不到鎖直接不斷嘗試獲取鎖，比較消耗效能。
• 另外來說的話，redis 的設計定位決定了它的資料並不是強一致性的，在某些極端情況下，可能會出現問題。鎖的模型不夠健壯
• 即便使用 redlock 演算法來實現，在某些複雜場景下，也無法保證其實現 100% 沒有問題，關於 redlock 的討論可以看 How to do distributed locking
• redis 分散式鎖，其實需要自己不斷去嘗試獲取鎖，比較消耗效能。

但是另一方面使用 redis 實現分散式鎖在很多企業中非常常見，而且大部分情況下都不會遇到所謂的 “極端複雜場景”

所以使用 redis 作為分散式鎖也不失為一種好的方案，最重要的一點是 redis 的效能很高，可以支撐高併發的獲取、釋放鎖操作。

對於 zk 分散式鎖而言:

• zookeeper 天生設計定位就是分散式協調，強一致性。鎖的模型健壯、簡單易用、適合做分散式鎖

如果獲取不到鎖，只需要新增一個監聽器就可以了，不用一直輪詢，效能消耗較小。

• 但是 zk 也有其缺點：如果有較多的客戶端頻繁的申請加鎖、釋放鎖，對於 zk 叢集的壓力會比較大

總結

綜上所述，redis 和 zookeeper 都有其優缺點。我們在做技術選型的時候可以根據這些問題作為參考因素。

一些建議:

通過前面的分析，實現分散式鎖的兩種常見方案：redis 和 zookeeper，他們各有千秋。應該如何選型呢？

就個人而言的話，我比較推崇 zk 實現的鎖。

因為 redis 是有可能存在隱患的，可能會導致資料不對的情況。但是，怎麼選用要看具體在公司的場景了。

如果公司裡面有 zk 叢集條件，優先選用 zk 實現，但是如果說公司裡面只有 redis 叢集，沒有條件搭建 zk 叢集。

那麼其實用 redis 來實現也可以，另外還可能是系統設計者考慮到了系統已經有 redis，但是又不希望再次引入一些外部依賴的情況下 ，可以選用 redis。

這個是要系統設計者基於架構的考慮了。