摘要：摘要是一種為了管理復制日志的一致性算法。接下來，這篇論文會介紹以下內容復制狀態機問題第節，討論的優點和缺點第節，討論我們為了可理解性而采取的方法第節，闡述一致性算法第節，評價算法第節，以及一些相關的工作第節。

摘要

Raft 是一種為了管理復制日志的一致性算法。它提供了和 Paxos 算法相同的功能和性能，但是它的算法結構和 Paxos 不同，使得 Raft 算法更加容易理解并且更容易構建實際的系統。為了提升可理解性，Raft 將一致性算法分解成了幾個關鍵模塊，例如領導人選舉、日志復制和安全性。同時它通過實施一個更強的一致性來減少需要考慮的狀態的數量。從一個用戶研究的結果可以證明，對于學生而言，Raft 算法比 Paxos 算法更加容易學習。Raft 算法還包括一個新的機制來允許集群成員的動態改變，它利用重疊的大多數來保證安全性。

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

但是不幸的是，盡管有很多工作都在嘗試降低它的復雜性，但是 Paxos 算法依然十分難以理解。并且，Paxos 自身的算法結構需要進行大幅的修改才能夠應用到實際的系統中。這些都導致了工業界和學術界都對 Paxos 算法感到十分頭疼。

和 Paxos 算法進行過努力之后，我們開始尋找一種新的一致性算法，可以為構建實際的系統和教學提供更好的基礎。我們的做法是不尋常的，我們的首要目標是可理解性：我們是否可以在實際系統中定義一個一致性算法，并且能夠比 Paxos 算法以一種更加容易的方式來學習。此外，我們希望該算法方便系統構建者的直覺的發展。不僅一個算法能夠工作很重要，而且能夠顯而易見的知道為什么能工作也很重要。

Raft 一致性算法就是這些工作的結果。在設計 Raft 算法的時候，我們使用一些特別的技巧來提升它的可理解性，包括算法分解（Raft 主要被分成了領導人選舉，日志復制和安全三個模塊）和減少狀態機的狀態（相對于 Paxos，Raft 減少了非確定性和服務器互相處于非一致性的方式）。一份針對兩所大學 43 個學生的研究表明 Raft 明顯比 Paxos 算法更加容易理解。在這些學生同時學習了這兩種算法之后，和 Paxos 比起來，其中 33 個學生能夠回答有關于 Raft 的問題。

Raft 算法在許多方面和現有的一致性算法都很相似（主要是 Oki 和 Liskov 的 Viewstamped Replication），但是它也有一些獨特的特性：

強領導者：和其他一致性算法相比，Raft 使用一種更強的領導能力形式。比如，日志條目只從領導者發送給其他的服務器。這種方式簡化了對復制日志的管理并且使得 Raft 算法更加易于理解。

領導選舉：Raft 算法使用一個隨機計時器來選舉領導者。這種方式只是在任何一致性算法都必須實現的心跳機制上增加了一點機制。在解決沖突的時候會更加簡單快捷。

成員關系調整：Raft 使用一種共同一致的方法來處理集群成員變換的問題，在這種方法下，處于調整過程中的兩種不同的配置集群中大多數機器會有重疊，這就使得集群在成員變換的時候依然可以繼續工作。

我們相信，Raft 算法不論出于教學目的還是作為實踐項目的基礎都是要比 Paxos 或者其他一致性算法要優異的。它比其他算法更加簡單，更加容易理解；它的算法描述足以實現一個現實的系統；它有好多開源的實現并且在很多公司里使用；它的安全性已經被證明；它的效率和其他算法比起來也不相上下。

接下來，這篇論文會介紹以下內容：復制狀態機問題（第 2 節），討論 Paxos 的優點和缺點（第 3 節），討論我們為了可理解性而采取的方法（第 4 節），闡述 Raft 一致性算法（第 5-8 節），評價 Raft 算法（第 9 節），以及一些相關的工作（第 10 節）。

一致性算法是從復制狀態機的背景下提出的（參考英文原文引用37）。在這種方法中，一組服務器上的狀態機產生相同狀態的副本，并且在一些機器宕掉的情況下也可以繼續運行。復制狀態機在分布式系統中被用于解決很多容錯的問題。例如，大規模的系統中通常都有一個集群領導者，像 GFS、HDFS 和 RAMCloud，典型應用就是一個獨立的的復制狀態機去管理領導選舉和存儲配置信息并且在領導人宕機的情況下也要存活下來。比如 Chubby 和 ZooKeeper。

圖 1 ：復制狀態機的結構。一致性算法管理著來自客戶端指令的復制日志。狀態機從日志中處理相同順序的相同指令，所以產生的結果也是相同的。

復制狀態機通常都是基于復制日志實現的，如圖 1。每一個服務器存儲一個包含一系列指令的日志，并且按照日志的順序進行執行。每一個日志都按照相同的順序包含相同的指令，所以每一個服務器都執行相同的指令序列。因為每個狀態機都是確定的，每一次執行操作都產生相同的狀態和同樣的序列。

保證復制日志相同就是一致性算法的工作了。在一臺服務器上，一致性模塊接收客戶端發送來的指令然后增加到自己的日志中去。它和其他服務器上的一致性模塊進行通信來保證每一個服務器上的日志最終都以相同的順序包含相同的請求，盡管有些服務器會宕機。一旦指令被正確的復制，每一個服務器的狀態機按照日志順序處理他們，然后輸出結果被返回給客戶端。因此，服務器集群看起來形成一個高可靠的狀態機。

實際系統中使用的一致性算法通常含有以下特性：

安全性保證（絕對不會返回一個錯誤的結果）：在非拜占庭錯誤情況下，包括網絡延遲、分區、丟包、冗余和亂序等錯誤都可以保證正確。

可用性：集群中只要有大多數的機器可運行并且能夠相互通信、和客戶端通信，就可以保證可用。因此，一個典型的包含 5 個節點的集群可以容忍兩個節點的失敗。服務器被停止就認為是失敗。他們當有穩定的存儲的時候可以從狀態中恢復回來并重新加入集群。

不依賴時序來保證一致性：物理時鐘錯誤或者極端的消息延遲只有在最壞情況下才會導致可用性問題。

通常情況下，一條指令可以盡可能快的在集群中大多數節點響應一輪遠程過程調用時完成。小部分比較慢的節點不會影響系統整體的性能。

在過去的 10 年里，Leslie Lamport 的 Paxos 算法幾乎已經成為一致性的代名詞：Paxos 是在課程教學中最經常使用的算法，同時也是大多數一致性算法實現的起點。Paxos 首先定義了一個能夠達成單一決策一致的協議，比如單條的復制日志項。我們把這一子集叫做單決策 Paxos。然后通過組合多個 Paxos 協議的實例來促進一系列決策的達成。Paxos 保證安全性和活性，同時也支持集群成員關系的變更。Paxos 的正確性已經被證明，在通常情況下也很高效。

