Previous implementations of consensus are mainly based on Paxos algorithm. However, Paxos is not easy to understand. In addition, its architecture needs to make many changes on existing practical systems. Therefore, it is needed to propose a new algorithm which may achieve the same duty as Paxos, but can be more suitable to practical system, and easier to understand. That is the reason why the authors propose Raft algorithm.
The consensus algorithms are with in the area of replicated state machines(SM). In the SM, keep the log consistent among servers is the main job of consensus algorithm.
Just like Paxos, Raft also has 3 roles: follower, candidate and leader. And during the runtime, it mainly contains two phrase: leader election and log replication.
Leader election: the followers transit into candidate state. And they vote and issues RequestVote RPCs within the cluster. Then finally one candidate will win when it receives votes from a majority of the servers.
Log replication: The elected Leader will make sure that AppendEntries RPCs in parallel to each of other servers to replicate the entry. And then the leader ensures the committed entries are executed by all the available state machines eventually.
Even though the authors claims that, compared with Paxos, their approach is easier to understand, I would argue about that. I do not think Raft is easier. And the "experimental result" of user study in two university(in total 43 students) is also untenable.
Yes, I think it will be influential in next few years. It is because, compared with Paxos, Raft is more like a system work instead of only theoretical statement.
No comments:
Post a Comment