takeaway
In the previous article “evolution of microservices architecture based on SpringCloud?” Consul is a distributed consistency algorithm Raft is used in the Consul distributed registry. In this article, we introduce the Raft algorithm.
We know that an important goal of microservices architecture is to achieve distributed performance and improve the reliability of the overall system. The key to provide system reliability is to establish multiple replica nodes to ensure that the system is still available when one or more service nodes fail. However, how to ensure the data consistency between multiple copies becomes a new problem, and the distributed consistency algorithm is to solve the data consistency between multiple copies in distributed environment.
In springCloud-based microservice system, Consul plays a key role as the registry of the whole service, so Consul provides services in the production environment in the form of clusters. Data synchronization between nodes in the whole Consul cluster requires consistency algorithm like Raft.
Here’s a graphic look at how Raft works!
The role of the Raft
In Raft algorithm, nodes have three states: Follower, Candidate and Leader.
Raft node Leader Election
In the initial state, all nodes in the cluster are in the Follower state.
At this time, if a Follower Node, such as Node A, cannot detect the heartbeat sent from the Leader Node, it will change its state to Candidate.
There is an election timeout between 150ms and 300ms randomly assigned. After the election timeout, the Follower node will become the Candidate node and start a new election Term.
The Candidate node votes For a Vote and then votes For me to the other node to elect itself as the Leader.
If the other nodes receiving the Candidate Vote request have not voted for this election Term (Term=1), they will Vote back to the Candidate who sent the request and reset the election timeout setting for this node.
If the Candidate node receives a majority of the votes, it becomes the new Leader node for the current term.
At this point, the Leader node and each Follower node will send heartbeats to sense each other’s status until a Follower node fails to sense the heartbeat of the Leader node and becomes the Candidate state to initiate a new election.
Raft Log Replication
After a new Leader node is elected, all changes in the cluster system will pass through the Leader node and be synchronized to all other nodes by the Leader node. This is done by using the same type of message as the heartbeat, called “Append Entries.”
Let’s take a closer look at what the process looks like:
First, the client sends a data change request “SET 5” to the Leader node, which, upon receiving the change, adds it to the node’s log entry.
This change is then synchronized to all the Follower nodes when the next heartbeat is sent. Once the change is accepted by the majority of followers, the Leader node formally commits the entry and responds to the Client.
After that, the Leader node synchronizes the Commit request to all the followers nodes. The followers nodes complete the Commit request, and the cluster reaches a consensus on the current system status.
If you do an “ADD 2” operation again, the process is the same, and all the nodes in the cluster will reach a consensus of 7.
The election conflict
In the previous example of node election, if a Follower does not receive the heartbeat from the Leader within the election timeout period, he/she changes to the role of Candidate to initiate the election, and most other Follower nodes elect him/her as the Leader node. This is an ideal situation.
In fact, once the Leader node fails in the cluster, multiple Follower nodes may become candidates after the election timeout time and initiate a new election request at the same time. As shown in figure:
Both nodes are elected for the same term…
In addition, each Candidate gets votes from a Follower node before the other, but neither Candidate will get more votes in this term, so no new Leader node can be selected in this term.
At this point, all nodes will enter a waiting state and try again to start the next election. As shown in figure:
After the next election, Node D finally becomes the new Leader. In practice, it is recommended to deploy an odd number of nodes in a cluster. For example, in the Consul cluster, we deployed five nodes to prevent an even number of nodes from causing an election conflict.
Cluster split
Let’s consider another extreme case. Suppose that the cluster is divided into two parts due to some reasons (such as network interruption), the one with Leader node continues to run, and the one without Leader node enters the election state and elects its new Leader node, as shown in the figure:
At this point, nodes C, D, and E form a cluster and elect a new Leader node E, whose election term is updated to 2, higher than node B. Meanwhile, the two clients send SET requests to the two clusters respectively. Since node B cannot be copied to most nodes, it remains in the Uncommit state, while node C can be committed because it can be copied to most nodes.
When the cluster splitting problem is recovered, the original Leader node B will step down voluntarily when it sees A higher election term, and nodes A and B will roll back their uncommitted entries and match the logs of the new Leader node C. In this way, log consistency is achieved across the entire cluster (in fact, the cluster with a few nodes learns from the leader of the cluster with many nodes to complete the consistency process).
Afterword.
Raft and Paxos are two well-known consensus algorithms to solve consistency problems in distributed systems. Both of them can solve consistency problems in distributed systems, but the implementation of Paxos has proved to be very difficult to understand. Raft’s implementation is concise and intuitive. It was created to solve problems that were difficult to understand and implement in Paxos.
In the future, WE can discuss the knowledge related to Paxos algorithm with you. Thank you for your support!
Reference: http://www.cnblogs.com/hzmark/p/raft.htmlhttp://thesecretlivesofdata.com/raft/https://raft.github.io/
— — the END — — –
Long press the qr code to identify the picture, follow the “invincible code farmers” for more exciting content