搞懂“分佈式鎖”,看這篇文章就對了

隨着分佈式的快速發展,本地的加鎖往往不能滿足我們的需要,在我們的分佈式環境中上面加鎖的方法就會失去作用。

於是人們爲了在分佈式環境中也能實現本地鎖的效果,也是紛紛各出其招,今天讓我們來聊一聊一般分佈式鎖實現的套路。

爲何需要分佈式鎖

Martin Kleppmann 是英國劍橋大學的分佈式系統的研究員,之前和 Redis 之父 Antirez 進行過關於 RedLock(紅鎖,後續有講到)是否安全的激烈討論。

Martin 認爲一般我們使用分佈式鎖有兩個場景:

  • 效率:使用分佈式鎖可以避免不同節點重複相同的工作,這些工作會浪費資源。比如用戶付了錢之後有可能不同節點會發出多封短信。

  • 正確性:加分佈式鎖同樣可以避免破壞正確性的發生,如果兩個節點在同一條數據上面操作,比如多個節點機器對同一個訂單操作不同的流程有可能會導致該筆訂單最後狀態出現錯誤,造成損失。

分佈式鎖的一些特點

當我們確定了在不同節點上需要分佈式鎖,那麼我們需要了解分佈式鎖到底應該有哪些特點?

分佈式鎖的特點如下:

  • 互斥性:和我們本地鎖一樣互斥性是最基本,但是分佈式鎖需要保證在不同節點的不同線程的互斥。

  • 可重入性:同一個節點上的同一個線程如果獲取了鎖之後那麼也可以再次獲取這個鎖。

  • 鎖超時:和本地鎖一樣支持鎖超時,防止死鎖。

  • 高效,高可用:加鎖和解鎖需要高效,同時也需要保證高可用防止分佈式鎖失效,可以增加降級。

  • 支持阻塞和非阻塞:和 ReentrantLock 一樣支持 lock 和 trylock 以及 tryLock(long timeOut)。

  • 支持公平鎖和非公平鎖(可選):公平鎖的意思是按照請求加鎖的順序獲得鎖,非公平鎖就相反是無序的。這個一般來說實現的比較少。

常見的分佈式鎖

我們瞭解了一些特點之後,我們一般實現分佈式鎖有以下幾個方式:

  • MySQL

  • ZK

  • Redis

  • 自研分佈式鎖:如谷歌的 Chubby。

下面分開介紹一下這些分佈式鎖的實現原理。

MySQL

首先來說一下 MySQL 分佈式鎖的實現原理,相對來說這個比較容易理解,畢竟數據庫和我們開發人員在平時的開發中息息相關。

對於分佈式鎖我們可以創建一個鎖表:


搞懂“分佈式鎖”,看這篇文章就對了



前面我們所說的 lock(),trylock(long timeout),trylock() 這幾個方法可以用下面的僞代碼實現。

lock()

lock 一般是阻塞式的獲取鎖,意思就是不獲取到鎖誓不罷休,那麼我們可以寫一個死循環來執行其操作:


搞懂“分佈式鎖”,看這篇文章就對了



mysqlLock.lcok 內部是一個 sql,爲了達到可重入鎖的效果,我們應該先進行查詢,如果有值,需要比較 node_info 是否一致。

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

僞代碼如下:


搞懂“分佈式鎖”,看這篇文章就對了



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

tryLock() 和 tryLock(long timeout)

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


搞懂“分佈式鎖”,看這篇文章就對了



tryLock(long timeout) 實現如下:


搞懂“分佈式鎖”,看這篇文章就對了



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

unlock()

unlock 的話如果這裏的 count 爲 1 那麼可以刪除,如果大於 1 那麼需要減去 1。


搞懂“分佈式鎖”,看這篇文章就對了



鎖超時

我們有可能會遇到我們的機器節點掛了,那麼這個鎖就不會得到釋放,我們可以啓動一個定時任務,通過計算一般我們處理任務的時間。

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

