原文地址：jm-blog.aliapp.com/?p=2561

本文主要是討論下兩個類似產品：ZooKeeper和Diamond在配置管理這個應用場景上的異同點。
Diamond，顧名思義，寄寓了開發人員對產品穩定性的厚望，希望它像鑽石一樣，提供穩定的配置訪問。Diamond是淘寶網Java中介軟體團隊的核心產品之一，服務於集團線上很多核心應用。目前已經開源，開源地址在：http://code.taobao.org/p/diamond/wiki/index/。

資料永續性

Diamond主要針對的是持久資料，這些資料有個共同的特點是：叢集中一批機器都會使用，但是資料的更新頻率不大，且希望diamond能夠永久儲存。
ZooKeeper即可以儲存持久資料，也可以儲存非持久資料。持久資料和diamond中的持久資料都類似，所謂的非持久資料是指這些資料的生命週期和資料建立者的會話生命週期繫結，一旦會話結束，那麼這些非持久資料也會被清除。

推拉模型

本質上，兩個產品都是“拉”模式的，即都是通過客戶端自己去伺服器獲取最新資料。具體實現上，兩個產品分別如下：
在Diamond中，客戶端每隔15s輪詢伺服器，比對資料是否更新，從而獲取最新資料。
在ZooKeeper中，則是通過客戶端對相應的資料path註冊Watcher，當資料有更新的時候，伺服器會有事件通知，注意，這個通知僅僅是告訴客戶端對應的資料有更新了，具體資料內容需要客戶端根據自己的情況來決定是否需要獲取最新資料。
因此在實時性方面，ZooKeeper比Diamond高一些。

伺服器資料儲存

在資料儲存上，ZooKeeper和Diamond差別比較大。
首先來看下Diamond的資料儲存。Diamond的資料儲存以mysql資料庫為中心，所有在mysql中的資料都是最新的，客戶端的所有寫請求，都會首先寫入資料庫，同時會dump資料到Server的本地檔案中，所有讀請求都是直接走這個靜態檔案。
在ZooKeeper中，所有執行時資料都是儲存在記憶體中，客戶端的所有讀寫操作都是針對這份記憶體資料來進行的。同時，記憶體中的資料，ZK會以快照的形式dump到指定檔案中去，配合事務日誌，幫助伺服器在下次重啟的時候，能夠載入正確的資料到記憶體中去。

資料模型

Diamond的資料都是以行組織的，這也更便於它使用mysql來管理資料。Diamond的基本資料結構包含dataid，group和content，根據group，可以將一組相關的資料組合起來。
ZooKeeper中，使用樹形結構來組織資料，每個節點型別於一個檔案系統的路徑，一個節點下面也可以建立多個子節點來規則一些相關的資料。

容災

在容災方面，diamond做得相當的完備：
1． 所有客戶端的讀請求，都是直接讀取伺服器端的本地靜態檔案，因此，即使資料庫掛了，都不會影響diamond的讀服務。而讀服務在所有使用diamond的應用場景中，佔到了絕大部分。
2． Diamond客戶端還儲存了資料的快照，客戶端每次從伺服器成功獲取資料後，都會把這份資料儲存到本地檔案系統中，稱為快照檔案。這個快照檔案是為了防止在伺服器無法獲取資料的時候，能夠在這個快照中獲取資料。
3． 客戶端還會有一個容災目錄，變個容災目錄是在伺服器完全不可用的時候，運維人員可以手動在這個容災目錄中建立相關目錄結構的資料，diamond就就會優先從這個目錄中獲取資料。
4. 說到這裡，我們就可以給diamond的資料獲取優先順序作一個總結：
首先都會從容災目錄中獲取資料——無法從容災目錄獲取資料的話，就通過網路到伺服器請求資料——如果無法從伺服器獲取資料，那麼就從本地的snapshot中獲取資料。
接下來看看ZooKeepe的容災，做得很少，只有以下一點：
1. ZooKeeper實現了paxos演算法，有效的解決了分散式單點問題。以一個3臺機器構成的叢集為例，任意一臺ZK掛掉，都不會影響叢集的資料一致性。
總結：在容災方面，diamond有很大的優勢，也符合了diamond的穩定性要求。

資料大小

Diamond對單個數據的大小，沒有嚴格的限制，通常2M左右的資料大小都是沒有問題的。而在ZooKeeper中，由於全量資料都是儲存在記憶體中，並且需求進行叢集機器間的資料兩步，所以對單個數據的大小有嚴格的限制，預設單個數據節點的最大資料大小是1M。

資料追加與聚合

Diamond支援對資料的追加與聚合功能，即對同一個dataid的寫入操作，可以設定為追加。而ZooKeeper目前不支援，只有覆蓋寫。