本文主要講述在使用ZooKeeper進行分布式鎖的實現過程中，如何有效的避免“羊群效應(?herd effect)”的出現。

一般的分布式鎖實現

這里簡單的講下一般的分布式鎖如何實現。具體的代碼實現可以在這里看到：https://svn.apache.org/repos/asf/zookeeper/trunk/src/recipes/lock/

在之前的《ZooKeepe數據模型》一文中提到過，zookeeper中節點的創建類型有4類，這里我們重點關注下臨時順序節點。這種類型的節點有幾下幾個特性：

節點的生命周期和客戶端會話綁定，即創建節點的客戶端會話一旦失效，那么這個節點也會被清除。

每個父節點都會負責維護其子節點創建的先后順序，并且如果創建的是順序節點（SEQUENTIAL）的話，父節點會自動為這個節點分配一個整形數值，以后綴的形式自動追加到節點名中，作為這個節點最終的節點名。

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

客戶端調用create()方法創建名為“_locknode_/guid-lock-”的節點，需要注意的是，這里節點的創建類型需要設置為EPHEMERAL_SEQUENTIAL。

客戶端調用getChildren(“_locknode_”)方法來獲取所有已經創建的子節點，同時在這個節點上注冊上子節點變更通知的Watcher。

客戶端獲取到所有子節點path之后，如果發現自己在步驟1中創建的節點是所有節點中序號最小的，那么就認為這個客戶端獲得了鎖。

如果在步驟3中發現自己并非是所有子節點中最小的，說明自己還沒有獲取到鎖，就開始等待，直到下次子節點變更通知的時候，再進行子節點的獲取，判斷是否獲取鎖。

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

問題所在

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

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

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

改進后的分布式鎖實現

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

客戶端調用create()方法創建名為“_locknode_/guid-lock-”的節點，需要注意的是，這里節點的創建類型需要設置為EPHEMERAL_SEQUENTIAL。

客戶端調用getChildren(“_locknode_”)方法來獲取所有已經創建的子節點，注意，這里不注冊任何Watcher。

客戶端獲取到所有子節點path之后，如果發現自己在步驟1中創建的節點序號最小，那么就認為這個客戶端獲得了鎖。

如果在步驟3中發現自己并非所有子節點中最小的，說明自己還沒有獲取到鎖。此時客戶端需要找到比自己小的那個節點，然后對其調用exist()方法，同時注冊事件監聽。

之后當這個被關注的節點被移除了，客戶端會收到相應的通知。這個時候客戶端需要再次調用getChildren(“_locknode_”)方法來獲取所有已經創建的子節點，確保自己確實是最小的節點了，然后進入步驟3。

結論

上次兩個分布鎖實現，都是可行的。具體選擇哪個，取決于你的集群規模。

轉發來自：http://rdc.taobao.com/team/jm/archives/tag/zookeeper

總結

以上是生活随笔為你收集整理的zookeeper分布式锁避免羊群效应（Herd Effect）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。