Zookeeper簡介：
ZooKeeper是一個分布式協調服務，可用於服務發現、分布式鎖、分布式領導選舉、配置管理等。
這一切的基礎，都是ZooKeeper提供了一個類似於Linux文件系統的樹形結構（可認為是輕量級的內存文件系統，但只適合存少量信息，完全不適合存儲大量文件或者大文件），同時提供了對於每個節點的監控與通知機制。
既然是一個文件系統，就不得不提ZooKeeper是如何保證數據的一致性的。本節將將介紹ZooKeeper如何保證數據一致性，如何進行領導選舉，以及數據監控/通知機制的語義保證。
Zookeeper中的共識機制是一種改進型的Raft協議。稱為ZAB協議。
Zab 協議分為三大塊：
* 廣播（boardcast）：Zab 協議中，所有的寫請求都由 leader 來處理。正常工作狀態下，leader 接收請求並通過廣播協議來處理。
* 恢復（recovery）：當服務初次啟動，或者 leader 節點掛了，系統就會進入恢復模式，直到選出了有合法數量 follower 的新 leader，然后新 leader 負責將整個系統同步到最新狀態。
* 選舉（Election）：Zab通過消息版本號選舉出Leader來負責所在區域的寫入工作
選舉：
成為 leader 的條件
選epoch最大的
epoch相等，選 zxid 最大的
epoch和zxid都相等，選擇server id最大的（就是我們配置data目錄下的myid）
節點在選舉開始都默認投票給自己，當接收其他節點的選票時，會根據上面的條件更改自己的選票並重新發送選票給其他節點，當有一個節點的得票超過半數，該節點會設置自己的狀態為 leading，其他節點會設置自己的狀態為 following。
恢復：
這一階段 follower 發送它們的 lastZixd 給 leader，leader 根據 lastZixd 決定如何同步數據。這里的實現跟前面 Phase 2 有所不同：Follower 收到 TRUNC 指令會中止 L.lastCommittedZxid 之后的提議，收到 DIFF 指令會接收新的提議。
廣播：
廣播的過程實際上是一個簡化的二階段提交過程：
1. Leader 接收到消息請求后，將消息賦予一個全局唯一的 64 位自增 id，叫做：zxid，通過 zxid 的大小比較即可實現因果有序這一特性。
2. Leader 通過先進先出隊列（通過 TCP 協議來實現，以此實現了全局有序這一特性）將帶有 zxid 的消息作為一個提案（proposal）分發給所有 follower。
3. 當 follower 接收到 proposal，先將 proposal 寫到硬盤，寫硬盤成功后再向 leader 回一個 ACK。
4. 當 leader 接收到合法數量的 ACKs 后，leader 就向所有 follower 發送 COMMIT 命令，同事會在本地執行該消息。
5. 當 follower 收到消息的 COMMIT 命令時，就會執行該消息