Shulou(Shulou.com)06/01 Report--

This article mainly introduces the relevant knowledge of the important knowledge points of raft protocol, the content is detailed and easy to understand, the operation is simple and fast, and it has a certain reference value. I believe you will gain something after reading this important knowledge point of raft protocol. Let's take a look at it.

Raft protocol is a relatively easy to understand implementation of conformance protocols, and there are similar consistency algorithms such as zab,paxos. Etcd is based on the raft protocol, and K8s depends on etcd.

The problem of the number of nodes in the 1Magne Raft algorithm

In the Raft protocol, after the heartbeat of the master node fails, follower becomes candidate and the two nodes vote as the master node. How to confirm what n is in the RAFT protocol cluster? How to dynamically increase the machine how to change n, and how long the timeout should be considered that the node is fixed as a dynamic adjustment?

The discussion of leader election, log replication and security is based on the constant membership of the Raft cluster. However, in many cases, the nodes of the cluster may need to be maintained, or because of the need for capacity expansion, it is inevitable to add and delete nodes to the Raft cluster. The easiest way is to stop the entire cluster, change the static configuration of the cluster, and then restart the cluster, but this loses the availability of the cluster, which is often undesirable, so Raft provides two ways to dynamically change cluster members without downtime:

Single node membership change: One Server ConfChange

Multi-node consensus: Joint Consensus

During the migration from Cold to Cnew, because each node actually receives the latest configuration differently, Ken can cause multiple Leader to exist at the same time in the same term.

In order to solve the above problems, some restrictions need to be made when the cluster membership changes.

Single node member change

The so-called single-node membership change means that only one node is added or removed from the cluster at a time. For example, in the past, there were three nodes in the cluster, but now you need to expand the cluster to five nodes, so you need to add one node at a time instead of two nodes at a time.

Why is this safe? It is easy to enumerate all cases, in the case of the original cluster odd and even nodes, add and delete one node respectively. As can be seen in the following figure, if only one node is added and deleted at a time, there must be an intersection between the Majority of Cold and the Majority of Cnew, that is, in the same Term, the node that intersects Cold and Cnew will only vote once, either for Cold or Cnew, thus avoiding the occurrence of two Leader under the same Term.

The process of the change is as follows:

Submit a member change request to Leader, which is whether the service node is added or removed, as well as the address information of the service node

After receiving the request, Leader appends a log of ConfChange, which contains Cnew, to the log. Subsequently, these logs will be synchronized to all Follower nodes with the RPC of AppendEntries.

When the log of ConfChange is added to the log, it takes effect immediately (note: it does not take effect until after the submission)

When ConfChange's log is copied to Cnew's Majority server, then the log can be submitted

The above is the entire single-node change process, after the log is submitted, then you can:

Respond to the client immediately, the change has been completed

If the server is removed during the change, the server can be shut down

You can start the next round of membership changes. Note that you are not allowed to start the next change until the last change is completed.

Usability

Availability issu

After we add or delete a node to the cluster, the service may be unavailable, such as adding a clean new node without any logs to a cluster with three nodes. After adding a node, a Follower in the original cluster goes down, so there are still three nodes available in the cluster to meet the Majority, but because the newly added node is clean, the node without any logs It takes time to catch up with the latest logs, so the entire service is not available while the new node is catching up with the logs.

2, client interaction

Including how the client discovers how leaders and Raft support linearized semantics

The client in Raft sends all requests to the leader. When the client starts, it will randomly pick a server to communicate. If the server selected by the client for the first time is not a leader, that server rejects the client's request and provides information about the leader he recently received (the additional entry request contains the leader's network address). If the leader has crashed, the client's request will time out; the client will then retry the random server selection process.

The goal of our Raft is to achieve linearized semantics (each operation is performed immediately, only once, between his call and the reply received). However, as mentioned above, Raft can execute the same command multiple times: for example, if the leader crashes after submitting the log but before responding to the client, the client will retry the instruction with the new leader, causing the command to be executed again. The solution is for the client to assign a unique serial number to each instruction. The state machine then tracks the latest sequence number of each instruction and the corresponding response. If an instruction is received and its sequence number has been executed, the result is returned immediately without re-executing the instruction.

3. Leader election

Nodes in Raft have three states:

Leader status: Leader

Follower status: Follower

Candidate status: Candidate

Each node is a state machine, and Raft will migrate and transform the state according to the current heartbeat, tenure and other states.

First of all, when the Raft node starts, all tasks are in Follower state, because there is no Leader, and all Follower cannot receive a heartbeat from Leader within a fixed timeout, so they become Candidate state and begin to elect Leader.

When a node is in Candidate state, a request for vote and request RequestVote will be issued to all nodes concurrently (described in more detail in later chapters). In Candidate state, nodes may migrate in three states:

Start the next round of new election: if the voting request issued does not receive a response from other nodes within a fixed period of time, or the number of nodes that have received the response (or agreed to vote) does not reach the number of NUniverse 2 nodes, then the selection timed out and went to the next round of election.

The election is successful and becomes the new Leader: if more than the number of nodes in the election process are received, then the election is successful and the current node becomes the new Leader

Become Follower: if the Leader heartbeats received from other nodes during the election process, or if the Term of the request for voting response is greater than the current node Term, then there is a new term of Leader

If the node is elected successfully and becomes Leader, the Leader will send heartbeats to all nodes within a fixed period, but if the response Term of the heartbeat request is greater than the Term of the current node, then the current node will become Follower. For example, the network of the Leader node is unstable. After being offline for a period of time, when the network is restored, there must be other nodes selected as the new Leader, but when the current node goes offline, it does not find that the other nodes choose Leader, and still sends the heartbeat to other nodes, and the other nodes will send the current new Term response to the outdated Leader, thus transforming it into Follower.

4. Log replication

Leaders must receive logs from the client and copy them to other nodes in the cluster, and force other nodes to keep their logs the same as they do.

Replication state machines are usually implemented based on replication logs, where each server stores a log containing a series of instructions and executes in the order of the logs.

The client requests the server, and the requested information is a series of indications, such as PUT KEY VALUE

After receiving the request, the server synchronizes the operation instructions to all servers.

After the server receives the synchronization instruction, it applies the instruction to the state machine.

Finally, the response client operation is successful.

5. Node timeout mechanism

Each node has a random timeout of 150~300ms. If a heartbeat packet of leader is received, it will be rescheduled, otherwise its status will be set to candidate and a vote will be initiated. Because the time is random, the possibility of voting at the same time is reduced. Follower knows that leader is alive through the node timeout mechanism, otherwise leader may be thought to be dead.

This is the end of the article on "what are the important knowledge points of raft protocol". Thank you for reading! I believe you all have a certain understanding of "what are the important knowledge points of the raft protocol". If you want to learn more, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.