zookeeper 負載均衡 核心機制-實現原理 包含ZAB協議(滴滴，阿里面試)

面試也常常問kafka的原理，以及zookeeper與kafka原理的區別：kafka 數據一致性-leader,follower機制與zookeeper的區別；

zookeeper是如何實現負載均衡的，參考：zookeeper如何實現負載均衡的？（具體鏈接哪個zookeeper服務器的選擇？）阿里面試

Zookeeper是Hadoop下的一個子項目，它是一個針對大型分佈式系統的可靠的協調系統，提供的功能包括命名服務、配置維護、分佈式同步、集羣服務等。

　　Zookeeper是能夠集羣複製的，集羣間經過Zab(Zookeeper Atomic Broadcast)協議來保持數據的一致性。

　　該協議包括2個階段：leader election階段和Atomic broadcast階段。集羣中將選舉出一個leader，其餘的機器則稱爲follower，全部的寫操做都被傳送給leader，並經過broadcast將全部的更新告訴follower。當leader崩潰或者leader失去大多數的follower時，須要從新選舉出一個新的leader，(使用選舉算法，少數服從多數，所以若是有4臺機器，至多隻容許一臺宕機 總2n+1臺，除非掛掉大於n臺)讓全部的服務器都恢復到一個正確的狀態。當leader被選舉出來，且大多數服務器完成了和leader的狀態同步後，leader election的過程就結束了，將進入Atomic broadcast的過程。Actomic broadcast同步leader和follower之間的信息，保證leader和follower具有相同的系統狀態。

 　　Zookeeper集羣的結構圖以下：

 　　　　

 

路由和負載均衡的實現

　　當服務愈來愈多，規模愈來愈大時，對應的機器數量也愈來愈龐大，單靠人工來管理和維護服務及地址的配置信息，已經愈來愈困難。而且，依賴單一的硬件負載均衡設備或者使用LVS、Nginx等軟件方案進行路由和負載均衡調度，單點故障的問題也開始凸顯，一旦服務路由或者負載均衡服務器宕機，依賴其的全部服務均將失效。若是採用雙機高可用的部署方案，使用一臺服務器「stand by」，能部分解決問題，可是鑑於負載均衡設備的昂貴成本，已難以全面推廣。

　　一旦服務器與ZooKeeper集羣斷開鏈接，節點也就不存在了，經過註冊相應的watcher，服務消費者可以第一時間獲知服務提供者機器信息的變動。利用其znode的特色和watcher機制，將其做爲動態註冊和獲取服務信息的配置中心，統一管理服務名稱和其對應的服務器列表信息，咱們可以近乎實時地感知到後端服務器的狀態(上線、下線、宕機)。Zookeeper集羣間經過Zab協議，服務配置信息可以保持一致，而Zookeeper自己容錯特性和leader選舉機制，能保證咱們方便地進行擴容。

　　Zookeeper中，服務提供者在啓動時，將其提供的服務名稱、服務器地址、以節點的形式註冊到服務配置中心，服務消費者經過服務配置中心來得到須要調用的服務名稱節點下的機器列表節點。經過前面所介紹的負載均衡算法，選取其中一臺服務器進行調用。當服務器宕機或者下線時，因爲znode非持久的特性，相應的機器能夠動態地從服務配置中內心面移除，並觸發服務消費者的watcher。在這個過程當中，服務消費者只有在第一次調用服務時須要查詢服務配置中心，而後將查詢到的服務信息緩存到本地，後面的調用直接使用本地緩存的服務地址列表信息，而不須要從新發起請求到服務配置中心去獲取相應的服務地址列表，直到服務的地址列表有變動(機器上線或者下線)，變動行爲會觸發服務消費者註冊的相應的watcher進行服務地址的從新查詢。這種無中心化的結構，使得服務消費者在服務信息沒有變動時，幾乎不依賴配置中心，解決了以前負載均衡設備所致使的單點故障的問題，而且大大下降了服務配置中心的壓力。

 　　經過Zookeeper來實現服務動態註冊、機器上線與下線的動態感知，擴容方便，容錯性好，且無中心化結構可以解決以前使用負載均衡設備所帶來的單點故障問題。只有當配置信息更新時服務消費者纔會去Zookeeper上獲取最新的服務地址列表，其餘時候使用本地緩存便可，這樣服務消費者在服務信息沒有變動時，幾乎不依賴配置中心，能大大下降配置中心的壓力。

 若是想了解其餘的Web負載均衡的原理參考：六大Web負載均衡原理與實現

LVS的負載均衡就是上面6個負載均衡中的3個，參考：LVS(Linus Virtual Server)：三種負載均衡方式比較+另三種負載均衡方式

 

 

 

一、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與之同步

　　其餘文檔：http://www.cnblogs.com/lpshou/archive/2013/06/14/3136738.html

二、Zookeeper 的讀寫機制

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

三、Zookeeper 的保證　

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

四、Zookeeper節點數據操做流程

　　　　　　　

　　　　注：1.在Client向Follwer發出一個寫的請求

　　　　　　2.Follwer把請求發送給Leader

　　　　　　3.Leader接收到之後開始發起投票並通知Follwer進行投票

　　　　　　4.Follwer把投票結果發送給Leader

