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

How to understand the protocol process, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain for you in detail, people with this need can come to learn, I hope you can gain something.

-citations-

We introduced the Raft protocol, the core idea of the consistency protocol tolerated by Raft protocol partition as a whole: the guarantee of consistency does not necessarily require all nodes to be consistent, as long as most nodes are updated, the data is also consistent for the whole distributed system. The Raft protocol decomposes the concept into: Leader election, Log replication, Safety. Raft divides the consistency protocol into several almost completely decoupled modules, such as Leader election, MemberShip change, log replication, Snapshot and so on.

The Raft design principle is to simplify the state space by reducing the number of states:

Logs do not allow holes, and Raft limits the possibility of log inconsistencies using randomized clocks to simplify the algorithm of leadership elections

-leadership election-

In order to ensure the robustness of Leader, Raft protocol uses the following techniques to ensure the simplified implementation of elections:

Timeout driver: Heartbeat/Election timeout

Random timeout: reduces the probability of votes being carved up as a result of election collisions

In order to ensure the validity of voting in the election, the Raft agreement stipulates a series of voting principles:

In any term, a single node can only vote at most one vote

Candidates cannot have less information than their own: the voting node determines whether to vote "yes" by comparing Term (term of office) with CommitId. First-come-first-served on a first-come-first-served basis: receive multiple RequestVote RPC canvassing and vote for the first to arrive

The overall election process of Raft is as follows:

When Candidate initiates the vote, it increments its current term by 1 (NewTerm) and initiates a vote request to all nodes in the cluster (RequestVote RPC: the request contains the new term value)

Follower nodes vote according to voting principles

After getting the "consent" of more than half of the nodes, Candidate becomes Leader, establishes the heartbeat with other nodes, and updates the current term of NewTerm; of all nodes. If the current term of office of all nodes is less than half, the election is lost, and the random election timeout strategy is enabled for all Condidate random sleep (that is, timeout) for a period of time, and then a new round of election is started. The first awakened Condidate will send all the Condidate applications to vote for me. If the Condidate has not yet awakened, it can only vote for the awakened Condidate.

-Log replication-

The log format defined by the Raft protocol is as follows:

(TermId, LogIndex, LogValue) where (TermId, LogIndex) can determine the only log

The Raft protocol replication policy prescribes a series of principles:

Continuity: hollow validity of logs is not allowed: a log is copied to most nodes, namely committed, to ensure that the leader will not be rolled back and must contain the latest committed log, so leader will only append logs and will not delete overwritten logs leader can only submit logs of the current term; cannot submit previous logs when leader is inconsistent with follower, leader forces follower to copy its own log

Followers log validity check:

AppendEntries RPC will also carry the recursive derivation of the unique ID (prevTermId, prevLogIndex) of the previous log.

Followers log recovery:

Leader decrements nextIndex and resends AppendEntries until it is consistent with the leader log

The complete process of log replication for Raft protocol is as follows:

Leader writes client's request command to the log as a new log entry. Leader sends AppendEntries RPC to follower to back up the log entry. Follower receives the AppendEntries RPC from leader, records the log entry to the log and gives back to ack. Leader receives more than half of the ack of follower, that is, it is considered that the message was sent successfully leader submitted the log entry to the state machine (state machine) processing leader returned the execution result to clientleader to send AppendEntries RPC notification to follower submission state machine follower received AppendEntries RPC,follower to determine whether the log entry has been executed, if not, execute commitIndex and previous log entries.

-Security-

Through a series of specification definitions, Radt protocol ensures the sequential consistency of the data of the whole Raft mechanism. The overall principles are as follows:

Election restrictions use voting rules to organize incomplete servers to win elections RequestVote RPC restrictions rules: reject logs do not have their own new candidate leader node can only append logs, cannot rewrite or delete log entries can only flow from leader to follower how to submit log entries in the previous term to maintain their own term number security argument leader integrity principle (Leader Completeness) a directive stored successfully in a term It is guaranteed to exist in the records after the leader's term of office. If the logs are the same in different nodes and in a location, then all logs before that location must be the same. State machine security principle (State Machine Safety) if a node applies logs from one location to the state machine, other nodes cannot apply different logs in the same location

Through the above specification definition, we can highlight the security of Raft protocol through some exception scenarios:

Followers crash:

When a follower crashes, all forwarding instructions and canvassing messages to it will fail because there is no response, and the sender will continue to retransmit. When the follower guides to rejoin the cluster, the followers will receive these messages, and the followers will respond again, and if the forwarded instruction has been written, it will not be repeated.

The leader crashed

When the leader crashes or goes offline, each stored instruction must have been written to more than half of the servers, and the election process will allow the server with the most complete record to win. One of the factors is that Raft candidates will disclose their latest records when canvassing, and will not vote for candidates if the server's own records are relatively new.

Timeout period and availability

Because the election guided by Raft is based on timeout, the choice of timeout period is crucial. If you comply with the time limit of the algorithm: broadcast time

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.