Crash fault-tolerant consensus method and system based on relay thought and lease mechanism

Abstract

The invention provides a relay thought and lease mechanism-based crash fault-tolerant consensus method and system, and provides a relay thought and lease mechanism-based crash fault-tolerant consensus algorithm Puft, and the message load of a leader node in the consensus process is shared from the two aspects of request processing and log synchronization. And the security and activity of the algorithm are ensured while the performance bottleneck problem is relieved. The crash fault-tolerant consensus method and system based on the relay thought and the lease mechanism are adopted to solve the problem of leader performance bottleneck caused by receiving and processing massive client read-write requests and synchronizing log entries among cluster nodes.

Description

Technical Field

[0001] The present invention relates to the field of distributed systems and consensus algorithms, and in particular to a crash-tolerant consensus method and system based on relay ideas and lease mechanisms. Background Art

[0002] The distributed system is designed based on a scalable architecture. Both machines and nodes are distributed in different physical locations. The horizontally increased machine resources can not only improve storage capacity but also provide independent services to the outside world, greatly improving the efficiency of read and write operations. Nodes in different physical locations coordinate message transmission and storage through a consensus algorithm to ensure data consistency between nodes.

[0003] The crash-tolerant consensus algorithm (Praft, Replicated Atomic Fault-Tolerant) is mainly used to solve the abnormal situations such as delayed arrival, loss, disorder, etc. of synchronization messages sent between nodes in an unreliable network environment. After the cluster is started, the algorithm will select a unique leader through the leader election mechanism to receive and process client requests. The selected leader node will synchronize the client request to other follower nodes in the form of log entries, and submit the log entry and execute the client read and write request after receiving the successful synchronization response from more than half of the nodes. This type of consensus algorithm that relies on a stable leader to coordinate synchronization is called a strong leader consensus algorithm. Common strong leader consensus algorithms include Paxos and Raft.

[0004] Although the strong leader consensus algorithm can meet the system's requirements for security and activity, the leader node will gradually become the bottleneck of cluster throughput as the cluster size grows due to the high communication load borne by the leader node during the consensus process. For the leader performance bottleneck problem existing in the strong leader consensus algorithm, the existing solutions are mainly to not elect a leader node or to say that each node can be a leader node, and on this basis, to solve the conflicts and disorder problems that may arise due to the lack of unified scheduling through additional coordination mechanisms. For example, Mencius uses a specific strategy to make cluster nodes take turns to become leader nodes to alleviate the performance bottleneck problem caused by fixed leader nodes, but any node failure may cause cluster services to be unavailable and have poor stability; Epaxos stipulates that any node in the cluster can be used as a leader node to process and synchronize requests, and an additional mechanism is used to sort and process requests when they conflict. Although multiple leader nodes processing requests in parallel can improve system throughput and share communication loads, in scenarios with more conflicting requests, additional conflict handling mechanisms will seriously affect system performance. It can be found that the existing solutions introduce complex fault and conflict handling mechanisms while solving the leader performance bottleneck problem, which violates the design concept of the Raft algorithm that is easy to understand and implement. Summary of the invention

[0005] The purpose of the present invention is to provide a crash-tolerant consensus method and system based on the relay idea and lease mechanism, which is committed to solving the leader performance bottleneck problem caused by receiving and processing massive client read and write requests and synchronizing log entries between cluster nodes. A crash-tolerant consensus algorithm Praft based on the relay idea and lease mechanism is proposed, which apportions the message load of the leader node in the consensus process from the two aspects of request processing and log synchronization, thereby alleviating the performance bottleneck problem while ensuring the security and activity of the algorithm.

[0006] To achieve the above objectives, the present invention provides a crash-tolerant consensus method based on relay ideas and lease mechanisms, comprising the following steps:

[0007] In the log pre-synchronization phase, the leader node accepts client requests, encapsulates them into log entries, and adds them to the local log. It divides the local log into groups, then selects a node from the pre-divided groups as a relay node and sends a log synchronization request to the relay node. The relay node processes the log synchronization request from the leader as a follower until the local log reaches a consensus with the leader, and then enters the log synchronization phase.