　　　　　　5.Leader將結果彙總後若是須要寫入，則開始寫入同時把寫入操做通知給Leader，而後commit;

　　　　　　6.Follwer把請求結果返回給Client

　　　　　　

　　　　• Follower主要有四個功能：
　　　　• 1. 向Leader發送請求（PING消息、REQUEST消息、ACK消息、REVALIDATE消息）；
　　　　• 2 .接收Leader消息並進行處理；
　　　　• 3 .接收Client的請求，若是爲寫請求，發送給Leader進行投票；
　　　　• 4 .返回Client結果。
　　　　• Follower的消息循環處理以下幾種來自Leader的消息：
　　　　• 1 .PING消息： 心跳消息；
　　　　• 2 .PROPOSAL消息：Leader發起的提案，要求Follower投票；
　　　　• 3 .COMMIT消息：服務器端最新一次提案的信息；
　　　　• 4 .UPTODATE消息：代表同步完成；
　　　　• 5 .REVALIDATE消息：根據Leader的REVALIDATE結果，關閉待revalidate的session仍是容許其接受消息；
　　　　• 6 .SYNC消息：返回SYNC結果到客戶端，這個消息最初由客戶端發起，用來強制獲得最新的更新。

五、Zookeeper leader 選舉　　

　　• 半數經過
　　　　– 3臺機器 掛一臺 2>3/2
　　　　– 4臺機器 掛2臺 2！>4/2

　　

　　• A提案說，我要選本身，B你贊成嗎？C你贊成嗎？B說，我贊成選A；C說，我贊成選A。(注意，這裏超過半數了，其實在現實世界選舉已經成功了。

　　　可是計算機世界是很嚴格，另外要理解算法，要繼續模擬下去。)
　　• 接着B提案說，我要選本身，A你贊成嗎；A說，我已經超半數贊成當選，你的提案無效；C說，A已經超半數贊成當選，B提案無效。
　　• 接着C提案說，我要選本身，A你贊成嗎；A說，我已經超半數贊成當選，你的提案無效；B說，A已經超半數贊成當選，C的提案無效。
　　• 選舉已經產生了Leader，後面的都是follower，只能服從Leader的命令。並且這裏還有個小細節，就是其實誰先啓動誰當頭。

　　

　　

六、zxid

　　• znode節點的狀態信息中包含czxid, 那麼什麼是zxid呢?
　　• ZooKeeper狀態的每一次改變, 都對應着一個遞增的Transaction id, 該id稱爲zxid. 因爲zxid的遞增性質, 若是zxid1小於zxid2, 那麼zxid1確定先於zxid2發生.

　　　建立任意節點, 或者更新任意節點的數據, 或者刪除任意節點, 都會致使Zookeeper狀態發生改變, 從而致使zxid的值增長.

七、Zookeeper工做原理

　　» Zookeeper的核心是原子廣播，這個機制保證了各個server之間的同步。實現這個機制的協議叫作Zab協議。Zab協議有兩種模式，它們分別是恢復模式和廣播模式。

　　　當服務啓動或者在領導者崩潰後，Zab就進入了恢復模式，當領導者被選舉出來，且大多數server的完成了和leader的狀態同步之後，恢復模式就結束了。

　　　狀態同步保證了leader和server具備相同的系統狀態

　　» 一旦leader已經和多數的follower進行了狀態同步後，他就能夠開始廣播消息了，即進入廣播狀態。這時候當一個server加入zookeeper服務中，它會在恢復模式下啓動，

　　　發現leader，並和leader進行狀態同步。待到同步結束，它也參與消息廣播。Zookeeper服務一直維持在Broadcast狀態，直到leader崩潰了或者leader失去了大部分

　　　的followers支持。

　　» 廣播模式須要保證proposal被按順序處理，所以zk採用了遞增的事務id號(zxid)來保證。全部的提議(proposal)都在被提出的時候加上了zxid。

　　　實現中zxid是一個64爲的數字，它高32位是epoch用來標識leader關係是否改變，每次一個leader被選出來，它都會有一個新的epoch。低32位是個遞增計數。

　　» 當leader崩潰或者leader失去大多數的follower，這時候zk進入恢復模式，恢復模式須要從新選舉出一個新的leader，讓全部的server都恢復到一個正確的狀態。　

　　» 每一個Server啓動之後都詢問其它的Server它要投票給誰。
　　» 對於其餘server的詢問，server每次根據本身的狀態都回複本身推薦的leader的id和上一次處理事務的zxid（系統啓動時每一個server都會推薦本身）
　　» 收到全部Server回覆之後，就計算出zxid最大的哪一個Server，並將這個Server相關信息設置成下一次要投票的Server。
　　» 計算這過程當中得到票數最多的的sever爲獲勝者，若是獲勝者的票數超過半數，則改server被選爲leader。不然，繼續這個過程，直到leader被選舉出來　　

　　» leader就會開始等待server鏈接
　　» Follower鏈接leader，將最大的zxid發送給leader
　　» Leader根據follower的zxid肯定同步點
　　» 完成同步後通知follower 已經成爲uptodate狀態
　　» Follower收到uptodate消息後，又能夠從新接受client的請求進行服務了

八、數據一致性與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 三、Zookeeper工做原理（詳細）