Distributed Request Processing Method and Related Devices Based on Multi-Round Message Exchange

Abstract

A distributed request processing method and related devices based on multi-round message exchange proposed in this application. The method includes: in response to any node server obtaining a task request, broadcasting a task consensus request message according to the task request; for each node server, determining the reception status of the task consensus request message, and broadcasting a first report message based on the reception status; for each node server, in response to the received first report message satisfying a preset second report condition, broadcasting a second report message based on the first report message; for each node server, broadcasting a current vote message according to the first report message and the second report message; for each node server, obtaining a current consensus result according to the first report message, the second report message, and the vote message; in response to the consensus result satisfying a preset consensus condition, processing the task request according to the current consensus result. This application can improve the efficiency of task request processing in a distributed system.

Description

Technical Field

[0001] The embodiments of the present application relate to, but are not limited to, the field of computer technology, and in particular, to a distributed request processing method based on multi-round message exchange and related devices. Background Art

[0002] A distributed system provides high availability, scalability, and fault tolerance by dispersing computing tasks across multiple nodes. In a distributed system, how to ensure data consistency among various nodes is a core issue. Especially in the case where some nodes fail, how to ensure that each node can establish consensus information on the response results of client requests is a key issue in a distributed system. Currently, solutions to the distributed consensus problem include asynchronous consensus.

[0003] In related technologies, an asynchronous consensus algorithm determines a binary value through multiple rounds of node interactions. In each round of node interaction, each node first generates a proposed value. When a sufficient number of nodes generate the same proposed value, the proposed value is determined based on this proposed value. In this process, the node proposed value is easily affected by a small number of abnormal nodes and changes frequently, which easily causes problems such as high latency in task response and large resource consumption. Summary of the Invention

[0004] This application aims to solve at least one of the technical problems existing in the prior art. To this end, this application provides a distributed request processing method based on multi-round message exchange and related devices, which can improve the efficiency of task request processing in a distributed system.

[0005] To achieve the above object, a first aspect of the embodiments of this application proposes a distributed request processing method based on multi-round message exchange, which is applied to a distributed system. The distributed system includes multiple node servers, and the method includes:

[0006] In response to any one of the node servers obtaining a task request, generating a task consensus request message according to the task request, and broadcasting the task consensus request message in the distributed system;

[0007] For each of the node servers, determining the reception status of the task consensus request message, generating a first report message based on the reception status, and broadcasting the first report message in the distributed system;

[0008] For each of the node servers, in response to the received first report message satisfying a preset second report condition, generating a second report message based on the first report message, and broadcasting the second report message in the distributed system;

[0009] For each of the node servers, generate a current voting message according to the first report message and the second report message, and broadcast the current voting message in the distributed system;

[0010] For each of the node servers, obtain a current consensus result according to the first report message, the second report message, and the voting message;

[0011] In response to the consensus result meeting a preset consensus condition, perform task request processing on the task request according to the current consensus result.

[0012] In some embodiments, the step of, in response to any one of the node servers obtaining a task request, generating a task consensus request message according to the task request and broadcasting the task consensus request message in the distributed system includes:

[0013] Obtain the task request;

[0014] Select, in a preconfigured request sequence set, the sequence number with the smallest sequence and not yet used as the task request sequence number of the task request;

[0015] Generate a task consensus request message according to the task request and the task request sequence number;

[0016] Broadcast the task consensus request message in the distributed system.

[0017] In some embodiments, the first report message includes a first report value, and the first report value is equal to a first binary value or a second binary value. The step of, for each of the node servers, determining the reception status of the task consensus request message, generating a first report message based on the reception status, and broadcasting the first report message in the distributed system includes:

[0018] For each of the node servers, if the reception status is received, broadcast the first report message including the first binary value in the distributed system;

[0019] For each of the node servers, if the reception status is not received and there are a target number of other task requests with sequence numbers greater than the task request sequence number that have been processed, broadcast the first report message including the second binary value in the distributed system.

[0020] In some embodiments, the distributed system further includes a randomly generated common binary value. For each of the node servers, in response to the received first report message satisfying a preset secondary report condition, a secondary report message is generated based on the first report message and the secondary report message is broadcast in the distributed system, including:

[0021] For each of the node servers, if the node server receives the target number of the first report messages, and the received first report messages simultaneously include the first binary value and the second binary value, and the first report value broadcast by the node server is different from the common binary value, then a secondary report message is generated according to the common binary value;

[0022] The secondary report message is broadcast in the distributed system; wherein, the secondary report message includes a secondary report value, and the secondary report value is equal to the first binary value or the second binary value.

[0023] In some embodiments, the voting message includes a first voting message and a second voting message. For each of the node servers, a current voting message is generated according to the first report message and the second report message and the current voting message is broadcast in the distributed system, including:

[0024] For each of the node servers, an implicit report message is generated according to the received second report message and the first report message; wherein, the implicit report value of the implicit report message is different from the secondary report value of the second report message;

[0025] If the sum of the number of the first report messages and the implicit report messages reaches the target number, and the corresponding implicit report values are the same as the first report values, then a first voting message is broadcast in the distributed system; wherein, the voting value of the first voting message is equal to the first report value;

[0026] If the sum of the number of the first report messages and the second report messages reaches the target number, and the corresponding first report values are the same as the second report values, then a second voting message is broadcast in the distributed system; wherein, the voting value of the second voting message is equal to the second report value.

[0027] In some embodiments, for each of the node servers, a current consensus result is obtained according to the first report message, the second report message and the voting message, including:

[0028] For each of the node servers, when the number of the first voting messages containing the same voting value received by the node server reaches the target number, or the sum of the number of the implicit report messages and the first report messages received reaches the target number, and the corresponding implicit report value and the first report value are both equal to the common binary value of the current round, or a first voting message with a voting value equal to the common binary value of the current round is received, a consensus result for indicating that consensus is reached is generated according to the voting value or the first report value, otherwise, the next round is entered.

[0029] In some embodiments, in response to the consensus result satisfying a preset consensus condition, task request processing is performed on the task request according to the current consensus result, including:

[0030] When the consensus result includes the first binary value, submission processing is performed on the task request;

[0031] When the consensus result includes the second binary value, skipping processing is performed on the task request.

[0032] In some embodiments, when the task request is skipped or the consensus result indicates that consensus is not reached, the method further includes:

[0033] For each of the node servers, if the node server receives the task consensus request message but does not send the first report message or the second report message or the first voting message or the second voting message containing the first binary value, a first confirmation message is broadcast in the distributed system according to the task request sequence number;

[0034] For each of the node servers, if the sum of the number of the first confirmation messages received and the first report messages with the first report value being the first binary value and the implicit report messages with the implicit report value being the first binary value reaches the target number, or in response to the server receiving a first voting message or a second voting message with a voting value being the first binary value, the task request is determined to be in a stable state;

[0035] For each of the node servers, a sequence number that is the smallest and unused in the request sequence set is reselected as the second request sequence number of the task request;

[0036] According to the task request sequence number and the second request sequence number, a request re-submission message is generated and the request re-submission message is broadcast in the distributed system;

[0037] For each of the node servers, in response to receiving the request resubmission message, submit the task request according to the task request sequence number.

[0038] In a second aspect, an embodiment of the present application provides a distributed request processing device based on multi-round message exchange, including:

[0039] A first broadcast module, configured to, in response to any one of the node servers obtaining a task request, generate a task consensus request message according to the task request, and broadcast the task consensus request message in the distributed system;

[0040] A second broadcast module, configured to, for each of the node servers, determine the reception status of the task consensus request message, generate a first report message based on the reception status, and broadcast the first report message in the distributed system;

[0041] A third broadcast module, configured to, for each of the node servers, in response to the received first report message satisfying a preset secondary report condition, generate a secondary report message based on the first report message, and broadcast the secondary report message in the distributed system;

[0042] A fourth broadcast module, configured to, for each of the node servers, generate a current vote message according to the first report message and the secondary report message, and broadcast the current vote message in the distributed system;

[0043] A consensus module, configured to, for each of the node servers, obtain a current consensus result according to the first report message, the secondary report message, and the vote message;

[0044] A processing module, configured to, in response to the consensus result satisfying a preset consensus condition, perform task request processing on the task request according to the current consensus result.

