首先.在我的文章中已經多次出現過zookeeper了,在我們的Hadoop生態中就存在著zookeeper,在Hbase中zookeeper也扮演著不可或缺的角色,接下來就讓我們來瞭解一下zookeeper吧

在百度釋義中,是這樣說明zookeeper的:zookeeper是一個分散式的，開放源碼的分散式應用程序協調服務，是Google的Chubby一個開源的實現，是Hadoop和Hbase的重要組件。它是一個為分散式應用提供一致性服務的軟體，提供的功能包括：配置維護、域名服務、分散式同步、組服務等。

任何事物的產生都必定存在著他的必然性,那麼zookeeper是怎麼催生出來的呢

隨著互聯網的爆炸式發展,我們的數據也越來越多,以前的太普通對數據的處理方式不再滿足我們的需求,於是開始有了分散式應用,而分散式應用意味著是由多臺設備來共同完成數據的計算,整理,存儲.那麼必然需要一個主控,協調器或者控制器來管理物理分佈的子進程(資源,任務的分配等)

目前大部分應用需要開發私有的協調程序,缺乏一個通用機制,協調程序的反覆編寫造成了浪費,且難以形成通用,伸縮性好的協調器,於是就出現了zookeeper來提供通用的分散式鎖服務

zookeeper工作原理

我們zookeeper要點是攘外必先安內,那麼他又是如何來進行自我協調的呢,由於zookeeper也是分散式的,所以必定存在著分散式所具有的問題,這裡我們要先了解一下Paxos協議

paxos協議

Paxos協議是一種基於消息傳遞的一致性演算法,這個演算法被公認為是類似演算法中最有效的,Paxos 演算法解決的問題是一個分散式系統如何就某個值（決議）達成一致。一個典型的場景是，在一個分散式資料庫系統中，如果各節點的初始狀態一致，每個節點執行相同的操作序列，那麼他們最後能得到一個一致的狀態。為保證每個節點執行相同的命令序列，需要在每一條指令上執行一個「一致性演算法」以保證每個節點看到的指令一致。

  • Paxos演算法通過投票來對寫操作進行全局編號,同一時刻只有一個寫操作被批准
  • 同時並發的寫操作要去爭取選票,只有獲得半數選票的寫操作才會被批准(因此永遠只會有一個寫操作在一個時刻得到批准,一次來保證數據的一致性)
  • 其他的寫操作競爭失敗,只好再發起一次選票,一次反覆,來讓所有的寫操作被嚴格編號排序
  • 編號嚴格遞增,當一個節點接受了一個編號為100的寫操作,之後又接到編號為99的操作(由於網路波動,或機器因素等),它馬上就能意識到自己數據不一致了,自動停止對外服務,並重啟同步過程
  • 任何一個節點掛掉都不會影響整個集羣的數據一致性(總2n+1臺,除非掛掉大於n臺)

再次回到zookeeper工作原理

  • 每個Server在內存中存儲了一份數據
  • Zookeeper啟動時,將從實例中選舉一個leader(Paxos協議,這個選舉一般由兩個因素來決定,文件同步版本號最高(意味著數據更完整)的和機器id最高的)
  • leader負責處理數據更新等操作,其他fllower節點負責接收客戶端的讀寫請求
  • 一個更新操作成功,當且僅當大多數Server在內存中成功修改數據(過半機制,也就是意味著只有當用戶的寫操作更新超過一半的Server中被同步成功,才會返回給客戶端說我們操作成功了,這樣子雖然會降低一定的效率,但是更大的保護了數據的安全性和可靠性)

Zookeeper優點

  • 最終一致性 --為客戶端展示同一個視圖
  • 可靠性 --如果消息被一臺伺服器接受,那麼它將被所有伺服器接受
  • 實時性 --Zookeeper不能保證兩個客戶端能同時得到剛跟新的數據,如果要確保自己得到的是最新的數據,應該在讀數據之前調用sync()介面
  • 獨立性 --各個Client之間互不幹預
  • 原子性 --更新只能成功或者失敗,沒有中間狀態
  • 順序性 --所有Server,統一消息發布順序一致

Zookeeper角色

  • Leader --領導者,負責進行投票的發起和決議,更新系統狀態
  • Fllower --跟隨者,用於接受客戶端請求並向客戶端返回結果,在選舉中參與投票
  • Observer --功能與Fllower一致,但是不參與選舉,只同步leader的狀態,目的是為了擴展系統,提高讀寫速度
  • client --客戶端,發送請求

Observer的存在,是由於如果leader掛掉的話,因為server的數量比較大,通過Paxos演算法,投票選舉,如果server數量較大的話會耗用較大的內存和時間,因此我們來減少一定的投票選舉的人數來確保服務能更加快捷有效

