共計(jì) 2243 個(gè)字符，預(yù)計(jì)需要花費(fèi) 6 分鐘才能閱讀完成。
這篇文章給大家介紹如何進(jìn)行 etcd 的分析，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。
機(jī)制概念
Raft：etcd 所采用的保證分布式系統(tǒng)強(qiáng)一致性的算法
Node：一個(gè) Raft 狀態(tài)機(jī)實(shí)例
Member：一個(gè) etcd 實(shí)例它管理著一個(gè) Node，并且可以為客戶端請求提供服務(wù)
Cluster：由多個(gè) Member 構(gòu)成可以協(xié)同工作的 etcd 集群
Peer：對同一個(gè) etcd 集群中另外一個(gè) Member 的稱呼
Client：向 etcd 集群發(fā)送 HTTP 請求的客戶端
WAL：預(yù)寫式日志，etcd 用于持久化存儲(chǔ)的日志格式
snapshot：etcd 防止 WAL 文件過多而設(shè)置的快照，存儲(chǔ) etcd 數(shù)據(jù)狀態(tài)
Proxy：etcd 的一種模式，為 etcd 集群提供反向代理服務(wù)
Leader：Raft 算法中通過競選而產(chǎn)生的處理所有數(shù)據(jù)提交的節(jié)點(diǎn)
Follower：競選失敗的節(jié)點(diǎn)作為 Raft 中的從屬節(jié)點(diǎn)，為算法提供強(qiáng)一致性保證
Candidate：當(dāng) Follower 超過一定時(shí)間接收不到 Leader 的心跳時(shí)轉(zhuǎn)變?yōu)?Candidate 開始競選
Term：某個(gè)節(jié)點(diǎn)成為 Leader 到下一次競選時(shí)間，稱為一個(gè) Term
Index：數(shù)據(jù)項(xiàng)編號(hào) Raft 中通過 Term 和 Index 來定位數(shù)據(jù)
Etcd 的 Raft
由于 Raft 算法在做決策時(shí)需要多數(shù)節(jié)點(diǎn)的投票，所以 etcd 一般部署集群推薦奇數(shù)個(gè)節(jié)點(diǎn)，推薦的數(shù)量為 3、5 或者 7 個(gè)節(jié)點(diǎn)構(gòu)成一個(gè)集群。
腦裂解決方案
引入一個(gè)新的概念, region leader
region leader 是一個(gè)邏輯上的概念
任意時(shí)刻對于某一個(gè) region 來說, 一定只擁有一個(gè) region leader
每個(gè) region leader 在任期之內(nèi)嘗試每隔 t 時(shí)間間隔, 在 raft group 內(nèi)部更新一下 region leader 的 lease.
所有的讀寫請求都必須通過 region leader 完成
但是值得注意的是，region leader 和 raft leader 可能不是一個(gè)節(jié)點(diǎn)。當(dāng) region leader 和 raft leader 不重合的時(shí)候，region leader 會(huì)將請求轉(zhuǎn)發(fā)給當(dāng)前的 raft leader
當(dāng)網(wǎng)絡(luò)出現(xiàn)分區(qū)時(shí)，會(huì)出現(xiàn)以下幾種情況：
region leader 落在多數(shù)派，老 raft leader 在多數(shù)派這邊
region leader 落在多數(shù)派，老 raft leader 在少數(shù)派這邊
region leader 落在少數(shù)派，老 raft leader 在多數(shù)派這邊
region leader 落在少數(shù)派，老 raft leader 在少數(shù)派這邊
存儲(chǔ) (v3)
v3 和之前版本差別太大，僅以其為準(zhǔn)
Backend：BoltDB
基本特點(diǎn)
單機(jī)
支持事務(wù)
鍵值對
事務(wù)處理
增、刪、讀：都要獲取一個(gè)事務(wù)
只讀事務(wù)：只讀，只能查找 Bucket 和 K/V
讀寫事務(wù)：可讀寫
結(jié)束時(shí)：若無異常，則提交事務(wù)
有異常：拋棄整個(gè)事務(wù)
MVCC 結(jié)構(gòu)層次
revision：對同一個(gè) key 每次修改都對應(yīng)一個(gè) revision – main：每次事務(wù) +1 – sub：同次事務(wù)每次對其操作 +1 generation：– 一個(gè) key 在生命周期內(nèi)可能被頻繁刪除 – 從某次創(chuàng)建到該次刪除的所有 revision 集合組成一個(gè) generation key：每個(gè) key 是由多個(gè) generation 組成多版本 keyIndex：組織這個(gè)多版本 key 的結(jié)構(gòu)體叫做 keyIndex
維護(hù)
多個(gè)版本同時(shí)保持，需要不定期清理
刪除過老版本
ectd 提供了命令行工具
實(shí)現(xiàn)
type keyIndex struct {key []byte
modified revision // 最新版本 revision
generations []generation // 代
type generation struct {
ver int64
created revision // 創(chuàng)建這個(gè)代的第一個(gè)版本
revs []revision// 版本數(shù)組
type revision struct {
main int64 // 事務(wù) id，全局遞增
sub int64 // 事務(wù)內(nèi)遞增
}例子 插入數(shù)據(jù)
(key1, value1)
(key2, value2)更新數(shù)據(jù)
(key1, update1)
(key2, update2)存儲(chǔ)的記錄
rev={1 0}, key=key1, value= value1
rev={1 0}, key=key2, value= value2
rev={2 0}, key=key1, value= update1
rev={2 1}, key=key2, value= update2內(nèi)存索引：KeyIndex
基本特點(diǎn)
基于 Google 開源
基于 btree
組件
HTTP Server：用于處理用戶發(fā)送的 API 請求以及其它 etcd 節(jié)點(diǎn)的同步與心跳信息請求。
Store：用于處理 etcd 支持的各類功能的事務(wù)，包括數(shù)據(jù)索引、節(jié)點(diǎn)狀態(tài)變更、監(jiān)控與反饋、事件處理與執(zhí)行等等，是 etcd 對用戶提供的大多數(shù) API 功能的具體實(shí)現(xiàn)。
Raft：Raft 強(qiáng)一致性算法的具體實(shí)現(xiàn)，是 etcd 的核心。
WAL：Write Ahead Log（預(yù)寫式日志），是 etcd 的數(shù)據(jù)存儲(chǔ)方式
除了在內(nèi)存中存有所有數(shù)據(jù)的狀態(tài)以及節(jié)點(diǎn)的索引以外，etcd 就通過 WAL 進(jìn)行持久化存儲(chǔ)
WAL 中，所有的數(shù)據(jù)提交前都會(huì)事先記錄日志
Snapshot 是為了防止數(shù)據(jù)過多而進(jìn)行的狀態(tài)快照
Entry 表示存儲(chǔ)的具體日志內(nèi)容
關(guān)于如何進(jìn)行 etcd 的分析就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。