MySQL 小結:

  • 適用場景:MySQL 分佈式鎖一般適用於資源不存在數據庫,如果數據庫存在比如訂單,可以直接對這條數據加行鎖,不需要我們上面多的繁瑣的步驟。

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

  • 優點:理解起來簡單,不需要維護額外的第三方中間件(比如 Redis,ZK)。

  • 缺點:雖然容易理解但是實現起來較爲繁瑣,需要自己考慮鎖超時,加事務等等。性能侷限於數據庫,一般對比緩存來說性能較低。對於高併發的場景並不是很適合。

樂觀鎖

前面我們介紹的都是悲觀鎖,這裏想額外提一下樂觀鎖,在我們實際項目中也是經常實現樂觀鎖,因爲我們加行鎖的性能消耗比較大,通常我們對於一些競爭不是那麼激烈。

但是其又需要保證我們併發的順序執行使用樂觀鎖進行處理,我們可以對我們的表加一個版本號字段。

那麼我們查詢出來一個版本號之後,update 或者 delete 的時候需要依賴我們查詢出來的版本號,判斷當前數據庫和查詢出來的版本號是否相等,如果相等那麼就可以執行,如果不等那麼就不能執行。

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

ZooKeeper

ZooKeeper 也是我們常見的實現分佈式鎖方法,相比於數據庫如果沒了解過 ZooKeeper 可能上手比較難一些。

ZooKeeper 是以 Paxos 算法爲基礎的分佈式應用程序協調服務。ZK 的數據節點和文件目錄類似,所以我們可以用此特性實現分佈式鎖。

我們以某個資源爲目錄,然後這個目錄下面的節點就是我們需要獲取鎖的客戶端,未獲取到鎖的客戶端註冊需要註冊 Watcher 到上一個客戶端,可以用下圖表示:


搞懂“分佈式鎖”,看這篇文章就對了



/lock 是我們用於加鎖的目錄,/resource_name 是我們鎖定的資源,其下面的節點按照我們加鎖的順序排列。

Curator

Curator 封裝了 ZooKeeper 底層的 API,使我們更加容易方便的對 ZooKeeper 進行操作,並且它封裝了分佈式鎖的功能,這樣我們就不需要在自己實現了。

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

InterProcessMutex

InterProcessMutex 是 Curator 實現的可重入鎖,我們可以通過下面的一段代碼實現我們的可重入鎖:


搞懂“分佈式鎖”,看這篇文章就對了



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

加鎖的流程具體如下:

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

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

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

  • 然後在我們的資源目錄下創建一個節點:比如這裏創建一個 /0000000002 這個節點,這個節點需要設置爲 EPHEMERAL_SEQUENTIAL 也就是臨時節點並且有序。

  • 獲取當前目錄下所有子節點,判斷自己的節點是否位於子節點第一個。

  • 如果是第一個,則獲取到鎖,那麼可以返回。

  • 如果不是第一個,則證明前面已經有人獲取到鎖了,那麼需要獲取自己節點的前一個節點。

/0000000002 的前一個節點是 /0000000001,我們獲取到這個節點之後,再上面註冊 Watcher(這裏的 Watcher 其實調用的是 object.notifyAll(),用來解除阻塞)。

  • object.wait(timeout) 或 object.wait():進行阻塞等待,這裏和我們第 5 步的 Watcher 相對應。

解鎖的具體流程:

  • 首先進行可重入鎖的判定:如果有可重入鎖只需要次數減 1 即可,減 1 之後加鎖次數爲 0 的話繼續下面步驟,不爲 0 直接返回。

  • 刪除當前節點。

  • 刪除 threadDataMap 裏面的可重入鎖的數據。

讀寫鎖

Curator 提供了讀寫鎖,其實現類是 InterProce***eadWriteLock,這裏的每個節點都會加上前綴:

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

根據不同的前綴區分是讀鎖還是寫鎖,對於讀鎖,如果發現前面有寫鎖,那麼需要將 Watcher 註冊到和自己最近的寫鎖。寫鎖的邏輯和我們之前 4.2 分析的依然保持不變。

鎖超時

