一、 Raft簡介

1.1 Raft簡介

Raft 是一種為了管理日志復(fù)制的分布式一致性算法。Raft 出現(xiàn)之前，Paxos 一直是分布式一致性算法的標(biāo)準(zhǔn)。Paxos 難以理解，更難以實(shí)現(xiàn)。Raft 的設(shè)計(jì)目標(biāo)是簡化 Paxos，使得算法既容易理解，也容易實(shí)現(xiàn)。

Paxos 和 Raft 都是分布式一致性算法，這個過程如同投票選舉領(lǐng)袖（Leader），參選者（Candidate）需要說服大多數(shù)投票者（Follower）投票給他，一旦選舉出領(lǐng)袖，就由領(lǐng)袖發(fā)號施令。Paxos 和 Raft 的區(qū)別在于選舉的具體過程不同。

Raft 可以解決分布式 CAP 理論中的 CP，即一致性（C：Consistency）和分區(qū)容忍性（P：Partition Tolerance），并不能解決可用性（A：Availability）的問題。

1.2 分布一致性

分布式一致性 (distributed consensus) 是分布式系統(tǒng)中最基本的問題，用來保證一個分布式系統(tǒng)的可靠性以及容錯能力。簡單來說，分布式一致性是指多個服務(wù)器的保持狀態(tài)一致。

在分布式系統(tǒng)中，可能出現(xiàn)各種意外（斷電、網(wǎng)絡(luò)擁塞、CPU/內(nèi)存耗盡等等），使得服務(wù)器宕機(jī)或無法訪問，最終導(dǎo)致無法和其他服務(wù)器保持狀態(tài)一致。為了應(yīng)對這種情況，就需要有一種一致性協(xié)議來進(jìn)行容錯，使得分布式系統(tǒng)中即使有部分服務(wù)器宕機(jī)或無法訪問，整體依然可以對外提供服務(wù)。

以容錯方式達(dá)成一致，自然不能要求所有服務(wù)器都達(dá)成一致狀態(tài)，只要超過半數(shù)以上的服務(wù)器達(dá)成一致就可以了。假設(shè)有 N 臺服務(wù)器，大于等于 N / 2 + 1 臺服務(wù)器就算是半數(shù)以上了。

1.3 復(fù)制狀態(tài)機(jī)

復(fù)制狀態(tài)機(jī)（Replicated State Machines）是指一組服務(wù)器上的狀態(tài)機(jī)產(chǎn)生相同狀態(tài)的副本，并且在一些機(jī)器宕掉的情況下也可以繼續(xù)運(yùn)行。一致性算法管理著來自客戶端指令的復(fù)制日志。狀態(tài)機(jī)從日志中處理相同順序的相同指令，所以產(chǎn)生的結(jié)果也是相同的。

復(fù)制狀態(tài)機(jī)通常都是基于復(fù)制日志實(shí)現(xiàn)的，如上圖。每一個服務(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)整體的性能。

1.4 RAFT應(yīng)用

通過 RAFT 提供的復(fù)制狀態(tài)機(jī)，可以解決分布式系統(tǒng)的復(fù)制、修復(fù)、節(jié)點(diǎn)管理等問題。Raft 極大的簡化當(dāng)前分布式系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)，讓開發(fā)者只關(guān)注于業(yè)務(wù)邏輯，將其抽象實(shí)現(xiàn)成對應(yīng)的狀態(tài)機(jī)即可?；谶@套框架，可以構(gòu)建很多分布式應(yīng)用：

分布式鎖服務(wù)，比如 Zookeeper
分布式存儲系統(tǒng)，比如分布式消息隊(duì)列、分布式塊系統(tǒng)、分布式文件系統(tǒng)、分布式表格系統(tǒng)等，比如大名鼎鼎的 Redis 就是基于 Raft 實(shí)現(xiàn)分布式一致性
高可靠元信息管理，比如各類 Master 模塊的 HA

二、 Raft基礎(chǔ)

Raft 將一致性問題分解成了三個子問題：選舉 Leader、日志復(fù)制、安全性。

