1. 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。