不幸的是，Paxos 有兩個明顯的缺點。第一個缺點是 Paxos 算法特別的難以理解。完整的解釋是出了名的不透明；通過極大的努力之后，也只有少數人成功理解了這個算法。因此，有了幾次用更簡單的術語來解釋 Paxos 的嘗試。盡管這些解釋都只關注了單決策的子集問題，但依然很具有挑戰性。在 2012 年 NSDI 的會議中的一次調查顯示，很少有人對 Paxos 算法感到滿意，甚至在經驗老道的研究者中也是如此。我們自己也嘗試去理解 Paxos；我們一直沒能理解 Paxos 直到我們讀了很多對 Paxos 的簡化解釋并且設計了我們自己的算法之后，這一過程花了近一年時間。

我們假設 Paxos 的不透明性來自它選擇單決策問題作為它的基礎。單決策 Paxos 是晦澀微妙的，它被劃分成了兩種沒有簡單直觀解釋和無法獨立理解的情景。因此，這導致了很難建立起直觀的感受為什么單決策 Paxos 算法能夠工作。構成多決策 Paxos 增加了很多錯綜復雜的規則。我們相信，在多決策上達成一致性的問題（一份日志而不是單一的日志記錄）能夠被分解成其他的方式并且更加直接和明顯。

Paxos算法的第二個問題就是它沒有提供一個足夠好的用來構建一個現實系統的基礎。一個原因是還沒有一種被廣泛認同的多決策問題的算法。Lamport 的描述基本上都是關于單決策 Paxos 的；他簡要描述了實施多決策 Paxos 的方法，但是缺乏很多細節。當然也有很多具體化 Paxos 的嘗試，但是他們都互相不一樣，和 Paxos 的概述也不同。例如 Chubby 這樣的系統實現了一個類似于 Paxos 的算法，但是大多數的細節并沒有被公開。

而且，Paxos 算法的結構也不是十分易于構建實踐的系統；單決策分解也會產生其他的結果。例如，獨立的選擇一組日志條目然后合并成一個序列化的日志并沒有帶來太多的好處，僅僅增加了不少復雜性。圍繞著日志來設計一個系統是更加簡單高效的；新日志條目以嚴格限制的順序增添到日志中去。另一個問題是，Paxos 使用了一種對等的點對點的方式作為它的核心（盡管它最終提議了一種弱領導人的方法來優化性能）。在只有一個決策會被制定的簡化世界中是很有意義的，但是很少有現實的系統使用這種方式。如果有一系列的決策需要被制定，首先選擇一個領導人，然后讓他去協調所有的決議，會更加簡單快速。

因此，實際的系統中很少有和 Paxos 相似的實踐。每一種實現都是從 Paxos 開始研究，然后發現很多實現上的難題，再然后開發了一種和 Paxos 明顯不一樣的結構。這樣是非常費時和容易出錯的，并且理解 Paxos 的難度使得這個問題更加糟糕。Paxos 算法在理論上被證明是正確可行的，但是現實的系統和 Paxos 差別是如此的大，以至于這些證明沒有什么太大的價值。下面來自 Chubby 實現非常典型：

在Paxos算法描述和實現現實系統中間有著巨大的鴻溝。最終的系統建立在一種沒有經過證明的算法之上。

由于以上問題，我們認為 Paxos 算法既沒有提供一個良好的基礎給實踐的系統，也沒有給教學很好的幫助。基于一致性問題在大規模軟件系統中的重要性，我們決定看看我們是否可以設計一個擁有更好特性的替代 Paxos 的一致性算法。Raft算法就是這次實驗的結果。

設計 Raft 算法我們有幾個初衷：它必須提供一個完整的實際的系統實現基礎，這樣才能大大減少開發者的工作；它必須在任何情況下都是安全的并且在大多數的情況下都是可用的；并且它的大部分操作必須是高效的。但是我們最重要也是最大的挑戰是可理解性。它必須保證對于普遍的人群都可以十分容易的去理解。另外，它必須能夠讓人形成直觀的認識，這樣系統的構建者才能夠在現實中進行必然的擴展。

在設計 Raft 算法的時候，有很多的點需要我們在各種備選方案中進行選擇。在這種情況下，我們評估備選方案基于可理解性原則：解釋各個備選方案有多大的難度（例如，Raft 的狀態空間有多復雜，是否有微妙的暗示）？對于一個讀者而言，完全理解這個方案和暗示是否容易？

我們意識到對這種可理解性分析上具有高度的主觀性；盡管如此，我們使用了兩種通常適用的技術來解決這個問題。第一個技術就是眾所周知的問題分解：只要有可能，我們就將問題分解成幾個相對獨立的，可被解決的、可解釋的和可理解的子問題。例如，Raft 算法被我們分成領導人選舉，日志復制，安全性和角色改變幾個部分。

我們使用的第二個方法是通過減少狀態的數量來簡化需要考慮的狀態空間，使得系統更加連貫并且在可能的時候消除不確定性。特別的，所有的日志是不允許有空洞的，并且 Raft 限制了日志之間變成不一致狀態的可能。盡管在大多數情況下我們都試圖去消除不確定性，但是也有一些情況下不確定性可以提升可理解性。尤其是，隨機化方法增加了不確定性，但是他們有利于減少狀態空間數量，通過處理所有可能選擇時使用相似的方法。我們使用隨機化去簡化 Raft 中領導人選舉算法。

Raft 是一種用來管理章節 2 中描述的復制日志的算法。圖 2 為了參考之用，總結這個算法的簡略版本，圖 3 列舉了這個算法的一些關鍵特性。圖中的這些元素會在剩下的章節逐一介紹。

Raft 通過選舉一個高貴的領導人，然后給予他全部的管理復制日志的責任來實現一致性。領導人從客戶端接收日志條目，把日志條目復制到其他服務器上，并且當保證安全性的時候告訴其他的服務器應用日志條目到他們的狀態機中。擁有一個領導人大大簡化了對復制日志的管理。例如，領導人可以決定新的日志條目需要放在日志中的什么位置而不需要和其他服務器商議，并且數據都從領導人流向其他服務器。一個領導人可以宕機，可以和其他服務器失去連接，這時一個新的領導人會被選舉出來。

通過領導人的方式，Raft 將一致性問題分解成了三個相對獨立的子問題，這些問題會在接下來的子章節中進行討論：

