Raft 簡介

Raft?是一種為了管理復(fù)制日志的一致性算法。它提供了和?Paxos 算法相同的功能和性能，但是它的算法結(jié)構(gòu)和?Paxos 不同，使得Raft 算法更加容易理解并且更容易構(gòu)建實(shí)際的系統(tǒng)。為了提升可理解性，Raft 將一致性算法分解成了幾個(gè)關(guān)鍵模塊，例如?Leader選舉、日志復(fù)制和安全性。同時(shí)它通過實(shí)施一個(gè)更強(qiáng)的一致性來減少需要考慮的狀態(tài)的數(shù)量。從一個(gè)用戶研究的結(jié)果可以證明，對(duì)于學(xué)生而言，Raft 算法比?Paxos 算法更加容易學(xué)習(xí)。Raft算法還包括一個(gè)新的機(jī)制來允許集群成員的動(dòng)態(tài)改變，它利用重疊的大多數(shù)來保證安全性。

?

分布式一致性算法

一致性算法允許一組機(jī)器像一個(gè)整體一樣工作，即使其中一些機(jī)器出現(xiàn)故障也能夠繼續(xù)工作下去。正因如此，一致性算法在構(gòu)建可信賴的大規(guī)模軟件系統(tǒng)中扮演著重要的角色。在過去的 10 年里，Paxos 算法統(tǒng)治著一致性算法這一領(lǐng)域：絕大多數(shù)的實(shí)現(xiàn)都是基于 Paxos 或者受其影響。同時(shí) Paxos 也成為了教學(xué)領(lǐng)域里講解一致性問題時(shí)的示例。

但是不幸的是，盡管有很多工作都在嘗試降低它的復(fù)雜性，但是?Paxos 算法依然十分難以理解。并且，Paxos 自身的算法結(jié)構(gòu)需要進(jìn)行大幅的修改才能夠應(yīng)用到實(shí)際的系統(tǒng)中。這些都導(dǎo)致了工業(yè)界和學(xué)術(shù)界都對(duì)?Paxos 算法感到十分頭疼。

和?Paxos 算法進(jìn)行過努力之后，研究人員開始尋找一種新的一致性算法，可以為構(gòu)建實(shí)際的系統(tǒng)和教學(xué)提供更好的基礎(chǔ)。作者的做法是不尋常的，首要目標(biāo)是可理解性：是否可以在實(shí)際系統(tǒng)中定義一個(gè)一致性算法，并且能夠比?Paxos 算法以一種更加容易的方式來學(xué)習(xí)。此外，Raft 作者希望該算法方便系統(tǒng)構(gòu)建者的直覺的發(fā)展。一個(gè)算法能夠工作是很重要的，而且能夠知道為什么能工作也很重要。

Raft 一致性算法就是這些工作的結(jié)果。在設(shè)計(jì) Raft 算法的時(shí)候，使用一些特別的技巧來提升它的可理解性，包括算法分解（Raft 主要被分成了 Leader 選舉，日志復(fù)制和安全性三個(gè)模塊）和減少狀態(tài)機(jī)的狀態(tài)（相對(duì)于 Paxos，Raft 減少了非確定性和服務(wù)器互相處于非一致性的方式）。

強(qiáng)領(lǐng)導(dǎo)者(Strong leader)：和其它一致性算法相比，Raft 使用一種更強(qiáng)的領(lǐng)導(dǎo)能力形式。比如，日志條目只從領(lǐng)導(dǎo)者發(fā)送給其它的服務(wù)器。這種方式簡化了對(duì)復(fù)制日志的管理并且使得 Raft 算法更加易于理解。

領(lǐng)導(dǎo)選舉(Leader election)：Raft 算法使用一個(gè)隨機(jī)計(jì)時(shí)器來選舉領(lǐng)導(dǎo)者。這種方式只是在任何一致性算法都必須實(shí)現(xiàn)的心跳機(jī)制上增加了一點(diǎn)機(jī)制。在解決沖突的時(shí)候會(huì)更加簡單快捷。

