Zookeeper是一個開源的分佈式的，爲分佈式應用提供協調服務的Apache項目

 

Zookeeper從設計模式角度來理解：是一個基於觀察者模式設計的分佈式服務管理框架，它

負責存儲和管理大家都關心的數據，然後接收觀察者的註冊，一旦這些數據的狀態發生變化，

Zookeeper就負責通知已經在Zookeeper上註冊的那些觀察者做出相應的反應

 

Zookeeper = 文件系統 + 通知機制

特點

Zookeeper的集羣中：

1）一個領導者（Leader），多個跟隨者（Follower) 組成的集羣

2）集羣中只要有半數以上的節點存活，Zookeeper集羣就能正常服務

3）全局數據一致，每個Server保存一份相同數據的副本，Client無論連接到哪個Server,數據都是

一致的

4）更新請求順序進行，來自同一個Client的更新請求按照其發送順序依次執行

5）數據更新原子性，一次數據更新要麼成功，要麼失敗

6）實時性，在一定的時間範圍內，Client能讀到最新數據

數據結構

Zookeeper數據模型的結構與Unix文件系統很類似，整體上可以看做是一棵樹，每個節點稱爲一個ZNode。每個ZNode能夠存儲1MB的數據，每個ZNode都可以通過其路徑唯一標識

應用場景

提供的服務包括：統一命名服務、統一配置管理、統一集羣管理、服務器節點動態上下線、軟負載均衡

 

統一命名服務：

在分佈式環境下，需要經常對應用服務器進行統一命名，便於識別，比如iP不容易記住，域名可以

 

統一配置管理：

1）分佈式環境下，配置文件的同步非常常見

一般要求一個集羣中，所有節點的配置信息是一致的，比如kafka集羣

對一個配置文件的修改能夠快速同步到各個節點上

2）配置管理可交由Zookeeper實現

可將配置信息寫入Zookeeper上的一個Znode

各個客戶端服務器監聽這個Znode

一旦Znode中數據被修改，Zookeeper將通知各個客戶端服務器

 

統一集羣管理：

服務器節點動態上下線

軟負載均衡

配置參數

Zookeeper中的配置文件zoo.cfg中參數含義解讀如下：

1．tickTime =2000：Zookeeper服務器與客戶端心跳時間，單位毫秒

服務器之間或客戶端與服務器之間維持心跳的時間間隔，也就是每個tickTime時間就會發送一個心跳，時間單位爲毫秒。

 

2．initLimit =10：LF初始通信時限

集羣中的Follower服務器與Leader服務器之間初始連接時能容忍的最多心跳數（tickTime的數量），用它來限定集羣中的Zookeeper服務器連接到Leader的時限。

 

3．syncLimit =5：LF同步通信時限

集羣中Leader與Follower之間的最大響應時間單位，假如響應超過syncLimit * tickTime，Leader認爲Follwer死掉，從服務器列表中刪除Follwer。

 

4．dataDir：數據文件目錄+數據持久化路徑

主要用於保存Zookeeper中的數據。

 

5．clientPort =2181：客戶端連接端口

監聽客戶端連接的端口。

 

server.2=172.20.10.14:2888:3888

server.3=172.20.10.4:2888:3888

server.4=172.20.10.5:2888:3888

配置參數解讀
server.A=B:C:D。
A是一個數字，表示這個是第幾號服務器；
集羣模式下配置一個文件myid，這個文件在dataDir目錄下，這個文件裏面有一個數據就是A的值，Zookeeper啓動時讀取此文件，拿到裏面的數據與zoo.cfg裏面的配置信息比較從而判斷到底是哪個server。
B是這個服務器的ip地址；
C是這個服務器與集羣中的Leader服務器交換信息的端口；
D是萬一集羣中的Leader服務器掛了，需要一個端口來重新進行選舉
選出一個新的Leader，而這個端口就是用來執行選舉時服務器相互通信的端口。

選舉機制