[0008] Log synchronization phase: The relay node selected in the pre-synchronization phase acts as the proxy leader node of the group and sends log synchronization requests to all follower nodes in the group, waiting for synchronization responses from the follower nodes. Finally, it aggregates them into a complete response message and returns it to the leader node, entering the confirmation submission phase;

[0009] Confirmation and submission phase: After receiving the aggregation message of its group returned by the relay node, the leader node summarizes the current synchronization progress of the cluster. If the log entry has been synchronized to more than half of the nodes, the corresponding log entry will be marked as submitted in the local state machine, and a confirmation submission message with the current submitted log number will be sent to the relay node, and the client request will be responded to at the same time; the relay node will then forward it to other follower nodes in the group, and the state machines of each node in the group will execute the client instructions in the submitted log entry.

[0010] Preferably, the leader node receives client read and write requests and allows follower nodes to receive and process client read-only requests. After receiving the client read-only request, the follower node requests the leader node for the maximum number of its currently submitted log entries. After the corresponding log entry is committed and applied to the local state machine, the follower node executes the client read operation and returns a query result that satisfies linear consistency.

[0011] Preferably, the log conflict handling mechanism of the crash-tolerant consensus algorithm Raft is optimized, including adding an additional field in the synchronization rejection response message to inform the leader node from which log entry the next synchronization request should be sent, thereby bypassing all conflicting log entries.

[0012] Preferably, in the log synchronization phase and the confirmation submission phase, each group's relay node will return a response message to the leader node that summarizes the synchronization status of other nodes in the group after successful synchronization. The Praft algorithm follows the majority theory, and the leader considers the synchronization successful when it receives successful responses from more than half of the nodes.

[0013] Preferably, the leader node receives successful responses from more than half of all relay nodes to submit log entries. A collection threshold is set for special cases. After the set threshold is met, the corresponding log entry is marked as submitted in the local state machine. The collection threshold t i Should satisfy the following

[0014]

[0015] In the formula, t i The response collection threshold for the ith group, s i is the number of responses ignored when collecting responses in the ith group, n i is the number of follower nodes in the i-th group, s i , t i , n i The relationship between the three is t i =n i -s i , p represents the number of groups divided by clustering.

[0016] Preferably, the crash-tolerant consensus algorithm Praft manages the leader node identity through a lease mechanism, and uses the isQuorum field to identify whether the leader node is valid in the current term. The leader node does not need to verify its identity by broadcasting a heartbeat during its validity period, and directly responds to the client's read-only request.

[0017] A crash-tolerant consensus system based on relay ideas and lease mechanisms, including

[0018] The leader node is used to process client requests and encapsulate the requests as log entries; append log entries to the local log; divide log entries into groups and select relay nodes; send log synchronization requests to relay nodes; receive responses from relay nodes and count the log synchronization progress of the cluster; mark submitted log entries as submitted and send a confirmation submission message;

[0019] The relay node acts as the proxy leader of the group and is used to receive log synchronization requests from the leader; broadcast log entries to all follower nodes in the group; wait for and aggregate synchronization responses from followers; send aggregated response messages to the leader node; receive and forward confirmation submission messages from the leader to other nodes in the group;

[0020] Follower nodes are used to receive log entries from relay nodes; log entries are appended to local logs; relay nodes send synchronization confirmation messages; receive and execute client instructions in confirmation submission messages from relay nodes;

[0021] The client is used to send requests to the leader node; wait and receive responses from the leader node.

[0022] Preferably, client and leader node: the client sends a request to the leader node and waits for a response;

[0023] Leader node and relay nodes: The leader node sends log entries to relay nodes and receives responses from relay nodes;

[0024] Relay nodes and follower nodes: Relay nodes broadcast log entries to follower nodes and collect their responses;

[0025] Relay node and leader node: The relay node sends the aggregated response to the leader node and receives a confirmation submission message from the leader;

[0026] Relay node and follower node: The relay node forwards the confirmation submission message to the follower node;

[0027] Follower nodes and local state machines: Follower nodes execute submitted client instructions in local state machines.

