06、etcd 寫請求執行流程-有解無憂

本篇內容主要來源于自己學習的視頻，如有侵權，請聯系洗掉，謝謝，

上一節我們學習了 etcd 讀請求執行流程，這一節，我們來學習 etcd 寫請求執行流程，

1、etcd寫請求概覽

etcd 一個寫請求執行流程又是怎樣的呢?

etcdctl 	put	 hello	world	‐‐endpoints	192.168.65.210:2379

執行流程:

1、首先 client 端通過負載均衡演算法選擇一個 etcd 節點，發起 gRPC 呼叫;
2、然后 etcd 節點收到請求后經過 gRPC 攔截器、Quota 模塊后，進入 KVServer 模塊;
3、KVServer 模塊向 Raft 模塊提交一個提案，提案內容為“大家好，請使用 put 方法執行一個 key 為 hello，value 為 world 的命令”，
4、隨后此提案通過 Raft HTTP 網路模塊轉發、經過集群多數節點持久化后，狀態會變成已提交;
5、etcdserver 從 Raft 模塊獲取已提交的日志條目，傳遞給 Apply 模塊
6、Apply 模塊通過 MVCC 模塊執行提案內容，更新狀態機，

與讀流程不一樣的是，寫流程還涉及 Quota、WAL、Apply 三個模塊，etcd 的 crash-safe 及冪等性也正是基于 WAL 和 Apply 流程的 consistent index 等實作的，

2、詳細步驟解讀

2.1、Quota 模塊

流程二

Quota 模塊主要用于檢查下當前 etcd db 大小加上你請求的 key-value 大小之和是否超過了配額(quota-backend-bytes)，如果超過了配額，它會產生一個告警(Alarm)請求，告警型別是 NO SPACE，并通過 Raft 日志同步給其它節點，告知 db 無空間了，并將告警持久化存盤到 db 中，最終，無論是 API 層 gRPC 模塊還是負責將 Raft 側已提交的日志條目應用到狀態機的 Apply 模塊，都拒絕寫入，集群只讀，

常見的 etcdserver: mvcc: database space exceeded 錯誤就是因為Quota 模塊檢測到 db 大小超限導致的，哪些情況會觸發這個錯誤:

一方面默認 db 配額僅為 2G，當你的業務資料、寫入 QPS、Kubernetes 集群規模增大后，你的 etcd db 大小就可能會超過 2G，
另一方面 etcd 是個 MVCC 資料庫，保存了 key 的歷史版本，當你未配置壓縮策略的時候，隨著資料不斷寫入，db 大小會不斷增大，導致超限，

解決辦法:

1、首先當然是調大配額，etcd 社區建議不超過 8G，

如果填的是個小于 0 的數，就會禁用配額功能，這可能會讓db 大小處于失控，導致性能下降，不建議你禁用配額，

2、檢查 etcd 的壓縮(compact)配置是否開啟、配置是否合理，

壓縮時只會給舊版本Key打上空閑(Free)標記，后續新的資料寫入的時候可復用這塊空間，db大小并不會減小，

如果需要回收空間，減少 db 大小，得使用碎片整理 (defrag)，它會遍歷舊的 db 檔案資料，寫入到一個新的 db 文件，但是它對服務性能有較大影響，不建議你在生產集群頻繁使用，

調整后還需要手動發送一個取消告警(etcdctl alarm disarm)的命令，以消除所有告警，否則因為告警的存在，集群還是無法寫入，

這個注意別忘記了！！！

查看狀態
etcdctl --endpoints=192.168.91.68:2379,192.168.91.68:12379,192.168.91.68:22379 endpoint status -w table

壓縮
etcdctl --endpoints=192.168.91.68:2379,192.168.91.68:12379,192.168.91.68:22379 compact 1

碎片整理
etcdctl --endpoints=192.168.91.68:2379,192.168.91.68:12379,192.168.91.68:22379 defrag


etcdctl alarm disarm

2.2、KVServer 模塊

流程3

通過流程二的配額檢查后，請求就從 API 層轉發到了流程三的 KVServer 模塊的 put 方法，

KVServer 模塊主要功能為:
1、打包提案: 將 put 寫請求內容打包成一個提案訊息，提交給 Raft 模塊

2、請求限速、檢查: 不過在提交提案前，還有限速、鑒權和大包檢查，

2.2.1、Preflight Check

為了保證集群穩定性，避免雪崩，任何提交到 Raft 模塊的請求，都會做一些簡單的限速判斷，

限速

如果 Raft 模塊已提交的日志索引(committed index)比已應用到狀態機的日志索引 (applied index)超過了 5000，那么它就回傳一個etcdserver: too many requests錯誤給 client，

鑒權

然后它會嘗試去獲取請求中的鑒權資訊，若使用了密碼鑒權、請求中攜帶了 token，如果 token 無效，則回傳auth: invalid auth token 錯誤給 client，

