zookeeper是什麼

  轉載：https://blog.csdn.net/zhangzq86/article/details/80981234

官方說辭：Zookeeper 分佈式服務框架是Apache Hadoop 的一個子項目，它主要是用來解決分佈式應用中常常遇到的一些數據管理問題，如：統一命名服務、狀態同步服務、集羣管理、分佈式應用配置項的管理等。

好抽象，咱們改變一下方式，先看看它都提供了哪些功能，而後再看看使用它的這些功能能作點什麼。

ZooKeeper是用於維護配置信息，命名，提供分佈式同步和提供組服務的集中式服務。全部這些類型的服務都以某種形式或由分佈式應用程序使用。每次實施它們時，都會進行不少工做來修復不可避免的錯誤和競爭條件。因爲難以實現這類服務，所以應用程序一般最初會在其上跳過，從而使它們在存在更改的狀況下變得脆弱而且難以管理。即便部署正確，這些服務的不一樣實現也會致使管理複雜。

 

官網文檔：https://zookeeper.apache.org/doc/current/javaExample.html

 

zookeeper提供了什麼

 

簡單的說，zookeeper=文件系統+通知機制。

一、 文件系統

Zookeeper維護一個相似文件系統的數據結構：

 

 

 

        每一個子目錄項如 NameService 都被稱做爲 znode，和文件系統同樣，咱們可以自由的增長、刪除znode，在一個znode下增長、刪除子znode，惟一的不一樣在於znode是能夠存儲數據的。

有四種類型的znode：

一、PERSISTENT-持久化目錄節點

客戶端與zookeeper斷開鏈接後，該節點依舊存在

二、 PERSISTENT_SEQUENTIAL-持久化順序編號目錄節點

客戶端與zookeeper斷開鏈接後，該節點依舊存在，只是Zookeeper給該節點名稱進行順序編號

三、EPHEMERAL-臨時目錄節點

客戶端與zookeeper斷開鏈接後，該節點被刪除

四、EPHEMERAL_SEQUENTIAL-臨時順序編號目錄節點

客戶端與zookeeper斷開鏈接後，該節點被刪除，只是Zookeeper給該節點名稱進行順序編號

 

二、 通知機制

        客戶端註冊監聽它關心的目錄節點，當目錄節點發生變化（數據改變、被刪除、子目錄節點增長刪除）時，zookeeper會通知客戶端。 

就這麼簡單，下面咱們看看能作點什麼呢？

 

 

咱們能用zookeeper作什麼

一、 命名服務

        這個彷佛最簡單，在zookeeper的文件系統裏建立一個目錄，即有惟一的path。在咱們使用tborg沒法肯定上游程序的部署機器時便可與下游程序約定好path，經過path即能互相探索發現，不見不散了。

 

二、 配置管理

        程序老是須要配置的，若是程序分散部署在多臺機器上，要逐個改變配置就變得困難。好吧，如今把這些配置所有放到zookeeper上去，保存在 Zookeeper 的某個目錄節點中，而後全部相關應用程序對這個目錄節點進行監聽，一旦配置信息發生變化，每一個應用程序就會收到 Zookeeper 的通知，而後從 Zookeeper 獲取新的配置信息應用到系統中就好。

                                         

 

三、 集羣管理

所謂集羣管理無在意兩點：是否有機器退出和加入、選舉master。

        對於第一點，全部機器約定在父目錄GroupMembers下建立臨時目錄節點，而後監聽父目錄節點的子節點變化消息。一旦有機器掛掉，該機器與 zookeeper的鏈接斷開，其所建立的臨時目錄節點被刪除，全部其餘機器都收到通知：某個兄弟目錄被刪除，因而，全部人都知道：它上船了。新機器加入 也是相似，全部機器收到通知：新兄弟目錄加入，highcount又有了。

        對於第二點，咱們稍微改變一下，全部機器建立臨時順序編號目錄節點，每次選取編號最小的機器做爲master就好。

                                 

 

四、  分佈式鎖

        有了zookeeper的一致性文件系統，鎖的問題變得容易。鎖服務能夠分爲兩類，一個是保持獨佔，另外一個是控制時序。

        對於第一類，咱們將zookeeper上的一個znode看做是一把鎖，經過createznode的方式來實現。全部客戶端都去建立 /distribute_lock 節點，最終成功建立的那個客戶端也即擁有了這把鎖。廁全部言：來也沖沖，去也沖沖，用完刪除掉本身建立的distribute_lock 節點就釋放出鎖。

        對於第二類， /distribute_lock 已經預先存在，全部客戶端在它下面建立臨時順序編號目錄節點，和選master同樣，編號最小的得到鎖，用完刪除，依次方便。

                                         