[0028] A terminal device comprises a memory, a processor and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the processor implements the steps of a crash-tolerant consensus method based on a relay concept and a lease mechanism.

[0029] Therefore, the present invention adopts the above-mentioned crash-tolerant consensus method and system based on relay idea and lease mechanism, and the technical effects are as follows:

[0030] In the request processing phase, follower nodes are allowed to process client read-only requests. After receiving a read-only request, they skip the log synchronization phase and directly request the maximum number of currently submitted log entries from the leader node. Based on the maximum number, they provide data reading services that meet linear consistency. At the same time, the legitimacy of the leader node identity is ensured through a lease mechanism, which improves the read request throughput while preventing the leader node from becoming a cluster performance bottleneck due to processing massive client requests.

[0031] In the log replication phase, relay nodes are introduced as new node states to achieve hierarchical log synchronization. Cluster nodes are divided into multiple consensus groups. Before each round of consensus starts, relay nodes are selected from the group as proxy leaders to share the communication load of the leader node during the consensus process, thereby avoiding single-point performance bottlenecks and improving the consensus throughput and concurrency of the cluster. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 It is the message flow chart of Praft algorithm;

[0033] Figure 2 It is the heartbeat lease mechanism of the Praft algorithm;

[0034] Figure 3 This is a throughput comparison experiment under different cluster sizes;

[0035] Figure 4 Conduct a comparative experiment on request load and latency under different cluster sizes; Figure 4 (a) is a comparison experiment of request load and latency when the number of nodes in the cluster is n=5; Figure 4 (b) is a comparison experiment of request load and latency when the number of nodes in the cluster is n=15; Figure 4 (c) is a comparison experiment of request load and latency when the number of nodes in the cluster is n=25;

[0036] Figure 5 This is a performance comparison experiment for different read-write ratios under different cluster sizes. DETAILED DESCRIPTION

[0037] The technical solution of the present invention is further described below through the accompanying drawings and embodiments.

[0038] Unless otherwise defined, technical or scientific terms used in the present invention shall have the common meanings understood by one having ordinary skills in the field to which the present invention belongs.

[0039] Embodiment 1

[0040] like Figure 1As shown, the present invention provides a crash-tolerant consensus method and system based on relay ideas and lease mechanisms, which are mainly divided into three stages: log pre-synchronization, log synchronization, and confirmation submission. The message flow of each stage is described in detail as follows:

[0041] Log pre-synchronization phase: The leader node receives client read and write requests, and allows follower nodes to receive and process client read-only requests. After receiving the client read-only request, the follower node will request the leader node for the maximum number of its currently submitted log entries. After the corresponding log entry is submitted and applied to the local state machine, the client read operation is executed and the query result that satisfies linear consistency is returned. For client write requests, the leader node encapsulates them as log entries and adds them to the local log. Then, it selects a node from the pre-divided group as a relay node. Figure 1 The red and blue parts represent two independent, non-overlapping consensus groups. The first node of each group is selected as the relay node for the current consensus round, and a log synchronization request is sent to the relay node. In the pre-synchronization phase, the relay node processes the log synchronization request from the leader as a follower until the local log reaches a consensus with the leader, and then enters the log synchronization phase.

[0042] Log synchronization phase: The relay node selected in the pre-synchronization phase will act as the proxy leader node of the group to send log synchronization requests to all follower nodes in the group, wait for synchronization responses from the follower nodes, and finally aggregate them into a complete response message and return it to the leader node, entering the confirmation submission phase.

[0043] Confirmation and submission phase: After receiving the response message of its group from the relay node, the leader node will summarize the current log synchronization progress of the cluster. If the log entry has been synchronized to more than half of the nodes, the corresponding log entry will be marked as submitted in the local state machine, and the confirmation submission message with the current submitted log number will be sent to the relay node, and the client request will be responded to at the same time. The relay node will then forward it to other follower nodes in the group, and the state machines of each node in the group will execute the client instructions in the submitted log entry.