[0045] In a third aspect, an embodiment of the present application provides an electronic device, including: a memory and a processor, where the memory stores a computer program, and the processor implements the distributed request processing method based on multi-round message exchange according to any one of the embodiments in the first aspect of the present application when executing the computer program.

[0046] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, where the storage medium stores a program, and the program is implemented by the processor to implement the distributed request processing method based on multi-round message exchange according to any one of the embodiments in the first aspect of the present application.

[0047] The distributed request processing method based on multi-round message exchange proposed in the embodiments of the present application is applied to a distributed system. The distributed system includes multiple node servers. The method includes: in response to any node server obtaining a task request, generating a task consensus request message according to the task request, and broadcasting the task consensus request message in the distributed system; for each node server, determining the reception status of the task consensus request message, generating a first report message based on the reception status, and broadcasting the first report message in the distributed system; for each node server, in response to the received first report message meeting a preset secondary report condition, generating a secondary report message based on the first report message, and broadcasting the secondary report message in the distributed system; for each node server, generating a current vote message according to the first report message and the secondary report message, and broadcasting the current vote message in the distributed system; for each node server, obtaining a current consensus result according to the first report message, the secondary report message, and the vote message; in response to the consensus result meeting a preset consensus condition, performing task request processing on the task request according to the current consensus result.

[0048] The distributed request processing method based on multi-round message exchange proposed in this application. The node server first broadcasts a task consensus request message, and then gradually reaches a consensus through multi-round message exchanges (initial report message, secondary report message, voting message). By introducing a two-stage reporting mechanism, the node server will not randomly change its reported value. Instead, only when the received initial report message meets the preset reporting conditions, will it trigger the broadcast of the secondary report message and may update its reported value in the secondary report. This design effectively restricts the conditions for the node server to change the proposal, preventing delays in the consensus process caused by easily changing the proposed value. In addition, in the voting stage, the node server will vote by comprehensively considering the received initial report message and secondary report message, and in each round of consensus result output stage, the node server will make a decision by comprehensively considering all the received messages (initial report message, secondary report message, and voting message). This mechanism of comprehensively considering the initial report, secondary report, and voting message further enhances the reliability and stability of the consensus result, avoiding the dominance of a single message type or a small number of node servers. When the consensus result indicates that a consensus has been reached, the request can be processed according to the consensus result. Different from the synchronous / semi-synchronous consensus algorithms that rely on the upper bound of network latency, this method belongs to an asynchronous consensus algorithm and does not rely on any latency assumptions, making it more suitable for actual network environments. Through the above two-stage reporting mechanism with constraints and comprehensive decision-making mechanism, compared with existing asynchronous consensus algorithms (in which nodes may change their proposals more frequently), this method significantly improves the stability of the consensus process, reduces unnecessary proposal changes and communication overhead, and reduces the latency of reaching a consensus while ensuring the correctness of the consensus. In summary, the method proposed in this application can improve the efficiency of reaching a consensus on task request processing in a distributed system.

[0049] Other features and advantages of this application will be described in the following specification, and part of them will become obvious from the specification or be understood by implementing this application. The objectives and other advantages of this application can be achieved and obtained through the structures specifically pointed out in the specification, claims, and drawings. Brief Description of the Drawings

[0050] Figure 1 is a schematic flowchart of the distributed request processing method based on multi-round message exchange provided by an embodiment of this application;

[0051] Figure 2 is a schematic flowchart of the distributed request processing method based on multi-round message exchange provided by another embodiment of this application;

[0052] Figure 3 is a schematic flowchart of the distributed request processing method based on multi-round message exchange provided by another embodiment of this application;

[0053] Figure 4 It is a schematic flowchart of a distributed request processing method based on multi-round message exchange provided by another embodiment of the present application;

[0054] Figure 5 It is a schematic flowchart of a distributed request processing method based on multi-round message exchange provided by another embodiment of the present application;

[0055] Figure 6 It is a schematic flowchart of a distributed request processing method based on multi-round message exchange provided by another embodiment of the present application;

[0056] Figure 7 It is a schematic flowchart of a distributed request processing method based on multi-round message exchange provided by another embodiment of the present application;

[0057] Figure 8 It is a schematic framework diagram of task request processing based on a distributed system provided by an embodiment of the present application;

[0058] Figure 9 It is a schematic framework diagram of a distributed request processing method based on multi-round message exchange provided by another embodiment of the present application;

[0059] Figure 10 It is a schematic diagram of a distributed request processing device based on multi-round message exchange provided by an embodiment of the present application;

[0060] Figure 11 It is a schematic hardware structure diagram of an electronic device provided by an embodiment of the present application. Detailed implementation manners

[0061] In order to make the objectives, technical solutions and advantages of the present application more clear and understandable, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application, but not to limit the present application.

[0062] It should be noted that although functional module division is performed in the device schematic diagram and the logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order from the module division in the device or the order in the flowchart. Terms such as "first" and "second" in the description, claims and above-mentioned drawings of the present application are used to distinguish similar objects, and do not necessarily need to be used to describe a specific order or sequence.

[0063] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the technical field to which the present application belongs. The terms used herein are only for the purpose of describing the embodiments of the present application, and are not intended to limit the present application.

[0064] In a distributed system, multiple independent nodes (servers) need to work together to jointly maintain a globally consistent state. This state can be a database, a file system, or any shared data structure. To achieve this consistency, the nodes need to reach a consensus on the execution order of a series of operations (e.g., client requests). Suppose there are a total of n nodes in a distributed system, and at most (n - 1) / 2 of these n nodes may experience downtime failures (this invention does not consider Byzantine errors, i.e., nodes will only experience downtime and will not deliberately forward incorrect messages). Nodes that experience failures are also called faulty nodes, while the remaining nodes are called correct nodes. Distributed consensus technology is to solve the problem of enabling correct nodes to reach an agreement in such a system.

[0065] According to different network environments, consensus mechanisms can be divided into synchronous consensus, semi-synchronous consensus, and asynchronous consensus. Both synchronous and semi-synchronous consensus assume that there is an upper bound on network latency, and consensus can only be reached when this upper bound exists. Asynchronous consensus algorithms can reach consensus without relying on any latency assumptions. Therefore, asynchronous consensus algorithms are more suitable for actual network conditions. The present invention belongs to asynchronous consensus algorithms. In an asynchronous network model, there is no upper bound on the message transmission latency between each pair of correct nodes, but the messages sent between each pair of correct nodes will eventually arrive. Currently, the best solution under the asynchronous network model is the Bandle protocol. In Bandle, first, a fixed task request processing order (slot) is assigned to each node. In this way, even if the nodes receive requests in different orders, the global request order can be determined according to the static sorting. Then, a binary consensus algorithm is used to determine whether the request corresponding to each slot is valid (whether it should be submitted). Due to node failures, some slots may not have corresponding requests, and the binary consensus algorithm is used to identify and skip these empty slots. The Bandle protocol uses the FlashBA binary consensus algorithm, which is a round-based binary consensus algorithm. Each round consists of two phases: propose and suggest. Each node inputs a binary value (0 or 1) for a specific request sequence number (seq). 1 indicates that the node has received the request, and 0 indicates that the node has not received the request (or believes that the request should not be submitted). In the propose phase, the node proposes a binary value based on the input value and broadcasts it to other nodes. When the node receives at least 2f + 1 identical proposed values (where f is the number of nodes that may fail in the system), the node suggests this value. When the node proposes or suggests a value, it tries to commit to this value. A commitment means that the node will not change its proposal in this round. When the node finds that at least 2f + 1 nodes have committed to the same value, the node outputs this value. If the node still cannot output after receiving at least 2f + 1 proposed values (because there are not enough commitments), it enters the next round. However, this method has obvious limitations. After receiving different proposals, the node will immediately change its proposal. This makes it difficult for the node to make a commitment because a commitment requires the node not to change its proposal in this round, and even if the node has not changed its proposal, if the value it proposes and suggests is different, it cannot make a commitment. This further reduces the possibility of the node outputting in this round, resulting in the need for multiple rounds of loops to achieve output, with a high output latency and large resource consumption.

[0066] Based on this, the embodiments of the present application provide a distributed request processing method and related devices based on multi-round message exchange, which can improve the efficiency of task request processing in a distributed system.

[0067] The distributed request processing method and related devices based on multi-round message exchange provided by the embodiments of the present application are specifically described through the following embodiments. First, the distributed request processing method based on multi-round message exchange in the embodiments of the present application is described.

