今天我們來說一下zookeeper，它翻譯爲中文的意思是：動物園管理者，可是這跟我們的架構有什麼關係呢？接着看。之前我們談到了dubbo，在dubbo解析中，我們提到了一種註冊服務的機制，但是當時並不知道那是個什麼東東，今天我們就來揭曉答案。
一、是什麼
ZooKeeper 顧名思義 動物園管理員，他是拿來管大象(Hadoop) 、 蜜蜂(Hive) 、 小豬(Pig) 的管理員，也就是說它是一個分佈式的，開放源碼的分佈式應用程序協調服務，是Google的Chubby一個開源的實現，是Hadoop和Hbase的重要組件。
它爲分佈式系統提供了高效可靠且易於使用的協同服務，它可以爲分佈式應用提供相當多的服務，諸如統一命名服務，配置管理，狀態同步和組服務等。
說的這麼抽象，它到底是個什麼呢。
簡單的說，zookeeper=文件系統+通知機制。1、文件系統
Zookeeper維護一個類似文件系統的數據結構：
每個子目錄項如 NameService 都被稱作爲 znode，和文件系統一樣，我們能夠自由的增加、刪除znode，在一個znode下增加、刪除子znode，唯一的不同在於znode是可以存儲數據的。
有四種類型的znode：
PERSISTENT-持久化目錄節點客戶端與zookeeper斷開連接後，該節點依舊存在
PERSISTENT_SEQUENTIAL-持久化順序編號目錄節點客戶端與zookeeper斷開連接後，該節點依舊存在，只是Zookeeper給該節點名稱進行順序編號
EPHEMERAL-臨時目錄節點客戶端與zookeeper斷開連接後，該節點被刪除
EPHEMERAL_SEQUENTIAL-臨時順序編號目錄節點客戶端與zookeeper斷開連接後，該節點被刪除，只是Zookeeper給該節點名稱進行順序編號
2、 通知機制
客戶端註冊監聽它關心的目錄節點，當目錄節點發生變化（數據改變、被刪除、子目錄節點增加刪除）時，zookeeper會通知客戶端。
二、做什麼
1、 命名服務
分佈式應用中，通常需要有一套完整的命名規則，既能夠產生唯一的名稱又便於人識別和記住，通常情況下用樹形的名稱結構是一個理想的選擇，樹形的名稱結構是一個有層次的目錄結構，既對人友好又不會重複。Name Service 已經是 Zookeeper 內置的功能，你只要調用 Zookeeper 的 API 就能實現。如調用 create 接口就可以很容易創建一個目錄節點。
2、 配置管理
程序總是需要配置的，如果程序分散部署在多臺機器上，要逐個改變配置就變得困難。好吧，現在把這些配置全部放到zookeeper上去，保存在 Zookeeper 的某個目錄節點中，然後所有相關應用程序對這個目錄節點進行監聽，一旦配置信息發生變化，每個應用程序就會收到 Zookeeper 的通知，然後從 Zookeeper 獲取新的配置信息應用到系統中就好。
3、 集羣管理
Zookeeper 能夠很容易的實現集羣管理的功能，如有多臺 Server 組成一個服務集羣，那麼必須要一個master知道當前集羣中每臺機器的服務狀態，一旦有機器不能提供服務，集羣中其它節點必須知道，從而做出調整重新分配服務策略。同樣當增加集羣的服務能力時，就會增加一臺或多臺 Server，同樣也必須讓master知道。Zookeeper 不僅能夠幫你維護當前的集羣中機器的服務狀態，而且能夠幫你選出一個master，讓這個master來管理集羣，這就是 Zookeeper 的另一個功能 Leader Election。
它們的實現方式都是在 Zookeeper 上創建一個 EPHEMERAL 類型的目錄節點，然後每個 Server 在它們創建目錄節點的父目錄節點上調用getChildren(String path, boolean watch) 方法並設置 watch 爲 true，由於是 EPHEMERAL 目錄節點，當創建它的 Server 死去，這個目錄節點也隨之被刪除，所以 Children 將會變化，這時 getChildren上的 Watch 將會被調用，所以其它 Server 就知道已經有某臺 Server 死去了。新增 Server 也是同樣的原理。
Zookeeper 如何實現 Leader Election，也就是選出一個 Master Server。和前面的一樣每臺 Server 創建一個 EPHEMERAL 目錄節點，不同的是它還是一個 SEQUENTIAL 目錄節點，所以它是個 EPHEMERAL_SEQUENTIAL 目錄節點。之所以它是 EPHEMERAL_SEQUENTIAL 目錄節點，是因爲我們可以給每臺 Server 編號，我們可以選擇當前是最小編號的 Server 爲 Master，假如這個最小編號的 Server 死去，由於是 EPHEMERAL 節點，死去的 Server 對應的節點也被刪除，所以當前的節點列表中又出現一個最小編號的節點，我們就選擇這個節點爲當前 Master。這樣就實現了動態選擇 Master，避免了傳統意義上單 Master 容易出現單點故障的問題。
4、 分佈式鎖
有了zookeeper的一致性文件系統，鎖的問題變得容易。鎖服務可以分爲兩類，一個是保持獨佔，另一個是控制時序。
對於第一類，我們將zookeeper上的一個znode看作是一把鎖，通過createznode的方式來實現。所有客戶端都去創建 /distribute_lock 節點，最終成功創建的那個客戶端也即擁有了這把鎖。廁所有言：來也沖沖，去也沖沖，用完刪除掉自己創建的distribute_lock 節點就釋放出鎖。
對於第二類， /distribute_lock 已經預先存在，所有客戶端在它下面創建臨時順序編號目錄節點，和選master一樣，編號最小的獲得鎖，用完刪除，依次方便。
5、隊列管理
Zookeeper 可以處理兩種類型的隊列：
（1）同步隊列：當一個隊列的成員都聚齊時，這個隊列纔可用，否則一直等待所有成員到達，這種是同步隊列。同步隊列用 Zookeeper 實現的實現思路如下：
創建一個父目錄 /synchronizing，每個成員都監控標誌（Set Watch）位目錄 /synchronizing/start 是否存在，然後每個成員都加入這個隊列，加入隊列的方式就是創建 /synchronizing/member_i 的臨時目錄節點，然後每個成員獲取 / synchronizing 目錄的所有目錄節點，也就是 member_i。判斷 i 的值是否已經是成員的個數，如果小於成員個數等待 /synchronizing/start 的出現，如果已經相等就創建 /synchronizing/start。
（2）FIFO 隊列：先進先出隊列，例如實現生產者和消費者模型。FIFO 隊列用 Zookeeper 實現思路如下：
實現的思路也非常簡單，就是在特定的目錄下創建 SEQUENTIAL 類型的子目錄 /queue_i，這樣就能保證所有成員加入隊列時都是有編號的，出隊列時通過 getChildren( ) 方法可以返回當前所有的隊列中的元素，然後消費其中最小的一個，這樣就能保證 FIFO。
三、產生背景
有這樣一個場景：系統中有大約100w的用戶，每個用戶平 均有3個郵箱賬號，每隔5分鐘，每個郵箱賬需要收取100封郵件，最多3億份郵件需要下載到服務器中(不含附件和正文)。用20臺機器劃分計算的壓力，從 多個不同的網路出口進行訪問外網，計算的壓力得到緩解，那麼每臺機器的計算壓力也不會很大了。
通過我們的討論和以往的經驗判斷在這場景中可以實現並行計算，但我們還期望能對並行計算的節點進行動態的添加/刪除，做到在線更新並行計算的數目並且不會影響計算單元中的其他計算節點，但是有4個問題需要解決，否則會出現一些嚴重的問題：
20臺機器同時工作時，有一臺機器down掉了，其他機器怎麼進行接管計算任務，否則有些用戶的業務不會被處理，造成用戶服務終斷。
隨着用戶數量增加，添加機器是可以解決計算的瓶頸，但需要重啓所有計算節點，如果需要，那麼將會造成整個系統的不可用。
用戶數量增加或者減少，計算節點中的機器會出現有的機器資源使用率繁忙，有的卻空閒，因爲計算節點不知道彼此的運行負載狀態。
怎麼去通知每個節點彼此的負載狀態，怎麼保證通知每個計算節點方式的可靠性和實時性。
先不說那麼多專業名詞，白話來說我們需要的是：1記錄狀態，2事件通知 ，3可靠穩定的中央調度器，4易上手、管理簡單。
採用Zookeeper完全可以解決我們的問題，分佈式計算中的協調員，觀察者，分佈式鎖 都可以作爲zookeeper的關鍵詞，在系統中利用Zookeeper來處理事件通知,隊列,優先隊列,鎖,共享鎖等功能，利用這些特色在分佈式計算中發揮重要的作用。
總結：
今天我們介紹了一下zookeeper，知道了它是一個文件系統+通知機制，這也就使它可以作爲dubbo的一個服務註冊機制來管理分佈式服務，而至於它的工作原理，我們將在下次博客中繼續說明，請大家繼續關注。