大包檢查

其次它會檢查你寫入的包大小是否超過默認的 1.5MB，如果超過了會回傳etcdserver: request is too large錯誤給 client，

2.3、Propose

流程4

通過檢查后會生成一個唯一的 ID，將此請求關聯到一個對應的訊息通知 channel(用于接收結果)，然后向 Raft 模塊發起(Propose)一個提案(Proposal)， Raft 模塊發起提案后，KVServer 模塊會等待此 put 請求，等待寫入結果通過訊息通知 channel 回傳或者超時，

etcd 默認超時時間是 7 秒(5 秒磁盤 IO 延時 +2*1 秒競選超時時間)，如果一個請求超時未回傳結果，則可能會出現你熟悉的etcdserver: request timed out 錯誤，

2.4 WAL 模塊

流程5

Raft 模塊收到提案后，如果當前節點是 Follower，它會轉發給 Leader，只有 Leader 才能處理寫請求，

Leader 收到提案后，通過 Raft 模塊輸出待轉發給 Follower 節點的訊息和待持久化的日志條目，日志條目則封裝了我們上面所說的 put hello 提案內容，

etcdserver 從 Raft 模塊獲取到以上訊息和日志條目后，作為 Leader，它會將 put 提案消息廣播給集群各個節點，同時需要把集群 Leader 任期號、投票資訊、已提交索引、提案內容持久化到一個 WAL(Write Ahead Log)日志檔案中，用于保證集群的一致性、可恢復性，也就是我們圖中的流程五模塊，

2.4.1、WAL 日志結構

WAL 日志結構如下:

WAL 檔案它由多種型別的 WAL 記錄順序追加寫入組成，每個記錄由型別、資料、回圈冗余校驗碼組成，不同型別的記錄通過 Type 欄位區分，Data 為對應記錄內容，CRC 為回圈校驗碼資訊，

WAL 記錄型別目前支持 5 種，分別是檔案元資料記錄、日志條目記錄、狀態資訊記錄、 CRC 記錄、快照記錄:

檔案元資料記錄：包含節點 ID、集群 ID 資訊，它在 WAL 檔案創建的時候寫入;
日志條目記錄：包含 Raft 日志資訊，如 put 提案內容;
狀態資訊記錄：包含集群的任期號、節點投票資訊等，一個日志檔案中會有多條，以最后的記錄為準;
CRC 記錄：包含上一個 WAL 檔案的最后的 CRC(回圈冗余校驗碼)資訊，在創建、切割 WAL 檔案時，作為第一條記錄寫入到新的 WAL 檔案，用于校驗資料檔案的完整性、準確性等;
快照記錄：包含快照的任期號、日志索引資訊，用于檢查快照檔案的準確性，

2.4.2、WAL 持久化

首先會將 put 請求封裝成一個 Raft 日志條目，Raft 日志條目的資料結構資訊如下:

type Entry struct {
   Term             uint64    `protobuf:"varint，2，opt，name=Term" json:"Term"`
   Index            uint64    `protobuf:"varint，3，opt，name=Index" json:"Index"`
   Type             EntryType `protobuf:"varint，1，opt，name=Type，enum=Raftpb.EntryType" json:"Type"`
   Data             []byte    `protobuf:"bytes，4，opt，name=Data" json:"Data，omitempty"`
}

它由以下欄位組成:

Term 是 Leader 任期號，隨著 Leader 選舉增加;
Index 是日志條目的索引，單調遞增增加;
Type 是日志型別，比如是普通的命令日志(EntryNormal)，還是集群配置變更日志(EntryConfChange);
Data 保存我們上面描述的 put 提案內容，

具體持久化程序如下:
1、它首先先將 Raft 日志條目內容(含任期號、索引、提案內容)序列化后保存到 WAL 記錄的 Data 欄位，然后計算 Data 的 CRC 值，設定 Type 為 Entry Type，以上資訊就組成了一個完整的 WAL 記錄，

2、最后計算 WAL 記錄的長度，順序先寫入 WAL 長度(Len Field)，然后寫入記錄內容，呼叫 fsync 持久化到磁盤，完成將日志條目保存到持久化存盤中，

3、當一半以上節點持久化此日志條目后， Raft 模塊就會通過 channel 告知 etcdserver 模塊，put 提案已經被集群多數節點確認，提案狀態為已提交，你可以執行此提案內容了，

4、于是進入流程六，etcdserver 模塊從 channel 取出提案內容，添加到先進先出(FIFO)調度佇列，隨后通過 Apply 模塊按入隊順序，異步、依次執行提案內容，

2.5、Apply 模塊

流程 7

Apply 模塊主要用于執行處于已提交狀態的提案，將其更新到狀態機，

