Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

How to understand the distributed consistent Raft protocol

2025-01-19 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >

Share

Shulou(Shulou.com)05/31 Report--

This article mainly introduces how to understand the distributed consistency Raft protocol related knowledge, the content is detailed and easy to understand, the operation is simple and fast, and has certain reference value. I believe that everyone will gain something after reading this article on how to understand the distributed consistency Raft protocol. Let's take a look at it together.

What is Distributed Consistency?

Here's an example:

Suppose we have a single-node service node A that stores only one letter. We also have a client that makes a request to update data to this service.

For single-node distributed consistency, the service responds to update requests from clients. But what happens when we have multiple service nodes?

Raft protocol is a protocol that guarantees data consistency among multiple server nodes.

Let's see how Raft works.

In the Raft protocol, a server node can be in any of three states:

Follower status: follower, passively receiving data. We'll use a solid circle.

Candidate status: candidate, can be selected as Leader. We use a solid circle + dashed border to indicate.

Leader status: Leader, handles all client interactions, log replication, etc., generally only one Leader at a time. We use a solid circle + solid border.

Leader election

All nodes start in the Follower state.

If the Follower does not receive an election request or a reply from the Leader node within a certain period of time, the Follower will become a Candidate.

Candidate will send election requests to all other nodes, and other nodes that receive election requests will feed back to Candidate. When the number of responses received by Candidate is greater than n/2, Candidate will think that most nodes have chosen me as Leader, and Candidate will change to Leader at this time. All subsequent data changes are initiated via the Leader.

Log replication process

In Raft systems, all data changes are added to service nodes in the form of log entries. The service node continuously reads log records and updates log records to the service node's data. The initial state of the log entry is uncommitted, and after updating the state changes to committed.

To achieve consistent updates for all service nodes, the steps are as follows:

client sends data change request to Leader

Leader copies logs to Follower node

The Leader waits for most nodes to complete replication logging.

The Leader node commits the current log entry and updates the Leader node's data.

image.png

The Leader notifies the Follower node that the log record has been committed.

The Follower node commits the log record.

Data consistency is achieved throughout the distributed system.

term Election cycle

In the Raft protocol, there is a concept of term. A term is an election cycle, a term cycle will only produce one Leader, and the term will increase continuously.

timeout

In the Raft protocol, in order to ensure the smooth progress of elections and data updates, two types of timeout are specified:

Election timeout and heartbeat timeout.

Elections and election timeout

At the beginning of each term, the election timeout is reset. In a term, the Follower waits for timeout. If no election request from other nodes is received after timeout, the Follower will actively change to Candidate, and term+1 means that a new election cycle has started.

Election timeout is a random number between 150ms and 300 ms. The reason why timeout is randomly generated is to avoid the situation of generating multiple Candidates at the same time.

When the Follower changes to Candidate, the term is incremented by 1, and a new round of elections begins. Candidate will first add 1 to its Vote Count and then send a message requesting election to other nodes.

The receiving node first compares the size of the term, and if its term is smaller than the Candidate's term, updates its term to be consistent with the Candidate's term, and resets the timeout. If the receiving node has not made any election in this term, it will return an election response message to the Candidate node.

Candidate nodes become Leader nodes after they receive most of the nodes 'election responses.

After an election cycle is completed, the Leader sends the update log to the Follower node and enters the log update phase.

electoral split

It is worth noting that a Candidate can only become a Leader node if it receives election responses from more than n/2 nodes. If two Follower nodes become Candidate nodes at the same time, the election split problem arises.

Now suppose we have a total of 4 nodes, two of which simultaneously become Candidate nodes and send election requests to the remaining two nodes:

Node B and node C become Candidate nodes and send election requests to nodes A and D in parallel.

Nodes A and D respond to the requests of nodes B and C respectively. At this time, since the votes obtained by the two Candidate nodes are both 2 and do not satisfy the condition greater than n/2, they cannot be transformed into Leader nodes. They continue to wait for timeout until the new term starts and a new round of elections is started until the conditions are met.

Log replication and heartbeat timeout

When the system enters the log replication phase, the Leader node sends log records to the Follower nodes at a heartbeat timeout rhythm, and needs to ensure that all nodes can receive complete log records.

The client sends set 5 to the Leader, and at the next heartbeat timeout, the Leader sends the log record of set 5 to the Follower.

After the Leader receives most of the nodes 'ack responses, it commits the log record.

The Leader notifies the Client that the log record has been submitted and notifies the Follower that the log record has been submitted.

That's all for the article "How to understand the distributed consistency Raft protocol." Thank you for reading! I believe everyone has a certain understanding of "how to understand distributed consistency Raft protocol" knowledge. If you want to learn more knowledge, please pay attention to 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.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Servers

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report