作者 | 陳潔（墨封） 阿里雲開發工程師
導讀：etcd 作爲 K8s 集羣中的存儲組件，讀寫性能方面會受到很多壓力，而 etcd 3.4 中的新特性將有效緩解壓力，本文將從 etcd 數據讀寫機制的發展歷史着手，深入解讀 etcd 3.4 新特性。
背景
etcd 是 Kubernetes 集羣中存儲元數據，保證分佈式一致性的組件，它的性能往往影響着整個集羣的響應時間。而在 K8s 的使用中，我們發現除了日常的讀寫壓力外，還存在某些特殊的場景會對 etcd 造成巨大的壓力，比如 K8s 下 apiserver 組件重啓或是其他組件繞過 apiserver cache 直接查詢 etcd 最新數據的情況時，etcd 會收到大量的 expensive read（後文會介紹該概念）請求，這對 etcd 讀寫會造成巨大的壓力。更爲嚴重的是，如果客戶端中存在失敗重試邏輯或客戶端數目較多，會產生大量這樣的請求，嚴重情況可能造成 etcd crash。
etcd 3.4 中增加了一個名爲“Fully Concurrent Read”的特性，較大程度上解決了上述的問題。在這篇文章中我們將重點解讀它。本篇文章首先回顧 etcd 數據讀寫機制發展的歷史，之後剖析爲何這個特性能大幅提升 expensive read 場景下 etcd 的讀寫性能，最後通過真實實驗驗證該特性的效果。
etcd 讀寫發展歷史
etcd v3.0 及之前早期版本
etcd 利用 Raft 算法實現了數據強一致性，它保證了讀操作的線性一致性。在 raft 算法中，寫操作成功僅僅以爲着寫操作被 commit 到日誌上，並不能確保當前全局的狀態機已經 apply 了該寫日誌。而狀態機 apply 日誌的過程相對於 commit 操作是異步的，因此在 commit 後立即讀取狀態機可能會讀到過期數據。
爲了保證線性一致性讀，早期的 etcd（etcd v3.0 ）對所有的讀寫請求都會走一遍 Raft 協議來滿足強一致性。然而通常在現實使用中，讀請求佔了 etcd 所有請求中的絕大部分，如果每次讀請求都要走一遍 raft 協議落盤，etcd 性能將非常差。
etcd v3.1
因此在 etcd v3.1 版本中優化了讀請求（PR#6275），使用的方法滿足一個簡單的策略：每次讀操作時記錄此時集羣的 commit index，當狀態機的 apply index 大於或者等於 commit index 時即可返回數據。由於此時狀態機已經把讀請求所要讀的 commit index 對應的日誌進行了 apply 操作，符合線性一致讀的要求，便可返回此時讀到的結果。
根據 Raft 論文 6.4 章的內容，etcd 通過 ReadIndex 優化讀取的操作核心爲以下兩個指導原則：
- 讓 Leader 處理 ReadIndex 請求，Leader 獲取的 commit index 即爲狀態機的 read index，follower 收到 ReadIndex 請求時需要將請求 forward 給 Leader；
- 保證 Leader 仍然是目前的 Leader，防止因爲網絡分區原因，Leader 已經不再是當前的 Leader，需要 Leader 廣播向 quorum 進行確認。
ReadIndex 同時也允許了集羣的每個 member 響應讀請求。當 member 利用 ReadIndex 方法確保了當前所讀的 key 的操作日誌已經被 apply 後，便可返回客戶端讀取的值。對 etcd ReadIndex 的實現，目前已有相對較多的文章介紹，本文不再贅述。
etcd v3.2
即便 etcd v3.1 中通過 ReadIndex 方法優化了讀請求的響應時間，允許每個 member 響應讀請求，但當我們把視角繼續下移到底層 k/v 存儲 boltdb 層，每個獨立的 member 在獲取 ReadIndex 後的讀取任然存在性能問題。
v3.1 中利用 batch 來提高寫事務的吞吐量，所有的寫請求會按固定週期 commit 到 boltDB。當上層向底層 boltdb 層發起讀寫事務時，都會申請一個事務鎖（如以下代碼片段），該事務鎖的粒度較粗，所有的讀寫都將受限。對於較小的讀事務，該鎖僅僅降低了事務的吞吐量，而對於相對較大的讀事務（後文會有詳細解釋），則可能阻塞讀、寫，甚至 member 心跳都有可能出現超時。
// release-3.2: mvcc/kvstore.go
func (s *store) TxnBegin() int64 {
...
s.tx = s.b.BatchTx()
// boltDB 事務鎖，所有的讀寫事務都需要申請該鎖
s.tx.Lock()
...
}針對以上提到的性能瓶頸，etcd v3.2 版本中對 boltdb 層讀寫進行優化，包含以下兩個核心點：
- 實現“N reads 或 1 write”的並行，將上文提到的粗粒度鎖細化成一個讀寫鎖，所有讀請求間相互並行；
- 利用 buffer 來提高了吞吐量。3.2 中對 readTx，batchTx 分別增加了一個 buffer，所有讀事務優先從 buffer 進行讀取，未命中再通過事務訪問 boltDB。同樣，寫事務在寫 boltDB 的同時，也會向 batchTx 的 buffer 寫入數據，而 batch commit 結束時，batchTx 的 buffer 會 writeBack 回 readTx 的 buffer 防止髒讀。
// release-3.3: mvcc/kvstore_txn.go
func (s *store) Read() TxnRead {
tx := s.b.ReadTx()
// 獲取讀事務的 RLock 後進行讀操作
tx.RLock()
}
// release-3.3: mvcc/backend/batch_tx.go
func (t *batchTxBuffered) commit(stop bool) {
// 獲取讀事務的 Lock 以確保 commit 之前所有的讀事務都已經被關閉
t.backend.readTx.Lock()
t.unsafeCommit(stop)
t.backend.readTx.Unlock()
}完全併發讀
etcd v3.2 的讀寫優化解決了大部分讀寫場景的性能瓶頸，但我們再從客戶端的角度出發，回到文章開頭我們提到的這種場景，仍然有導致 etcd 讀寫性能下降的危險。
這裏我們先引入一個 expensive read 的概念，在 etcd 中，所有客戶端的讀請求最後都是轉化爲 range 的請求向 KV 層進行查詢，我們以一次 range 請求的 key 數量以及 value size 來衡量一次 read 請求的壓力大小。綜合而言，當 range 請求的 key 數量越多，平均每個 key 對應的 value size 越大，則該 range 請求對 DB 層的壓力就越大。而實際劃分 expensive read 和 cheap read 邊界視 etcd 集羣硬件能力而定。
從客戶端角度，在大型集羣中的 apiserver 進行一次 pod、node、pvc 等 resource 的全量查詢，可以視爲一次 expensive read。簡要分析下爲何 expensive read 會對 boltDB 帶來壓力。上文提到，爲了防止髒讀，需要保證每次 commit 時沒有讀事務進行，因此寫事務每次 commit 之前，需要將當前所有讀事務進行回滾，所以 commit interval 時間點上需要申請 readTx.lock ，會將該鎖從 RLock() 升級成 Lock() ，該讀寫鎖的升級會可能導致所有讀操作的阻塞。
如下圖（以下圖中，藍色條爲讀事務，綠色條爲寫事務，紅色條爲事務因鎖問題阻塞），t1 時間點會觸發 commit，然而有事務未結束，T5 commit 事務因申請鎖被阻塞到 t2 時間點才進行。理想狀態下大量的寫事務會在一個 batch 中結束，這樣每次 commit 的寫事務僅僅阻塞少部分的讀事務（如圖中僅僅阻塞了 T6 這個事務）。
然而此時如果 etcd 中有非常大的讀請求，那麼該讀寫鎖的升級將被頻繁阻塞。如下圖，T3 是一個非常長的讀事務，跨過了多個 commit batch。每個 commit batch 結束時間點照常觸發了 commit 的寫事務，然而由於讀寫鎖無法升級，寫事務 T4 被推遲，同樣 t2 commit 點的寫事務 T7 因爲申請不到寫鎖一樣也被推遲。
此外，在寫事務的 commit 進行了之後，需要將寫緩存裏的 bucket 信息寫入到讀緩存中，此時同樣需要升級 readTx.lock 到 Lock() 。而上層調用 backend.Read() 獲取 readTx 時，需要確保這些 bucket 緩存已經成功寫過來了，需要申請讀鎖 readTx.RLock() ，而如果這期間存在寫事務，該鎖則無法得到，這些讀事務都無法開始。如上的情形下，在第三個 batch（t2-t3）中其他讀事務因爲得不到讀鎖都無法進行了。
總結而言，因 expensive read 造成讀寫鎖頻繁升級，導致寫事務的 commit 不斷被後移（通常我們將這種問題叫做 head-of-line blocking），從而導致 etcd 讀寫性能雪崩。
etcd v3.4 中，增加了一個 “Fully Concurrent Read” 的 feature，核心指導思想是如下兩點：
- 將上述讀寫鎖去除（事實上是對該鎖再次進行細化），使得所有讀和寫操作不再因該鎖而頻繁阻塞；
- 每個 batch interval 不再 reset 讀事務
readTxn，而是創建一個新的concurrentReadTxn實例去服務新的讀請求，而原來的readTxn在所有事務結束後會被關閉。每個concurrentReadTxn實例擁有一片自己的 buffer 緩存。
除了以上兩點變動外，fully concurrent read 在創建新的 ConcurrentReadTx 實例時需要從 ReadTx copy 對應的 buffer map，會存在一定的額外開銷，社區也在考慮將這個 copy buffer 的操作 lazy 化，在每個寫事務結束後或者每個 batch interval 結束點進行。然而在我們的實驗中發現，該 copy 帶來的影響並不大。改動的核心代碼如以下片段所示：
// release-3.4: mvcc/backend/read_tx.go
type concurrentReadTx struct {
// 每個 concurrentReadTx 實例保留一份 buffer，在創建時從 readTx 的 buffer 中獲得一份 copy
buf txReadBuffer
...
}
// release-3.4: mvcc/backend/backend.go
func (b *backend) ConcurrentReadTx() ReadTx {
// 由於需要從 readTx 拷貝 buffer，創建 concurrentReadTx 時需要對常駐的 readTx 上讀鎖。
b.readTx.RLock()
defer b.readTx.RUnlock()
...
}
// release-3.4: mvcc/backend/read_tx.go
// concurrentReadTx 的 RLock 中不做任何操作，不再阻塞讀事務
func (rt *concurrentReadTx) RLock() {}
// release-3.4: mvcc/kvstore_tx.go
func (s *store) Read() TxnRead {
// 調用 Read 接口時，返回 concurrentReadTx 而不是 readTx
tx := s.b.ConcurrentReadTx()
// concurrentReadTx 的 RLock 中不做任何操作
tx.RLock()
}我們再回到上文提到的存在 expensive read 的場景。在 fully concurrent read 的改動之後，讀寫場景如下圖所示。
首先在 mvcc 創建 backend 時會創建一個常駐的 readTx 實例，和之後的寫事務 batchTx 存在鎖衝突的也僅僅只有這一個實例。之後的所有讀請求（例如 T1，T2，T3 等），會創建一個新的 concurrentReadTx 實例進行服務，同時需要從 readTx 拷貝 buffer；當出現 expensive read 事務 T3 時，T4 不再被阻塞並正常執行。同時 T5 需要等待 T4 commit 完成後， readTx 的 buffer 被更新後，再進行 buffer 拷貝，因此阻塞一小段時間。而 t2、t3 commit 時間點的寫事務 T7、T8 也因爲沒有被阻塞而順利進行。
在 fully concurrent read 的讀寫模式下， concurrentReadTx 僅在創建時可能存在阻塞（因爲依賴從 readTx 進行 buffer 拷貝的操作），一旦創建後則不再有阻塞的情況，因此整個流程中讀寫吞吐量有較大的提升。<br />
讀寫性能驗證實驗
針對 etcd v3.4 fully concurrent read 的新 feature，我們在集羣中進行了實驗對比增加該 feature 前後讀寫性能的變化。爲了排除網絡因素干擾，我們做了單節點 etcd 的測試，但是已經足以從結果上看出該 feature 的優勢。以下是驗證實驗的設置：
- 讀寫設置
- 模擬集羣已有存儲量，預先寫入 100k KVs，每個 KV 由一個128B key和 一個 1~32KB 隨機的 values 組成（平均 16KB）
- expensive read：每次 range 20k keys，每秒 1 併發。
- cheap read：每次 range 10 keys，每秒 100 併發。
- write：每次 put 1 key，每秒 20 併發。
- 對照組
- 普通讀寫場景：cheap read + write；
- 模擬存在較重的讀事務的場景：cheap read + expensive read + write。
- 對比版本：
- etcd - ali2019rc2 未加入該優化
- etcd - ali2019rc3 加入該優化
- 防止偶然性：每組 test case 跑 5 次，取 99 分位（p99）的響應時間的平均值作爲該組 test case 的結果。
實驗結果如下表所示。對於普通讀寫場景，3.4 中的讀寫性能和 3.3 近似；對於存在較重的讀事務的場景，3.4 中的 fully concurrent read feature 一定程度降低了 expensive read 的響應時間。而在該場景下的 cheap read 和 write，rc2 中因讀寫鎖導致讀寫速度非常緩慢，而 rc3 中實現的完全並行使得讀寫響應時間減少到約爲原來的 1/7。
| etcd
version | cheap
read + write | | expensive
| read + cheap read + write | ||
|---|---|---|
| p99 read (ms) | p99 write (ms) | |
| read (ms) | p99 cheap read (ms) | p99 write (ms) |
| 3.3 | 14.1 | 15.1 |
| 3.4 （with FCR） | 16.1 | 14.2 |
其他場景下，如在 Kuberentes 5000節點性能測試，也表明在大規模讀壓力下，P99 寫的延時降低 97.4%。
總結
etcd fully concurrent read 的新 feature 優化 expensive 降低了近 85% 的寫響應延遲以及近 80% 的讀響應延遲，同時提高了 etcd 的讀寫吞吐量，解決了在讀大壓力場景下導致的 etcd 性能驟降的問題。調研和實驗的過程中感謝宇慕的指導，目前我們已經緊跟社區應用了該新能力，經過長時間測試表現穩定。未來我們也會不斷優化 etcd 的性能和穩定性，並將優化以及最佳實踐經驗反饋回社區。
參考文獻
- Etcd Fully Concurrent Read Design Proposal
- Strong consistency models
- Attiya H, Welch J L. Sequential consistency versus linearizability[J]. ACM Transactions on Computer Systems (TOCS), 1994, 12(2): 91-122.
- Ongaro D, Ousterhout J. In search of an understandable consensus algorithm[C]//2014 {USENIX} Annual Technical Conference ({USENIX}{ATC} 14). 2014: 305-319. [raft paper]
“ 阿里巴巴雲原生微信公衆號（ID：Alicloudnative）關注微服務、Serverless、容器、Service Mesh等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術公衆號。”