Zookeeper 和 Etcd 都是非常優秀的分佈式協調系統，zookeeper 起源於 Hadoop 生態系統，etcd 的流行是因爲它是 kubernetes 的後臺支撐。
本文將會說明 zookeeper 和 etcd 的優缺點，以便於您根據實際需求選擇更合適的分佈式協調系統。
1. Zookeeper
概述
zookeeper 起源於 Hadoop，後來進化爲 Apache 的頂級項目。現在已經被廣泛使用在 Apache 的項目中，例如 Hadoop，kafka，solr 等等。
zookeeper 使用 ZAB 協議作爲其一致性協議。 zookeeper 通過團隊的形式工作，一組 node 一起工作，來提供分佈式能力，這組 node 的數量需要是奇數。
第一個節點與其他節點溝通，選舉出一個 leader，獲取多數票數的成爲 leader，這就是爲什麼需要奇數個 node，其他節點被稱爲follower。
client 連接 zookeeper 時可以連接任何一個，client 的讀請求可以被任何一個節點處理，寫請求只能被 leader 處理。所以，添加新節點可以提高讀的速度，但不會提高寫的速度。
對於 CAP 模型，zookeeper 保障的是 CP。
ZNode
存儲數據時，zookeeper 使用樹形結構，其中的每個節點稱作 ZNode，訪問一個 ZNode 時，需要提供從 root 開始的絕對路徑。
每個 ZNode 可以存儲最多 1MB 的數據，用戶可以：
- 創建 ZNode
- 刪除 ZNode
- 存儲數據到指定 ZNode
- 從 ZNode 中讀取數據
zookeeper 還提供了一個非常重要的特性：watcher API。
zookeeper watches
用戶可以對一個 ZNode 設置 watch，當這個 ZNode 發生了變化時，例如 創建、刪除、數據變更、添加或移除子節點，watch API 就會發出通知，這是 zookeeper 非常重要的功能。
zookeeper 的 watch 有一個缺點，就是這個 watch 只能被觸發一次，一旦發出了通知，如果還想對這個節點繼續 watch，用戶需要重新設置 watch。
優點
- 非阻塞全部快照（達成最終一致）
- 高效的內存管理
- 高可靠
- API 簡單
- 連接管理可以自動重試
- ZooKeeper recipes 的實現是經過完整良好的測試的。
- 有一套框架使得寫新的 ZooKeeper recipes 非常簡單。
- 支持監聽事件
- 發生網絡分區時，各個區都會開始選舉 leader，那麼節點數少的那個分區將會停止運行。
缺點
- zookeeper 是 java 寫的，那麼自然就會繼承 java 的缺點，例如 GC 暫停。
- 如果開啓了快照，數據會寫入磁盤，此時 zookeeper 的讀寫操作會有一個暫時的停頓。
- 對於每個 watch 請求，zookeeper 都會打開一個新的 socket 連接，這樣 zookeeper 就需要實時管理很多 socket 連接，比較複雜。
etcd
概述
etcd 是用 go 開發的，出現的時間並不長，不像 zookeeper 那麼悠久和有名，但是前景非常好。
etcd 是因爲 kubernetes 而被人熟知的，kubernetes 的 kube master 使用 etcd 作爲分佈式存儲獲取分佈式鎖，這爲 etcd 的強大做了背書。
etcd 使用 RAFT 算法實現的一致性，比 zookeeper 的 ZAB 算法更簡單。
etcd 沒有使用 zookeeper 的樹形結構，而是提供了一個分佈式的 key-value 存儲。
特性：
- 原子性
- 一致性
- 順序一致性
- 可串行化級別
- 高可用
- 可線性化
API
etcd3 提供瞭如下操作接口：
- put - 添加一個新的 key-value 到存儲中
- get - 獲取一個 key 的 value
- range - 獲取一個範圍的 key 的 value，例如：key1 - key10
- transaction - 讀、對比、修改、寫的組合
- watch - 監控一個或一個範圍的 key，發生變化後就會得到通知
優點
- 支持增量快照，避免了 zookeeper 的快照暫停問題
- 堆外存儲，沒有垃圾回收暫停問題
- 無需像 zookeeper 那樣爲每個 watch 都做個 socket 連接，可以複用
- zookeeper 每個 watch 只能收到一次事件通知，etcd 可以持續監控，在一次 watch 觸發之後無需再次設置一次 watch
- zookeeper 會丟棄事件，etcd3 持有一個事件窗口，在 client 斷開連接後不會丟失所有事件
缺點
- 如果超時，或者 client 與 etcd 網絡中斷，client 不會明確的知道當前操作的狀態
- 在 leader 選舉時，etcd 會放棄操作，並且不會給 client 發送放棄響應
- 在網絡分區時，當 leader 處於小分區時，讀請求會繼續被處理
總結
zookeeper 是用 java 開發的，被 Apache 很多項目採用。
etcd 是用 go 開發的，主要是被 Kubernetes 採用。
zookeeper 非常穩定，是一個著名的分佈式協調系統，etcd 是後起之秀，前景廣闊。
因爲 etcd 是用 go 寫的，現在還沒有很好的 java 客戶端庫，需要通過 http 方式調用。
而 zookeeper 在這方面就成熟很多，對於 java 之外的其他開發語言都有很好的客戶端庫。
具體選擇 zookeeper 還是 etcd，需要根據您的需求結合它們各自的特性進行判斷，還有您所使用的開發語言。
翻譯整理自：
https://medium.com/@Imesha94/apache-curator-vs-etcd3-9c1362600b26
