注：本文原創(chuàng)，轉(zhuǎn)載請(qǐng)標(biāo)明出處。

歡迎轉(zhuǎn)發(fā)、關(guān)注微信公眾號(hào)：Q的博客。 不定期發(fā)送干貨，實(shí)踐經(jīng)驗(yàn)、系統(tǒng)總結(jié)、源碼解讀、技術(shù)原理。

本文目的

筆者期望通過(guò)系列文章幫助讀者深入理解Raft協(xié)議并能付諸于工程實(shí)踐中，同時(shí)解讀不易理解或容易誤解的關(guān)鍵點(diǎn)。

該系列會(huì)從原理、源碼、實(shí)踐三個(gè)部分為大家講解Raft算法，本文為《Raft實(shí)戰(zhàn)》系列第二篇：

原理部分我們會(huì)結(jié)合 Raft 論文講解 Raft 算法思路，整體分篇會(huì)遵循 Raft 的模塊化思想，分別講解 Leader election、Log replication、Safety、Cluster membership change、Log compaction 等。

源碼部分我們會(huì)通過(guò)分析 hashicorp/raft 來(lái)學(xué)習(xí)一個(gè)工業(yè)界的 Raft 實(shí)現(xiàn)，hashicorp/raft 是 Consul 的底層依賴(lài)。

實(shí)踐部分我們會(huì)基于 hashicorp/raft 來(lái)實(shí)現(xiàn)一個(gè)簡(jiǎn)單的分布式 kv 存儲(chǔ)，以此作為系列的收尾。

什么是選主

選主(Leader election)就是在分布式系統(tǒng)內(nèi)抉擇出一個(gè)主節(jié)點(diǎn)來(lái)負(fù)責(zé)一些特定的工作。在執(zhí)行了選主過(guò)程后，集群中每個(gè)節(jié)點(diǎn)都會(huì)識(shí)別出一個(gè)特定的、唯一的節(jié)點(diǎn)作為leader。

我們開(kāi)發(fā)的系統(tǒng)如果遇到選主的需求，通常會(huì)直接基于 zookeeper 或 etcd 來(lái)做，把這部分的復(fù)雜性收斂到第三方系統(tǒng)。然而作為 etcd 基礎(chǔ)的 raft 自身也存在“選主”的概念，這是兩個(gè)層面的事情：基于 etcd 的選主指的是利用第三方 etcd 讓集群對(duì)誰(shuí)做主節(jié)點(diǎn)的決策達(dá)成一致，技術(shù)上來(lái)說(shuō)利用的是 etcd 的一致性狀態(tài)機(jī)、lease 以及 watch 機(jī)制，這個(gè)事情也可以改用單節(jié)點(diǎn)的 MySQL/Redis 來(lái)做，只是無(wú)法獲得高可用性；而 raft 本身的選主則指的是在 raft 集群自身內(nèi)部通過(guò)票選、心跳等機(jī)制來(lái)協(xié)調(diào)出一個(gè)大多數(shù)節(jié)點(diǎn)認(rèn)可的主節(jié)點(diǎn)作為集群的 leader 去協(xié)調(diào)所有決策。

當(dāng)你的系統(tǒng)利用 etcd 來(lái)寫(xiě)入誰(shuí)是主節(jié)點(diǎn)的時(shí)候，這個(gè)決策也在 etcd 內(nèi)部被它自己集群選出的主節(jié)點(diǎn)處理并同步給其它節(jié)點(diǎn)。

Raft 為什么要進(jìn)行選主？

按照論文所述，原生的 Paxos 算法使用了一種點(diǎn)對(duì)點(diǎn)(peer-to-peer)的方式，所有節(jié)點(diǎn)地位是平等的。在理想情況下，算法的目的是制定一個(gè)決策，這對(duì)于簡(jiǎn)化的模型比較有意義。但在工業(yè)界很少會(huì)有系統(tǒng)會(huì)使用這種方式，當(dāng)有一系列的決策需要被制定的時(shí)候，先選出一個(gè) leader 節(jié)點(diǎn)然后讓它去協(xié)調(diào)所有的決策，這樣算法會(huì)更加簡(jiǎn)單快速。

此外，和其它一致性算法相比，raft 賦予了 leader 節(jié)點(diǎn)更強(qiáng)的領(lǐng)導(dǎo)力，稱(chēng)之為 Strong Leader。比如說(shuō)日志條目只能從 leader 節(jié)點(diǎn)發(fā)送給其它節(jié)點(diǎn)而不能反著來(lái)，這種方式簡(jiǎn)化了日志復(fù)制的邏輯，使 raft 變得更加簡(jiǎn)單易懂。

