ZooKeeper是一個分佈式的應用程序協調服務。
2 ZooKeeper的工作原理
Zookeeper 的核心是原子廣播，這個機制保證了各個Server之間的同步。實現這個機制的協議叫做Zab(Zookeeper Atomic Broadcast)協議。Zab協議有兩種模式，它們分別是恢復模式（recovery選主）和 廣播模式（broadcast同步）。當服務啓動或者在領導者崩潰後，Zab就進入了恢復模式，當領導者被選舉出來，且大多數Server完成了和leader的狀態同步以 後，恢復模式就結束了。狀態同步保證了leader和Server具有相同的系統狀態。
1、ZooKeeper數據模型：
類似於一個標準的文件系統，具有層次關係的數據結構
每個子目錄項如NameService都被稱作爲znode。
ZNode根據其本身的特性，可以分爲下面兩類：
Regular ZNode: 常規型ZNode，
Ephemeral ZNode: (ɪ’fem(ə)r(ə)l)（臨時的）類型的目錄節點不能有子節點目錄。
Zookeeper的客戶端和服務器通信採用長連接方式，每個客戶 端和服務器通過心跳來保持連接，這個連接狀態稱爲session，如果znode是臨時節點，這個session失效，znode也就刪除了。(3s/一次，200次)。
如果Client因爲Timeout和Zookeeper Server失去連接，client處在CONNECTING狀態，會自動嘗試再去連接Server，如果在session有效期內再次成功連接到某個Server，則回到CONNECTED狀態。
2、ZooKeeper Watch：
Zookeeper從設計模式的角度來看，是一個基於觀察者設計模式設計的。簡單來說就是
Client可以在某個ZNode上設置一個Watcher，來Watch該ZNode上的變化。如果該ZNode上有相應的變化，就會觸發這個Watcher，把相應的事件通知給設置Watcher的Client。需要注意的是，ZooKeeper中的Watcher是一次性的，即觸發一次就會被取消，如果想繼續Watch的話，需要客戶端重新設置Watcher。
3、ZooKeeper特性 ：
讀、寫(更新)模式：
在ZooKeeper集羣中，讀可以從任意一個ZooKeeper Server讀。寫的請求會先Forwarder到Leader，然後由Leader來通過ZooKeeper中的原子廣播協議，將請求廣播給所有的Follower，Leader收到一半以上的寫成功的消息後，就認爲該寫成功了，就會將該寫進行持久化，並告訴客戶端寫成功了。
FIFO
對於每一個ZooKeeper客戶端而言，所有的操作都是遵循FIFO順序的，這一特性是由下面兩個基本特性來保證的：一是ZooKeeper Client與Server之間的網絡通信是基於TCP，TCP保證了Client/Server之間傳輸包的順序；二是ZooKeeper Server執行客戶端請求也是嚴格按照FIFO順序的。
爲 了保證事務的順序一致性，zookeeper採用了遞增的事務id號（zxid）來標識事務。所有的提議（proposal）都在被提出的時候加上了 zxid。實現中zxid是一個64位的數字，它高32位是epoch用來標識leader關係是否改變，每次一個leader被選出來，它都會有一個新 的epoch，標識當前屬於那個leader的統治時期。低32位用於遞增計數。
ZooKeeper典型應用場景
1.名字服務(NameService) ：
每個ZNode都可以由其路徑唯一標識，路徑本身也比較簡潔直觀，另外ZNode上還可以存儲少量數據，這些都是實現統一的NameService的基礎。通過簡單的名字，訪問對應的服務器集羣。
2.配置管理(Configuration Management) ：
一:分佈式互斥鎖
在傳統的應用程序中，線程、進程的同步，都可以通過操作系統提供的機制來完成。但是在分佈式系統中，多個進程之間的同步，操作系統層面就無能爲力了。
zookeeper中,並沒有像JAVA裏一樣有Synchronized或者是ReentrantLock機制來實現鎖機制,但是在zookeeper中,實現起來更簡單：我們可以講將zk的一個數據節點代表一個鎖,當多個客戶端同時調用create()節點創建節點的時候,zookeeper會保證只會有一個客戶端創建成功,那麼我們就可以讓這個創建成功的客戶端讓其持有鎖,而其它的客戶端則註冊Watcher監聽當持有鎖的客戶端釋放鎖後,監聽的客戶端就會收到Watcher通知,然後再去試圖獲取鎖,這樣反覆即可。
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)選舉和投票的結果.
Zookeeper集羣，選舉機制
zookeeper選舉機制
FastLeaderElection算法通過異步的通信方式來收集其它節點的選票，同時在分析選票時又根據投票者的當前狀態來作不同的處理，以加快Leader的選舉進程。
每個在zookeeper服務器啓動先讀取當前保存在磁盤的數據,zookeeper中的每份數據都有一個對應的id值,這個值是依次遞增的；換言之,越新的數據,對應的ID值就越大。
在讀取數據完畢之後,每個zookeeper服務器發送自己選舉的leader,這個協議中包含了以下幾部分的數據:
1)、所選舉leader的id(就是配置文件中寫好的每個服務器的id) ,在初始階段,每臺服務器的這個值都是自己服務器的id,也就是它們都選舉自己爲leader。
2)、服務器最大數據的id,這個值大的服務器,說明存放了更新的數據。
3)、邏輯時鐘的值,這個值從0開始遞增,每次選舉對應一個值,也就是說:如果在同一次選舉中,那麼這個值應該是一致的，邏輯時鐘值越大,說明這一次選舉leader的進程更新。
4)、本機在當前選舉過程中的狀態,有以下幾種:LOOKING,FOLLOWING,OBSERVING,LEADING
每臺服務器將自己服務器的以上數據發送到集羣中的其他服務器之後,同樣的也需要接收來自其他服務器的數據,它將做以下的處理:
A、如果所接收數據服務器的狀態還是在選舉階段(LOOKING 狀態),那麼首先判斷邏輯時鐘值,又分爲以下三種情況:
a) 如果發送過來的邏輯時鐘大於目前的邏輯時鐘,那麼說明這是更新的一次選舉,此時需要更新一下本機的邏輯時鐘值，代碼如下:
if (n.epoch > logicalclock) { logicalclock = n.epoch; recvset.clear(); if(totalOrderPredicate(n.leader, n.zxid,getInitId(), getInitLastLoggedZxid())) updateProposal(n.leader, n.zxid); else updateProposal(getInitId(),getInitLastLoggedZxid()); sendNotifications();
其中的totalOrderPredicate函數就是根據發送過來的封包中的leader id,數據id來與本機保存的相應數據進行判斷的函數（首先看數據id,數據id大者勝出;其次再判斷leader id,leader id大者勝出）,返回true則調用updateProposal函數更新數據。
b) 發送過來數據的邏輯時鐘小於本機的邏輯時鐘
說明對方在一個相對較早的選舉進程中,這裏只需要將本機的數據廣播出去
c) 兩邊的邏輯時鐘相同,此時也只是調用totalOrderPredicate函數判斷是否需要更新本機的數據,將最新的選舉結果廣播出去
B、如果所接收服務器不在選舉狀態,也就是在FOLLOWING或者LEADING狀態
a) 如果邏輯時鐘相同,將該數據保存到recvset,如果所接收服務器宣稱自己是leader,那麼將判斷是不是有半數以上的服務器選舉它,如果是則設置選舉狀態退出選舉過程
如果邏輯時鐘不相同,那麼說明在另一個選舉過程中已經有了選舉結果,於是將該選舉結果加入到outofelection集合中,再根 據outofelection來判斷是否可以結束選舉,如果可以也是保存邏輯時鐘,設置選舉狀態,退出選舉過程
以一個簡單的例子來說明整個選舉的過程.
假設有五臺服務器組成的zookeeper集羣,它們的id從1-5,同時它們都是最新啓動的,也就是沒有歷史數據,在存放數據量這一點上,都是一樣的.假設這些服務器依序啓動,來看看會發生什麼
- 服務器1啓動,此時只有它一臺服務器啓動了,它發出去的報沒有任何響應,所以它的選舉狀態一直是LOOKING狀態
- 服務器2啓動,它與最開始啓動的服務器1進行通信,互相交換自己的選舉結果,由於兩者都沒有歷史數據,所以id值較大的服務器2勝出,但是由於沒有達到超 過半數以上的服務器都同意選舉它(這個例子中的半數以上是3),所以服務器1,2還是繼續保持LOOKING狀態.
- 服務器3啓動,根據前面的理論分析,服務器3成爲服務器1,2,3中的老大,而與上面不同的是,此時有三臺服務器選舉了它,所以它成爲了這次選舉的leader.
- 服務器4啓動,根據前面的分析,理論上服務器4應該是服務器1,2,3,4中最大的,但是由於前面已經有半數以上的服務器選舉了服務器3,所以它只能接收當小弟的命了.
- 服務器5啓動,同4一樣,當小弟