1. zookeeper 的一致性，為了防止單機掛掉，zookeeper維護了一個集群，實現自身的高可用
1.1 Zookeeper 集群是一主多從結構
1.2 在更新數據時，首先更新到主節點（這里的節點時指服務器，不是Znode），再同步到從節點。
1.3 再讀取數據時，直接讀取任意從節點
1.4 為了保證主從節點的數據一致性，Zookeeper采用了ZAB協議，這種協議非常類似於一致性算法 Paxos和Raft.
2. 什么是ZAB？
2.1 Zookeeper Automic Broadcast,有效的解決了Zookeeper集群崩潰恢復，以及主從同步數據的問題。
2.2 ZAB協議定義的三種節點狀態
Looking-選舉狀態
Following-從節點
Leader-主節點
2.3 最大ZXID：節點本地的最新事務編碼，包含epoch和計數兩部分。
2.4 ZAB的崩潰恢復
假如Zookeeper 當前的主節點掛掉了，集群會進行崩潰恢復，分三個階段：
2.4.1 Leader election 選舉狀態。此時季軍中的節點處於Looking狀態，向其他節點發起投票，投票當中包含自己的服務器ID和最新的事務ID（ZXID)
接下來，節點會用自身的ZXID和從其他節點接收到的ZXID做比較，如果發現別人家的ZXID比自己的大，也就是數據比自己新，那么久重新發起投票，投票給目前已知最大的ZXID所屬節點。
每次投票后，服務器都會統計投票數量，判斷是否有某個節點但得到半數以上的投票，如果存在這樣的節點，該節點將會成為准Leader，狀態變為Leader,其他系欸但狀態變為Following。
2.4.2 Discover 發現階段，用於從節點中發現最新的ZXID和事務日志，問：既然Leader被選為主節點，已經是集群里最新數據了，為什么還要從節點中尋找最新事務呢？
這是為了防止某些意外情況，比如因網絡原因再上一階段產生多個Leader的情況。
所以該階段。Leader接受所有Follower發來的各自最新的epoch值，Leader從中選出最大的epoch，基於此值加1，生成新的epoch分發給各個Follower。
各個Follower收到全新的epoch后，返回ACK給Leader，帶上各自最大的ZXID和歷史事務日志。Leader選出最大的ZXID，並更新自身歷史日志。
2.4.3 Sysnchronization 同步階段，把Leader 剛才收集得到的最新歷史事務日志，同步給集群中所有的Follower，只有當半數Follower同步成功，這個准Leader才能成為正式的Leader，故障恢復正式完成。
2.5 ZAB數據寫入
2.5.1 Broadcast，Zookeeper常規情況下更新數據的時候，由Leader廣播所有的Follower，其過程如下：
1. 客戶端發出寫入的數據請求給任意Follower
2. Follower把寫入數據請求轉發給Leader
3. Leader采用二階段提交方式，先發送Propose廣播給Follower
4. Follower接收到Propose消息，寫入日志成功后，返回ACK消息給Leader。
5. Leader接到半數以上ACK消息，返回成功給客戶端，並且廣播Commit請求給Follower