成員關(guān)系調(diào)整(Membership changes)：Raft使用一種共同一致的方法來處理集群成員變換的問題，在這種方法下，處于調(diào)整過程中的兩種不同的配置集群中大多數(shù)機(jī)器會(huì)有重疊，這就使得集群在成員變換的時(shí)候依然可以繼續(xù)工作。

實(shí)際系統(tǒng)中使用的一致性算法通常含有以下特性：

安全性保證（絕對(duì)不會(huì)返回一個(gè)錯(cuò)誤的結(jié)果）：在非拜占庭錯(cuò)誤情況下，包括網(wǎng)絡(luò)延遲、分區(qū)、丟包、冗余和亂序等錯(cuò)誤都可以保證正確。

可用性：集群中只要有大多數(shù)的機(jī)器可運(yùn)行并且能夠相互通信、和客戶端通信，就可以保證可用。因此，一個(gè)典型的包含 5 個(gè)節(jié)點(diǎn)的集群可以容忍兩個(gè)節(jié)點(diǎn)的失敗。服務(wù)器被停止就認(rèn)為是失敗。它們當(dāng)有穩(wěn)定的存儲(chǔ)的時(shí)候可以從狀態(tài)中恢復(fù)回來并重新加入集群。

不依賴時(shí)序來保證一致性：物理時(shí)鐘錯(cuò)誤或者極端的消息延遲只有在最壞情況下才會(huì)導(dǎo)致可用性問題。

通常情況下，一條指令可以盡可能快的在集群中大多數(shù)節(jié)點(diǎn)響應(yīng)一輪遠(yuǎn)程過程調(diào)用時(shí)完成。小部分比較慢的節(jié)點(diǎn)不會(huì)影響系統(tǒng)整體的性能。

?

Leader 選舉和日志復(fù)制

Raft 的角色

Client：系統(tǒng)外部客戶端，以下?gif 使用綠色節(jié)點(diǎn)代表 client。

Leader：負(fù)責(zé)接受 Client 的寫請(qǐng)求，并將寫請(qǐng)求同步到所有的 Follower，使用帶有黑色實(shí)線的節(jié)點(diǎn)表示。

Follower：同步?Leader 的數(shù)據(jù)。

Candidate：當(dāng)一定時(shí)間內(nèi)不存在 Leader 時(shí)，會(huì)有相應(yīng)的 Follower 成為候選者進(jìn)行 Leader 選舉，使用帶有虛線的節(jié)點(diǎn)表示。

?

單一節(jié)點(diǎn)

假設(shè)有一個(gè)單節(jié)點(diǎn)系統(tǒng)。以此為例，可以將這個(gè)節(jié)點(diǎn)視為存儲(chǔ)單個(gè)值的數(shù)據(jù)庫服務(wù)器。客戶端只需要將數(shù)據(jù)發(fā)送到這個(gè)服務(wù)器上就能完成存儲(chǔ)，讀取數(shù)據(jù)是也是從這個(gè)服務(wù)器獲取數(shù)據(jù)。一個(gè)節(jié)點(diǎn)只需要完好的保持?jǐn)?shù)據(jù)即可，不需要共識(shí)機(jī)制，因?yàn)橹挥羞@么一個(gè)數(shù)據(jù)。但是，如果有多個(gè)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)都需要存儲(chǔ)同一個(gè)值，那么就需要共識(shí)機(jī)制保證數(shù)據(jù)的一致性，即分布式共識(shí)問題。

?

單一?Leader?選舉

