歡迎關注本人公眾號

大家也許都很熟悉了多個執行緒或者多個程序間的共享鎖的實現方式了，但是在分散式場景中我們會面臨多個Server之間的鎖的問題，實現的複雜度比較高。利用基於google chubby原理開發的開源的zookeeper，可以使得這個問題變得簡單很多。下面介紹幾種可能的實現方式，並且對比每種實現方式的優缺點。

1. 利用節點名稱的唯一性來實現共享鎖

ZooKeeper抽象出來的節點結構是一個和unix檔案系統類似的小型的樹狀的目錄結構。ZooKeeper機制規定：同一個目錄下只能有一個唯一的檔名。例如：我們在Zookeeper目錄/test目錄下建立，兩個客戶端建立一個名為Lock節點，只有一個能夠成功。

演算法思路: 利用名稱唯一性，加鎖操作時，只需要所有客戶端一起建立/test/Lock節點，只有一個建立成功，成功者獲得鎖。解鎖時，只需刪除/test/Lock節點，其餘客戶端再次進入競爭建立節點，直到所有客戶端都獲得鎖。

基於以上機制，利用節點名稱唯一性機制的共享鎖演算法流程如圖所示：

該共享鎖實現很符合我們通常多個執行緒去競爭鎖的概念，利用節點名稱唯一性的做法簡明、可靠。

由上述演算法容易看出，由於客戶端會同時收到/test/Lock被刪除的通知，重新進入競爭建立節點，故存在"驚群現象"。

使用該方法進行測試鎖的效能列表如下：

總結 這種方案的正確性和可靠性是ZooKeeper機制保證的，實現簡單。缺點是會產生“驚群”效應，假如許多客戶端在等待一把鎖，當鎖釋放時候所有客戶端都被喚醒，僅僅有一個客戶端得到鎖。

2. 利用臨時順序節點實現共享鎖的一般做法

首先介紹一下，Zookeeper中有一種節點叫做順序節點，故名思議，假如我們在/lock/目錄下建立節3個點，ZooKeeper叢集會按照提起建立的順序來建立節點，節點分別為/lock/0000000001、/lock/0000000002、/lock/0000000003。

ZooKeeper中還有一種名為臨時節點的節點，臨時節點由某個客戶端建立，當客戶端與ZooKeeper叢集斷開連線，則開節點自動被刪除。

利用上面這兩個特性，我們來看下獲取實現分散式鎖的基本邏輯：

• 客戶端呼叫create()方法建立名為“locknode/guid-lock-”的節點，需要注意的是，這裡節點的建立型別需要設定為EPHEMERAL_SEQUENTIAL。
• 客戶端呼叫getChildren(“locknode”)方法來獲取所有已經建立的子節點，同時在這個節點上註冊上子節點變更通知的Watcher。
• 客戶端獲取到所有子節點path之後，如果發現自己在步驟1中建立的節點是所有節點中序號最小的，那麼就認為這個客戶端獲得了鎖。
• 如果在步驟3中發現自己並非是所有子節點中最小的，說明自己還沒有獲取到鎖，就開始等待，直到下次子節點變更通知的時候，再進行子節點的獲取，判斷是否獲取鎖。

釋放鎖的過程相對比較簡單，就是刪除自己建立的那個子節點即可。

上面這個分散式鎖的實現中，大體能夠滿足了一般的分散式叢集競爭鎖的需求。這裡說的一般性場景是指叢集規模不大，一般在10臺機器以內。

不過，細想上面的實現邏輯，我們很容易會發現一個問題，步驟4，“即獲取所有的子點，判斷自己建立的節點是否已經是序號最小的節點”，這個過程，在整個分散式鎖的競爭過程中，大量重複執行，並且絕大多數的執行結果都是判斷出自己並非是序號最小的節點，從而繼續等待下一次通知——這個顯然看起來不怎麼科學。客戶端無端的接受到過多的和自己不相關的事件通知，這如果在叢集規模大的時候，會對Server造成很大的效能影響，並且如果一旦同一時間有多個節點的客戶端斷開連線，這個時候，伺服器就會像其餘客戶端傳送大量的事件通知——這就是所謂的驚群效應。而這個問題的根源在於，沒有找準客戶端真正的關注點。

我們再來回顧一下上面的分散式鎖競爭過程，它的核心邏輯在於：判斷自己是否是所有節點中序號最小的。於是，很容易可以聯想的到的是，每個節點的建立者只需要關注比自己序號小的那個節點。

3. 利用臨時順序節點實現共享鎖的改進實現

下面是改進後的分散式鎖實現，和之前的實現方式唯一不同之處在於，這裡設計成每個鎖競爭者，只需要關注”locknode”節點下序號比自己小的那個節點是否存在即可。

演算法思路：對於加鎖操作，可以讓所有客戶端都去/lock目錄下建立臨時順序節點，如果建立的客戶端發現自身建立節點序列號是/lock/目錄下最小的節點，則獲得鎖。否則，監視比自己建立節點的序列號小的節點（比自己建立的節點小的最大節點），進入等待。

對於解鎖操作，只需要將自身建立的節點刪除即可。

具體演算法流程如下圖所示:

使用上述演算法進行測試的的結果如下表所示：

該演算法只監控比自身建立節點序列號小(比自己小的最大的節點)的節點，在當前獲得鎖的節點釋放鎖的時候沒有“驚群”。

總結 利用臨時順序節點來實現分散式鎖機制其實就是一種按照建立順序排隊的實現。這種方案效率高，避免了“驚群”效應，多個客戶端共同等待鎖，當鎖釋放時只有一個客戶端會被喚醒。

4. 使用menagerie

其實就是對方案3的一個封裝，不用自己寫程式碼了。直接拿來用就可以了。

menagerie基於Zookeeper實現了java.util.concurrent包的一個分散式版本。這個封裝是更大粒度上對各種分散式一致性使用場景的抽象。其中最基礎和常用的是一個分散式鎖的實現： org.menagerie.locks.ReentrantZkLock，通過ZooKeeper的全域性有序的特性和EPHEMERAL_SEQUENTIAL型別znode的支援，實現了分散式鎖。具體做法是：不同的client上每個試圖獲得鎖的執行緒，都在相同的basepath下面建立一個EPHEMERAL_SEQUENTIAL的node。EPHEMERAL表示要建立的是臨時znode，建立連線斷開時會自動刪除； SEQUENTIAL表示要自動在傳入的path後面綴上一個自增的全域性唯一字尾,作為最終的path。因此對不同的請求ZK會生成不同的字尾，並分別返回帶了各自後綴的path給各個請求。因為ZK全域性有序的特性，不管client請求怎樣先後到達，在ZKServer端都會最終排好一個順序，因此自增字尾最小的那個子節點，就對應第一個到達ZK的有效請求。然後client讀取basepath下的所有子節點和ZK返回給自己的path進行比較，當發現自己建立的sequential node的字尾序號排在第一個時，就認為自己獲得了鎖；否則的話，就認為自己沒有獲得鎖。這時肯定是有其他併發的並且是沒有斷開的client/執行緒先建立了node。

menagerie地址：https://github.com/openUtility/menagerie

參考資料以及推薦閱讀