ZooKeeper 不需要配置鎖超時,由於我們設置節點是臨時節點,我們的每個機器維護着一個 ZK 的 Session,通過這個 Session,ZK 可以判斷機器是否宕機。

如果我們的機器掛掉的話,那麼這個臨時節點對應的就會被刪除,所以我們不需要關心鎖超時。

ZK 小結:

  • 優點:ZK 可以不需要關心鎖超時時間,實現起來有現成的第三方包,比較方便,並且支持讀寫鎖,ZK 獲取鎖會按照加鎖的順序,所以其是公平鎖。對於高可用利用 ZK 集羣進行保證。

  • 缺點:ZK 需要額外維護,增加維護成本,性能和 MySQL 相差不大,依然比較差。並且需要開發人員瞭解 ZK 是什麼。

Redis

大家在網上搜索分佈式鎖,恐怕最多的實現就是 Redis 了,Redis 因爲其性能好,實現起來簡單所以讓很多人都對其十分青睞。

Redis 分佈式鎖簡單實現

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

對於某個資源加鎖我們只需要:

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 實現的客戶端,其 API 提供了比較全面的 Redis 命令的支持。

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

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

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

下面介紹一下其如何實現分佈式鎖:

搞懂“分佈式鎖”,看這篇文章就對了


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

由於內部源碼較多,就不貼源碼了,這裏用文字敘述來分析它是如何加鎖的,這裏分析一下 tryLock 方法:

①嘗試加鎖:首先會嘗試進行加鎖,由於需要兼容老版本的 Redis,所以不能直接使用 ex,nx 原子操作的 API,那麼就只能使用 Lua 腳本,相關的 Lua 腳本如下:


搞懂“分佈式鎖”,看這篇文章就對了



可以看見它並沒有使用我們的 sexNx 來進行操作,而是使用的 hash 結構,我們的每一個需要鎖定的資源都可以看做是一個 HashMap,鎖定資源的節點信息是 Key,鎖定次數是 Value。

通過這種方式可以很好的實現可重入的效果,只需要對 Value 進行加 1 操作,就能進行可重入鎖。當然這裏也可以用之前我們說的本地計數進行優化。

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

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

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

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


搞懂“分佈式鎖”,看這篇文章就對了



Redission 還有公平鎖的實現,對於公平鎖其利用了 list 結構和 hashset 結構分別用來保存我們排隊的節點,和我們節點的過期時間,用這兩個數據結構幫助我們實現公平鎖,這裏就不展開介紹了,有興趣可以參考源碼。

RedLock

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

爲了解決這個問題 Redis 作者提出了 RedLock 紅鎖的算法,在 Redission 中也對 RedLock 進行了實現。


搞懂“分佈式鎖”,看這篇文章就對了



通過上面的代碼,我們需要實現多個 Redis 集羣,然後進行紅鎖的加鎖,解鎖。

具體的步驟如下:

①首先生成多個 Redis 集羣的 Rlock,並將其構造成 RedLock。

②依次循環對三個集羣進行加鎖,加鎖的過程和 5.2 裏面一致。

③如果循環加鎖的過程中加鎖失敗,那麼需要判斷加鎖失敗的次數是否超出了最大值,這裏的最大值是根據集羣的個數,比如三個那麼只允許失敗一個,五個的話只允許失敗兩個,要保證多數成功。

④加鎖的過程中需要判斷是否加鎖超時,有可能我們設置加鎖只能用 3ms,第一個集羣加鎖已經消耗了 3ms 了。那麼也算加鎖失敗。

⑤3,4 步裏面加鎖失敗的話,那麼就會進行解鎖操作,解鎖會對所有的集羣在請求一次解鎖。

可以看見 RedLock 基本原理是利用多個 Redis 集羣,用多數的集羣加鎖成功,減少 Redis 某個集羣出故障,造成分佈式鎖出現問題的概率。

