大數據之Zookeeper概述

Zookeeper概述

Zookeeper是一個開放源碼的分佈式應用程序協調服務，是 Google的Chubby一個開源的實現，是 Hadoop和 HBASE的重要組件。主要解決分佈式應用一致性問題。

1.分佈式應用

分佈式應用能夠在給定時間（同時）在網絡中的多個系統上運行，經過協調它們以快速有效的方式完成特定任務。一般來講，對於複雜而耗時的任務，非分佈式應用（運行在單個系統中）須要幾個小時才能完成，而分佈式應用經過使用全部系統涉及的計算能力能夠在幾分鐘內完成。

經過將分佈式應用配置爲在更多系統上運行，能夠進一步減小完成任務的時間。分佈式應用正在運行的一組系統稱爲集羣，而在集羣中運行的每臺機器被稱爲節點。

分佈式應用有兩部分， Server（服務器） 和 Client（客戶端） 應用程序。服務器應用程序其實是分佈式的，並具備通用接口，以便客戶端能夠鏈接到集羣中的任何服務器並得到相同的結果。 客戶端應用程序是與分佈式應用進行交互的工具。

 

 

分佈式應用的優勢

• 可靠性 - 單個或幾個系統的故障不會使整個系統出現故障。
• 可擴展性 - 能夠在須要時增長性能，經過添加更多機器，在應用程序配置中進行微小的更改，而不會有停機時間。
• 透明性 - 隱藏系統的複雜性，並將其顯示爲單個實體/應用程序。

分佈式應用的挑戰

• 競爭條件 - 兩個或多個機器嘗試執行特定任務，實際上只需在任意給定時間由單個機器完成。例如，共享資源只能在任意給定時間由單個機器修改。
• 死鎖 - 兩個或多個操做等待彼此無限期完成。
• 不一致 - 數據的部分失敗。

       分佈式應用程序提供了不少好處，但它們也拋出了一些複雜和難以解決的挑戰。ZooKeeper框架提供了一個完整的機制來克服全部的挑戰。

2. Zookeeper簡介

       Zookeeper是一個可以高效開發和維護分佈式的開放源碼的應用協調服務。是Google的 Chubby一個開源的實現，是 Hadoop和 HBASE的重要組件。Zookeeper是一個爲分佈式應用提供一致性服務的軟件，提供的功能包括維護配置信息、名字服務、分佈式同步、組服務等。ZooKeeper框架最初是在「Yahoo!"上構建的，用於以簡單而穩健的方式訪問他們的應用程序。 後來，Apache ZooKeeper成爲Hadoop，HBase和其餘分佈式框架使用的有組織服務的標準。

首先咱們對上一個段落作一個解釋。

1. Zookeeper是一個開放源代碼的軟件。
2. Zookeeper是一個管理「分佈式應用程序」的軟件。什麼是分佈式應用程序服務？咱們知道，Hadoop中的組件，如hdfs、MapReduce/yarn、hbase、double、kafka都是分佈式服務。如MapReduce就是一個分佈式服務，MapReduce會將所作的工做分發給Hadoop集羣中的多臺服務器共同實現。如何對分佈式服務作協調，管理這些運行在不一樣電腦上的任務？就須要一個對分佈式應用程序作協調的服務，這就是Zookeeper的工做。
3. Zookeeper能夠實現對分佈式應用程序作一致性服務，什麼是一致性服務？好比咱們對A服務器上的一個數據進行了修改，這個數據同時在D服務器和M服務器有兩個備份，這時就要對D服務器和M服務器有兩個備份都進行修改，這就是一致性服務。Zookeeper就能夠實現這麼一個一致性服務。
4. Zookeeper實現的強一致性服務。一致性服務分爲3類，分別是：

• 強一致性：a發生變化，b馬上就發生變化
• 弱一致性：a發生變化，b過一會會發生變化
• 最終一致性：a發生變化，b最終也會發生變化     

    Zookeeper能夠實現馬上的數據一致性，即強一致性。

       你們知道，Hadoop生態系統中的組件，都喜歡起動物的名稱。如Hadoop、Hive、Pig等。而Zookeeper中文意思是動物園管理員，就是管理Hadoop生態系統。

　　　5.       ZooKeeper的好處

       如下是使用ZooKeeper的好處：