領導選舉：一個新的領導人需要被選舉出來，當現存的領導人宕機的時候（章節 5.2）

日志復制：領導人必須從客戶端接收日志然后復制到集群中的其他節點，并且強制要求其他節點的日志保持和自己相同。

安全性：在 Raft 中安全性的關鍵是在圖 3 中展示的狀態機安全：如果有任何的服務器節點已經應用了一個確定的日志條目到它的狀態機中，那么其他服務器節點不能在同一個日志索引位置應用一個不同的指令。章節 5.4 闡述了 Raft 算法是如何保證這個特性的；這個解決方案涉及到一個額外的選舉機制（5.2 節）上的限制。

在展示一致性算法之后，這一章節會討論可用性的一些問題和計時在系統的作用。

狀態：

附加日志 RPC：

由領導人負責調用來復制日志指令；也會用作heartbeat

接收者實現：

如果 term < currentTerm 就返回 false （5.1 節）

如果日志在 prevLogIndex 位置處的日志條目的任期號和 prevLogTerm 不匹配，則返回 false （5.3 節）

如果已經存在的日志條目和新的產生沖突（索引值相同但是任期號不同），刪除這一條和之后所有的 （5.3 節）

附加日志中尚未存在的任何新條目

如果 leaderCommit > commitIndex，令 commitIndex 等于 leaderCommit 和 新日志條目索引值中較小的一個

請求投票 RPC：

由候選人負責調用用來征集選票（5.2 節）

接收者實現：

如果term < currentTerm返回 false （5.2 節）

如果 votedFor 為空或者為 candidateId，并且候選人的日志至少和自己一樣新，那么就投票給他（5.2 節，5.4 節）

所有服務器需遵守的規則：

所有服務器：

如果commitIndex > lastApplied，那么就 lastApplied 加一，并把log[lastApplied]應用到狀態機中（5.3 節）

如果接收到的 RPC 請求或響應中，任期號T > currentTerm，那么就令 currentTerm 等于 T，并切換狀態為跟隨者（5.1 節）

跟隨者（5.2 節）：

響應來自候選人和領導者的請求

如果在超過選舉超時時間的情況之前都沒有收到領導人的心跳，或者是候選人請求投票的，就自己變成候選人

候選人（5.2 節）：

在轉變成候選人后就立即開始選舉過程

自增當前的任期號（currentTerm）

給自己投票

重置選舉超時計時器

發送請求投票的 RPC 給其他所有服務器

如果接收到大多數服務器的選票，那么就變成領導人

如果接收到來自新的領導人的附加日志 RPC，轉變成跟隨者

如果選舉過程超時，再次發起一輪選舉

領導人：

一旦成為領導人：發送空的附加日志 RPC（心跳）給其他所有的服務器；在一定的空余時間之后不停的重復發送，以阻止跟隨者超時（5.2 節）

如果接收到來自客戶端的請求：附加條目到本地日志中，在條目被應用到狀態機后響應客戶端（5.3 節）

如果對于一個跟隨者，最后日志條目的索引值大于等于 nextIndex，那么：發送從 nextIndex 開始的所有日志條目：

如果成功：更新相應跟隨者的 nextIndex 和 matchIndex

如果因為日志不一致而失敗，減少 nextIndex 重試

如果存在一個滿足N > commitIndex的 N，并且大多數的matchIndex[i] ≥ N成立，并且log[N].term == currentTerm成立，那么令 commitIndex 等于這個 N （5.3 和 5.4 節）

圖 2：一個關于 Raft 一致性算法的濃縮總結（不包括成員變換和日志壓縮）。

圖 3：Raft 在任何時候都保證以上的各個特性。

一個 Raft 集群包含若干個服務器節點；通常是 5 個，這允許整個系統容忍 2 個節點的失效。在任何時刻，每一個服務器節點都處于這三個狀態之一：領導人、跟隨者或者候選人。在通常情況下，系統中只有一個領導人并且其他的節點全部都是跟隨者。跟隨者都是被動的：他們不會發送任何請求，只是簡單的響應來自領導者或者候選人的請求。領導人處理所有的客戶端請求（如果一個客戶端和跟隨者聯系，那么跟隨者會把請求重定向給領導人）。第三種狀態，候選人，是用來在 5.2 節描述的選舉新領導人時使用。圖 4 展示了這些狀態和他們之間的轉換關系；這些轉換關系會在接下來進行討論。

圖 4：服務器狀態。跟隨者只響應來自其他服務器的請求。如果跟隨者接收不到消息，那么他就會變成候選人并發起一次選舉。獲得集群中大多數選票的候選人將成為領導者。在一個任期內，領導人一直都會是領導人直到自己宕機了。

圖 5：時間被劃分成一個個的任期，每個任期開始都是一次選舉。在選舉成功后，領導人會管理整個集群直到任期結束。有時候選舉會失敗，那么這個任期就會沒有領導人而結束。任期之間的切換可以在不同的時間不同的服務器上觀察到。

Raft 把時間分割成任意長度的任期，如圖 5。任期用連續的整數標記。每一段任期從一次選舉開始，就像章節 5.2 描述的一樣，一個或者多個候選人嘗試成為領導者。如果一個候選人贏得選舉，然后他就在接下來的任期內充當領導人的職責。在某些情況下，一次選舉過程會造成選票的瓜分。在這種情況下，這一任期會以沒有領導人結束；一個新的任期（和一次新的選舉）會很快重新開始。Raft 保證了在一個給定的任期內，最多只有一個領導者。

不同的服務器節點可能多次觀察到任期之間的轉換，但在某些情況下，一個節點也可能觀察不到任何一次選舉或者整個任期全程。任期在 Raft 算法中充當邏輯時鐘的作用，這會允許服務器節點查明一些過期的信息比如陳舊的領導者。每一個節點存儲一個當前任期號，這一編號在整個時期內單調的增長。當服務器之間通信的時候會交換當前任期號；如果一個服務器的當前任期號比其他人小，那么他會更新自己的編號到較大的編號值。如果一個候選人或者領導者發現自己的任期號過期了，那么他會立即恢復成跟隨者狀態。如果一個節點接收到一個包含過期的任期號的請求，那么他會直接拒絕這個請求。

Raft 算法中服務器節點之間通信使用遠程過程調用（RPCs），并且基本的一致性算法只需要兩種類型的 RPCs。請求投票（RequestVote） RPCs 由候選人在選舉期間發起（章節 5.2），然后附加條目（AppendEntries）RPCs 由領導人發起，用來復制日志和提供一種心跳機制（章節 5.3）。第 7 節為了在服務器之間傳輸快照增加了第三種 RPC。當服務器沒有及時的收到 RPC 的響應時，會進行重試， 并且他們能夠并行的發起 RPCs 來獲得最佳的性能。

