ETCD 深入（一）：揭開etcd神秘面紗-源碼實現(xiàn)剖析
文本為 etcd 深入系列文章的首篇。etcd 是非常優(yōu)秀的開源項目，深入系列的目標是通過閱讀 etcd 源碼，跟隨 etcd 的實現(xiàn)思路，學習如何實現(xiàn)數(shù)據(jù)強一致性、raft 共識算法、多版本并發(fā)控制等分布式系統(tǒng)原理，同時也關注 etcd 在 golang 程序設計上的良好實踐。
本篇文章主要介紹 etcd 實現(xiàn)的基本架構、源碼組織結構，以及基本的讀寫流程。每部分的細化研讀會放在之后的系列文章中。
etcd 總體架構
etcd 中比較核心的四個模塊就是：etcd server、raft 共識算法模塊、WAL 持久化日志模塊 、MVCC 狀態(tài)機存儲和多版本控制模塊 。它們之間互相交互完成了讀寫流程。
grpc server 是最上層處理客戶端請求層，主要處理了 HTTP/ grpc 等協(xié)議，本文先不做過多介紹。
一次完整的讀寫流程
寫請求
leader 節(jié)點收到寫請求，會發(fā)送給 raft 模塊
raft 模塊會將寫請求同步給其他 follower 節(jié)點；與此同時 leader 節(jié)點會將寫請求日志寫入自己的 WAL；
follower 節(jié)點回復是否接受本次寫請求；
超過半數(shù) ?（n/2+1）的 follower 節(jié)點同意寫入，則此條數(shù)據(jù)認為可以被 commit 。raft 模塊會通知 etcd server 模塊此條數(shù)據(jù)已經(jīng)被 commit，可以進行 Apply；
各節(jié)點的 ?etcd server ?向 MVCC 狀態(tài)機存儲模塊發(fā)起 Apply 請求，寫入后端存儲，完成本節(jié)點的寫請求數(shù)據(jù)版本持久化。
? ? ?不同節(jié)點間的 raft 模塊會相互通信，保持對 raft log 狀態(tài)的一致性，即一旦認為此條寫請求可以開始進行 Apply，此時各節(jié)點的 ?raft 模塊都會各自通知自己的 etcd server 進行 Apply；但是不同節(jié)點的 Apply 速度可能會有差異。那么 client 端會因此讀不到最新的數(shù)據(jù)嗎？并不會，因為 etcd 的 ReadIndex 機制保證了讀請求的線性一致性，下文會詳細描述。
當 client 所連接的節(jié)點完成 Apply 操作后，會返回 client 端本次寫請求成功。
讀請求
etcd 任意節(jié)點的 etcd server 收到讀請求。
判斷讀請求類型，如果是串行化讀，則直接進入 Apply 流程。即直接從本節(jié)點的 MVCC 后端存儲中讀取數(shù)據(jù)。（不一定是最新值）；
如果是線性一致性讀，則進去 Raft 模塊；
Raft 模塊向 leader 節(jié)點發(fā)起 ReadIndex 請求，獲取目前已經(jīng)提交的最新 Index ；（）
然后節(jié)點會等待本地的 AppliedIndex 大于或等于 ReadIndex 請求返回的 CommittedIndex, 才進入 Apply 流程；
Apply 流程：通過 Key 名從 TreeIndex 中獲取對用的 Revision，再通過 Revision 從 BoltDB 中獲取對應的 Key Value。
其中第5點是最重要的，它表明節(jié)點 Apply 到 CommittedIndex 之后的狀態(tài)都能使讀請求滿足線性一致性。
?
etcd Server 模塊
TBD
Raft 模塊 ：
etcd 是一個強一致性的分布式 kv 存儲系統(tǒng)。強一致性指的是一旦一個數(shù)據(jù)寫入成功后，從任意節(jié)點讀取出來的數(shù)據(jù)都是最新值，保證不會出現(xiàn)讀失敗或者讀出來舊值的情況。那么 etcd 到底是如何實現(xiàn)強一致性的呢？其中主要的 “功勞” 都是 raft 共識算法保證的?？梢?raft 模塊也是 etcd 最核心的模塊。
etcd 依賴 raft 算法實現(xiàn) leader 選舉、數(shù)據(jù)一致性。共識算法能保證多個節(jié)點對某個對象的狀態(tài)是一致的，在 Raft 算法中即保證了多個節(jié)點對 Raft Log 的狀態(tài)是一致的。
復制狀態(tài)機
Replicated state machine architecture. The consensus algorithm manages a replicated log containing state machine commands from clients. The state machines process identical sequences of commands from the logs, so they produce the same outputs.
節(jié)點選舉、共識算法與數(shù)據(jù)一致性
TBD
線性一致性讀
上文提到，etcd 如何通過 readIndex 實現(xiàn)強一致性？?
通過分析一個完整的讀操作可以看出，etcd 為了達成線性一致性讀需要滿足下面兩個條件：
由 leader 來處理只讀請求：如果 Follower 收到讀請求，需要將請求轉發(fā)給 leader 處理；
確保 leader 的有效性：leader 需要向集群發(fā)送一次廣播，如果能收到大多數(shù)節(jié)點的回應，說明 leader 節(jié)點的身份是有效的，這一過程是為了確保 leader 節(jié)點的數(shù)據(jù)都是最新的。
在 etcd 中實現(xiàn)讀請求的線性一致性必須要經(jīng)過 Raft 一致性協(xié)議，這種方式必須要付出一些性能和時延的代價。如果對數(shù)據(jù)一致性沒有特別強的要求，可以在客戶端將一致性模式配置成串行化（Serializable）。Serializable 模式的只讀請求可以由任何一個 etcd 成員提供，但是 etcd 可能會因此讀到過期的數(shù)據(jù)。
優(yōu)化：LeaseRead
優(yōu)化：Wait Free
Storage 后端存儲
WAL 模塊：數(shù)據(jù)持久化
TBD
MVCC 模塊：狀態(tài)機存儲
TBD
BoltDB：索引存儲
TBD
總結
TBD
參考
https://github.com/etcd-io
In Search of an Understandable Consensus Algorithm
分布式鍵值存儲 etcd 原理與實現(xiàn)
線性一致性和 Raft
高可用分布式存儲 etcd 的實現(xiàn)原理
