關(guān)于 etcd

本文的主角是 etcd。名稱 “etcd” 源自兩個想法，即 unix “/etc” 文件夾 和 “d” 分布式系統(tǒng)。“/etc” 文件夾是用于存儲單個系統(tǒng)的配置數(shù)據(jù)的位置，而 etcd 用于存儲大規(guī)模分布式的配置信息。因此，分配了 “d” 的 “/etc” 就是 “etcd”。

etcd 被設(shè)計(jì)為大型分布式系統(tǒng)的通用基板。這些大型系統(tǒng)需要避免裂腦操作，并且愿意犧牲可用性來實(shí)現(xiàn)此目的。 etcd 以一致且容錯的方式存儲元數(shù)據(jù)。 etcd 集群旨在提供具有穩(wěn)定性、可靠性、可伸縮性和性能的鍵值存儲。

分布式系統(tǒng)將 etcd 用作配置管理、服務(wù)發(fā)現(xiàn)和協(xié)調(diào)分布式工作的一致鍵值存儲組件。許多組織在生產(chǎn)系統(tǒng)上使用 etcd，例如容器調(diào)度程序、服務(wù)發(fā)現(xiàn)服務(wù)和分布式數(shù)據(jù)存儲。使用 etcd 的常見分布式模式包括領(lǐng)導(dǎo)者選舉、分布式鎖和監(jiān)視機(jī)器活動狀態(tài)等。

使用案例

CoreOS 的 Container Linux：在 Container Linux 上運(yùn)行的應(yīng)用程序?qū)@得零停機(jī)時間的 Linux 內(nèi)核自動更新。Container Linux 使用鎖來協(xié)調(diào)更新。 Locksmith 在 etcd上 實(shí)現(xiàn)了一個分布式信號量，以確保在任何給定時間僅集群的一個子集正在重啟。

Kubernetes 將配置數(shù)據(jù)存儲到 etcd 中以進(jìn)行服務(wù)發(fā)現(xiàn)和集群管理；etcd的一致性對于容器的編排至關(guān)重要。 Kubernetes API 服務(wù)器將群集狀態(tài)持久保存到 etcd 中。它使用 etcd 的 watch API 監(jiān)視集群并回滾關(guān)鍵的配置更改。

多維度對比

也許 etcd 已經(jīng)看起來很合適，但是與所有技術(shù)選型一樣，我們需要謹(jǐn)慎進(jìn)行。盡管理想的情況是對技術(shù)和功能進(jìn)行客觀的比較，但是作者的專業(yè)知識和偏見顯然傾向于etcd（實(shí)驗(yàn)和文檔由etcd的作者編寫）。

下表是一目了然的快速參考，可發(fā)現(xiàn) etcd 及其最受歡迎的替代方案之間的差異。 表格后面的各節(jié)中提供了每列的進(jìn)一步說明和詳細(xì)信息。

與 ZooKeeper

ZooKeeper 解決了與 etcd 相同的問題：分布式系統(tǒng)協(xié)調(diào)和元數(shù)據(jù)存儲。但是， etcd 踩在前人的肩膀上，其參考了 ZooKeeper 的設(shè)計(jì)和實(shí)現(xiàn)經(jīng)驗(yàn)。從 Zookeeper 汲取的經(jīng)驗(yàn)教訓(xùn)無疑為 etcd 的設(shè)計(jì)提供了支撐，從而幫助其支持 Kubernetes 等大型系統(tǒng)。對 Zookeeper 進(jìn)行的 etcd 改進(jìn)包括：

動態(tài)重新配置集群成員

高負(fù)載下穩(wěn)定的讀寫

多版本并發(fā)控制數(shù)據(jù)模型

可靠的鍵值監(jiān)控

租期原語將 session 中的連接解耦

用于分布式共享鎖的 API

此外，etcd 開箱即用地支持多種語言和框架。Zookeeper 擁有自己的自定義Jute RPC 協(xié)議，該協(xié)議對于 Zookeeper 而言是完全唯一的，并限制了其受支持的語言綁定，而 etcd 的客戶端協(xié)議則是基于 gRPC 構(gòu)建的，gRP 是一種流行的 RPC 框架，具有 go，C ++，Java 等語言支持。同樣，gRPC 可以通過 HTTP 序列化為 JSON，因此即使是通用命令行實(shí)用程序（例如curl）也可以與之通信。由于系統(tǒng)可以從多種選擇中進(jìn)行選擇，因此它們是基于具有本機(jī)工具的 etcd 構(gòu)建的，而不是基于一組固定的技術(shù)圍繞 etcd 構(gòu)建的。

在考慮功能，支持和穩(wěn)定性時，etcd 相比于 Zookeeper，更加適合用作一致性的鍵值存儲的組件。

Consul

Consul 是一個端到端的服務(wù)發(fā)現(xiàn)框架。它提供內(nèi)置的運(yùn)行狀況檢查，故障檢測和 DNS 服務(wù)。此外，Consul 還使用 RESTful HTTP API 公開了密鑰值存儲。在 Consul 1.0 中，存儲系統(tǒng)在鍵值操作中無法像 etcd 或 Zookeeper 等其他組件那樣擴(kuò)展。數(shù)百萬個鍵的系統(tǒng)將遭受高延遲和內(nèi)存壓力。Consul 最明顯的是缺少多版本鍵，條件事務(wù)和可靠的流監(jiān)視。