[0068] The present application can be used in many general or special computer system environments or configurations. For example: personal computers, server computers, handheld or portable devices, tablet devices, multi-processor systems, microprocessor-based systems, set-top boxes, programmable consumer electronic devices, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, and so on. The present application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. The present application can also be practiced in a distributed computing environment, where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules can be located in local and remote computer storage media including storage devices.

[0069] It should be noted that in each specific embodiment of the present application, when it comes to performing relevant processing based on data related to user identity or characteristics such as user information, user behavior data, user historical data, and user location information, the user's permission or consent will be obtained first. Moreover, the collection, use, and processing of these data will comply with relevant laws, regulations, and standards. In addition, when the embodiments of the present application need to obtain sensitive personal information of users, the user's separate permission or separate consent will be obtained through methods such as pop-up windows or redirecting to a confirmation page. After clearly obtaining the user's separate permission or separate consent, the necessary user-related data for the normal operation of the embodiments of the present application will be obtained.

[0070] Figure 1 is an optional flowchart of the distributed request processing method based on multi-round message exchange provided by the embodiments of the present application. Figure 1 The method in is applied to a distributed system, and the distributed system includes multiple node servers, and may include but is not limited to steps 101 to 106.

[0071] Step 101, in response to any node server obtaining a task request, generating a task consensus request message according to the task request, and broadcasting the task consensus request message in the distributed system.

[0072] Step 102, for each node server, determining the reception status of the task consensus request message, generating a first report message based on the reception status, and broadcasting the first report message in the distributed system.

[0073] Step 103: For each node server, in response to the first report message received satisfying a preset secondary report condition, generate a secondary report message based on the first report message, and broadcast the secondary report message in the distributed system.

[0074] Step 104: For each node server, generate a current vote message according to the first report message and the secondary report message, and broadcast the current vote message in the distributed system.

[0075] Step 105: For each node server, obtain the current consensus result according to the first report message, the secondary report message, and the vote message.

[0076] Step 106: In response to the consensus result satisfying a preset consensus condition, perform task request processing on the task request according to the current consensus result.

[0077] In steps 101 to 104 illustrated in the embodiments of the present application, the node server first broadcasts a task consensus request message, and then gradually reaches a consensus through multiple rounds of message exchanges (the first report message, the secondary report message, and the vote message). By introducing a two-stage reporting mechanism, the node server will not randomly change its reported value. Instead, only when the first report message received satisfies the preset reporting condition, will it trigger the broadcast of the secondary report message and may update its reported value in the secondary report. This design effectively restricts the conditions for the node server to change the proposal, preventing the delay of the consensus process caused by easily changing the proposed value. In addition, in the voting stage, the node server will vote by comprehensively considering the first report message and the secondary report message received, and in each round of consensus result output stage, the node server will make a decision by comprehensively considering all the messages received (the first report message, the secondary report message, and the vote message). This mechanism of comprehensively considering the first report, the secondary report, and the vote message further enhances the reliability and stability of the consensus result, avoiding the dominance of a single message type or a small number of node servers. When the consensus result indicates that a consensus has been reached, the request can be processed according to the consensus result. Different from the synchronous / semi-synchronous consensus algorithms that rely on the upper bound of network latency, this method belongs to an asynchronous consensus algorithm and does not rely on any latency assumptions, making it more suitable for the actual network environment. Through the above two-stage reporting mechanism with constraint conditions and the comprehensive decision-making mechanism, compared with the existing asynchronous consensus algorithms (in which nodes may change their proposals more frequently), this method significantly improves the stability of the consensus process, reduces unnecessary proposal changes and communication overhead, and reduces the latency of reaching a consensus while ensuring the correctness of the consensus. In summary, the method proposed in the present application can improve the efficiency of reaching a consensus on task request processing in a distributed system.

[0078] In step 101 of some embodiments, any node server in the distributed system, such as a server called the "proposing node", upon receiving a task request from a client (which can be an operation such as performing a specific calculation, storing data, etc.), will initiate a consensus process. The proposing node first generates a "task consensus request message" based on the content of the task request. This message can be understood as a data packet containing the detailed information of the task request and a unique identifier (such as a serial number), used to identify and track this specific task request throughout the distributed system. Subsequently, the proposing node broadcasts this "task consensus request message" to all other node servers in the distributed system, namely the "consensus nodes", to notify them that there is a new task request that needs to reach a consensus.

[0079] Please refer to Figure 2 , in some embodiments, step 101 may include but is not limited to steps 201 to 204.

[0080] Step 201, obtain the task request.

[0081] Step 202, select the serial number with the smallest value and not yet used in the pre-configured request sequence set as the task request serial number for the task request.

[0082] Step 203, generate a task consensus request message based on the task request and the task request serial number.

[0083] Step 204, broadcast the task consensus request message in the distributed system.

[0084] In step 201 of some embodiments, a node server in the distributed system, which we call the "proposing node", receives a "task request" from a client. This "task request" can be any operation on system resources, such as requesting to execute a specific calculation code, updating a certain record in the database, or reading a certain file stored in the distributed file system. The specific content and format of the task request will be defined according to the actual application scenario, but usually include necessary information such as the operation type and operation parameters.

[0085] In step 202 of some embodiments, in order to ensure that the processing order of task requests in the distributed system is deterministic and unique, and to avoid out-of-order or repeated execution caused by network latency or node failures, the proposing node assigns a globally unique "task request sequence number" to the received task requests. The assignment of this sequence number follows a strategy called "static sorting". Specifically, each node server is pre-assigned a set of non-overlapping sequence number ranges. For example, assume there are 3 node servers (numbered 1, 2, 3) in a distributed system. Then the sequence numbers can be assigned as follows: Node 1 is responsible for assigning sequence numbers in the form of 3k + 1 (such as 1, 4, 7, 10...), Node 2 is responsible for assigning sequence numbers in the form of 3k + 2 (such as 2, 5, 8, 11...), and Node 3 is responsible for assigning sequence numbers in the form of 3k + 3 (such as 3, 6, 9, 12...), where k is a non-negative integer. When a node server receives a new task request, it selects the smallest unused sequence number from its responsible sequence number range as the "task request sequence number" for this task request.

[0086] In step 203 of some embodiments, the proposing node generates a "task consensus request message" based on the detailed content of the task request obtained in step 201 and the task request sequence number assigned in step 202. This message can be regarded as a data packet containing the complete information of the task request and the unique sequence number.

[0087] In step 204 of some embodiments, the proposing node sends the "task consensus request message" generated in step 203 to all other node servers in the distributed system through "broadcast". Broadcast is a communication mechanism that can ensure that the message is sent to every node in the system. By broadcasting the "task consensus request message", the proposing node officially starts the consensus negotiation loop for this task request. All node servers will participate in the subsequent consensus process, such as reporting the reception status, voting, etc., and finally reach a consensus on how to handle this task request (whether to execute or skip).

[0088] Through the above steps 201 to 204, the embodiments of the present application assign globally unique sequence numbers to each task request through the static sorting strategy, and distribute the task request information to all node servers in combination with the broadcast mechanism. The static sorting ensures the uniqueness and determinacy of the sequence numbers, and avoids out-of-order or repeated execution of requests caused by network latency or node failures. The broadcast mechanism ensures that all node servers can obtain the task request information in a timely manner, so as to participate in the consensus negotiation. These steps together ensure that the distributed system can maintain consistency and reliability in processing task requests in an asynchronous network environment.

[0089] In step 102 of some embodiments, each node server in the distributed system, whether it is the initial proposing node or other consensus nodes, checks whether it has received the "task consensus request message" broadcast in step 101. Here, the "receiving status" refers to whether the node server has successfully received and parsed the message. Based on this receiving status, each node server independently generates a "first report message". The "first report message" contains a key "first report value", which is a binary value. Usually, the "first binary value" (such as the logical value "1") indicates that the task request has been received, and the "second binary value" (such as the logical value "0") indicates that the task request has not been received or tends to skip the request. After generating the "first report message", each node server broadcasts it in the distributed system.

[0090] Please refer to Figure 3 , in some embodiments, the first report message includes a first report value, the first report value is equal to the first binary value or the second binary value, and step 102 may include, but is not limited to, steps 301 to 302.

