上篇博文描述了基於ZooKeeper構建互聯網大規模配置系統的基本概念，並對ZooKeeper做了簡單的介紹。這裏談談ZooKeeper的一些關鍵技術以及用ZooKeeper構建大規模配置系統的細節，最後講述我們在構建系統過程中的遇到問題及其解決思路，僅作參考，希望對您有所幫助。
提到zookeeper，我們不得不提起Paoxs算法和LesileLamport。Paoxs算法是zookeeper的靈魂，這個算法是Leslie Lamport在1990年提出的一種基於消息傳遞的一致性算法。Paxos 算法解決的問題是一個分佈式系統就某個值達成一致。典型的場景就決定zookeeper中的leader。算法具體可參見http：//zh.wikipedia.org/zh-cn/Paxos%E7%AE%97%E6%B3%95
集中式的配置管理在應用集羣中是非常常見的，一般公司都會實現一套集中的配置管理中心，應對不同的應用集羣對於共享各自配置的需求，並且在配置變更時能夠通知到集羣中的每一個機器。應用Zookeeper很容易實現這種集中式的配置管理，比如將APP1的所有配置配置到/APP1這個節點下，APP1所有機器一啓動就對/APP1這個節點進行監控，並且實現回調方法Watcher，那麼在zookeeper上/APP1下節點數據發生變化的時候，每個Client機器都會收到通知，Watcher方法將會被執行。以上這個例子只是簡單的粗顆粒度配置監控，細顆粒度的數據可以進行分層級監控，這一切都是可以設計和控制。它的具體示例圖如下：
如圖中/APP1目錄下就項目APP1所有配置的信息，每個配置都是一個節點。Watch就是應用ZooKeeper來監控APP1節點數據變化。Watch可以理解爲一個分佈式的回調，當client關心的節點發生變化時，zookeeper將會把消息傳回到client，並導致client的消息處理函數得到調用。zk的任何一個讀操作都能夠設置watch，例如：getData()，
getChildren()， exists()
可以watch的event包括如下的二種：
n KeeperState：Disconnected、SyncConnected、Expired
n EventType：None、NodeCreated、NodeDeleted、NodeDataChanged、NodeChildrenChanged
Zookeeper的使用主要是通過創建其jar包下的Zookeeper實例，並且調用其接口方法進行的，主要的操作就是對節點的增、刪、改操作，監聽數據節點的變化以及處理。它的簡單示例如下圖所示：
上面對ZooKeeper的一些基本常識以及基本編程方法，下面談談我們在搭建集羣配置系統中遇到的兩個主要問題，以及它的解決思路。
問題1：ZooKeeper的session超時問題。
超時問題是任何分佈式應用程序都需要考慮到的問題，ZooKeeper也不例外。由於網絡中斷一段時間，當它自動恢復過來時候，如果這段時間大於設置的Session超時時間，此時就會產生超時異常。ZooKeeper客戶端和服務器是基於長連接的方式，並用心跳保持連接，一旦遇到超時問題，這個連接就無效了。一般解決思路大致有如下三種：
l 在程序中顯式用try和Catch主動獲取超時異常，然後將客戶端和服務器重新連接，前提是在您應用程序中要緩存一些重新連接需要的屬性。
l 在程序中啓動一個後臺線程和ZooKeeper服務器進行通信，這個線程可以做數據的同步，同時也起到一個心跳作用。當檢查到超時異常，程序重新連接ZooKeeperServer。
l 最優雅的一種方式，監控ZooKeeper最上層的父節點，當遇到超時異常時，此Watch的回調方法的參數event的屬性KeepState包括了Expired，也就是超時異常，在此你可以重新連接服務器。
問題2：ZooKeeper和應用程序數據同步問題。
ZooKeeper會協調應用程序的配置的一致性。但是應用程序是否需要始終需要獲取配置的最新信息呢？顯然不是。一個程序對外提供服務，它可能部署在10臺機器上。當它有了新版本更新時，它的一些配置需要重新修改。項目版本更新時，總是先停掉部分機器，一批批的進行版本更新。如果項目始終獲取的最新的配置信息時候，一些老版本項目會獲取最新配置導致運行出錯。這樣的思路一般解決思路有如下：
l ZooKeeper是的節點是帶版本信息，項目一個版本可以和節點的一個版本進行對應。
l 將修改配置分爲兩種情況：修改ZooKeeper服務器配置，但是客戶端已經運行配置不做修改；在修改ZooKeeper服務器配置，同時修改客戶端的配置。