搞懂“分布式鎖”，看這篇文章就對了

作者：咖啡拿鐵 2018-10-12 09:42:00

開發(fā)

后端

開發(fā)工具

分布式 對于鎖大家肯定不會陌生，在 Java 中 synchronized 關(guān)鍵字和 ReentrantLock 可重入鎖在我們的代碼中是經(jīng)常見的，一般我們用其在多線程環(huán)境中控制對資源的并發(fā)訪問。

創(chuàng)新互聯(lián)公司專注于高港企業(yè)網(wǎng)站建設(shè),自適應(yīng)網(wǎng)站建設(shè),商城建設(shè)。高港網(wǎng)站建設(shè)公司,為高港等地區(qū)提供建站服務(wù)。全流程按需策劃，專業(yè)設(shè)計，全程項目跟蹤，創(chuàng)新互聯(lián)公司專業(yè)和態(tài)度為您提供的服務(wù)

但是隨著分布式的快速發(fā)展，本地的加鎖往往不能滿足我們的需要，在我們的分布式環(huán)境中上面加鎖的方法就會失去作用。

于是人們?yōu)榱嗽诜植际江h(huán)境中也能實現(xiàn)本地鎖的效果，也是紛紛各出其招，今天讓我們來聊一聊一般分布式鎖實現(xiàn)的套路。

為何需要分布式鎖

Martin Kleppmann 是英國劍橋大學(xué)的分布式系統(tǒng)的研究員，之前和 Redis 之父 Antirez 進行過關(guān)于 RedLock(紅鎖，后續(xù)有講到)是否安全的激烈討論。

Martin 認為一般我們使用分布式鎖有兩個場景：

• 效率：使用分布式鎖可以避免不同節(jié)點重復(fù)相同的工作，這些工作會浪費資源。比如用戶付了錢之后有可能不同節(jié)點會發(fā)出多封短信。
• 正確性：加分布式鎖同樣可以避免破壞正確性的發(fā)生，如果兩個節(jié)點在同一條數(shù)據(jù)上面操作，比如多個節(jié)點機器對同一個訂單操作不同的流程有可能會導(dǎo)致該筆訂單最后狀態(tài)出現(xiàn)錯誤，造成損失。

分布式鎖的一些特點

當我們確定了在不同節(jié)點上需要分布式鎖，那么我們需要了解分布式鎖到底應(yīng)該有哪些特點?

分布式鎖的特點如下：

• 互斥性：和我們本地鎖一樣互斥性是最基本，但是分布式鎖需要保證在不同節(jié)點的不同線程的互斥。
• 可重入性：同一個節(jié)點上的同一個線程如果獲取了鎖之后那么也可以再次獲取這個鎖。
• 鎖超時：和本地鎖一樣支持鎖超時，防止死鎖。
• 高效，高可用：加鎖和解鎖需要高效，同時也需要保證高可用防止分布式鎖失效，可以增加降級。
• 支持阻塞和非阻塞：和 ReentrantLock 一樣支持 lock 和 trylock 以及 tryLock(long timeOut)。
• 支持公平鎖和非公平鎖(可選)：公平鎖的意思是按照請求加鎖的順序獲得鎖，非公平鎖就相反是無序的。這個一般來說實現(xiàn)的比較少。

常見的分布式鎖

我們了解了一些特點之后，我們一般實現(xiàn)分布式鎖有以下幾個方式：

• MySQL
• ZK
• Redis
• 自研分布式鎖：如谷歌的 Chubby。

下面分開介紹一下這些分布式鎖的實現(xiàn)原理。

MySQL

首先來說一下 MySQL 分布式鎖的實現(xiàn)原理，相對來說這個比較容易理解，畢竟數(shù)據(jù)庫和我們開發(fā)人員在平時的開發(fā)中息息相關(guān)。

對于分布式鎖我們可以創(chuàng)建一個鎖表：

前面我們所說的 lock()，trylock(long timeout)，trylock() 這幾個方法可以用下面的偽代碼實現(xiàn)。

lock()