1）半數機制：集羣中半數以上機器存活，集羣可用。所以 Zookeeper 適合安裝奇數臺 服務器。

 

2）Zookeeper 雖然在配置文件中並沒有指定 Master 和 Slave。但是，Zookeeper 工作時， 是有一個節點爲 Leader，其他則爲 Follower，Leader 是通過內部的選舉機制臨時產生的。

 

3）以一個簡單的例子來說明整個選舉的過程。

 

假設有五臺服務器組成的 Zookeeper 集羣，它們的 id 從 1-5，同時它們都是最新啓動的， 也就是沒有歷史數據，在存放數據量這一點上，都是一樣的。假設這些服務器依序啓動，來 看看會發生什麼

（1）服務器 1 啓動，發起一次選舉。服務器 1 投自己一票。此時服務器 1 票數一票， 不夠半數以上（3 票），選舉無法完成，服務器 1 狀態保持爲 LOOKING；

 

（2）服務器 2 啓動，再發起一次選舉。服務器 1 和 2 分別投自己一票並交換選票信息： 此時服務器 1 發現服務器 2 的 ID 比自己目前投票推舉的（服務器 1）大，更改選票爲推舉 服務器 2。此時服務器 1 票數 0 票，服務器 2 票數 2 票，沒有半數以上結果，選舉無法完成， 服務器 1，2 狀態保持 LOOKING

 

（3）服務器 3 啓動，發起一次選舉。此時服務器 1 和 2 都會更改選票爲服務器 3。此 次投票結果：服務器 1 爲 0 票，服務器 2 爲 0 票，服務器 3 爲 3 票。此時服務器 3 的票數已 經超過半數，服務器 3 當選 Leader。服務器 1，2 更改狀態爲 FOLLOWING，服務器 3 更改 狀態爲 LEADING；

 

（4）服務器 4 啓動，發起一次選舉。此時服務器 1，2，3 已經不是 LOOKING 狀態， 不會更改選票信息。交換選票信息結果：服務器 3 爲 3 票，服務器 4 爲 1 票。此時服務器 4 服從多數，更改選票信息爲服務器 3，並更改狀態爲 FOLLOWING；

 

（5）服務器 5 啓動，同 4 一樣當小弟。

節點類型

持久（persistent）：客戶端和服務器斷開連接後，創建的節點不刪除

短暫（Ephemeral）：客戶端和服務器斷開連接後，節點自己刪除

客戶端命令行操作

命令基本語法	功能描述
help	顯示所有操作命令
ls path [watch]	使用 ls 命令來查看當前 znode 中所包含的內容
ls2 path [watch]	查看當前節點數據並能看到更新次數等數據
create	普通創建 -s 含有序列 -e 臨時（重啓或者超時消失）
get path [watch]	獲得節點的值
set	設置節點的具體值
stat	查看節點狀態
delete	刪除節點
rmr	遞歸刪除節點

Stat結構體

1）czxid-創建節點的事務 zxid

每次修改 ZooKeeper 狀態都會收到一個 zxid 形式的時間戳，也就是 ZooKeeper 事務 ID。

事務 ID 是 ZooKeeper 中所有修改總的次序。每個修改都有唯一的 zxid，如果 zxid1 小於 zxid2，那麼 zxid1 在 zxid2 之前發生。

 

2）ctime - znode 被創建的毫秒數(從 1970 年開始)

 

3）mzxid - znode 最後更新的事務 zxid

 

4）mtime - znode 最後修改的毫秒數(從 1970 年開始)

 

5）pZxid-znode 最後更新的子節點 zxid

 

6）cversion - znode 子節點變化號，znode 子節點修改次數

 

7）dataversion - znode 數據變化號

 

8）aclVersion - znode 訪問控制列表的變化號

 

9）ephemeralOwner- 如果是臨時節點，這個是 znode 擁有者的 session id。如果不是臨時節 點則是 0。

 

10）dataLength- znode 的數據長度

 

11）numChildren - znode 子節點數量

監聽器原理

寫數據流程

服務器動態上下線案例