Hbase記錄-ZooKeeper介紹

ZooKeeper是一個分佈式協調服務來管理大量的主機。協調和管理在分佈式環境的一個服務是一個複雜的過程。ZooKeeper 簡單解決了其結構和API這個問題。ZooKeeper容許開發人員可以專一於核心應用程序邏輯,而無需擔憂應用程序的分佈式特性。node

ZooKeeper框架始建於「雅虎」,一個簡單而強大的方法用於訪問應用程序。後來 Apache ZooKeeper 成爲用 Hadoop,HBase 的組織服務以及其餘分佈式架構的標準。例如,Apache HBase 使用 ZooKeeper 跟蹤分佈式數據的狀態。數據庫

Apache ZooKeeper是由羣集(組節點)之間進行相互協調,並保持強大的同步技術共享數據的服務。ZooKeeper自己是一個分佈式應用寫入分佈式應用提供服務。安全

ZooKeeper 提供的通用服務以下-服務器

  • 命名服務 − 肯定在一個集羣中的節點的名字。它相似於DNS,只不是過節點。架構

  • 配置管理 − 系統最近加入節點和向上最新配置信息。併發

  • 集羣管理 − 加入/節點的羣集和節點狀態實時離開。app

  • 節點領導者選舉 − 選舉一個節點做爲領導者協調的目的。框架

  • 鎖定和同步服務 − 鎖定數據,同時修改它。這種機制能夠幫助自動故障恢復,同時鏈接其它的分佈式應用程序。如Apache HBase。分佈式

  • 高可靠的數據註冊表 − 一個或幾個節點的可用性的數據向下。oop

分佈式應用程序提供了不少好處,但他們也帶來了一些複雜的,難以破解的挑戰。ZooKeeper框架提供了完整的機制來克服全部挑戰。競爭條件和死鎖使用故障安全同步的方式進行處理。另外一個主要缺點是不一致的數據,ZooKeeper 使用原子性解決。

ZooKeeper的優勢

下面是使用 ZooKeeper 的好處 -

  • 簡單的分佈式協調過程

  • 同步 − 互斥和服務器進程之間的合做。這個過程有助於Apache HBase 的配置管理。

  • 有序消息

  • 序列化− 根據特定的規則進行編碼數據。確保應用程序不斷地運行。這種方法能夠用來在MapReduce的協調隊列以執行正在運行的線程。

  • 可靠性

  • 原子性 − 數據傳輸成功或徹底失敗,但沒有事務處理部分。

ZooKeeper的體系結構

看看下面的圖。它描繪ZooKeeper 的「客戶端 - 服務器架構」。

Architecture of ZooKeeper

ZooKeeper 架構的一部分組件以下表中所解釋。

部分 描述
Client

客戶端,在咱們的分佈式應用集羣的一個節點,從服務器獲取信息。對於一個特定的時間間隔,每一個客戶端將消息發送到服務器,以讓服務器都知道客戶機是活的。

一樣,服務器會發送一個確認當客戶端鏈接。若是沒有從所鏈接的服務器的響應,客戶端自動重定向消息到另外一個服務器

Server 服務器,ZooKeeper集成的一個節點,提供全部的服務提供給客戶。給出應答客戶,告知該服務器還活着
合組 ZooKeeper 服務器組。節點所須要造成的合奏的最小數目爲3
Leader 它執行自動恢復,若是任何鏈接的節點的故障的服務器節點。領導者服務啓動
Follower 遵循領導指示服務器節點

分層命名空間

下圖顯示了用於內存中表示 ZooKeeper 文件系統的樹形結構。 ZooKeeper節點被稱爲znode。每一個znode由一個名稱識別,並經過路徑(/)序列隔開。

  • 在圖中,首先有一個根znode,它由「/」分隔。在根下,有兩個邏輯命名空間 config 和 workers。

  • 在config命名空間用於集中配置管理以及 workers 命名空間用於命名。

  • 在 config 命名空間下,每一個znode能夠存儲高達 1MB 的數據。這相似於UNIX文件系統,不一樣的是父 znode 也能夠存儲數據。這種結構的主要目的是存儲同步數據以及描述znode的元數據。這種結構被稱爲 ZooKeeper數據模型。

Hierarchical Namespace

在 ZooKeeper 數據模型中每一個 znode 維護一個 stat 結構。 一個統計(stat )只是提供了一個 znode 元數據。 它由版本號,動做控制列表(ACL),時間戳和數據長度組成。

  • 版本號 − 每一個znode都有一個版本號,這意味着每一個相關的時間使用節點改變數據,其相應的版本號也將增長。使用版本號是重要的,在多個 zookeeper 的客戶端正在努力經過相同znode執行操做。

  • 動做控制列表(ACL) −ACL是基本的身份驗證機制,用於訪問znode。它管理全部的znode讀寫操做。

  • 時間戳 − 時間戳表示過去時間,從znode建立和修改起算。它一般以毫秒錶示。ZooKeeper 肯定每次從「事務ID」(zxid)更改znodes。Zxid是獨特的,爲每一個事務處理維持時間,使您能夠輕鬆地識別從一個請求到另外一個請求通過的時間。

  • 數據長度 − 存儲在 znode 數據的合計量是數據長度。能夠存儲的最大數據容量爲1MB。

