Zookeeper 啓蒙

2018-12-14

關鍵詞： Zookeeper入門介紹 、 Zookeeper是什麼、Zookeeper架構解析、Zookeeper應用場景、Zookeeper有什麼用

---

 

本篇文章系筆者依據當前所掌握的知識對 Zookeeper 做出的一個啓蒙式介紹，不對文章的絕對、徹底正確性負責。

 

Zookeeper 對於大數據開發來講實在是過重要了！ Zookeeper 是由雅虎研究院開發，現現在是 apache 基金會的一個頂級項目。本篇文章不會涉及太多專業知識，主要是想以聊天的方式向讀者介紹一下筆者眼中的 Zookeeper 。

 

一、啓蒙篇

1.一、Zookeeper 是什麼？

 

官網上對於 Zookeeper 的一句話介紹是：一款支持高可用的分佈式協調框架。這個介紹一看就顯得它很高大上，不過對於不少初學者來講，可能就會一頭霧水了。不只官話很晦澀難懂，連市面上絕大多數教材在關於 Zookeeper 的介紹上都是狂甩那些讓人懵圈的專業名詞，什麼配置維護啦，命名服務啦巴啦巴啦的。我就不喜歡這些一板一眼的東西。

 

說人話： Zookeeper 是一款用於在多臺電腦之間同步消息用的。這話看起來就舒服多了吧！在分佈式系統中，因爲涉及到設備的物理隔離，各設備之間的消息傳遞、狀態監控就變得極其重要且棘手。而 Zookeeper 就是爲了解決這個問題而產生的。

 

那，Zookeeper 通常都在分佈式系統中同步些什麼消息呢？

a) 設備的狀態信息

分佈式系統中，咱們很是關心其它機器當前的上/下線等狀態。一般每一臺機器上線後都會在 Zookeeper 上註冊本身的信息以供集羣中其它機器能夠知曉本身上線了，同時本身也能夠經過 Zookeeper 得知當前還有哪些機器在線。

b) 關鍵信息同步

這個 「關鍵信息」 其實就說的很模糊了。其實本質上任何信息均可以被稱之爲是關鍵信息，均可以被保存在 Zookeeper 上，可是因爲 Zookeeper 每一個節點的容量很是小，只有 1MB ，所以，只能將一些相當重要的信息保存在 Zookeeper 上。好比，HBase 會將相當重要的 meta 表的存儲位置保存在 Zookeeper 上，任何有權限的客戶端均可以經過 Zookeeper 獲得存儲地址後去訪問 meta 信息。你看，即便 meta 表於 HBase 是相當重要的，但在 Zookeeper 上也僅僅是保存着其存儲位置而非內容信息，由此，相信咱們也大概知曉該將什麼信息放在 Zookeeper 上了吧。固然這裏僅僅是舉個小例子，其實只要你考慮到它每一個節點僅 1MB 的容量之後，你就能夠根據你的業務需求在 Zookeeper 上存儲任何數據。

 

 好，咱們來總結一下： Zookeeper 是一個在分佈式系統之中分享消息用的開源軟件框架。

zookeeper logo

 

1.二、Zookeeper 的應用場景

 

Zookeeper 通常在哪些場景下有應用呢？

 

這個問題真的很差回答。想象一下若是有人問你：「螺絲在哪些場景下有應用？」  你該如何回答？上至已經飛出太陽系的 「旅行者 1 號」，下及汽車手機甚至生物骨骼接駁，處處都能見到螺絲的應用場景。我猜，關於這個問題你很大多是沉吟一會後給出回答：「哪裏須要螺絲，螺絲就在哪裏有應用」 。是的， Zookeeper 也是！

 

咱們知道螺絲它的做用就是鏈接兩個物理隔離物體，那麼當咱們須要將某兩個物理隔離的物體鏈接起來的時候，就會要用到螺絲了。而 Zookeeper 嘛，前面已經說到它是用於在多臺電腦之間分享消息用的，因此當咱們的某個場景正好有這個需求時，那它就能有應用啦。好比，大名鼎鼎的 HBase 就是期望 Zookeeper 而活的。

 

一句話總結：Zookeeper 通常應用於有同步消息的分佈式系統場景中。

 

這裏額外探討一個重要知識點：Zookeeper 的功能通常是如何來使用的？

咱們一直在說 Zookeeper 是一個給分佈式應用提供消息同步服務的框架，那分佈式應用平時都是如何來使用它提供的服務的呢？從設計模式的角度來看，Zookeeper 是一個基於 「觀察者模式」 而設計的框架。應用通常會經過向 Zookeeper 「註冊監聽」 的方式來實時監聽咱們所感興趣的數據。一般，一臺機器在上線後，會主動鏈接配置好的 Zookeeper 集羣，並向指定地址註冊本身的信息或者請求消息監聽，當監聽的數據發生變化時，Zookeeper 就會主動向註冊者發送回調消息。

 

