Zookeeper應用場景之【資料釋出/訂閱】

yanke_shanghai發表於2016-06-02
場景描述：
釋出與訂閱模型，即所謂的配置中心，顧名思義就是釋出者將資料釋出到ZK節點上，供訂閱者動態獲取資料，實現配置資訊的集中式管理和動態更新。例如全域性的配置資訊，服務式服務框架的服務地址列表等就非常適合使用。

使用ZooKeeper的釋出與訂閱模型，可以將應用中用到的一些配置資訊放到ZK上進行集中管理。這類場景通常是這樣：應用在啟動的時候會主動來獲取一次配置，同時，在節點上註冊一個Watcher，這樣一來，以後每次配置有更新的時候，都會實時通知到訂閱的客戶端，從來達到獲取最新配置資訊的目的。這樣的場景適合資料量很小，但是資料更新可能會比較快的需求。

傳統配置方案：
1. 將配置資訊儲存在程式程式碼中
這種方案簡單，但每次修改配置都要重新編譯、部署應用程式。顯然這種方案很不方便，也不可靠，更無法做到修改的實時生效。

2. 將配置資訊儲存在xml檔案或者屬性檔案中
在引數資訊儲存在xml或者屬性檔案中，當需要修改引數時，直接修改 xml 檔案。這樣無需重新編譯，只需重新部署修改的檔案即可。但然後對所有的應用進行重新部署。這樣做的缺點顯而易見，要往上百臺機器上重新部署應用，簡直是一個噩夢。同時該方案還有一個缺點，就是配置修改無法做到實時生效。修改後往往過一段時間才能生效。

3. 將配置資訊儲存在資料庫中
當需要修改引數時，直接修改資料庫，然後重啟分散式應用程式，或者重新整理分散式應用的快取。儘管這種做法比以上兩種方案簡單，但卻面臨著單點失效問題。如果資料庫伺服器停機，則分散式應用程式的配置資訊將無法更新。另外這種方案的配置修改生效實時性雖然比第二種方案好些，但仍然不能達到某些情況下的要求。

基於Zookeeper的配置方案：

同一個應用系統需要多臺 PC Server 執行，但是它們執行的應用系統的某些配置項是相同的，如果要修改這些相同的配置項，那麼就必須同時修改每臺執行這個應用系統的 PC Server，這樣非常麻煩而且容易出錯。將配置資訊儲存在 Zookeeper 的某個目錄節點中，然後將所有需要修改的應用機器監控配置資訊的狀態，一旦配置資訊發生變化，每臺應用機器就會收到 Zookeeper 的通知，然後從 Zookeeper 獲取新的配置資訊應用到系統中。

Zookeeper很容易實現這種集中式的配置管理，比如將所需要的配置資訊放到/Configuration 節點上，叢集中所有機器一啟動就會通過Client對/Configuration這個節點進行監控【zk.exist("/Configuration″,true)】，並且實現Watcher回撥方法process()，那麼在zookeeper上/Configuration節點下資料發生變化的時候，每個機器都會收到通知，Watcher回撥方法將會被執行，那麼應用再取下資料即可【zk.getData("/Configuration″,false,null)】。

參考文獻：（1）《從paxos到zookeeper》（2）http://www.mamicode.com/info-detail-1164032.html

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/30316686/viewspace-2112898/，如需轉載，請註明出處，否則將追究法律責任。

相關文章