使用ZooKeeper實作配置同步前言ZooKeeper資料釋出與訂閱配置存儲方案基于ZooKeeper的配置資訊同步方案源代碼優點總結

應用項目中都會有一些配置資訊，這些配置資訊資料量少，一般會儲存到記憶體、檔案或者資料庫，有時候需要動态更新。當需要在多個應用伺服器中修改這些配置檔案時，需要做到快速、簡單、不停止應用伺服器的方式修改并同步配置資訊到所有應用中去。本篇文章就是介紹如何使用ZooKeeper來實作配置的動态同步。

資料釋出與訂閱（配置中心）

負載均衡

命名服務(Naming Service)

分布式通知/協調

叢集管理與Master選舉

分布式鎖

分布式隊列

一些線上系統在運作中，需要在不停止程式的情況下能夠動态調整某一個變量的值并且能夠及時生效。特别是當部署了多台應用伺服器的時候，需要能夠做到在一台機器上修改配置檔案，然後在同步到所有應用伺服器。這時候使用ZooKeeper來實作就很合适了。

釋出與訂閱模型，即所謂的配置中心，顧名思義就是釋出者将資料釋出到ZK節點上，供訂閱者動态擷取資料，實作配置資訊的集中式管理和動态更新。例如全局的配置資訊，服務式服務架構的服務位址清單等就非常适合使用。

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

配置檔案通常有如下幾種儲存方式：

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

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

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

如果使用ZooKeeper來實作，就可以直接把配置資訊儲存到ZooKeeper中，或者把屬性檔案内容儲存到ZooKeeper中，當屬性檔案内容發生變化時，就通知監聽者如應用程式去重新讀取配置檔案。

基于ZooKeeper的特性,借助ZooKeeper可以實作一個可靠的、簡單的、修改配置能夠實時生效的配置資訊存儲方案,整體的設計方案如圖：

整個配置資訊存儲方案由三部分組成:ZooKeeper伺服器叢集、配置管理程式、分布式應用程式。

ZooKeeper伺服器叢集存儲配置資訊,在伺服器上建立一個儲存資料的節點(建立節點操作);配置管理程式提供一個配置管理的UI界面或者指令行方式,使用者通過配置界面修改ZooKeeper伺服器節點上配置資訊(設定節點資料操作);分布式應用連接配接到ZooKeeper叢集上(建立ZooKeeper用戶端操作),監聽配置資訊的變化(使用擷取節點資料操作,并注冊一個watcher)。

當配置資訊發生變化時，分布式應用會更新程式中使用配置資訊。

借助 ZooKeeper我們實作的配置資訊存儲方案具有的優點如下:

簡單。盡管前期搭建ZooKeeper伺服器叢集較為麻煩,但是實作該方案後,修改配置整個過程變得簡單很多。使用者隻要修改配置,無需進行其他任何操作,配置自動生效。

可靠。ZooKeeper服務叢集具有無單點失效的特性,使整個系統更加可靠。即使ZooKeeper 叢集中的一台機器失效,也不會影響整體服務,更不會影響分布式應用配置資訊的更新。

實時。ZooKeeper的資料更新通知機制,可以在資料發生變化後,立即通知給分布式應用程式,具有很強的變化響應能力。

本文參考了網上的一些文章，給出了基于ZooKeeper的配置資訊同步方案,解決了傳統配置資訊同步方案的缺點如實時性差、可靠性差、複雜等。