Zab協議

  • Zookeeper的核心是原子廣播,這個機制保證了各個Server之間的同步
  • 實現這個機制的協議叫做Zab協議,算是Paxos演算法的改進版
  • ZAB ( ZooKeeper Atomic Broadcast , ZooKeeper 原子消息廣播協議）是zookeeper數據一致性的核心演算法
  • ZAB 協議並不像 Paxos 演算法那樣，是一種通用的分散式一致性演算法，它是一種特別為 ZooKeeper 設計的崩潰可恢復的原子消息廣播演算法。

Zab協議的兩種模式

  • 恢復模式(選主):當服務啟動或者leader掛掉時,Zab就進入恢復模式,當leader被選舉出來,且過半Server(fllower&observer)完成了對leader的狀態同步,模式就結束了
  • 廣播模式(同步):狀態同步保證了leader和Server(fllower&observer)具有相同的系統狀態

Zookeeper事務的一致性

為了保證事務的順序一致性,zookeeper採用了遞增的事務id(zxid)來標識事務,所有的提議(proposal)都在被提出的時候加上了zxid,zxid是一個64位的數字,他高32位數字是epoch用來標識leader關係是否改變,每次leader被選出來,他都會有一個新的epoch,標識當前屬於哪一個leader的統治時期,低32位用於遞增計數

Zookeeper Server的三種狀態

每個Server在工作過程中有三種狀態:

  • LOOKING:當前Server不知道Laeder是誰,正在搜尋
  • LEADINNG:當前Server即為選舉出來的leader
  • FLLOWING:leader已經選舉出來了,當前Server與之同步

總體來說Zookeeper是一個由多個Server組成的集羣,一個leader多個fllower,每個server中都保存一份數據副本,全局數據一致,分散式讀寫,更新請求轉發由leader實施,Zookeeper更新請求順序執行,來自同一個client的更新請求按其順序依次執行,數據更新原子性,要麼成功要麼失敗,沒有中間狀態,全局數據視圖唯一,client無論請求鏈接的是哪一個server,數據視圖是一致的,在一定事件範圍內,client能讀到最新數--實時性

Zookeeper節點數據操作流

給大家在解析一下這張圖吧,首先客戶端像server發送讀寫請求,server請求leader,提議通過後Fllower向leader中寫入數據,其他fllower則往leader中同步數據,同步過半,則向客戶端返回說操作成功

Zookeeper的數據模型

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

Zookeeper的節點

  • Zookeeper有兩種類型的節點,短暫的(ephemeral)和持久的(persistent)
  • Znode的類型在創建時確定並且之後不能修改
  • 短暫(ephemeral)znode的客戶端會話結束時,zookeeper會將該ephemeral znode刪除,ephemeral znode不可以有子節點
  • persistent znode 不依賴於客戶端會話,只有當客戶端明確要刪除該persistent znode時才會被刪除

Znode有四種形式的目錄節點(默認是persistent)

  • 持久化目錄節點(PERSISTENT) -- 客戶端與zookeeper斷開連接後,該節點依然存在
  • 持久化順序編號目錄節點(PERSISTENT_SEQUENTIAL) -- 客戶端與zookeeper斷開連接後,該節點依然存在,只是zookeeper給該節點名稱進行順序編號
  • 臨時目錄節點(EPHEMERAL) -- 客戶端與zookeeper斷開連接後,該節點被刪除
  • 臨時順序編號目錄節點(EPHEMERAL_SEQUENTIAL)客戶端與zookeeper斷開連接後,該節點被刪除,只是Zookeeper給該節點名稱進行順序編號

Zookeeper的會話

客戶端的Session

  • 客戶端與Server建立TCP連接後得到一個Session
  • 如果鏈接的Server掛掉,沒有超過timeout時間之內,可以連接其他的Server
  • 同一時期內,Session的特性保持不變

Session由Leader產生一個唯一的Session,放到消息隊列內,讓所有的Server知道

Zookeeper總結

  • Zookeeper作為Hadoop項目中的一個子項目,是Hadoop集羣管理的一個必不可少的模塊,他主要用來控制集羣中的數據,如他管理Hadoop集羣中的NameNode,還有Hbase中Master Election , Server之間狀態同步等
  • Zookeeper提供了一套很好的分散式集羣管理機制,就是他這種基於層次型的目錄樹的數據結構,並對樹中的節點進行有效管理,從而可以設計出多種多樣的分散式的數據管理模型

Ending......................

張愛玲的句子還是太沉重了,下次放前期三毛,林徽因的吧....最後祝大家事業有成,生活順利!


推薦閱讀：
相關文章