天天看點

雲原生必備知識: etcd性能

所屬技術領域:

雲原生

| 名詞定義 |

首先我們來看一張圖:

雲原生必備知識: etcd性能

上圖是一個标準的 etcd 叢集架構簡圖。可以将 etcd 叢集劃分成幾個核心的部分:例如藍色的 Raft 層、紅色的 Storage 層,Storage 層内部又分為 treeIndex 層和 boltdb 底層持久化存儲 key/value 層。它們的每一層都有可能造成 etcd 的性能損失。

首先來看 Raft 層,Raft 需要通過網絡同步資料,網絡 IO 節點之間的 RTT 和 / 帶寬會影響 etcd 的性能。除此之外,WAL 也受到磁盤 IO 寫入速度影響。

再來看 Storage 層,磁盤 IO fdatasync 延遲會影響 etcd 性能,索引層鎖的 block 也會影響 etcd 的性能。除此之外,boltdb Tx 的鎖以及 boltdb 本身的性能也将大大影響 etcd 的性能。

從其他方面來看,etcd 所在主控端的核心參數和 grpc api 層的延遲,也将影響 etcd 的性能。

決定etcd性能的關鍵因素,包括:

 延遲( agency):延遲是完成操作的時間。

 吞吐量 (throughput):吞吐量是在某個時間期間之内完成操作的總數量。當etcd接收并發用戶端請求時,通常平均延遲随着總體吞吐量增加而增加。

在通常的雲環境,比如 Google Compute Engine(GCE)标準的n-4或者AWS上相當的機器類型,一個三成員etcd叢集在輕負載下可以在低于毫秒内完成一個請求,并在重負載下可以每秒完成超過30000個請求。

etcd使用Raft-緻性算法來在成員之間複制請求并達成一緻。一緻性性能,特別是送出延遲,受限于兩個實體限制:網絡IO延遲和磁盤IO延遲。完成一個etcd請求的最小時間是成員之間的網絡往返時延( Round Trip Time/RT),加需要送出資料到持久化存儲的 fdatasync時間。在一個資料中心内的RTT可能有數百亳秒。在美國典型的RTT是大概50ms,而在大陸之間可以慢到400ms。旋轉硬碟(注:指傳統機械硬碟)的典型 fdatasync延遲是大概10ms。對于SSD硬碟,延遲通常低于1ms。為了提高吞吐量etcd将多個請求打包在一起并送出給Raft這個批量政策讓etcd在重負載試獲得高吞吐量。也有其他子系統影響到etcd的整體性能。每個序列化的etcd請求必須通過etcd的 bolted支援的(boltdb- backed)MVCC存儲引擎,它通常需要10微秒來完成。etcd定期遞增快照它最近實施的請求,将他們和之前在磁盤上的快照合并。這個過程可能導緻延遲尖峰(latency spike)。雖然在SSD上這通常不是問題,在HDD上它可能加倍可觀察到的延遲。而且,進行中的壓縮可以影響etcd的性能。幸運的是,壓縮通常無足輕重,因為壓縮是錯開的,是以它不和正常請求競争資源。RPC系統,gRPC,為etcd提供定義良好,可擴充的APl,但是它也引入了額外的延遲,尤其是本地讀取。

Etcd的預設配置在本地網絡環境(localhost)下通常能夠運作的很好,因為延遲很低。然而,當跨資料中心部署Etcd或網絡延時很高時,etcd的心跳間隔或選舉逾時時間等參數需要根據實際情況進行調整。

網絡并不是導緻延時的唯一來源。不論是 Follower還是 Leader,其請求和響應都受磁盤I/O延時的影響。每個 timeout都代表從請求發起到成功傳回響應的總時間。

| 技術特點 |

• 簡單:

基于 HTTP+JSON 的 API 讓你用 curl 就可以輕松使用。

• 安全:

可選 SSL 客戶認證機制。

• 快速:

每個執行個體每秒支援一千次寫操作。

• 可信:

使用 Raft 算法充分實作了分布式。

适用場景:

從 etcd github 上的介紹來看:

etcd is a distributed reliable key-value store for the most critical data of a distributed system, with a focus on being:

Simple: well-defined, user-facing API (gRPC)

Secure: automatic TLS with optional client cert authentication

Fast: benchmarked 10,000 writes/sec

Reliable: properly distributed using Raft

etcd 是一個分布式的 kv 存儲,具有高性能和可靠的優點。etcd 可以應用到以下場景:

一:服務發現

所有服務将元資訊存儲到以某個 prefix 開頭的 key 中,然後消費者從這些 key 中擷取服務資訊并調用。消費者也可以 watch 這些 key 的變更,以便在服務增加和減少時及時獲得通知。

二:配置共享

應用将配置資訊存放到 etcd,當配置資訊被更改時可以通過 watch 機制從 etcd 及時獲得通知。

三:分布式鎖

由于 etcd 中的資料是一緻的,當多個應用同時去建立一個 key 時隻有一個會成功,建立成功的應用即擷取了鎖。

etcd 還有更多的應用場景,例如叢集監控,Leader 競選等。需要注意的是,應該使用 etcd 來存儲一個關鍵的控制資料,對于應用資料應該隻在資料量較小時存儲。

etcd 已經應用到很多的項目中,其中最著名的莫過于 kubernetes。etcd 已經是一個相當成熟的項目,當你的項目中有需要服務發現,配置共享等功能時,可以考慮使用 etcd。

資料來源:

  1. 名詞定義: https://developer.aliyun.com/lesson_1651_16861 簡書: https://www.jianshu.com/p/f31ef5e7bdd0
  2. 技術特點:etcd的特性
  3. 适用場景:知乎 https://www.zhihu.com/question/60406751/answer/388896426

繼續閱讀