A collapse fault-tolerant consensus method and system based on relay idea and lease mechanism

Abstract

The application provides a crash fault-tolerant consensus method and system based on a relay thought and a lease mechanism, and proposes a crash fault-tolerant consensus algorithm Praft based on the relay thought and the lease mechanism. The message load of a leader node in a consensus process is apportioned from two aspects of request processing and log synchronization, so that the safety and activity of the algorithm are ensured while the performance bottleneck problem is relieved. The application adopts the crash fault-tolerant consensus method and system based on the relay thought and the lease mechanism, and is dedicated to solving the leader performance bottleneck problem 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 a lease mechanism. Background Art

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

[0003] The Replicated Atomic Fault-Tolerant (Praft) consensus algorithm is primarily used to address anomalies such as delayed arrival, loss, and out-of-order synchronization messages sent between nodes in unreliable network environments. After the cluster is started, the algorithm selects a single leader through a leader election mechanism to receive and process client requests. The elected leader node synchronizes client requests to other follower nodes as log entries. After receiving successful synchronization responses from more than half of the nodes, the log entry is submitted and the client's read and write requests are executed. Consensus algorithms that rely on a stable leader to coordinate synchronization are called strong leader consensus algorithms. Common strong leader consensus algorithms include Paxos and Raft.

[0004] While the strong leader consensus algorithm meets the system's safety and liveness requirements, the leader node bears a heavy communication load during the consensus process. As the cluster scales, the leader node gradually becomes a bottleneck for cluster throughput. Existing solutions to the leader performance bottleneck in strong leader consensus algorithms primarily eliminate leader elections or allow every node to serve as a leader. Furthermore, additional coordination mechanisms are used to address conflicts and out-of-order scheduling issues that can arise from the lack of unified scheduling. For example, Mencius uses a specific strategy to rotate cluster nodes as leaders to alleviate the performance bottleneck caused by a fixed leader. However, any node failure can potentially cause cluster service unavailability and poor stability. Epaxos allows any node in the cluster to serve as a leader to process and synchronize requests, and uses an additional mechanism to sort requests when they conflict. While concurrently processing requests by multiple leader nodes can improve system throughput and distribute the communication load, the additional conflict handling mechanism can severely impact system performance in scenarios with a high number of conflicting requests. While existing solutions address the leader performance bottleneck, they also introduce complex failure and conflict handling mechanisms, violating the Raft algorithm's design philosophy of being 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 concept 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. An optimized crash-tolerant consensus algorithm Praft based on the relay concept and lease mechanism is proposed. The method 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.

[0006] To achieve the above objectives, the present invention provides a crash-tolerant consensus method based on relay ideas and a lease mechanism, 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 then divides the local log into groups, 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, as a follower, processes the log synchronization request from the leader until the local log reaches a consensus with the leader, at which point the log synchronization phase begins.