五、隊列管理

兩種類型的隊列：

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

二、隊列按照 FIFO 方式進行入隊和出隊操做。

第一類，在約定目錄下建立臨時目錄節點，監聽節點數目是不是咱們要求的數目。

第二類，和分佈式鎖服務中的控制時序場景基本原理一致，入列有編號，出列按編號。                 

         終於瞭解完咱們能用zookeeper作什麼了，但是做爲一個程序員，咱們老是想狂熱瞭解zookeeper是如何作到這一點的，單點維護一個文件系統沒有什麼難度，但是若是是一個集羣維護一個文件系統保持數據的一致性就很是困難了。

 

分佈式與數據複製

Zookeeper做爲一個集羣提供一致的數據服務，天然，它要在全部機器間作數據複製。數據複製的好處：

一、 容錯
一個節點出錯，不致於讓整個系統中止工做，別的節點能夠接管它的工做；

二、提升系統的擴展能力
把負載分佈到多個節點上，或者增長節點來提升系統的負載能力；

三、提升性能
讓客戶端本地訪問就近的節點，提升用戶訪問速度。

 

從客戶端讀寫訪問的透明度來看，數據複製集羣系統分下面兩種：

一、寫主(WriteMaster)
對數據的修改提交給指定的節點。讀無此限制，能夠讀取任何一個節點。這種狀況下客戶端須要對讀與寫進行區別，俗稱讀寫分離；

二、寫任意(Write Any)
對數據的修改可提交給任意的節點，跟讀同樣。這種狀況下，客戶端對集羣節點的角色與變化透明。

 

        對zookeeper來講，它採用的方式是寫任意。經過增長機器，它的讀吞吐能力和響應能力擴展性很是好，而寫，隨着機器的增多吞吐能力確定降低（這 也是它創建observer的緣由），而響應能力則取決於具體實現方式，是延遲複製保持最終一致性，仍是當即複製快速響應。

咱們關注的重點仍是在如何保證數據在集羣全部機器的一致性，這就涉及到paxos算法。

 

數據一致性與paxos算法

        聽說Paxos算法的難理解與算法的知名度同樣使人敬仰，因此咱們先看如何保持數據的一致性，這裏有個原則就是：

在一個分佈式數據庫系統中，若是各節點的初始狀態一致，每一個節點都執行相同的操做序列，那麼他們最後能獲得一個一致的狀態。

        Paxos算法解決的什麼問題呢，解決的就是保證每一個節點執行相同的操做序列。好吧，這還不簡單，master維護一個全局寫隊列，全部寫操做都必須 放入這個隊列編號，那麼不管咱們寫多少個節點，只要寫操做是按編號來的，就能保證一致性。沒錯，就是這樣，但是若是master掛了呢。

        Paxos算法經過投票來對寫操做進行全局編號，同一時刻，只有一個寫操做被批准，同時併發的寫操做要去爭取選票，只有得到過半數選票的寫操做纔會被 批准（因此永遠只會有一個寫操做獲得批准），其餘的寫操做競爭失敗只好再發起一輪投票，就這樣，在日復一日年復一年的投票中，全部寫操做都被嚴格編號排 序。編號嚴格遞增，當一個節點接受了一個編號爲100的寫操做，以後又接受到編號爲99的寫操做（由於網絡延遲等不少不可預見緣由），它立刻能意識到本身 數據不一致了，自動中止對外服務並重啓同步過程。任何一個節點掛掉都不會影響整個集羣的數據一致性（總2n+1臺，除非掛掉大於n臺）。

總結

        Zookeeper 做爲 Hadoop 項目中的一個子項目，是 Hadoop 集羣管理的一個必不可少的模塊，它主要用來控制集羣中的數據，如它管理 Hadoop 集羣中的 NameNode，還有 Hbase 中 Master Election、Server 之間狀態同步等。

 

Zookeeper工做原理

        ZooKeeper是一個分佈式的，開放源碼的分佈式應用程序協調服務，它包含一個簡單的原語集，分佈式應用程序能夠基於它實現同步服務，配置維護和 命名服務等。Zookeeper是hadoop的一個子項目，其發展歷程無需贅述。在分佈式應用中，因爲工程師不能很好地使用鎖機制，以及基於消息的協調 機制不適合在某些應用中使用，所以須要有一種可靠的、可擴展的、分佈式的、可配置的協調機制來統一系統的狀態。Zookeeper的目的就在於此。本文簡 單分析zookeeper的工做原理，對於如何使用zookeeper不是本文討論的重點。

 

 

 

