在一個分布式環(huán)境中，同類型的服務往往會部署很多實例。這些實例使用了一些配置，為了更好地維護這些配置就產(chǎn)生了配置管理服務。通過這個服務可以輕松地管理這些應用服務的配置問題。應用場景可概括為：
zookeeper的一種應用就是分布式配置管理(基于ZooKeeper的配置信息存儲方案的設計與實現(xiàn))。百度也有類似的實現(xiàn)：disconf。
Diamond則是淘寶開源的一種分布式配置管理服務的實現(xiàn)。Diamond本質(zhì)上是一個Java寫的Web應用，其對外提供接口都是基于HTTP協(xié)議的，在閱讀代碼時可以從實現(xiàn)各個接口的controller入手。
分布式配置管理
分布式配置管理的本質(zhì)基本上就是一種推送-訂閱模式的運用。配置的應用方是訂閱者，配置管理服務則是推送方。概括為下圖：
其中，客戶端包括管理人員publish數(shù)據(jù)到配置管理服務，可以理解為添加/更新數(shù)據(jù)；配置管理服務notify數(shù)據(jù)到訂閱者，可以理解為推送。
配置管理服務往往會封裝一個客戶端庫，應用方則是基于該庫與配置管理服務進行交互。在實際實現(xiàn)時，客戶端庫可能是主動拉取(pull)數(shù)據(jù)，但對于應用方而言，一般是一種事件通知方式。
Diamond中的數(shù)據(jù)是簡單的key-value結(jié)構。應用方訂閱數(shù)據(jù)則是基于key來訂閱，未訂閱的數(shù)據(jù)當然不會被推送。數(shù)據(jù)從類型上又劃分為聚合和非聚合。因為數(shù)據(jù)推送者可能很多，在整個分布式環(huán)境中，可能有多個推送者在推送相同key的數(shù)據(jù)，這些數(shù)據(jù)如果是聚合的，那么所有這些推送者推送的數(shù)據(jù)會被合并在一起；反之如果是非聚合的，則會出現(xiàn)覆蓋。
數(shù)據(jù)的來源可能是人工通過管理端錄入，也可能是其他服務通過配置管理服務的推送接口自動錄入。
架構及實現(xiàn)
Diamond服務是一個集群，是一個去除了單點的協(xié)作集群。如圖：
圖中可分為以下部分講解：
服務之間同步
Diamond服務集群每一個實例都可以對外完整地提供服務，那么意味著每個實例上都有整個集群維護的數(shù)據(jù)。Diamond有兩種方式保證這一點：
- 任何一個實例都有其他實例的地址；任何一個實例上的數(shù)據(jù)變更時，都會將改變的數(shù)據(jù)同步到mysql上，然后通知其他所有實例從mysql上進行一次數(shù)據(jù)拉取(
DumpService::dump)，這個過程只拉取改變了的數(shù)據(jù)
- 任何一個實例啟動后都會以較長的時間間隔（幾小時），從mysql進行一次全量的數(shù)據(jù)拉取(
DumpAllProcessor)
實現(xiàn)上為了一致性，通知其他實例實際上也包含自己。以服務器收到添加聚合數(shù)據(jù)為例，處理過程大致為：
DatumController::addDatum // /datum.do?method=addDatum
PersistService::addAggrConfigInfo
MergeDatumService::addMergeTask // 添加一個MergeDataTask，異步處理
MergeTaskProcessor::process
PersistService::insertOrUpdate
EventDispatcher.fireEvent(new ConfigDataChangeEvent // 派發(fā)一個ConfigDataChangeEvent事件
NotifyService::onEvent // 接收事件并處理
TaskManager::addTask(..., new NotifyTask // 由此，當數(shù)據(jù)發(fā)生變動，則最終創(chuàng)建了一個NoticyTask
// NotifyTask同樣異步處理
NotifyTaskProcessor::process
foreach server in serverList // 包含自己
notifyToDump // 調(diào)用 /notify.do?method=notifyConfigInfo 從mysql更新變動的數(shù)據(jù)
雖然Diamond去除了單點問題，不過問題都下降到了mysql上。但由于其作為配置管理的定位，其數(shù)據(jù)量就mysql的應用而言算小的了，所以可以一定程度上保證整個服務的可用性。
數(shù)據(jù)一致性
由于Diamond服務器沒有master，任何一個實例都可以讀寫數(shù)據(jù)，那么針對同一個key的數(shù)據(jù)則可能面臨沖突。這里應該是通過mysql來保證數(shù)據(jù)的一致性。每一次客戶端請求寫數(shù)據(jù)時，Diamond都將寫請求投遞給mysql，然后通知集群內(nèi)所有Diamond實例（包括自己）從mysql拉取數(shù)據(jù)。當然，拉取數(shù)據(jù)則可能不是每一次寫入都能拉出來，也就是最終一致性。
Diamond中沒有把數(shù)據(jù)放入內(nèi)存，但會放到本地文件。對于客戶端的讀操作而言，則是直接返回本地文件里的數(shù)據(jù)。
服務實例列表
Diamond服務實例列表是一份靜態(tài)數(shù)據(jù)，直接將每個實例的地址存放在一個web server上。無論是Diamond服務還是客戶端都從該web server上取出實例列表。
對于客戶端而言，當其取出了該列表后，則是隨機選擇一個節(jié)點(ServerListManager.java)，以后的請求都會發(fā)往該節(jié)點。
數(shù)據(jù)同步
客戶端庫中以固定時間間隔從服務器拉取數(shù)據(jù)(ClientWorker::ClientWorker，ClientWorker::checkServerConfigInfo)。只有應用方關心的數(shù)據(jù)才可能被拉取。另外，為了數(shù)據(jù)推送的及時，Diamond還使用了一種long polling的技術，其實也是為了突破HTTP協(xié)議的局限性。如果整個服務是基于TCP的自定義協(xié)議，客戶端與服務器保持長連接則沒有這些問題。
數(shù)據(jù)的變更
Diamond中很多操作都會檢查數(shù)據(jù)是否發(fā)生了變化。標識數(shù)據(jù)變化則是基于數(shù)據(jù)對應的MD5值來實現(xiàn)的。
容災
在整個Diamond系統(tǒng)中，幾個角色為了提高容災性，都有自己的緩存，概括為下圖：
每一個角色出問題時，都可以盡量保證客戶端對應用層提供服務。
參考文檔