在后續(xù)章節(jié)，會詳細(xì)講解這個子問題?，F(xiàn)在，先了解一下 Raft 的一些核心概念。

2.1 服務(wù)器角色

在 Raft 中，任何時刻，每個服務(wù)器都處于這三個角色之一：

Leader - 領(lǐng)導(dǎo)者，通常一個系統(tǒng)中是一主（Leader）多從（Follower）。Leader 負(fù)責(zé)處理所有的客戶端請求。
Follower - 跟隨者，不會發(fā)送任何請求，只是簡單的 響應(yīng)來自 Leader 或者 Candidate 的請求。
Candidate - 參選者，選舉新 Leader 時的臨時角色。

圖示說明：

Follower 只響應(yīng)來自其他服務(wù)器的請求。在一定時限內(nèi)，如果 Follower 接收不到消息，就會轉(zhuǎn)變成 Candidate，并發(fā)起選舉。
Candidate 向 Follower 發(fā)起投票請求，如果獲得集群中半數(shù)以上的選票，就會轉(zhuǎn)變?yōu)?Leader。
在一個 Term 內(nèi)，Leader 始終保持不變，直到下線了。Leader 需要周期性向所有 Follower 發(fā)送心跳消息，以阻止 Follower 轉(zhuǎn)變?yōu)?Candidate。

2.2 任期

Raft 把時間分割成任意長度的 任期（Term），任期用連續(xù)的整數(shù)標(biāo)記。每一段任期從一次選舉開始。Raft 保證了在一個給定的任期內(nèi)，最多只有一個領(lǐng)導(dǎo)者。

如果選舉成功，Leader 會管理整個集群直到任期結(jié)束。
如果選舉失敗，那么這個任期就會因?yàn)闆]有 Leader 而結(jié)束。

不同服務(wù)器節(jié)點(diǎn)觀察到的任期轉(zhuǎn)換狀態(tài)可能不一樣：

服務(wù)器節(jié)點(diǎn)可能觀察到多次的任期轉(zhuǎn)換。
服務(wù)器節(jié)點(diǎn)也可能觀察不到任何一次任期轉(zhuǎn)換。

任期在 Raft 算法中充當(dāng)邏輯時鐘的作用，使得服務(wù)器節(jié)點(diǎn)可以查明一些過期的信息（比如過期的 Leader）。每個服務(wù)器節(jié)點(diǎn)都會存儲一個當(dāng)前任期號，這一編號在整個時期內(nèi)單調(diào)的增長。當(dāng)服務(wù)器之間通信的時候會交換當(dāng)前任期號。

如果一個服務(wù)器的當(dāng)前任期號比其他人小，那么他會更新自己的編號到較大的編號值。
如果一個 Candidate 或者 Leader 發(fā)現(xiàn)自己的任期號過期了，那么他會立即恢復(fù)成跟隨者狀態(tài)。
如果一個節(jié)點(diǎn)接收到一個包含過期的任期號的請求，那么他會直接拒絕這個請求。

數(shù)據(jù)可視化的應(yīng)用場景越來越廣泛，數(shù)據(jù)可以呈現(xiàn)為更多豐富的可視化形式，使用戶能夠更加輕易、便捷的獲取并理解數(shù)據(jù)傳達(dá)的信息。

2.3 RPC

Raft 算法中服務(wù)器節(jié)點(diǎn)之間的通信使用 遠(yuǎn)程過程調(diào)用（RPC）。基本的一致性算法只需要兩種 RPC：

RequestVote RPC - 請求投票 RPC，由 Candidate 在選舉期間發(fā)起。
AppendEntries RPC - 附加條目 RPC，由 Leader 發(fā)起，用來復(fù)制日志和提供一種心跳機(jī)制。

三、選舉Leader

3.1 選舉規(guī)則

Raft 使用一種心跳機(jī)制來觸發(fā) Leader 選舉。Leader 需要周期性的向所有 Follower 發(fā)送心跳消息，以此維持自己的權(quán)威并阻止新 Leader 的產(chǎn)生。

