In Search of an Understandable Consensus Algorithm
Diego Ongaro, John Ousterhout2014USENIX ATC 2014
Read it on raft.github.io(opens in a new tab)Why this one
The unusual thing about this paper is that understandability was the design goal, stated up front, and the authors ran a user study to check they had hit it. That makes it the one consensus paper you can actually finish. Raft splits the problem into three pieces you can hold separately - leader election, log replication, and safety - and then insists that all writes flow through a leader so that the log is only ever appended to in one place. Read it when you reach distributed coordination, and read the figure with the state transitions rather than skimming to the end; the terms, the election timeout and the commit index are the whole algorithm, and every production system you will meet later (etcd, Consul, TiKV) is a direct implementation of that figure.
What to take away
- One leader at a time is not a simplification, it is the mechanism.
- Randomised election timeouts are what stop split votes - a one-line idea doing a lot of work.
- A committed entry is one a majority has written. Nothing weaker is safe.
Reads with
- Paxos Made Simple
raft is the understandable rewrite of the same replicated state machine idea
- Impossibility of Distributed Consensus with One Faulty Process
explains why raft needs timeouts and cannot guarantee progress during partitions
- ZooKeeper: Wait-free Coordination for Internet-scale Systems
shows consensus turned into a practical coordination service engineers actually call