zookeeper-架構設計與角色分工-《每日五分鐘搞定大數據》

本篇文章閱讀時間5分鐘左右

點擊看《每日五分鐘搞定大數據》完整思惟導圖

  zookeeper做爲一個分佈式協調系統，不少組件都會依賴它，那麼此時它的可用性就很是重要了，那麼保證可用性的同時做爲分佈式系統的它是怎麼保證擴展性的？問題不少，讀完接下來的內容你會有答案。

  上圖來自zookeeper的官方文檔，我解釋下這張圖的各個角色（observer在上圖中能夠理解爲特殊的follower）

角色	分工	數量
client客戶端	請求發起方	不限
observer觀察者	接受用戶讀寫請求，寫轉發給leader，讀直接返回（選主過程不參加投票）	不限
follower跟隨者	接受用戶讀寫請求，寫轉發給leader，讀直接返回（選主過程參加投票）	奇數個（不可過多）
leader領導者	負責提議，更新系統狀態	1個

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

zk的讀寫

  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節點緩解這個問題.

zk在CAP問題上作的取捨

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

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

  爲了協調AP（一致性和擴展性），用戶能夠本身選擇是否添加obsever以及添加個數，observer是3.3.0 之後版本新增角色，它不會參加選舉和投票過程，目的就是提升集羣擴展性。由於follower的數量不能過多，follower須要參加選舉和投票，過多的話選舉的收斂速度會很是慢，寫數據時的投票過程也會好久。observer的增長能夠提升可用性和擴展性，集羣可接受client請求的點多了，可用性天然會提升，可是一致性的問題依然存在，這時又回到了上面CA的取捨問題上。

  做爲分佈式集羣，系統是如何保證各臺機器間的狀態是一致的？下一篇講下paxos協議和一致性。

推薦閱讀：

zookeeper-操做與應用場景

評論不能及時回覆可直接加公衆號提問或交流，知無不答，謝謝 。