如何讓一群節點對「一個單一且有序的決策序列」達成一致——這是本篇唯一的主軸。

多台機器各自接受寫入，狀態必然分叉。要讓它們表現得像「一台機器」，系統需要一份所有存活節點都同意、且一旦回覆客戶端成功就不會被回捲的 log。Raft 把這件事做成可實作的協定：同一個 term 最多一個 Leader 負責編號與複製，Follower 只附加、不改寫歷史；多數派持久化之後，那筆決策才算 committed，才能安全地套用到狀態機、回覆客戶端。

資料複寫基礎講的是主從拓撲與同步／異步取捨；進階複寫與一致性講的是讀到什麼（R + W > N、Session Guarantees、Version Vector）。那些處理「多個副本上的值如何收斂」。本篇處理的是協定如何決定唯一順序——log 裡第 i 筆是什麼、何時不能再改。產品化之後對外的 Watch、Ephemeral Node、分散式鎖，交給 協調服務與分散式鎖；每個 shard 一個 Raft group、跨 shard 交易與 TrueTime，是 Distributed SQL 的事，這裡只點出「分片邊界 = 共識組邊界」。

沒有單一決策者時，每個節點都是合法的寫入入口——分區一來，歷史就拆成兩條。

兩台都接受 SET x 的複本，在網路正常時看起來像同步；一分區，左側寫 x=A、右側寫 x=B，修復後沒有客觀的「誰比較新」。時間戳不可靠（時鐘跳動），「最後寫入獲勝」只是再引入一個衝突規則，不是共識。要讓狀態機確定性重放，所有節點必須先同意同一份指令序列，再各自套用。

兩欄的差別不在「有沒有複製」，而在誰有權編號：左邊兩側都能編號，於是同一個 index 可以是兩筆不同的東西；右邊只有一個 Leader 編號，少數派寫下的尾巴因此可以被安全地切掉。

這份 log 有兩個不可妥協的性質：

• 唯一順序：index i 在所有節點上要麼還沒有、要麼是同一筆（同 term、同指令）。
• 不可回捲已確認寫入：一旦 Leader 告訴客戶端「成功」，該項目必須出現在之後每一位 Leader 的 log 裡。否則金融入帳、鎖釋放、組態變更都會幽靈消失。

注意箭頭是單向的。反過來不成立：一筆項目就算已經複製到多數派，也未必已經提交、更未必回覆過客戶端。這個縫隙看起來像吹毛求疵，卻是共識協定最容易出錯的地方——第 6 章會用論文的 Figure 8 場景說明它為什麼會吃掉已確認的寫入。

Follower 待命、Candidate 拉票、Leader 編號。Term 單調增加，用來作廢過期的權力。

1 · 三個角色

同一 term 最多一個 Leader。兩個 Leader 同時存活，只可能發生在它們處於不同 term——這正是後面 fencing 要處理的腦裂。

2 · Term 是邏輯時鐘，不是牆鐘

每次選舉開始，候選人把 currentTerm 加一。任何 RPC 若攜帶更大的 term，收件者先更新自己的 term、放棄手上的 Leader／Candidate 身分，再處理請求。這樣過期的 Leader 一旦聽到新世界，權力自動作廢。牆鐘不同步不會讓 term 倒退；它只影響「誰先超時」。

實線是「往上爬」的轉移，虛線是「被作廢」的轉移。注意兩條虛線都終止於 Follower——Raft 沒有任何一條邊可以從 Leader 直接跳到 Candidate，權力只會先歸零再重選。圖上刻意不畫 Candidate 的自迴圈（split vote 後換新 term 重選），那是下一段的主題。

3 · 隨機 Election Timeout 拆開同時超時

若所有 Follower 用同一個超時、在同一毫秒發現 Leader 靜音，他們會在同一 term 同時變成 Candidate、互不投票，形成票數瓜分（split vote）。Raft 的解法極其工程：每個節點從區間（例如 150–300 ms）抽隨機超時。先響的那位先發 RequestVote，其他人還在等，就會把票投給他。即使偶發瓜分，下一個隨機超時幾乎不會再對齊。

「拆開」到什麼程度才夠？這句口訣其實是一道可以算的題。設區間寬度 W = T_max − T_min、單程網路延遲 D、參與抽籤的存活節點 m 台。最早超時者在 t 發出 RequestVote，訊息在 t + D 抵達其他人；凡是自己的籤落在這段 D 寬的前導區間裡的節點，會在收到拉票之前先自己變成 Candidate——那就是一次瓜分。把「所有人的籤都落在安全側」的機率積出來，會得到一個乾淨的閉式：

上半部每一條橫條是一台存活節點的抽籤區間（不是時間線）：整條寬 W，左端 D 寬的斜紋是危險前導段，未斜紋的比例就是 (W − D) / W。下半部的連乘階梯把「為什麼是 m 次方」畫出來——每多一台一起抽籤的節點，安全比例就再乘一次，最後一根就是 P。兩處申報：E[T] = C / P 是簡化模型（失敗的那一輪也按整輪成本 C 計），且區間被拖成上界小於下界時一律夾成 W = max(1, T_max − T_min)、只剩一台在抽籤時 P 定義為 1。

