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