大家也許都很熟悉了多個線程或者多個進程間的共享鎖的實現方式了，但是在分佈式場景中我們會面臨多個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
轉載自：http://ju.outofmemory.cn/entry/75844