Raft 所有的節(jié)點(diǎn)都以 Follower?狀態(tài)開始。如果?Follower?沒有收到 Leader 的信息，那么它們可以成為?Candidate。然后，Candidate?從其他節(jié)點(diǎn)請(qǐng)求投票。節(jié)點(diǎn)將投票表決。如果?Candidate?從多數(shù)節(jié)點(diǎn)中獲得選票，它將成為 Leader。這個(gè)過程稱為?Leader?選舉。在 Raft 中，有兩個(gè)超時(shí)設(shè)置可控制選舉。首先是選舉超時(shí)。選舉超時(shí)是指 Follower 成為 Candidate 之前所等待的時(shí)間。選舉超時(shí)被隨機(jī)分配在 150毫秒 至 300毫秒 之間。選舉超時(shí)后，Follower?成為?Candidate?并開始新的選舉任期(Term)，它先為自己投票，然后向其他節(jié)點(diǎn)發(fā)送請(qǐng)求投票的消息。如果接收節(jié)點(diǎn)在這個(gè)期間還沒有投票，那么它將投票給?Candidate。并且該節(jié)點(diǎn)重置其選舉超時(shí)。

若 Leader 宕機(jī)了，觀察選舉連任的情況。節(jié)點(diǎn)? A? 經(jīng)過重新選舉后成為 任期2 的 Leader。在這一個(gè)過程中獲得多數(shù)票，可以確保每個(gè)任期只能選出一位 Leader。Leader 選舉需要半數(shù)以上的 Follower 同意才行，一般節(jié)點(diǎn)數(shù)量應(yīng)該選擇為奇數(shù)。宕機(jī)選舉如下：

Leader 開始向其 Follower?發(fā)送?"添加條目"?消息。這些消息以心跳超時(shí)指定的時(shí)間間隔發(fā)送。Follower?然后響應(yīng)每個(gè)追加條目消息。此選舉任期將持續(xù)到?Follower?停止接收心跳并成為 Candidate 為止。Leader 向其他 Follower 發(fā)送 Log 同步請(qǐng)求時(shí)，實(shí)質(zhì)上也是一個(gè)心跳包，這里心跳包的作用：一是攜帶請(qǐng)求，二是刷新 Follower 的選舉超時(shí)時(shí)間。

?

多個(gè)?Candidate 競爭選舉

如果兩個(gè)節(jié)點(diǎn)同時(shí)成為候選節(jié)點(diǎn)，則可能會(huì)發(fā)生拆分表決。兩個(gè)節(jié)點(diǎn)都開始以相同的任期進(jìn)行選舉，而每個(gè)?Candidate?都先到達(dá)一個(gè)?Follower?節(jié)點(diǎn)，并且得到投票。現(xiàn)在，每位 Candidate 都有2票，并且在這個(gè)任期中將無法獲得更多選票，此時(shí)需要超時(shí)時(shí)間過后再進(jìn)行選舉。節(jié)點(diǎn) C 在第 5 個(gè)任期中獲得了大多數(shù)選票，因此成為 Leader。雙候選者選舉情況如下：

一個(gè)比較特殊的情況，后來者居上：

?

日志復(fù)制

系統(tǒng)的所有更改都通過 Leader。每次更改都將添加到節(jié)點(diǎn)的日志中。該日志條目當(dāng)前未提交，因此不會(huì)更新節(jié)點(diǎn)的值。要提交條目，節(jié)點(diǎn)首先將其復(fù)制到 Follower 節(jié)點(diǎn)，然后 Leader 等待，直到大多數(shù)節(jié)點(diǎn)都寫了該條目。如下所示，該條目已提交到 Follower?節(jié)點(diǎn)上，并且節(jié)點(diǎn)狀態(tài)為?"5"。Leader 然后通知?Follower?該條目已提交。現(xiàn)在，集群已就系統(tǒng)狀態(tài)達(dá)成共識(shí)。此過程稱為日志復(fù)制。

?

當(dāng)選出一位 Leader 后，需要將系統(tǒng)的所有更改復(fù)制到所有節(jié)點(diǎn)（剛才是Term 0，現(xiàn)在是Term 1）。通過使用與心跳相同的?"添加條目"?消息來完成此操作。首先，客戶將更改發(fā)送給?Leader。更改將添加到 Leader 的日志中，然后將更改在下一個(gè)心跳發(fā)送給?Follower。一旦大多數(shù)?Follower?認(rèn)可，便提交該條目。然后將響應(yīng)發(fā)送給客戶端。現(xiàn)在，讓再發(fā)送一條命令，將值增加?"2"。最終系統(tǒng)的值更新為?"7"。

