何爲 zookeeper？

一、定義

1、字面含義來看

什麼是zookeeper，zookeeper從其單詞的字面意思來看就是動物園管理員的意思，爲什麼要這樣起名字呢，其實也跟這些組件有關；就hadoop而言最初名字的來源是作者的孩子有一個名爲hadop的大象玩具，剛好這個單詞呢也很符合容易記住的特點，然後就以它爲hadoop的名字了，後面呢一系列的大數據組件都效仿，都以動物的方式進行命名，然後就有了我們的動物園（Hadoop生態圈） ，動物嘛畢竟是動物，而且還有還這麼多，如果沒人管那豈不亂了套了，所以就有了我們的zookeeper，zookeeper和其名字的含義一樣，就是一個管理者，它是用於分佈式環境下的協調工作。

2、官方的解釋

官網上的解釋就是，很多分佈式應用它們在爭奪同一個資源時，有時會因爲沒有協商從而導致系統出錯，其實就是解決一個分佈式環境下的同步問題；

官網上的解釋其實也很模糊，只是大概講了一下zookeeper的作用，我們再來看一下Wiki上的解釋：

可以看到Wiki上面就解釋的非常清楚了，大概呢就是說：
ZooKeeper是一個用於維護配置信息，命名，提供分佈式同步以及提供組服務的集中式服務。所有這些類型的服務都以某種形式被分佈式應用程序使用。每次運行它們時，都會進行很多工作來修復不可避免的錯誤和競爭條件。ZooKeeper的目的就是將這些不同服務的本質提煉成一個非常簡單的界面，以實現集中式協調服務。服務本身是分佈式的，並且高度可靠。共識，組管理和狀態協議將由服務實現，因此應用程序不需要自己實現它們。這些應用程序的特定用途將包括Zoo Keeper的特定組件和特定於應用程序的約定的混合。

二、zookeeper能做哪些事

1、先來看看它的結構

• 從Wiki中我們我們發現這樣一句話

    ZooKeeper nodes store their data in a hierarchical name space, much like a file system or a tree data structure
  

  什麼意思呢就是說，zookeeper的節點存儲在分層的命名空間當中，有點類似於Linux中的文件系統的樹型結構。
  
  Linux的文件系統格式就如上圖所示，那麼zookeeper這棵樹又是怎麼樣個特點呢？

  • 在zookeeper中每個節點被成爲Znode而且Znode分爲兩種：
    1.（Ephemeral）臨時節點或者稱爲短暫節點，這種節點的特點就是，當客戶端於服務端的連接斷開後，那麼此次連接會話期間創建的臨時節點就會被註銷掉。
    2.（Persistent）持久節點，這類節點不會在客戶端斷開的情況下自動刪除。
    根據上面的解釋，相信大家也已經猜到了，沒錯zookeeper採用的時C/S架構即由服務端和客戶端兩部分組成，可以根據下圖進行理解：
    

• 監聽器
  在上面我們已經簡單知道了ZooKeeper的數據結構了，ZooKeeper還配合了監聽器才能夠做那麼多事的。
  常見的監聽場景有以下兩項：
  (1)監聽Znode節點的數據變化
  因爲在zookeeper中的節點是可以保存數據的，所以我們可以監聽節點中數據的變化
  
  (2)監聽子節點的增減變化
  這一點毋庸置疑，我們可以監聽某個節點下子節點的個數。
  

2.統一配置

• 假如你有很多臺服務器，你需要在這個集羣上面配置一個分佈式的服務，既然是配置服務，那少不了的就是更改配置文件，我的服務器由成百上千臺，要是以人手動的方式去更改配置那豈不得配到猴年馬月，有運維基礎的可能會用同步命令的方式進行統一配置，那就不用說了，zookeeper在這裏也可以很好的解決這個問題，比如我們要配置的這個文件叫做 test-site.xml 那麼zookeeper的工作機理就如下圖所示：
  
  我們的所有服務器都監聽/configuration節點中的test-site.xml數據，如果節點中的數據已有變化，就會觸發監聽器，然後將消息發哦送給正在監聽此節點的服務器，服務器收到消息後然後再進行相應的配置修改，這就實現了統一配置；

3.統一命名服務

• 假如我有一個域名www.nickwiki.com,但是我的服務器有多臺，我想別人通過訪問我的這個域名然後我自己內部協調條它訪問哪一臺機器，zookeeper便可以完成這一需求，其實這有點類似於nginx的功能，
  zookeeper的實現方式其實很簡單，和上面的統一配置有一點類似，假如我其他機器的IP地址爲
  192.168.1.1
  192.168.1.2
  192.168.1.3
  192.168.1.4
  那麼就有下圖：

