ETCD Performance

理解效能

etcd 提供穩定、持續的高效能。有兩個因素定義了效能：延遲 (latency) 和吞吐量 (throughput) :

• 延遲是完成一個操作所需的時間。
• 吞吐量是在某個時間段內完成的總操作數。

通常，當 etcd 接受並發的客戶端請求時，平均延遲會隨著整體吞吐量的增加而增加。在常見的雲端環境中，例如 Google Compute Engine (GCE) 上的標準 n-4 機器或 AWS 上同等級的機器類型，一個三成員的 etcd 叢集在輕度負載下，能於一毫秒內完成請求，並可在重度負載下每秒完成超過 30,000 個請求。

etcd 使用 Raft 共識演算法在成員之間複製請求並達成共識。共識效能，尤其是提交延遲 (commit latency)，受到兩個物理限制：網路 IO 延遲和磁碟 IO 延遲。完成一個 etcd 請求的最短時間是成員之間的網路來回時間 (RTT)，加上 fdatasync 將資料提交到永久儲存所需的時間。

資料中心內的 RTT 可能長達數百微秒。在美國境內的典型 RTT 約為 50 毫秒，而在跨洲之間可能慢至 400 毫秒。旋轉磁碟 (spinning disk) 的典型 fdatasync 延遲約為 10 毫秒。對於 SSD (固態硬碟)，延遲通常低於 1 毫秒。為了提高吞吐量，etcd 將多個請求批次處理 (batching) 在一起，並將它們提交給 Raft。這種批次處理策略使 etcd 即使在重度負載下也能達到高吞吐量。

還有其他子系統會影響 etcd 的整體效能。每個序列化的 etcd 請求都必須通過 etcd 的由 boltdb 支援的 MVCC 儲存引擎，這通常需要數十微秒才能完成。etcd 會定期對其最近套用的請求進行增量快照 (snapshot)，將它們與先前的磁碟快照合併。這個過程可能會導致延遲突波 (latency spike)。儘管這在 SSD 上通常不是問題，但在 HDD (傳統硬碟) 上可能會使觀察到的延遲加倍。同樣地，執行中的壓縮 (compaction) 也可能影響 etcd 的效能。幸運的是，這種影響通常微不足道，因為壓縮是交錯執行的，因此不會與常規請求競爭資源。RPC 系統 (gRPC) 為 etcd 提供了一個定義良好、可擴展的 API，但它也引入了額外的延遲，特別是對於本地讀取。