[0091] Step 301, for each node server, if the receiving status is received, broadcast a first report message containing the first binary value in the distributed system.

[0092] Step 302, for each node server, if the receiving status is not received and there are a target number of other task requests with sequence numbers greater than the task request sequence number that have been processed, broadcast a first report message containing the second binary value in the distributed system.

[0093] In step 301 of some embodiments, each node server in the distributed system independently checks whether it has successfully received and parsed the "task consensus request message". This "task consensus request message" is broadcast by the proposing node to all node servers at the beginning of the consensus process and contains the detailed information of the task request and a unique serial number. If a node server confirms that it has received the message, i.e., its "receiving status" is "received", then it generates a "first report message". This "first report message" is a way for the node server to indicate its initial attitude towards the task request to other nodes in the system. In the "first report message", there is a "first report value", which is set to the "first binary value". The "first binary value" usually represents logically "true", "affirmative" or "supportive". In this scenario, it can be understood that the node server initially agrees or supports the execution of this task request. For example, it can be agreed that the "first binary value" is the number "1". After generating the "first report message", the node server broadcasts it in the distributed system, which means the message will be sent to all other node servers in the system.

[0094] In step 302 of some embodiments, if a node server has not received the "task consensus request message", i.e., its "receiving status" is "not received", it does not immediately generate a report message with a negative attitude. Instead, it further checks a condition: whether it has processed enough (reaching the preset "target quantity") other task requests with serial numbers larger than the current task request serial number. Here, the "target quantity" is usually related to the fault tolerance of the distributed system. Specifically, the "target quantity" is equal to the total number of node servers (n) in the system minus the maximum number of faulty node servers (f) allowed by the system design, i.e., n - f. This value of n - f represents the minimum number of node servers running normally in the system. If a node server has processed at least n - f subsequent requests with larger serial numbers, it means that these subsequent requests have been confirmed and processed by the majority of normal nodes in the system. In this case, even if the node server has not received the current task request, it can consider that the current request may have been lost. Therefore, when this condition is met, the node server generates a "first report message" and includes a "second binary value" in the message. The "second binary value" usually represents logically "false", "negative" or "opposing". In this scenario, it can be understood that the node server initially tends to skip or oppose the execution of this task request. For example, it can be agreed that the "second binary value" is the number "0". After generating the "first report message", the node server also broadcasts it in the distributed system.

[0095] Exemplarily, assume that a distributed system has 5 node servers (n = 5), and the design allows for a maximum of 2 node failures (f = 2), then the "target quantity" is n - f = 3. If a node server has not received a task request with a sequence number of 10, but it has processed three task requests with sequence numbers of 11, 12, and 13, then the node server will generate a "first report message" containing a "second binary value" (e.g., 0), indicating that it tends to skip the request with a sequence number of 10.

[0096] Through steps 301 to 302, in this embodiment, by introducing the "first report message" mechanism, each node server can inform other node servers in the distributed system of its reception status of the "task consensus request message" (or the inference based on the processed subsequent requests). This mechanism provides basic information for the subsequent consensus negotiation process, enabling nodes to start exchanging opinions and gradually reach an agreement. The design of the "first binary value" and the "second binary value" enables the node server to express two distinct attitudes (support or oppose / skip), thus introducing the necessary discrimination in the consensus process. In particular, the conditional judgment in step 302 fully considers the possible message delay or loss in an asynchronous network environment. By utilizing the information of the processed subsequent requests, the node server can make reasonable inferences without receiving the current request, which helps to improve the fault tolerance and efficiency of the consensus algorithm. Specifically, it avoids the entire system waiting for a long time due to individual message delays, ensuring that even in the case of partial node failures or network instability, the consensus process can continue to advance and finally reach an agreement, thereby guaranteeing the overall availability and reliability of the distributed system.

[0097] In step 103 of some embodiments, each node server continuously receives "first report messages" broadcast from other node servers. When the "first report messages" received by a node server meet a preset "secondary report condition", the node server generates a "secondary report message". The "secondary report condition" generally includes that the number of "first report messages" received reaches a threshold (for example, exceeding a specific proportion of the total number of system nodes), and both "first binary value" and "second binary value" are included in these "first report messages" (indicating a disagreement among nodes). In addition, the "secondary report condition" may also include that the "first report value" previously broadcast by the node server itself is inconsistent with a system-preset "common binary value". When these conditions are met, the node server generates a "secondary report message" according to the "common binary value", where the "secondary report value" is also a binary value and generally is opposite to the "first report value" or directly equal to the "common binary value", depending on the preset rules. After generating the "secondary report message", the node server broadcasts it in the distributed system.

[0098] Please refer to Figure 4 , in some embodiments, the distributed system further includes a randomly generated common binary value, and step 103 may include, but is not limited to, steps 401 to 402.

[0099] Step 401, for each node server, if the node server receives a target number of first report messages, and both the first binary value and the second binary value are included in the received first report messages, and the first report value broadcast by the node server is different from the common binary value, then generate a secondary report message according to the common binary value.

[0100] Step 402, broadcast the secondary report message in the distributed system.

[0101] In step 401 of some embodiments, each node server continuously receives "first report messages" broadcast from other node servers. When the number of "first report messages" received by a node server reaches the "target number", and both the "first binary value" and the "second binary value" are included in the received "first report messages", this means that there is a disagreement among the nodes regarding whether to process the current task request. At this time, in order to break the deadlock and promote the consensus process, the node server will further check whether the "first report value" it broadcast previously is the same as the "common binary value". This "common binary value" is a random value (0 or 1) pre-generated in the distributed system and known to all nodes. It may be different in each round of consensus negotiation and can be set to 1 in the first round of consensus negotiation. If the node server finds that the "first report value" it broadcast previously is different from the current "common binary value", then it will generate a "second report message". The generation of the "second report message" is based on the "common binary value", and its purpose is to try to change its position in order to reach an agreement with the majority opinion or a certain random trend in the system.

[0102] In step 402 of some embodiments, the node server broadcasts the "second report message" generated in step 401 in the distributed system. The "second report message" contains a "second report value", which can be the "first binary value" or the "second binary value", depending on the "common binary value" in step 401. By broadcasting the "second report message", the node server informs all other node servers in the system of its updated position (which may be different from the previous "first report value"), thus providing new information for further consensus negotiation.

[0103] Exemplarily, a distributed system has 5 nodes (n = 5) and the maximum number of fault-tolerant nodes is 1 (f = 1), so the "target number" is 4. Assume that the "common binary value" for the current round is 1. A node server (such as node A) receives 4 "first report messages", 2 of which contain the "first binary value" (1) and 2 contain the "second binary value" (0). At the same time, the "first report value" previously broadcast by node A itself is 0. Since the number of "first report messages" received by node A reaches the "target number" (4), and both 0 and 1 are included, and the "first report value" (9) of node A itself is different from the "common binary value" (1), node A will generate a "second report message" in which the "second report value" is 1 (the same as the "common binary value"). Then, node A broadcasts this "second report message" to all other nodes.

[0104] Through steps 401 to 402, in this embodiment, by introducing the "secondary report message" and "common binary value" mechanisms, the problem of differences in opinions that may occur in the "first report" stage is effectively solved. When there are different opinions among nodes, the "common binary value" provides a coordination factor, prompting some nodes to adjust their positions according to this random factor, thereby increasing the possibility of reaching a consensus. It is required that the node server generates a "secondary report message" only when its "first report value" is different from the "common binary value". This design avoids unnecessary changes in positions and reduces the overhead of message transmission. At the same time, since the "secondary report value" is the same as the "common binary value", this actually makes the node server move closer to the trend represented by the "common binary value", helping the system converge to a consistent state faster. By broadcasting the "secondary report message", the node server notifies all other nodes of its updated position, providing more accurate information for the subsequent voting stage, helping to reach a consensus faster, and improving the efficiency and reliability of the consensus algorithm.

[0105] Among them, the formats of the "first report message" and the "secondary report message" are , where b is the report value, r is the current round, report indicates that this is a report message, and here tag represents the number of values reported before this report in this round. A node can report at most twice, so . Specifically, tag = 0 indicates that this is the first report of this node in round r, and tag = 1 indicates that this is the second report of this node in round r.

