zookeeper-架構設計與角色分工-《每日五分鐘搞定大資料》
本篇文章閱讀時間5分鐘左右
ofollow,noindex" target="_blank">點選看《每日五分鐘搞定大資料》完整思維導圖
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點需要分析的
- 節點多了會導致寫資料延時非常大（需要半數以上follower寫完提交）,因為需要多個節點同步.
- 節點多了Leader選舉非常耗時, 就會放大網路的問題. 可以通過引入 observer節點緩解這個問題.
zk在CAP問題上做的取捨
嚴格地意義來講zk把取捨這個問題拋給了開發者即使用者。
為了協調CA（一致性和可用性），使用者可以自己選擇是否使用Sync()操作。使用則保證所有節點強一致，但是這個操作同步資料會有一定的延遲時間。反過來若不是必須保證強一致性的場景，可不使用sync，雖然zookeeper同步的資料很快，但是 此時是沒有辦法保證各個節點的資料一定是一致的 ，這一點使用者要注意。實際的開發中就要開發者根據實際場景來做取捨了，看更關注一致性還是可用性。
為了協調AP（一致性和擴充套件性），使用者可以自己選擇是否新增obsever以及添加個數，observer是3.3.0 以後版本新增角色，它不會參加選舉和投票過程，目的就是提高叢集擴充套件性。因為follower的數量不能過多， follower需要參加選舉和投票，過多的話選舉的收斂速度會非常慢，寫資料時的投票過程也會很久 。observer的增加可以提高可用性和擴充套件性，叢集可接受client請求的點多了，可用性自然會提高，但是一致性的問題依然存在，這時又回到了上面CA的取捨問題上。
作為分散式叢集，系統是如何保證各臺機器間的狀態是一致的？下一篇講下paxos協議和一致性。
評論不能及時回覆可直接加公眾號提問或交流，知無不答，謝謝 。