Znodes 類型

Znodes 被歸類爲持久性,順序和短暫。

  • 持久性znode − 持久性 znode 處於活動狀態,即便客戶端,它創造了特定的 znode。默認狀況下,全部的 znodes 是持久的,除非另有說明。

  • 短暫znode − 短暫znodes活躍,直到客戶端還活着。當客戶端被從 ZooKeeper 集合斷開鏈接,而後znodes自動刪除。因爲這個緣由,只有短暫znodes不容許再有一個子。若是短週期znode被刪除,那麼下一個合適的節點,將填補其位置。短暫znodes 發揮在領導選舉中起重要做用。

  • 連續znode − 連續znodes能夠是持久或短暫的。當一個新的znode做爲連續znode建立的,則 ZooKeeper 經過將10位的序列號爲原始名稱設置znode的路徑。例如,若是使用路徑 /myapp 來建立一個znode做爲連續znode,ZooKeeper將改變路徑 /myapp0000000001並設置一個序列號爲0000000002。若是兩個連續znodes同時被建立,ZooKeeper歷來不使用相同數量在每一個znode上。連續znodes在鎖定和同步中起到重要做用。

會話

會話對於 ZooKeeper 操做是很是重要的。請求在會話 FIFO 順序執行。當一個客戶端鏈接到服務器,會話將創建一個會話ID並分配給客戶端。

客戶端在特定的時間間隔發送心跳來保持會話有效。若是 ZooKeeper 從客戶端接收檢測信號超過在服務的開始指定的期間(會話超時),它認爲該客戶死亡。

會話超時一般以毫秒錶示。當一個會話因任何緣由而結束,該會話期間短暫創造了的 znodes 會被刪除。

監視

監視是一個簡單的機制,在ZooKeeper集合通知下以獲取客戶有關的變化。 客戶端能夠設置監視,同時讀取特定znode。監視發送通知給註冊的客戶機對任何znode(在其上的客戶端寄存器)的變化。

節點改變時znode或子znode變化相關聯的數據也會被修改。監視只被觸發一次。若是客戶想要再次通知,則必須經過另外一次讀操做來完成。當一個鏈接會話已過時,客戶端會從服務器斷開,並在相關的監視也將被刪除。

Zookeeper工做流

當ZooKeeper集合啓動時,它會等待客戶端鏈接。客戶端將鏈接到ZooKeeper的集合的其中一個節點。它多是一個領導者或跟隨者節點。當客戶機鏈接時,該節點分配會話ID給特定的客戶端,併發送一個確認消息給客戶端。若是客戶端沒有獲得確認,它會嘗試鏈接ZooKeeper集合的另外一個節點。當鏈接到一個節點後,客戶端將以規則的間隔發送心跳到節點,以確保鏈接不會丟失。

  • 若是客戶想要讀取特定的znode,它發送一個讀請求使用znode路徑的節點,所述節點從其本身的數據庫中獲取它返回所請求的znode。出於這個緣由,讀取在動物園管理員集合中速度很是快。

  • 若是客戶但願將數據存儲在ZooKeeper 集合,它發送znode路徑和數據到服務器。鏈接的服務器將請求轉發到領導者,那麼領導者將從新發出書面請求到全部的追隨者。若是隻有一個數節點成功響應,接着寫請求將成功及一個成功的返回代碼將被髮送到客戶端。不然,寫請求將失敗。嚴格大部分節點被稱爲定額。

ZooKeeper集合的節點

讓咱們來分析ZooKeeper集合不一樣數量的節點的做用。

  • 若是咱們有一個節點,那麼當該節點出現故障時ZooKeeper集合失敗。它有利於「單一失敗教程」,它不建議用在生產環境中。

  • 若是咱們有兩個節點,一個節點出現故障,咱們也沒有「多數」,由於二分之一併非一個大多數。

  • 若是咱們有三個節點及其一個節點發生故障,咱們有大多數,所以它是最低要求。它強制 ZooKeeper 集合在實際生產環境中至少有三個節點。

  • 若是咱們有四個節點及其有當兩個節點失敗,它相似於有三個節點。額外的節點沒有任何做用,所以,最好是單數增長節點,例如,3, 5, 7.

咱們知道,寫處理它比在 ZooKeeper 集合讀過程是昂貴的,因爲全部的節點須要寫相同的數據在其數據庫中。所以,最好是具備節點(3,5或7)比具備大量節點的一個平衡的環境的數量少。