[0106] In step 104 of some embodiments, each node server comprehensively analyzes all the "first report messages" and "secondary report messages" it receives, and generates a "current voting message" based on this information. The "current voting message" contains a "voting value", which represents the current inclination of the node server towards the task request, that is, support (such as "1") or opposition / skip (such as "0"). In the process of generating the "current voting message", the node server also utilizes the concept of the "implied report message". Specifically, if a node server broadcasts a "secondary report message", it can be considered that it implicitly also sends an "implied report message" opposite to the "secondary report value". The node server will comprehensively consider the "first report message", the "secondary report message", and the "implied report message" to determine the "voting value" of the "current voting message". After generating the "current voting message", each node server broadcasts it in the distributed system.

[0107] Please refer to Figure 5, in some embodiments, the voting message includes a first voting message and a second voting message, and step 104 may include, but is not limited to, steps 501 to 503.

[0108] Step 501, for each node server, generate an implicit report message according to the received second report message and the first report message.

[0109] Step 502, if the sum of the number of the first report messages and the implicit report messages reaches the target number, and the corresponding implicit report value is the same as the first report value, then broadcast the first voting message in the distributed system.

[0110] Step 503, if the sum of the number of the first report messages and the second report messages reaches the target number, and the corresponding first report value is the same as the second report value, then broadcast the second voting message in the distributed system.

[0111] In step 501 of some embodiments, each node server generates an "implicit report message" according to the received "first report message" and "second report message". The "implicit report message" is not an actually received message, but a virtual concept used to assist the node server in making voting decisions. Each node server generates an "implicit report message" for other node servers according to the received "second report message", and its value is opposite to the "second report value" actually sent by this node server. For example, if node A receives a message with a "second report value" of 1 from node B, then node A generates an "implicit report message" with an "implicit report value" of 0 for node B. The purpose of introducing the "implicit report message" is to simulate possible network delays or message losses in some cases. For example, node B may have changed its mind and sent a message with a "second report value" of 0, but due to network delay, node A has not received the "first report value" of 1. At this time, the "implicit report message" mechanism can help node A judge the "first report value" of node B, so as to make a more accurate voting decision.

[0112] In step 502 of some embodiments, each node server counts the number of "first report messages" and "implied report messages" it receives and checks whether their values meet specific conditions. If the total number of "first report messages" and "implied report messages" received by a node server reaches the "target number" (n - f), and the corresponding "first report values" and "implied report values" of these messages are the same (for example, both are 1), then the node server broadcasts a "first vote message" in the distributed system. The "first vote message" contains a "vote value" that is equal to the corresponding "first report value". For example, if the "first report value" and "implied report value" that meet the voting conditions are both 1, then the "vote value" of the broadcast "first vote message" is also 1.

[0113] In step 503 of some embodiments, each node server counts the number of "first report messages" and "second report messages" it receives and checks whether their values meet specific conditions. If the total number of "first report messages" and "second report messages" received by a node server reaches the "target number" (n - f), and the corresponding "first report values" and "second report values" of these messages are the same (for example, both are 0), then the node server broadcasts a "second vote message" in the distributed system. The "second vote message" contains a "vote value" that is equal to the corresponding "second report value". For example, if the "first report value" and "second report value" that meet the voting conditions are both 0, then the "vote value" of the broadcast "second vote message" is also 0.

[0114] For example: Suppose a distributed system has 5 nodes and the target number is 4. Node A receives messages with a "first report value" of 1 from nodes B, C, and D, and a "second report value" of 1 from node E. At the same time, node A generates an "implied report message" with an "implied report value" of 0 for node E. At this time, the total number of "first report messages" and "implied report messages" received by node A is 4, reaching the target number, but the corresponding values are not completely the same (1 for B, C, D, and 0 for E), so it does not meet the conditions of step 502 and will not broadcast the "first vote message". On the other hand, the total number of "first report messages" and "second report messages" received by node A is also 4, reaching the target number, and the corresponding values are both 1, so it meets the conditions of step 503, and node A will broadcast a "second vote message" with a "vote value" of 1.

[0115] In some embodiments, the formats of the "first vote message" and the "second vote message" are , where b is the voting value, r is the current round, vote indicates that this is a voting message, tag = 0 indicates that this is the first voting message of this node in round r, and tag = 1 indicates that this is the second voting message of this node in round r.

[0116] The overall technical effect of the above steps 501 to 503 is that by combining the "first report message", "second report message" and "implied report message", as well as the "target quantity" mechanism, reliable voting for task requests is achieved. Introducing the "implied report message" mechanism can effectively handle network delays or message losses and improve the accuracy of voting. Voting based on the "first report value" and "second report value" respectively can more finely control the consensus process and avoid affecting the decision-making of the entire system due to errors of individual nodes. By requiring the "target quantity" to be reached for voting, the reliability and consistency of the voting results are ensured. Even in the case of partial node failures, the system can still operate normally and reach a consensus. This multi-stage voting mechanism effectively improves the fault tolerance of the distributed system in an asynchronous network environment and ensures the reliability and consistency of task request processing.

[0117] In step 105 of some embodiments, each node server continuously collects the "first report message", "second report message" and "voting message" (including "first voting message" and "second voting message") from other node servers. Based on this collected information, each node server independently calculates a "current consensus result". This "current consensus result" indicates whether the consensus negotiation in the current round has reached an agreement, that is, whether most node servers have reached an agreement on the processing method (submit or skip) of the task request.

[0118] Please refer to Figure 6 , in some embodiments, step 105 may include, but is not limited to, step 601.

[0119] Step 601, for each node server, when the number of first voting messages received by the node server that contain the same voting value reaches the target quantity, or the sum of the number of implied report messages and first report messages received reaches the target quantity, and the corresponding implied report value and first report value are both equal to the public binary value of the current round, or a first voting message is received and the voting value is equal to the public binary value of the current round, generate a consensus result indicating that consensus has been reached according to the voting value or the first report value, otherwise enter the next round.

[0120] In step 601 of some embodiments, each node server continuously collects voting messages from other node servers (including "initial voting messages" and "secondary voting messages"), as well as previously collected "initial report messages" and "implied report messages" generated based on "secondary report messages". Based on this information, the node server determines whether the conditions for reaching a consensus have been met and generates a "consensus result" accordingly. Specifically, there are three cases that can trigger the node server to generate a "consensus result":

[0121] Condition 1: Receiving enough identical "initial voting messages": If the number of "initial voting messages" containing the same "voting value" received by a node server reaches the "target number" (n - f), then the node server considers that a consensus has been reached. At this time, the "consensus result" is this identical "voting value". For example, if the "target number" is 4 and a node server receives 4 "initial voting messages" with a "voting value" of 1, then the "consensus result" it generates is 1.

[0122] Condition 2: The "initial report messages" and "implied report messages" meet specific conditions: If the total number of "initial report messages" and "implied report messages" received by a node server reaches the "target number" (n - f), and the corresponding "initial report values" and "implied report values" of these messages are all equal to the "common binary value" of the current round, then the node server also considers that a consensus has been reached. At this time, the "consensus result" is this "common binary value". For example, if the "target number" is 4 and the "common binary value" of the current round is 0, and a node server receives 3 messages with an "initial report value" of 0 and 1 message with an "implied report value" of 0 (which means it received a "secondary report value" of 1), then the "consensus result" it generates is 0.

[0123] Condition 3: Receiving any "initial voting message" that is the same as the "common binary value": If a node server receives any "initial voting message" and the "voting value" of this message is equal to the "common binary value" of the current round, then the node server also considers that a consensus has been reached. At this time, the "consensus result" is this "common binary value". This condition is designed to accelerate the reaching of a consensus in certain cases. Even if not enough voting messages are received, as long as one node clearly expresses an opinion consistent with the "common binary value", this opinion can be directly adopted as the consensus result.

[0124] If none of the above three conditions are met, the node server considers that the consensus has not been reached in the current round and needs to enter the next round of negotiation.

[0125] Exemplarily, a distributed system has 5 nodes (n = 5) and the maximum number of fault - tolerant nodes is 1 (f = 1). Thus, the "target quantity" is 4. The "common binary value" for the current round is 1.

[0126] Case 1: Node A receives 4 "first - vote messages" where the "vote values" are all 1. Condition 1 is satisfied, and Node A generates a "consensus result" of 1.