etcd 和 Consul 解決了不同的問題。如果要尋找分布式一致鍵值存儲，那么與 Consul 相比，etcd是更好的選擇。如果正在尋找端到端的集群服務(wù)發(fā)現(xiàn)，etcd 將沒有足夠的功能。可以選擇 Kubernetes，Consul或 SmartStack。

NewSQL(Cloud Spanner, CockroachDB, TiDB)

etcd 和 NewSQL 數(shù)據(jù)庫（例如Cockroach，TiDB，Google Spanner）都提供了具有高可用性的強(qiáng)大數(shù)據(jù)一致性保證。但是，不同的系統(tǒng)設(shè)計(jì)思路導(dǎo)致顯著不同的客戶端 API 和性能特征。

NewSQL 數(shù)據(jù)庫旨在跨數(shù)據(jù)中心水平擴(kuò)展。這些系統(tǒng)通?？缍鄠€一致的復(fù)制組（分片）對數(shù)據(jù)進(jìn)行分區(qū)，這些復(fù)制組可能相距很遠(yuǎn)，并以 TB 或更高級別存儲數(shù)據(jù)集。這種縮放比例使它們成為分布式協(xié)調(diào)的較差候選者，因?yàn)樗鼈冃枰荛L的等待時間，并且期望使用大多數(shù)本地化的依賴拓?fù)溥M(jìn)行更新。NewSQL 數(shù)據(jù)被組織成表格，包括具有比 etcd 更為豐富的語義的 SQL 樣式的查詢工具，但是以處理和優(yōu)化查詢的額外復(fù)雜性為代價(jià)。

簡而言之，選擇 etcd 來存儲元數(shù)據(jù)或協(xié)調(diào)分布式應(yīng)用程序。如果存儲的數(shù)據(jù)超過數(shù) GB，或者需要完整的 SQL 查詢，請選擇 NewSQL 數(shù)據(jù)庫。

使用 etcd 存儲元配置數(shù)據(jù)

etcd 在單個復(fù)制組中復(fù)制所有數(shù)據(jù)。對于以一致的順序存儲多達(dá)幾 GB 的數(shù)據(jù)，這是最有效的方法。集群狀態(tài)的每次修改（可能會更改多個鍵）都從一個單調(diào)遞增的計(jì)數(shù)器中分配了一個全局唯一 ID（在etcd中稱為修訂版），以進(jìn)行排序。由于只有一個復(fù)制組，因此修改請求只需通過 raft 協(xié)議提交。通過將共識限制在一個復(fù)制組中，etcd 使用簡單的協(xié)議即可獲得分布式一致性，同時實(shí)現(xiàn)低延遲和高吞吐量。

etcd 后面的復(fù)制無法水平擴(kuò)展，因?yàn)樗鄙贁?shù)據(jù)分片。相反，NewSQL 數(shù)據(jù)庫通常在多個一致的復(fù)制組之間分片數(shù)據(jù)，存儲數(shù)據(jù)集的級別為 TB 或更高。但是，要為每個修改分配一個全局唯一且遞增的 ID，每個請求必須通過復(fù)制組之間的附加協(xié)調(diào)協(xié)議。這個額外的協(xié)調(diào)步驟可能會在全局 ID 上發(fā)生沖突，從而強(qiáng)制有序的請求重試。結(jié)果是，對于嚴(yán)格的一致性，NewSQL 方法的性能通常比 etcd 更復(fù)雜。

如果應(yīng)用程序主要是出于元數(shù)據(jù)或元數(shù)據(jù)排序的原因（例如協(xié)調(diào)流程），請選擇etcd。如果應(yīng)用程序需要跨多個數(shù)據(jù)中心的大型數(shù)據(jù)存儲，并且在很大程度上不依賴于強(qiáng)大的全局排序?qū)傩?，請選擇 NewSQL 數(shù)據(jù)庫。

使用 etcd 作為分布式協(xié)調(diào)組件

etcd 具有分布式協(xié)調(diào)原語，例如事件監(jiān)視，租約，選舉和開箱即用的分布式鎖。這些原語由 etcd 開發(fā)人員維護(hù)和支持；將這些功能留給承擔(dān)了開發(fā)基礎(chǔ)分布式軟件的外部庫，實(shí)質(zhì)上使系統(tǒng)不完整。 NewSQL 數(shù)據(jù)庫通常期望這些分布式協(xié)調(diào)原語由第三方編寫。同樣，ZooKeeper 有一個獨(dú)立的協(xié)調(diào)庫。提供本地鎖 API 的 Consul 甚至對 “不是防彈方法” 深表歉意（1個client釋放鎖之后，其它c(diǎn)lient無法立刻獲得鎖，這可能是由于lock-delay設(shè)置引起的。）。

從理論上講，可以在提供強(qiáng)一致性的任何存儲系統(tǒng)上構(gòu)建這些原語。但是，算法往往很微妙。很容易開發(fā)出一種看起來有效的鎖定算法，但是由于邊界和時序偏差而中斷。此外，etcd 支持的其他原語（例如事務(wù)性存儲器）取決于 etcd 的 MVCC 數(shù)據(jù)模型；簡單的強(qiáng)一致性是不夠的。

對于分布式協(xié)調(diào)，選擇 etcd 可以幫助避免操作上的麻煩并減少工作量。