[0044] Since the efficiency of log synchronization between the leader node and the relay node is related to the performance of the consensus algorithm, if there is a large log difference between the leader node and the selected relay node, the additional communication will cause the relay node to be unable to synchronize new log entries to its group in time, thereby affecting the overall consensus progress of the cluster. Therefore, this patent also optimizes the log conflict handling mechanism of the Raft algorithm by adding an additional field to the synchronization rejection response message to inform the leader node from which log entry the next synchronization request should be sent, thereby bypassing all conflicting log entries.

[0045] To improve consensus efficiency, the relay node does not need to wait for all followers to return a synchronous successful response in each group. It only needs to sort out the partial responses currently collected and return them to the leader after reaching a certain threshold. Under normal circumstances, the leader node receives successful responses from more than half of all relay nodes to submit log entries. For special cases, a collection threshold is set. After the set threshold is met, the corresponding log entry is marked as submitted in the local state machine. The collection threshold t i Should satisfy the following

[0046]

[0047] In the formula, t i The response collection threshold for the ith group, s i is the number of responses ignored when collecting responses in the ith group, n i is the number of follower nodes in the i-th group, s i , t i , n i The relationship between the three is t i =n i -s i , p represents the number of groups divided by clustering.

[0048] In the log synchronization phase and confirmation submission phase, after successful synchronization, the relay node of each group will return a response message to the leader node that aggregates the synchronization status of other nodes in the group. Similar to the Raft algorithm, the Praft algorithm follows the majority theory. The leader is considered to have successfully synchronized when it receives successful responses from more than half of the nodes. Therefore, the relay node does not need to wait for all followers to return a successful synchronization response in each group. After reaching a certain threshold, it can return the currently collected partial responses. Ideally, the leader node only needs to receive more than half of the successful synchronization responses to submit the log entry. Correspondingly, the relay node of each group only needs to collect the synchronization responses of some followers to return the response message to the leader node, thereby avoiding some slow or faulty nodes from affecting the overall consensus process and reducing consensus delays. In the special case where the number of groups is 1, compared to the situation where there are multiple groups and the internal log synchronization progress cannot be obtained, the relay node of the group has a global view of the cluster log synchronization progress. After collecting the successful synchronization responses that meet the majority number, the aggregated message can be safely returned without waiting for a few slow nodes.

[0049] The Praft algorithm ensures that the leader node always has the latest version of log information. The client read request only reads data from the state machine and does not involve any modification operations on the data. Therefore, the log synchronization phase can be skipped, and the leader directly responds to the client read request to avoid the network and I / O overhead of copying the log to more than half of the nodes. However, leader switching caused by node failure or network partitioning may cause the old leader to return outdated data to the client and fail to provide linear consistency guarantees. The key to solving this problem is that the leader needs to confirm whether it is still the valid leader for the current term after receiving the client read request to determine whether to respond to the request. The Praft algorithm manages the leader node identity through a lease mechanism and uses the isQuorum field to identify whether the leader node is valid in the current term. The leader node does not need to verify its identity by broadcasting a heartbeat during the validity period and can directly respond to client read-only requests. For example Figure 2 As shown in the figure, after completing majority log synchronization or receiving heartbeat responses from more than half of the follower nodes, the leader node resets the lease and guarantees the validity of the identity during the lease.

[0050] A crash-tolerant consensus system based on relay ideas and lease mechanisms, including

[0051] The leader node is used to process client requests and encapsulate the requests as log entries; append log entries to the local log; divide log entries into groups and select relay nodes; send log synchronization requests to relay nodes; receive responses from relay nodes and count the log synchronization progress of the cluster; mark submitted log entries as submitted and send a confirmation submission message;

[0052] The relay node acts as the proxy leader of the group and is used to receive log synchronization requests from the leader; broadcast log entries to all follower nodes in the group; wait for and aggregate synchronization responses from followers; send aggregated response messages to the leader node; receive and forward confirmation submission messages from the leader to other nodes in the group;

[0053] Follower nodes are used to receive log entries from relay nodes; log entries are appended to local logs; relay nodes send synchronization confirmation messages; receive and execute client instructions in confirmation submission messages from relay nodes;

[0054] The client is used to send requests to the leader node; wait and receive responses from the leader node.

[0055] Client and leader node: The client sends a request to the leader node and waits for a response;

