ZooKeeper向Client(s)提供高可用的{鍵、值}對的讀/寫操作，高可用實現原理是透過將資料同時複製到多個節點，讓Client可從任一節點讀取。而ZooKeeper設計的關鍵是遵循了這樣一個規則(observation)，即每個狀態改變都是前一狀態的增量；因此，它對狀態改變的順序存在一種固有依賴。ZooKeeper原子廣播協議就是這樣一種能確保ZooKeeper複製順序的協議，同時它也能處理leader選舉和leader失效後時的節點恢復。ZooKeeper原子廣播協議英文全稱，Zookeeper Atomic Broadcast (ZAB) protocol，也即本文主題。

定義

leader和followers --在ZooKeeper叢集中，同一時刻，只能有一個節點擔任leader, 剩下的為follower。leader負責接收來自Client(s)的所用狀態變更，它在自己儲存的同時，也會複製到其他的follower(s)。不過，對於所有讀請求，則是被同時負載均衡到leader和follower(s)。

transactions -- 事務，即Client狀態變更, 它(們)會由leader傳播到它的follower(s)：

‘e’ -- leader的epoch。epoch是由普通節點變為leader時，生成的一個整數。它應該大於任何先前leader的epoch；‘c’ -- 一個由leader生成的序數，從0開始，向上增加。它和epoch一起被用作對不斷到來的Client(s)狀態改變/事務進行排序；‘F.history’ -- follower的history佇列。用於確保到達事務，按照它們到達的先後順序被提交；outstanding transactions -- F.history中序號小於當前COMMIT序號的事務集合。ZAB要求

1. 複製保證

可靠遞送-- 如果一個事務M被一個伺服器提交，它最後也會被所有伺服器提交。絕對順序-- 如果一個伺服器提交的事務A先於事務B, 那麼對於所有伺服器，A都將先於B被提交。因果順序（Causal Order）-- 如果事務B傳送的時間，是在B的傳送者提交事務A之後，A必須是排在B之前。如果在傳送B之後，某個傳送者發出C ，那麼C必須排在B之後。

2. 只要達到法定數量(quorum)/大多數節點是正常的，事務就會被複制。

3. 在事務複製期間，因down機錯過的失敗節點，恢復執行時應能再次獲得。

ZooKeeper使用一種two-phase-commit協議的變體，將複製事務到follower(s)。當leader接收到來自某個Client的狀態更新時，它用序數c和leader epoch e(見前面定義)生成一個事務，並將其傳送給所有follower(s)。

follower接收後，會將事務新增到它的history佇列中，並向leader回送ACK。當leader收到法定數量(quorum)的ACK時，它就會發出事務quorum提交。接收到提交的follower(s)就會提交該事務，除非c值大於它history佇列裡的所用序號。這時，它會先等待接收先前事務(outstanding transaction(s))的提交操作，然後再執行該提交。

一旦leader崩潰，節點間會執行一個recovery協議，以確保以下兩點：

恢復正常服務之前，節點間對共同狀態的一致性達成共識；找出一個新leader來廣播狀態更新。一個節點要行使leader角色，獲得法定數量(quorum)的節點支援也是必須的。現實中，由於存在節點的崩潰、恢復往復；一段時間裡，可能出現多位leader的更迭，甚至是同一節點多次成為leader的情形。

節點的生命週期：每個節點要麼一次執行這個協議的一個完整迴圈；要麼迴圈被突然中斷，回到Phase 0, 再開始一個新的迴圈。

Phase 0 -- leader選舉Phase 1 -- 發現Phase 2 -- 同步Phase 3 -- 廣播

注：Phase 1和Phase 2，對於確保所有節點上狀態的一致性很重要，特別是在節點從崩潰恢復時。

Phase 0 -- leader選舉

節點在該階段執行初始化，狀態為election。leader選舉協議不必多特別，只要可結束、高機率，能選出一個可用節點，選舉節點數達到法定數量(quorum)就行。leader選舉演算法結束後，節點會將它的選舉結果儲存到本地記憶體。

大致為：如果節點p投票給p0, 那麼p0就稱為p的預期leader；如果節點投票給它自己，它的狀態應設為leading，否則就設為following。順便提一下，只有到達Phase 3的開始，這裡選出的預期leader才可能變成真正的leader，併成為主處理節點。

Phase 1 -- 發現

在這個階段，follower(s)和它們的預期leader保持通訊，以便leader能夠收集有關follower(s)最近接受的事務資訊。這個階段的目的，是為了在法定數量(quorum)節點內，發現儘可能多的已接受事務更新序號，以便建立一個新的epoch,以防先前的leader再提交新的事務。

