5分鐘帶你快速瞭解Zookeeper工做原理

一、Zookeeper的角色html

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

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

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

• 每一個Server在工做過程當中有三種狀態:數據庫

LOOKING:當前Server不知道leader是誰,正在搜尋。服務器

LEADING:當前Server即爲選舉出來的leader。網絡

FOLLOWING:leader已經選舉出來,當前Server與之同步。session

其餘文檔:http://www.cnblogs.com/lpshou...併發

二、Zookeeper 的讀寫機制分佈式

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

三、Zookeeper 的保證 oop

  • 更新請求順序進行,來自同一個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做爲靈魂

九、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(暫時化順序編號目錄節點)
相關文章
相關標籤/搜索