Understanding the Raft Consensus Algorithm: Principles, Workflow, and Comparison with Paxos

1. Raft Algorithm Background

For many engineers, the Paxos algorithm is difficult to understand and implement. Stanford researchers therefore proposed Raft, a consensus algorithm that is easier to grasp and deploy.

2. Basic Principles of Raft

Consensus ensures that a cluster of machines works together and keeps data consistent even when some nodes fail.

Raft decomposes the consensus problem into three sub‑problems:

Leader election : there must be exactly one leader; if the leader crashes, a new one is elected.

Log replication : the leader receives client updates, replicates the log to followers, and guarantees cluster‑wide consistency.

Safety : a set of rules handles special cases to keep the algorithm correct.

Leader Election Details

Each node can be in one of three states: follower, candidate, or leader.

(1) Follower : the default state. If a follower does not hear from a leader, it starts an election and becomes a candidate.

(2) Candidate : a node that has started an election. It requests votes from other nodes. If it receives a majority of votes, it becomes the leader. If it receives a request from a higher‑term leader, it steps down to follower.

(3) Leader : the node that has won the election. It handles all client requests, appends entries to its log, and replicates them to followers. If a higher‑term leader appears, the current leader steps down.

Terms (TermId) are monotonically increasing identifiers for election periods. The leader must have the most up‑to‑date log to be elected.

Log Replication Process

(1) The leader sends AppendEntries (log replication) requests to followers, including the previous log’s term and index.

(2) If a follower’s log matches the previous entry, it accepts the request; otherwise it rejects it.

(3) Upon rejection, the leader backs up to an earlier log entry and retries until a common entry is found.

(4) Once a majority of followers have replicated an entry, the leader commits it and applies it to the state machine.

Safety Rules in Raft

Election Safety : at most one leader per term (prevents split‑brain).

Leader Append‑Only : only the leader may append new log entries; followers cannot write directly.

Log Matching : if two entries have the same index and term, they store the same command, and all preceding entries are identical.

Leader Completeness : only a candidate whose log is at least as up‑to‑date as any other can become leader.

State Machine Safety : a log entry is considered committed only if it is from the current term and replicated on a majority of nodes.

3. Paxos vs. Raft

Paxos is the classic consensus algorithm but is hard to implement. Multi‑Paxos introduces a leader (proposer) but still allows concurrent log appends, which can create gaps. Raft improves on Multi‑Paxos by enforcing:

Sequential, gap‑free log appends.

Only nodes with the latest log are eligible to become leader.

These restrictions make Raft easier to understand and implement for most engineers.

4. Summary

Raft is a leader‑based consensus algorithm designed for understandability and practical deployment. Its performance, reliability, and availability are comparable to Paxos, while its rules are simpler and more intuitive for developers.

Studying Paxos and Raft provides valuable insights for designing, implementing, deploying, and testing distributed systems.

Author Bio

Zhang Hui, backend engineer at Tencent, works on the Tencent Cloud Computing Platform PCDN SDK. Graduated from Nanjing University, Computer Science department.