這是悟空的第 77 篇原創文章
web
做者 | 悟空聊架構算法
來源 | 悟空聊架構（ID：PassJava666）數據庫
1、Raft 概述
Raft 算法是分佈式系統開發首選的共識算法。好比如今流行 Etcd、Consul。服務器
若是掌握了這個算法，就能夠較容易地處理絕大部分場景的容錯和一致性需求。好比分佈式配置系統、分佈式 NoSQL 存儲等等，輕鬆突破系統的單機限制。微信
Raft 算法是經過一切以領導者爲準的方式，實現一系列值的共識和各節點日誌的一致。網絡
2、Raft 角色
2.1 角色
跟隨者（Follower）：普通羣衆，默默接收和來自領導者的消息，當領導者心跳信息超時的時候，就主動站出來，推薦本身當候選人。架構
候選人（Candidate）：候選人將向其餘節點請求投票 RPC 消息，通知其餘節點來投票，若是贏得了大多數投票選票，就晉升當領導者。編輯器
領導者（Leader）：霸道總裁，一切以我爲準。處理寫請求、管理日誌複製和不斷地發送心跳信息，通知其餘節點「我是領導者，我還活着，大家不要」發起新的選舉，不用找新領導來替代我。分佈式
以下圖所示，分別用三種圖表明跟隨者、候選人和領導者。flex
3、單節點系統
3.1 數據庫服務器
如今咱們想象一下，有一個單節點系統，這個節點做爲數據庫服務器，且存儲了一個值爲 X。
3.2 客戶端
左邊綠色的實心圈就是客戶端，右邊的藍色實心圈就是節點 a（Node a）。Term 表明任期，後面會講到。
3.3 客戶端向服務器發送數據
客戶端向單節點服務器發送了一條更新操做，設置數據庫中存的值爲 8。單機環境下（單個服務器節點），客戶端從服務器拿到的值也是 8。一致性很是容易保證。
3.4 多節點如何保證一致性？
但若是有多個服務器節點，怎麼保證一致性呢？好比有三個節點：a，b，c。以下圖所示。這三個節點組成一個數據庫集羣。客戶端對這三個節點進行更新操做，如何保證三個節點中存的值一致？這個就是分佈式一致性問題。Raft 算法就是來解決這個問題的。固然還有其餘協議也能夠保證，本篇只針對 Raft 算法。
在多節點集羣中，在節點故障、分區錯誤等異常狀況下，Raft 算法如何保證在同一個時間，集羣中只有一個領導者呢？下面就開始講解 Raft 算法選舉領導者的過程。
4、選舉領導過程
4.1 初始狀態
初始狀態下，集羣中全部節點都是跟隨者的狀態。
以下圖所示，有三個節點(Node) a、b、c，任期（Term）都爲 0。
4.2 成爲候選者
Raft 算法實現了隨機超時時間的特性，每一個節點等待領導者節點心跳信息的超時時間間隔是隨機的。好比 A 節點等待超時的時間間隔 150 ms，B 節點 200 ms，C 節點 300 ms。那麼 a 先超時，最早由於沒有等到領導者的心跳信息，發生超時。以下圖所示，三個節點的超時計時器開始運行。
當 A 節點的超時時間到了後，A 節點成爲候選者，並增長本身的任期編號，Term 值從 0 更新爲 1，並給本身投了一票。
-
Node A：Term = 1, Vote Count = 1。 -
Node B：Term = 0。 -
Node C：Term = 0。
4.3 投票
咱們來看下候選者如何成爲領導者的。
-
第一步：節點 A 成爲候選者後，向其餘節點發送請求投票 RPC 信息，請它們選舉本身爲領導者。 -
第二步：節點 B 和 節點 C 接收到節點 A 發送的請求投票信息後，在編號爲 1 的這屆任期內，尚未進行過投票，就把選票投給節點 A，並增長本身的任期編號。 -
第三步：節點 A 收到 3 次投票，獲得了大多數節點的投票，從候選者成爲本屆任期內的 新的領導者。 -
第四步：節點 A 做爲領導者，固定的時間間隔給 節點 B 和節點 C 發送心跳信息，告訴節點 B 和 C，我是領導者，組織其餘跟隨者發起新的選舉。 -
第五步：節點 B 和節點 C 發送響應信息給節點 A，告訴節點 A 我是正常的。
4.4 任期
英文單詞是 term，領導者是有任期的。
-
自動增長：跟隨者在等待領導者心跳信息超時後，推薦本身爲候選人，會增長本身的任期號，如上圖所示，節點 A 任期爲 0，推舉本身爲候選人時，任期編號增長爲 1。 -
更新爲較大值：當節點發現本身的任期編號比其餘節點小時，會更新到較大的編號值。好比節點 A 的任期爲 1，請求投票，投票消息中包含了節點 A 的任期編號，且編號爲 1，節點 B 收到消息後，會將本身的任期編號更新爲 1。 -
恢復爲跟隨者：若是一個候選人或者領導者，發現本身的任期編號比其餘節點小，那麼它會當即恢復成跟隨者狀態。這種場景出如今分區錯誤恢復後，任期爲 3 的領導者受到任期編號爲 4 的心跳消息，那麼前者將當即恢復成跟隨者狀態。 -
拒絕消息：若是一個節點接收到較小的任期編號值的請求，那麼它會直接拒絕這個請求，好比任期編號爲 6 的節點 A，收到任期編號爲 5 的節點 B 的請求投票 RPC 消息，那麼節點 A 會拒絕這個消息。
4.5 選舉規則
-
一個任期內，領導者一直都會領導者，直到自身出現問題（如宕機），或者網絡問題（延遲），其餘節點發起一輪新的選舉。 -
在一次選舉中，每個服務器節點最多會對一個任期編號投出一張選票，投完了就沒了。
4.6 大多數
假設一個集羣由 N 個節點組成，那麼大多數就是至少 N/2+1。例如：3 個節點的集羣，大多數就是 2。
4.7 心跳超時
爲了防止多個節點同時發起投票，會給每一個節點分配一個隨機的選舉超時時間。這個時間內，節點不能成爲候選者，只能等到超時。好比上述例子，節點 A 先超時，先成爲了候選者。這種巧妙的設計，在大多數狀況下只有一個服務器節點先發起選舉，而不是同時發起選舉，減小了因選票瓜分致使選舉失敗的狀況。
5、領導者故障
若是領導者節點出現故障，則會觸發新的一輪選舉。以下圖所示，領導者節點 B 發生故障，節點 A 和 節點 B 就會從新選舉 Leader。
-
第一步 ：節點 A 發生 故障，節點 B 和節點 C 沒有收到領導者節點 A 的心跳信息，等待超時。 -
第二步：節點 C 先發生超時，節點 C 成爲 候選人。 -
第三步：節點 C 向節點 A 和節點 B 發起請求投票信息。 -
第四步：節點 C 響應投票，將票投給了 C，而節點 A 由於發生故障了，沒法響應 C 的投票請求。 -
第五步：節點 C 收到兩票（大多數票數），成爲 領導者。 -
第六步：節點 C 向節點 A 和 B 發送心跳信息，節點 A 響應心跳信息，節點 B 不響應心跳信息。
總結
Raft 算法經過如下幾種方式來進行領導選舉，保證了一個任期只有一位領導，極大減小了選舉失敗的狀況。
-
任期 -
領導者心跳信息 -
隨機選舉超時時間 -
先來先服務的投票原則 -
大多數選票原則
本篇經過動圖的方式來說解 Raft 算法如何選舉領導者，更容易理解和消化。
- END -
往期推薦
我是悟空，努力變強，變身超級賽亞人！
本文分享自微信公衆號 - 悟空聊架構（PassJava666）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。