Raft選主過(guò)程

下圖的節(jié)點(diǎn)狀態(tài)轉(zhuǎn)移圖，我們?cè)谇耙黄恼乱呀?jīng)看到了，但只是做了簡(jiǎn)單的描述，接下來(lái)我們會(huì)結(jié)合具體的Leader election細(xì)節(jié)來(lái)深刻理解節(jié)點(diǎn)的狀態(tài)轉(zhuǎn)換。

*圖名：節(jié)點(diǎn)狀態(tài)圖

Follower狀態(tài)轉(zhuǎn)移過(guò)程

Raft 的選主基于一種心跳機(jī)制，集群中每個(gè)節(jié)點(diǎn)剛啟動(dòng)時(shí)都是 follower 身份(Step: starts up)，leader 會(huì)周期性的向所有節(jié)點(diǎn)發(fā)送心跳包來(lái)維持自己的權(quán)威，那么首個(gè) leader 是如何被選舉出來(lái)的呢？方法是如果一個(gè) follower 在一段時(shí)間內(nèi)沒(méi)有收到任何心跳，也就是選舉超時(shí)，那么它就會(huì)主觀認(rèn)為系統(tǒng)中沒(méi)有可用的 leader，并發(fā)起新的選舉(Step: times out, starts election)。

這里有一個(gè)問(wèn)題，即這個(gè)“選舉超時(shí)時(shí)間”該如何制定？如果所有節(jié)點(diǎn)在同一時(shí)刻啟動(dòng)，經(jīng)過(guò)同樣的超時(shí)時(shí)間后同時(shí)發(fā)起選舉，整個(gè)集群會(huì)變得低效不堪，極端情況下甚至?xí)恢边x不出一個(gè)主節(jié)點(diǎn)。Raft 巧妙的使用了一個(gè)隨機(jī)化的定時(shí)器，讓每個(gè)節(jié)點(diǎn)的“超時(shí)時(shí)間”在一定范圍內(nèi)隨機(jī)生成，這樣就大大的降低了多個(gè)節(jié)點(diǎn)同時(shí)發(fā)起選舉的可能性。

*圖解：一個(gè)五節(jié)點(diǎn)Raft集群的初始狀態(tài)，所有節(jié)點(diǎn)都是follower身份，term為1，且每個(gè)節(jié)點(diǎn)的選舉超時(shí)定時(shí)器不同

若 follower 想發(fā)起一次選舉，follower 需要先增加自己的當(dāng)前 term，并將身份切換為 candidate。然后它會(huì)向集群其它節(jié)點(diǎn)發(fā)送“請(qǐng)給自己投票”的消息(RequestVote RPC)。

*圖解：S1 率先超時(shí)，變?yōu)?candidate，term + 1，并向其它節(jié)點(diǎn)發(fā)出拉票請(qǐng)求

Candicate狀態(tài)轉(zhuǎn)移過(guò)程

Follower 切換為 candidate 并向集群其他節(jié)點(diǎn)發(fā)送“請(qǐng)給自己投票”的消息后，接下來(lái)會(huì)有三種可能的結(jié)果，也即上面節(jié)點(diǎn)狀態(tài)圖中 candidate 狀態(tài)向外伸出的三條線(xiàn)。

1. 選舉成功(Step: receives votes from majority of servers)

當(dāng)candicate從整個(gè)集群的大多數(shù)(N/2+1)節(jié)點(diǎn)獲得了針對(duì)同一 term 的選票時(shí)，它就贏得了這次選舉，立刻將自己的身份轉(zhuǎn)變?yōu)?leader 并開(kāi)始向其它節(jié)點(diǎn)發(fā)送心跳來(lái)維持自己的權(quán)威。

*圖解：“大部分”節(jié)點(diǎn)都給了S1選票

*圖解：S1變?yōu)閘eader，開(kāi)始發(fā)送心跳維持權(quán)威

每個(gè)節(jié)點(diǎn)針對(duì)每個(gè) term 只能投出一張票，并且按照先到先得的原則。這個(gè)規(guī)則確保只有一個(gè) candidate 會(huì)成為 leader。

2. 選舉失敗(Step: discovers current leader or new term)