不是誰先舉手誰當選。票只投給「log 至少跟我一樣新」的候選人，這才保得住已提交的歷史。

RequestVote 攜帶候選人的 term、lastLogTerm、lastLogIndex。Follower 答應的條件有兩條，缺一不可：

• 這個 term 還沒投過（每個 term 一票；已投給別人就拒絕）。
• 候選人的 log 至少與自己一樣新：先比最後一筆的 term，term 相同再比 index。自己比較新就拒絕——否則一個空白節點靠先超時就能當選，然後用空 log 覆蓋已提交的歷史。

「新」的第一鍵是最後一筆的 term，不是 log 長度。較新的 term 代表那條歷史已經經歷過更新的選舉，較可能含有已提交項目。

多數派的定義是 ⌊N / 2⌋ + 1。五節點集群要三票（含自己）。候選人同時只會在一個 term 拉票；拿到多數立刻轉 Leader，開始心跳以阻止其他人再選。

這裡要避開一個常見誤讀：投票規則不保證「log 最新的那台一定當選」，它只擋下「舊到拿不出多數票」的候選人。若某台沒有跟上最後那幾筆未提交的項目，卻仍湊得出三票，它照樣合法當選——那段尾巴接著會被截斷。這不違反任何承諾，因為未提交的項目從來沒有回覆過客戶端成功。第 9 節的 log 推進互動可以讓你親手挑一條路走走看：同樣的崩潰，換一個接任者、或讓那條尾巴多複製一台，命運就完全相反。

Leader 附加、Follower 對齊、多數派落盤後才推進 commitIndex——這一步之前不能回覆客戶端成功。

1 · AppendEntries 與一致性檢查

Leader 為每位 Follower 維護 nextIndex（下一個要送的位置）與 matchIndex（已知已複製到的最高位置）。RPC 帶著 prevLogIndex / prevLogTerm：Follower 若在該位置對不上，回覆失敗。Leader 把該 Follower 的 nextIndex 往回退，重送更早的項目，直到對上為止。對上之後，Follower 截斷後面衝突的尾巴，再附加 Leader 送來的新項目。未提交的分歧允許被切掉；已提交的前綴因為 Log Matching，本來就不會衝突。

1. 1
   Client SET x=1 抵達 Leader
   寫入還沒進任何 log。送到 Follower 的請求會被轉介或拒絕——只有 Leader 能編號。
2. 2
   Leader 本地 append 到 index i
   順序在這一刻決定。此時回覆客戶端成功就是說謊：這筆只存在一台機器上。
3. 3
   AppendEntries 帶 prevLogIndex / prevLogTerm 送出
   錨點檢查。對不上的 Follower 回失敗，Leader 把它的 nextIndex 往回退再重送，直到對上為止。
4. 4
   Follower 截斷衝突尾巴、持久化、回 ACK
   落盤才算數——回 ACK 代表「已寫進我的磁碟」，不是「已收到」。
5. 5
   多數派 ACK → commitIndex 推進
   五節點要三份（含 Leader 自己）。而且該項目的 term 必須等於現任 term——第 6 節解釋這個限制從哪來。
6. 6
   套用到狀態機 → 回覆客戶端 OK
   到這一步，那筆寫入才真正成為歷史的一部分。

2 · 何時能回覆客戶端

commitIndex 是 Leader 知道「多數派已持久化」的最高 index。只有 commitIndex 推進過的項目，Leader 才套用到狀態機並回覆成功。只寫在 Leader 本地、或只複製到少數派，都還是 uncommitted——Leader 崩潰後可以被下一任截斷。這就是「成功」的契約：不是 Leader 記憶體裡有，是多數派磁碟裡有。

這是一條推進規則，不是絕對定義：commitIndex 只增不減。新 Leader 剛當選、本 term 還沒提交任何項目時，右邊的集合是空的，但它從前任繼承的 commitIndex 不會因此倒退。式子裡的「現任 term」也不是筆誤，第 6 節會解釋為什麼不能單憑計數把前任 term 的項目標成 committed。

兩條不變量保住已確認寫入；一條反直覺規則防止「數人頭」把未封印的歷史提前定稿。

1 · Log Matching

若兩個節點的 log 在某 index 有相同 term，則從開頭到該 index 的所有項目完全相同。AppendEntries 的 prevLog 檢查 + 衝突截斷，讓這條不變量在每一步複製後都成立。它的用途是：Leader 不必重傳整份歷史來證明前綴一致，檢查一個錨點就夠。

2 · Leader Completeness

若一筆項目在某 term 被提交，之後任何 term 的 Leader 都帶有這筆項目。證明骨架：提交需要當時的多數派；下一任要當選也需要一個多數派；兩個多數派必相交，相交的那台持有已提交項目，又因為投票規則拒絕 log 比較舊的候選人，當選者至少跟相交者一樣新——於是已提交項目跟著走。