Zookeeper的基本概念

1.1 角色

Zookeeper中的角色主要有如下三類，以下表所示：

                         

系統模型如圖所示：

                                 

1.2 設計目的

1.最終一致性：client不論鏈接到哪一個Server，展現給它都是同一個視圖，這是zookeeper最重要的性能。

2 .可靠性：具備簡單、健壯、良好的性能，若是消息m被到一臺服務器接受，那麼它將被全部的服務器接受。

3 .實時性：Zookeeper保證客戶端將在一個時間間隔範圍內得到服務器的更新信息，或者服務器失效的信息。但因爲網絡延時等緣由，Zookeeper不能保證兩個客戶端能同時獲得剛更新的數據，若是須要最新數據，應該在讀數據以前調用sync()接口。

4 .等待無關（wait-free）：慢的或者失效的client不得干預快速的client的請求，使得每一個client都能有效的等待。

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

6 .順序性：包括全局有序和偏序兩種：全局有序是指若是在一臺服務器上消息a在消息b前發佈，則在全部Server上消息a都將在消息b前被髮布；偏序是指若是一個消息b在消息a後被同一個發送者發佈，a必將排在b前面。

 ZooKeeper的工做原理

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

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

每一個Server在工做過程當中有三種狀態：

• LOOKING：當前Server不知道leader是誰，正在搜尋
• LEADING：當前Server即爲選舉出來的leader
• FOLLOWING：leader已經選舉出來，當前Server與之同步

2.1 選主流程

      當leader崩潰或者leader失去大多數的follower，這時候zk進入恢復模式，恢復模式須要從新選舉出一個新的leader，讓全部的 Server都恢復到一個正確的狀態。Zk的選舉算法有兩種：一種是基於basic paxos實現的，另一種是基於fast paxos算法實現的。系統默認的選舉算法爲fast paxos。先介紹basic paxos流程：

        1 .選舉線程由當前Server發起選舉的線程擔任，其主要功能是對投票結果進行統計，並選出推薦的Server；

        2 .選舉線程首先向全部Server發起一次詢問(包括本身)；

        3 .選舉線程收到回覆後，驗證是不是本身發起的詢問(驗證zxid是否一致)，而後獲取對方的id(myid)，並存儲到當前詢問對象列表中，最後獲取對方提議的leader相關信息(        id,zxid)，並將這些信息存儲到當次選舉的投票記錄表中；

        4.  收到全部Server回覆之後，就計算出zxid最大的那個Server，並將這個Server相關信息設置成下一次要投票的Server；

        5.  線程將當前zxid最大的Server設置爲當前Server要推薦的Leader，若是此時獲勝的Server得到n/2 + 1的Server票數， 設置當前推薦的leader爲獲勝的Server，將根據獲勝的Server相關信息設置本身的狀態，不然，繼續這個過程，直到leader被選舉出來。

    經過流程分析咱們能夠得出：要使Leader得到多數Server的支持，則Server總數必須是奇數2n+1，且存活的Server的數目不得少於n+1.

    每一個Server啓動後都會重複以上流程。在恢復模式下，若是是剛從崩潰狀態恢復的或者剛啓動的server還會從磁盤快照中恢復數據和會話信息，zk會記錄事務日誌並按期進行快照，方便在恢復時進行狀態恢復。選主的具體流程圖以下所示：

                                         

      fast paxos流程是在選舉過程當中，某Server首先向全部Server提議本身要成爲leader，當其它Server收到提議之後，解決epoch和 zxid的衝突，並接受對方的提議，而後向對方發送接受提議完成的消息，重複這個流程，最後必定能選舉出Leader。其流程圖以下所示：

                         

2.2 同步流程

選完leader之後，zk就進入狀態同步過程。

        1. leader等待server鏈接；

        2 .Follower鏈接leader，將最大的zxid發送給leader；

        3 .Leader根據follower的zxid肯定同步點；

        4 .完成同步後通知follower 已經成爲uptodate狀態；

        5 .Follower收到uptodate消息後，又能夠從新接受client的請求進行服務了。

流程圖以下所示：

                                 

2.3 工做流程

2.3.1 Leader工做流程

Leader主要有三個功能：

        1 .恢復數據；

        2 .維持與Learner的心跳，接收Learner請求並判斷Learner的請求消息類型；

        3 .Learner的消息類型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息，根據不一樣的消息類型，進行不一樣的處理。

        PING消息是指Learner的心跳信息；REQUEST消息是Follower發送的提議信息，包括寫請求及同步請求；ACK消息是 Follower的對提議的回覆，超過半數的Follower經過，則commit該提議；REVALIDATE消息是用來延長SESSION有效時間。