[0127] Case 2: Node A receives 3 messages with "first - reported values" of 1 and 1 message with an "implied reported value" of 1 (from a message with a "second - reported value" of 0). The values of these 4 messages are all equal to the "common binary value" 1. Condition 2 is satisfied, and Node A generates a "consensus result" of 1.

[0128] Case 3: Node A receives 1 "first - vote message" with a "vote value" of 1, which is equal to the "common binary value" 1. Condition 3 is satisfied, and Node C generates a "consensus result" of 1.

[0129] Case 4: Node A receives 2 "first - vote messages" with "vote values" of 0 and 1 respectively. At the same time, it also receives 1 message with a "first - reported value" of 0 and 1 message with an "implied reported value" of 0. Among these 4 messages, only 3 have values the same as the "common binary value" 1, so Condition 2 is not satisfied. Also, not enough identical "first - vote messages" are received, so Condition 1 is not satisfied. And no "first - vote message" is received that is the same as the "common binary value", so Condition 3 is not satisfied. Therefore, Node A believes that no consensus is reached in the current round and needs to enter the next round.

[0130] In some embodiments, when a node server fails to reach a consensus in a certain round of negotiation, it will enter the next round of negotiation. Before entering the new round, the node server first needs to update its internal state to prepare for the new round of negotiation. This state update process mainly includes two key steps: obtaining the "common binary value" of the new round, and updating its "first reported value" according to the voting situation of the previous round. The "common binary value" is a random value (0 or 1) that changes in each round of negotiation. It is generated by a deterministic random number generator, and all node servers have the same "common binary value" in the same round. After obtaining the new "common binary value", the node server will update its "first reported value" according to the voting messages collected in the previous round. The "first reported value" is the value included in the "first reported message" broadcast by the node server in the new round of negotiation, which reflects the initial attitude of the node server towards the task request. The update rule takes into account two situations of the voting messages in the previous round: if all the voting messages received in the previous round are "second voting messages", it means that the voting in the previous round was mainly based on the "second reported messages". The node server will check the "voting values" of these voting messages. If all the "voting values" are the "common binary value" of the previous round, then the "first reported value" of the node server in the new round will be set to the "common binary value" of the previous round; if the voting messages received in the previous round include the "first reported messages", then the "first reported value" of the node server in the new round will be set to the first reported value in the "first reported message", and enter the next round of consensus negotiation loop.

[0131] Exemplarily, the "common binary value" broadcast by a node server in the first round of negotiation is 1. At the end of the first round, this node server does not reach a consensus. Before entering the second round, it first obtains the "common binary value" of the second round, assumed to be 1. Then, it checks the voting messages received in the previous round. If it finds that all the voting messages are "second voting messages" and the voting values are all 1, then its "first reported value" in the second round will be set to 1. If it finds that the voting messages received in the previous round include the "first voting messages", then the "first reported value" in the second round will be the same as the "first voting message" received in the previous round. After determining the "first reported value", the node server will generate and broadcast a new "first reported message", and start receiving and processing messages from other nodes to participate in the new round of consensus negotiation.

[0132] In step 106 of some embodiments, each node server determines whether the "current consensus result" calculated in step 105 meets the pre-set "consensus condition". The "consensus condition" generally includes receiving a sufficient number of "vote messages" with the same "vote value", or the received "report messages" (including "first report message", "second report message" and "implied report message") meeting specific combination and quantity requirements and being related to the "common binary value". If the "consensus condition" is met, it is considered that consensus has been reached, and the node server will decide how to process the original task request according to the "current consensus result": if the "consensus result" indicates "submit" (for example, the consensus value is "1"), the task request is executed; if the "consensus result" indicates "skip" (for example, the consensus value is "0"), the task request is ignored. If the "consensus condition" is not met, the consensus process will enter the next round, repeating similar processes of reporting, voting and result calculation until consensus is reached or the preset maximum round limit is reached.

[0133] Please refer to Figure 7 , in some embodiments, step 106 may include, but is not limited to, steps 701 to 702.

[0134] Step 701, when the consensus result includes a first binary value, perform a submission process on the task request.

[0135] Step 702, when the consensus result includes a second binary value, perform a skip process on the task request.

[0136] In step 701 of some embodiments, after a series of consensus negotiation processes, the node server will finally obtain a "consensus result". This "consensus result" is a binary value used to indicate how the node server should process the original task request. If the "consensus result" contains the "first binary value" (usually agreed as the number "1"), then the node server will perform a "submission process" on the task request. The "submission process" means that the node server will execute the operations specified in the task request, such as executing a piece of code, updating database records, writing data to a file, etc.

[0137] In step 702 of some embodiments, if the "consensus result" obtained by the node server contains the "second binary value" (usually agreed as the number "0"), then the node server will perform a "skip process" on the task request. The "skip process" means that the node server will ignore this task request and will not execute the operations specified therein. Even if the node server receives this task request again later (for example, due to network latency, the request just arrives), it will directly ignore it and will not repeat the processing.

[0138] Please refer to Figure 8, in some embodiments, when the task request is skipped from processing or the consensus result indicates that no consensus has been reached, steps 801 to 805 are further included.

[0139] Step 801, for each node server, if the node server receives a task consensus request message but has not sent a first report message or a second report message or a first vote message or a second vote message containing the first binary value, then broadcast a first confirmation message in the distributed system according to the task request sequence number.

[0140] Step 802, for each node server, if the sum of the number of first confirmation messages received and the first report messages with the first binary value as the first report value and the implicit report messages with the first binary value as the implicit report value reaches the target number, or, in response to the server receiving a first vote message or a second vote message with a vote value of the first binary value, determine the task request as a stable state.

[0141] Step 803, for each node server, reselect a sequence number with the smallest sequence and not used in the request sequence set as the second request sequence number of the task request.

[0142] Step 804, generate a request retransmission message according to the task request sequence number and the second request sequence number, and broadcast the request retransmission message in the distributed system.

[0143] Step 805, for each node server, in response to receiving the request retransmission message, perform a submission process on the task request according to the task request sequence number.

[0144] In step 801 of some embodiments, if a node server receives a "task consensus request message" but during the previous consensus negotiation process, this node server has not sent any message indicating "submission", that is, has not sent a "first report message", "second report message", "first vote message" or "second vote message" containing the "first binary value", then this node server will take a special action: it will broadcast a "first confirmation message" (ACK message) in the distributed system according to the received "task request sequence number". The role of the "first confirmation message" is to indicate to other node servers in the system that this task request has been received, but has not expressed an opinion in support of submission. This usually occurs when the node server misses participating in the consensus negotiation due to network latency, high self-load, etc., or it has always been inclined to skip this request.

[0145] In step 802 of some embodiments, each node server continuously collects messages from other node servers, including "First Confirmation Message", "First Report Message", "Implicit Report Message", "First Vote Message", and "Second Vote Message". When a node server discovers either of the following two situations, it marks the corresponding task request as "stable state":

[0146] 1. The sum of the number of received "First Confirmation Messages", the number of "First Report Messages" with "First Report Value" being "First Binary Value", and the number of "Implicit Report Messages" with "Implicit Report Value" being "First Binary Value" reaches the "target quantity" (n - f, where n is the total number of nodes and f is the maximum number of fault - tolerant nodes).

[0147] 2. It receives any "First Vote Message" or "Second Vote Message" with "Vote Value" being "First Binary Value".

[0148] The stable state indicates that the task request has been correctly received by a sufficient number of node servers (at least n - f). Even if the previous consensus negotiation did not successfully submit the request, it can now be safely considered for re - proposal without worrying about data inconsistency or duplicate execution issues.

[0149] In step 803 of some embodiments, if a task request is marked as "stable state", but the result of the previous consensus negotiation was to skip the request (or no consensus was reached, i.e., no resolution was output), then the node server attempts to re - propose this request. It re - selects a smallest unused sequence number in the "request sequence set" it maintains as the "Second Request Sequence Number" of this task request. This "Second Request Sequence Number" is used to identify the re - proposed request, while the original "Task Request Sequence Number" is used to associate with the original task request.

[0150] In step 804 of some embodiments, the proposing node generates a "Request Re - proposal Message" based on the original "Task Request Sequence Number" and the new "Second Request Sequence Number" and broadcasts it in the distributed system. The role of the "Request Re - proposal Message" is to announce to all node servers: I am re - proposing a task request that may have been skipped or not reached consensus before. Please reconsider whether to submit it based on the new FTBA instance. Since the request is already in the "stable state", the "Request Re - proposal Message" only needs to contain the original "Task Request Sequence Number" and the "Second Request Sequence Number", and does not need to contain the full content of the task request. In addition, to improve efficiency, when the proposing node submits a new request with a new sequence number assigned by itself, it can attach the "Request Re - proposal Message" to the new request and send them together.

