Kafka與Zookeeper

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