Raft 使用一種心跳機制來觸發領導人選舉。當服務器程序啟動時，他們都是跟隨者身份。一個服務器節點繼續保持著跟隨者狀態只要他從領導人或者候選者處接收到有效的 RPCs。領導者周期性的向所有跟隨者發送心跳包（即不包含日志項內容的附加日志項 RPCs）來維持自己的權威。如果一個跟隨者在一段時間里沒有接收到任何消息，也就是選舉超時，那么他就會認為系統中沒有可用的領導者,并且發起選舉以選出新的領導者。

要開始一次選舉過程，跟隨者先要增加自己的當前任期號并且轉換到候選人狀態。然后他會并行的向集群中的其他服務器節點發送請求投票的 RPCs 來給自己投票。候選人會繼續保持著當前狀態直到以下三件事情之一發生：(a) 他自己贏得了這次的選舉，(b) 其他的服務器成為領導者，(c) 一段時間之后沒有任何一個獲勝的人。這些結果會分別的在下面的段落里進行討論。

當一個候選人從整個集群的大多數服務器節點獲得了針對同一個任期號的選票，那么他就贏得了這次選舉并成為領導人。每一個服務器最多會對一個任期號投出一張選票，按照先來先服務的原則（注意：5.4 節在投票上增加了一點額外的限制）。要求大多數選票的規則確保了最多只會有一個候選人贏得此次選舉（圖 3 中的選舉安全性）。一旦候選人贏得選舉，他就立即成為領導人。然后他會向其他的服務器發送心跳消息來建立自己的權威并且阻止新的領導人的產生。

在等待投票的時候，候選人可能會從其他的服務器接收到聲明它是領導人的附加日志項 RPC。如果這個領導人的任期號（包含在此次的 RPC中）不小于候選人當前的任期號，那么候選人會承認領導人合法并回到跟隨者狀態。 如果此次 RPC 中的任期號比自己小，那么候選人就會拒絕這次的 RPC 并且繼續保持候選人狀態。

第三種可能的結果是候選人既沒有贏得選舉也沒有輸：如果有多個跟隨者同時成為候選人，那么選票可能會被瓜分以至于沒有候選人可以贏得大多數人的支持。當這種情況發生的時候，每一個候選人都會超時，然后通過增加當前任期號來開始一輪新的選舉。然而，沒有其他機制的話，選票可能會被無限的重復瓜分。

Raft 算法使用隨機選舉超時時間的方法來確保很少會發生選票瓜分的情況，就算發生也能很快的解決。為了阻止選票起初就被瓜分，選舉超時時間是從一個固定的區間（例如 150-300 毫秒）隨機選擇。這樣可以把服務器都分散開以至于在大多數情況下只有一個服務器會選舉超時；然后他贏得選舉并在其他服務器超時之前發送心跳包。同樣的機制被用在選票瓜分的情況下。每一個候選人在開始一次選舉的時候會重置一個隨機的選舉超時時間，然后在超時時間內等待投票的結果；這樣減少了在新的選舉中另外的選票瓜分的可能性。9.3 節展示了這種方案能夠快速的選出一個領導人。

領導人選舉這個例子，體現了可理解性原則是如何指導我們進行方案設計的。起初我們計劃使用一種排名系統：每一個候選人都被賦予一個唯一的排名，供候選人之間競爭時進行選擇。如果一個候選人發現另一個候選人擁有更高的排名，那么他就會回到跟隨者狀態，這樣高排名的候選人能夠更加容易的贏得下一次選舉。但是我們發現這種方法在可用性方面會有一點問題（如果高排名的服務器宕機了，那么低排名的服務器可能會超時并再次進入候選人狀態。而且如果這個行為發生得足夠快，則可能會導致整個選舉過程都被重置掉）。我們針對算法進行了多次調整，但是每次調整之后都會有新的問題。最終我們認為隨機重試的方法是更加明顯和易于理解的。

一旦一個領導人被選舉出來，他就開始為客戶端提供服務。客戶端的每一個請求都包含一條被復制狀態機執行的指令。領導人把這條指令作為一條新的日志條目附加到日志中去，然后并行的發起附加條目 RPCs 給其他的服務器，讓他們復制這條日志條目。當這條日志條目被安全的復制（下面會介紹），領導人會應用這條日志條目到它的狀態機中然后把執行的結果返回給客戶端。如果跟隨者崩潰或者運行緩慢，再或者網絡丟包，領導人會不斷的重復嘗試附加日志條目 RPCs （盡管已經回復了客戶端）直到所有的跟隨者都最終存儲了所有的日志條目。

圖 6：日志由有序序號標記的條目組成。每個條目都包含創建時的任期號（圖中框中的數字），和一個狀態機需要執行的指令。一個條目當可以安全的被應用到狀態機中去的時候，就認為是可以提交了。

日志以圖 6 展示的方式組織。每一個日志條目存儲一條狀態機指令和從領導人收到這條指令時的任期號。日志中的任期號用來檢查是否出現不一致的情況，同時也用來保證圖 3 中的某些性質。每一條日志條目同時也都有一個整數索引值來表明它在日志中的位置。

領導人來決定什么時候把日志條目應用到狀態機中是安全的；這種日志條目被稱為已提交。Raft 算法保證所有已提交的日志條目都是持久化的并且最終會被所有可用的狀態機執行。在領導人將創建的日志條目復制到大多數的服務器上的時候，日志條目就會被提交（例如在圖 6 中的條目 7）。同時，領導人的日志中之前的所有日志條目也都會被提交，包括由其他領導人創建的條目。5.4 節會討論某些當在領導人改變之后應用這條規則的隱晦內容，同時他也展示了這種提交的定義是安全的。領導人跟蹤了最大的將會被提交的日志項的索引，并且索引值會被包含在未來的所有附加日志 RPCs （包括心跳包），這樣其他的服務器才能最終知道領導人的提交位置。一旦跟隨者知道一條日志條目已經被提交，那么他也會將這個日志條目應用到本地的狀態機中（按照日志的順序）。

我們設計了 Raft 的日志機制來維護一個不同服務器的日志之間的高層次的一致性。這么做不僅簡化了系統的行為也使得更加可預計，同時他也是安全性保證的一個重要組件。Raft 維護著以下的特性，這些同時也組成了圖 3 中的日志匹配特性：

如果在不同的日志中的兩個條目擁有相同的索引和任期號，那么他們存儲了相同的指令。

如果在不同的日志中的兩個條目擁有相同的索引和任期號，那么他們之前的所有日志條目也全部相同。

