Zookeeper
Zookeeper是一個高性能分布式應用協調服務
》Naming Service
》配置管理
》Leader Election
》服務發現
》同步
》Group Service
》Barrier
》分布式隊列(其實zookeeper並不適合作為分布式隊列，性能不高只不過在特定場合可以)
》兩階段提交
Zookeeper工作方式
》Zookeeper集群包含一個1個Leader，多個Follower
》所有的Follower都可提供讀服務
》所有的寫操作都會被forward到Leader
》Client與Server通過NIO通信
》全局串行化所有的寫操作
》保證同一客戶端的指令被FIFO執行
》保證消息通知的FIFO
與Kafka讀寫操作不一樣，Kafka只有Leader提供讀寫操作。
Zab協議-廣播模式
客戶端每發送一個更新請求，ZooKeeper都會生成一個全局唯一的遞增編號，這個編號反映了所有事務操作的先后順序，這個唯一編號就是事務ID(ZXID)，只有更新請求才算是事務請求。
為保證按照事務的ZXID先后順序來處理，Leader服務器會分別為每個Follower服務器創建一個隊列，並將事務的先后順序放入隊列中，並按照FIFO的策略進行消息發送。收到需要處理的事務后，Follower服務器會首先以事務日志的形式寫入服務器的磁盤中，寫入成功后會向Leader服務器發送ACK響應。當Leader服務器收到超過一半的Follower服務器的ACK響應后，會向所有Follower服務器廣播Commit消息，收到Commit消息的Follower服務器也會完成對事務的提交。
如果接收到事務請求的是Follower服務器，它會將請求轉發給Leader服務器處理。
Zab協議-恢復模式
進入恢復模式：當Leader宕機或者丟失大多數Follower后，即進入恢復模式
結束恢復模式：新領導被選舉出來，且大多數Follower完成了與Leader的狀態同步后，恢復模式即結束，從而進入廣播模式
恢復模式的意義
》發現集群中被commit的proposal的最大zxid
》建立新的epoch，從而保證之前的Leader不能再commit新的proposal
》集群中大部分節點都commit過前一個Leader commit過的信息，而新的Leader是被大部分節點所支持的，所以被之前Leader commit過的Proposal不會丟失，至少被一個節點所保存
》新Leader會與所有Follower通信，從而保證大部分節點都擁有最新的數據
Zookeeper一致性保證
順序一致性：從一個客戶端發出的更新操作會發送順序被順序執行
原子性：更新操作要么成功要么失敗，無中間狀態
單一系統鏡像：一個客戶端只會看到同一個view，無論它連到哪台服務器
可靠性：
》一旦一個更新被應用，該更新將被持久化，直到有客戶端更新該結果
》如果一個客戶端得到更新成功的狀態碼，則該更新一定生效
》任何一個被客戶端通過讀或者更新“看到”的結果，將不會被回滾，即使是從失敗中恢復
實時性：保證客戶端可在一定時間（通常是幾十秒）內看到最新的視圖
Zookeeper使用注意事項
》只保證同一客戶端的單一系統鏡像，並不保證多個不同客戶端在同一時刻一定看到同一系統鏡像，如果要實現這種效果，需要在讀取數據之前調用sync操作
》Zookeeper讀性能好於寫性能，因為任何Server均可提供讀服務，而只有Leader可提供寫服務
》為了保證Zookeeper本身的Leader Election順利進行，通常將Server設置為奇數
》若需容忍f個Server的失敗，必須保證有2f+1個以上的Server