zookeeper3.3學習筆記4：zookeeper的三種角色

zookeeper的每一個節點能夠有以下三種角色：

1.leader和follower

 

      ZooKeeper須要在全部的服務（能夠理解爲服務器）中選舉出一個Leader，而後讓這個Leader來負責管理集羣。此時，集羣中的其它服務器則成爲此Leader的Follower。而且，當Leader故障的時候，須要ZooKeeper可以快速地在Follower中選舉出下一個Leader。這就是ZooKeeper的Leader機制，下面咱們將簡單介紹在ZooKeeper中，Leader選舉（Leader Election）是如何實現的。

此操做實現的核心思想是：首先建立一個EPHEMERAL目錄節點，例如「/election」。而後。每個ZooKeeper服務器在此目錄下建立一個SEQUENCE|EPHEMERAL類型的節點，例如「/election/n_」。在SEQUENCE標誌下，ZooKeeper將自動地爲每個ZooKeeper服務器分配一個比前一個分配的序號要大的序號。此時建立節點的ZooKeeper服務器中擁有最小序號編號的服務器將成爲Leader。

在實際的操做中，還須要保障：當Leader服務器發生故障的時候，系統可以快速地選出下一個ZooKeeper服務器做爲Leader。一個簡單的解決方案是，讓全部的follower監視leader所對應的節點。當Leader發生故障時，Leader所對應的臨時節點將會自動地被刪除，此操做將會觸發全部監視Leader的服務器的watch。這樣這些服務器將會收到Leader故障的消息，並進而進行下一次的Leader選舉操做。可是，這種操做將會致使「從衆效應」的發生，尤爲當集羣中服務器衆多而且帶寬延遲比較大的時候，此種狀況更爲明顯。

在Zookeeper中，爲了不從衆效應的發生，它是這樣來實現的：每個follower對follower集羣中對應的比本身節點序號小一號的節點（也就是全部序號比本身小的節點中的序號最大的節點）設置一個watch。只有當follower所設置的watch被觸發的時候，它才進行Leader選舉操做，通常狀況下它將成爲集羣中的下一個Leader。很明顯，此Leader選舉操做的速度是很快的。由於，每一次Leader選舉幾乎只涉及單個follower的操做。

 

 

2.Observer

      observer的行爲在大多數狀況下與follower徹底一致, 可是他們不參加選舉和投票, 而僅僅接受(observing)選舉和投票的結果.

 

參考：

http://labs.chinamobile.com/mblog/225_35225

 

http://hi.baidu.com/airyoung/blog/item/c8ab53d628ac4a3506088b6b.html

 

http://www.blogjava.net/ivanwan/archive/2011/05/05/349582.html

 

http://zookeeper.apache.org/doc/r3.3.2/zookeeperObservers.html