[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. It waits for synchronization responses from the follower nodes and finally aggregates them into a complete response message and returns it to the leader node, entering the confirmation and submission phase.

[0009] Confirmation and submission phase: After receiving the aggregation message of its group from 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 committed in the local state machine, and a confirmation submission message with the current committed log number will be sent to the relay node, while responding to the client request; the relay node then forwards it to other follower nodes in the group, and the state machine of each node in the group executes the client instructions in the committed 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 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 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 which log entry the next synchronization request should start from, thereby bypassing all conflicting log entries.

[0012] Preferably, during 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 optimized crash-tolerant consensus algorithm Praft 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 is set to 0. Should satisfy the following formula

[0014] ;

[0015] Where, The response collection threshold for the i-th group, is the number of responses omitted when collecting responses in the i-th group, is the number of follower nodes in the i-th group, , The relationship between the three is , p represents the number of groups divided by the cluster.

[0016] Preferably, the optimized 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. During the validity period, the leader node does not need to verify its identity through broadcasting heartbeats and directly responds to client read-only requests.

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

[0018] The leader node processes client requests and encapsulates them as log entries; appends log entries to the local log; groups log entries into groups and selects relay nodes; sends log synchronization requests to relay nodes; receives responses from relay nodes and counts the log synchronization progress of the cluster; marks submitted log entries as submitted and sends a confirmation message.

[0019] The relay node acts as the proxy leader of the group, receiving log synchronization requests from the leader; broadcasting log entries to all follower nodes in the group; waiting for and aggregating synchronization responses from followers; sending aggregated response messages to the leader node; receiving and forwarding confirmation submission messages from the leader to other nodes in the group;

[0020] Follower nodes receive log entries from relay nodes; append log entries 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 for 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 their local state machines.

[0028] A terminal device includes 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 the relay concept and lease mechanism, and the technical effects are as follows:

[0030] In the request processing phase, the follower node is allowed to process the client read-only request, and after receiving the read-only request, the log synchronization phase is skipped, and the leader node is directly requested for the maximum number of currently committed log entries, and the data read service meeting linear consistency is provided according to the maximum number, and the legality of the leader node identity is ensured through the lease mechanism, so as to improve the read request throughput and avoid the leader node from becoming the performance bottleneck of the cluster due to processing a large number of client requests;

[0031] In the log replication phase, a relay node is introduced as a new node state to implement hierarchical log synchronization, and the cluster nodes are divided into multiple consensus groups, and the relay node is selected as a proxy leader from the group before each round of consensus to share the communication load of the leader node in the consensus process, so as to avoid the single point performance bottleneck problem and improve the consensus throughput and concurrency of the cluster. BRIEF DESCRIPTION OF DRAWINGS

[0032] Figure 1 The message flowchart for the Praft algorithm;

[0033] Figure 2 The heartbeat lease mechanism for the Praft algorithm;

[0034] Figure 3 The throughput comparison experiment under different cluster sizes;

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

[0036] Figure 5 The performance comparison experiment of different read-write ratios under different cluster sizes. DETAILED DESCRIPTION

[0037] The technical solutions of the present application are further described below by means of the drawings and examples.

[0038] Unless otherwise defined, the technical terms or scientific terms used in the present application shall have the usual meanings understood by those skilled in the art to which the present application belongs.

[0039] Example 1

[0040] As Figure 1As shown, the present invention provides a crash-tolerant consensus method and system based on the relay concept and lease mechanism. It is 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 a 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 follower node will execute the client read operation and return a query result that satisfies linear consistency. For client write requests, the leader node encapsulates it as a log entry and adds it to the local log. It then selects a node from the pre-divided group as a relay node. Figure 1 The red and blue sections represent two independent, non-overlapping consensus groups. The first node in each group is selected as the relay node for the current consensus round, and a log synchronization request is sent to that relay node. During the pre-synchronization phase, the relay node, acting as a follower, processes log synchronization requests from the leader until its local logs reach consensus with the leader, at which point the log synchronization phase begins.

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

[0043] Confirmation and Commitment Phase: After receiving a response message from the relay node for its group, the leader node aggregates the cluster's current log synchronization progress. If a log entry has been synchronized to more than half of the nodes, the leader node marks the corresponding log entry as committed in its local state machine and sends a confirmation and commit message with the currently committed log number to the relay node, responding to the client request. The relay node then forwards this message to the other follower nodes in its group, and the state machines of each node in the group execute the client instructions in the committed log entry.

[0044] Since the efficiency of log synchronization between the leader node and the relay nodes is related to the performance of the consensus algorithm, if there is a large log discrepancy 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 a timely manner, 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 which log entry the next synchronization request should start from, 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 submits a log entry after receiving successful responses from more than half of all relay nodes. 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 is set to 0. Should satisfy the following formula

[0046] ;

[0047] Where, The response collection threshold for the i-th group, is the number of responses omitted when collecting responses in the i-th group, is the number of follower nodes in the i-th group, , The relationship between the three is , p represents the number of groups divided by the cluster.

[0048] During the log synchronization and commit phases, after successful synchronization, each group's relay nodes return a response message to the leader node that aggregates the synchronization status of all other nodes in the group. Similar to the Raft algorithm, the Praft algorithm adheres to the majority principle, where the leader considers synchronization successful upon receiving successful responses from more than half of the nodes. Therefore, relay nodes within each group do not need to wait for all followers to return successful synchronization responses. Instead, they can return the subset of responses they have collected once a certain threshold is reached. Ideally, the leader node only needs to receive more than half of the successful synchronization responses to commit a log entry. Correspondingly, each group's relay nodes only need to collect synchronization responses from a subset of followers before returning a response message to the leader node. This prevents slow or faulty nodes from impacting the overall consensus process and reduces consensus latency. In the special case of a single group, unlike multiple groups, where internal log synchronization progress is inaccessible, the group's relay nodes have a global view of the cluster's log synchronization progress. Once a majority of successful synchronization responses have been collected, they can safely return an aggregated message without waiting for a small number of 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 linear consistency guarantees cannot be provided. The key to solving this problem is that the leader needs to confirm whether it is still the valid leader of 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 through broadcast heartbeats during the validity period and can directly respond to client read-only requests. For example Figure 2 As shown in Figure 2, 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 processes client requests and encapsulates them as log entries; appends log entries to the local log; groups log entries into groups and selects relay nodes; sends log synchronization requests to relay nodes; receives responses from relay nodes and counts the log synchronization progress of the cluster; marks submitted log entries as submitted and sends a confirmation message.

[0052] The relay node acts as the proxy leader of the group, receiving log synchronization requests from the leader; broadcasting log entries to all follower nodes in the group; waiting for and aggregating synchronization responses from followers; sending aggregated response messages to the leader node; receiving and forwarding confirmation submission messages from the leader to other nodes in the group;

[0053] Follower nodes receive log entries from relay nodes; append log entries 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 for 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 their local state machines.

[0061] In the Raft algorithm consensus process, 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] Follower nodes need to receive the log entries synchronized by the leader or the numbers of submitted log entries and reply to the leader with the log synchronization results. 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 follower nodes during the consensus process will become increasingly unbalanced. However, 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 of each of the aforementioned method embodiments are implemented. Alternatively, when the processor executes the computer program, the functions of each module / unit in each of the aforementioned device embodiments are implemented.

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

