數據發布和訂閱

也就是常用的配置管理，將數據信息發布到一個或者多個ZK節點上，應用程序監聽這些節點當有數據變化時就獲取這些變化並應用到程序中，實現動態更新配置的功能。發布訂閱中通常有推拉兩種模式，ZK采用推拉結合，客戶端註冊感興趣的節點，一旦節點發生變化服務器會發出Watcher事件通知（推），然後客戶端收到消息後主動去服務器提取變化（拉）。

這種配置管理通常應用在具有配置通用性的場景中，比如機器列表、某些參數的開關或者數據庫配置信息等。

• 這些信息通常體量小

• 在應用運行時會隨時調整

• 這些應用（至少是某一組應用）都使用相同的配置

常規解決辦法是本地配置文件或者內存變量（通過JMX方式對正在運行的JAVA程序進行修改）。這些常規辦法在集群規模較小的時候比較方便但是集群規模一大管理就比較困難。

比如數據庫配置信息變化

• 首先在ZK上創建一個節點叫做 /Configuration 這裏面有一個APP名稱節點表示特定APP，這個APP名稱節點下面有一個叫做 dbConfig的節點用於存儲數據庫配置信息（/Configuration-->APP1-->dbConfig）

• 然後將配置信息寫入到這個節點（這些信息肯定是序列化後寫入的，如果在程序中不是以對象形式存在也可以不用序列化）

• 應用程序啟動後讀取這個節點數據，然後在這個節點上註冊一個Watcher事件，當數據有變化時再次讀取該節點數據並應用到自己的程序上。

負載均衡

ZK提供的負載屬於軟負載均衡服務。通常的做法就是動態的DNS服務，如果你的機器數量比較少你可以手動在內網DNS上配置這些域名，你要知道一個域名就對應一個IP。如果集群規模比較大手動維護這些信息相當繁瑣；另外你還可以采用HOST的方式就是在服務器上配置本地HOST把這些域名寫進去，還是一樣的問題規模小傳統方式都很好用，但是規模大尤其是有時候需要動態擴容或者縮容的時候你再去手動維護這些HOST或者DNS記錄顯然就不能滿足業務需求。

在Zookeeper中如何解決呢？下面的名稱就是名字不一定你也這樣取，畢竟節點名稱是自定義的。

• 首先建立一個節點叫做 /DDNS 這下面包含所有應用的名字比如APP1，APP2等，每個應用名字節點下面又一個域名比如 app1.servers.abc.com這樣一個域名（/DDNS-->APP1-->app1.servers.abc.com）後面這個域名就是改APP1集群使用的，這個節點包含的數據可以是IP:PORT或者多個IP:PORT，看下圖

• 的
  

Zookeeper詳解（六）：Zookeeper的應用場景