第一個特性來自這樣的一個事實，領導人最多在一個任期里在指定的一個日志索引位置創建一條日志條目，同時日志條目在日志中的位置也從來不會改變。第二個特性由附加日志 RPC 的一個簡單的一致性檢查所保證。在發送附加日志 RPC 的時候，領導人會把新的日志條目緊接著之前的條目的索引位置和任期號包含在里面。如果跟隨者在它的日志中找不到包含相同索引位置和任期號的條目，那么他就會拒絕接收新的日志條目。一致性檢查就像一個歸納步驟：一開始空的日志狀態肯定是滿足日志匹配特性的，然后一致性檢查保護了日志匹配特性當日志擴展的時候。因此，每當附加日志 RPC 返回成功時，領導人就知道跟隨者的日志一定是和自己相同的了。

在正常的操作中，領導人和跟隨者的日志保持一致性，所以附加日志 RPC 的一致性檢查從來不會失敗。然而，領導人崩潰的情況會使得日志處于不一致的狀態（老的領導人可能還沒有完全復制所有的日志條目）。這種不一致問題會在領導人和跟隨者的一系列崩潰下加劇。圖 7 展示了跟隨者的日志可能和新的領導人不同的方式。跟隨者可能會丟失一些在新的領導人中有的日志條目，他也可能擁有一些領導人沒有的日志條目，或者兩者都發生。丟失或者多出日志條目可能會持續多個任期。

圖 7：當一個領導人成功當選時，跟隨者可能是任何情況（a-f）。每一個盒子表示是一個日志條目；里面的數字表示任期號。跟隨者可能會缺少一些日志條目（a-b），可能會有一些未被提交的日志條目（c-d），或者兩種情況都存在（e-f）。例如，場景 f 可能會這樣發生，某服務器在任期 2 的時候是領導人，已附加了一些日志條目到自己的日志中，但在提交之前就崩潰了；很快這個機器就被重啟了，在任期 3 重新被選為領導人，并且又增加了一些日志條目到自己的日志中；在任期 2 和任期 3 的日志被提交之前，這個服務器又宕機了，并且在接下來的幾個任期里一直處于宕機狀態。

在 Raft 算法中，領導人處理不一致是通過強制跟隨者直接復制自己的日志來解決了。這意味著在跟隨者中的沖突的日志條目會被領導人的日志覆蓋。5.4 節會闡述如何通過增加一些限制來使得這樣的操作是安全的。

要使得跟隨者的日志進入和自己一致的狀態，領導人必須找到最后兩者達成一致的地方，然后刪除從那個點之后的所有日志條目，發送自己的日志給跟隨者。所有的這些操作都在進行附加日志 RPCs 的一致性檢查時完成。領導人針對每一個跟隨者維護了一個 nextIndex，這表示下一個需要發送給跟隨者的日志條目的索引地址。當一個領導人剛獲得權力的時候，他初始化所有的 nextIndex 值為自己的最后一條日志的index加1（圖 7 中的 11）。如果一個跟隨者的日志和領導人不一致，那么在下一次的附加日志 RPC 時的一致性檢查就會失敗。在被跟隨者拒絕之后，領導人就會減小 nextIndex 值并進行重試。最終 nextIndex 會在某個位置使得領導人和跟隨者的日志達成一致。當這種情況發生，附加日志 RPC 就會成功，這時就會把跟隨者沖突的日志條目全部刪除并且加上領導人的日志。一旦附加日志 RPC 成功，那么跟隨者的日志就會和領導人保持一致，并且在接下來的任期里一直繼續保持。

如果需要的話，算法可以通過減少被拒絕的附加日志 RPCs 的次數來優化。例如，當附加日志 RPC 的請求被拒絕的時候，跟隨者可以包含沖突的條目的任期號和自己存儲的那個任期的最早的索引地址。借助這些信息，領導人可以減小 nextIndex 越過所有那個任期沖突的所有日志條目；這樣就變成每個任期需要一次附加條目 RPC 而不是每個條目一次。在實踐中，我們十分懷疑這種優化是否是必要的，因為失敗是很少發生的并且也不大可能會有這么多不一致的日志。

通過這種機制，領導人在獲得權力的時候就不需要任何特殊的操作來恢復一致性。他只需要進行正常的操作，然后日志就能自動的在回復附加日志 RPC 的一致性檢查失敗的時候自動趨于一致。領導人從來不會覆蓋或者刪除自己的日志（圖 3 的領導人只附加特性）。

日志復制機制展示出了第 2 節中形容的一致性特性：Raft 能夠接受，復制并應用新的日志條目只要大部分的機器是工作的；在通常的情況下，新的日志條目可以在一次 RPC 中被復制給集群中的大多數機器；并且單個的緩慢的跟隨者不會影響整體的性能。

前面的章節里描述了 Raft 算法是如何選舉和復制日志的。然而，到目前為止描述的機制并不能充分的保證每一個狀態機會按照相同的順序執行相同的指令。例如，一個跟隨者可能會進入不可用狀態同時領導人已經提交了若干的日志條目，然后這個跟隨者可能會被選舉為領導人并且覆蓋這些日志條目；因此，不同的狀態機可能會執行不同的指令序列。

這一節通過在領導選舉的時候增加一些限制來完善 Raft 算法。這一限制保證了任何的領導人對于給定的任期號，都擁有了之前任期的所有被提交的日志條目（圖 3 中的領導人完整特性）。增加這一選舉時的限制，我們對于提交時的規則也更加清晰。最終，我們將展示對于領導人完整特性的簡要證明，并且說明領導人是如何領導復制狀態機的做出正確行為的。

在任何基于領導人的一致性算法中，領導人都必須存儲所有已經提交的日志條目。在某些一致性算法中，例如 Viewstamped Replication，某個節點即使是一開始并沒有包含所有已經提交的日志條目，它也能被選為領導者。這些算法都包含一些額外的機制來識別丟失的日志條目并把他們傳送給新的領導人，要么是在選舉階段要么在之后很快進行。不幸的是，這種方法會導致相當大的額外的機制和復雜性。Raft 使用了一種更加簡單的方法，它可以保證所有之前的任期號中已經提交的日志條目在選舉的時候都會出現在新的領導人中，不需要傳送這些日志條目給領導人。這意味著日志條目的傳送是單向的，只從領導人傳給跟隨者，并且領導人從不會覆蓋自身本地日志中已經存在的條目。

