阿里P8架構師談：Zookeeper的原理和架構設計，以及應用場景

隨着信息化水平的不斷提升，企業級應用系統變得愈來愈龐大，性能隨之降低，用戶抱怨頻頻。拆分系統是目前咱們可選擇的解決系統可伸縮性和性能問題的惟一行之有效的方法。可是拆分系統同時也帶來了系統的複雜性——各子系統不是孤立存在的，它們彼此之間須要協做和交互（分佈式系統）。各個子系統就比如動物園裏的動物，爲了使各個子系統能正常爲用戶提供統一的服務，必須須要一種機制來進行協調——這就是ZooKeeper（動物園管理員）。下面詳解：

 

什麼是 Zookeeper

Zookeeper 分佈式服務框架是Apache Hadoop 的一個子項目，它主要是用來解決分佈式應用中常常遇到的一些數據管理問題，如：

1. 統一命名服務
2. 狀態同步服務
3. 集羣管理
4. 分佈式應用配置項的管理等

Zookeeper已經成爲Hadoop生態系統中的基礎組件。

 

Zookeeper的基本原理和架構

 

一、Zookeeper的角色

• 領導者（leader）：負責進行投票的發起和決議，更新系統狀態。
• 學習者（learner）：包括跟隨者（follower）和觀察者（observer），follower用於接受客戶端請求並想客戶端返回結果，在選主過程當中參與投票。
• Observer：能夠接受客戶端鏈接，將寫請求轉發給leader，但observer不參加投票過程，只同步leader的狀態，observer的目的是爲了擴展系統，提升讀取速度
• 客戶端（client）：請求發起方

 

 

• Zookeeper的核心是原子廣播，這個機制保證了各個Server之間的同步。實現這個機制的協議叫作Zab協議。Zab協議有兩種模式，它們分別是恢復模式（選主）和廣播模式（同步）。當服務啓動或者在領導者崩潰後，Zab就進入了恢復模式，當領導者被選舉出來，且大多數Server完成了和leader的狀態同步之後，恢復模式就結束了。狀態同步保證了leader和Server具備相同的系統狀態。

• 爲了保證事務的順序一致性，zookeeper採用了遞增的事務id號（zxid）來標識事務。全部的提議（proposal）都在被提出的時候加上了zxid。實現中zxid是一個64位的數字，它高32位是epoch用來標識leader關係是否改變，每次一個leader被選出來，它都會有一個新的epoch，標識當前屬於那個leader的統治時期。低32位用於遞增計數。

• 每一個Server在工做過程當中有三種狀態：

LOOKING：當前Server不知道leader是誰，正在搜尋

LEADING：當前Server即爲選舉出來的leader

FOLLOWING：leader已經選舉出來，當前Server與之同步

 

二、Zookeeper 的讀寫機制

• Zookeeper是一個由多個server組成的集羣；
• 一個leader，多個follower；
• 每一個server保存一份數據副本；
• 全局數據一致；
• 分佈式讀寫；
• 更新請求轉發，由leader實施。

 

三、Zookeeper 的保證　

• 更新請求順序進行，來自同一個client的更新請求按其發送順序依次執行；
• 數據更新原子性，一次數據更新要麼成功，要麼失敗；
• 全局惟一數據視圖，client不管鏈接到哪一個server，數據視圖都是一致的；
• 實時性，在必定事件範圍內，client能讀到最新數據。

 

四、Zookeeper節點數據操做流程

 

 

• 在Client向Follwer發出一個寫的請求
• Follwer把請求發送給Leader
• Leader接收到之後開始發起投票並通知Follwer進行投票
• Follwer把投票結果發送給Leader
• Leader將結果彙總後若是須要寫入，則開始寫入同時把寫入操做通知給Leader，而後commit;
• Follwer把請求結果返回給Client

 

五、Zookeeper工做原理

Zookeeper的核心是原子廣播，這個機制保證了各個server之間的同步。實現這個機制的協議叫作Zab協議。Zab協議有兩種模式，它們分別是：恢復模式和廣播模式。當服務啓動或者在領導者崩潰後，Zab就進入了恢復模式，當領導者被選舉出來，且大多數server的完成了和leader的狀態同步之後，恢復模式就結束了。

 

六、數據一致性與paxos 算法

• 聽說Paxos算法的難理解與算法的知名度同樣使人敬仰，因此咱們先看如何保持數據的一致性，這裏有個原則就是：

• 在一個分佈式數據庫系統中，若是各節點的初始狀態一致，每一個節點都執行相同的操做序列，那麼他們最後能獲得一個一致的狀態。

• Paxos算法解決的什麼問題呢，解決的就是保證每一個節點執行相同的操做序列。好吧，這還不簡單，master維護一個全局寫隊列，全部寫操做都必須 放入這個隊列編號，那麼不管咱們寫多少個節點，只要寫操做是按編號來的，就能保證一致性。沒錯，就是這樣，但是若是master掛了呢。

• Paxos算法經過投票來對寫操做進行全局編號，同一時刻，只有一個寫操做被批准，同時併發的寫操做要去爭取選票，只有得到過半數選票的寫操做纔會被 批准（因此永遠只會有一個寫操做獲得批准），其餘的寫操做競爭失敗只好再發起一輪投票，就這樣，在日復一日年復一年的投票中，全部寫操做都被嚴格編號排 序。編號嚴格遞增，當一個節點接受了一個編號爲100的寫操做，以後又接受到編號爲99的寫操做（由於網絡延遲等不少不可預見緣由），它立刻能意識到本身 數據不一致了，自動中止對外服務並重啓同步過程。任何一個節點掛掉都不會影響整個集羣的數據一致性（總2n+1臺，除非掛掉大於n臺）。

