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

Today, I will talk to you about how to analyze SOFAJRaft in the practice of Raft protocol. Many people may not know much about it. In order to make you understand better, the editor has summarized the following contents for you. I hope you can get something from this article.

-Overview of SOFAJRaft-

Deepen the understanding of the Raft protocol through the analysis of the core process of the SOFAJRaft framework. SOFAJRaft is a pure Java Raft algorithm implementation library, based on Baidu braft implementation, using Java to rewrite all functions, support:

Leadership elections and priority-based semi-deterministic leadership elections.

Log replication and recovery.

Snapshot and log compression.

Read only member (learner).

Cluster member management, add nodes, delete nodes, replace nodes, etc.

Full concurrent replication.

Fault tolerance.

Asymmetric network partition tolerance.

The solution when a quorum is dead.

Pipe replication

Linear consistent reading, ReadIndex/LeaseRead.

Some additional features have been extended:

Symmetrical network partition tolerance

Implementation of transfer leader and load balancing scenario after restart

Richer statistical display of indicators

Pass the Jepsen conformance verification test

Include embedded distributed KV storage implementation

The overall project is as follows:

-leadership election-

The election of SOFAJRaft is mainly through the judgment of two attributes: LogIndex and Term;Term, that is, the term of office. The tasks submitted to raft group by LogIndex are serialized and stored as a log, with a number for each log, which is monotonously incremented and copied to each raft node throughout the raft group. Can be understood as a transaction id. The logic of voting processing is mainly in com.alipay.sofa.jraft.core.NodeImpl, with four main functions:

Process the pre-voting request

Message handlePreVoteRequest (request)

Advance voting

Void preVote ()

Process the voting request

Message handleRequestVoteRequest (request)

vote

ElectSelf ()

The overall process is as follows:

Candidate (candidate) triggered by Election timeout

Candidate started trying to launch pre-vote pre-voting.

Follower (follower) determines whether or not to approve the pre-vote request

Candidate decides whether to launch RequestVoteRequest or not according to pre-vote response.

Follower judges whether to approve the RequestVoteRequest or not

Candidate judges whether he is elected or not according to response.

The use of pre-voting can prevent instant missing nodes caused by special reasons such as network jitter from causing trouble for no reason: candidates initiate pre-voting before initiating voting. If they do not get feedback from more than half of the nodes, the candidates will wisely give up running and will not raise the overall Term.

Voting source code:

Advance voting source code:

-Storage mechanism-

The SOFAJRaft enclosure is divided into:

Log storage records Raft configuration changes and user-submitted task logs, copying logs from Leader to other nodes

CheckAndResolveConflict (entries, done)

OfferEvent (done, type)

Disruptor queue publishes other type events

AppendToStorage (toAppend)

Callback event handler StableClosureEventHandler stores logs

Returns the first / last log index in the log

Obtain Log Entry and its term of office according to log index

Add single / batch Log Entry to log store

Delete the log from the Log storage header / end

Delete all existing logs and reset the next log index.

LogStorage is a log storage implementation. The default implementation is based on RocksDB storage, which is implemented by extending custom log storage through LogStorage APIs. The core APIs include:

LogManager is responsible for invoking the underlying log storage LogStorage, caching, batch submission, necessary checks and optimizations for log storage calls.

Check the Node node to resolve log conflicts.

Configuration Manager: caching configuration Chan

LogsInMemory cache log Entries

Meta storage, that is, meta-information storage records the internal state of the Raft implementation, such as the current term, which node to vote for, and so on.

Set / get the current term Term of Raft metadata

Vote on the PeerId node that assigns / queries Raft meta-information.

RaftMetaStorage meta-information storage implementation. The core API interface of the Metadata enclosure that defines Raft metadata includes:

Snapshot stores the user's state machine Snapshot and meta-information, which is used for Node to restart and reconstruct the entire state machine instance.

State Machine Snapshot doSnapshot (done)

Install Snapshot installSnapshot (request, response, done).

Set filterBeforeCopyRemote, which means to filter data before copying to the remote for true

Create a snapshot writer

Open snapshot reader

Copy data from a remote Uri

Start a replication task to replicate data from a remote Uri

Configure SnapshotThrottle,SnapshotThrottle to limit traffic in redisk read / write scenarios, such as disk read and write, network bandwidth.

SnapshotStorage is used for snapshot storage implementation. The Snapshot enclosure core interfaces that define Raft state machines include:

SnapshotExecutor is used for the management of snapshot actual storage, remote installation and replication.

LogManager calls log storage LogStorage to implement the logic:

SnapshotExecutor state machine snapshots and remote installation images implement logic:

-consistent state machine-

Through the design of storage, the consistent state machine can be completed by introducing the state machine mechanism. The SOFAJRaft state machine consists of:

StateMachine: the main interface of the business logic implementation. The state machine runs on each raft node. If the submitted task is successful, it will eventually be copied and applied to the state machine of each node. The core is the onApply (Iterator) method, which applies logs submitted through Node#apply (task) to the business state machine.

FSMCaller: encapsulates the call to the state transition of the business StateMachine and the writing of the log, the implementation of a finite state machine, doing the necessary checks, request merge submission and concurrent processing, etc.

SOFAJRaft Node nodes use log replication to complete data synchronization, which is mainly composed of:

Replicator: used for leader to copy logs to follower, that is, appendEntries calls in raft, including heartbeat survival check, etc.

ReplicatorGroup: used for a single RAFT Group to manage all replicator, necessary permission checks and dispatches.

The following is a brief introduction to the election implementation, storage mechanism, state machine and log replication of SOFAJRaft. Basically completed the core implementation of the Raft implementation. But SOFAJRaft has more cores and optimizations, which are not analyzed in detail because of its length. If we self-implement the Raft protocol, basically we can also implement these main processes to complete the simplified version of Raft. Tell us about the Raft protocol for the time being, and then we are going to write the ZAB protocol.

After reading the above, do you have any further understanding of how to analyze SOFAJRaft in the practice of Raft protocol? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

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.