[0056] Leader node and relay nodes: The leader node sends log entries to relay nodes and receives responses from relay nodes;

[0057] Relay nodes and follower nodes: Relay nodes broadcast log entries to follower nodes and collect their responses;

[0058] Relay node and leader node: The relay node sends the aggregated response to the leader node and receives a confirmation submission message from the leader;

[0059] Relay node and follower node: The relay node forwards the confirmation submission message to the follower node;

[0060] Follower nodes and local state machines: Follower nodes execute submitted client instructions in local state machines.

[0061] In the consensus process of the Raft algorithm, the messages that the leader node needs to process can be summarized into the following four categories: (1) receiving read and write requests from the client; (2) synchronizing logs to other nodes in the cluster or sending submitted log entry numbers; (3) receiving response messages returned by other nodes; and (4) replying to the client request execution results.

[0062] The follower node needs to receive the log entry synchronized by the leader or the submitted log entry number and reply to the leader's log synchronization result. In a cluster consisting of n nodes, for each client request, the leader node needs to send and receive at least 2n+n / 2+1 messages, while the follower node only needs to process 2 messages. As the cluster size continues to increase, the message load borne by the leader node and the follower node in the consensus process will become more and more unbalanced, but there is no significant difference in the physical performance of the nodes where the two are located. The exponential message forwarding and reception will gradually make the leader node a performance bottleneck. At the same time, as the only interface for the cluster's external services, receiving and processing massive client requests will also cause the leader node to become a performance bottleneck, affecting the cluster's throughput.

[0063] The terminal device provided by the present invention includes: a processor, a memory, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the steps in the above-mentioned method embodiments are implemented. Alternatively, when the processor executes the computer program, the functions of the modules / units in the above-mentioned device embodiments are implemented.

[0064] The computer program may be divided into one or more modules / units, and the one or more modules / units are stored in the memory and executed by the processor to accomplish the present invention.

[0065] The terminal device may be a computing device such as a desktop computer, a notebook, a PDA, a cloud server, etc. The terminal device may include, but is not limited to, a processor and a memory.

[0066] The processor can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0067] The memory may be used to store the computer programs and / or modules, and the processor implements various functions of the terminal device by running or executing the computer programs and / or modules stored in the memory and calling the data stored in the memory.

[0068] If the module / unit integrated in the terminal device is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present invention implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, U disk, mobile hard disk, disk, optical disk, computer memory, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), electric carrier signal, telecommunication signal and software distribution medium. It should be noted that the content contained in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electric carrier signals and telecommunication signals.

[0069] Embodiment 2

[0070] The present invention selects the Etcd-raft algorithm as the control algorithm, and uses throughput and latency as performance evaluation criteria to verify the effectiveness of the Praft algorithm improvement strategy. As the most widely used Raft algorithm implementation in production practice, the Etcd-raft algorithm implements batch processing of messages and log entries, asynchronous submission, periodic identity verification and other optimizations based on the Raft algorithm. It is currently deployed in distributed systems such as Etcd, Kubernetes, CockroachDB, and Hyperledger.

[0071] In terms of communication load, as the cluster size continues to increase, the message load borne by the follower nodes of the Etcd-raft algorithm during the consensus process has not changed, while the message load borne by the leader node during the consensus process has increased significantly, leading to the emergence of the leader performance bottleneck problem. In the improved Praft algorithm, when the number of relay nodes remains the same, the additional message load brought about by the increase in cluster size is more evenly distributed between the leader and the selected relay nodes. For example, in a test cluster with 25 nodes, the average message load of the Raft algorithm leader node during the consensus process is about 25 times that of the follower node, while the message load of the Praft algorithm leader node with one relay node during the consensus process is only about 1.02 times that of the follower node. This shows that the introduction of relay nodes in the Praft algorithm can effectively alleviate the leader performance bottleneck problem caused by the forwarding and reception of massive messages.