每個 Follower 都設(shè)置了一個隨機(jī)的競選超時時間，一般為 150ms ~ 300ms，如果在競選超時時間內(nèi)沒有收到 Leader 的心跳消息，就會認(rèn)為當(dāng)前 Term 沒有可用的 Leader，并發(fā)起選舉來選出新的 Leader。開始一次選舉過程，F(xiàn)ollower 先要增加自己的當(dāng)前 Term 號，并轉(zhuǎn)換為 Candidate。

Candidate 會并行的向集群中的所有服務(wù)器節(jié)點(diǎn)發(fā)送投票請求（RequestVote RPC），它會保持當(dāng)前狀態(tài)直到以下三件事情之一發(fā)生：

自己成為 Leader
其他的服務(wù)器成為 Leader
沒有任何服務(wù)器成為 Leader

3.1.1自己成為 Leader

當(dāng)一個 Candidate 從整個集群半數(shù)以上的服務(wù)器節(jié)點(diǎn)獲得了針對同一個 Term 的選票，那么它就贏得了這次選舉并成為 Leader。每個服務(wù)器最多會對一個 Term 投出一張選票，按照先來先服務(wù)（FIFO）的原則。要求半數(shù)以上選票的規(guī)則確保了最多只會有一個 Candidate 贏得此次選舉。

一旦 Candidate 贏得選舉，就立即成為 Leader。然后它會向其他的服務(wù)器發(fā)送心跳消息來建立自己的權(quán)威并且阻止新的領(lǐng)導(dǎo)人的產(chǎn)生。

3.1.2 其他的服務(wù)器成為 Leader

等待投票期間，Candidate 可能會從其他的服務(wù)器接收到聲明它是 Leader 的 AppendEntries RPC。

如果這個 Leader 的 Term 號（包含在此次的 RPC 中）不小于 Candidate 當(dāng)前的 Term，那么 Candidate 會承認(rèn) Leader 合法并回到 Follower 狀態(tài)。

如果此次 RPC 中的 Term 號比自己小，那么 Candidate 就會拒絕這個消息并繼續(xù)保持 Candidate 狀態(tài)。

3.1.3 沒有任何服務(wù)器成為 Leader

如果有多個 Follower 同時成為 Candidate，那么選票可能會被瓜分以至于沒有 Candidate 可以贏得半數(shù)以上的投票。當(dāng)這種情況發(fā)生的時候，每一個 Candidate 都會競選超時，然后通過增加當(dāng)前 Term 號來開始一輪新的選舉。然而，沒有其他機(jī)制的話，選票可能會被無限的重復(fù)瓜分。

Raft 算法使用隨機(jī)選舉超時時間的方法來確保很少會發(fā)生選票瓜分的情況，就算發(fā)生也能很快的解決。為了阻止選票起初就被瓜分，競選超時時間是一個隨機(jī)的時間，在一個固定的區(qū)間（例如 150-300 毫秒）隨機(jī)選擇，這樣可以把選舉都分散開。

以至于在大多數(shù)情況下，只有一個服務(wù)器會超時，然后它贏得選舉，成為 Leader，并在其他服務(wù)器超時之前發(fā)送心跳包。

同樣的機(jī)制也被用在選票瓜分的情況下：每一個 Candidate 在開始一次選舉的時候會重置一個隨機(jī)的選舉超時時間，然后在超時時間內(nèi)等待投票的結(jié)果；這樣減少了在新的選舉中另外的選票瓜分的可能性。

理解了上面的選舉規(guī)則后，我們通過動圖來加深認(rèn)識。

3.2 單Candidate選舉

1) 下圖表示一個分布式系統(tǒng)的最初階段，此時只有 Follower，沒有 Leader。Follower A 等待一個隨機(jī)的選舉超時時間之后，沒收到 Leader 發(fā)來的心跳消息。因此，將 Term 由 0 增加為 1，轉(zhuǎn)換為 Candidate，進(jìn)入選舉狀態(tài)。

2)此時，A 向所有其他節(jié)點(diǎn)發(fā)送投票請求。

3) 其它節(jié)點(diǎn)會對投票請求進(jìn)行回復(fù)，如果超過半數(shù)以上的節(jié)點(diǎn)投票了，那么該 Candidate 就會立即變成 Term 為 1 的 Leader。