綠色 = 已提交、黃虛線 = 已複製但未提交、斜線底 = 該位置還沒有項目、紅色 = 原本的項目被後續 Leader 覆蓋掉。左欄階段 2 的 S1 已經崩潰，它的 log 停在崩潰當下、不再參與任何決策。兩欄的差別只有一件事：右邊多提交了一筆現任 term 的項目。這就是論文 Figure 8 的全部結論。

換機器比換 log 更危險。Joint consensus 讓舊集合與新集合同時過半；強 Leader 則是拿彈性換可理解性。

1 · 一次換掉多數派會裂成兩個合法集群

五節點 {A,B,C,D,E} 若直接改成 {C,D,E,F,G}，舊多數 {A,B,C} 與新多數 {E,F,G} 可以在過渡期同時選出 Leader——兩份 log、兩份真實。這不是實作 bug，是「新舊多數不相交」的組合後果。

Joint consensus 把變更本身寫進 log，而且規則很反直覺：節點一 append 到 C_old,new 就立刻採用它，不等提交。之後任何決策（含下一場選舉）都必須同時取得舊集合多數 與 新集合多數；兩組多數的交集非空，所以不會出現兩個 Leader。等 C_old,new 被提交，才可以 append C_new；C_new 提交後舊節點才能下線。若改成「提交後才生效」，append 到 commit 之間會留下一段只需舊多數的窗口，Safety 就從那裡漏掉。實務上 etcd / Consul 常把變更限制成一次加一台或減一台，讓每一步的新舊多數自然相交，同等安全、狀態機比較簡單。

2 · Paxos / Multi-Paxos 對照

Raft 並沒有放寬 Safety，它把「先選出強 Leader，再由他編號」做成預設路徑。代價是選舉期間集群不接受寫入；換到的是可教學、可實作、可審查的狀態機。

在 Distributed SQL 裡，這份協定的應用面很窄、但關鍵：每個 shard / range 一個 Raft group。單一分片的線性寫入由該 group 的 Leader 提供；跨分片原子性是另一層交易協定的事，不是把全世界放進同一個 Raft log。

舊 Leader 在分區另一側仍自認 Leader。Raft log 是安全的；寫到外部資源則必須另加單調 token。

分區把 N1（舊 Leader, term 1）隔開，N2–N5 選出 N2（term 2）。N1 還沒聽到更高 term，心跳繼續、客戶端若連到它仍會把寫入送進去。對 Raft log 本身這是安全的：N1 湊不齊多數派，commitIndex 不會前進，它不該回覆成功。危險在協定外面：N1 可能對磁碟陣列、物件儲存、或另一個沒有共識的資料庫發出副作用——那些系統不知道 term 已經換人。

關鍵差別在誰做檢查：左欄把判斷留在持有者身上（我的 lease 還沒到期），右欄把判斷搬到被保護的資源上（我見過更大的 token）。只有後者不依賴任何一方的時鐘。

這是 協調服務與分散式鎖 那一篇展開的同一條正確性論證：鎖 = lease + fencing token。那篇的鎖競態時間軸互動可以把這段競態一秒一秒攤開——GC pause 多長、keepalive 多久一次、租約何時過期、危險窗有多寬，都是算出來的；本篇不重複那個模擬。token 的定義是由共識集群分配、單調遞增、客戶端無法偽造的世代號——在 Raft 裡它就是 term；換成協調服務，會是 ZooKeeper 的 zxid 或 etcd 鎖 key 的 revision。沒有這樣一個世代號，任何「我還是主」的宣告在分區下都只是意見。

你選誰當 term 1 的 Leader、第二筆寫入複製到幾台、崩潰後由誰接任；投票規則與提交規則負責算出每一步的 log 矩陣、票型與 commitIndex。

第 6 節的 Figure 8 對照圖是靜態的結論。這裡把同一組規則交到你手上：三個選擇一共一百種組合，每一步的狀態都由規則推出來，沒有預寫的劇本。特別注意第二筆寫入的複製台數那支滑桿——它同時決定兩件事：那筆寫入算不算已提交，以及接任者拿不拿得到票。

橫軸是 log index、縱軸是節點，所以「同一 index 在不同節點上是不是同一筆」可以直接對齊著看。三個讀法：格子裡印的是該位置的 term 號（不是佔用與否）；綠色直線是 commitIndex 的封印線，線左側的前綴再也不會被任何後任 Leader 改寫；節點名右邊那道欄位在選舉步會變成票標，把每一張 YES／NO 連同「我的 last log 比你新」的理由一起印出來。（nextIndex 回溯要 Follower 落後多筆才會觸發，這裡刻意讓衝突都落在下一個 index，好把注意力留給提交規則。）

先畫「誰在決定順序」，再談讀取、分片與鎖。協定講完就停，不要滑進產品 API。

本篇停在協定。Watch、Ephemeral Node、分散式鎖的正確用法見 協調服務與分散式鎖；訊息骨幹從 訊息佇列基礎 進；API 契約的先備是 gRPC 與 Protocol Buffers。