[0072] In terms of throughput, Figure 3 As shown in the figure, when the cluster size is small, the communication load faced by the leader node is not enough to make it a performance bottleneck. Therefore, compared with the three-stage consensus process of the Praft algorithm, the two-stage consensus of the control algorithm Etcd-raft has a higher throughput. As the cluster size increases, the throughput of the Etcd-raft algorithm drops significantly due to the leader performance bottleneck problem. The Praft algorithm uses the method of polling to select relay nodes to amortize the message load during log synchronization. Under the same cluster size, the consensus throughput is about 135% to 700% of the Etcd-raft algorithm.

[0073] Delay, such as Figure 4As shown in the figure, in a test cluster with 5 nodes, Praft and Etcd-raft have similar delays when the request load is low. As the client write request load continues to increase, the throughput of the Etcd-raft algorithm quickly saturates. The Praft algorithm reduces the leader message load through layered log synchronization and read-only request optimization, and the consensus delay is reduced by 20% to 30% compared with the Etcd-raft algorithm. As the cluster scale continues to expand, under the dual influence of client request load and intra-cluster communication load, the scalability of the Etcd-raft algorithm is further limited, reaching the throughput limit faster, while the performance of the Praft algorithm is not affected too much. Although the delay is improved under high-frequency client request load, it still fluctuates within a relatively stable range and is significantly lower than the Etcd-raft algorithm. In a test cluster with 25 nodes, the Praft algorithm and the Etcd-raft algorithm show significant differences in delay. Under the same frequency of client request load, the delay is reduced by 40% to 50% compared with the Etcd-raft algorithm. In addition, the difference in latency of the Praft algorithm with different numbers of relay nodes gradually increases with the increase of request load. Configuring multiple relay nodes can prevent a single relay node from becoming a new performance bottleneck, accelerate the consensus reached between cluster nodes for client requests, and thus reduce the overall latency of the algorithm and improve scalability.

[0074] In addition, as the proportion of client read requests continues to increase, compared to write requests that need to be synchronized to more than half of the nodes in the form of log entries to reach a consensus, read requests only need to request the maximum number of submitted log entries from the valid leader of the cluster's current term, thereby greatly reducing the time and resource overhead required to process requests. In addition, as the size of the cluster continues to increase, the request processing time overhead of the test group with a lower proportion of read requests also increases accordingly, while the time overhead of the test group with a higher proportion of read requests is not affected too much. This is because the message load required to process read requests in the Praft algorithm is fixed and will not change significantly with the size of the cluster, while the communication complexity of processing write requests is O(n), which increases linearly with the size of the cluster, and therefore shows a gradual upward trend, such as Figure 5 shown.

[0075] Therefore, the present invention adopts the above-mentioned crash-tolerant consensus method and system based on the relay idea and lease mechanism, and is committed to solving the leader performance bottleneck problem caused by receiving and processing massive client read and write requests and synchronizing log entries between cluster nodes. It proposes a crash-tolerant consensus algorithm Praft based on the relay idea and lease mechanism, which distributes the message load of the leader node in the consensus process from the two aspects of request processing and log synchronization, thereby alleviating the performance bottleneck problem while ensuring the security and activity of the algorithm.

[0076] Finally, it should be noted that the above embodiments are only used to illustrate the technical solution of the present invention rather than to limit it. Although the present invention has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that they can still modify or replace the technical solution of the present invention with equivalents, and these modifications or equivalent replacements cannot cause the modified technical solution to deviate from the spirit and scope of the technical solution of the present invention.

Claims

1. A crash-tolerant consensus method based on relay ideas and lease mechanisms, characterized in that: The following steps are involved: In the log pre-synchronization phase, the leader node accepts client requests, encapsulates them into log entries, and adds them to the local log. It divides the local log into groups, then selects a node from the pre-divided groups as a relay node and sends a log synchronization request to the relay node. The relay node processes the log synchronization request from the leader as a follower until the local log reaches a consensus with the leader, and then enters the log synchronization phase. Log synchronization phase: The relay node selected in the pre-synchronization phase acts as the proxy leader node of the group and sends log synchronization requests to all follower nodes in the group, waiting for synchronization responses from the follower nodes. Finally, it aggregates them into a complete response message and returns it to the leader node, entering the confirmation submission phase; Confirmation and submission phase: After receiving the aggregation message of its group returned by the relay node, the leader node summarizes the current synchronization progress of the cluster. If the log entry has been synchronized to more than half of the nodes, the corresponding log entry will be marked as submitted in the local state machine, and a confirmation submission message with the current submitted log number will be sent to the relay node, and the client request will be responded to at the same time; the relay node will then forward it to other nodes in the group, and the state machines of each node in the group will execute the client instructions in the submitted log entry.

