16120九、簡要分析ZooKeeper基本原理及安裝部署

時間 2019-11-17

標籤簡要分析 zookeeper 基本原理安裝部署欄目 Zookeeper 简体版

原文原文鏈接

1、ZooKeeper 基本概念

一、ZooKeeper 是什麼？html

Zookeeper官網地址： http://zookeeper.apache.org/node

Zookeeper官網文檔地址：http://zookeeper.apache.org/doc/trunk/index.html算法

ZooKeeper 是Hadoop下的一個子項目，它是一個針對大型分佈式系統的可靠協調系統；它提供的功能包括：配置維護、名字服務、分佈式同步、組服務等；它的目標就是封裝好複雜易出錯的關鍵服務，將簡單易用的接口和性能高效、功能穩定的系統提供給用戶。數據庫

Zookeeper一個最經常使用的使用場景就是用於擔任服務生產者和服務消費者的註冊中心，服務生產者將本身提供的服務註冊到Zookeeper中心，服務的消費者在進行服務調用的時候先到Zookeeper中查找服務，獲取到服務生產者的詳細信息以後，再去調用服務生產者的內容與數據，簡單示例圖以下：apache

二、ZooKeeper設計目標：性能優化

ZooKeeper容許分佈式進程經過共享的層次結構命名空間進行相互協調，這與標準文件系統相似。名稱空間由ZooKeeper中的數據寄存器組成 - 稱爲znode，這些相似於文件和目錄。與爲存儲設計的典型文件系統不一樣，ZooKeeper數據保存在內存中，這意味着ZooKeeper能夠實現高吞吐量和低延遲。服務器

Zookeeper層次結構命名空間示意圖以下：架構

經過這種樹圖結構的數據模型，很容易的查找到具體的某一個服務。分佈式

三、ZooKeeper主要特色：oop

1)、最終一致性：爲客戶端展現同一視圖，這是 ZooKeeper 最重要的性能。

2)、可靠性：若是消息被一臺服務器接受，那麼它將被全部的服務器接受。

3)、實時性：ZooKeeper 不能保證兩個客戶端同時獲得剛更新的數據，若是須要最新數據，應該在讀數據以前調用sync()接口。

4)、等待無關（wait-free）：慢的或者失效的 client 不干預快速的client的請求。

5)、原子性：更新只能成功或者失敗，沒有中間其它狀態。

6)、順序性：對於全部Server，同一消息發佈順序一致。

2、ZooKeeper 基本原理

一、ZooKeeper 系統架構

首先看一下 ZooKeeper 的架構圖。

ZooKeeper 的架構圖中咱們須要瞭解和掌握的主要有：

（1）ZooKeeper分爲服務器端（Server）和客戶端（Client），客戶端能夠鏈接到整個 ZooKeeper服務的任意服務器上（除非 leaderServes 參數被顯式設置， leader 不容許接受客戶端鏈接）。

（2）客戶端使用並維護一個 TCP 鏈接，經過這個鏈接發送請求、接受響應、獲取觀察的事件以及發送心跳。若是這個 TCP 鏈接中斷，客戶端將自動嘗試鏈接到另外的 ZooKeeper服務器。客戶端第一次鏈接到 ZooKeeper服務時，接受這個鏈接的 ZooKeeper服務器會爲這個客戶端創建一個會話。當這個客戶端鏈接到另外的服務器時，這個會話會被新的服務器從新創建。

（3）上圖中每個Server表明一個安裝Zookeeper服務的機器，便是整個提供Zookeeper服務的集羣（或者是由僞集羣組成）；

（4）組成ZooKeeper服務的服務器必須彼此瞭解。它們維護一個內存中的狀態圖像，以及持久存儲中的事務日誌和快照，只要大多數服務器可用，ZooKeeper服務就可用；

（5）ZooKeeper 啓動時，將從實例中選舉一個 leader，Leader 負責處理數據更新等操做，一個更新操做成功的標誌是當且僅當大多數Server在內存中成功修改數據。每一個Server 在內存中存儲了一份數據。

（6）Zookeeper是能夠集羣複製的，集羣間經過Zab協議（Zookeeper Atomic Broadcast）來保持數據的一致性；

（7）Zab協議包含兩個階段：leader election階段和Atomic Brodcast階段。

a) 集羣中將選舉出一個leader，其餘的機器則稱爲follower，全部的寫操做都被傳送給leader，並經過brodcast將全部的更新告訴給follower。

b) 當leader崩潰或者leader失去大多數的follower時，須要從新選舉出一個新的leader，讓全部的服務器都恢復到一個正確的狀態。

c) 當leader被選舉出來，且大多數服務器完成了和leader的狀態同步後，leadder election 的過程就結束了，就將會進入到Atomic brodcast的過程。

d) Atomic Brodcast同步leader和follower之間的信息，保證leader和follower具備形同的系統狀態。

二、Zookeeper 角色

啓動 Zookeeper 服務器集羣環境後，多個 Zookeeper 服務器在工做前會選舉出一個 Leader。選舉出 leader 前，全部 server 不區分角色，都須要平等參與投票（ obServer 除外，不參與投票）；

選主過程完成後，存在如下幾種角色：

思考：

一、爲何須要server?

①ZooKeeper 需保證高可用和強一致性;

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

③Follower增多會致使投票階段延遲增大，影響性能。 123123

２、在Zookeeper 中ObServer 起到什麼做用？

①ObServer 不參與投票過程，只同步 leader的狀態 ;

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

③加入更多ObServer 節點，提升伸縮性，同時還不影響吞吐率。123123

３、爲何在Zookeeper中Server 數目通常爲奇數？