[0065] The terminal device can be a desktop computer, a notebook computer, a palm computer, a cloud server, and the like. The terminal device can include, but is not limited to, a processor and a memory.

[0066] The processor can be a central processing unit (CPU), and can also be other general-purpose processors, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, and the like.

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

[0068] The modules / units integrated in the terminal device, if realized in the form of software function units and sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the above-mentioned embodiments can also be completed by a computer program instructing related hardware, and the computer program can be stored in a computer-readable storage medium. When the processor executes the computer program, the steps of the above-mentioned various method embodiments can be realized. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or some intermediate forms, etc. The computer-readable medium can include any entity or device capable of carrying the computer program code, recording media, U disks, mobile hard disks, magnetic disks, optical disks, computer memories, read-only memories (ROMs), random access memories (RAMs), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the computer-readable medium can include or exclude contents according to the requirements of legislation and patent practice in different jurisdictions. For example, in some jurisdictions, according to legislation and patent practice, the computer-readable medium does not include electrical carrier signals and telecommunication signals.

[0069] Embodiment Two

[0070] This paper selects the Etcd-Raft algorithm as a control algorithm and uses throughput and latency as performance evaluation criteria to verify the effectiveness of the Praft algorithm's improvement strategy. As the most widely used Raft algorithm implementation in production practice, the Etcd-Raft algorithm implements optimizations such as batch processing of messages and log entries, asynchronous submission, and periodic identity verification 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 Etcd-Raft algorithm follower nodes during the consensus process remains unchanged, while the message load borne by the leader node during the consensus process increases significantly, leading to the emergence of a performance bottleneck for the leader. With the improved Praft algorithm, while maintaining the same number of relay nodes, 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 approximately 25 times that of the follower nodes, while the message load of the Praft algorithm leader node with one relay node is only approximately 1.02 times that of the follower nodes during the consensus process. This indicates that the introduction of relay nodes in the Praft algorithm can effectively alleviate the leader performance bottleneck caused by the forwarding and reception of massive messages.