Raft 使用投票的方式來阻止一個候選人贏得選舉除非這個候選人包含了所有已經提交的日志條目。候選人為了贏得選舉必須聯系集群中的大部分節點，這意味著每一個已經提交的日志條目在這些服務器節點中肯定存在于至少一個節點上。如果候選人的日志至少和大多數的服務器節點一樣新（這個新的定義會在下面討論），那么他一定持有了所有已經提交的日志條目。請求投票 RPC 實現了這樣的限制： RPC 中包含了候選人的日志信息，然后投票人會拒絕掉那些日志沒有自己新的投票請求。

Raft 通過比較兩份日志中最后一條日志條目的索引值和任期號定義誰的日志比較新。如果兩份日志最后的條目的任期號不同，那么任期號大的日志更加新。如果兩份日志最后的條目任期號相同，那么日志比較長的那個就更加新。

如同 5.3 節介紹的那樣，領導人知道一條當前任期內的日志記錄是可以被提交的，只要它被存儲到了大多數的服務器上。如果一個領導人在提交日志條目之前崩潰了，未來后續的領導人會繼續嘗試復制這條日志記錄。然而，一個領導人不能斷定一個之前任期里的日志條目被保存到大多數服務器上的時候就一定已經提交了。圖 8 展示了一種情況，一條已經被存儲到大多數節點上的老日志條目，也依然有可能會被未來的領導人覆蓋掉。

圖 8：如圖的時間序列展示了為什么領導人無法決定對老任期號的日志條目進行提交。在 (a) 中，S1 是領導者，部分的復制了索引位置 2 的日志條目。在 (b) 中，S1 崩潰了，然后 S5 在任期 3 里通過 S3、S4 和自己的選票贏得選舉，然后從客戶端接收了一條不一樣的日志條目放在了索引 2 處。然后到 (c)，S5 又崩潰了；S1 重新啟動，選舉成功，開始復制日志。在這時，來自任期 2 的那條日志已經被復制到了集群中的大多數機器上，但是還沒有被提交。如果 S1 在 (d) 中又崩潰了，S5 可以重新被選舉成功（通過來自 S2，S3 和 S4 的選票），然后覆蓋了他們在索引 2 處的日志。反之，如果在崩潰之前，S1 把自己主導的新任期里產生的日志條目復制到了大多數機器上，就如 (e) 中那樣，那么在后面任期里面這些新的日志條目就會被提交（因為S5 就不可能選舉成功）。 這樣在同一時刻就同時保證了，之前的所有老的日志條目就會被提交。

為了消除圖 8 里描述的情況，Raft 永遠不會通過計算副本數目的方式去提交一個之前任期內的日志條目。只有領導人當前任期里的日志條目通過計算副本數目可以被提交；一旦當前任期的日志條目以這種方式被提交，那么由于日志匹配特性，之前的日志條目也都會被間接的提交。在某些情況下，領導人可以安全的知道一個老的日志條目是否已經被提交（例如，該條目是否存儲到所有服務器上），但是 Raft 為了簡化問題使用一種更加保守的方法。

當領導人復制之前任期里的日志時，Raft 會為所有日志保留原始的任期號, 這在提交規則上產生了額外的復雜性。在其他的一致性算法中，如果一個新的領導人要重新復制之前的任期里的日志時，它必須使用當前新的任期號。Raft 使用的方法更加容易辨別出日志，因為它可以隨著時間和日志的變化對日志維護著同一個任期編號。另外，和其他的算法相比，Raft 中的新領導人只需要發送更少日志條目（其他算法中必須在他們被提交之前發送更多的冗余日志條目來為他們重新編號）。

在給定了完整的 Raft 算法之后，我們現在可以更加精確的討論領導人完整性特性（這一討論基于 9.2 節的安全性證明）。我們假設領導人完全性特性是不存在的，然后我們推出矛盾來。假設任期 T 的領導人（領導人 T）在任期內提交了一條日志條目，但是這條日志條目沒有被存儲到未來某個任期的領導人的日志中。設大于 T 的最小任期 U 的領導人 U 沒有這條日志條目。

圖 9：如果 S1 （任期 T 的領導者）提交了一條新的日志在它的任期里，然后 S5 在之后的任期 U 里被選舉為領導人，然后至少會有一個機器，如 S3，既擁有來自 S1 的日志，也給 S5 投票了。

在領導人 U 選舉的時候一定沒有那條被提交的日志條目（領導人從不會刪除或者覆蓋任何條目）。

領導人 T 復制這條日志條目給集群中的大多數節點，同時，領導人U 從集群中的大多數節點贏得了選票。因此，至少有一個節點（投票者、選民）同時接受了來自領導人T 的日志條目，并且給領導人U 投票了，如圖 9。這個投票者是產生這個矛盾的關鍵。

這個投票者必須在給領導人 U 投票之前先接受了從領導人 T 發來的已經被提交的日志條目；否則他就會拒絕來自領導人 T 的附加日志請求（因為此時他的任期號會比 T 大）。

投票者在給領導人 U 投票時依然保存有這條日志條目，因為任何中間的領導人都包含該日志條目（根據上述的假設），領導人從不會刪除條目，并且跟隨者只有在和領導人沖突的時候才會刪除條目。

投票者把自己選票投給領導人 U 時，領導人 U 的日志必須和投票者自己一樣新。這就導致了兩者矛盾之一。

首先，如果投票者和領導人 U 的最后一條日志的任期號相同，那么領導人 U 的日志至少和投票者一樣長，所以領導人 U 的日志一定包含所有投票者的日志。這是另一處矛盾，因為投票者包含了那條已經被提交的日志條目，但是在上述的假設里，領導人 U 是不包含的。

除此之外，領導人 U 的最后一條日志的任期號就必須比投票人大了。此外，他也比 T 大，因為投票人的最后一條日志的任期號至少和 T 一樣大（他包含了來自任期 T 的已提交的日志）。創建了領導人 U 最后一條日志的之前領導人一定已經包含了那條被提交的日志（根據上述假設，領導人 U 是第一個不包含該日志條目的領導人）。所以，根據日志匹配特性，領導人 U 一定也包含那條被提交的日志，這里產生矛盾。

這里完成了矛盾。因此，所有比 T 大的領導人一定包含了所有來自 T 的已經被提交的日志。

日志匹配原則保證了未來的領導人也同時會包含被間接提交的條目，例如圖 8 (d) 中的索引 2。

通過領導人完全特性，我們就能證明圖 3 中的狀態機安全特性，即如果服務器已經在某個給定的索引值應用了日志條目到自己的狀態機里，那么其他的服務器不會應用一個不一樣的日志到同一個索引值上。在一個服務器應用一條日志條目到他自己的狀態機中時，他的日志必須和領導人的日志，在該條目和之前的條目上相同，并且已經被提交。現在我們來考慮在任何一個服務器應用一個指定索引位置的日志的最小任期；日志完全特性保證擁有更高任期號的領導人會存儲相同的日志條目，所以之后的任期里應用某個索引位置的日志條目也會是相同的值。因此，狀態機安全特性是成立的。