lock 一般是阻塞式的獲取鎖，意思就是不獲取到鎖誓不罷休，那么我們可以寫一個死循環(huán)來執(zhí)行其操作：

mysqlLock.lcok 內(nèi)部是一個 sql，為了達到可重入鎖的效果，我們應(yīng)該先進行查詢，如果有值，需要比較 node_info 是否一致。

這里的 node_info 可以用機器 IP 和線程名字來表示，如果一致就加可重入鎖 count 的值，如果不一致就返回 false。如果沒有值就直接插入一條數(shù)據(jù)。

偽代碼如下：

需要注意的是這一段代碼需要加事務(wù)，必須要保證這一系列操作的原子性。

tryLock() 和 tryLock(long timeout)

tryLock() 是非阻塞獲取鎖，如果獲取不到就會馬上返回，代碼如下：

tryLock(long timeout) 實現(xiàn)如下：

mysqlLock.lock 和上面一樣，但是要注意的是 select … for update 這個是阻塞的獲取行鎖，如果同一個資源并發(fā)量較大還是有可能會退化成阻塞的獲取鎖。

unlock()

unlock 的話如果這里的 count 為 1 那么可以刪除，如果大于 1 那么需要減去 1。

鎖超時

我們有可能會遇到我們的機器節(jié)點掛了，那么這個鎖就不會得到釋放，我們可以啟動一個定時任務(wù)，通過計算一般我們處理任務(wù)的時間。

比如是 5ms，那么我們可以稍微擴大一點，當這個鎖超過 20ms 沒有被釋放我們就可以認定是節(jié)點掛了然后將其直接釋放。

MySQL 小結(jié)：

• 適用場景：MySQL 分布式鎖一般適用于資源不存在數(shù)據(jù)庫，如果數(shù)據(jù)庫存在比如訂單，可以直接對這條數(shù)據(jù)加行鎖，不需要我們上面多的繁瑣的步驟。

比如一個訂單，我們可以用 select * from order_table where id = 'xxx' for update 進行加行鎖，那么其他的事務(wù)就不能對其進行修改。

• 優(yōu)點：理解起來簡單，不需要維護額外的第三方中間件(比如 Redis，ZK)。
• 缺點：雖然容易理解但是實現(xiàn)起來較為繁瑣，需要自己考慮鎖超時，加事務(wù)等等。性能局限于數(shù)據(jù)庫，一般對比緩存來說性能較低。對于高并發(fā)的場景并不是很適合。

樂觀鎖

前面我們介紹的都是悲觀鎖，這里想額外提一下樂觀鎖，在我們實際項目中也是經(jīng)常實現(xiàn)樂觀鎖，因為我們加行鎖的性能消耗比較大，通常我們對于一些競爭不是那么激烈。

但是其又需要保證我們并發(fā)的順序執(zhí)行使用樂觀鎖進行處理，我們可以對我們的表加一個版本號字段。

那么我們查詢出來一個版本號之后，update 或者 delete 的時候需要依賴我們查詢出來的版本號，判斷當前數(shù)據(jù)庫和查詢出來的版本號是否相等，如果相等那么就可以執(zhí)行，如果不等那么就不能執(zhí)行。

這樣的一個策略很像我們的 CAS(Compare And Swap)，比較并交換是一個原子操作。這樣我們就能避免加 select * for update 行鎖的開銷。

ZooKeeper

ZooKeeper 也是我們常見的實現(xiàn)分布式鎖方法，相比于數(shù)據(jù)庫如果沒了解過 ZooKeeper 可能上手比較難一些。

ZooKeeper 是以 Paxos 算法為基礎(chǔ)的分布式應(yīng)用程序協(xié)調(diào)服務(wù)。ZK 的數(shù)據(jù)節(jié)點和文件目錄類似，所以我們可以用此特性實現(xiàn)分布式鎖。

我們以某個資源為目錄，然后這個目錄下面的節(jié)點就是我們需要獲取鎖的客戶端，未獲取到鎖的客戶端注冊需要注冊 Watcher 到上一個客戶端，可以用下圖表示：