?

網(wǎng)絡(luò)分區(qū)

面對(duì)網(wǎng)絡(luò)分區(qū)，Raft 仍然可以保持一致。假如添加一個(gè)分區(qū)以將[ A, B ]，[ C, D, E ]分開。現(xiàn)在有兩位 Leader 使用不同的選舉。我們添加另一個(gè)客戶端，并嘗試更新兩個(gè) Leader。通過添加客戶端對(duì)不同分區(qū)的訪問來學(xué)習(xí) Raft 在網(wǎng)絡(luò)分區(qū)發(fā)生時(shí)的處理策略。

分區(qū)產(chǎn)生前后：

分區(qū)產(chǎn)生后，由于[ C, D, E ]的選舉超時(shí)時(shí)間流逝，其中 C 成為候選人，向 D、E 節(jié)點(diǎn)發(fā)送投票請(qǐng)求，C 成為所在分區(qū)的 Leader。

?

分別添加客戶端訪問兩個(gè)分區(qū)：

此時(shí) 客戶端 1 向 Leader B 發(fā)送請(qǐng)求，Leader B 會(huì)發(fā)送心跳包給 A，確認(rèn)其是否可以同步，但是卻發(fā)現(xiàn)當(dāng)前只有?2 個(gè)節(jié)點(diǎn)同意同步（包括 Leader B 自身的一票），達(dá)不到節(jié)點(diǎn)總數(shù)的一半以上（不到3個(gè)），所以暫時(shí)不會(huì)進(jìn)行數(shù)據(jù)的更新。此時(shí) 客戶端 2?向Leader C 發(fā)送了一個(gè)請(qǐng)求，Leader C 把心跳包發(fā)送給 D?和 E ，收獲到半數(shù)以上節(jié)點(diǎn)的投票，即表明可以同步數(shù)據(jù)，所以提交日志，C、D、E節(jié)點(diǎn)被設(shè)置為 8。

?

恢復(fù)分區(qū)后：

現(xiàn)在讓網(wǎng)絡(luò)分區(qū)恢復(fù)。節(jié)點(diǎn) A、B 看到更高的選舉期限(Term)并退出。節(jié)點(diǎn) A 和 B 都將回滾其未提交的條目并匹配新 Leader 的日志。現(xiàn)在，我們的日志在整個(gè)集群中是一致的。

?

總結(jié)

算法的設(shè)計(jì)通常會(huì)把正確性，效率或者簡潔作為主要的目標(biāo)。盡管這些都是很有意義的目標(biāo)，但是對(duì)于?Raft 而言，可理解性也是同樣的重要。一個(gè)廣為接受但是十分令人費(fèi)解的算法?Paxos 已經(jīng)困擾了無數(shù)學(xué)生和開發(fā)者很多年了。在開發(fā)者把算法應(yīng)用到實(shí)際的系統(tǒng)中之前，這些目標(biāo)沒有被實(shí)現(xiàn)，那必然會(huì)偏離發(fā)表算法時(shí)的初衷。除非開發(fā)人員對(duì)這個(gè)算法有著很深的理解并且有著直觀的感覺，否則將會(huì)對(duì)它們而言很難在實(shí)現(xiàn)的時(shí)候保持原有的期望。Raft 比?Paxos 要容易理解。Raft 也可以為實(shí)際的系統(tǒng)實(shí)現(xiàn)提供堅(jiān)實(shí)的基礎(chǔ)。

?

?

參考：

Raft?論文：In Search of an Understandable Consensus Algorithm?(Extended Version)

Raft 算法在線演示：http://thesecretlivesofdata.com/raft/

總結(jié)

以上是生活随笔為你收集整理的Raft算法的Leader选举和日志复制过程的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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