• 簡單的分佈式協調過程
• 同步 - 服務器進程之間的相互排斥和協做。此過程有助於Apache HBase進行配置管理。
• 有序的消息
• 序列化 - 根據特定規則對數據進行編碼。確保應用程序運行一致。這種方法能夠在MapReduce中用來協調隊列以執行運行的線程。
• 可靠性
• 原子性 - 數據轉移徹底成功或徹底失敗，但沒有事務是部分的。

3 .Zookeeper的選舉機制

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

 

 

配置多個實例共同構成一個Zookeeper集羣對外提供服務以達到水平擴展的目的，集羣中的每一臺電腦都稱爲服務器(Server)，每一個服務器上的數據是相同的，每個服務器都可以對外提供讀和寫的服務，這點和redis是相同的，即對客戶端來說每一個服務器都是平等的。zookeeper集羣通常須要奇數臺服務器，爲何是奇數臺服務器？由於咱們須要經過選舉機制選出領導者(leader)，因此必須是奇數臺服務器。

Zookeeper提供了三種選舉機制：

•  LeaderElection
• AuthFastLeaderElection
• FastLeaderElection

默認的算法是FastLeaderElection，因此這篇主要分析它的選舉機制。

 

客戶端(client)是請求發起方。服務器分爲不一樣的角色，有領導者(leader)，也有學習者(learner)。角色的不一樣是在選舉中產生的，下面是選舉的流程。

目前有5臺服務器，每臺服務器均沒有數據，它們的編號分別是A,B,C,D,E按編號依次啓動，它們的選擇舉過程以下：

• 服務器A啓動，給本身投票，而後發投票信息，因爲其它機器尚未啓動因此它收不到反饋信息，服務器A的狀態一直屬於Looking(選舉狀態)。
• 服務器B啓動，給本身投票，同時與以前啓動的服務器A交換結果，因爲服務器B的編號大因此服務器B勝出，但此時投票數沒有大於半數，因此兩個服務器的狀態依然是Looking(選舉狀態)。
• 服務器C啓動，給本身投票，同時與以前啓動的服務器A,B交換信息，因爲服務器C的編號最大因此服務器C勝出，此時投票數正好大於半數，因此服務器C成爲領導者(Leader)，服務器A,B成爲小弟。
• 服務器D啓動，給本身投票，同時與以前啓動的服務器A,B,C交換信息，儘管服務器D的編號大，但以前服務器C已經勝出，因此服務器D只能成爲小弟。
• 服務器E啓動，後面的邏輯同服務器E成爲小弟。

這裏的小弟就是學習者(learner)。學習者(learner)分爲兩類，可以參與投票的就是跟隨者(follower)，不然就是觀察者(observer)。

服務器有如下狀態。

• LOOKING：競選狀態。
• FOLLOWING：隨從狀態，同步leader狀態，參與投票。
• OBSERVING：觀察狀態，同步leader狀態，不參與投票。
• LEADING：領導者狀態。

下面是選舉的簡易流程圖。

 

 

如下是選舉狀態圖

 

描述Leader選擇過程當中的狀態變化，這是假設所有實例中均沒有數據，假設服務器啓動順序分別爲：A,B,C。

 

角色	描述
服務器(Server)	領導者(Leader)	服務器節點，負責進行投票的發起和決議，更新系統狀態。
學習者(Learner)	跟隨者(Follower)	服務器節點，用於接收客戶端請求並向客戶端返回結果，在選舉過程當中能參與投票。
觀察者(Observer)	當集羣節點數目逐漸增大爲了支持更多的客戶端，須要增長更多Server，然而Server增多，投票階段延遲增大，影響性能。爲了權衡伸縮性和高吞吐率，引入Observer。 服務器節點，能夠接收客戶端鏈接，將寫請求轉發給Leader節點。但Observer不能參與投票，只同步Leader的狀態。Observer的目的是爲了擴展系統，提升讀取速度。
客戶端(Client)	請求發起方

4. Zookeeper的讀寫機制

Zookeeper是分佈式應用程序的協調程序。分佈式應用程序運行在集羣上，客戶端對一臺服務器的請求完成後修改了數據並將數據同步到其餘備份，而且須要將結果告知集羣中全部電腦，這個由分佈式應用程序自身實現嗎？能夠，可是也能夠由另外一個協調程序完成這個功能，Zookeeper就是這麼一個協調程序。下面咱們介紹如下Zookeeper寫流程。下面咱們見下圖。

 

 

 

 

