雲計算越來越流行的今天，單一機器處理能力已經不能滿足我們的需求，不得不採用大量的服務集羣。服務集羣對外提供服務的過程中，有很多的配置需要隨時更新，服務間需要協調工作，這些信息如何推送到各個節點？並且保證信息的一致性和可靠性？
衆所周知，分佈式協調服務很難正確無誤的實現，它們很容易在競爭條件和死鎖上犯錯誤。如何在這方面節省力氣？Zookeeper是一個不錯的選擇。Zookeeper背後的動機就是解除分佈式應用在實現協調服務上的痛苦。本文在介紹Zookeeper的基本理論基礎上，用Zookeeper實現了一個配置管理中心，利用Zookeeper將配置信息分發到各個服務節點上，並保證信息的正確性和一致性。
Zookeeper是什麼？
引用官方的說法：“Zookeeper是一個高性能，分佈式的，開源分佈式應用協調服務。它提供了簡單原始的功能，分佈式應用可以基於它實現更高級的服務，比如同步，配置管理，集羣管理，名空間。它被設計爲易於編程，使用文件系統目錄樹作爲數據模型。服務端跑在java上，提供java和C的客戶端API”。
Zookeeper總體結構
Zookeeper服務自身組成一個集羣(2n+1個服務允許n個失效)。Zookeeper服務有兩個角色，一個是leader，負責寫服務和數據同步，剩下的是follower，提供讀服務，leader失效後會在follower中重新選舉新的leader。
Zookeeper邏輯圖如下，
1.客戶端可以連接到每個server，每個server的數據完全相同。
2.每個follower都和leader有連接，接受leader的數據更新操作。
3.Server記錄事務日誌和快照到持久存儲。
4.大多數server可用，整體服務就可用。
Zookeeper數據模型
Zookeeper表現爲一個分層的文件系統目錄樹結構（不同於文件系統的是，節點可以有自己的數據，而文件系統中的目錄節點只有子節點）。
數據模型結構圖如下，
圓形節點可以含有子節點，多邊形節點不能含有子節點。一個節點對應一個應用，節點存儲的數據就是應用需要的配置信息。
Zookeeper 特點
順序一致性：按照客戶端發送請求的順序更新數據。
原子性：更新要麼成功，要麼失敗，不會出現部分更新。
單一性 ：無論客戶端連接哪個server，都會看到同一個視圖。
可靠性：一旦數據更新成功，將一直保持，直到新的更新。
及時性：客戶端會在一個確定的時間內得到最新的數據。
Zookeeper運用場景
1.數據發佈與訂閱 （我的業務用到這個特性，後面會有詳細介紹）
應用配置集中到節點上，應用啓動時主動獲取，並在節點上註冊一個watcher，每次配置更新都會通知到應用。
2.名空間服務
分佈式命名服務，創建一個節點後，節點的路徑就是全局唯一的，可以作爲全局名稱使用。
3.分佈式通知/協調
不同的系統都監聽同一個節點，一旦有了更新，另一個系統能夠收到通知。
4.分佈式鎖
Zookeeper能保證數據的強一致性，用戶任何時候都可以相信集羣中每個節點的數據都是相同的。一個用戶創建一個節點作爲鎖，另一個用戶檢測該節點，如果存在，代表別的用戶已經鎖住，如果不存在，則可以創建一個節點，代表擁有一個鎖。
5.集羣管理
每個加入集羣的機器都創建一個節點，寫入自己的狀態。監控父節點的用戶會受到通知，進行相應的處理。離開時刪除節點，監控父節點的用戶同樣會收到通知。
Zookeeper在我們業務邏輯上的運用
我們公司做極光推送，Push 業務平臺有大量的邏輯服務器，按業務類型分組。邏輯服務的運行依賴於配置，並且配置會在線調整，需要一個集中的配置項管理中心。Zookeeper的發佈與訂閱特性以及發送更新通知的機制很好的滿足了我們的需求。Zookeeper的容災特性也免去了我們相關的大量管理工作。
下面我主要和大家分享一下Zookeeper在我們內部服務中的應用。
a. 我們的邏輯服務器包含兩類配置。
一種爲Acl（訪問控制列表），用戶的消息消費後，按照列表中的條件走向下一個邏輯服務器。另一種只是單獨的算法邏輯的外提，稱爲Agl（訪問算法列表），但是其中某些判斷條件會經常變化。這兩類配置被收集到了配置管理中心（即Zookeeper）。
邏輯圖如下，
用戶編輯好策略配置信息（xml格式），通過客戶端加載到Zookeeper。Zookeeper立即通知其下的邏輯服務器（BLx），邏輯服務器下載最新的配置策略，並應用新的策略。新的策略有可能改變某一段id範圍內用戶的數據流向，或越過原來的邏輯服務器，或指向新加入的邏輯服務器。
b. 數據模型設計
同一類型的邏輯服務在Zookeeper上創建一個節點，共享相同的配置信息。
該節點下面爲策略配置項，分爲Acl和Agl兩類，如下圖：（以代理邏輯服務爲例）
Acl1, Acl2, Acl3, Agl1, Agl2分別存有策略配置信息。變化後會通知監聽Proxy節點的邏輯服務器，Proxy邏輯服務器下載最新策略，並應用該策略。新節點的加入和退出也會通知到Proxy邏輯服務器。
c. 業務處理流程如下圖
1.邏輯服務監聽自己類型節點（本例如前圖Proxy節點）
2.編輯新策略,加載策略到Zookeeper（策略保存在Proxy/Acls/Acl[1..n]，或Proxy/Agls/Agl1[1..n]）
3.Zookeeper通知各邏輯節點
4.各邏輯節點下載新策略到本地，並應用新策略