zookeeper，一個致力於分散式應用程式協調服務的框架。
使用場景包括：
1、配置中心
2、命名服務（RPC的使用場景，Eureka也是個不錯的選擇）
3、通知協調（基於zk的釋出訂閱功能）
4、心跳檢測
5、Master選舉（搶佔式，類似redis的setnx，只能建立一個，建立成功的搶佔成功）
6、鎖
上面很多場景都是基於zk的watcher監聽機制，當監聽的節點發生變更會通知所有監聽該節點的客戶端，而通知則是基於zk的原子廣播（基於Zab協議）。
而ZAB協議有兩種模式：
1、廣播模式，zk大部分時間處於廣播模式。主要處理客戶端請求和leader與Follow之間的狀態同步。
1、恢復模式，當系統啟動或者leader節點down掉或者失去大部分Follow的時候進入恢復模式，進行選主流程。

自動選主
瞭解這個過程，分四個步驟
1、系統角色

2、互動事件（選舉過程中跟隨者節點之間持續發生的事件）
（1）傳送訊息給其他節點
（2）接受其他節點發送過來的資訊
（3）處理其他節點發送過來的資訊

3、訊息內容
（1）myid：來源節點想要推舉的leaderid，和zxid用（myid，zxid表示）
（2）id：來源節點的id（可以等於leaderid，即自己推舉自己當leader）
（3）zxid：來源節點當前資料版本，值越大則資料越新，這是成為leader最重要的條件
（4）epoch：當前選舉輪次標識（邏輯時鐘），值越大則輪次越新，成為leader的首要條件。

4、選主過程
（1）叢集啟動
（2）叢集每個服務節點都沒有資料，資料版本都相等，即為預設值。
（3）此時沒有leader，每個節點都推舉自己當leader，即id=myid，將以上四個資訊廣播給其他所有節點（包括自己）
（4）接受到其他節點發送的資訊的節點，先要判斷來源節點狀體，如果對方處於Looking，且自己處於Following或者leading則直接回復訊息通知來源節點，leading已產生，請儘快同步。如果自己也處於looking狀態，則對來源資訊和自己的資訊進行對比。1.對比epoch，採用值較大者的資訊。2.如果epoch一樣則對比zxid，採用值較大者的資訊。3.如果zxid也一樣，則比較節點id，採用值較大者的資訊。如果採用的是來源節點的資訊，則更新自己的節點資訊，並且廣播給其他節點。否則直接將自己的資訊直接廣播給其他節點。
（5）直到某輪選舉已經選出被絕大多數節點承認的leader，其他節點同步新leader的狀態。