4) Leader 會周期性地發(fā)送心跳消息給所有 Follower，F(xiàn)ollower 接收到心跳包，會重新開始計(jì)時。

3.3 多 Candidate 選舉

1) 1如果有多個 Follower 成為 Candidate，并且所獲得票數(shù)相同，那么就需要重新開始投票。例如下圖中 Candidate B 和 Candidate D 都發(fā)起 Term 為 4 的選舉，且都獲得兩票，因此需要重新開始投票。

2) 當(dāng)重新開始投票時，由于每個節(jié)點(diǎn)設(shè)置的隨機(jī)競選超時時間不同，因此能下一次再次出現(xiàn)多個 Candidate 并獲得同樣票數(shù)的概率很低。

四、日志復(fù)制

4.1 日志格式

日志由含日志索引（log index）的日志條目（log entry）組成。每個日志條目包含它被創(chuàng)建時的 Term 號（下圖中方框中的數(shù)字），和一個復(fù)制狀態(tài)機(jī)需要執(zhí)行的指令。如果一個日志條目被復(fù)制到半數(shù)以上的服務(wù)器上，就被認(rèn)為可以提交（Commit）了。

日志條目中的 Term 號被用來檢查是否出現(xiàn)不一致的情況。
日志條目中的日志索引（一個整數(shù)值）用來表明它在日志中的位置。

Raft 日志同步保證如下兩點(diǎn)；圖示說明：

如果不同日志中的兩個日志條目有著相同的日志索引和 Term，則它們所存儲的命令是相同的。

這個特性基于這條原則：Leader 最多在一個 Term 內(nèi)、在指定的一個日志索引上創(chuàng)建一條日志條目，同時日志條目在日志中的位置也從來不會改變。

如果不同日志中的兩個日志條目有著相同的日志索引和 Term，則它們之前的所有條目都是完全一樣的。

這個特性由 AppendEntries RPC 的一個簡單的一致性檢查所保證。在發(fā)送 AppendEntries RPC 時，Leader 會把新日志條目之前的日志條目的日志索引和 Term 號一起發(fā)送。如果 Follower 在它的日志中找不到包含相同日志索引和 Term 號的日志條目，它就會拒絕接收新的日志條目。

4.2 日志復(fù)制流程

Leader 負(fù)責(zé)處理所有客戶端的請求。

Leader 把請求作為日志條目加入到它的日志中，然后并行的向其他服務(wù)器發(fā)送 AppendEntries RPC 請求，要求 Follower 復(fù)制日志條目。

Follower 復(fù)制成功后，返回確認(rèn)消息。

當(dāng)這個日志條目被半數(shù)以上的服務(wù)器復(fù)制后，Leader 提交這個日志條目到它的復(fù)制狀態(tài)機(jī)，并向客戶端返回執(zhí)行結(jié)果。

注意：如果 Follower 崩潰或者運(yùn)行緩慢，再或者網(wǎng)絡(luò)丟包，Leader 會不斷的重復(fù)嘗試發(fā)送 AppendEntries RPC 請求（盡管已經(jīng)回復(fù)了客戶端），直到所有的跟隨者都最終復(fù)制了所有的日志條目。

下面，通過一組動圖來加深認(rèn)識：

1)來自客戶端的修改都會被傳入 Leader。注意該修改還未被提交，只是寫入日志中。

2)Leader 會把修改復(fù)制到所有 Follower。

3)Leader 會等待大多數(shù)的 Follower 也進(jìn)行了修改，然后才將修改提交。

4)此時 Leader 會通知的所有 Follower 讓它們也提交修改，此時所有節(jié)點(diǎn)的值達(dá)成一致。

4.3 日志一致性

一般情況下，Leader 和 Followers 的日志保持一致，因此日志條目一致性檢查通常不會失敗。然而，Leader 崩潰可能會導(dǎo)致日志不一致：舊的 Leader 可能沒有完全復(fù)制完日志中的所有條目。

4.3.1 Leader 和 Follower 日志不一致的可能

Leader 和 Follower 可能存在多種日志不一致的可能。

