一、基本介紹

        Zookeeper 是 Google 的 Chubby一個開源的實現，是 Hadoop 的分散式協調服務 。它包含一個簡單的原語集，分散式應用程式可以基於它實現同步服務，配置維護和命名服務等。

        大部分分散式應用需要一個主控、協調器或控制器來管理物理分佈的子程序（如資源、任務分配等） ，目前，大部分應用需要開發私有的協調程式，缺乏一個通用的機制，協調程式的反覆編寫浪費，且難以形成通用、伸縮性好的協調器。而ZooKeeper提供通用的分散式鎖服務，用以協調分散式應用。zookeeper的最主要功能就是保管客戶端提交的資料（極其少量的資料），每一份資料在zookeeper叫做一個znode。znode之間形成一種樹狀結構（類似於檔案樹）。雖然說可以提供各種服務，但是zookeeper在底層其實只提供了兩個功能：

• 管理(儲存，讀取)使用者程式提交的資料；
• 併為使用者程式提供資料節點監聽服務；

二、工作原理

        Zookeeper的核心是原子廣播，這個機制保證了各個server之間的同步。實現這個機制的協議叫做Zab協議。Zab協議有兩種模式，它們分別是恢復模式和廣播模式。當服務啟動或者在領導者崩潰後，Zab就進入了恢復模式，當領導者被選舉出來，且大多數server的完成了和leader的狀態同步以後，恢復模式就結束了。狀態同步保證了leader和server具有相同的系統狀態。 一旦leader已經和多數的follower進行了狀態同步後，他就可以開始廣播訊息了，即進入廣播狀態。這時候當一個server加入zookeeper服務中，它會在恢復模式下啟動，發現leader，並和leader進行狀態同步。待到同步結束，它也參與訊息廣播。Zookeeper服務一直維持在Broadcast狀態，直到leader崩潰了或者leader失去了大部分的followers支援。

        廣播模式需要保證proposal被按順序處理，因此zk採用了遞增的事務id號(zxid)來保證。所有的提議(proposal)都在被提出的時候加上了zxid。實現中zxid是一個64為的數字，它高32位是epoch用來標識leader關係是否改變，每次一個leader被選出來，它都會有一個新的epoch。低32位是個遞增計數。 當leader崩潰或者leader失去大多數的follower，這時候zk進入恢復模式，恢復模式需要重新選舉出一個新的leader，讓所有的server都恢復到一個正確的狀態(只要叢集中有半數以上節點存活，叢集就能提供服務)。 

三、應用場景

1、統一命名服務

        分散式應用中，通常需要有一套完整的命名規則，既能夠產生唯一的名稱又便於人識別和記住，通常情況下用樹形的名稱結構是一個理想的選擇，樹形的名稱結構是一個有層次的目錄結構，既對人友好又不會重複。 Name Service 是 Zookeeper 內建的功能，只要呼叫 Zookeeper 的 API 就能實現。【其實就類似Doubbo和Spring Cloud的註冊中心，將服務Id和對應的服務地址放到Zookeeper中】

2、配置管理

        配置的管理在分散式應用環境中很常見，例如同一個應用系統需要多臺 PC Server 執行，但是它們執行的應用系統的某些配置項是相同的，如果要修改這些相同的配置項，那麼就必須同時修改每臺執行這個應用系統的 PC Server，這樣非常麻煩而且容易出錯。

        將配置資訊儲存在 Zookeeper 的某個目錄節點中，然後將所有需要修改的應用機器監控配置資訊的狀態，一旦配置資訊發生變化，每臺應用機器就會收到 Zookeeper 的通知，然後從 Zookeeper 獲取新的配置資訊應用到系統中。【solrCloud就是將配置檔案（主要是schema.xml、solrconfig.xml）都交由zookeeper統一管理的】

3、叢集管理

        Zookeeper 能夠很容易的實現叢集管理的功能，如有多臺 Server 組成一個服務叢集，那麼必須要一個“總管”知道當前叢集中每臺機器的服務狀態，一旦有機器不能提供服務，叢集中其它叢集必須知道，從而做出調整重新分配服務策略。同樣當增加叢集的服務能力時，就會增加一臺或多臺 Server，同樣也必須讓“總管”知道。

        Zookeeper 不僅能夠維護當前的叢集中機器的服務狀態，而且能夠選出一個“總管”，讓這個總管來管理叢集，這就是 Zookeeper 的另一個功能 Leader Election。

四、zookeeper結構和命令

1、 zookeeper結構

        zookeeper的資料結構為層次化的目錄結構，命名符合常規檔案系統規範。每個節點在zookeeper中叫做znode,並且其有一個唯一的路徑標識。節點Znode可以包含資料和子節點（但是EPHEMERAL型別的節點不能有子節點，下一頁詳細講解）。客戶端應用可以在節點上設定監視器。

其中Znode有兩種型別：

• 短暫（ephemeral）（斷開連線自己刪除）
• 持久（persistent）（斷開連線不刪除）

有四種形式的目錄節點（預設是persistent ）：

• PERSISTENT
• PERSISTENT_SEQUENTIAL（持久序列/test0000000019 ）
• EPHEMERAL
• EPHEMERAL_SEQUENTIAL

在建立znode時設定順序標識，znode名稱後會附加一個值，順序號是一個單調遞增的計數器，由父節點維護。在分散式系統中，順序號可以被用於為所有的事件進行全域性排序，這樣客戶端可以通過順序號推斷事件的順序。

2、zookeeper命令列操作

        可以通過bin命令下的zkCli.sh（執行 zkCli.sh –server <ip>進入命令列工具）啟動客戶端，啟動完成後可以通過help參考基本命令：

1、使用 ls 命令來檢視當前 ZooKeeper 中所包含的內容：

[zk: 202.115.36.251:2181(CONNECTED) 1] ls /

2、建立一個新的 znode ，使用 create /zk myData 。這個命令建立了一個新的 znode 節點“ zk ”以及與它關聯的字串：

[zk: 202.115.36.251:2181(CONNECTED) 2] create /zk "myData“

3、我們執行 get 命令來確認 znode 是否包含我們所建立的字串：

[zk: 202.115.36.251:2181(CONNECTED) 3] get /zk
#監聽這個節點的變化,當另外一個客戶端改變/zk時,它會打出下面的
#WATCHER::
#WatchedEvent state:SyncConnected type:NodeDataChanged path:/zk
[zk: localhost:2181(CONNECTED) 4] get /zk watch

4、下面我們通過 set 命令來對 zk 所關聯的字串進行設定：

[zk: 202.115.36.251:2181(CONNECTED) 4] set /zk "zsl"

5、下面我們將剛才建立的 znode 刪除：

[zk: 202.115.36.251:2181(CONNECTED) 5] delete /zk

6、刪除節點：rmr

[zk: 202.115.36.251:2181(CONNECTED) 5] rmr /zk

3、通過命令方式演示zookeeper的監聽

        首先我們使用啟動兩個zookeeper客戶端（如果啟動時不指定ip:port，預設連線本地），啟動客戶端1：

然後啟動客戶端2，啟動命令一樣，啟動後使用命令連線的和客戶端1相同的zookeeper節點，如下：

然後先在客戶端1建立檔案結點，

然後在客戶端2上檢視：

這時，我們在客戶端1上set值時，客戶端2上是不會收到通知的，除非我們

即表示啟動監聽，這時我們在客戶端1上更改值，

我們再來看客戶端2：

我們發現會收到監聽事件，但是當我們再在客戶端1上改變值時，將不會再監聽到（一次性的），需要再次啟動監聽。