定位：zookeeper是一個分佈式協調服務，可以在分佈式系統中共享配置，協調鎖資源，提供命名服務
1、zookeeper的數據模型：（類似數據結構中的樹、文件系統的目錄）
樹是由節點組成，zookeeper的數據存儲也是基於節點，這種節點稱爲Znode，znode的引用方式就是路徑引用。如下所示：
2、znode中都包含了什麼？
data：znode存儲的數據信息
acl：記錄znode的訪問權限，即哪些人或哪些IP可以訪問本節點
stat：包含znode的各種元數據，比如事務ID、版本號、時間戳、大小等等
child：當前節點的子節點引用，類似於二叉樹的左孩子和右孩子
需要注意的是，zookeeper是爲讀多寫少的場景所設計，znode並不是用來保存大規模業務數據的，每個節點的數據最大不能超過1MB.
3、zookeeper的基本操作和事件通知
創建節點：create
刪除節點：delete
判斷節點是否存在：exists
獲得一個節點的數據：getData
設置一個節點的數據：setData
獲取節點下的所有子節點：getChildren
其中讀操作的時候，zookeeper客戶端在請求讀操作的時候，可以選擇是否設置watch。
什麼是watch?
相當於znode上的觸發器，當znode發生改變，就會觸發znode上註冊的對應事件，請求watch的客戶端會接收到異步通知。
如下所示：
1、客戶端調用getData方法，watch參數是true，服務端收到請求，返回節點數據，並且在對應的哈希表裏插入被watch的znode路徑，以及watcher列表：
2、當被watch的znode已刪除，服務端會查找哈希表，找到該znode對應的所有watcher，異步通知客戶端。並且刪除哈希表中對應的key-value。（應該是客戶端連接zk的時候，引入的sdk包中維持了一個長連接？也可能是短連接吧。）
4、zookeeper的一致性
爲了防止zk單機掛掉的情況，zk維護了一個集羣。
zk service集羣是一主多從結構，在更新數據時，首先更新到主節點，然後再同步到從節點。而讀取數據時，直接讀取任意從節點。
如何保證從節點的數據一致性？zk採用了ZAB協議。ZAB(zookeeper atomic broadcast )
5、ZAB協議
zab協議中定義了三種節點狀態。（這裏的節點，應該是指的每臺zk）
Looking：選舉狀態
Following：Follower節點（從節點）所處於的狀態
Leading：Leader節點（主節點）所處狀態。
最大ZXID：節點本地的最新事務編號，包含epoch和計數兩部分。epoch是紀元的意思，相當於raft算法選主時候的term。
假如zk當前的主節點掛掉了，集羣會進行崩潰恢復。zab的崩潰恢復分爲三個階段：
a、leader election
選舉階段，此時集羣中的節點處於looking狀態，會各自向其他節點發起投票，投票當中包含自己的服務器ID和最新事務ID(ZXID)
.
接下來，節點會用自身的ZXID和從其他節點接收到的ZXID比較，如果發現別人的ZXID比自己的大，也就是數據比自己新，那麼就重新發起投票，投票給目前已知最大ZXID所屬節點。
每次投票後，服務器都會統計投票數量，判斷是否有某個節點得到半數以上的投票。如果存在這樣的節點，該節點將會成爲準leader，狀態變爲leading。其他節點的狀態變爲following。
2、Discovery
發現階段。用於在從節點中發現最新的zxid和事務日誌。（雖然leader被選爲了主節點，已經是集羣裏數據最新的了，但是爲了防止某些意外情況，比如因網絡原因在上一階段產生多個leader的情況）
leader需要接收所有follower發來各自的最新epoch值。leader從中選出最大的epoch，基於此值加1，生成新的epoch分發給各個follower。各個follower收到全新的epoch 後，返回ack給leader，帶上各自最大的zxid和歷史事務日誌。leader選出最大的zxid，並更新自身歷史日誌。
3、synchronization
同步階段，把leader剛纔收集得到的最新歷史事務日誌，同步給集羣中所有的follower，只有當半數follower同步成功，這個準leader才能成爲正式的leader。
5、zab如何實現寫入數據的？
上面說到了zk是通過zab協議，實現故障恢復的。那麼zk又是如何實現主從數據的寫入的呢？
寫入數據，涉及到zab協議的broadcast階段。
簡單來說，就是zk常規情況下更新數據的時候，由leader廣播到所有的follower，過程如下：
a、客戶端發出寫入數據請求給任意follower
b、follower把寫入數據請求轉發給leader
c、leader採用二階段提交方式，先發送propose廣播給follower
d、follower接到propose消息，寫入日誌成功後，返回ack消息給leader
e、leader接到半數以上ack消息，返回成功給客戶端，並且廣播commit請求給follower
