一套以可理解性為設計目標的 leader 式共識演算法，安全性與效率等同 multi-Paxos，但教得會也寫得出來。
Raft 管理一份 replicated log，提供與 multi-Paxos 相同的保證，但它從第一天就是為了「讓人真的看得懂、也寫得出來」而設計。它選出唯一一位權威的 leader：客戶端只跟 leader 說話，log entry 只從 leader 單向流向 follower，而 AppendEntries 的一致性檢查搭配 Log Matching Property，會把分歧的 follower log 硬拉回與 leader 一致。時間被切成一段段 term 充當邏輯時鐘，選舉採用隨機化的 timeout 讓分票變得罕見，而選舉限制——候選人的 log 至少要跟投票給它的那個多數派一樣新——保證每位新 leader 在當選那一刻就已握有全部已提交的 entry，log 因此永遠不必倒流。論文另外規範了線上變更成員的 joint consensus、以 snapshot 為基礎的 log 壓縮合併，以及線性一致的客戶端語意。43 位學生的使用者研究中有 33 位 Raft 成績勝過 Paxos，滿分 60 分的平均是 25.7 對 20.8。
這篇論文問世前的十年，共識幾乎等同於 Paxos：課堂上教的是它，幾乎每個實作也都拿它當起點。但 Lamport 的說明以 single-decree Paxos 為核心，那是一個被切成兩階段、兩階段都沒有簡單直觀解釋、也無法各自獨立理解的協定；而把多個實例組成 multi-Paxos 的規則只有草稿式的描述，業界始終沒有一套公認的 multi-Paxos 演算法。實務系統——Chubby、ZooKeeper，以及 GFS、HDFS、RAMCloud 底下的協調層——每一個都從 Paxos 出發，撞上缺失的細節，最後長成架構明顯不同的東西，而且細節多半沒有公開；Chubby 的實作者自己寫下：最終系統將建立在一個未經證明的協定之上。Ongaro 與 Ousterhout 提到他們在 NSDI 2012 做過一次非正式調查，即使在資深研究者之中，也很少人自認對 Paxos 感到自在；他們自己則是讀了好幾份簡化說明、又動手設計出一套替代協定之後才真正弄懂完整協定，前後花掉將近一年。他們的結論是：無論作為系統建構的基礎或教學的基礎，Paxos 都不夠好，而「對一整條 log 達成共識」這個問題值得換一種拆法重新來過。
作者的首要目標不是新穎、也不是把訊息數壓到最少，而是讓夠大的一群人能舒服地理解這個演算法，並對它建立直覺。每一個設計分岔口他們都問：這個選項有多難解釋、它的狀態空間有多複雜？而他們反覆使用兩種可複製的技巧：問題拆解，把共識切成 leader 選舉、log 複寫、安全性與成員變更；以及狀態空間縮減，消去不確定性，並禁止 log 出現空洞。這件事之所以重要，是因為論文上的形式從來不是最後上線的形式；開發者必然會偏離、也必然會擴充，唯有具備深層直覺，才可能在改動之後仍保住原有性質。隨機性只被保留在一個地方，正是因為它反而縮小狀態空間——所有可能的選擇都以同一種方式處理，讀者只要想「隨便挑一個，沒差」就好。
Raft 採用比 Paxos 或 Viewstamped Replication 更強的領導形式：log entry 只從 leader 往外流，而 leader 從不覆寫或刪除自己 log 裡的 entry。新 entry 放在哪裡由 leader 一人決定，不需要跟任何人商量；於是「讓分歧的複本重新一致」這個問題塌縮成單一方向——強迫 follower 複製 leader 的 log——而不是一場對稱的合併。Viewstamped Replication 的 log entry 是雙向流動的，因為 leader 在選舉過程中可以接收 entry，這就多出額外機制與複雜度。這也是為什麼 Raft 的基本共識加上成員變更只需要四種訊息型別（兩個 RPC 請求與其回覆），而 VR 與 ZooKeeper 各自定義了十種。
Raft 把時間切成長度任意的 term，以連續整數編號；每個 term 以一次選舉開場、最多只會有一位 leader，而若票被分散，這個 term 也可能自始至終沒有 leader。每台伺服器保存單調遞增的 currentTerm，而且每次 RPC 都交換當前 term：看到更大 term 的伺服器直接採用它，而發現自己 term 過期的 candidate 或 leader 會立刻退回 follower 狀態。帶著過期 term 的請求則一律被拒絕。這一個機制就同時偵測出過期 leader、過時訊息與癒合中的網路分割，完全不需要實體時鐘，並把「這份資訊還新嗎」化約成一次整數比較。
Raft 不替候選人排名次，也不外掛一套獨立的選舉協定，而是讓每個 follower 從固定區間（例如 150–300ms）隨機抽一個 timeout 才轉成 candidate，並在每次選舉開始時重新抽一次。把各台伺服器在時間軸上散開，通常只有一台會先逾時、先勝出，並在其他人醒來前就送出心跳；真的發生分票時，重新抽出的隨機等待也讓下一輪再度分票的機率很低。作者原本試過一套決定性的排名方案，讓排名較低的候選人讓位給排名較高者，但每修好一個可用性的邊角情況，就又冒出新的邊角情況。最後隨機化以可理解性勝出：它對所有選擇一視同仁，讀者根本不必逐案推理。
Raft 維持 Log Matching Property：若兩份 log 有 index 與 term 都相同的 entry，則該位置存的是同一個指令，而且兩份 log 在其之前的所有 entry 完全相同。前半成立，是因為 leader 在同一個 term、同一個 index 至多只會產生一個 entry，而 entry 的位置永不改變。後半則由單一道檢查保證：每個 AppendEntries 都帶上新 entry 前一格的 index 與 term，follower 若找不到相符的 entry 就拒絕這次追加。這道檢查其實是歸納法的推進步驟：空 log 天然滿足此性質，而每次延長 log 時檢查都會保住它；因此只要 AppendEntries 成功回覆，leader 就知道 follower 的 log 到新 entry 為止都與自己完全相同。
Raft 不是先隨便選一位 leader、再把它缺的 entry 補送過去，而是保證新 leader 在當選那一刻就已握有每一筆已提交的 entry。RequestVote 帶上候選人的 lastLogIndex 與 lastLogTerm，投票者若判定自己的 log 比較新就拒絕投票：最後一筆 entry 的 term 較大者較新，term 相同時則較長者較新。由於候選人需要一個多數派，而任何已提交的 entry 都存在於某個多數派上，兩個集合必然相交——至少有一位投票者持有該 entry，而它會拒絕投給缺少該 entry 的候選人。這正是單向 log 流動得以成立的原因，也省掉了 Viewstamped Replication 在選舉期間或選後補送 entry 的那整套機制。
讓伺服器直接從舊組態切換到新組態並不安全，因為各台切換的時刻不同，叢集可能短暫裂成「Cold 的一個多數派」與「Cnew 的一個多數派」，兩邊各自為同一個 term 選出一位 leader。Raft 改為先提交一個過渡組態 Cold,new：entry 要複寫到兩個組態的所有伺服器，兩個組態的伺服器都可以當 leader，而任何一致決定——包含選舉與 entry 提交——都必須同時取得新舊兩個組態各自的多數派。多數派彼此重疊，意味著任一組態都無法單方面下決定，於是根本不存在分歧視窗，而叢集在整個變更過程中照常服務客戶端。組態以普通 log entry 的形式傳播，而且伺服器一把它追加進 log 就立即生效，不管提交與否——這正是允許各台在不同時間點跨越、卻仍然安全的關鍵。
每台伺服器在任一時刻是 leader、follower 或 candidate 三者之一；follower 是被動的，只回應 RPC，客戶端若連到 follower 會被導向 leader。所有伺服器都必須在回覆任何 RPC 之前寫進穩定儲存的持久狀態有三項：currentTerm、votedFor 與 log[]，其中每個 entry 存著狀態機指令以及 leader 收到它時的 term；揮發狀態是 commitIndex 與 lastApplied，leader 另外為每個 follower 維護 nextIndex[] 與 matchIndex[]。基本共識只需要兩種 RPC：candidate 發出的 RequestVote，以及 leader 發出、既負責複寫 entry 也充當心跳的 AppendEntries；第 7 節再加上 InstallSnapshot。RPC 平行送出並持續重試到有回應為止，而任何伺服器只要看到比自己大的 term，就把 currentTerm 更新過去並轉為 follower。
follower 在一個選舉 timeout 內收不到任何有效 RPC，就把 currentTerm 加一、轉成 candidate、投自己一票，並平行對其他所有伺服器送出 RequestVote。接下來只有三種結局：在該 term 取得整個叢集的多數票而當選，隨即以心跳壓制其他競爭者；收到某台 term 不小於自己的伺服器送來的 AppendEntries，於是退回 follower；或是 timeout 到期仍無人勝出，就以更高的 term 重啟一次選舉。每台伺服器在同一個 term 內先到先得、至多投一票，光是這條規則就給出 Election Safety——每個 term 至多一位 leader。安全性從不依賴時序，可用性卻完全依賴：Raft 只有在 broadcastTime 遠小於 electionTimeout、而 electionTimeout 又遠小於 MTBF 時才維持得住穩定的 leader；論文估計 broadcastTime 約 0.5–20ms（因為 RPC 通常要落到穩定儲存）、electionTimeout 約 10–500ms，而典型伺服器 MTBF 為數個月以上。
leader 把客戶端指令追加到自己的 log，平行送出 AppendEntries，等到該 entry 提交——也就是由產生它的 leader 複寫到多數派——才套用到狀態機並回覆客戶端；這同時也提交了它前面所有 entry，包括先前 leader 留下的 entry。leader 把 commitIndex 夾帶在後續的 AppendEntries 與心跳裡，讓 follower 知道可以套用到哪；而所有伺服器一律嚴格依 log index 順序套用。leader 當機會讓 follower 缺 entry、多出未提交的 entry、或兩者兼有，而且可能橫跨多個 term（Figure 7 把各種情形都列了出來）；leader 靠 nextIndex 修復，初始值設為自己最後 index 加一，每被一致性檢查拒絕一次就遞減並重試，直到雙方對上為止——此時 AppendEntries 會刪掉 follower 衝突的尾段並補上 leader 的 entry。可選的最佳化是讓拒絕的 follower 回報衝突 entry 的 term 以及它為該 term 存的第一個 index，讓 leader 一個 RPC 跳過一整個 term，而不是一個 RPC 只退一格。follower 與 candidate 當機則完全不需要特別處理：leader 無限重試，而 Raft 的 RPC 是冪等的，重送的 AppendEntries 若帶的 entry 已在 log 裡就直接忽略。
leader 不能因為某個舊 term 的 entry 現在剛好存在於多數派上，就斷定它已提交：Figure 8 展示 S1 把 term 2 的 entry 複寫到多數派後，S5 在更晚的 term 當選並把它覆寫掉。因此 Raft 絕不以「數複本」的方式提交先前 term 的 entry——提交規則要求 log[N].term 等於 currentTerm——而一旦當前 term 的任一 entry 提交，前面所有 entry 就透過 Log Matching 間接提交。新 leader 重新複寫舊 entry 時，entry 保留原本的 term 編號，這讓推理更容易，也比那些必須先重編號才能提交的演算法少送許多冗餘 entry。Leader Completeness 的證明梗概是一個反證：若大於 T 的最小 term U 的 leader 缺少 term T 的 leader 已提交的某個 entry，那麼必有一位投票者既接受過該 entry、又投票給 leader U；而 up-to-date 檢查會逼出兩種情況之一——要嘛 leader U 的 log 涵蓋投票者的全部 entry，要嘛 leader U 最後一筆 entry 的 term 來自某個本身就持有該 entry 的更早 leader——兩者都導致矛盾。State Machine Safety 隨之成立，因為伺服器依 index 順序套用，而所有更晚的 leader 在該 index 上存的都是同一筆 entry。
收到重組態請求時，leader 追加一個 Cold,new entry 並複寫出去；伺服器只要在自己 log 裡看到某個組態就立刻採用，不管它是否已提交，因此 leader 判斷 Cold,new 是否提交時，用的正是 Cold,new 自己的規則——新舊兩個組態各自的多數派。若 leader 在變更中途當機，新 leader 可能在 Cold 之下、也可能在 Cold,new 之下產生，但這段期間 Cnew 絕不可能單方面下決定。Cold,new 一旦提交，Leader Completeness 就確保只有持有該 entry 的伺服器能當選，於是 leader 可以安全地追加 Cnew；當 Cnew 依自己的規則提交後，不在新組態內的伺服器就可以關機。論文另外處理了三個實務細節：新伺服器先以不計入多數派的 non-voting 成員身分加入並接收 entry，避免它追進度的期間卡住提交；不在 Cnew 內的 leader 會繼續複寫但不把自己算進多數派，並在 Cnew 提交後退位；而被移除的伺服器因為不再收到心跳，本會逾時並用越來越高的 term 把現任 leader 拉下來，因此規定：伺服器若在距離上次聽到現任 leader 不到最小選舉 timeout 的期間內收到 RequestVote，一律忽略。
每台伺服器各自為自己 log 中已提交的前段拍 snapshot：由狀態機寫出當前狀態，再加上少量 metadata——last included index、last included term，以及該 index 當下 log 中最新的組態——然後就可以刪掉該 index 以前的全部 log entry 以及任何舊 snapshot。保留 last included index 與 term，是為了讓 snapshot 之後第一個 entry 仍有前一格可供 AppendEntries 的一致性檢查比對。當 leader 已經丟掉某個落後 follower 需要的 entry（可能是異常緩慢的伺服器，或是剛加入叢集的新機器），就改送 InstallSnapshot：分塊、依序傳送，每一塊同時也是給 follower 的生命跡象，讓它重設選舉計時器；follower 收到後通常直接丟棄整份 log，只有在 snapshot 恰好只涵蓋自己 log 的前綴時，才僅刪掉被涵蓋的部分、保留其後的 entry。各自獨立拍 snapshot 是有意偏離強 leader 原則的，理由是這些 entry 早已達成共識、不可能再有衝突的決定；而只讓 leader 拍再送給所有人，既浪費頻寬也讓 leader 實作更複雜。以「log 超過固定位元組大小」作為拍照時機可讓磁碟開銷維持很小，而 copy-on-write（作者的實作使用 Linux 的 fork）則讓寫 snapshot 不會拖慢正常操作。
客戶端一開始隨機挑一台伺服器連線；若對方不是 leader，它會拒絕請求並附上自己最近聽過的 leader 是誰——因為 AppendEntries 請求本身就帶著 leader 的網路位址。leader 當機後的重試可能讓同一個指令執行兩次，因為舊 leader 可能已提交該 entry 卻在回覆前掛掉；解法是每個指令帶一個唯一的客戶端序號，狀態機為每個客戶端記住最新處理過的序號與對應回應，遇到重複序號就直接回覆而不重新執行。唯讀操作可以完全不寫 log，但需要兩道額外防護才不會讀到過期資料：leader 在 term 開始時提交一筆空白的 no-op entry，好知道究竟哪些 entry 真的已提交；而且在回覆唯讀請求前，先與多數派交換一輪心跳，確認自己還沒被取代。若改用以心跳間隔為基礎的 lease 就能省下這一趟往返，但那會讓安全性依賴有界的時鐘偏移，而這是 Raft 在其他地方一律避免的。
Raft 成為 2010 年代基礎設施的預設共識演算法，很大一部分原因是 Figure 2 本身就是一份開發者幾乎可以逐行照抄實作的規格。CoreOS 依本文草稿寫出的 etcd，是 Kubernetes 存放全部叢集狀態的地方，而它的 Go raft 函式庫被 CockroachDB 與 TiKV 整套沿用——兩者都採用每個 key range 或 region 各跑一個 Raft group 的 multi-Raft 設計，藉此繞開單一 leader 的吞吐量天花板。HashiCorp 的 Consul、Nomad 與 Vault，MongoDB 的 replication protocol version 1，Apache Kafka 用來取代 ZooKeeper 的 KRaft 模式，Neo4j 的 causal clustering，以及 RethinkDB、Hazelcast、Apache Ratis，全都採用同一套「leader 加 term 加 log」的骨架。joint consensus 反而是最少被照抄的部分：多數系統改用 Ongaro 2014 年博士論文裡「一次只增減一台」的做法，而且幾乎都自行補上 Pre-Vote 與明確的 leadership transfer。那份 400 行的 TLA+ 規格給了社群一個可機器檢查的參考基準，後續的模型檢查與驗證工作都建立在它之上；而像 MIT 6.824 這類課程，如今教共識的方式已經是讓學生動手實作 Raft，而不是去讀 Paxos。它最廣泛的影響或許是：讓「可理解性」正式成為系統論文裡站得住腳、而且可以量測的設計目標——背後有一個對照式的使用者研究，而不只是一句主張。
“In order to enhance understandability, Raft separates the key elements of consensus, such as leader election, log replication, and safety, and it enforces a stronger degree of coherency to reduce the number of states that must be considered.”
“It was important not just for the algorithm to work, but for it to be obvious why it works.”
“To eliminate problems like the one in Figure 8, Raft never commits log entries from previous terms by counting replicas.”