最后，Raft 要求服務器按照日志中索引位置順序應用日志條目。和狀態機安全特性結合起來看，這就意味著所有的服務器會應用相同的日志序列集到自己的狀態機中，并且是按照相同的順序。

到目前為止，我們都只關注了領導人崩潰的情況。跟隨者和候選人崩潰后的處理方式比領導人要簡單的多，并且他們的處理方式是相同的。如果跟隨者或者候選人崩潰了，那么后續發送給他們的 RPCs 都會失敗。Raft 中處理這種失敗就是簡單的通過無限的重試；如果崩潰的機器重啟了，那么這些 RPC 就會完整的成功。如果一個服務器在完成了一個 RPC，但是還沒有響應的時候崩潰了，那么在他重新啟動之后就會再次收到同樣的請求。Raft 的 RPCs 都是冪等的，所以這樣重試不會造成任何問題。例如一個跟隨者如果收到附加日志請求但是他已經包含了這一日志，那么他就會直接忽略這個新的請求。

Raft 的要求之一就是安全性不能依賴時間：整個系統不能因為某些事件運行的比預期快一點或者慢一點就產生了錯誤的結果。但是，可用性（系統可以及時的響應客戶端）不可避免的要依賴于時間。例如，如果消息交換比服務器故障間隔時間長，候選人將沒有足夠長的時間來贏得選舉；沒有一個穩定的領導人，Raft 將無法工作。

領導人選舉是 Raft 中對時間要求最為關鍵的方面。Raft 可以選舉并維持一個穩定的領導人,只要系統滿足下面的時間要求：

廣播時間（broadcastTime）  <<  選舉超時時間（electionTimeout） <<  平均故障間隔時間（MTBF）

在這個不等式中，廣播時間指的是從一個服務器并行的發送 RPCs 給集群中的其他服務器并接收響應的平均時間；選舉超時時間就是在 5.2 節中介紹的選舉的超時時間限制；然后平均故障間隔時間就是對于一臺服務器而言，兩次故障之間的平均時間。廣播時間必須比選舉超時時間小一個量級，這樣領導人才能夠發送穩定的心跳消息來阻止跟隨者開始進入選舉狀態；通過隨機化選舉超時時間的方法，這個不等式也使得選票瓜分的情況變得不可能。選舉超時時間應該要比平均故障間隔時間小上幾個數量級，這樣整個系統才能穩定的運行。當領導人崩潰后，整個系統會大約相當于選舉超時的時間里不可用；我們希望這種情況在整個系統的運行中很少出現。

廣播時間和平均故障間隔時間是由系統決定的，但是選舉超時時間是我們自己選擇的。Raft 的 RPCs 需要接收方將信息持久化的保存到穩定存儲中去，所以廣播時間大約是 0.5 毫秒到 20 毫秒，取決于存儲的技術。因此，選舉超時時間可能需要在 10 毫秒到 500 毫秒之間。大多數的服務器的平均故障間隔時間都在幾個月甚至更長，很容易滿足時間的需求。

到目前為止，我們都假設集群的配置（加入到一致性算法的服務器集合）是固定不變的。但是在實踐中，偶爾是會改變集群的配置的，例如替換那些宕機的機器或者改變復制級別。盡管可以通過暫停整個集群，更新所有配置，然后重啟整個集群的方式來實現，但是在更改的時候集群會不可用。另外，如果存在手工操作步驟，那么就會有操作失誤的風險。為了避免這樣的問題，我們決定自動化配置改變并且將其納入到 Raft 一致性算法中來。

為了讓配置修改機制能夠安全，那么在轉換的過程中不能夠存在任何時間點使得兩個領導人同時被選舉成功在同一個任期里。不幸的是，任何服務器直接從舊的配置直接轉換到新的配置的方案都是不安全的。一次性自動的轉換所有服務器是不可能的，所以在轉換期間整個集群存在劃分成兩個獨立的大多數群體的可能性（見圖 10）。

圖 10：直接從一種配置轉到新的配置是十分不安全的，因為各個機器可能在任何的時候進行轉換。在這個例子中，集群配額從 3 臺機器變成了 5 臺。不幸的是，存在這樣的一個時間點，兩個不同的領導人在同一個任期里都可以被選舉成功。一個是通過舊的配置，一個通過新的配置。

為了保證安全性，配置更改必須使用兩階段方法。目前有很多種兩階段的實現。例如，有些系統在第一階段停掉舊的配置所以集群就不能處理客戶端請求；然后在第二階段在啟用新的配置。在 Raft 中，集群先切換到一個過渡的配置，我們稱之為共同一致；一旦共同一致已經被提交了，那么系統就切換到新的配置上。共同一致是老配置和新配置的結合：

日志條目被復制給集群中新、老配置的所有服務器。

新、舊配置的服務器都可以成為領導人。

達成一致（針對選舉和提交）需要分別在兩種配置上獲得大多數的支持。

共同一致允許獨立的服務器在不影響安全性的前提下，在不同的時間進行配置轉換過程。此外，共同一致可以讓集群在配置轉換的過程人依然響應客戶端的請求。

集群配置在復制日志中以特殊的日志條目來存儲和通信；圖 11 展示了配置轉換的過程。當一個領導人接收到一個改變配置從 C-old 到 C-new 的請求，他會為了共同一致存儲配置（圖中的 C-old,new），以前面描述的日志條目和副本的形式。一旦一個服務器將新的配置日志條目增加到它的日志中，他就會用這個配置來做出未來所有的決定（服務器總是使用最新的配置，無論他是否已經被提交）。這意味著領導人要使用 C-old,new 的規則來決定日志條目 C-old,new 什么時候需要被提交。如果領導人崩潰了，被選出來的新領導人可能是使用 C-old 配置也可能是 C-old,new 配置，這取決于贏得選舉的候選人是否已經接收到了 C-old,new 配置。在任何情況下， C-new 配置在這一時期都不會單方面的做出決定。

一旦 C-old,new 被提交，那么無論是 C-old 還是 C-new，在沒有經過他人批準的情況下都不可能做出決定，并且領導人完全特性保證了只有擁有 C-old,new 日志條目的服務器才有可能被選舉為領導人。這個時候，領導人創建一條關于 C-new 配置的日志條目并復制給集群就是安全的了。再者，每個服務器在見到新的配置的時候就會立即生效。當新的配置在 C-new 的規則下被提交，舊的配置就變得無關緊要，同時不使用新的配置的服務器就可以被關閉了。如圖 11，C-old 和 C-new 沒有任何機會同時做出單方面的決定；這保證了安全性。