Apply 模塊在執行提案內容前，首先會判斷當前提案是否已經執行過了，如果執行了則直接回傳，若未執行同時無 db 配額滿告警，則進入到 MVCC 模塊，開始與持久化存盤模塊打交道，

如果執行程序中 crash，重啟后如何找回例外提案，再次執行的呢?

主要依賴 WAL 日志，因為提交給 Apply 模塊執行的提案已獲得多數節點確認、持久化， etcd 重啟時，會從 WAL 中決議出 Raft 日志條目內容，追加到 Raft 日志的存盤中，并重放已提交的日志提案給 Apply 模塊執行，

重啟恢復時，如何確保冪等性，防止提案重復執行導致資料混亂呢?

etcd 通過引入一個 consistent index 的欄位，來存盤系統當前已經執行過的日志條目索引，實作冪等性，

因為 Raft 日志條目中的索引(index)欄位，而且是全域單調遞增的，每個日志條目索引對應一個提案，如果一個命令執行后，我們在 db 里面也記錄下當前已經執行過的日志條目索引，就可以解決冪等性問題了，當然還需要將執行命令和記錄index這兩個操作作為原子性事務提交，才能實作冪等，

2.6、MVCC 模塊

流程 8 和 9

MVCC 主要由兩部分組成，一個是記憶體索引模塊 treeIndex，保存 key 的歷史版本號信息，另一個是 boltdb 模塊，用來持久化存盤 key-value 資料，

MVCC 模塊執行 put hello 為 world 命令時，它是如何構建記憶體索引和保存哪些資料到 db呢?

2.6.1、treeIndex

MVCC 寫事務在執行 put hello 為 world 的請求時，會基于 currentRevision 自增生成新的 revision，如{2,0}，然后從 treeIndex 模塊中查詢 key 的創建版本號、修改次數資訊，這些資訊將填充到 boltdb 的 value 中，同時將用戶的 hello key 和 revision 等資訊存盤到 B-tree，也就是下面簡易寫事務圖的流程一，整體架構圖中的流程八，

hello: revision{2,0}

這里的 2，0 具體指的是什么呢?

這里不太懂，有清楚的朋友，請不吝賜教，

2.6.2、boltdb

MVCC 寫事務自增全域版本號后生成的 revision{2,0}，它就是 boltdb 的 key，通過它就可以往 boltdb 寫資料了，進入了整體架構圖中的流程九，

那么寫入 boltdb 的 value 含有哪些資訊呢?

寫入 boltdb 的 value，并不是簡單的"world"，如果只存一個用戶 value，索引又是保存在易失的記憶體上，那重啟 etcd 后，我們就丟失了用戶的 key 名，無法構建 treeIndex 模塊了，

因此為了構建索引和支持 Lease(租約) 等特性，etcd 會持久化以下資訊:

key 名稱;
key 創建時的版本號(create_revision)、最后一次修改時的版本號 (mod_revision)、key 自身修改的次數(version);
value 值;
租約資訊，

boltdb value 的值就是將含以上資訊的結構體序列化成的二進制資料，然后通過 boltdb 提供的 put 介面，etcd 就快速完成了將你的資料寫入 boltdb，

注意: 在以上流程中，etcd 并未提交事務(commit)，因此資料只更新在 boltdb 所管理的記憶體資料結構中，

事務提交的程序，包含 B+tree 的平衡、分裂，將 boltdb 的臟資料(dirty page)、元數據資訊重繪到磁盤，因此事務提交的開銷是昂貴的，

如果我們每次更新都提交事務，etcd寫性能就會較差，

etcd 的解決方案是合并再合并:

首先 boltdb key 是版本號，put/delete 操作時，都會基于當前版本號遞增生成新的版本號，因此屬于順序寫入，可以調整 boltdb 的 bucket.FillPercent 引數，使每個 page 填充更多資料，減少 page 的分裂次數并降低 db 空間，
其次 etcd 通過合并多個寫事務請求，通常情況下，是異步機制定時(默認每隔 100ms) 將批量事務一次性提交(pending 事務過多才會觸發同步提交)，從而大大提高吞吐量，但是這優化又引發了另外的一個問題，因為事務未提交，讀請求可能無法從 boltdb 獲取到最新資料，
為了解決這個問題，etcd 引入了一個 bucket buffer 來保存暫未提交的事務資料，在更新 boltdb 的時候，etcd 也會同步資料到 bucket buffer，因此 etcd 處理讀請求的時候會優先從 bucket buffer 里面讀取，其次再從 boltdb 讀，通過 bucket buffer 實作讀寫性能提升，同時保證資料一致性，

以上就是 etcd 寫請求執行的流程，自己還是有蠻多地方不太懂，常看常新吧，

學習鏈接

b站-etcd寫請求執行流程-圖靈教程

轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/556897.html

標籤：NoSQL

上一篇：華為云河圖KooMap：夯實數字孿生底座，點燃燎原星火

下一篇：返回列表