Raft's Implementation
Let's have an overview of Raft's implementation.
We'll cover the following
A brief overview
What has been described so far consists of the main specification of the Raft protocol. The
contains more information on some other implementation details that will be covered briefly here. paper D. Ongaro and J. Ousterhout, “In Search of an Understandable Consensus Algorithm,” Proceedings of the 2014 USENIX Conference on USENIX Annual Technical Conference, 2014.
Cluster membership changes can be performed using the same mechanisms by storing the cluster members in the same way regular data is stored.
An important note is that transition from an old configuration to a new configuration must be done via a transition to an intermediate configuration that contains both the old and the new configuration. This is to prevent two different leaders from being elected for the same term. The following illustration illustrates how that could happen if the cluster transitioned from directly to .
During the intermediate transition, log entries are replicated to the servers of both configurations. Any node from both configurations can serve as a leader and consensus requires a majority from both the old and the new configuration. After the configuration has been committed, the cluster then switches to the new configuration .
Since the log can grow infinitely, there also needs to be a mechanism to avoid running out of storage.
Mechanism to avoid running out of storage problem
Nodes can perform log compaction by writing a snapshot of the system’s current state on stable storage and removing old entries.
When handling read requests from clients, a leader needs first to send heartbeats to ensure it’s still the current leader. That guarantees the linearizability of reads.
Alternatively, leaders can rely on the heartbeat mechanism to provide some form of lease, but this would assume bounded clock skew to be safe.
A leader might also fail after applying a committed entry to its state machine, but before replying to the client.
In these cases, clients are supposed to retry the request to the new leader. If these requests are tagged with unique serial numbers, the Raft nodes can identify commands that have already been executed and reply to the clients without re-executing the same request twice.
You have been provided with the workflow for the Raft consensus algorithm below. Your task is to rearrange them in their correct order.
Committed entries are applied to the state machine.
Nodes can be added or removed without disruption.
The leader sends periodic heartbeats.
Followers initiate new elections if no heartbeat is received.
The leader appends client requests to its log.
Followers reset election timeout on receiving a heartbeat.
First candidate with a majority of votes becomes the leader.
The leader updates its log if a follower’s log is more up to date.
Raft allows dynamic changes to the cluster membership.
Nodes start as followers.
Get hands-on with 1400+ tech skills courses.