壹致性協議方面，註意CP。
首先，Zookeeper集群中有幾個關鍵概念，比如領導者、跟隨者、觀察者。在Zookeeper中，只有領導者節點可以寫，跟隨者和觀察者只負責讀，但是跟隨者會參與節點的選舉，寫壹半就成功，而觀察者不會。他只是提供了讀取數據的功能。
通常這種設置是為了防止過多的從節點參與到半寫的過程中，影響性能。這樣，Zookeeper只需使用幾臺機器組成的小集群就能實現高性能。如果它想橫向擴展，只需要添加觀察點節點。
ZooKeeper建議集群節點的數量是奇數。只要有壹半以上的機器能夠正常提供服務，整個集群都是可用的。
Zookeeper中的數據存儲在內存中，這個數據節點叫做Znode，是壹個樹形結構，比如/a/b/c。
Znode可以分為持久節點、臨時節點和順序節點。
持久節點意味著只要它們被創建，就應該壹直保存在Zookeeper中，除非它們被主動刪除。
臨時節點的不同之處在於，它的生命周期與客戶端會話的生命周期相同。如果會話失敗，臨時節點將被刪除。
還有臨時順序節點和持久順序節點。除了基本特征之外，子節點的名稱也是有序的。
對話自然是指Zookeeper客戶端和服務器之間的通信。他們使用TCP長連接來保持通信。通常要有心跳檢測機制，他可以接受服務器的手表事件通知。
用戶可以在指定的節點上註冊Wather，這樣當事件被觸發時，客戶端就會收到服務器的通知。
Zookeeper使用ACL來控制權限，包括以下五種類型:
創建，創建子節點的權限
刪除，刪除子節點的權限。
讀取，獲得節點數據和子節點列表的權限。
寫入、更新節點權限
管理員，設置節點的ACL權限。
因此，ZooKeeper通過集群實現高可用性，通過內存數據節點Znode實現高性能，但存儲的數據量不能太大，通常適用於讀多寫少的場景。
Zookeeper可以依靠Wather監控機制提供分布式數據的發布/訂閱功能。
客戶端可以向服務器註冊Wather monitoring，當服務器的指定事件被觸發後，會向客戶端發送事件通知。
他有幾個特點:
Zookeeper通過ZAB原子廣播協議實現數據的最終序列壹致性，這是壹個類似於2PC的兩階段提交過程。
由於Zookeeper只有Leader節點寫數據，如果其他節點收到寫數據的請求，會轉發給Leader節點。
主要流程如下:
Leader收到請求後，將其轉換為proposal提議，並為每個提議分配壹個全局唯壹的增量事務ID: zxid，然後將該提議放入壹個FIFO隊列中，根據FIFO策略發送給所有Follower。
Follower將提案以事務日誌的形式寫入本地磁盤，寫入成功後向Leader返回ACK。
領導者收到追隨者超過壹半的ack後，就可以認為數據已經寫入成功，會向追隨者發送commit命令，告訴他們可以提交提案。
ZAB包括兩種基本模式，崩潰恢復和消息廣播。
當整個集群服務啟動，網絡中斷或重啟時，會首先進入崩潰恢復狀態。這時候就要選舉領袖節點了。當群集中超過壹半的節點與Leader狀態同步時，ZAB將退出恢復模式。之後會進入消息廣播模式。
領袖的選舉可以分為兩個方面。同時，選舉主要包括事務zxid和myid，節點主要包括三種狀態。
首先，每個節點為自己投票，然後將投票信息廣播給集群中的其他節點。
節點接收其他節點的投票信息，然後與自己的投票進行比較。首先，較大的zxid優先。如果zxid相同，他們會選擇myid較大的那個。這個時候大家都是在看的狀態。
投票完成後，統計投票信息。如果集群中超過壹半的機器選擇壹個節點機器作為領導者，選舉就結束了。
最後，更新每個節點的狀態，領導者變為領導者狀態，追隨者變為追隨者狀態。
如果選出的領導者節點發生故障，將在運行過程中重新進行領導者的選舉。
領導者下臺後，非觀察者節點會將其狀態更改為LOOKING狀態，然後重新進入選舉過程。
生成投票信息(myid，zxid)。同樣，每個人都會在第壹輪投票中為自己投票，然後廣播投票信息。
接下來的流程和上面的選舉壹樣，會優先選擇zxid，然後選擇myid，最後統計投票信息，修改節點狀態，選舉結束。
還是會存在的，可以分三種場景來描述這個問題。
因為《動物園管理員》成功了壹半，就意味著成功。假設我們有五個節點。如果123節點寫成功，如果此時請求訪問4或5節點，可能無法讀取數據，因為數據可能無法同步到4或5節點，也可以認為是數據不壹致問題。
該解決方案可以在讀取之前使用sync命令。
這也是數據同步的問題。
領導在發送之前剛剛生成了壹個建議。這時候領導下去了，改選後就成了追隨者，但是新領導沒有這個提議。
這種情況下的日誌將被丟棄。
如果建議發送成功，但在提交命令發送之前已關閉，如果再次進行選舉，具有最大zxid的節點仍將被選為領導者。所以這個日誌不會被丟棄，會在選舉出首領後重新同步到其他節點。