2. According to claim 1, a crash-tolerant consensus method based on relay concept and lease mechanism is characterized in that: The leader node receives client read and write requests and allows follower nodes to receive and process client read-only requests. After receiving a client read-only request, the follower node requests the leader node for the maximum number of its currently committed log entries. After the corresponding log entry is committed and applied to the local state machine, the follower node executes the client read operation and returns a query result that satisfies linear consistency.

3. According to claim 1, a crash-tolerant consensus method based on relay concept and lease mechanism is characterized in that: The log conflict handling mechanism of the crash-tolerant consensus algorithm Raft is optimized, including adding an additional field in the synchronization rejection response message to inform the leader node which log entry the next synchronization request should start from, thereby bypassing all conflicting log entries.

4. According to claim 1, a crash-tolerant consensus method based on relay concept and lease mechanism is characterized in that: During the log synchronization phase and the confirmation submission phase, after successful synchronization, each group's relay node will return a response message to the leader node that summarizes the synchronization status of other nodes in the group. The Praft algorithm follows the majority theory, and the leader considers the synchronization successful when it receives successful responses from more than half of the nodes.

5. According to claim 1, a crash-tolerant consensus method based on relay concept and lease mechanism is characterized in that: The leader node receives successful responses from more than half of all relay nodes to submit log entries. A collection threshold is set for special cases. After the set threshold is met, the corresponding log entry is marked as submitted in the local state machine. The collection threshold t i Should satisfy the following Where, t i The response collection threshold for the ith group, s i is the number of responses ignored when collecting responses in the ith group, n i is the number of follower nodes in the i-th group, s i , t i , n i The relationship between the three is t i =n i -s i , p represents the number of groups divided by clustering.

6. According to claim 1, a crash-tolerant consensus method based on relay concept and lease mechanism is characterized in that: The crash-tolerant consensus algorithm Praft manages the identity of the leader node through a lease mechanism, and uses the isQuorum field to identify whether the leader node is valid in the current term. During the validity period, the leader node does not need to verify its identity by broadcasting heartbeats, and directly responds to client read-only requests.

7. A crash-tolerant consensus system based on relay ideas and lease mechanisms, characterized in that: include The leader node is used to process client requests, encapsulate the requests as log entries, append the log entries to the local log, divide the log entries into groups, and select relay nodes; Send log synchronization requests to relay nodes; receive responses from relay nodes and count the log synchronization progress of the cluster; mark submitted log entries as submitted and send a confirmation submission message; The relay node acts as the proxy leader of the group and is used to receive log synchronization requests from the leader; it broadcasts log entries to all follower nodes in the group; Wait for and aggregate synchronization responses from followers; send aggregated response messages to the leader node; receive and forward confirmation submission messages from the leader to other nodes in the group; Follower nodes are used to receive log entries from relay nodes; log entries are appended to local logs; relay nodes send synchronization confirmation messages; receive and execute client instructions in confirmation submission messages from relay nodes; The client is used to send requests to the leader node; Wait for and receive a response from the leader node.

8. According to claim 7, a crash-tolerant consensus system based on relay concept and lease mechanism is characterized in that: include Client and leader node: The client sends a request to the leader node and waits for a response; Leader node and relay nodes: The leader node sends log entries to relay nodes and receives responses from relay nodes; Relay nodes and follower nodes: Relay nodes broadcast log entries to follower nodes and collect their responses; Relay node and leader node: The relay node sends the aggregated response to the leader node and receives a confirmation submission message from the leader; Relay node and follower node: The relay node forwards the confirmation submission message to the follower node; Follower nodes and local state machines: Follower nodes execute submitted client instructions in local state machines.

9. A terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

Images