Raft 算法原理及其在 CMQ 中的應(yīng)用（上）
導(dǎo)語(yǔ)
Raft算法是一種分布式一致性算法。與paxos相比，它更易理解和工程化。我們完整實(shí)現(xiàn)了該算法并將其應(yīng)用在自研的高可靠消息中間件CMQ中，同時(shí)沉淀出對(duì)外通用的Raft算法庫(kù)。本文主要介紹Raft算法的原理、工程化時(shí)遇到的問(wèn)題與解決方案、以及改進(jìn)性能的措施。
一 背景介紹
分布式系統(tǒng)是指一組獨(dú)立的計(jì)算機(jī)，通過(guò)網(wǎng)絡(luò)協(xié)同工作的系統(tǒng)，客戶看來(lái)就如同單臺(tái)機(jī)器在工作。隨著互聯(lián)網(wǎng)時(shí)代數(shù)據(jù)規(guī)模的爆發(fā)式增長(zhǎng)，傳統(tǒng)的單機(jī)系統(tǒng)在性能和可用性上已經(jīng)無(wú)法勝任，分布式系統(tǒng)具有擴(kuò)展性強(qiáng)，可用性高，廉價(jià)高效等優(yōu)點(diǎn)，得以廣泛應(yīng)用。
但與單機(jī)系統(tǒng)相比，分布式系統(tǒng)在實(shí)現(xiàn)上要復(fù)雜很多。CAP理論是分布式系統(tǒng)的理論基石，它提出在以下3個(gè)要素中：
Consistency(強(qiáng)一致性)：任何客戶端都可以讀取到其他客戶端最近的更新。
Availability(可用性)： 系統(tǒng)一直處于可服務(wù)狀態(tài)。
Partition-tolenrance(分區(qū)可容忍性)：?jiǎn)螜C(jī)故障或網(wǎng)絡(luò)分區(qū)，系統(tǒng)仍然可以保證強(qiáng)一致性和可用性。
一個(gè)分布式系統(tǒng)最多只能滿足其中2個(gè)要素。對(duì)于分布式系統(tǒng)而言，P顯然是必不可少的，那么只能在AP和CP之間權(quán)衡。AP系統(tǒng)犧牲強(qiáng)一致性，這在某些業(yè)務(wù)場(chǎng)景下(如金融類)是不可接受的，CP系統(tǒng)可以滿足這類需求，問(wèn)題的關(guān)鍵在于會(huì)犧牲多少可用性。傳統(tǒng)的主備強(qiáng)同步模式雖然可以保證一致性，但一旦機(jī)器故障或網(wǎng)絡(luò)分區(qū)系統(tǒng)將變得不可用。paxos和raft等一致性算法的提出，彌補(bǔ)了這一缺陷。它們?cè)诒ＷCCP的前提下，只要求大多數(shù)節(jié)點(diǎn)可以正常互聯(lián)，系統(tǒng)便可以一直處于可用狀態(tài)，可用性上顯著提高。paxos的理論性偏強(qiáng)，開發(fā)者需要自己處理很多細(xì)節(jié)，這也是它有很多變種的原因，相對(duì)而言raft更易理解和工程化，一經(jīng)提出便廣受歡迎。
在我們關(guān)注的消息中間件領(lǐng)域，金融支付類業(yè)務(wù)往往對(duì)數(shù)據(jù)的強(qiáng)一致性和高可靠性有嚴(yán)格要求。強(qiáng)一致性：A給B轉(zhuǎn)賬100元，系統(tǒng)返回A轉(zhuǎn)賬成功。此后B查詢余額時(shí)應(yīng)該能顯示收到100元，如果發(fā)現(xiàn)并未收到或隔一段時(shí)間后才收到，那這樣的系統(tǒng)非強(qiáng)一致性;高可靠性：一個(gè)請(qǐng)求如果返回客戶成功，那么需要保證請(qǐng)求結(jié)果不丟失。
在對(duì)主流的消息中間件進(jìn)行調(diào)研后，發(fā)現(xiàn)它們?cè)趹?yīng)對(duì)這種場(chǎng)景時(shí)都存在一定的不足：
RabbitMQ：一個(gè)請(qǐng)求需要在所有節(jié)點(diǎn)上處理2次才能保證一致性，性能不高。
Kafka：kafka主要應(yīng)用在日志、大數(shù)據(jù)等方向，少量丟失數(shù)據(jù)業(yè)務(wù)可以忍受，但不適合要求數(shù)據(jù)高可靠性的系統(tǒng)。
RocketMQ：未采用一致性算法，如果配置成異步模式可能丟失數(shù)據(jù)，同步模式下節(jié)點(diǎn)故障或網(wǎng)絡(luò)分區(qū)都會(huì)影響可用性。
SQS：只提供最終一致性，不保證強(qiáng)一致性。
鑒于以上分析，我們?cè)O(shè)計(jì)開發(fā)了基于Raft的強(qiáng)一致高可靠消息中間件CMQ。接下來(lái)會(huì)詳細(xì)介紹raft算法原理細(xì)節(jié)、如何應(yīng)用在CMQ中在保證消息可靠不丟失以及實(shí)現(xiàn)過(guò)程中我們?cè)谛阅芊矫嫠鞯膬?yōu)化。
二 Raft算法核心原理
2.1 概述
raft算法是Diego Ongaro博士在論文《In Search of an Understandable Consensus Algorithm》,2014 USENIX中***提出，算法主要包括選舉和日志同步兩部分:
***階段 選舉：
- 從集群中選出一個(gè)合適的節(jié)點(diǎn)作為L(zhǎng)eader。
第二階段 日志同步：
- 選舉出的Leader接收客戶端請(qǐng)求，將其轉(zhuǎn)為raft日志。
- Leader將日志同步到其他節(jié)點(diǎn)，當(dāng)大多數(shù)節(jié)點(diǎn)寫入成功后，日志變?yōu)镃ommitted，一經(jīng)Committed日志便不會(huì)再被篡改。
- Leader故障時(shí)，切換到***階段，重新選舉。
以下是貫穿raft算法的重要術(shù)語(yǔ)：
Term： 節(jié)點(diǎn)當(dāng)前所處的周期，可以看作一個(gè)文明所處的時(shí)代。
votedFor： 當(dāng)前Term的投票信息，每個(gè)節(jié)點(diǎn)在給定的Term上只能投票一次。
Entry： raft日志中的基本單元，包含index、term和user_data。其中index在日志文件中順序分配，term為創(chuàng)建該entry的leader term，user_data 業(yè)務(wù)數(shù)據(jù)。
State : 節(jié)點(diǎn)角色(Leader、Candidate、Follower之一)。
CommitIndex：已提交到的日志Index。
State Machine：狀態(tài)機(jī)。業(yè)務(wù)模塊，與Raft交互。
ApplyIndex：已應(yīng)用到的日志Index。
ElectionTime：選舉超時(shí)時(shí)間。
節(jié)點(diǎn)之間通過(guò)RPC通信來(lái)完成選舉和日志同步，發(fā)送方在發(fā)送RPC時(shí)會(huì)攜帶自身的Term，接收方在處理RPC時(shí)有以下兩條通用規(guī)則：
- RPC中的RTerm大于自身當(dāng)前Term，更新自身Term = RTerm、votedFor = null，轉(zhuǎn)為Follower。
- RPC中的RTerm小于自身當(dāng)前Term，拒絕請(qǐng)求，響應(yīng)包中攜帶自身的Term。
2.2 選舉
Raft算法屬于強(qiáng)Leader模式，只有Leader可以處理客戶端的請(qǐng)求，Leader通過(guò)心跳維持自身地位，除非Leader故障或網(wǎng)絡(luò)異常，否則Leader保持不變。選舉階段的目的就是為了從集群中選出合適的Leader節(jié)點(diǎn)。
選舉流程：
1.節(jié)點(diǎn)初始狀態(tài)均為Follower，F(xiàn)ollower只被動(dòng)接收請(qǐng)求，如果ElectionTime到期時(shí)仍未收到Leader的AppendEntry RPC，F(xiàn)ollower認(rèn)為當(dāng)前沒有Leader，轉(zhuǎn)為Candidate。
2.Candidate在集群中廣播RequestVote RPC，嘗試競(jìng)選Leader，其他節(jié)點(diǎn)收到后首先判斷是否同意本次選舉，并將結(jié)果返回給Candidate。如果Candidate收到大多數(shù)節(jié)點(diǎn)的同意響應(yīng)，轉(zhuǎn)為L(zhǎng)eader。
3.Leader接收客戶端請(qǐng)求，將其轉(zhuǎn)為Entry追加到日志文件，同時(shí)通過(guò)AppendEntry RPC同步日志Entry給其他節(jié)點(diǎn)。
下面通過(guò)一個(gè)案例詳細(xì)說(shuō)明選舉流程。
1)初始狀態(tài)：3個(gè)節(jié)點(diǎn)組成的集群，初始均為Follower狀態(tài)，圖中方格部分代表節(jié)點(diǎn)的raft日志。
2)發(fā)起選舉：節(jié)點(diǎn)1選舉定時(shí)器先到期，轉(zhuǎn)為Candidate，Term自增，更新voteFor=1(投票給自己)，接著廣播RequestVote RPC給集群中其他節(jié)點(diǎn)，RequestVote RPC會(huì)攜帶節(jié)點(diǎn)的日志信息。
3)響應(yīng)選舉：節(jié)點(diǎn)2和3收到RequestVote RPC后，根據(jù)RPC規(guī)則，更新term和voteFor(term:6 , voteFor:null );然后判斷是否同意本次選舉，如果已投票給別人，則拒絕本次選舉(這里voteFor：null 未投票)，如果RequestVote RPC中的日志沒有自身全，也拒絕，否則同意(這里節(jié)點(diǎn)1的日志比2、3都更全);***通過(guò)voteReply RPC響應(yīng)投票結(jié)果。
4)選舉完成：由于節(jié)點(diǎn)2和3都同意本次選舉，所以節(jié)點(diǎn)1在收到任何一個(gè)的voteReply RPC便轉(zhuǎn)為L(zhǎng)eader(大多數(shù)同意即可)。
選舉超時(shí)值：
在選舉時(shí)可能會(huì)出現(xiàn)兩個(gè)節(jié)點(diǎn)的選舉定時(shí)器同時(shí)到期并發(fā)起選舉，各自得到一半選票導(dǎo)致選舉失敗，選舉失敗意味著系統(tǒng)沒有Leader，不可服務(wù)。如果選舉定時(shí)器是定值，很可能兩者再次同時(shí)到期。為了降低沖突的概率，選舉超時(shí)值采用隨機(jī)值的方式。此外，選舉超時(shí)值如果過(guò)大會(huì)導(dǎo)致Leader故障會(huì)很久才會(huì)再次選舉。選舉超時(shí)值通常取300ms~600ms之間的隨機(jī)值。
2.3日志同步
選舉階段完成后，Leader節(jié)點(diǎn)開始接收客戶端請(qǐng)求，將請(qǐng)求封裝成Entry追加到raft日志文件末尾，之后同步Entry到其他Follower節(jié)點(diǎn)。當(dāng)大多數(shù)節(jié)點(diǎn)寫入成功后，該Entry被標(biāo)記為committed，raft算法保證了committed的Entry一定不會(huì)再被修改。
日志同步具體流程：
1)Leader上為每個(gè)節(jié)點(diǎn)維護(hù)NextIndex、MatchIndex，NextIndex表示待發(fā)往該節(jié)點(diǎn)的Entry index，MatchIndex表示該節(jié)點(diǎn)已匹配的Entry index，同時(shí)每個(gè)節(jié)點(diǎn)維護(hù)CommitIndex表示當(dāng)前已提交的Entry index。轉(zhuǎn)為L(zhǎng)eader后會(huì)將所有節(jié)點(diǎn)的NextIndex置為自己***一條日志index+1，MatchIndex全置0，同時(shí)將自身CommitIndex置0。
2)Leader節(jié)點(diǎn)不斷將user_data轉(zhuǎn)為Entry追加到日志文件末尾，Entry包含index、term和user_data，其中index在日志文件中從1開始順序分配，term為L(zhǎng)eader當(dāng)前的term。
3)Leader通過(guò)AppendEntry RPC將Entry同步到Followers，F(xiàn)ollower收到后校驗(yàn)該Entry之前的日志是否已匹配。如匹配則直接寫入Entry，返回成功;否則刪除不匹配的日志，返回失敗。校驗(yàn)是通過(guò)在AppendEntry RPC中攜帶待寫入Entry的前一條entry信息完成。
4)當(dāng)Follower返回成功時(shí)，更新對(duì)應(yīng)節(jié)點(diǎn)的NextIndex和MatchIndex，繼續(xù)發(fā)送后續(xù)的Entry。如果MatchIndex更新后，大多數(shù)節(jié)點(diǎn)的MatchIndex已大于CommitIndex，則更新CommitIndex。Follower返回失敗時(shí)回退NextIndex繼續(xù)發(fā)送，直到Follower返回成功。
5)Leader每次AppendEntry RPC中會(huì)攜帶當(dāng)前***的LeaderCommitIndex，F(xiàn)ollower寫入成功時(shí)會(huì)將自身CommitIndex更新為Min(LastLogIndex,LeaderCommitIndex)。
同步過(guò)程中每次日志的寫入均需刷盤以保證宕機(jī)時(shí)數(shù)據(jù)不丟失。
下面通過(guò)一個(gè)例子介紹日志同步基本流程：
1)初始狀態(tài)所有節(jié)點(diǎn)的Term=2，CommitIndex=2，接著Leader收到一條y←9的請(qǐng)求，轉(zhuǎn)為Entry寫入日志的末尾，Entry的index =3 term =1。
2)Leader通過(guò)AppendEntry RPC同步該Entry給2個(gè)Follower，RPC中包含前一條Entry信息(index=2 term =1)，F(xiàn)ollower收到后首先校驗(yàn)前一條Entry是否與自身匹配(這里匹配成功)，之后寫入該Entry，返回Leader成功。
3)Leader在收到Follower的回包后，更新相應(yīng)節(jié)點(diǎn)的NextIndex和MatchIndex，這時(shí)大多數(shù)節(jié)點(diǎn)MatchIndex已經(jīng)大于CommitIndex，所以Leader更新CommitIndex=3。
4)Leader繼續(xù)發(fā)送AppendEntry到Follower，此時(shí)由于沒有新Entry，所以RPC中entry信息為空，LeaderCommitIndex為3。Follower收到后更新CommitIndex=3 (Min(3,3))。
日志沖突：
在日志同步的過(guò)程中，可能會(huì)出現(xiàn)節(jié)點(diǎn)之間日志不一致的問(wèn)題。例如Follower寫日志過(guò)慢、Leader切換導(dǎo)致舊Leader上未提交的臟數(shù)據(jù)等場(chǎng)景下都會(huì)發(fā)生。在Raft算法中，日志沖突時(shí)以Leader的日志為準(zhǔn)，F(xiàn)ollower刪除不匹配部分。
如下圖所示，F(xiàn)ollower節(jié)點(diǎn)與Leader節(jié)點(diǎn)的日志都存在不一致問(wèn)題，其中(a)、(b)節(jié)點(diǎn)日志不全，(c)、(d)、(e)、(f)有沖突日志。Leader首先從index=11(***一條Entry index +1)開始發(fā)送AppendEntry RPC,Follower均返回不匹配，Leader收到后不斷回退。(a)、(b)在找到***條匹配的日志后正常同步，(c)、(d)、(e)、(f)在這個(gè)過(guò)程中會(huì)逐步刪除不一致的日志，最終所有節(jié)點(diǎn)的日志都與Leader一致。成為L(zhǎng)eader節(jié)點(diǎn)后不會(huì)修改和刪除已存在的日志，只會(huì)追加新的日志。
2.4 算法證明
Raft算法的2個(gè)核心屬性：
1)已提交的日志不會(huì)再修改;(可靠性)
2)所有節(jié)點(diǎn)上的數(shù)據(jù)一致。(一致性)
具體證明如下：
1)Leader Completeness：給定Term上提交的日志一定存在于后續(xù)更高Term的 Leader上。(日志不丟失)
- 選舉出的Leader一定包含當(dāng)前已提交所有日志：已提交的日志存在于大多數(shù)節(jié)點(diǎn)上，而同意選舉的前提是候選者的日志必須夠全或更新。一個(gè)不包含已提交日志的節(jié)點(diǎn)必然不會(huì)得到大多數(shù)節(jié)點(diǎn)的選票(這些節(jié)點(diǎn)上都有已提交的日志，不滿足日志足夠全的前提)，也就無(wú)法成為L(zhǎng)eader。
- Leader節(jié)點(diǎn)不修改和刪除已存在日志(算法的約束)。
綜上所述，選舉和日志同步時(shí)都不會(huì)破壞已提交的日志，得證。
2)State Machine Safety：所有節(jié)點(diǎn)的數(shù)據(jù)最終一致。
根據(jù)Leader Completeness可知已提交的日志不會(huì)再修改，業(yè)務(wù)的狀態(tài)機(jī)依次取出Entry中的user_data應(yīng)用，最終所有節(jié)點(diǎn)的數(shù)據(jù)一致。
2.5集群管理
Raft算法中充分考慮了工程化中集群管理問(wèn)題，支持動(dòng)態(tài)的添加節(jié)點(diǎn)到集群，剔除故障節(jié)點(diǎn)等。下面詳細(xì)描述添加和刪除節(jié)點(diǎn)流程。
- 添加節(jié)點(diǎn)
如下圖所示，集群中包含A B C，A為L(zhǎng)eader，現(xiàn)在添加節(jié)點(diǎn)D。
1)清空D節(jié)點(diǎn)上的所有數(shù)據(jù)，避免有臟數(shù)據(jù)。
2)Leader將存量的日志通過(guò)AppendEntry RPC同步到D，使D的數(shù)據(jù)跟上其他節(jié)點(diǎn)。
3)待D的日志追上后，Leader A創(chuàng)建一條Config Entry，其中集群信息包含ABCD。
4)Leader A將Config Entry同步給B C D，F(xiàn)ollower收到后應(yīng)用，之后所有節(jié)點(diǎn)的集群信息都變?yōu)锳BCD，添加完成。
注：在步驟2過(guò)程中,Leader仍在不斷接收客戶請(qǐng)求生成Entry，所以只要D與A日志相差不大即認(rèn)為D已追上。
- 刪除節(jié)點(diǎn)
如下圖所示，集群中原來(lái)包含A B C D，A為L(zhǎng)eader，現(xiàn)在剔除節(jié)點(diǎn)D。
1) Leader A創(chuàng)建一條Config Entry，其中集群信息為ABC。
2) A將日志通過(guò)AppendEntry RPC同步給節(jié)點(diǎn)B C。
3) A B C在應(yīng)用該日志后集群信息變?yōu)锳BC，A不再發(fā)送AppendEntry給D，D從集群中移除。
4) 此時(shí)D的集群信息依舊為ABCD，在選舉超時(shí)到期后，發(fā)起選舉，為了防止D的干擾，引入額外機(jī)制：所有節(jié)點(diǎn)在正常接收Leader的AppendEntry時(shí)，拒絕其他節(jié)點(diǎn)發(fā)來(lái)的選舉請(qǐng)求。
5) 將D的數(shù)據(jù)清空并下線。
2.5 Raft應(yīng)用
我們用State Matchine統(tǒng)一表示業(yè)務(wù)模塊，其通過(guò)ApplyIndex維護(hù)已應(yīng)用到的日志index。以下為Raft與狀態(tài)機(jī)交互的流程：
1)客戶端請(qǐng)求發(fā)往Leader節(jié)點(diǎn)。
2)Leader節(jié)點(diǎn)的Raft模塊將請(qǐng)求轉(zhuǎn)為Entry并同步到Followers。
3)大多數(shù)節(jié)點(diǎn)寫入成功后Raft模塊更新CommitIndex。
4)各節(jié)點(diǎn)的State Machine順序讀取ApplyIndex+1到CimmitIndex之間的Entry，取出其中的user_data并應(yīng)用，完成后更新ApplyIndex。
5)Leader 上的State Machine通知客戶端操作成功。
6)如此循環(huán)。
2.6 快照管理
在節(jié)點(diǎn)重啟時(shí)，由于無(wú)法得知State Matchine當(dāng)前ApplyIndex(除非每次應(yīng)用完日志都持久化ApplyIndex，還要保證是原子操作，代價(jià)較大)，所以必須清空State Matchine的數(shù)據(jù)，將ApplyIndex置為0,，從頭開始應(yīng)用日志，代價(jià)太大，可以通過(guò)定期創(chuàng)建快照的方式解決該問(wèn)題。如下圖所示：
1) 在應(yīng)用完Entry 5 后，將當(dāng)前State Matchine的數(shù)據(jù)連同Entry信息寫入快照文件。
2) 如果節(jié)點(diǎn)重啟，首先從快照文件中恢復(fù)State Matchine，等價(jià)于應(yīng)用了截止到Entry 5為止的所有Entry，但效率明顯提高。
3) 將ApplyIndex置為5，之后從Entry 6繼續(xù)應(yīng)用日志，數(shù)據(jù)和重啟前一致。
快照的優(yōu)點(diǎn)：
- 降低重啟耗時(shí)：通過(guò)snapshot + raft log恢復(fù)，無(wú)需從***條Entry開始。
- 節(jié)省空間：快照做完后即可刪除快照點(diǎn)之前的Raft日志。
2.7異常場(chǎng)景及處理
Raft具有很強(qiáng)的容錯(cuò)性，只要大多數(shù)節(jié)點(diǎn)正常互聯(lián)，即可保證系統(tǒng)的一致性和可用性，下面是一些常見的異常情況，以及他們的影響及處理：
可以看到異常情況對(duì)系統(tǒng)的影響很小，即使是Leader故障也可以在極短的時(shí)間內(nèi)恢復(fù)，任何情況下系統(tǒng)都一直保持強(qiáng)一致性，為此犧牲了部分可用性(大多數(shù)節(jié)點(diǎn)故障時(shí)，概率極低)。不過(guò)，Leader故障時(shí)新的Leader可能會(huì)包含舊Leader未提交或已提交但尚未通知客戶端的日志，由于算法規(guī)定成為L(zhǎng)eader后不允許刪除日志，所以這部分日志會(huì)被新Leader同步并提交，但由于連接信息丟失，客戶端無(wú)法得知該情況，當(dāng)發(fā)起重試后會(huì)出現(xiàn)重復(fù)數(shù)據(jù)，需要有冪等性保證。此外，raft的核心算法都是圍繞Leader展開，網(wǎng)絡(luò)分區(qū)時(shí)可能出現(xiàn)偽Leader問(wèn)題，也需要特殊考慮。
以下是網(wǎng)絡(luò)分區(qū)時(shí)產(chǎn)生偽Leader 的過(guò)程：
上述情況下，Leader與2個(gè)Follower網(wǎng)絡(luò)異常，而2個(gè)Follower之間通信正常，由于收不到Leader的心跳，其中一個(gè)Follower發(fā)起選舉并成為L(zhǎng)eader，原Leader成為偽Leader，接下來(lái)我們分析該場(chǎng)景下是否會(huì)影響系統(tǒng)的一致性：
寫一致性：發(fā)往新Leader的寫請(qǐng)求可以被提交，而發(fā)往偽Leader的請(qǐng)求無(wú)法得到提交，只有一個(gè)Leader在正常處理寫請(qǐng)求，所以不影響寫一致性。
讀一致性：如果讀請(qǐng)求不經(jīng)過(guò)Raft同步，那么當(dāng)客戶端的寫請(qǐng)求被發(fā)往新Leader并執(zhí)行成功后，讀請(qǐng)求發(fā)往了偽Leader并得到結(jié)果，就會(huì)造成數(shù)據(jù)不一致。有兩種方案可以解決該問(wèn)題：
讀請(qǐng)求也經(jīng)過(guò)Raft同步，這樣就不會(huì)有不一致的問(wèn)題，但會(huì)增加系統(tǒng)負(fù)載。
讀請(qǐng)求收到后，Leader節(jié)點(diǎn)等待大多數(shù)節(jié)點(diǎn)再次響應(yīng)心跳RPC，接著返回結(jié)果。
因?yàn)榇蠖鄶?shù)節(jié)點(diǎn)響應(yīng)心跳，說(shuō)明當(dāng)前一定沒有另一個(gè)Leader存在(大多數(shù)節(jié)點(diǎn)還與當(dāng)前Leader維持租約，新Leader需要得到大多數(shù)投票)。
2.8 小結(jié)
Raft算法具備強(qiáng)一致、高可靠、高可用等優(yōu)點(diǎn)，具體體現(xiàn)在：
強(qiáng)一致性：雖然所有節(jié)點(diǎn)的數(shù)據(jù)并非實(shí)時(shí)一致，但Raft算法保證Leader節(jié)點(diǎn)的數(shù)據(jù)最全，同時(shí)所有請(qǐng)求都由Leader處理，所以在客戶端角度看是強(qiáng)一致性的。
高可靠性：Raft算法保證了Committed的日志不會(huì)被修改，State Matchine只應(yīng)用Committed的日志，所以當(dāng)客戶端收到請(qǐng)求成功即代表數(shù)據(jù)不再改變。Committed日志在大多數(shù)節(jié)點(diǎn)上冗余存儲(chǔ)，少于一半的磁盤故障數(shù)據(jù)不會(huì)丟失。
高可用性：從Raft算法原理可以看出，選舉和日志同步都只需要大多數(shù)的節(jié)點(diǎn)正常互聯(lián)即可，所以少量節(jié)點(diǎn)故障或網(wǎng)絡(luò)異常不會(huì)影響系統(tǒng)的可用性。即使Leader故障，在選舉超時(shí)到期后，集群自發(fā)選舉新Leader，無(wú)需人工干預(yù)，不可用時(shí)間極小。但Leader故障時(shí)存在重復(fù)數(shù)據(jù)問(wèn)題，需要業(yè)務(wù)去重或冪等性保證。
高性能：與必須將數(shù)據(jù)寫到所有節(jié)點(diǎn)才能返回客戶端成功的算法相比，Raft算法只需要大多數(shù)節(jié)點(diǎn)成功即可，少量節(jié)點(diǎn)處理緩慢不會(huì)延緩整體系統(tǒng)運(yùn)行。
原文鏈接：https://cloud.tencent.com/community/article/678192
【本文是51CTO專欄作者“騰訊云技術(shù)社區(qū)”的原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)通過(guò)51CTO聯(lián)系原作者獲取授權(quán)】