Leader的工做流程簡圖以下所示，在實際實現中，流程要比下圖複雜得多，啓動了三個線程來實現功能。

                                 

2.3.2 Follower工做流程

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結果到客戶端，這個消息最初由客戶端發起，用來強制獲得最新的更新。

Follower的工做流程簡圖以下所示，在實際實現中，Follower是經過5個線程來實現功能的。

                         

對於observer的流程再也不敘述，observer流程和Follower的惟一不一樣的地方就是observer不會參加leader發起的投票。

 

附錄：

ZooKeeper典型使用場景一覽

        ZooKeeper是一個高可用的分佈式數據管理與系統協調框架。基於對Paxos算法的實現，使該框架保證了分佈式環境中數據的強一致性，也正是基 於這樣的特性，使得zookeeper可以應用於不少場景。網上對zk的使用場景也有很多介紹，本文將結合做者身邊的項目例子，系統的對zk的使用場景進 行歸類介紹。 值得注意的是，zk並非生來就爲這些場景設計，都是後來衆多開發者根據框架的特性，摸索出來的典型使用方法。所以，也很是歡迎你分享你在ZK使用上的奇 技淫巧。

       

 

 

 

 

 

 

 

 

場景類別	典型場景描述（ZK特性，使用方法）	應用中的具體使用
數據發佈與訂閱	發佈與訂閱即所謂的配置管理，顧名思義就是將數據發佈到zk節點上，供訂閱者動態獲取數據，實現配置信息的集中式管理和動態更新。例如全局的配置信息，地址列表等就很是適合使用。	1. 索引信息和集羣中機器節點狀態存放在zk的一些指定節點，供各個客戶端訂閱使用。2. 系統日誌（通過處理後的）存儲，這些日誌一般2-3天后被清除。   3. 應用中用到的一些配置信息集中管理，在應用啓動的時候主動來獲取一次，而且在節點上註冊一個Watcher，之後每次配置有更新，實時通知到應用，獲取最新配置信息。 4. 業務邏輯中須要用到的一些全局變量，好比一些消息中間件的消息隊列一般有個offset，這個offset存放在zk上，這樣集羣中每一個發送者都能知道當前的發送進度。 5. 系統中有些信息須要動態獲取，而且還會存在人工手動去修改這個信息。之前一般是暴露出接口，例如JMX接口，有了zk後，只要將這些信息存放到zk節點上便可。
Name Service	這個主要是做爲分佈式命名服務，經過調用zk的create node api，可以很容易建立一個全局惟一的path，這個path就能夠做爲一個名稱。
分佈通知/協調	ZooKeeper 中特有watcher註冊與異步通知機制，可以很好的實現分佈式環境下不一樣系統之間的通知與協調，實現對數據變動的實時處理。使用方法一般是不一樣系統都對 ZK上同一個znode進行註冊，監聽znode的變化（包括znode自己內容及子節點的），其中一個系統update了znode，那麼另外一個系統能 夠收到通知，並做出相應處理。	1. 另外一種心跳檢測機制：檢測系統和被檢測系統之間並不直接關聯起來，而是經過zk上某個節點關聯，大大減小系統耦合。2. 另外一種系統調度模式：某系統有控制檯和推送系統兩部分組成，控制檯的職責是控制推送系統進行相應的推送工做。管理人員在控制檯做的一些操做，其實是修改 了ZK上某些節點的狀態，而zk就把這些變化通知給他們註冊Watcher的客戶端，即推送系統，因而，做出相應的推送任務。   3. 另外一種工做彙報模式：一些相似於任務分發系統，子任務啓動後，到zk來註冊一個臨時節點，而且定時將本身的進度進行彙報（將進度寫回這個臨時節點），這樣任務管理者就可以實時知道任務進度。 總之，使用zookeeper來進行分佈式通知和協調可以大大下降系統之間的耦合。
分佈式鎖	分佈式鎖，這個主要得益於ZooKeeper爲咱們保證了數據的強一致性，即用戶只要徹底相信每時每刻，zk集羣中任意節點（一個zk server）上的相同znode的數據是必定是相同的。鎖服務能夠分爲兩類，一個是保持獨佔，另外一個是控制時序。   所 謂保持獨佔，就是全部試圖來獲取這個鎖的客戶端，最終只有一個能夠成功得到這把鎖。一般的作法是把zk上的一個znode看做是一把鎖，經過create znode的方式來實現。全部客戶端都去建立 /distribute_lock 節點，最終成功建立的那個客戶端也即擁有了這把鎖。 控 制時序，就是全部視圖來獲取這個鎖的客戶端，最終都是會被安排執行，只是有個全局時序了。作法和上面基本相似，只是這裏 /distribute_lock 已經預先存在，客戶端在它下面建立臨時有序節點（這個能夠經過節點的屬性控制：CreateMode.EPHEMERAL_SEQUENTIAL來指 定）。Zk的父節點（/distribute_lock）維持一份sequence,保證子節點建立的時序性，從而也造成了每一個客戶端的全局時序。
集羣管理	1. 集羣機器監 控：這一般用於那種對集羣中機器狀態，機器在線率有較高要求的場景，可以快速對集羣中機器變化做出響應。這樣的場景中，每每有一個監控系統，實時檢測集羣 機器是否存活。過去的作法一般是：監控系統經過某種手段（好比ping）定時檢測每一個機器，或者每一個機器本身定時向監控系統彙報「我還活着」。 這種作法可行，可是存在兩個比較明顯的問題：1. 集羣中機器有變更的時候，牽連修改的東西比較多。2. 有必定的延時。   利 用ZooKeeper有兩個特性，就能夠實時另外一種集羣機器存活性監控系統：a. 客戶端在節點 x 上註冊一個Watcher，那麼若是 x 的子節點變化了，會通知該客戶端。b. 建立EPHEMERAL類型的節點，一旦客戶端和服務器的會話結束或過時，那麼該節點就會消失。 例 如，監控系統在 /clusterServers 節點上註冊一個Watcher，之後每動態加機器，那麼就往 /clusterServers 下建立一個 EPHEMERAL類型的節點：/clusterServers/{hostname}. 這樣，監控系統就可以實時知道機器的增減狀況，至於後續處理就是監控系統的業務了。 2. Master選舉則是zookeeper中最爲經典的使用場景了。 在 分佈式環境中，相同的業務應用分佈在不一樣的機器上，有些業務邏輯（例如一些耗時的計算，網絡I/O處理），每每只須要讓整個集羣中的某一臺機器進行執行， 其他機器能夠共享這個結果，這樣能夠大大減小重複勞動，提升性能，因而這個master選舉即是這種場景下的碰到的主要問題。 利用ZooKeeper的強一致性，可以保證在分佈式高併發狀況下節點建立的全局惟一性，即：同時有多個客戶端請求建立 /currentMaster 節點，最終必定只有一個客戶端請求可以建立成功。 利用這個特性，就能很輕易的在分佈式環境中進行集羣選取了。 另外，這種場景演化一下，就是動態Master選舉。這就要用到 EPHEMERAL_SEQUENTIAL類型節點的特性了。 上 文中提到，全部客戶端建立請求，最終只有一個可以建立成功。在這裏稍微變化下，就是容許全部請求都可以建立成功，可是得有個建立順序，因而全部的請求最終 在ZK上建立結果的一種可能狀況是這樣： /currentMaster/{sessionId}-1 , /currentMaster/{sessionId}-2 , /currentMaster/{sessionId}-3 ….. 每次選取序列號最小的那個機器做爲Master，若是這個機器掛了，因爲他建立的節點會立刻小時，那麼以後最小的那個機器就是Master了。	1. 在搜索系統中，若是集羣中每一個機器都生成一份全量索引，不只耗時，並且不能保證彼此之間索引數據一致。所以讓集羣中的Master來進行全量索引的生成， 而後同步到集羣中其它機器。2. 另外，Master選舉的容災措施是，能夠隨時進行手動指定master，就是說應用在zk在沒法獲取master信息時，能夠經過好比http方式，向 一個地方獲取master。
分佈式隊列	隊列方面，我目前感受有兩種，一種是常規的先進先出隊列，另外一種是要等到隊列成員聚齊以後的才統一按序執行。對於第二種先進先出隊列，和分佈式鎖服務中的控制時序場景基本原理一致，這裏再也不贅述。   第 二種隊列實際上是在FIFO隊列的基礎上做了一個加強。一般能夠在 /queue 這個znode下預先創建一個/queue/num 節點，而且賦值爲n（或者直接給/queue賦值n），表示隊列大小，以後每次有隊列成員加入後，就判斷下是否已經到達隊列大小，決定是否能夠開始執行 了。這種用法的典型場景是，分佈式環境中，一個大任務Task A，須要在不少子任務完成（或條件就緒）狀況下才能進行。這個時候，凡是其中一個子任務完成（就緒），那麼就去 /taskList 下創建本身的臨時時序節點（CreateMode.EPHEMERAL_SEQUENTIAL），當 /taskList 發現本身下面的子節點知足指定個數，就能夠進行下一步按序進行處理了。