【ZooKeeper Notes 30】ZooKeeper與Diamond有什麼不同

轉載請註明：@ni掌櫃 nileader@gmail.com

   本文主要是討論下兩個相似產品：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目前不支持，只有覆蓋寫。