圖 11：一個配置切換的時間線。虛線表示已經被創建但是還沒有被提交的條目，實線表示最后被提交的日志條目。領導人首先創建了 C-old,new 的配置條目在自己的日志中，并提交到 C-old,new 中（C-old 的大多數和  C-new 的大多數）。然后他創建 C-new 條目并提交到 C-new 中的大多數。這樣就不存在  C-new 和 C-old 可以同時做出決定的時間點。

在關于重新配置還有三個問題需要提出。第一個問題是，新的服務器可能初始化沒有存儲任何的日志條目。當這些服務器以這種狀態加入到集群中，那么他們需要一段時間來更新追趕，這時還不能提交新的日志條目。為了避免這種可用性的間隔時間，Raft 在配置更新的時候使用了一種額外的階段，在這個階段，新的服務器以沒有投票權身份加入到集群中來（領導人復制日志給他們，但是不考慮他們是大多數）。一旦新的服務器追趕上了集群中的其他機器，重新配置可以像上面描述的一樣處理。

第二個問題是，集群的領導人可能不是新配置的一員。在這種情況下，領導人就會在提交了 C-new 日志之后退位（回到跟隨者狀態）。這意味著有這樣的一段時間，領導人管理著集群，但是不包括他自己；他復制日志但是不把他自己算作是大多數之一。當 C-new 被提交時，會發生領導人過渡，因為這時是最早新的配置可以獨立工作的時間點（將總是能夠在 C-new 配置下選出新的領導人）。在此之前，可能只能從 C-old 中選出領導人。

第三個問題是，移除不在 C-new 中的服務器可能會擾亂集群。這些服務器將不會再接收到心跳，所以當選舉超時，他們就會進行新的選舉過程。他們會發送擁有新的任期號的請求投票 RPCs，這樣會導致當前的領導人回退成跟隨者狀態。新的領導人最終會被選出來，但是被移除的服務器將會再次超時，然后這個過程會再次重復，導致整體可用性大幅降低。

為了避免這個問題，當服務器確認當前領導人存在時，服務器會忽略請求投票 RPCs。特別的，當服務器在當前最小選舉超時時間內收到一個請求投票 RPC，他不會更新當前的任期號或者投出選票。這不會影響正常的選舉，每個服務器在開始一次選舉之前，至少等待一個最小選舉超時時間。然而，這有利于避免被移除的服務器擾亂：如果領導人能夠發送心跳給集群，那么他就不會被更大的任期號廢黜。

Raft 的日志在正常操作中不斷的增長，但是在實際的系統中，日志不能無限制的增長。隨著日志不斷增長，他會占用越來越多的空間，花費越來越多的時間來重置。如果沒有一定的機制去清除日志里積累的陳舊的信息，那么會帶來可用性問題。

快照是最簡單的壓縮方法。在快照系統中，整個系統的狀態都以快照的形式寫入到穩定的持久化存儲中，然后到那個時間點之前的日志全部丟棄。快照技術被使用在 Chubby 和 ZooKeeper 中，接下來的章節會介紹 Raft 中的快照技術。

增量壓縮的方法，例如日志清理或者日志結構合并樹，都是可行的。這些方法每次只對一小部分數據進行操作，這樣就分散了壓縮的負載壓力。首先，他們先選擇一個已經積累的大量已經被刪除或者被覆蓋對象的區域，然后重寫那個區域還活躍的對象，之后釋放那個區域。和簡單操作整個數據集合的快照相比，需要增加復雜的機制來實現。狀態機可以實現 LSM tree 使用和快照相同的接口，但是日志清除方法就需要修改 Raft 了。

圖 12：一個服務器用新的快照替換了從 1 到 5 的條目，快照值存儲了當前的狀態。快照中包含了最后的索引位置和任期號。

圖 12 展示了 Raft 中快照的基礎思想。每個服務器獨立的創建快照，只包括已經被提交的日志。主要的工作包括將狀態機的狀態寫入到快照中。Raft 也包含一些少量的元數據到快照中：最后被包含索引指的是被快照取代的最后的條目在日志中的索引值（狀態機最后應用的日志），最后被包含的任期指的是該條目的任期號。保留這些數據是為了支持快照后緊接著的第一個條目的附加日志請求時的一致性檢查，因為這個條目需要前一日志條目的索引值和任期號。為了支持集群成員更新（第 6 節），快照中也將最后的一次配置作為最后一個條目存下來。一旦服務器完成一次快照，他就可以刪除最后索引位置之前的所有日志和快照了。

盡管通常服務器都是獨立的創建快照，但是領導人必須偶爾的發送快照給一些落后的跟隨者。這通常發生在當領導人已經丟棄了下一條需要發送給跟隨者的日志條目的時候。幸運的是這種情況不是常規操作：一個與領導人保持同步的跟隨者通常都會有這個條目。然而一個運行非常緩慢的跟隨者或者新加入集群的服務器（第 6 節）將不會有這個條目。這時讓這個跟隨者更新到最新的狀態的方式就是通過網絡把快照發送給他們。

安裝快照 RPC：

由領導人調用以將快照的分塊發送給跟隨者。領導者總是按順序發送分塊。

接收者實現：

如果term < currentTerm就立即回復

如果是第一個分塊（offset 為 0）就創建一個新的快照

在指定偏移量寫入數據

如果 done 是 false，則繼續等待更多的數據

保存快照文件，丟棄具有較小索引的任何現有或部分快照

如果現存的日志條目與快照中最后包含的日志條目具有相同的索引值和任期號，則保留其后的日志條目并進行回復

丟棄整個日志

使用快照重置狀態機（并加載快照的集群配置）

圖 13：一個關于安裝快照的簡要概述。為了便于傳輸，快照都是被分成分塊的；每個分塊都給了跟隨者生命的跡象，所以跟隨者可以重置選舉超時計時器。

在這種情況下領導人使用一種叫做安裝快照的新的 RPC 來發送快照給太落后的跟隨者；見圖 13。當跟隨者通過這種 RPC 接收到快照時，他必須自己決定對于已經存在的日志該如何處理。通常快照會包含沒有在接收者日志中存在的信息。在這種情況下，跟隨者丟棄其整個日志；它全部被快照取代，并且可能包含與快照沖突的未提交條目。如果接收到的快照是自己日志的前面部分（由于網絡重傳或者錯誤），那么被快照包含的條目將會被全部刪除，但是快照后面的條目仍然有效，必須保留。

這種快照的方式背離了 Raft 的強領導人原則，因為跟隨者可以在不知道領導人情況下創建快照。但是我們認為這