咱們知道在Zookeeper中 Leader 選舉算法採用了Zab協議。Zab核心思想是當多數 Server 寫成功，則任務數據寫成功。

①若是有3個Server，則最多容許1個Server 掛掉。

②若是有4個Server，則一樣最多容許1個Server掛掉。

既然3個或者4個Server，一樣最多容許1個Server掛掉，那麼它們的可靠性是同樣的，因此選擇奇數個ZooKeeper Server便可，這裏選擇3個Server。

三、ZooKeeper 寫數據流程

ZooKeeper 寫數據的流程圖以下所示。

ZooKeeper 的寫數據流程主要分爲如下幾步：

a)、好比 Client 向 ZooKeeper 的 Server1 上寫數據，發送一個寫請求。

b)、若是Server1不是Leader，那麼Server1 會把接受到的請求進一步轉發給Leader，由於每一個ZooKeeper的Server裏面有一個是Leader。這個Leader 會將寫請求廣播給各個Server，好比Server1和Server2，各個Server寫成功後就會通知Leader。

c)、當Leader收到大多數 Server 數據寫成功了，那麼就說明數據寫成功了。若是這裏三個節點的話，只要有兩個節點數據寫成功了，那麼就認爲數據寫成功了。寫成功以後，Leader會告訴Server1數據寫成功了。

d)、Server1會進一步通知 Client 數據寫成功了，這時就認爲整個寫操做成功。

四、ZooKeeper 組件

ZooKeeper組件顯示了ZooKeeper服務的高級組件。除了請求處理器，組成ZooKeeper服務的每一個服務器複製其本身的每一個組件的副本。

Replicated Database是包含整個數據樹的內存數據庫。更新操做會記錄到磁盤裏以進行可恢復性，而且寫操做將在放到內存數據庫以前序列化到磁盤。

每一個ZooKeeper服務器服務客戶端。客戶端鏈接到一個服務器以提交irequest。讀取請求從每一個服務器數據庫的本地副本服務。更改服務狀態（寫入請求）的請求由協議進行處理。

做爲協議協議的一部分，來自客戶端的全部寫請求被轉發到單個服務器，稱爲leader。其他的ZooKeeper服務器（稱爲followers）從領導者接收消息提議並贊成消息傳遞。消息層負責在失敗時替換領導者，並與leader同步followers。

3、ZooKeeper 應用場景總結

一、統一命名服務

統一命名服務的命名結構圖以下所示：

一、在分佈式環境下，常常須要對應用/服務進行統一命名，便於識別不一樣服務。

a）相似於域名與ip之間對應關係，ip不容易記住，而域名容易記住。

b）經過名稱來獲取資源或服務的地址，提供者等信息。

二、按照層次結構組織服務/應用名稱。

a）可將服務名稱以及地址信息寫到ZooKeeper上，客戶端經過ZooKeeper獲取可用服務列表類。

二、配置管理

配置管理結構圖以下所示：

一、分佈式環境下，配置文件管理和同步是一個常見問題。

a）一個集羣中，全部節點的配置信息是一致的，好比 Hadoop 集羣。

b）對配置文件修改後，但願可以快速同步到各個節點上。

二、配置管理可交由ZooKeeper實現。

a）可將配置信息寫入ZooKeeper上的一個Znode。

b）各個節點監聽這個Znode。

c）一旦Znode中的數據被修改，ZooKeeper將通知各個節點。

三、集羣管理

集羣管理結構圖以下所示：

一、分佈式環境中，實時掌握每一個節點的狀態是必要的。

a）可根據節點實時狀態作出一些調整。

二、可交由ZooKeeper實現。

a）可將節點信息寫入ZooKeeper上的一個Znode。

b）監聽這個Znode可獲取它的實時狀態變化。

三、典型應用

a）Hbase中Master狀態監控與選舉。

四、分佈式通知與協調

一、分佈式環境中，常常存在一個服務須要知道它所管理的子服務的狀態。

a）NameNode需知道各個Datanode的狀態。

b）JobTracker需知道各個TaskTracker的狀態。

二、心跳檢測機制可經過ZooKeeper來實現。

三、信息推送可由ZooKeeper來實現，ZooKeeper至關於一個發佈/訂閱系統。

五、分佈式鎖

處於不一樣節點上不一樣的服務，它們可能須要順序的訪問一些資源，這裏須要一把分佈式的鎖。

分佈式鎖具備如下特性：

一、ZooKeeper是強一致的。好比各個節點上運行一個ZooKeeper客戶端，它們同時建立相同的Znode，可是隻有一個客戶端建立成功。

二、實現鎖的獨佔性。建立Znode成功的那個客戶端才能獲得鎖，其它客戶端只能等待。當前客戶端用完這個鎖後，會刪除這個Znode，其它客戶端再嘗試建立Znode，獲取分佈式鎖。

三、控制鎖的時序。各個客戶端在某個Znode下建立臨時Znode，這個類型必須爲CreateMode.EPHEMERAL_SEQUENTIAL，這樣該Znode可掌握全局訪問時序。

六、分佈式隊列

分佈式隊列分爲兩種：

一、當一個隊列的成員都聚齊時，這個隊列纔可用，不然一直等待全部成員到達，這種是同步隊列。

a）一個job由多個task組成，只有全部任務完成後，job才運行完成。

b）可爲job建立一個/job目錄，而後在該目錄下，爲每一個完成的task建立一個臨時的Znode，一旦臨時節點數目達到task總數，則代表job運行完成。

二、隊列按照FIFO方式進行入隊和出隊操做，例如實現生產者和消費者模型。