我問在外部僅需訪問域名即可，置於到底是訪問哪一臺服務器就由master端自行選擇，這非常有助於服務器的負載均衡，提高服務的可靠性；

4.分佈式鎖的實現

• 鎖的概念在這我就不說了，可以自行百度進行了解，在這裏我們可以使用ZooKeeper來實現分佈式鎖，那是怎麼做的呢？？下面來看看：
  假如系統server1、server2、server3都去訪問/locks節點
  
  訪問的時候會創建帶順序號的臨時/短暫(EPHEMERAL_SEQUENTIAL)節點，比如，serve1創建了id_000000節點，serve2創建了id_000002節點，serve3創建了id_000001節點。
  

• 接着，拿到/lock節點下的所有子節點(id_000000,id_000001,id_000002)，判斷自己創建的是不是最小的那個節點

  如果是，則拿到鎖。

  釋放鎖：執行完操作後，把創建的節點給刪掉

  如果不是，則監聽比自己要小1的節點變化

舉個例子：

• server1拿到/lock節點下的所有子節點，經過比較，發現自己(id_000000)，是所有子節點最小的。所以得到鎖

• server2拿到/lock節點下的所有子節點，經過比較，發現自己(id_000002)，不是所有子節點最小的。所以監聽比自己小1的節點id_000001的狀態

• server3拿到/lock節點下的所有子節點，經過比較，發現自己(id_000001)，不是所有子節點最小的。所以監聽比自己小1的節點id_000000的狀態
  ……

• 等到系統server1執行完操作以後，將自己創建的節點刪除(id_000000)。通過監聽，server3發現id_000000節點已經刪除了，發現自己已經是最小的節點了，於是順利拿到鎖
  ….server2如上

5.集羣狀態

• 在很多分佈式環境當中我們需要監控整個集羣的狀態，比如那一臺機器宕機了，哪一臺機器又重啓了，這都需要我們進行監控，又比如HA（高可用）模式下的hadoop有多個namenode節點，這些namenode之間就有主從之分，在衆多namnode當中只有一個namenode處於active狀態，其他全部處於standby狀態，只有當處於active狀態的namenode出問題後，纔會在待命狀態下的namenode中重新選舉出一個作爲active的namenode出來，這當中的active-namenode的監控，和後面namnode的選舉就需要用到zookeeper來實現，下面就簡單的來說一下zookeeper是如何進行監控集羣狀態的；

集羣中每臺機器都在/cluster節點上維護一個子節點，如果server1掛掉了，那麼它就會自動刪除掉/cluster/s1節點，然後整個系統通過監聽/cluster下中的所有子節點就可以知道集羣當中所有機器的狀態；
前面提到的hadoop中active-namenode的選舉過程其實也可以參照前面分佈式鎖的方式進行實現；

• 首先當前的active-namenode掛掉了，那麼通過監聽/cluster節點下的子節點就可以知道這個消息。
• 然後集羣知道這個消息後就會通知現在還存活的其他namenode，然後它們就會各自在zookeeper中進行註冊一個供選舉用且有順序的臨時節點，然後通過比較自己創建的節點的編號是否是最小的；
  （1）如果是那麼他就可以切換身份由standby狀態轉爲active狀態
  （2）不是最小時那麼他就會放棄此次爭奪

三、性能情況

• zoookeeper本身自項目啓動之日起目標就是高性能的一個分佈式協調框架，根據雅虎做的實驗來看，也確實如此：
  
  在讀取次數超過寫入次數的應用程序中，由於寫入操作會涉及同步所有服務器的狀態，因此該操作特別耗費性能。（但對於協調服務，通常情況下，讀取次數多於寫入次數。）

四、簡單的API

ZooKeeper的設計目標之一是提供一個非常簡單的編程界面。因此，它僅支持以下操作：

• create：在樹中的某個位置創建一個節點

• delete：刪除節點

• exists ：測試節點是否存在於某個位置

• get data：從節點讀取數據

• set data：將數據寫入節點

• get children：獲取節點子節點的列表

• sync：等待數據傳播

今天簡單的講了一下zookeeper的工作原理和用途，其實呢在實際當中遠遠沒有上面所說的這麼簡單，要真的想深層次的學習於理解zookeeper還需要多看一些專業的文檔，才能更全面的瞭解zookeeper，如果大家發現博文中出現什麼問題，歡迎在評論區下留言探討。