1.三、Zookeeper 的架構與結構

 

 Zookeeper 是比較 「小巧」 的框架，它的內部只有兩種角色： 1. Leader； 2. Follower 。同時它還能夠劃分爲： 1. 服務端； 2. 客戶端。 其架構圖直接盜用官網的圖片展現以下

zookeeper 架構

 什麼是 「服務端」 與 「客戶端」 ？

在官網及其它教材上 Zookeeper 常常會被介紹爲是一款爲分佈式應用提供協調服務的框架。因此它本質上也是提供服務用的。所以 「服務端」 是描述 Zookeeper 做爲服務提供者的特性。通常咱們說 Zookeeper ，都是在說它的服務端功能。

 

至於客戶端，就是開放給人使用的了，咱們通常會經過自帶的客戶端程序來查看當前服務端的狀態及其存儲的信息等。

 

關於 Leader 和 Follower

Leader 和 Follower 都是在服務端纔有的角色劃分。Zookeeper 在生產環境中都是以集羣的狀態來提供服務的。既然涉及到集羣，那就必須得有一我的是 「說了算」 的。一個 Zookeeper 集羣中，有且僅有一個 Leader 角色，其他的都是 Follower 。Zookeeper 自己是提供消息服務的，對於消息的基礎操做莫過於 讀和寫 了。集羣中全部成員都具備 讀權限 。但只有 Leader 才具有 寫權限 。

 

僅對 Leader 開放寫權限的目的就是爲了實現其 「數據一致性」 的。從上面架構圖中能夠看到，雖然客戶端能夠與任意一個 Follower 創建通訊，可是客戶端能與 Follower 直接通訊的也僅有讀取數據而已。若是客戶端向某 Follower 發起 寫請求 ，該 Follower 在接收到這個寫請求後仍是會將寫請求操做轉發給 Leader ，讓 Leader 來實現真正的數據寫入操做，不過這一過程對客戶端而言是透明的。正如上面架構圖所示，Leader 和 Follower 之間也會有很緊密的交互聯繫，這些聯繫一部分是數據同步，另外一部分可能就是來自客戶端的寫請求了。值得一提的是，Zookeeper 會將數據完整地複製到全部機器上，這樣才能實現客戶端能夠經過任意機器讀取數據的功能。

 

關於 Zookeeper 的數據結構

Zookeeper 的數據結構和 Linux 文件系統結構是同樣的。都是經過一個以 「 / 」 爲根目錄的目錄樹形結構。其結構圖以下圖所示

zk 目錄樹

 不過 Zookeeper 的目錄樹與 Linux 的文件系統的目錄樹還有一個不一樣：Zookeeper 的目錄名稱自己是能夠存儲數據的。 以上圖爲例，在 Linux 文件系統中， app1 這個節點只能是做爲 「目錄」 存在，由於它內部還有子節點，app1 自己不能保存數據。而在 Zookeeper 中 app1 除了能有子節點之外，自己還能再保存數據。

 

在 Zookeeper 中，根節點 「 / 」 是默認存在的，而且在根目錄內默認還有一個名稱爲 「zookeeper」 的子節點。每一個節點都被稱爲 「znode」 ，它既能再擴展子節點，也能保存一段數據，默認每一個 znode 能存儲 1MB 的數據。

 

Zookeeper 中的操做幾乎都是發生在 znode 中的。znode 可分爲兩種類型：

1. 臨時節點

又可分爲普通節點和序列化節點。

2. 持久節點

又可分爲普通節點和序列化節點。

關於臨時節點和持久節點想必不用解釋了吧。臨時節點在會話結束後即會被銷燬。序列化節點則是在你提供的節點名稱後面自動加上一個用於標識當前節點在本路徑下的序號，通常是用於防止因節點重名而創建失敗的狀況。不過序列化節點的用途可遠不止於此，只是這裏筆者爲避免將知識點複雜化就不羅列了。

 

每一個 znode 節點還會有一些描述該節點的基本信息，以下圖所示，下圖中 cZxid ~ numChildren 即爲節點的屬性信息

節點屬性信息

不過筆者認爲，對於初次接觸的同窗來講，不須要去糾結這些屬性信息是什麼。只須要知道有這麼個東西就差很少了。

  

二、 實戰篇

原本想着在這裏貼出一篇使用 Java 寫的示例程序以演示一下 Zookeeper 在分佈式應用中的使用方式的。但彷佛示例程序也過於簡單，卻又比較佔篇幅，就算了。只在這裏簡單提一下吧，有興趣的同窗本身隨便摸索一下都能寫出來的。

 

經過前面咱們知道臨時節點的特性就是當會話斷掉後即會被刪除，並且節點還支持被各客戶端註冊狀態改變的監聽。利用這一特性就能很好地實現集羣主機狀態監控功能。所以，一般一臺主機上線後，會當即在 Zookeeper 中註冊一個本身並獲取其它主機的節點信息。當某臺主機宕機或斷開鏈接後，其對應的節點信息就會被刪除，並通知到其它節點主機中。主機之間須要同步什麼信息，也是直接向事先約定的好路徑寫入數據便可。

 

---

 

2019-04-07 修改