理論上，具有法定人數(quorum)數量的follower(s)都擁有前任leader所有已接受狀態變更的資訊，於是在當前法定節點數(quorum)中，至少有一個follower，在它的history佇列中擁有前任leader所有已接受的狀態變更。這就意味著，這位新leader同樣可以獲得這些資訊，具體演算法如下：

Phase 2 -- 同步

同步階段對該協議的發現階段做出總結，即leader將用發現階段獲得的變更歷史，對叢集節點進行同步操作。leader會和follower(s)進行通訊，並從自己的history佇列裡發出事務。如果follower(s)的history滯後於leader，follower(s)就會回覆ACK； 當leader看到來自法定節點數(quorum)的ACK,它就會發出提交資訊給它們。此時，leader角色真正成立，不再是預期leader了。演算法如下：

Phase 3 -- 廣播

現在開始，如果沒有節點發生崩潰，它們將永遠呆在該階段，收到ZooKeeper Client發出的寫請求，就執行事務廣播。演算法如下：

注：對於失敗檢測，ZAB採用的是在leader和follower(s)間週期性的傳送心跳(heartbeat)資訊。如果leader在規定時間內，沒有收到法定數量(quorum)節點的心跳，它就會放棄領導權，並轉到選舉狀態，Phase 0；而如果follower超時未收到來自leader的心跳(heartbeat)也會轉入leader選舉階段。

Zookeeper的主要有四個作用：

配置管理

名字服務

提供分散式同步

叢集管理

配置管理

在我們的應用中，會有一些配置項是寫在

application.properties

檔案裡的，程式碼中透過@Value讀取對應的值，如果配置非常多，而且還可能是動態的話使用配置檔案就需要重啟服務。這個時候往往需要尋找一種集中管理配置的方法，我們在這個集中的地方修改了配置，所有對這個配置感興趣的都可以獲得變更。

這個時候就需要使用一種實現了一致性協議的服務了。Zookeeper就是這種服務，它使用Zab（原子廣播協議）來提供一致性。現在有很多開源專案使用Zookeeper來維護配置，比如在訊息佇列Kafka中，使用Zookeeper來維護broker的資訊。在Alibaba開源的SOA框架Dubbo中也廣泛的使用Zookeeper管理一些配置來實現服務治理。

名字服務

我們大家應該都知道DNS這個東西。我們只需要訪問一個大家熟知的站點，它就會告訴你這個域名對應的IP是什麼。我們的應用中也會存在很多這類問題，特別是在我們的服務特別多的時候，如果我們在本地儲存服務的地址將非常不方便，但如果我們只需要訪問一個大家都熟知的endpoint，這裡提供統一的入口，那麼維護起來將方便得多。

分散式鎖

可以利用Zookeeper來協調多個分散式程序之間的活動。比如在一個分散式環境中，為了提高可靠性，叢集的每臺伺服器上都部署著同樣的服務。但是，一件事情如果叢集中的每個伺服器都進行的話，那相互之間就要協調，程式設計起來非常複雜。如果我們只讓一個服務進行操作，那又存在單點。

通常的做法就是使用分散式鎖，在某個時刻只讓一個服務去工作，當這個服務出問題時釋放鎖，立即fail over到另外的服務，即Leader Election(leader選舉)機制。比如HBase的Master就是採用這種機制。需要注意的是分散式鎖跟同一個程序的鎖還是有區別的，所以使用的時候要比同一個程序裡的鎖更謹慎的使用。

叢集管理

在分散式叢集中，經常有各種原因，比如硬體故障，軟體故障，網路問題，有新的節點加入進來，也有老的節點退出叢集。這時，叢集中其他機器需要感知到這種變化，然後根據這種變化做出對應的決策。

比如一個分散式儲存系統，有一箇中央控制節點負責儲存的分配，當有新的儲存進來時我們要根據現在叢集當前的狀態分配儲存節點。這時我們就需要動態感知到叢集目前的狀態。

還有，比如一個分散式的SOA架構中，服務是一個叢集提供的，當消費者訪問某個服務時，就需要採用某種機制發現現在有哪些節點可以提供該服務(這也稱之為服務發現，比如Alibaba開源的SOA框架Dubbo就採用了Zookeeper作為服務發現的底層機制)。還有開源的Kafka佇列就採用了Zookeeper作為Cosnumer的上下線管理。

zookeeper意思就是動物園管理員，為什麼這麼起名字呢？因為世面上的大資料框架比如hadoop，spark等，它們的圖示都是動物，而zppkeeper可以管理這些大資料框架，所以起這個名字意思就是把動物們管理起來。哈哈，這是我的個人見解。。。