客戶端首先和一個Server或者Observer（能夠認爲是一個Server的代理）通訊，發起寫請求，而後Server將寫請求轉發給Leader，Leader再將寫請求轉發給其餘Server，Server在接收到寫請求後寫入數據並回應Leader，Leader在接收到大多數寫成功迴應後，認爲數據寫成功，迴應Client。

Zookeeper讀取由特定鏈接的Server在內部執行，所以不須要與集羣進行交互。

5. Zookeeper的數據模型

Zookeeper的數據保存在一個相似於文件系統的一個樹形結構中，每一個數據節點只能攜帶少許的數據。爲何只能攜帶少許的數據呢？由於Zookeeper用於進行協調服務的，因此不須要攜帶大量數據。

每一個數據節點（樹中的每個分支節點或者葉子節點）稱之爲znode。每個znode節點既是目錄又是文件（是文件的含義是它能夠帶少許數據，是目錄的含義是它有可能還有子目錄），這和咱們普通看到的文件系統不同。

 

 

每一個目錄在zookeeper中叫作znode,而且其有一個惟一的路徑標識，如/services/myservice/servers/stuidname1

• znode有兩種類型，短暫的(ephemeral: 斷開鏈接本身刪除)和持久的(ersistent: 斷開鏈接不刪除)；
• znode能夠包含數據和子znode(ephemeral類型的節點不能有子znode)；
• znode中的數據能夠有多個版本，好比某一個znode下存有多個數據版本，那麼查詢這個路徑下的數據需帶上版本；

建立znode時設置順序標識，znode名稱後會附加一個值，順序號是一個單調遞增的計數器，由父節點維護 。

如存一個/stu/name值mike，會對路徑上加序列化，如/name000001

再存一個/stu/name值jack，會對路徑上加序列化， 如/name000002

上面的znode就有兩個版本

•   客戶端應用能夠在znode上設置監視器(Watcher)。
•   znode不支持部分讀寫，而是一次性完整讀寫
•   znode的類型在建立時肯定而且以後不能再修改；
•   ephemeral znode的客戶端會話結束時，zookeeper會將該ephemeral znode刪除，ephemeral znode不能夠有子節點；
•   persistent znode不依賴於客戶端會話，只有當客戶端明確要刪除該persistent znode時纔會被刪除；

Zookeeper以節點的方式存儲一些關鍵信息，默認狀況下，全部應用均可以讀寫任何節點，在複雜的應用中，這不太安全，Zookeeper經過ACL(Access Controll List)機制來解決訪問權限問題。

整體來講，Zookeeper的節點有5種ACL(Access Controller List)權限：

•   CREATE 容許建立Child Nodes
•   READ 容許獲取ZNode的數據，以及該節點的孩子列表
•   WRITE 能夠修改ZNode的數據
•   DELETE 能夠刪除一個孩子節點
•   ADMIN 能夠設置權限

這5種權限簡寫爲crwda(即：每一個單詞的首字符縮寫)。注意這5種權限中，delete是指對子節點的刪除權限，其它4種權限指對自身節點的操做權限。

 

6. Zookeeper的監聽機制

Zookeeper的節點是能夠被監控，目錄中存儲數據的修改、子節點目錄的變化，均可以觸發事件並通知監聽的客戶端，這是 Zookeeper重要的特性。經過此特性能夠實現的功能個監聽事件是一個有配置的集中管理、集羣管理、分佈式鎖等。監聽機制官方說明爲次性的監聽器，當被設置了監聽的數據發生變化時，服務器就會將這個改變發送給負責設置 Watch的客戶端。

 ZooKeeper中的Watch是隻能觸發一次。也就是說，若是客戶端在指定的ZNode設置了Watch，若是該ZNode數據發生變動，ZooKeeper會發送一個變動通知給客戶端，同時觸發設置的Watch事件。若是ZNode數據又發生了變動，客戶端在收到第一次通知後沒有從新設置該ZNode的Watch，則ZooKeeper就不會發送一個變動通知給客戶端。

Zookeeper的特色是

• 一次性觸發
•  事件觸發後發給客戶端。
• 數據被設置 Watch