The primary goal of the raft is to find a more understandable consensus algorithm than traditional Paxos,which is in a domination but unfortunately hard to realize in praticle.
Serveral novel features:
- Strong leader:e.g:log entries only flow from the leader to other servers.
- Leader election:Raft uses randomized timers to elect leaders.
Replicated state machines
Replicateds state machines are used to solve a variety of fault tolerance problems in distributed systems.They’re typically implemented using a replicated log.
The consensus algorithm’s job is to keep replicated log consistent.Once cmmands are properly replicated,each server’s state machine processes them in log order.The algorithm for a praticle system typically follow these features:
- Safety(under non-Byzantine conditions)
- Do not depend on timing to ensure the consistency of the logs.
- A command can complete as soon as a majority of the cluster has responded to a single round of RPC.
The shortcoming of Paxos
Two significant drawbacks:
- Hard to understand.
- Doesn’t provide a good foundation for building praticle implementations.
The Raft consensus algorithm
Raft is an algorithm for managing a replicated log in replicated state machines.
Given the leader approach,Raft decomposes the consensus problem into three relatively independent subproblems:
- Leader election
- Log replication:The leader must accept log entries from clients and replicate them across the cluster.
- Safety:If any server has applied a particular log entry to its state machine,then no other server may apply a different command for the same log index.
At any given time each server is in one of three states:leader,follower,or
Raft ensures that there is at most one leader in a given term
Raft servers communicate using RPC,and the basic algorithm requires two types:
- RequestVote RPC
- AppendEntries RPC