Introduction to Raft
Get introduced to an easy to understand consensus algorithm—Raft.
Introducing Raft
Raft is a consensus algorithm that champions itself on its easier understandability. Paxos, another consensus algorithm, had the reputation of being intricate, and the original Paxos paper omits many implementation-specific details for the engineers. As a result, there are many variants of Paxos, and many of them have never been mathematically proven.
Raft’s algorithm maintains replicated state machines across different nodes. A sequential log is maintained on each node; such a log has monotonically increasing slots, and each slot can hold one application-specific command. The purpose of the Raft algorithm is to ensure consistency of the log across all nodes.
Raft's algorithm uses a simple majority vote to achieve consensus with high availability. The nodes that miss some updates catch up later as they rejoin the Raft cluster. The nodes that miss updates apply the commands from the log to the state machine from left to right (from lower slot numbers to higher slot numbers).
Like Paxos, Raft is always safe, but it is not live under specific circumstances. Unlike Paxos, leader election is a mandatory part of the Raft algorithm, and the leader services all client requests. Such a leader is one of the reasons for Raft's simplicity. However, it might be a scalability issue if the number of concurrent clients is very high.
Note: As per the FLP impossibility, it is not possible to always achieve consensus in an asynchronous network even when a single node can crash-fail. Raft takes two major steps to avoid FLP impossibility:
Raft tweaks the meaning of consensus and termination by using a majority rather than requiring immediate agreement from all nodes. However, Raft makes sure that if a majority has agreed on something, the minority can not change those decisions.
Raft detects those cases when consensus is not possible. Under ...