The old driver took you with the Go language implementation of Raft distributed consistency Protocol

This is a creation in Article, where the information may have evolved or changed.

With the large number of high-concurrency access, massive data processing and other scenarios more and more, how to achieve the high availability of web sites, scalability, scalability, security and other goals are becoming more and more important.

In order to solve such a series of problems, the architecture of large-scale web site is also evolving. To improve the high-availability architecture of a large web site, you have to mention distributed. No single distributed system can meet the consistency (consistency), availability (availability), Partition tolerance (partition fault tolerance) of the three basic requirements, up to two. However, a distributed system can not completely abandon consistency (consistency) regardless of the CAP, if the consistency is not true, then the data in this system is not credible, the data is meaningless, then the system will not have any value to say. Therefore, in any case, the consistency problem of distributed systems needs to be focused.

Raft applies to a protocol that manages log consistency, which is easier to understand and implement than the Paxos protocol Raft.

Get in

Raft by electing a leader and then giving him all the responsibility to manage the replication log to achieve consistency. Leaders receive log entries from clients, copy log entries to other servers, and tell other servers to apply log entries to their state machines when security is ensured. Having a leader greatly simplifies the management of replication logs. For example, a leader can decide where a new log entry needs to be placed in the log without consulting with other servers, and the data flows from the leader to the other server. A leader can be down and lose connections to other servers, and a new leader will be elected.

The Raft divides the time into a term of any length, with a continuous integer tag. Each term starts with an election, and one or more candidates try to become leaders. If a candidate wins the election, then he will act as a leader for the rest of his tenure. In some cases, an electoral process would result in the partition of ballot papers. In this case, the term will end with no leader, and a new term (and a new election) will soon start again. Raft guarantees that there is at most one leader in a given term.

To implement the Raft protocol, see:

The Raft protocol divides the entire process into 3 main steps:

1. Leader: Raft uses a stronger form of leadership than other consistency algorithms. For example, log entries are sent only from the leader to other servers. This approach simplifies the management of replication logs and makes the Raft algorithm easier to understand.

2. Leadership election: The Raft algorithm uses a random timer to elect the leader. This approach only adds a bit of mechanism to the heartbeat mechanism that any consistency algorithm must implement. It's easier and quicker to resolve conflicts.

3. Relationship tuning: Raft uses a common and consistent approach to dealing with the problem of cluster member transformations, in which the majority of machines required by two different configurations overlap. This allows the cluster to continue to work when the members are transformed.

These 3 main processes will be carried out later.

The departure (leading election)

Raft uses a heartbeat mechanism to trigger a leader election. When the server program starts, they are all followers. If a follower does not receive any messages for a period of time, that is, the election is timed out, then he will assume that there are no available leaders in the system and then start the election to elect a new leader. To begin an electoral process, the follower will first increase their current term number and switch to the candidate status. Then he would send a poll RPCs to the other server nodes in the cluster in parallel to vote for himself. The status of the candidate is maintained until any of the following conditions occur, (a) he won the election himself, (b) The other servers became leaders, and (c) there was not a single winning person for some time. When a candidate obtains a ballot for the same term number from most server nodes across the cluster, he wins the election and becomes a leader. Each server will have a maximum of one vote for a term number, in accordance with the principle of first-come first service.

Raft uses voting to prevent candidates from winning the election unless the candidate contains all the log entries that have been submitted. Candidates must contact most of the nodes in the cluster in order to win the election, which means that each log entry that has been submitted must have at least one of these server nodes. If the candidate's log is at least as new as the majority of the server nodes, then he must have all the log entries that have been submitted. Request to vote RPC implements the restriction that RPC contains the candidate's log information, and then the voter rejects those logs without a new polling request.

Raft by comparing the index value of the last log entry in the two logs with the term number to define who's log is newer. If the last entry in the two logs has a different term number, then the log with the term number is more new. If the last entry in the two logs has the same term number, the longer the log is the newer.

Arrival (log copy)

Once a leader is elected, he begins to serve the client. Each request from the client contains a command that is executed by the replicated state machine. The leader attaches this instruction as a new log entry to the log, and then initiates additional entries in parallel to RPCs the other servers, allowing them to copy the log entry. When this log entry is securely copied, the leader applies the log entry to its state machine and returns the result of the execution to the client. If the follower crashes or runs slowly, or if the network drops, the leader repeatedly tries to append the log entry RPCs (although the client has been restored) until all the followers have finally stored all the log entries.

Raft log mechanism to maintain a high level of consistency between logs of a different server. This not only simplifies the behavior of the system but also makes it more predictable, and he is also an important component of security assurances. Raft maintains the following features, which also comprise the log matching feature:

1. If two entries in a different log have the same index and term number, they store the same instruction.
2. If two entries in a different log have the same index and term number, then all of their previous log entries are the same.

The first feature comes from the fact that leaders at most one term create a log entry at a specified log index location, and the log entry's position in the log never changes. The second feature is guaranteed by a simple consistency check of additional log RPC. When sending additional log RPC, the leader will include the index and term number of the new log entry immediately preceding the entry. If the follower cannot find an entry in its log that contains the same index location and term number, then he will refuse to receive the new log entry.

The consistency check is like an inductive step: The first empty log state is sure to satisfy the log matching feature, and then the consistency check protects the log-matching feature when it is extended. Therefore, whenever an additional log RPC returns successfully, the leader knows that the follower's log must be the same as himself.

Get out

Originated from MIT, then used for self-study, source annotated address.