總結：Zookeeper 做爲 Hadoop 項目中的一個子項目，是 Hadoop 集羣管理的一個必不可少的模塊，它主要用來控制集羣中的數據，如它管理 Hadoop 集羣中的 NameNode，還有 Hbase 中 Master Election、Server 之間狀態同步等。關於Paxos算法能夠查看文章《Zookeeper全解析——Paxos做爲靈魂》，推薦書籍：《從Paxos到Zookeeper分佈式一致性原理與實踐》。

 

七、Observer　

• Zookeeper需保證高可用和強一致性；

• 爲了支持更多的客戶端，須要增長更多Server；

• Server增多，投票階段延遲增大，影響性能；

• 權衡伸縮性和高吞吐率，引入Observer；

• Observer不參與投票；

• Observers接受客戶端的鏈接，並將寫請求轉發給leader節點；

• 加入更多Observer節點，提升伸縮性，同時不影響吞吐率。

 

八、 爲何zookeeper集羣的數目，通常爲奇數個？

•Leader選舉算法採用了Paxos協議；

•Paxos核心思想：當多數Server寫成功，則任務數據寫成功若是有3個Server，則兩個寫成功便可；若是有4或5個Server，則三個寫成功便可；

•Server數目通常爲奇數（三、五、7）若是有3個Server，則最多容許1個Server掛掉；若是有4個Server，則一樣最多容許1個Server掛掉由此，咱們看出3臺服務器和4臺服務器的的容災能力是同樣的，因此爲了節省服務器資源，通常咱們採用奇數個數，做爲服務器部署個數。

 

九、Zookeeper 的數據模型　

• 層次化的目錄結構，命名符合常規文件系統規範；
• 每一個節點在zookeeper中叫作znode,而且其有一個惟一的路徑標識；
• 節點Znode能夠包含數據和子節點，可是EPHEMERAL類型的節點不能有子節點；
• Znode中的數據能夠有多個版本，好比某一個路徑下存有多個數據版本，那麼查詢這個路徑下的數據就須要帶上版本；
• 客戶端應用能夠在節點上設置監視器；
• 節點不支持部分讀寫，而是一次性完整讀寫。

 

十、Zookeeper 的節點

• Znode有兩種類型，短暫的（ephemeral）和持久的（persistent）；
• Znode的類型在建立時肯定而且以後不能再修改；
• 短暫znode的客戶端會話結束時，zookeeper會將該短暫znode刪除，短暫znode不能夠有子節點；
• 持久znode不依賴於客戶端會話，只有當客戶端明確要刪除該持久znode時纔會被刪除；
• Znode有四種形式的目錄節點；
• PERSISTENT（持久的）；
• EPHEMERAL(暫時的)；
• PERSISTENT_SEQUENTIAL（持久化順序編號目錄節點）；
• EPHEMERAL_SEQUENTIAL（暫時化順序編號目錄節點）。

 

Zookeeper的應用場景

1. 配置管理

這個好理解，分佈式系統都有好多機器，好比我在搭建hadoop的HDFS的時候，須要在一個主機器上（Master節點）配置好HDFS須要的各類配置文件，而後經過scp命令把這些配置文件拷貝到其餘節點上，這樣各個機器拿到的配置信息是一致的，才能成功運行起來HDFS服務。

Zookeeper提供了這樣的一種服務：一種集中管理配置的方法，咱們在這個集中的地方修改了配置，全部對這個配置感興趣的均可以得到變動。這樣就省去手動拷貝配置了，還保證了可靠和一致性。

 

 

2. 名字服務

這個能夠簡單理解爲一個電話薄，電話號碼很差記，可是人名好記，要打誰的電話，直接查人名就行了。分佈式環境下，常常須要對應用/服務進行統一命名，便於識別不一樣服務；

• 相似於域名與ip之間對應關係，域名容易記住；
• 經過名稱來獲取資源或服務的地址，提供者等信息。

 

3. 分佈式鎖

碰到分佈二字貌似就難理解了，其實很簡單。單機程序的各個進程須要對互斥資源進行訪問時須要加鎖，那分佈式程序分佈在各個主機上的進程對互斥資源進行訪問時也須要加鎖。不少分佈式系統有多個可服務的窗口，可是在某個時刻只讓一個服務去幹活，當這臺服務出問題的時候鎖釋放，當即fail over到另外的服務。這在不少分佈式系統中都是這麼作，這種設計有一個更好聽的名字叫Leader Election(leader選舉)。舉個通俗點的例子，好比銀行取錢，有多個窗口，可是呢對你來講，只能有一個窗口對你服務，若是正在對你服務的窗口的櫃員忽然有急事走了，那咋辦？找大堂經理（zookeeper）!大堂經理指定另外的一個窗口繼續爲你服務！

 

4. 集羣管理

在分佈式的集羣中，常常會因爲各類緣由，好比硬件故障，軟件故障，網絡問題，有些節點會進進出出。有新的節點加入進來，也有老的節點退出集羣。這個時候，集羣中有些機器（好比Master節點）須要感知到這種變化，而後根據這種變化作出對應的決策。我已經知道HDFS中namenode是經過datanode的心跳機制來實現上述感知的，那麼咱們能夠先假設Zookeeper其實也是實現了相似心跳機制的功能吧！

 

更多高併發架構系列連載，內容包括：java高併發、SOA、分佈式集羣、多線程、Redis、數據庫分庫分表、負載均衡等。以爲不錯請點贊支持，歡迎留言或進個人我的羣179961551領取【架構資料專題目合集90期】、【BATJTMD大廠JAVA面試真題1000+】，本羣專用於學習交流技術、分享面試機會，拒絕廣告，我也會在羣內不按期答題、探討。