/lock 是我們用于加鎖的目錄，/resource_name 是我們鎖定的資源，其下面的節(jié)點按照我們加鎖的順序排列。

Curator

Curator 封裝了 ZooKeeper 底層的 API，使我們更加容易方便的對 ZooKeeper 進行操作，并且它封裝了分布式鎖的功能，這樣我們就不需要在自己實現(xiàn)了。

Curator 實現(xiàn)了可重入鎖(InterProcessMutex)，也實現(xiàn)了不可重入鎖(InterProcessSemaphoreMutex)。在可重入鎖中還實現(xiàn)了讀寫鎖。

InterProcessMutex

InterProcessMutex 是 Curator 實現(xiàn)的可重入鎖，我們可以通過下面的一段代碼實現(xiàn)我們的可重入鎖：

我們利用 acuire 進行加鎖，release 進行解鎖。

加鎖的流程具體如下：

• 首先進行可重入的判定：這里的可重入鎖記錄在 ConcurrentMap

如果 threadData.get(currentThread)是有值的那么就證明是可重入鎖，然后記錄就會加 1。

我們之前的 MySQL 其實也可以通過這種方法去優(yōu)化，可以不需要 count 字段的值，將這個維護在本地可以提高性能。

• 然后在我們的資源目錄下創(chuàng)建一個節(jié)點：比如這里創(chuàng)建一個 /0000000002 這個節(jié)點，這個節(jié)點需要設(shè)置為 EPHEMERAL_SEQUENTIAL 也就是臨時節(jié)點并且有序。
• 獲取當前目錄下所有子節(jié)點，判斷自己的節(jié)點是否位于子節(jié)點第一個。
• 如果是第一個，則獲取到鎖，那么可以返回。
• 如果不是第一個，則證明前面已經(jīng)有人獲取到鎖了，那么需要獲取自己節(jié)點的前一個節(jié)點。

/0000000002 的前一個節(jié)點是 /0000000001，我們獲取到這個節(jié)點之后，再上面注冊 Watcher(這里的 Watcher 其實調(diào)用的是 object.notifyAll()，用來解除阻塞)。

• object.wait(timeout) 或 object.wait()：進行阻塞等待，這里和我們第 5 步的 Watcher 相對應(yīng)。

解鎖的具體流程：

• 首先進行可重入鎖的判定：如果有可重入鎖只需要次數(shù)減 1 即可，減 1 之后加鎖次數(shù)為 0 的話繼續(xù)下面步驟，不為 0 直接返回。
• 刪除當前節(jié)點。
• 刪除 threadDataMap 里面的可重入鎖的數(shù)據(jù)。

讀寫鎖

Curator 提供了讀寫鎖，其實現(xiàn)類是 InterProcessReadWriteLock，這里的每個節(jié)點都會加上前綴：

  
 
 
 

   
  
  
  
private static final String READ_LOCK_NAME  = "__READ__"; 
   
  
  
  
private static final String WRITE_LOCK_NAME = "__WRIT__"; 
  
 
 
 

根據(jù)不同的前綴區(qū)分是讀鎖還是寫鎖，對于讀鎖，如果發(fā)現(xiàn)前面有寫鎖，那么需要將 Watcher 注冊到和自己最近的寫鎖。寫鎖的邏輯和我們之前 4.2 分析的依然保持不變。

鎖超時

ZooKeeper 不需要配置鎖超時，由于我們設(shè)置節(jié)點是臨時節(jié)點，我們的每個機器維護著一個 ZK 的 Session，通過這個 Session，ZK 可以判斷機器是否宕機。

如果我們的機器掛掉的話，那么這個臨時節(jié)點對應(yīng)的就會被刪除，所以我們不需要關(guān)心鎖超時。

ZK 小結(jié)：

• 優(yōu)點：ZK 可以不需要關(guān)心鎖超時時間，實現(xiàn)起來有現(xiàn)成的第三方包，比較方便，并且支持讀寫鎖，ZK 獲取鎖會按照加鎖的順序，所以其是公平鎖。對于高可用利用 ZK 集群進行保證。
• 缺點：ZK 需要額外維護，增加維護成本，性能和 MySQL 相差不大，依然比較差。并且需要開發(fā)人員了解 ZK 是什么。

