Zookeeper vs Etcd

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/...