[0072] Throughput, such as Figure 3 As shown in the figure, when the cluster size is small, the communication load faced by the leader node is not high enough to become a performance bottleneck. Therefore, compared with the three-phase consensus process of the Praft algorithm, the two-phase consensus of the control algorithm Etcd-Raft has higher throughput. As the cluster size increases, the throughput of the Etcd-Raft algorithm drops significantly due to the leader performance bottleneck. The Praft algorithm uses polling to select relay nodes to distribute the message load during log synchronization. At the same cluster size, the consensus throughput of the Praft algorithm is approximately 135% to 700% of that of the Etcd-Raft algorithm.

[0073] Delay, such as Figure 4As shown, in a 5-node test cluster, Praft and Etcd-Raft have similar latencies under low request loads. As client write request loads increase, Etcd-Raft's throughput quickly saturates. Praft reduces the leader message load through layered log synchronization and read-only request optimization, resulting in a 20%-30% reduction in consensus latency compared to Etcd-Raft. As cluster size increases, Etcd-Raft's scalability is further limited by the combined effects of client request load and intra-cluster communication load, reaching its throughput limit more quickly. However, Praft's performance is not significantly impacted. While latency increases under high-frequency client request loads, it remains within a relatively stable range and is significantly lower than Etcd-Raft. In a 25-node test cluster, Praft and Etcd-Raft exhibit significant latency differences, with Praft achieving a 40%-50% reduction in latency compared to Etcd-Raft under the same frequency of client requests. 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, thereby reducing the overall latency of the algorithm and improving 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 significantly reducing the time and resource overhead required to process requests. In addition, as the cluster size 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 gradually increasing 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 solutions of the present invention rather than to limit the same. 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 solutions of the present invention with equivalents, and these modifications or equivalent replacements cannot cause the modified technical solutions to deviate from the spirit and scope of the technical solutions of the present invention.

Claims

1. A crash-tolerant consensus method based on relay ideas and lease mechanisms, characterized by: The following steps are involved: In the log pre-synchronization phase, the leader node accepts client requests, encapsulates the client requests into log entries, and adds them to the local log. The leader node then divides the local log into groups. It 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, acting as a follower, processes the log synchronization request from the leader until the local log reaches a consensus with the leader, at which point the log synchronization phase begins. 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. It waits for synchronization responses from the follower nodes and finally aggregates them into a complete response message and returns it to the leader node, entering the confirmation and submission phase. Confirmation and submission phase: After receiving the aggregation message of its group from 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 leader node marks the corresponding log entry as committed in the local state machine, sends a confirmation and submission message with the current committed log number to the relay node, and responds to the client request at the same time; The relay node then forwards it to other nodes in its group, and the state machine of each node in the group executes the client instructions in the submitted log entry; 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 Should satisfy the following formula ； Where, Collect thresholds for responses of group i, is the number of responses omitted when collecting responses in the i-th group, is the number of follower nodes in the i-th group, The relationship between the three is , p represents the number of groups divided by the cluster.

2. A crash-tolerant consensus method based on relay concept and lease mechanism according to claim 1, 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 maximum number of its currently submitted log entries from the leader node. 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. The crash-tolerant consensus method based on relay concept and lease mechanism according to claim 1 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. The crash-tolerant consensus method based on relay concept and lease mechanism according to claim 1 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 optimized crash-tolerant consensus algorithm Praft follows the majority theory. The leader considers synchronization successful when it receives successful responses from more than half of the nodes.

5. The crash-tolerant consensus method based on relay concept and lease mechanism according to claim 1 is characterized in that: The optimized 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 through broadcasting heartbeats and can directly respond to client read-only requests.

6. A crash-tolerant consensus system based on relaying and lease mechanisms, characterized by: include The leader node processes client requests, encapsulates the requests as log entries, appends the log entries to the local log, divides the log entries into groups, and selects 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 message; The relay node acts as the proxy leader of the group, receiving log synchronization requests from the leader and broadcasting 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 receive log entries from relay nodes; append log entries 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; 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 Should satisfy the following formula ； Where, Collect thresholds for responses of group i, is the number of responses omitted when collecting responses in the i-th group, is the number of follower nodes in the i-th group, The relationship between the three is , p represents the number of groups divided by the cluster.

7. A crash-tolerant consensus system based on relay concept and lease mechanism according to claim 6, 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 their local state machines.

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

Images