Redis

大家在網(wǎng)上搜索分布式鎖，恐怕最多的實現(xiàn)就是 Redis 了，Redis 因為其性能好，實現(xiàn)起來簡單所以讓很多人都對其十分青睞。

Redis 分布式鎖簡單實現(xiàn)

熟悉 Redis 的同學(xué)那么肯定對 setNx(set if not exist) 方法不陌生，如果不存在則更新，其可以很好的用來實現(xiàn)我們的分布式鎖。

對于某個資源加鎖我們只需要：

  
 
 
 

   
  
  
  
setNx resourceName value 
  
 
 
 

這里有個問題，加鎖了之后如果機器宕機那么這個鎖就不會得到釋放所以會加入過期時間，加入過期時間需要和 setNx 同一個原子操作。

在 Redis 2.8 之前我們需要使用 Lua 腳本達到我們的目的，但是 Redis 2.8 之后 Redis 支持 nx 和 ex 操作是同一原子操作。

  
 
 
 

   
  
  
  
set resourceName value ex 5 nx 
  
 
 
 

Redission

Javaer 都知道 Jedis，Jedis 是 Redis 的 Java 實現(xiàn)的客戶端，其 API 提供了比較全面的 Redis 命令的支持。

Redission 也是 Redis 的客戶端，相比于 Jedis 功能簡單。Jedis 簡單使用阻塞的 I/O 和 Redis 交互，Redission 通過 Netty 支持非阻塞 I/O。

Jedis 最新版本 2.9.0 是 2016 年的快 3 年了沒有更新，而 Redission 最新版本是 2018 年 10 月更新。

Redission 封裝了鎖的實現(xiàn)，其繼承了 java.util.concurrent.locks.Lock 的接口，讓我們像操作我們的本地 Lock 一樣去操作 Redission 的 Lock。

下面介紹一下其如何實現(xiàn)分布式鎖：

Redission 不僅提供了 Java 自帶的一些方法(lock，tryLock)，還提供了異步加鎖，對于異步編程更加方便。

由于內(nèi)部源碼較多，就不貼源碼了，這里用文字敘述來分析它是如何加鎖的，這里分析一下 tryLock 方法：

①嘗試加鎖：首先會嘗試進行加鎖，由于需要兼容老版本的 Redis，所以不能直接使用 ex，nx 原子操作的 API，那么就只能使用 Lua 腳本，相關(guān)的 Lua 腳本如下：

可以看見它并沒有使用我們的 sexNx 來進行操作，而是使用的 hash 結(jié)構(gòu)，我們的每一個需要鎖定的資源都可以看做是一個 HashMap，鎖定資源的節(jié)點信息是 Key，鎖定次數(shù)是 Value。

通過這種方式可以很好的實現(xiàn)可重入的效果，只需要對 Value 進行加 1 操作，就能進行可重入鎖。當然這里也可以用之前我們說的本地計數(shù)進行優(yōu)化。

②如果嘗試加鎖失敗，判斷是否超時，如果超時則返回 false。

③如果加鎖失敗之后，沒有超時，那么需要在名字為 redisson_lock__channel+lockName 的 channel 上進行訂閱，用于訂閱解鎖消息，然后一直阻塞直到超時，或者有解鎖消息。

④重試步驟 1，2，3，直到最后獲取到鎖，或者某一步獲取鎖超時。

對于我們的 unlock 方法比較簡單也是通過 lua 腳本進行解鎖，如果是可重入鎖，只是減 1。如果是非加鎖線程解鎖，那么解鎖失敗。

Redission 還有公平鎖的實現(xiàn)，對于公平鎖其利用了 list 結(jié)構(gòu)和 hashset 結(jié)構(gòu)分別用來保存我們排隊的節(jié)點，和我們節(jié)點的過期時間，用這兩個數(shù)據(jù)結(jié)構(gòu)幫助我們實現(xiàn)公平鎖，這里就不展開介紹了，有興趣可以參考源碼。