Redis 小結:

  • 優點:對於 Redis 實現簡單,性能對比 ZK 和 MySQL 較好。如果不需要特別複雜的要求,自己就可以利用 setNx 進行實現,如果自己需要複雜的需求的話,可以利用或者借鑑 Redission。對於一些要求比較嚴格的場景可以使用 RedLock。

  • 缺點:需要維護 Redis 集羣,如果要實現 RedLock 需要維護更多的集羣。

分佈式鎖的安全問題

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

有關於 Martin 反駁的幾點,我認爲其實不僅僅侷限於 RedLock,前面說的算法基本都有這個問題,下面我們來討論一下這些問題。

長時間的 GC pause

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

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


搞懂“分佈式鎖”,看這篇文章就對了



client1 獲取了鎖並且設置了鎖的超時時間,但是 client1 之後出現了 STW,這個 STW 時間比較長,導致分佈式鎖進行了釋放。

client2 獲取到了鎖,這個時候 client1 恢復了鎖,那麼就會出現 client1,2 同時獲取到鎖,這個時候分佈式鎖不安全問題就出現了。

這個不僅僅侷限於 RedLock,對於我們的 ZK,MySQL 一樣的有同樣的問題。

時鐘發生跳躍

對於 Redis 服務器如果其時間發生了跳躍,肯定會影響我們鎖的過期時間。

那麼我們的鎖過期時間就不是我們預期的了,也會出現 client1 和 client2 獲取到同一把鎖,也會出現不安全,這個對於 MySQL 也會出現。但是 ZK 由於沒有設置過期時間,那麼發生跳躍也不會受影響。

長時間的網絡 I/O

這個問題和我們的 GC 的 STW 很像,也就是我們這個獲取了鎖之後我們進行網絡調用,其調用時間由可能比我們鎖的過期時間都還長,那麼也會出現不安全的問題,這個 MySQL 也會有,ZK 也不會出現這個問題。

對於這三個問題,在網上包括 Redis 作者在內發起了很多討論。

GC 的 STW

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

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

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

時鐘發生跳躍

Martin 覺得 RedLock 不安全很大的原因也是因爲時鐘的跳躍,因爲鎖過期強依賴於時間,但是 ZK 不需要依賴時間,依賴每個節點的 Session。

Redis 作者也給出瞭解答,對於時間跳躍分爲人爲調整和 NTP 自動調整:

  • 人爲調整:人爲調整影響的完全可以人爲不調整,這個是處於可控的。

  • NTP 自動調整:這個可以通過一定的優化,把跳躍時間控制在可控範圍內,雖然會跳躍,但是是完全可以接受的。

長時間的網絡 I/O

這一塊不是他們討論的重點,我自己覺得,對於這個問題的優化可以控制網絡調用的超時時間,把所有網絡調用的超時時間相加。

那麼我們鎖過期時間其實應該大於這個時間,當然也可以通過優化網絡調用比如串行改成並行,異步化等。

Chubby 的一些優化

大家搜索 ZK 的時候,會發現他們都寫了 ZK 是 Chubby 的開源實現,Chubby 內部工作原理和 ZK 類似。但是 Chubby 的定位是分佈式鎖和 ZK 有點不同。

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

  • CheckSequencer():調用 Chubby 的 API 檢查此時這個序列號是否有效。

  • 訪問資源服務器檢查,判斷當前資源服務器最新的序列號和我們的序列號的大小。

  • lock-delay:爲了防止我們校驗的邏輯***我們的資源服務器,其提供了一種方法當客戶端失聯的時候,並不會立即釋放鎖,而是在一定的時間內(默認 1min)阻止其他客戶端拿去這個鎖。

那麼也就是給予了一定的 buffer 等待 STW 恢復,而我們的 GC 的 STW 時間如果比 1min 還長那麼你應該檢查你的程序,而不是懷疑你的分佈式鎖了。

小結

本文主要講了多種分佈式鎖的實現方法,以及它們的一些優缺點。最後也說了一下關於分佈式鎖的安全的問題。

對於不同的業務需要的安全程度完全不同,我們需要根據自己的業務場景,通過不同的維度分析,選取最適合自己的方案。


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章