[0151] In step 805 of some embodiments, after any node server receives a "request re-submission message", it will first check whether the task request corresponding to the original "task request sequence number" included in the message has been processed (i.e., whether it has been executed). If it has not been processed yet, then the node server will perform "submission processing" on the task request according to the original "task request sequence number", that is, execute the operations specified in the task request. Due to the uniqueness of the "task request sequence number", even if multiple node servers re-submit the same task request simultaneously, only one node server will successfully submit it, thus avoiding duplicate execution.

[0152] The overall technical effect of the above steps 801 to 805 is that by introducing a "fast re-proposal mechanism", the problem that task requests may be accidentally skipped or fail to reach a consensus in a timely manner during the FTBA consensus negotiation process is effectively solved. Even if a task request fails to be successfully submitted in the initial consensus negotiation due to network latency, node failures, or other reasons, as long as the request is finally correctly received by a sufficient number of node servers (reaching a "stable state"), it can be processed by re-proposing, thus avoiding unnecessary waiting and resource waste. The "first confirmation message" is used to confirm that the node has received the request but has not participated in the previous consensus. The determination of the "stable state" ensures that the re-submitted request is safe and will not cause data inconsistency or duplicate execution. The "request re-submission message" provides a simple and efficient way to re-trigger the consensus negotiation for the task request, and further improves the processing efficiency by associating with the sequence number of the new request.

[0153] Please refer to Figure 9 , the present invention adopts a log-based state machine replication (SMR) design. Each node server maintains an identical log, which consists of multiple "slots". Each slot is used to store a client request that has reached a consensus. The goal of the present invention is to ensure that the logs of all normally operating node servers are exactly the same in content and order. To achieve this goal, the present invention adopts a strategy of circularly allocating log slots. Specifically, log slot i is pre-allocated to node server R (imodn), where n is the total number of node servers in the system (in this case, n=3), and mod represents the modulo operation. This means that node R0 is responsible for making requests for slots 0, 3, 6, ..., node R1 is responsible for making requests for slots 1, 4, 7, ..., and node R2 is responsible for making requests for slots 2, 5, 8, .... This allocation method ensures that each node server has the opportunity to make requests and the order in which the requests are made is determined. When a node server (such as R0) receives a request from a client, it assigns a sequence number to the request (i.e., selects the next slot it is responsible for) and broadcasts the request to other node servers. After receiving the request, other node servers will start a consensus negotiation instance (i.e., FTBA in the figure) to reach a consensus on whether to submit or skip the request. The series of boxes above each node server represent the consensus negotiation instances started for different requests. The arrows indicate the direction of message transmission. For example, after node R0 broadcasts "Request 0", all node servers will start a consensus negotiation instance to reach a consensus on "Request 0". The output result of the consensus negotiation instance ("output 1" means submission, "output 0" means skip) determines whether the request will be stored in the log. Figure 9 The log content is shown below. It can be seen that the consensus negotiation instances corresponding to "Request 0" and "Request 1" both output 1, so the two requests are submitted and stored in slots 0 and 1 of the log. The consensus negotiation instance corresponding to "Request 2" outputs 0, so the request is skipped and no request is stored in slot 2 of the log. Subsequent slots in the log are similar, and whether to store a request is determined based on the output results of the consensus negotiation instance.

[0154] The distributed request processing method based on multi-round message exchange proposed in this application. The node server first broadcasts a task consensus request message, and then gradually reaches a consensus through multi-round message exchanges (first report message, second report message, voting message). By introducing a two-stage reporting mechanism, the node server will not randomly change its reported value. Instead, only when the received first report message meets the preset reporting conditions, the node server will trigger the broadcast of the second report message and may update its reported value in the second report. This design effectively restricts the conditions for the node server to change the proposal, preventing the delay of the consensus process caused by easily changing the proposed value. In addition, in the voting stage, the node server will comprehensively consider the received first report message and second report message for voting, and in each round of consensus result output stage, the node server will comprehensively consider all the received messages (first report message, second report message, and voting message) to make a decision. This mechanism of comprehensively considering the first report, second report, and voting message further enhances the reliability and stability of the consensus result, avoiding the dominance of a single message type or a small number of node servers. When the consensus result indicates that a consensus has been reached, the request can be processed according to the consensus result. Different from the synchronous / semi-synchronous consensus algorithms that rely on the upper bound of network latency, this method belongs to an asynchronous consensus algorithm and does not rely on any latency assumptions, making it more suitable for the actual network environment. Through the above two-stage reporting mechanism with constraints and the comprehensive decision-making mechanism, compared with the existing asynchronous consensus algorithms (in which nodes may change their proposals more frequently), this method significantly improves the stability of the consensus process, reduces unnecessary proposal changes and communication overhead, and reduces the latency of reaching a consensus while ensuring the correctness of the consensus. In summary, the method proposed in this application can improve the efficiency of reaching a consensus on task request processing in a distributed system.

[0155] Please refer to Figure 10 , this application embodiment also provides a distributed request processing device based on multi-round message exchange, which can implement the above-mentioned distributed request processing method based on multi-round message exchange, including:

[0156] The first broadcast module is used to, in response to any one of the node servers obtaining a task request, generate a task consensus request message according to the task request, and broadcast the task consensus request message in the distributed system;

[0157] The second broadcast module is used to, for each of the node servers, determine the reception status of the task consensus request message, generate a first report message based on the reception status, and broadcast the first report message in the distributed system;

[0158] A third broadcast module, which is configured to, for each of the node servers, in response to the received first report message satisfying a preset secondary report condition, generate a secondary report message based on the first report message, and broadcast the secondary report message in the distributed system;

[0159] A fourth broadcast module, which is configured to, for each of the node servers, generate a current voting message according to the first report message and the secondary report message, and broadcast the current voting message in the distributed system;

[0160] A consensus module, which is configured to, for each of the node servers, obtain a current consensus result according to the first report message, the secondary report message, and the voting message;

[0161] A processing module, which is configured to, in response to the consensus result satisfying a preset consensus condition, perform task request processing on the task request according to the current consensus result.

[0162] In a third aspect, an embodiment of the present application provides an electronic device, including: a memory and a processor, where the memory stores a computer program, and when the processor executes the computer program, the distributed request processing method based on multi-round message exchange according to any one of the embodiments in the first aspect of the present application is implemented.

[0163] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, where the storage medium stores a program, and when the program is executed by a processor, the distributed request processing method based on multi-round message exchange according to any one of the embodiments in the first aspect of the present application is implemented.

[0164] Please refer to Figure 11 , Figure 11 , which schematically shows the hardware structure of an electronic device in another embodiment. The electronic device includes:

[0165] A processor 1101, which can be implemented in a general-purpose CPU (Central Processing Unit, central processor), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, etc., and is configured to execute relevant programs to implement the technical solutions provided by the embodiments of the present application;

[0166] The memory 1102 can be implemented in the form of a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM), etc. The memory 1102 can store an operating system and other application programs. When implementing the technical solutions provided in the embodiments of this specification through software or firmware, the relevant program codes are stored in the memory 1102 and are called by the processor 1101 to execute the distributed request processing method based on multi-round message exchange in the embodiments of this application;

[0167] The input / output interface 1103 is used to implement information input and output;

[0168] The communication interface 1104 is used to implement communication and interaction between this device and other devices. It can communicate through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.);

[0169] The bus 1105 transmits information between the various components of the device (such as the processor 1101, the memory 1102, the input / output interface 1103, and the communication interface 1104);

[0170] Among them, the processor 1101, the memory 1102, the input / output interface 1103, and the communication interface 1104 are communicatively connected to each other inside the device through the bus 1105.

[0171] The embodiments of this application also provide a computer-readable storage medium. The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, it implements the above-mentioned distributed request processing method based on multi-round message exchange.