Candidate 在等待投票回復(fù)的時(shí)候，可能會(huì)突然收到其它自稱(chēng)是 leader 的節(jié)點(diǎn)發(fā)送的心跳包，如果這個(gè)心跳包里攜帶的 term 不小于 candidate 當(dāng)前的 term，那么 candidate 會(huì)承認(rèn)這個(gè) leader，并將身份切回 follower。這說(shuō)明其它節(jié)點(diǎn)已經(jīng)成功贏得了選舉，我們只需立刻跟隨即可。但如果心跳包中的 term 比自己小，candidate 會(huì)拒絕這次請(qǐng)求并保持選舉狀態(tài)。

*圖解：S4、S2 依次開(kāi)始選舉

*圖解：S4 成為 leader，S2 在收到 S4 的心跳包后，由于 term 不小于自己當(dāng)前的 term，因此會(huì)立刻切為 follower 跟隨S4

3. 選舉超時(shí)(Step: times out, new election)

第三種可能的結(jié)果是 candidate 既沒(méi)有贏也沒(méi)有輸。如果有多個(gè) follower 同時(shí)成為 candidate，選票是可能被瓜分的，如果沒(méi)有任何一個(gè) candidate 能得到大多數(shù)節(jié)點(diǎn)的支持，那么每一個(gè) candidate 都會(huì)超時(shí)。此時(shí) candidate 需要增加自己的 term，然后發(fā)起新一輪選舉。如果這里不做一些特殊處理，選票可能會(huì)一直被瓜分，導(dǎo)致選不出 leader 來(lái)。這里的“特殊處理”指的就是前文所述的隨機(jī)化選舉超時(shí)時(shí)間。

*圖解：S1~S5都在參與選舉

*圖解：沒(méi)有任何節(jié)點(diǎn)愿意給他人投票

*圖解：如果沒(méi)有隨機(jī)化超時(shí)時(shí)間，所有節(jié)點(diǎn)將會(huì)繼續(xù)同時(shí)發(fā)起選舉……

以上便是 candidate 三種可能的選舉結(jié)果。

Leader 切換狀態(tài)轉(zhuǎn)移過(guò)程

節(jié)點(diǎn)狀態(tài)圖中的最后一條線(xiàn)是：discovers server with higher term。想象一個(gè)場(chǎng)景：當(dāng) leader 節(jié)點(diǎn)發(fā)生了宕機(jī)或網(wǎng)絡(luò)斷連，此時(shí)其它 follower 會(huì)收不到 leader 心跳，首個(gè)觸發(fā)超時(shí)的節(jié)點(diǎn)會(huì)變?yōu)?candidate 并開(kāi)始拉票(由于隨機(jī)化各個(gè) follower 超時(shí)時(shí)間不同)，由于該 candidate 的 term 大于原 leader 的 term，因此所有 follower 都會(huì)投票給它，這名 candidate 會(huì)變?yōu)樾碌?leader。一段時(shí)間后原 leader 恢復(fù)了，收到了來(lái)自新leader 的心跳包，發(fā)現(xiàn)心跳中的 term 大于自己的 term，此時(shí)該節(jié)點(diǎn)會(huì)立刻切換為 follower 并跟隨的新 leader。

上述流程的動(dòng)畫(huà)模擬如下：

*圖解：S4 作為 term2 的 leader

*圖解：S4 宕機(jī)，S5 即將率先超時(shí)

*圖解：S5 當(dāng)選 term3 的 leader

*圖解：S4 宕機(jī)恢復(fù)后收到了來(lái)自 S5 的 term3 心跳

*圖解：S4 立刻變?yōu)?S5 的 follower

以上就是 raft 的選主邏輯，但還有一些細(xì)節(jié)(譬如是否給該 candidate 投票還有一些其它條件)依賴(lài)算法的其它部分基礎(chǔ)，我們會(huì)在后續(xù)“安全性”一篇描述。

當(dāng)票選出 leader 后，leader 也該承擔(dān)起相應(yīng)的責(zé)任了，這個(gè)責(zé)任是什么？就是下一篇將介紹的“日志復(fù)制”~

歡迎轉(zhuǎn)發(fā)、關(guān)注微信公眾號(hào)：Q的博客，不定期發(fā)送干貨，實(shí)踐經(jīng)驗(yàn)、系統(tǒng)總結(jié)、源碼解讀、技術(shù)原理。

總結(jié)

以上是生活随笔為你收集整理的raft协议 MySQL 切换_Raft 协议实战系列（二）—— 选主的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。