圖示說明：上圖闡述了 Leader 和 Follower 可能存在多種日志不一致的可能，每一個方框表示一個日志條目，里面的數(shù)字表示任期號。

當(dāng)一個 Leader 成功當(dāng)選時，F(xiàn)ollower 可能出現(xiàn)以下情況（a-f）：

存在未更新日志條目，如（a、b）。
存在未提交日志條目，如（c、d）。
或兩種情況都存在，如（e、f）。

例如，場景 f 可能會這樣發(fā)生，某服務(wù)器在 Term2 的時候是 Leader，已附加了一些日志條目到自己的日志中，但在提交之前就崩潰了；很快這個機(jī)器就被重啟了，在 Term3 重新被選為 Leader，并且又增加了一些日志條目到自己的日志中；在 Term 2 和 Term 3 的日志被提交之前，這個服務(wù)器又宕機(jī)了，并且在接下來的幾個任期里一直處于宕機(jī)狀態(tài)。

4.3.2 Leader 和 Follower 日志一致的保證

Leader 通過強(qiáng)制 Followers 復(fù)制它的日志來處理日志的不一致，Followers 上的不一致的日志會被 Leader 的日志覆蓋。

Leader 為了使 Followers 的日志同自己的一致，Leader 需要找到 Followers 同它的日志一致的地方，然后覆蓋 Followers 在該位置之后的條目。

Leader 會從后往前試，每次日志條目失敗后嘗試前一個日志條目，直到成功找到每個 Follower 的日志一致位點(diǎn)，然后向后逐條覆蓋 Followers 在該位置之后的條目。

五、安全性

前面描述了 Raft 算法是如何選舉 Leader 和復(fù)制日志的。

Raft 還增加了一些限制來完善 Raft 算法，以保證安全性：保證了任意 Leader 對于給定的 Term，都擁有了之前 Term 的所有被提交的日志條目。

5.1 選舉限制

擁有最新的已提交的日志條目的 Follower 才有資格成為 Leader。

Raft 使用投票的方式來阻止一個 Candidate 贏得選舉除非這個 Candidate 包含了所有已經(jīng)提交的日志條目。Candidate 為了贏得選舉必須聯(lián)系集群中的大部分節(jié)點(diǎn)，這意味著每一個已經(jīng)提交的日志條目在這些服務(wù)器節(jié)點(diǎn)中肯定存在于至少一個節(jié)點(diǎn)上。如果 Candidate 的日志至少和大多數(shù)的服務(wù)器節(jié)點(diǎn)一樣新（這個新的定義會在下面討論），那么他一定持有了所有已經(jīng)提交的日志條目。

RequestVote RPC 實(shí)現(xiàn)了這樣的限制：RequestVote RPC 中包含了 Candidate 的日志信息， Follower 會拒絕掉那些日志沒有自己新的投票請求。

5.1.1 場如何判斷哪個日志條目比較新？

Raft 通過比較兩份日志中最后一條日志條目的日志索引和 Term 來判斷哪個日志比較新。

先判斷 Term，哪個數(shù)值大即代表哪個日志比較新。
如果 Term 相同，再比較日志索引，哪個數(shù)值大即代表哪個日志比較新。

5.1.2 提交舊任期的日志條目

一個當(dāng)前 Term 的日志條目被復(fù)制到了半數(shù)以上的服務(wù)器上，Leader 就認(rèn)為它是可以被提交的。如果這個 Leader 在提交日志條目前就下線了，后續(xù)的 Leader 可能會覆蓋掉這個日志條目。

圖示說明：上圖解釋了為什么 Leader 無法對舊 Term 的日志條目進(jìn)行提交。