[0172] As a non-transitory computer-readable storage medium, the memory can be used to store non-transitory software programs and non-transitory computer-executable programs. In addition, the memory can include high-speed random access memory, and can also include non-transitory memory, such as at least one magnetic disk storage device, a flash memory device, or other non-transitory solid-state storage devices. In some embodiments, the memory optionally includes a memory remotely provided relative to the processor, and these remote memories can be connected to the processor through a network. Examples of the above-mentioned network include but are not limited to the Internet, an enterprise intranet, a local area network, a mobile communication network, and combinations thereof.

[0173] The embodiments described in the embodiments of the present application are to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation to the technical solutions provided by the embodiments of the present application. As those skilled in the art can know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of the present application are also applicable to similar technical problems.

[0174] Those skilled in the art can understand that the technical solutions shown in the figures do not constitute a limitation to the embodiments of the present application, and may include more or fewer steps than those shown in the figures, or combine certain steps, or different steps.

[0175] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separated, that is, they may be located in one place, or may be distributed to multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0176] Those of ordinary skill in the art can understand that all or some of the steps in the methods disclosed above, and the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, and their appropriate combinations.

[0177] The terms "first", "second", "third", "fourth", etc. (if any) in the specification of the present application and the above-mentioned drawings are used to distinguish similar objects, and do not have to be used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances, so that the embodiments of the present application described here can be implemented in an order other than those illustrated or described here. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units does not have to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these processes, methods, products, or devices.

[0178] It should be understood that in this application, "at least one (item)" means one or more, and "a plurality" means two or more. "And / or" is used to describe the association relationship of associated objects, indicating that there can be three relationships. For example, "A and / or B" can mean: only A exists, only B exists, and both A and B exist at the same time. Among them, A and B can be singular or plural. The character " / " generally indicates that the associated objects before and after are in an "or" relationship. "At least one (item) of the following" or its similar expressions refer to any combination of these items, including any combination of single items (items) or plural items (items). For example, at least one (one) of a, b, or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0179] In several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the above-mentioned unit division is only a logical function division. In actual implementation, there can be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed coupling or direct coupling or communication connection between each other can be through some interfaces. The indirect coupling or communication connection of devices or units can be in electrical, mechanical or other forms.

[0180] The units described above as separate components may or may not be physically separated. The components displayed as units may or may not be physical units, that is, they can be located in one place, or can be distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0181] In addition, each functional unit in various embodiments of this application can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of a software functional unit.

[0182] When the integrated unit 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 such understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods of various embodiments of this application. The aforementioned storage medium includes: various media that can store programs such as USB flash drives, mobile hard disks, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical discs.

[0183] The preferred embodiments of the embodiments of this application have been described above with reference to the accompanying drawings, and thus do not limit the scope of rights of the embodiments of this application. Any modifications, equivalent replacements, and improvements made by those skilled in the art without departing from the scope and essence of the embodiments of this application shall be within the scope of rights of the embodiments of this application.

Claims

1. A distributed request processing method based on multi-round message exchange, characterized in that, Applied to a distributed system, the distributed system includes multiple node servers, and the method includes: In response to any one of the node servers obtaining a task request, generating a task consensus request message according to the task request, and broadcasting the task consensus request message in the distributed system; For each of the node servers, determining the reception status of the task consensus request message, generating a first report message based on the reception status, and broadcasting the first report message in the distributed system; For each of the node servers, in response to the received first report message satisfying a preset secondary report condition, generating a secondary report message based on the first report message, and broadcasting the secondary report message in the distributed system; For each of the node servers, generating a current vote message according to the first report message and the secondary report message, and broadcasting the current vote message in the distributed system; For each of the node servers, obtaining a current consensus result according to the first report message, the secondary report message, and the vote message; In response to the consensus result satisfying a preset consensus condition, performing task request processing on the task request according to the current consensus result.

2. The distributed request processing method based on multi-round message exchange according to claim 1, characterized in that, The step of "In response to any one of the node servers obtaining a task request, generating a task consensus request message according to the task request, and broadcasting the task consensus request message in the distributed system" includes: Obtaining a task request; Selecting, in a pre-configured request sequence set, the sequence number with the smallest sequence and not yet used as the task request sequence number of the task request; Generating a task consensus request message according to the task request and the task request sequence number; Broadcasting the task consensus request message in the distributed system.

3. The distributed request processing method based on multi-round message exchange according to claim 2, wherein The first report message includes a first report value, and the first report value is equal to a first binary value or a second binary value. The step of "For each of the node servers, determining the reception status of the task consensus request message, generating a first report message based on the reception status, and broadcasting the first report message in the distributed system" includes: For each of the node servers, if the reception status is received, broadcasting the first report message including the first binary value in the distributed system; For each of the node servers, if the reception status is not received and there are a target number of other task requests with sequence numbers greater than the task request sequence number that have been processed, broadcasting the first report message including the second binary value in the distributed system.

4. The distributed request processing method based on multi-round message exchange according to claim 3, wherein The distributed system further includes a randomly generated common binary value. The step of "For each of the node servers, in response to the received first report message satisfying a preset secondary report condition, generating a secondary report message based on the first report message, and broadcasting the secondary report message in the distributed system" includes: For each of the node servers, if the node server receives the target number of the first report messages, and the received first report messages contain both the first binary value and the second binary value, and the first report value broadcast by the node server is different from the common binary value, then generate a second report message according to the common binary value; Broadcast the second report message in the distributed system; wherein, the second report message includes a second report value, and the second report value is equal to the first binary value or the second binary value.

5. The distributed request processing method based on multi-round message exchange according to claim 4, wherein The voting message includes a first voting message and a second voting message. For each of the node servers, generating a current voting message according to the first report message and the second report message and broadcasting the current voting message in the distributed system includes: For each of the node servers, generate an implicit report message according to the received second report message and the first report message; wherein, the implicit report value of the implicit report message is different from the second report value of the second report message; If the sum of the numbers of the first report messages and the implicit report messages reaches the target number, and the corresponding implicit report values and the first report values are all the same, then broadcast a first voting message in the distributed system; wherein, the voting value of the first voting message is equal to the first report value; If the sum of the numbers of the first report messages and the second report messages reaches the target number, and the corresponding first report values and the second report values are all the same, then broadcast a second voting message in the distributed system; wherein, the voting value of the second voting message is equal to the second report value.

6. The distributed request processing method based on multi-round message exchange according to claim 5, wherein For each of the node servers, obtaining a current consensus result according to the first report message, the second report message and the voting message includes: For each of the node servers, when the node server receives the target number of the first voting messages containing the same voting value, or the sum of the numbers of the received implicit report messages and the first report messages reaches the target number, and the corresponding implicit report values and the first report values are both equal to the common binary value of the current round, or receives a first voting message and the voting value is equal to the common binary value of the current round, generate a consensus result for indicating reaching a consensus according to the voting value or the first report value, otherwise enter the next round.

7. The distributed request processing method based on multi-round message exchange according to claim 6, wherein In response to the consensus result satisfying a preset consensus condition, performing task request processing on the task request according to the current consensus result includes: In response to the consensus result including the first binary value, perform submission processing on the task request; In response to the consensus result including the second binary value, perform skip processing on the task request.

8. The distributed request processing method based on multi-round message exchange according to claim 7, wherein When the task request is skipped or the consensus result indicates that no consensus is reached, the method further includes: For each of the node servers, if the node server receives the task consensus request message but does not send the first report message or the second report message or the first vote message or the second vote message containing the first binary value, then broadcast a first confirmation message in the distributed system according to the task request sequence number; For each of the node servers, if the sum of the number of the first confirmation messages received and the first report messages with the first report value being the first binary value and the implicit report messages with the implicit report value being the first binary value reaches the target number, or in response to the server receiving a first vote message or a second vote message with the vote value being the first binary value, determine the task request as a stable state; For each of the node servers, reselect a sequence number with the smallest sequence and not used in the request sequence set as the second request sequence number of the task request; Generate a request retransmission message according to the task request sequence number and the second request sequence number, and broadcast the request retransmission message in the distributed system; For each of the node servers, in response to receiving the request retransmission message, perform a submission process on the task request according to the task request sequence number.

9. An electronic device, characterized in that, Including: A memory and a processor, where the memory stores a computer program, and when the processor executes the computer program, it implements the distributed request processing method based on multi-round message exchange according to any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The storage medium stores a program, and when the program is executed by the processor, it implements the distributed request processing method based on multi-round message exchange according to any one of claims 1 to 8.

Images