下圖描述了ZooKeeper 的工做流程以及在隨後的表說明了其不一樣的組件。

ZooKeeper Ensemble
組件 描述
寫入 寫過程是由領導節點處理。領導者轉發寫請求到全部znodes及其等待來自znodes應答。若是一半的znodes的回覆,那麼寫入過程就完成了。
讀取 讀取在內部由特定鏈接znode進行的,因此沒有必要與集羣交互。
複製數據庫 它是用來將數據存儲在zookeeper。每一個znode都有本身的數據庫及其每一個znode 在一致性的做用下,每次有相同的數據。
領導者(節點) 領導者是由Znode負責處理寫請求。
追隨者(節點) 追隨者收到來自客戶端的寫請求,並將其轉發到領導znode。
請求處理器 目前僅在領導節點。它從跟隨節點的請求支配寫入。
原子廣播 負責從領導節點到從節點廣播更改。

Zookeeper領導人選舉

讓咱們來分析一下一個領導節點在ZooKeeper集合的選舉。考慮集羣中有N多的節點。領導人選舉的過程以下 −

  • 全部節點建立一個順序,znode具備相同路徑,/app/leader_election/guid_。

  • ZooKeeper 的集合將追加的10位序列號的路徑,創造了 znode 將會是 /app/leader_election/guid_0000000001, /app/leader_election/guid_0000000002, ...等。

  • 對於給定的實例,它在znode建立最小數量的節點成爲領導者以及全部其餘節點的追隨者。

  • 每個追隨者節點監控下一個最小號的znode。

        例如,節點這將建立znode /app/leader_election/guid_0000000008 將監控znode/app/leader_election/guid_0000000007 
        及其該節點建立znode /app/leader_election/guid_0000000007 將監控znode /app/leader_election/guid_0000000006.
  • 若是領導停機,接着其對應的znode/app/leader_electionN被刪除。

  • 跟隨節點接下來將經過觀察者獲得關領導去除的通知。

  • 跟隨節點接下來會檢查是否有其餘znodes用最小數量。 若是沒有,接着它將承擔領導者的角色。不然,它會找到哪些用最小數創造了znode做爲領導者的節點。

  • 一樣,其餘全部跟隨節點選舉創造了znode用最小數做爲領導者的節點。

領導人選舉時,它從頭開始作一個複雜的過程。但ZooKeeper服務,使得它很是簡單。讓咱們在接下來的章節介紹 ZooKeeper 安裝和開發。

Zookeeper CLI

ZooKeeper 命令行界面(CLI)是用來與 ZooKeeper 集成做開發進行交互的。這是在調試和使用不一樣的選項時的工做有用。

爲了執行ZooKeeper的CLI操做, ZooKeeper服務器首先要啓動 (「bin/zkServer.sh start」) , 而後使用 ZooKeeper 客戶端 (「bin/zkCli.sh」). 當客戶端啓動後,能夠執行如下操做 -

  • 建立znodes
  • 獲取數據
  • 監視 znode 變化
  • 設置數據
  • 建立 znode 的子 znode
  • 列出一個 znode 的子 znode
  • 檢查狀態
  • 刪除一個 znode

如今,讓咱們一個個用一個例子地來看上面的命令。

建立Znodes

由一個給定的路徑來建立znode。flag參數指定了建立的 znode 是否爲短暫的,持久的,或連續的。默認狀況下,全部的 znodes是持久的。

  • 短暫 znodes(flag: e)當會話過時或當客戶端斷開鏈接將被自動刪除。

  • 連續 znodes 保證 znode 路徑是惟一的。

  • ZooKeeper集成將沿着添加序列號使用10位填充到znode路徑。例如,znode路徑 /myapp 將被轉換爲 /myapp0000000001 以及下一個序列號將是 /myapp0000000002. 若是沒有指定flag,那麼 znode 是持久的。

語法

create /path /data

示例

create /FirstZnode 「Myfirstzookeeper-app」

輸出結果

[zk: localhost:2181(CONNECTED) 0] create /FirstZnode 「Myfirstzookeeper-app」
Created /FirstZnode

要建立一個連續znode,以下圖所示添加 -s 標誌。

語法

create -s /path /data

示例

create -s /FirstZnode second-data

輸出

[zk: localhost:2181(CONNECTED) 2] create -s /FirstZnode 「second-data」
Created /FirstZnode0000000023

要建立一個臨時Znode,添加-e標誌,以下圖所示。

語法

create -e /path /data

示例

create -e /SecondZnode 「Ephemeral-data」

輸出

[zk: localhost:2181(CONNECTED) 2] create -e /SecondZnode 「Ephemeral-data」
Created /SecondZnode

記住,當丟失一個客戶端鏈接,在臨時 znode 將被刪除。能夠經過退出 ZooKeeper CLI 嘗試,而後從新打開命令行。