階段 (a) ，S1 是 Leader，且 S1 寫入日志條目為 (Term 2，日志索引 2），只有 S2 復(fù)制了這個日志條目。
階段 (b)，S1 下線，S5 被選舉為 Term3 的 Leader。S5 寫入日志條目為 (Term 3，日志索引 2）。
階段 (c)，S5 下線，S1 重新上線，并被選舉為 Term4 的 Leader。此時，Term 2 的那條日志條目已經(jīng)被復(fù)制到了集群中的大多數(shù)節(jié)點(diǎn)上，但是還沒有被提交。
階段 (d)，S1 再次下線，S5 重新上線，并被重新選舉為 Term3 的 Leader。然后 S5 覆蓋了日志索引 2 處的日志。
階段 (e)，如果階段 (d) 還未發(fā)生，即 S1 再次下線之前，S1 把自己主導(dǎo)的日志條目復(fù)制到了大多數(shù)節(jié)點(diǎn)上，那么在后續(xù) Term 里面這些新日志條目就會被提交。這樣在同一時刻就同時保證了，之前的所有舊日志條目就會被提交。

Raft 永遠(yuǎn)不會通過計(jì)算副本數(shù)目的方式去提交一個之前 Term 內(nèi)的日志條目。只有 Leader 當(dāng)前 Term 里的日志條目通過計(jì)算副本數(shù)目可以被提交；一旦當(dāng)前 Term 的日志條目以這種方式被提交，那么由于日志匹配特性，之前的日志條目也都會被間接的提交。

當(dāng) Leader 復(fù)制之前任期里的日志時，Raft 會為所有日志保留原始的 Term，這在提交規(guī)則上產(chǎn)生了額外的復(fù)雜性。在其他的一致性算法中，如果一個新的領(lǐng)導(dǎo)人要重新復(fù)制之前的任期里的日志時，它必須使用當(dāng)前新的任期號。

Raft 使用的方法更加容易辨別出日志，因?yàn)樗梢噪S著時間和日志的變化對日志維護(hù)著同一個任期編號。另外，和其他的算法相比，Raft 中的新領(lǐng)導(dǎo)人只需要發(fā)送更少日志條目（其他算法中必須在他們被提交之前發(fā)送更多的冗余日志條目來為他們重新編號）。

六、日志壓縮

在實(shí)際的系統(tǒng)中，不能讓日志無限膨脹，否則系統(tǒng)重啟時需要花很長的時間進(jìn)行恢復(fù)，從而影響可用性。Raft 采用對整個系統(tǒng)進(jìn)行快照來解決，快照之前的日志都可以丟棄。

每個副本獨(dú)立的對自己的系統(tǒng)狀態(tài)生成快照，并且只能對已經(jīng)提交的日志條目生成快照?？煺瞻韵聝?nèi)容：

日志元數(shù)據(jù)。最后一條已提交的日志條目的日志索引和 Term。這兩個值在快照之后的第一條日志條目的 AppendEntries RPC 的完整性檢查的時候會被用上。
系統(tǒng)當(dāng)前狀態(tài)。

當(dāng) Leader 要發(fā)送某個日志條目，落后太多的 Follower 的日志條目會被丟棄，Leader 會將快照發(fā)給 Follower?；蛘咝律暇€一臺機(jī)器時，也會發(fā)送快照給它。

生成快照的頻率要適中，頻率過高會消耗大量 I/O 帶寬；頻率過低，一旦需要執(zhí)行恢復(fù)操作，會丟失大量數(shù)據(jù)，影響可用性。推薦當(dāng)日志達(dá)到某個固定的大小時生成快照。

生成一次快照可能耗時過長，影響正常日志同步?？梢酝ㄟ^使用 copy-on-write 技術(shù)避免快照過程影響正常日志同步。

說明：本文僅闡述 Raft 算法的核心內(nèi)容，不包括算法論證、評估等

七、參考資料

1.Raft 一致性算法論文原文

2.Raft 一致性算法論文譯文

3.Raft 作者講解視頻

4.Raft 作者講解視頻對應(yīng)的 PPT

5.分布式系統(tǒng)的 Raft 算法

6.Raft 算法詳解

7.Raft: Understandable Distributed

Consensus

8.sofa-jraft - 螞蟻金服的 Raft 算法實(shí)現(xiàn)庫（Java 版）

- END -

「技術(shù)分享」某種程度上，是讓作者和讀者，不那么孤獨(dú)的東西。歡迎關(guān)注我的微信公眾號：「Kirito的技術(shù)分享」

深入剖析共識性算法 Raft