RedLock

我們想象一個這樣的場景當機器 A 申請到一把鎖之后，如果 Redis 主宕機了，這個時候從機并沒有同步到這一把鎖，那么機器 B 再次申請的時候就會再次申請到這把鎖。

為了解決這個問題 Redis 作者提出了 RedLock 紅鎖的算法，在 Redission 中也對 RedLock 進行了實現(xiàn)。

通過上面的代碼，我們需要實現(xiàn)多個 Redis 集群，然后進行紅鎖的加鎖，解鎖。

具體的步驟如下：

①首先生成多個 Redis 集群的 Rlock，并將其構(gòu)造成 RedLock。

②依次循環(huán)對三個集群進行加鎖，加鎖的過程和 5.2 里面一致。

③如果循環(huán)加鎖的過程中加鎖失敗，那么需要判斷加鎖失敗的次數(shù)是否超出了最大值，這里的最大值是根據(jù)集群的個數(shù)，比如三個那么只允許失敗一個，五個的話只允許失敗兩個，要保證多數(shù)成功。

④加鎖的過程中需要判斷是否加鎖超時，有可能我們設(shè)置加鎖只能用 3ms，第一個集群加鎖已經(jīng)消耗了 3ms 了。那么也算加鎖失敗。

⑤3，4 步里面加鎖失敗的話，那么就會進行解鎖操作，解鎖會對所有的集群在請求一次解鎖。

可以看見 RedLock 基本原理是利用多個 Redis 集群，用多數(shù)的集群加鎖成功，減少 Redis 某個集群出故障，造成分布式鎖出現(xiàn)問題的概率。

Redis 小結(jié)：

• 優(yōu)點：對于 Redis 實現(xiàn)簡單，性能對比 ZK 和 MySQL 較好。如果不需要特別復(fù)雜的要求，自己就可以利用 setNx 進行實現(xiàn)，如果自己需要復(fù)雜的需求的話，可以利用或者借鑒 Redission。對于一些要求比較嚴格的場景可以使用 RedLock。
• 缺點：需要維護 Redis 集群，如果要實現(xiàn) RedLock 需要維護更多的集群。

分布式鎖的安全問題

上面我們介紹過紅鎖，但是 Martin Kleppmann 認為其依然不安全。

有關(guān)于 Martin 反駁的幾點，我認為其實不僅僅局限于 RedLock，前面說的算法基本都有這個問題，下面我們來討論一下這些問題。

長時間的 GC pause

熟悉 Java 的同學(xué)肯定對 GC 不陌生，在 GC 的時候會發(fā)生 STW(stop-the-world)。

例如 CMS 垃圾回收器，它會有兩個階段進行 STW 防止引用繼續(xù)進行變化。那么有可能會出現(xiàn)下面圖(引用至 Martin 反駁 Redlock 的文章)中這個情況：

client1 獲取了鎖并且設(shè)置了鎖的超時時間，但是 client1 之后出現(xiàn)了 STW，這個 STW 時間比較長，導(dǎo)致分布式鎖進行了釋放。

client2 獲取到了鎖，這個時候 client1 恢復(fù)了鎖，那么就會出現(xiàn) client1，2 同時獲取到鎖，這個時候分布式鎖不安全問題就出現(xiàn)了。

這個不僅僅局限于 RedLock，對于我們的 ZK，MySQL 一樣的有同樣的問題。

時鐘發(fā)生跳躍

對于 Redis 服務(wù)器如果其時間發(fā)生了跳躍，肯定會影響我們鎖的過期時間。

那么我們的鎖過期時間就不是我們預(yù)期的了，也會出現(xiàn) client1 和 client2 獲取到同一把鎖，也會出現(xiàn)不安全，這個對于 MySQL 也會出現(xiàn)。但是 ZK 由于沒有設(shè)置過期時間，那么發(fā)生跳躍也不會受影響。

長時間的網(wǎng)絡(luò) I/O

