Zookeeper 如何實現分布式鎖

zookeeper 分布式鎖的原理

zookeeper 的資料儲存結構就像一棵樹，這棵樹由節點組成，這種節點叫做 znode。

znode 分為四種型別：

預設的節點型別。建立節點的客戶端與 zookeeper 斷開連線後，該節點依舊存在。

所謂順序節點，就是在建立節點時，zookeeper 根據建立的時間順序給該節點名稱進行編號：

和持久節點相反，當建立節點的客戶端與 zookeeper 斷開連線後，臨時節點會被刪除：

顧名思義，臨時順序節點結合和臨時節點和順序節點的特點：在建立節點時，zookeeper 根據建立的時間順序給該節點名稱進行編號；當建立節點的客戶端與 zookeeper 斷開連線後，臨時節點會被刪除。

zookeeper 分布式鎖恰恰應用了臨時順序節點。具體如何實現呢？讓我們來看一看詳細步驟：

首先，在 zookeeper 當中建立乙個持久節點 parentlock。當第乙個客戶端想要獲得鎖時，需要在 parentlock 這個節點下面建立乙個臨時順序節點 lock1。

之後，client1 查詢 parentlock 下面所有的臨時順序節點並排序，判斷自己所建立的節點 lock1 是不是順序最靠前的乙個。如果是第乙個節點，則成功獲得鎖。

client2 查詢 parentlock 下面所有的臨時順序節點並排序，判斷自己所建立的節點 lock2 是不是順序最靠前的乙個，結果發現節點 lock2 並不是最小的。

於是，client2 向排序僅比它靠前的節點 lock1 註冊 watcher，用於監聽 lock1 節點是否存在。這意味著 client2 搶鎖失敗，進入了等待狀態。

於是，client3 向排序僅比它靠前的節點 lock2 註冊 watcher，用於監聽 lock2 節點是否存在。這意味著 client3 同樣搶鎖失敗，進入了等待狀態。

這樣一來，client1 得到了鎖，client2 監聽了 lock1，client3 監聽了 lock2。這恰恰形成了乙個等待佇列.

釋放鎖分為兩種情況：

任務完成，客戶端顯示釋放

當任務完成時，client1 會顯示呼叫刪除節點 lock1 的指令。

任務執行過程中，客戶端崩潰

由於 client2 一直監聽著 lock1 的存在狀態，當 lock1 節點被刪除，client2 會立刻收到通知。這時候 client2 會再次查詢 parentlock 下面的所有節點，確認自己建立的節點 lock2 是不是目前最小的節點。如果是最小，則 client2 順理成章獲得了鎖。

同理，如果 client2 也因為任務完成或者節點崩潰而刪除了節點 lock2，那麼 client3 就會接到通知。

最終，client3 成功得到了鎖。