Raft是一種為了管理日志復(fù)制的一致性算法氓辣。它提供了和Paxos算法相同的功能和性能秒裕，但是它的算法結(jié)構(gòu)和Paxos不同，使得Raft算法更加容易理解并且更容易構(gòu)建實(shí)際的系統(tǒng)钞啸。為了提升可理解性几蜻，Raft將一致性算法分解成幾個關(guān)鍵的模塊，例如領(lǐng)導(dǎo)選舉,日志復(fù)制和安全性体斩。同時它通過實(shí)施一個更強(qiáng)的一致性來減少需要考慮的狀態(tài)和數(shù)量梭稚。從一個用戶研究的結(jié)果可以證明，對于學(xué)生而言絮吵，Raft算法比Paxos算法更容易學(xué)弧烤。Raft算法還包括了新的機(jī)制來允許集群成員的動態(tài)改變，讓利用重疊的大多數(shù)來保證安全性源武。
Raft算法概述
Raft算法是從多副本狀態(tài)機(jī)的角度提出扼褪，用于管理多副本狀態(tài)機(jī)的日志復(fù)制，它一致性分解為多個子問題：領(lǐng)導(dǎo)選舉(Leader election)粱栖，日志復(fù)制(Log replication),安全性(Safety),日志壓縮(Log compaction),成員變更(Menbership change)等话浇。同時，Raft算法使用了更強(qiáng)的假設(shè)來減少需要考慮的狀態(tài)闹究，使之變得更加容易理解幔崖。
Raft講系統(tǒng)中的角色分為領(lǐng)導(dǎo)者(Leader),跟從者(Follower)和候選人(Candidate)：
Leader: 接收客戶端請求，并向Follower同步請求日志。當(dāng)日志同步到大都數(shù)節(jié)點(diǎn)上后告告訴Follower提交日志赏寇。
Follower:接收并持久化Leader同步的日志吉嫩，在Leader告訴它的日志提交之后，提交日志嗅定。
Candidate:Leader選舉過程中的臨時角色自娩。
Raft要求系統(tǒng)在任意時刻最多只有一個Leader,正常工作期間Leader和Followers。
Raft算法角色狀態(tài)轉(zhuǎn)換如下:
跟隨者只響應(yīng)來自其他服務(wù)器的請求渠退。如果跟隨者接收不到消息忙迁，那么它就會變成候選人并發(fā)起一次選舉。獲得集群中大多數(shù)選票的候選人將成為領(lǐng)導(dǎo)者碎乃。在一個任期內(nèi)姊扔，領(lǐng)導(dǎo)人直到自己宕機(jī)了。
Raft算法時間被劃分成為一個個的任期(Term)梅誓，每個任期(Term)開始都是一次Leader選舉恰梢。選舉成功后，領(lǐng)導(dǎo)人會管理整個集群直到任期(Term)結(jié)束梗掰。有時候會選舉失敗嵌言，那么任期(Term)就會沒有領(lǐng)導(dǎo)者，而結(jié)束及穗。任期(Term)之間的切換可以在不同的時間不同的服務(wù)器上觀察到呀页。
Raft算法中服務(wù)器之間節(jié)點(diǎn)通信使用遠(yuǎn)程調(diào)用(RPCs).而在etcd的實(shí)現(xiàn)當(dāng)中v2版本用的http，而v3版本采用的是grpc(本身是跨平臺)拥坛。并且基本的一致性算法只是用了兩種類型的Rpcs。請求投票(RequestVote)RPCs由候選人發(fā)起尘分。然后附加條目數(shù)(AppendEntries)由Leader發(fā)起猜惋。用來復(fù)制日志和提供一種心跳機(jī)制。為了服務(wù)器之間傳輸快照增加了第三種RPCs培愁。當(dāng)服務(wù)器沒有及時收到RPC的響應(yīng)時著摔，會進(jìn)行重試，并且它們能夠并行發(fā)起RPCs來獲取最佳性能定续。
復(fù)制狀態(tài)機(jī)
一組服務(wù)器上的狀態(tài)機(jī)產(chǎn)生相同狀態(tài)的副本谍咆，并且在一些機(jī)器宕掉的情況下也可以繼續(xù)運(yùn)行。復(fù)制狀態(tài)機(jī)在分布式系統(tǒng)中被用于解決很多容錯的問題私股。例如摹察，大規(guī)模的系統(tǒng)中通常都有一個集群領(lǐng)導(dǎo)者，像 GFS倡鲸、HDFS 和 RAMCloud供嚎，典型應(yīng)用就是一個獨(dú)立的的復(fù)制狀態(tài)機(jī)去管理領(lǐng)導(dǎo)選舉和存儲配置信息并且在領(lǐng)導(dǎo)人宕機(jī)的情況下也要存活下來。比如 Chubby 和 ZooKeeper。
復(fù)制狀態(tài)機(jī)的結(jié)構(gòu)克滴。一致性算法管理著來自客戶端指令的復(fù)制日志逼争。狀態(tài)機(jī)從日志中處理相同順序的相同指令，所以產(chǎn)生的結(jié)果也是相同的劝赔。
復(fù)制狀態(tài)機(jī)通常都是基于復(fù)制日志實(shí)現(xiàn)的誓焦，如圖 1。每一個服務(wù)器存儲一個包含一系列指令的日志着帽，并且按照日志的順序進(jìn)行執(zhí)行杂伟。每一個日志都按照相同的順序包含相同的指令，所以每一個服務(wù)器都執(zhí)行相同的指令序列启摄。因?yàn)槊總€狀態(tài)機(jī)都是確定的稿壁，每一次執(zhí)行操作都產(chǎn)生相同的狀態(tài)和同樣的序列。
保證復(fù)制日志相同就是一致性算法的工作了歉备。在一臺服務(wù)器上傅是，一致性模塊接收客戶端發(fā)送來的指令然后增加到自己的日志中去。它和其他服務(wù)器上的一致性模塊進(jìn)行通信來保證每一個服務(wù)器上的日志最終都以相同的順序包含相同的請求蕾羊，盡管有些服務(wù)器會宕機(jī)喧笔。一旦指令被正確的復(fù)制，每一個服務(wù)器的狀態(tài)機(jī)按照日志順序處理他們龟再，然后輸出結(jié)果被返回給客戶端书闸。因此，服務(wù)器集群看起來形成一個高可靠的狀態(tài)機(jī)利凑。
實(shí)際系統(tǒng)中使用的一致性算法通常含有以下特性：
安全性保證（絕對不會返回一個錯誤的結(jié)果）：在非拜占庭錯誤情況下浆劲，包括網(wǎng)絡(luò)延遲、分區(qū)哀澈、丟包牌借、冗余和亂序等錯誤都可以保證正確。
可用性：集群中只要有大多數(shù)的機(jī)器可運(yùn)行并且能夠相互通信割按、和客戶端通信膨报，就可以保證可用。因此适荣，一個典型的包含 5 個節(jié)點(diǎn)的集群可以容忍兩個節(jié)點(diǎn)的失敗现柠。服務(wù)器被停止就認(rèn)為是失敗。他們當(dāng)有穩(wěn)定的存儲的時候可以從狀態(tài)中恢復(fù)回來并重新加入集群弛矛。
不依賴時序來保證一致性：物理時鐘錯誤或者極端的消息延遲在可能只有在最壞情況下才會導(dǎo)致可用性問題够吩。
通常情況下，一條指令可以盡可能快的在集群中大多數(shù)節(jié)點(diǎn)響應(yīng)一輪遠(yuǎn)程過程調(diào)用時完成丈氓。小部分比較慢的節(jié)點(diǎn)不會影響系統(tǒng)整體的性能废恋。
Leader選舉
Raft使用心跳(heartbeat)觸發(fā)Leader選舉谈秫。當(dāng)服務(wù)器啟動時，初始化Follower鱼鼓。Leader向所有的Followers周期性的發(fā)送heartbeat拟烫。如果Follower在選舉超時時間內(nèi)沒有收到Leader的heartbeat，就會等待一段隨機(jī)時間(150ms-300ms)發(fā)起一次選舉迄本。
Follower先要增加自己的當(dāng)前任期號硕淑，也就把當(dāng)前的任期號加一并且轉(zhuǎn)換到候選人狀態(tài)。然后它們會并行的向集群中的其他服務(wù)器節(jié)點(diǎn)發(fā)起請求投票的RPCs來給自己投票嘉赎。結(jié)果會有以下三種情況:
- 它自己贏得了這次選舉
- 其他的服務(wù)器成為了領(lǐng)導(dǎo)者
- 一段世家之后沒有人獲取勝利的人置媳。
日志復(fù)制
Leader被選舉出來后.它就開始為客戶端提供服務(wù)，客戶端每個請求都包含一條被復(fù)制狀態(tài)機(jī)執(zhí)行的命令公条。領(lǐng)導(dǎo)人將這條指令作為新的日志條目附加到日志中去拇囊。然后并行的發(fā)起附加條目RPCs給其他的服務(wù)器，讓它們復(fù)制這個日志條目靶橱，當(dāng)這條日志條目被安全的復(fù)制寥袭。領(lǐng)導(dǎo)人會應(yīng)用這條日志條目到它的狀態(tài)中然后把執(zhí)行的結(jié)果返回客戶端。如果Follower崩潰或者運(yùn)行緩慢关霸，再或者網(wǎng)絡(luò)丟包传黄，領(lǐng)導(dǎo)人會不斷的嘗試附加日志條目RPCs(盡管已經(jīng)回復(fù)了客戶端)直到所有Follower都最終存儲了所有條目數(shù)。
日志由有序編號(log index)的日志組成條目队寇。每個日志條目包含它被創(chuàng)建的任期號(term),和用于狀態(tài)機(jī)執(zhí)行的命令膘掰。如果一個日志條目被復(fù)制到大多數(shù)服務(wù)器上,就被認(rèn)為可以提交了(commit)了。
Raft維護(hù)著一下特征:
1.如果在不同的日志中的兩個條目擁有相同的索引和任期號,那么它們存儲了相同的指令佳遣。
2.如果在不同的日志中的兩個條目擁有相同的索引和任期號,那么他們的之前的所有日志條目也全部相同识埋。
第一個特新來這樣的一個事實(shí),領(lǐng)導(dǎo)人最多在一個任期里在指定的日志索引位置創(chuàng)建一條日志條目，同時日志條目在日志中的位置也從來不會改變零渐。第二個特性由附加日志RPC的一個簡單一致性檢查保證惭聂。在發(fā)送附加日志RPC的時候，領(lǐng)導(dǎo)人會把新的日志條目緊接著之前的條目索引位置和任期號包含在里面相恃。如果跟隨者在它的日志中找不到包含相同的日志索引位置和任期號的條目,那么他就會拒絕接收新的條目日志。一致性檢查就像一個歸納步驟:一開始空日志狀態(tài)肯定是滿足日志匹配特性的笨觅，然后一致性檢查保護(hù)了日志匹配特性當(dāng)日志擴(kuò)展的時候拦耐。因此,每當(dāng)附加日志RPC返回成功時，領(lǐng)導(dǎo)人就知道跟隨著的日志時一樣的了见剩。
當(dāng)一個領(lǐng)導(dǎo)人成功當(dāng)選時杀糯，跟隨者可能是任何情況(a-f)。每一個盒子表示是一個日志條目苍苞，里面的數(shù)字表示任期號固翰。跟隨者可能缺少一些體制條目(a-b)狼纬，可能會有一些未被提交的日志條目(c-d)，或者兩種情況都存在的(e-f)骂际。例如,場景f可能會發(fā)生疗琉，某些服務(wù)器在任期號2的時候是領(lǐng)導(dǎo)人，已附加了一些日志條目到自己的日志中歉铝，但在提交之前就就崩潰了,很快這個機(jī)器就被重啟了,在任期3重新被選為領(lǐng)導(dǎo)人盈简，并且又增加了一些日志條目到自己的日志中,并且又增加了一些日志條目到自己的日志中，在任期2和任期3的日志被提交之前太示，這個服務(wù)器又宕機(jī)了柠贤，并且在接下來的幾個任期里一直處于宕機(jī)狀態(tài)。
要使得跟隨著的日志進(jìn)入和自己一致的狀態(tài)类缤，領(lǐng)導(dǎo)人必須找到最后兩者達(dá)成一致的地方臼勉，然后刪除那個點(diǎn)之后的所有日志條目，發(fā)送自己的日志給跟隨者餐弱。所有的這些日志操作都在進(jìn)行附加日志RPCs的一致性檢查時完成宴霸。領(lǐng)導(dǎo)人針對沒一個維護(hù)者維護(hù)了一個nextIndex,這表示下一個發(fā)送給追隨者的日志條目的索引地址。當(dāng)一個領(lǐng)導(dǎo)人剛獲得領(lǐng)導(dǎo)者的權(quán)利的時候岸裙，他初始化所有的nextIndex值作為自己的最后一條日志的index加1猖败。如果一個跟隨者的日志和領(lǐng)導(dǎo)人不一致，那么下一次日志附RPC時的一致性檢查就會失敗降允。在被跟隨者拒絕之后恩闻，領(lǐng)導(dǎo)人就會減少nextIndex值并進(jìn)行重試。最終nextIndex會在某個位置使得領(lǐng)導(dǎo)人和跟隨者的日志達(dá)成一致剧董。當(dāng)這種情況發(fā)生幢尚，附加日志RPC就會成功，這時就會把跟隨者沖突的日志條目全部刪除并且加上領(lǐng)導(dǎo)人的日志翅楼。一旦附加日志RPC成功尉剩，那么跟隨者的日志就會和領(lǐng)導(dǎo)人保持一直，并且在接下來的任期里一直繼續(xù)保持毅臊。
安全性
Raft增加了如下兩條限制以保證安全性:
1>擁有最新的已提交的log entry的Follower才有資格成為Leader理茎。
這個保證是在RequestVote RPC中做的，Candidate在發(fā)送RequestVote RPC時管嬉。要帶上自己的最后一條日志的term和log Index皂林。其他節(jié)點(diǎn)收到消息時，如果發(fā)現(xiàn)自己的日志請求中攜帶的更新蚯撩，則拒絕投票础倍。日志比較的原則是:如果本地的最后一條log entry的term更大，則term大更新胎挎，如果term一樣大沟启，則log Index更大的更新忆家。
2.Leader只能推進(jìn)commit Index來提交當(dāng)前term已經(jīng)復(fù)制最到最大服務(wù)器上的日志，舊term日志的日志要等到提交當(dāng)前的term的日志來間接提交(log Index 小于commit Index的日志被間接提交)
之所以要這樣德迹，是因?yàn)榭赡軙霈F(xiàn)已提交的日志被覆蓋的情況:
如圖的時間序列展示了領(lǐng)導(dǎo)人無法決定對老任期號的日志條目進(jìn)行提交芽卿。在(a)中，S1是Leader浦辨，部分的是復(fù)制了索引的位置2的條目數(shù)目蹬竖。(b)是時期，S1崩潰了流酬，然后S5在任期3里通過S3,S4和自己的選票贏得選舉币厕，然后從客戶端接收了一條不一樣的日志條目放在了索引2處。然后到(c),S5崩潰了芽腾，S1重新啟動旦装，選舉成功，開始日志復(fù)制摊滔。在這個時候阴绢，來自任期2的那條日志已經(jīng)被復(fù)制到了集群的大多數(shù)機(jī)器上，但是還沒有被提交艰躺，如果S1在(d)時期中又崩潰了呻袭。S5可以重新被選舉成功(通過來自S2,S3,S4的選票)，然后覆蓋了他門在索引2處的日志腺兴。反之左电，如果在崩潰之前，S1把自己主導(dǎo)的任期里產(chǎn)生的日志日條目復(fù)制到了大多數(shù)機(jī)器上页响，就如(e)中那樣篓足。那么在后面任期里面這些新的日志條目會被提交(因?yàn)镾5就不可能選舉成功)。這牙膏在同一時刻就同時保證了闰蚕，之前的所有老的日志條目就會被提交栈拖。
時間和可用性
Raft的要求之一就是安全性不能依賴時間:整個系統(tǒng)不能因?yàn)槟承┦录\(yùn)行的比預(yù)期快一點(diǎn)或者慢一點(diǎn)產(chǎn)生了錯誤的結(jié)果。但是没陡，可用性(系統(tǒng)可以及時的響應(yīng)客戶端)不可避免的要依賴時間涩哟。例如，如果消息交換比服務(wù)器故障間隔時間長盼玄，候選人沒有足夠長的時間來贏得選舉贴彼，沒有一個穩(wěn)定的領(lǐng)導(dǎo)人，Raft將無法工作强岸。
領(lǐng)導(dǎo)人選舉時Raft中對時間要求最為關(guān)鍵的方面。Raft可以選舉并維持一個穩(wěn)定的領(lǐng)導(dǎo)人砾赔，只需要滿足下面的時間要求:
廣播時間(broadcastTime) << 選舉時間(election Timeout) << 平均故障時間(MTBF)
在這個不等式中蝌箍，廣播時間指的時從一個服務(wù)器并行的發(fā)送RPCs給集群中的其他服務(wù)器并接收平均時間青灼，選舉超時時間（150ms-300ms）選舉超時時間限制，然后平均故障時間就是對于一臺服務(wù)器而言妓盲，兩次故障之間的平均時間杂拨。廣播時間必須比選舉超時時間小一個量級，這樣領(lǐng)導(dǎo)人才能發(fā)送穩(wěn)定的心跳消息來阻止跟隨者開始進(jìn)入選舉狀態(tài)悯衬，通過隨機(jī)化選舉超時時間的方法弹沽，整個不等式也使得選票瓜分的情況變成不肯能。選舉選舉超時時間要比平局故障時間間隔小上幾個數(shù)量級,這樣系統(tǒng)才能穩(wěn)定的運(yùn)行筋粗。當(dāng)領(lǐng)導(dǎo)人崩潰后策橘，整個系統(tǒng)會大約相當(dāng)于超時時的時間里不可用。我們希望這種情況在系統(tǒng)中國運(yùn)行很少出現(xiàn)娜亿。
廣播時間和平均故障間隔時間是由系統(tǒng)決定的丽已，但是選舉超時時間是我們自己選擇的。Raft 的 RPCs 需要接收方將信息持久化的保存到穩(wěn)定存儲中去买决，所以廣播時間大約是 0.5 毫秒到 20 毫秒沛婴，取決于存儲的技術(shù)。因此督赤，選舉超時時間可能需要在 10 毫秒到 500 毫秒之間嘁灯。大多數(shù)的服務(wù)器的平均故障間隔時間都在幾個月甚至更長，很容易滿足時間的需求躲舌。
成員變更
成員變更是在集群運(yùn)行過程中副本發(fā)生變化丑婿，如增加/減少副本數(shù)，節(jié)點(diǎn)替換等孽糖。
成員變更也是一個分布式一致性的問題枯冈，既所有服務(wù)器對成員新成員達(dá)成一致。但是成員變更又有其特殊性办悟，因?yàn)槌蓡T變更的一致性達(dá)成的過程中尘奏，參與投票的過程會發(fā)生變化。
如果將成員變更當(dāng)成一般的一致性問題病蛉，直接向Leader發(fā)送成員變更請求炫加，Leader復(fù)制成員變更日志，達(dá)成多數(shù)之后提交铺然，各個服務(wù)器提交成員變更日志后從日志成員(Cold)切換到最新成員配置(Cnew的時刻不同.
成員變更不能影響服務(wù)的可用性俗孝，但是成員變更過程的某一時刻，可能出現(xiàn)Cold和Cnew中同時存在兩個不相交的多數(shù)派魄健，進(jìn)而可能選出兩個Leader赋铝，形成不同的決議，破壞安全性沽瘦。
由于成員變更的這一特殊性革骨，成員變更不能當(dāng)成一般的一致性問題去解決农尖。
為了解決這一問題.Raft提出了兩段的成員變更方法。集群先成舊成員配置Cold切換到一個過度的配置良哲，稱為共同一致(joint consensus),共同一致時舊成員配置Cold和新成員配置Cnew的組合Cold U Cnew盛卡，一旦共同一致Cold U Cnew被提交，系統(tǒng)在切換到新成員配置Cnew筑凫。
一個配置切換的時間線滑沧。虛線表示已經(jīng)被創(chuàng)建但是還沒有被提交的條目，實(shí)線表示最后被提交的日志條目巍实。領(lǐng)導(dǎo)人首先創(chuàng)建了C-old
,new的配置條目在自己的日志中滓技，并提交到C-old,new中(C-old的大多數(shù)和c-new的大多數(shù))。然后他創(chuàng)建C-new條目并且提交到C-new的大多數(shù)蔫浆。這樣就不存在C-new和C-old同時做出決定的時間點(diǎn)殖属。
在關(guān)于重新配置還有三個問題需要提出,第一個問題是，新的服務(wù)器額能初始化沒有存儲任何的日志條目瓦盛。當(dāng)這些服務(wù)器以這種狀態(tài)加入到集群中洗显，那么它們需要一段時間來更新追趕。這時還不能提交新的日志條目原环。為了避免這種可用性的間隔時間Raft在配置更新的時候用了一種額外的階段挠唆，在這種階段，新的服務(wù)器以沒有投票權(quán)的身份加入集群中來(領(lǐng)導(dǎo)人復(fù)制日志給它們嘱吗。但是不考慮它們是大多數(shù))玄组。一旦新的服務(wù)器追趕上了集群中的集群，重新配置可以向上面描述一樣處理谒麦。
第二個問題俄讹，集群的領(lǐng)導(dǎo)人可能不是新配置的一員。在這種情況下绕德，領(lǐng)導(dǎo)人就會在提交了C-new日志后退位(回到追隨者狀態(tài))患膛。這意味著有這樣一段時間，領(lǐng)導(dǎo)人管理著集群耻蛇，但是不包括他自己踪蹬，他復(fù)制日志但是不把他自己算作大多數(shù)之一。當(dāng)C-new被提交時臣咖，會發(fā)生領(lǐng)導(dǎo)人過度跃捣。因?yàn)檫@時時最新的配置可以獨(dú)立工作時間點(diǎn)(將總是能夠在C-new配置下選出新的Leader)。再此之前夺蛇，可能只從C-old中選出領(lǐng)導(dǎo)人疚漆。
第三個問題是:移除不再C-new中的服務(wù)器可能會擾亂集群。這些服務(wù)器將不會再接收心跳。當(dāng)選舉超時時娶聘，它們就會進(jìn)行新的選舉過程灵临。它們會發(fā)送擁有新的任期號的請求投票RPCs，這樣會導(dǎo)致當(dāng)前的領(lǐng)導(dǎo)人退回成跟隨者狀態(tài)趴荸。新的領(lǐng)導(dǎo)人最終被選出來，但是被移除的服務(wù)器將會再次超時宦焦，然后這種過程再次重復(fù)发钝，導(dǎo)致整體可用性大幅度下降。
為了避免這個問題波闹，當(dāng)服務(wù)器確認(rèn)當(dāng)前領(lǐng)導(dǎo)人存在時酝豪，服務(wù)器會忽略投票RPCs。特別的精堕，當(dāng)服務(wù)器再當(dāng)前最小選舉超時時間內(nèi)收到一個請求投票的RPC孵淘。他不會更新當(dāng)前的任期號和投票號。這不會影響正常的選舉歹篓，每個服務(wù)器在開始一次選舉之前瘫证，至少等待一個最小選舉超時時間。然后這有利于避免被移除的服務(wù)器的擾亂庄撮。如果領(lǐng)導(dǎo)人能夠發(fā)送心跳給集群背捌，那么他就不會更大的任期號廢黜。
日志壓縮
在實(shí)際系統(tǒng)中洞斯，不能讓日志無限增長毡庆，否則系統(tǒng)重啟時需要花很長的時間回放，從而影響可用性烙如。Raft采用對整個系統(tǒng)進(jìn)行snapshot來解決么抗，snapshot之前的日志都可以拋棄。
每個副本獨(dú)立的對自己系統(tǒng)狀態(tài)進(jìn)行snapshot亚铁，并且只能對已經(jīng)提交的日志進(jìn)行snapshot蝇刀。
Snapshot中包含以下內(nèi)容:
1>日志元數(shù)據(jù):最后提交的log entry的log index和term。這兩個值在snapshot之后的第一條log entry的AppendEntriesRPC的完整性檢查的時候會被用上刀闷。
2> 系統(tǒng)當(dāng)前狀態(tài)熊泵。
當(dāng)Leader要發(fā)給某個日志落后太多的Follower的log entry被丟棄，Leader會將snapshot發(fā)給Follower甸昏⊥绶郑或者新加入一臺機(jī)器時，也會發(fā)送snapshot給它施蜜。發(fā)送snapshot使用InstalledSnapshot RPC卒蘸。
一個服務(wù)器用新的快照替換了從1到5的條目數(shù)，快照存儲了當(dāng)前的狀態(tài)「孜郑快照中包含了最后的索引位置和任期號
做snapshot不要做的太頻繁恰起，否則消耗磁盤帶寬，也不要做的太平凡趾牧，否則一點(diǎn)節(jié)點(diǎn)重啟要回放大量日志检盼，影響可用性。推薦當(dāng)日組織達(dá)到某個固定的大小做一次snapshot翘单。
做一次snapshot可能耗時過長吨枉，會影響正常日志同步『逦撸可以通過使用copy-on-write技術(shù)避免snapshot過程影響正常的日志同步過程貌亭。
一個關(guān)于 Raft 一致性算法的濃縮總結(jié)（不包括成員變換和日志壓縮）。
參考：
http://thesecretlivesofdata.com/raft/(Raft動畫)
https://github.com/maemual/raft-zh_cn/blob/master/raft-zh_cn.md(Raft論文翻譯)
