本文翻譯自 https://etcd.io/docs/v3.4.0/learning/why/
關於 etcd
本文的主角是 etcd。名稱 “etcd” 源自兩個想法，即 unix “/etc” 文件夾 和 “d” 分佈式系統。“/etc” 文件夾是用於存儲單個系統的配置數據的位置，而 etcd 用於存儲大規模分佈式的配置信息。因此，分配了 “d” 的 “/etc” 就是 “etcd”。
etcd 被設計爲大型分佈式系統的通用基板。這些大型系統需要避免腦裂，並且願意犧牲可用性來實現此目的。etcd 以一致且容錯的方式存儲元數據。etcd 集羣旨在提供具有穩定性、可靠性、可伸縮性和性能的鍵值存儲。
分佈式系統將 etcd 用作配置管理、服務發現和協調分佈式工作的一致鍵值存儲組件。許多組織在生產系統上使用 etcd，例如容器調度程序、服務發現服務和分佈式數據存儲。使用 etcd 的常見分佈式模式包括領導者選舉、分佈式鎖和監視機器活動狀態等。
使用案例
CoreOS 的 Container Linux：在 Container Linux 上運行的應用程序將獲得零停機時間的 Linux 內核自動更新。Container Linux 使用鎖來協調更新。Locksmith 在 etcd上 實現了一個分佈式信號量，以確保在任何給定時間僅集羣的一個子集正在重啓。
Kubernetes 將配置數據存儲到 etcd 中以進行服務發現和集羣管理；etcd的一致性對於容器的編排至關重要。Kubernetes API 服務器將羣集狀態持久保存到 etcd 中。它使用 etcd 的 watch API 監視集羣並回滾關鍵的配置更改。
多維度對比
也許 etcd 已經看起來很合適，但是與所有技術選型一樣，我們需要謹慎進行。儘管理想的情況是對技術和功能進行客觀的比較，但是作者的專業知識和偏見顯然傾向於etcd（實驗和文檔由etcd的作者編寫）。
下表是一目瞭然的快速參考，可發現 etcd 及其最受歡迎的替代方案之間的差異。表格後面的各節中提供了每列的進一步說明和詳細信息。
與 ZooKeeper
ZooKeeper 解決了與 etcd 相同的問題：分佈式系統協調和元數據存儲。但是， etcd 踩在前人的肩膀上，其參考了 ZooKeeper 的設計和實現經驗。從 Zookeeper 汲取的經驗教訓無疑爲 etcd 的設計提供了支撐，從而幫助其支持 Kubernetes 等大型系統。對 Zookeeper 進行的 etcd 改進包括：
動態重新配置集羣成員
高負載下穩定的讀寫
多版本併發控制數據模型
可靠的鍵值監控
租期原語將 session 中的連接解耦
用於分佈式共享鎖的 API
此外，etcd 開箱即用地支持多種語言和框架。Zookeeper 擁有自己的自定義Jute RPC 協議，該協議對於 Zookeeper 而言是完全唯一的，並限制了其受支持的語言綁定，而 etcd 的客戶端協議則是基於 gRPC 構建的，gRP 是一種流行的 RPC 框架，具有 go，C ++，Java 等語言支持。同樣，gRPC 可以通過 HTTP 序列化爲 JSON，因此即使是通用命令行使用程序（例如curl）也可以與之通信。由於系統可以從多種選擇中進行選擇，因此它們是基於具有本機工具的 etcd 構建的，而不是基於一組固定的技術圍繞 etcd 構建的。
在考慮功能，支持和穩定性時，etcd 相比於 Zookeeper，更加適合用作一致性的鍵值存儲的組件。
Consul
Consul 是一個端到端的服務發現框架。它提供內置的運行狀況檢查，故障檢測和 DNS 服務。此外，Consul 還使用 RESTful HTTP API 公開了密鑰值存儲。在 Consul 1.0 中，存儲系統在鍵值操作中無法像 etcd 或 Zookeeper 等其他組件那樣擴展。數百萬個鍵的系統將遭受高延遲和內存壓力。Consul 最明顯的是缺少多版本鍵，條件事務和可靠的流監視。
etcd 和 Consul 解決了不同的問題。如果要尋找分佈式一致鍵值存儲，那麼與 Consul 相比，etcd是更好的選擇。如果正在尋找端到端的集羣服務發現，etcd 將沒有足夠的功能。可以選擇 Kubernetes，Consul或 SmartStack。
NewSQL(Cloud Spanner, CockroachDB, TiDB)
etcd 和 NewSQL 數據庫（例如Cockroach，TiDB，Google Spanner）都提供了具有高可用性的強大數據一致性保證。但是，不同的系統設計思路導致顯著不同的客戶端 API 和性能特徵。
NewSQL 數據庫旨在跨數據中心水平擴展。這些系統通常跨多個一致的複製組（分片）對數據進行分區，這些複製組可能相距很遠，並以 TB 或更高級別存儲數據集。這種縮放比例使它們成爲分佈式協調的較差候選者，因爲它們需要很長的等待時間，並且期望使用大多數本地化的依賴拓撲進行更新。NewSQL 數據被組織成表格，包括具有比 etcd 更爲豐富的語義的 SQL 樣式的查詢工具，但是以處理和優化查詢的額外複雜性爲代價。
簡而言之，選擇 etcd 來存儲元數據或協調分佈式應用程序。如果存儲的數據超過數 GB，或者需要完整的 SQL 查詢，請選擇 NewSQL 數據庫。
使用 etcd 存儲元配置數據
etcd 在單個複製組中複製所有數據。對於以一致的順序存儲多達幾 GB 的數據，這是最有效的方法。集羣狀態的每次修改（可能會更改多個鍵）都從一個單調遞增的計數器中分配了一個全局唯一 ID（在etcd中稱爲修訂版），以進行排序。由於只有一個複製組，因此修改請求只需通過 raft 協議提交。通過將共識限制在一個複製組中，etcd 使用簡單的協議即可獲得分佈式一致性，同時實現低延遲和高吞吐量。
etcd 後面的複製無法水平擴展，因爲它缺少數據分片。相反，NewSQL 數據庫通常在多個一致的複製組之間分片數據，存儲數據集的級別爲 TB 或更高。但是，要爲每個修改分配一個全局唯一且遞增的 ID，每個請求必須通過複製組之間的附加協調協議。這個額外的協調步驟可能會在全局 ID 上發生衝突，從而強制有序的請求重試。結果是，對於嚴格的一致性，NewSQL 方法的性能通常比 etcd 更復雜。
如果應用程序主要是出於元數據或元數據排序的原因（例如協調流程），請選擇etcd。如果應用程序需要跨多個數據中心的大型數據存儲，並且在很大程度上不依賴於強大的全局排序屬性，請選擇 NewSQL 數據庫。
使用 etcd 作爲分佈式協調組件
etcd 具有分佈式協調原語，例如事件監視，租約，選舉和開箱即用的分佈式鎖。這些原語由 etcd 開發人員維護和支持；將這些功能留給承擔了開發基礎分佈式軟件的外部庫，實質上使系統不完整。NewSQL 數據庫通常期望這些分佈式協調原語由第三方編寫。同樣，ZooKeeper 有一個獨立的協調庫。提供本地鎖 API 的 Consul 甚至對 “不是防彈方法” 深表歉意（1個client釋放鎖之後，其它client無法立刻獲得鎖，這可能是由於lock-delay設置引起的。）。
從理論上講，可以在提供強一致性的任何存儲系統上構建這些原語。但是，算法往往很微妙。很容易開發出一種看起來有效的鎖定算法，但是由於邊界和時序偏差而中斷。此外，etcd 支持的其他原語（例如事務性存儲器）取決於 etcd 的 MVCC 數據模型；簡單的強一致性是不夠的。
對於分佈式協調，選擇 etcd 可以幫助避免操作上的麻煩並減少工作量。
