zookeeper架構設計與角色分工是什么

這篇文章主要講解了“zookeeper架構設計與角色分工是什么”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“zookeeper架構設計與角色分工是什么”吧！

另外：follower和observer同時均為learner（學習者）角色，learner的分工是同步leader的狀態。

zookeeper的讀寫

??

zookeeper的各個復制集節點（follower，leader，observer）都包含了集群所有的數據且存在內存中，像個內存數據庫。更新操作會以日志的形式記錄到磁盤以保證可恢復性，并且寫入操作會在寫入內存數據庫之前序列化到磁盤。

??每個ZooKeeper服務器都為客戶端服務。客戶端只連接到一臺服務器以提交請求。讀取請求由每個服務器數據庫的本地副本提供服務。更改服務狀態，寫請求的請求由zab協議處理。

??作為協議協議的一部分，來自客戶端的所有寫入請求都被轉發到稱為leader的單個服務器。其余的ZooKeeper服務器（稱為followers）接收來自領導者leader的消息提議并同意消息傳遞。消息傳遞層負責替換失敗的leader并將followers與leader同步。

??ZooKeeper使用自定義原子消息傳遞協議zab。由于消息傳遞層是原子的，當領導者收到寫入請求時，它會計算應用寫入時系統的狀態，并將其轉換為捕獲此新狀態的事務。

zk的CAP原則

??cap原則是指作為一個分布式系統，一致性，可用性，分區容錯性這三個方面，最多只能任意選擇兩種。就是必定會要有取舍。

• 一致性C

??Zookeeper是強一致性系統，同步數據很快。但是在不用sync()操作的前提下無法保證各節點的數據完全一致。zookeeper為了保證一致性使用了基于paxos協議且為zookeeper量身定做的zab協議。這兩個協議是什么東西之后的文章會講。

• 可用性A（高可用性和響應能力）

??Zookeeper數據存儲在內存中，且各個節點都可以相應讀請求，具有好的響應性能。Zookeeper保證了可用性,數據總是可用的,沒有鎖.并且有一大半的節點所擁有的數據是最新的,實時的。

• 分區容忍性P

??有2點需要分析的

1. 節點多了會導致寫數據延時非常大（需要半數以上follower寫完提交）,因為需要多個節點同步.

2. 節點多了Leader選舉非常耗時, 就會放大網絡的問題. 可以通過引入 observer節點緩解這個問題.

zookeeper在CAP問題上做的取舍

嚴格地意義來講zk把取舍這個問題拋給了開發者即用戶。

??為了協調CA（一致性和可用性），用戶可以自己選擇是否使用Sync()操作。使用則保證所有節點強一致，但是這個操作同步數據會有一定的延遲時間。反過來若不是必須保證強一致性的場景，可不使用sync，雖然zookeeper同步的數據很快，但是此時是沒有辦法保證各個節點的數據一定是一致的，這一點用戶要注意。實際的開發中就要開發者根據實際場景來做取舍了，看更關注一致性還是可用性。

??為了協調AP（一致性和擴展性），用戶可以自己選擇是否添加obsever以及添加個數，observer是3.3.0 以后版本新增角色，它不會參加選舉和投票過程，目的就是提高集群擴展性。因為follower的數量不能過多，follower需要參加選舉和投票，過多的話選舉的收斂速度會非常慢，寫數據時的投票過程也會很久。observer的增加可以提高可用性和擴展性，集群可接受client請求的點多了，可用性自然會提高，但是一致性的問題依然存在，這時又回到了上面CA的取舍問題上。

感謝各位的閱讀，以上就是“zookeeper架構設計與角色分工是什么”的內容了，經過本文的學習后，相信大家對zookeeper架構設計與角色分工是什么這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！