獲取數據

它返回 znode 的相關數據和指定 znode 元數據。這裏將獲得信息,例如當數據最後一次修改,在那裏它被修改和有關數據的信息。此外 CLI 還用於分配監視顯示通知有關的數據。

語法

get /path 

示例

get /FirstZnode

輸出

[zk: localhost:2181(CONNECTED) 1] get /FirstZnode
「Myfirstzookeeper-app」
cZxid = 0x7f
ctime = Tue Sep 29 16:15:47 IST 2015
mZxid = 0x7f
mtime = Tue Sep 29 16:15:47 IST 2015
pZxid = 0x7f
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 22
numChildren = 0

要訪問順序znode,必須輸入znode的完整路徑。

示例

get /FirstZnode0000000023

輸出

[zk: localhost:2181(CONNECTED) 1] get /FirstZnode0000000023
「Second-data」
cZxid = 0x80
ctime = Tue Sep 29 16:25:47 IST 2015
mZxid = 0x80
mtime = Tue Sep 29 16:25:47 IST 2015
pZxid = 0x80
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 13
numChildren = 0

監視

監視顯示通知當指定znode或znode的子數據變化。只能在 get 命令中設置監視。

語法

get /path [watch] 1

示例

get /FirstZnode 1

輸出

[zk: localhost:2181(CONNECTED) 1] get /FirstZnode 1
「Myfirstzookeeper-app」
cZxid = 0x7f
ctime = Tue Sep 29 16:15:47 IST 2015
mZxid = 0x7f
mtime = Tue Sep 29 16:15:47 IST 2015
pZxid = 0x7f
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 22
numChildren = 0

輸出相似於正常get命令,但它會在後臺等待節點改變。

設置數據

設置指定znode的數據。當你完成設置操做,就可使用get CLI命令檢查數據。

語法

set /path /data

示例

set /SecondZnode Data-updated

輸出

[zk: localhost:2181(CONNECTED) 1] get /SecondZnode 「Data-updated」
cZxid = 0x82
ctime = Tue Sep 29 16:29:50 IST 2015
mZxid = 0x83
mtime = Tue Sep 29 16:29:50 IST 2015
pZxid = 0x82
cversion = 0
dataVersion = 1
aclVersion = 0
ephemeralOwner = 0x15018b47db00000
dataLength = 14
numChildren = 0

若是分配監視選項在get命令(以前的命令),則輸出將相似以下 -

輸出

[zk: localhost:2181(CONNECTED) 1] get /FirstZnode 「Mysecondzookeeper-app」

WATCHER: :

WatchedEvent state:SyncConnected type:NodeDataChanged path:/FirstZnode
cZxid = 0x7f
ctime = Tue Sep 29 16:15:47 IST 2015
mZxid = 0x84
mtime = Tue Sep 29 17:14:47 IST 2015
pZxid = 0x7f
cversion = 0
dataVersion = 1
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 23
numChildren = 0

建立子znode

建立子znode相似於建立新的znodes。惟一的區別在於,子 znode 的路徑將包含有父路徑。

語法

create /parent/path/subnode/path /data

示例

create /FirstZnode/Child1 firstchildren

輸出

[zk: localhost:2181(CONNECTED) 16] create /FirstZnode/Child1 「firstchildren」
created /FirstZnode/Child1
[zk: localhost:2181(CONNECTED) 17] create /FirstZnode/Child2 「secondchildren」
created /FirstZnode/Child2

列出子znode

該命令用於列出和顯示子 znode 。

語法

ls /path

示例

ls /MyFirstZnode

輸出

[zk: localhost:2181(CONNECTED) 2] ls /MyFirstZnode
[mysecondsubnode, myfirstsubnode]

檢查狀態

狀態描述了指定znode的元數據。它包含詳細信息,如時間戳,版本號,訪問控制列表,數據長度和子znode。

語法

stat /path

示例

stat /FirstZnode

輸出

[zk: localhost:2181(CONNECTED) 1] stat /FirstZnode
cZxid = 0x7f
ctime = Tue Sep 29 16:15:47 IST 2015
mZxid = 0x7f
mtime = Tue Sep 29 17:14:24 IST 2015
pZxid = 0x7f
cversion = 0
dataVersion = 1
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 23
numChildren = 0

刪除Znode

刪除指定znode和遞歸刪除全部的子znode。這隻有在znode可用時發生。

語法

rmr /path

示例

rmr /FirstZnode

輸出

[zk: localhost:2181(CONNECTED) 10] rmr /FirstZnode
[zk: localhost:2181(CONNECTED) 11] get /FirstZnode
Node does not exist: /FirstZnode

刪除(刪除/路徑)命令相似remove命令,但它僅適用於無子znode的znode。

相關文章
相關標籤/搜索