本文開始將爲各位帶來 Zookeeper 方面的知識，由於個人計劃原因，最近這幾天寫的知識點會很雜。但是仍會保證系列文章內的順序性。關注我的公衆號「Java面典」，每天 10：24 和你一起了解更多 Java 相關知識點。
什麼是 Zookeeper
Zookeeper 是一個分佈式協調服務。Zookeeper 提供了一個類似於 Linux 文件系統的樹形結構（可認爲是輕量級的內存文件系統，但只適合存少量信息，完全不適合存儲大量文件或者大文件），同時提供了對於每個節點的監控與通知機制。可用於服務發現，分佈式鎖，分佈式領導選舉，配置管理等。
Zookeeper 角色
Zookeeper 集羣是一個基於主從複製的高可用集羣，每個服務器承擔如下三種角色中的一種：
Leader
- 一個 Zookeeper 集羣同一時間只會有一個實際工作的 Leader，它會發起並維護與各 Follwer 及 Observer 間的心跳；
- 所有的寫操作必須要通過 Leader 完成再由 Leader 將寫操作廣播給其它服務器。只要有超過半數節點（不包括 observeer 節點）寫入成功，該寫請求就會被提交（類 2PC 協議）。
Follower
- 一個 Zookeeper 集羣可能同時存在多個 Follower，它會響應 Leader 的心跳；
- Follower 可直接處理並返回客戶端的讀請求，同時會將寫請求轉發給 Leader 處理；
- 並且負責在 Leader 處理寫請求時對請求進行投票。
Observer
Zookeeper 需保證高可用和強一致性，爲了支持更多的客戶端，需要增加更多 Server；Server 增多，投票階段延遲增大，影響性能，所以引入了 Observer，Observer 不參與投票。
- 角色與 Follower 類似，但是無投票權；
- Observers 接受客戶端的連接，並將寫請求轉發給 leader 節點。
工作原理
- Zookeeper 的核心是原子廣播，這個機制保證了各個 Server 之間的同步。實現這個機制的協議叫做 Zab 協議。Zab 協議有兩種模式，它們分別是恢復模式和廣播模式；
- 當服務啓動或者在 Leader 崩潰後，Zab 就進入了恢復模式，當新的 Leader 被選舉出來，且大多數的 Server 完成了和 Leader 的狀態同步以後，恢復模式就結束了（狀態同步保證了 Leader 和 Server 具有相同的系統狀態）；
- 一旦 Leader 已經和多數的 Follower 進行了狀態同步後，他就可以開始廣播消息了，即進入廣播狀態。這時候當一個 Server 加入 Zookeeper 服務中，它會在恢復模式下啓動，發現 Leader，並和 Leader 進行狀態同步。待到同步結束，它也參與消息廣播。Zookeeper 服務一直維持在 Broadcast 狀態，直到 Leader 崩潰了或者 Leader 失去了大部分的 Follower 支持；
- 廣播模式需要保證 proposal 被按順序處理，因此 Zookeeper 採用了遞增的事務 id 號(zxid)來保證。所有的提議(proposal)都在被提出的時候加上了 zxid；
- 實現中 zxid 是一個 64 爲的數字，它高 32 位是 epoch 用來標識 Leader 關係是否改變，每次一個 Leader 被選出來，它都會有一個新的 epoch。低 32 位是個遞增計數；
- 當 Leader 崩潰或者 Leader 失去大多數的 Follower，這時候 Zookeeper 進入恢復模式，恢復模式需要重新選舉出一個新的 Leader，讓所有的 Server 都恢復到一個正確的狀態。