這個問題和我們的 GC 的 STW 很像，也就是我們這個獲取了鎖之后我們進行網(wǎng)絡(luò)調(diào)用，其調(diào)用時間由可能比我們鎖的過期時間都還長，那么也會出現(xiàn)不安全的問題，這個 MySQL 也會有，ZK 也不會出現(xiàn)這個問題。

對于這三個問題，在網(wǎng)上包括 Redis 作者在內(nèi)發(fā)起了很多討論。

GC 的 STW

對于這個問題可以看見基本所有的都會出現(xiàn)問題，Martin 給出了一個解法，對于 ZK 這種他會生成一個自增的序列，那么我們真正進行對資源操作的時候，需要判斷當前序列是否是最新，有點類似于樂觀鎖。

當然這個解法 Redis 作者進行了反駁，你既然都能生成一個自增的序列了那么你完全不需要加鎖了，也就是可以按照類似于 MySQL 樂觀鎖的解法去做。

我自己認為這種解法增加了復(fù)雜性，當我們對資源操作的時候需要增加判斷序列號是否是最新，無論用什么判斷方法都會增加復(fù)雜度，后面會介紹谷歌的 Chubby 提出了一個更好的方案。

時鐘發(fā)生跳躍

Martin 覺得 RedLock 不安全很大的原因也是因為時鐘的跳躍，因為鎖過期強依賴于時間，但是 ZK 不需要依賴時間，依賴每個節(jié)點的 Session。

Redis 作者也給出了解答，對于時間跳躍分為人為調(diào)整和 NTP 自動調(diào)整：

• 人為調(diào)整：人為調(diào)整影響的完全可以人為不調(diào)整，這個是處于可控的。
• NTP 自動調(diào)整：這個可以通過一定的優(yōu)化，把跳躍時間控制在可控范圍內(nèi)，雖然會跳躍，但是是完全可以接受的。

長時間的網(wǎng)絡(luò) I/O

這一塊不是他們討論的重點，我自己覺得，對于這個問題的優(yōu)化可以控制網(wǎng)絡(luò)調(diào)用的超時時間，把所有網(wǎng)絡(luò)調(diào)用的超時時間相加。

那么我們鎖過期時間其實應(yīng)該大于這個時間，當然也可以通過優(yōu)化網(wǎng)絡(luò)調(diào)用比如串行改成并行，異步化等。

Chubby 的一些優(yōu)化

大家搜索 ZK 的時候，會發(fā)現(xiàn)他們都寫了 ZK 是 Chubby 的開源實現(xiàn)，Chubby 內(nèi)部工作原理和 ZK 類似。但是 Chubby 的定位是分布式鎖和 ZK 有點不同。

Chubby 也是使用上面自增序列的方案用來解決分布式不安全的問題，但是它提供了多種校驗方法：

• CheckSequencer()：調(diào)用 Chubby 的 API 檢查此時這個序列號是否有效。
• 訪問資源服務(wù)器檢查，判斷當前資源服務(wù)器最新的序列號和我們的序列號的大小。
• lock-delay：為了防止我們校驗的邏輯入侵我們的資源服務(wù)器，其提供了一種方法當客戶端失聯(lián)的時候，并不會立即釋放鎖，而是在一定的時間內(nèi)(默認 1min)阻止其他客戶端拿去這個鎖。

那么也就是給予了一定的 buffer 等待 STW 恢復(fù)，而我們的 GC 的 STW 時間如果比 1min 還長那么你應(yīng)該檢查你的程序，而不是懷疑你的分布式鎖了。

小結(jié)

本文主要講了多種分布式鎖的實現(xiàn)方法，以及它們的一些優(yōu)缺點。最后也說了一下關(guān)于分布式鎖的安全的問題。

對于不同的業(yè)務(wù)需要的安全程度完全不同，我們需要根據(jù)自己的業(yè)務(wù)場景，通過不同的維度分析，選取最適合自己的方案。

分享題目：搞懂“分布式鎖”，看這篇文章就對了
瀏覽路徑：http://www.dlmjj.cn/article/djcegsi.html