Distributed request processing method based on multi-round message exchange and related equipment

Abstract

The invention provides a distributed request processing method based on multi-round message exchange and related equipment, and the method comprises the steps: obtaining a task request in response to any node server, and broadcasting a task consensus request message according to the task request; for each node server, determining a receiving state of the task consensus request message, and broadcasting a first report message based on the receiving state; for each node server, in response to the received first report message meeting a preset secondary report condition, broadcasting a secondary report message based on the first report message; for each node server, broadcasting a current voting 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 voting message; and processing the task request according to the current consensus result in response to the consensus result meeting a preset consensus condition. The task request processing efficiency in the distributed system can be improved.

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 equipment. Background Art

[0002] Distributed systems provide high availability, scalability, and fault tolerance by distributing computing tasks to multiple nodes. In distributed systems, how to ensure data consistency between nodes is a core issue. Especially when 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 distributed systems. Currently, solutions to the distributed consensus problem include asynchronous consensus.

[0003] In related technologies, asynchronous consensus algorithms determine a binary value through multiple rounds of node interactions. In each round of node interaction, each node will first generate a suggested value. When enough nodes generate the same suggested value, the proposed value is determined based on this suggested value. In this process, the node suggested value is easily affected by a few abnormal nodes and changes frequently, which can easily cause high delays in task response and high resource consumption. Summary of the invention

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

[0005] To achieve the above-mentioned purpose, a first aspect of an embodiment of the present application proposes a distributed request processing method based on multi-round message exchange, which is applied to a distributed system, wherein the distributed system includes multiple node servers, and the method includes: In response to any of the node servers acquiring 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 a 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 second report condition, generating a second report message based on the first report message, and broadcasting the second report message in the distributed system; 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; 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; 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.

[0006] In some embodiments, in response to any of the node servers acquiring 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: Get task request; Selecting a sequence number with the smallest sequence and which has not been used from a pre-configured request sequence set as the task request sequence number of the task request; Generate a task consensus request message according to the task request and the task request sequence number; The task consensus request message is broadcasted in the distributed system.

[0007] In some embodiments, the first report message includes a first report value, the first report value is equal to a first binary value or a second binary value, and for each of the node servers, determining a 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 receiving 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 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, then the first report message containing the second binary value is broadcast in the distributed system.

[0008] In some embodiments, the distributed system further includes a randomly generated public binary value, wherein 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, comprises: For each of the node servers, if the node server receives the target number of first report messages, and the received first report message includes both the first binary value and the second binary value, and the first report value broadcast by the node server is different from the public binary value, then generating the second report message according to the public binary value; 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.

[0009] In some embodiments, the voting message includes a first voting message and a second voting message, and 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, comprises: For each of the node servers, an implicit report message is generated according to the received secondary 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 secondary report message; If the sum of the number of the first report message and the number of the implicit report message reaches the target number, and the corresponding implicit report value is the same as the first report value, 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; 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 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.

[0010] In some embodiments, for each of the node servers, obtaining the 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 number of first voting messages received by the node server containing the same voting value reaches the target number, or the sum of the number of the received implicit report messages and the first report messages reaches the target number, and the corresponding implicit report value and the first report value are equal to the common binary value of the current round, or a first voting message is received and the voting value is equal to the common binary value of the current round, the consensus result indicating that a consensus has been reached is generated according to the voting value or the first report value, otherwise it proceeds to the next round.

[0011] In some embodiments, 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, submitting the task request; In response to the consensus result including the second binary value, skipping processing of the task request.

[0012] In some embodiments, when the task request is skipped or the consensus result indicates that no consensus has been 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 voting message or the second voting message containing the first binary value, 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 first confirmation message received, the first report message whose first report value is the first binary value, and the implicit report message whose implicit report value is the first binary value reaches the target number, or in response to the server receiving the first voting message or the second voting message whose voting value is the first binary value, the task request is determined to be in a stable state; For each of the node servers, reselect a sequence number with the smallest sequence and which has not been used in the request sequence set as the second request sequence number of the task request; Generate a request re-assignment message according to the task request sequence number and the second request sequence number, and broadcast the request re-assignment message in the distributed system; For each of the node servers, in response to receiving the request resubmission message, the task request is submitted for processing according to the task request sequence number.

[0013] In a second aspect, an embodiment of the present application provides a distributed request processing device based on multi-round message exchange, including: A first broadcast module, configured to generate a task consensus request message according to the task request in response to any of the node servers obtaining the task request, and broadcast the task consensus request message in the distributed system; A second broadcast module is used to determine, for each of the node servers, a 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; A third broadcast module is configured to generate a secondary report message based on the first report message for each of the node servers in response to the received first report message satisfying a preset second report condition, and broadcast the second report message in the distributed system; a fourth broadcast module, configured to generate, for each of the node servers, 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; A consensus module, configured to obtain a current consensus result for each of the node servers according to the first report message, the second report message and the voting message; A processing module is used to perform task request processing on the task request according to the current consensus result in response to the consensus result satisfying a preset consensus condition.

[0014] In a third aspect, an embodiment of the present application provides an electronic device, comprising: a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, it implements a distributed request processing method based on multi-round message exchange as described in any one of the embodiments of the first aspect of the present application.

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

[0016] A distributed request processing method based on multi-round message exchange proposed in an embodiment of the present application is applied to a distributed system, wherein the distributed system includes multiple node servers, and 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 second report condition, generating a second report message based on the first report message, and broadcasting the second report message in the distributed system; for each node server, 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; for each node server, obtaining a current consensus result according to the first report message, the second report message and the voting message; in response to the consensus result meeting the preset consensus condition, performing task request processing on the task request according to the current consensus result.

[0017] The distributed request processing method based on multi-round message exchange proposed in this application, the node server first broadcasts the task consensus request message, and then gradually reaches a consensus through multiple rounds of message exchange (first report message, second report message, voting message). By introducing a two-stage reporting mechanism, the node server will not change its report value at will, but will only trigger the broadcast of the second report message when the first report message received meets the preset reporting conditions, and may update its own report value in the second report. This design effectively limits the conditions for the node server to change the proposal, and prevents the consensus process from being delayed due to the easy change of the proposal value. In addition, in the voting stage, the node server will comprehensively consider the first report message and the second report message received to vote, and in the consensus result output stage of each round, 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 messages further enhances the reliability and stability of the consensus result and avoids the dominance of a single message type or a few node servers. When the consensus result indicates that a consensus has been reached, the request can be processed according to the consensus result. Unlike synchronous / semi-synchronous consensus algorithms that rely on the upper bound of network delay, this method is an asynchronous consensus algorithm that does not rely on any delay assumptions and is more suitable for actual network environments. Through the above-mentioned two-stage reporting mechanism and comprehensive decision-making mechanism with constraints, 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 while ensuring the correctness of the consensus, reduces unnecessary proposal changes and communication overhead, and reduces the delay in reaching consensus. In summary, the method proposed in this application can improve the efficiency of reaching consensus on task request processing in distributed systems.

[0018] Other features and advantages of the present application will be described in the following description, and partly become apparent from the description, or understood by practicing the present application. The purpose and other advantages of the present application can be realized and obtained by the structures specifically pointed out in the description, claims and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 It is a flowchart of a distributed request processing method based on multi-round message exchange provided by an embodiment of the present application; Figure 2 It is a flowchart of a distributed request processing method based on multi-round message exchange provided by another embodiment of the present application; Figure 3 It is a flowchart of a distributed request processing method based on multi-round message exchange provided by another embodiment of the present application; Figure 4It is a flowchart of a distributed request processing method based on multi-round message exchange provided by another embodiment of the present application; Figure 5 It is a flowchart of a distributed request processing method based on multi-round message exchange provided by another embodiment of the present application; Figure 6 It is a flowchart of a distributed request processing method based on multi-round message exchange provided by another embodiment of the present application; Figure 7 It is a flowchart of a distributed request processing method based on multi-round message exchange provided by another embodiment of the present application; Figure 8 This is a schematic diagram of a framework for task request processing based on a distributed system provided by an embodiment of the present application; Fig. 9 It is a schematic diagram of a framework of a distributed request processing method based on multi-round message exchange provided by another embodiment of the present application; Fig.10 is a schematic diagram of a distributed request processing device based on multi-round message exchange provided by an embodiment of the present application; Fig.11 It is a schematic diagram of the hardware structure of the electronic device provided in the embodiment of the present application. DETAILED DESCRIPTION

[0020] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0021] It should be noted that, although the functional modules are divided in the device schematic diagram and the logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first", "second", etc. in the specification, claims and the above drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

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

[0023] In a distributed system, multiple independent nodes (servers) need to work together to maintain a globally consistent state. This state can be a database, a file system, or any data structure that needs to be shared. In order to achieve this consistency, the nodes need to reach a consensus on the execution order of a series of operations (for example, client requests). Assuming that a distributed system contains a total of n nodes, no more than (n-1) / 2 of these n nodes may crash (the present invention does not consider Byzantine errors, that is, nodes will only crash and will not intentionally forward wrong messages). Failed nodes are also called error nodes, and the remaining nodes are called correct nodes. Distributed consensus technology is designed to solve the problem of getting correct nodes to agree in such a system.

[0024] 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 delay, and consensus can only be reached when the upper bound exists. The asynchronous consensus algorithm does not rely on any delay assumption to reach consensus, so the asynchronous consensus algorithm is more suitable for actual network conditions. The present invention belongs to an asynchronous consensus algorithm. In an asynchronous network model, there is no upper bound on the message transmission delay between each correct node, but the messages sent between each correct node will eventually arrive. At present, the best solution under the asynchronous network model is the Bandle protocol. In Bandle, a fixed task request processing order (slot) is first assigned to each node. In this way, even if the order of requests received by the nodes is different, the global request order can be determined based on static sorting. Then, the 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 includes two phases: propose and suggest. Each node inputs a binary value (0 or 1) for a specific request sequence number (seq). 1 means that the node has received the request, and 0 means that the node has not received the request (or believes that the request should not be submitted). In the proposal phase, the node proposes a binary value based on the input value and broadcasts it to other nodes. When a node receives at least 2f+1 identical proposed values ​​(where f is the number of nodes that may fail in the system), the node proposes the value. When a node suggests or proposes a value, it will try to make a commitment to the value. Commitment means that the node will not change its proposal in this round. When a node finds that at least 2f+1 nodes have made a commitment to the same value, the node outputs the 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 suggestions, the node will immediately change its suggestion. This makes it difficult for nodes to make commitments, because commitments require nodes to not change their recommendations in this round, and even if a node has not changed its recommendations, it cannot make commitments if its recommendations are different from the proposed values. This further reduces the likelihood of nodes outputting in this round, resulting in multiple rounds of cycles required to achieve output, higher output delays, and greater resource consumption.

[0025] Based on this, the embodiment of the present application provides a distributed request processing method and related equipment based on multi-round message exchange, which can improve the efficiency of task request processing in a distributed system.

[0026] The distributed request processing method based on multi-round message exchange and related equipment provided in the embodiments of the present application are specifically illustrated 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.

[0027] 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, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, etc. 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 distributed computing environments, in which 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.

[0028] It should be noted that in each specific implementation of the present application, when it comes to the need to perform 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, and the collection, use, and processing of these data will comply with relevant laws, regulations, and standards. In addition, when the embodiment of the present application needs to obtain the user's sensitive personal information, the user's separate permission or consent will be obtained through a pop-up window or by jumping to a confirmation page. After clearly obtaining the user's separate permission or consent, the necessary user-related data for the normal operation of the embodiment of the present application will be obtained.

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

[0030] Step 101, in response to any node server obtaining a task request, a task consensus request message is generated according to the task request, and the task consensus request message is broadcast in the distributed system.

[0031] Step 102: for each node server, 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.

[0032] Step 103: for each node server, in response to the received first report message satisfying the preset second report condition, a second report message is generated based on the first report message, and the second report message is broadcasted in the distributed system.

[0033] Step 104: for each node server, 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.

[0034] Step 105, for each node server, obtain the current consensus result based on the first report message, the second report message and the voting message.

[0035] Step 106 , in response to the consensus result satisfying the preset consensus condition, executing task request processing on the task request according to the current consensus result.

[0036] In steps 101 to 104 shown in the embodiment of the present application, the node server first broadcasts the task consensus request message, and then gradually reaches a consensus through multiple rounds of message exchanges (first report message, second report message, voting message). By introducing a two-stage reporting mechanism, the node server will not change its report value at will, but will only trigger the broadcast of the second report message when the first report message received meets the preset reporting conditions, and may update its own report value in the second report. This design effectively limits the conditions for the node server to change the proposal, and prevents the consensus process from being delayed due to the easy change of the proposal value. In addition, in the voting stage, the node server will comprehensively consider the received first report message and the second report message for voting, and in the consensus result output stage of each round, 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 messages further enhances the reliability and stability of the consensus result and avoids the dominance of a single message type or a few node servers. When the consensus result indicates that a consensus has been reached, the request can be processed according to the consensus result. Unlike synchronous / semi-synchronous consensus algorithms that rely on the upper bound of network delay, this method is an asynchronous consensus algorithm that does not rely on any delay assumptions and is more suitable for actual network environments. Through the above-mentioned two-stage reporting mechanism and comprehensive decision-making mechanism with constraints, 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 while ensuring the correctness of the consensus, reduces unnecessary proposal changes and communication overhead, and reduces the delay in reaching consensus. In summary, the method proposed in this application can improve the efficiency of reaching consensus on task request processing in distributed systems.

[0037] In step 101 of some embodiments, any node server in the distributed system, such as a server called a "proposing node", receives a task request from a client (the request may be to perform a specific calculation, store data, etc.), and then starts the 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 detailed information about the task request and a unique identifier (such as a serial number) for identifying and tracking this specific task request in the entire distributed system. Subsequently, the proposing node will broadcast this "task consensus request message" to all other node servers in the distributed system, namely "consensus nodes", to notify them that there is a new task request that needs to be agreed upon.

[0038] See also Figure 2 In some embodiments, step 101 may include but is not limited to steps 201 to 204.

[0039] Step 201, obtaining a task request.

[0040] Step 202 : Select a sequence number with the smallest sequence and which has not been used from a pre-configured request sequence set as the task request sequence number of the task request.

[0041] Step 203: Generate a task consensus request message according to the task request and the task request sequence number.

[0042] Step 204: broadcast the task consensus request message in the distributed system.

[0043] In step 201 of some embodiments, a node server in a distributed system, which we call a "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 computing code, update a record in a database, or read a file stored in a distributed file system. The specific content and format of the task request will be defined according to the actual application scenario, but it will usually include necessary information such as the operation type and operation parameters.

[0044] 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 disorder or repeated execution due to network delays or node failures, it is proposed that the node will assign a globally unique "task request sequence number" to the received task request. 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 intervals. For example, assuming that there are 3 node servers in a distributed system (numbered 1, 2, and 3 respectively), 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 a smallest, unused sequence number from the sequence number range for which it is responsible as the "task request sequence number" for the task request.

[0045] 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 task request information and a unique sequence number.

[0046] 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 by "broadcasting". Broadcasting is a communication mechanism that ensures that the message is sent to every node in the system. By broadcasting the "task consensus request message", the proposing node formally starts the consensus negotiation cycle for the 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).

[0047] Through the above steps 201 to 204, the embodiment of the present application assigns a globally unique sequence number to each task request through a static sorting strategy, and distributes the task request information to all node servers in combination with a broadcast mechanism. Static sorting ensures the uniqueness and certainty of the sequence number, and avoids out-of-order or repeated execution of requests due to network delays or node failures. The broadcast mechanism ensures that all node servers can obtain the task request information in a timely manner, thereby participating in the consensus negotiation. These steps together ensure that the distributed system can maintain consistency and reliability in the processing of task requests in an asynchronous network environment.

[0048] In step 102 of some embodiments, each node server in the distributed system, whether it is the initial proposing node or other consensus nodes, will check whether it has received the "task consensus request message" broadcast in step 101. The "receiving status" here refers to whether the node server has successfully received and parsed the message. Based on this receiving status, each node server will independently generate a "first report message". The "first report message" contains a key "first report value", which is a binary value. Usually, a "first binary value" (such as a logical value of "1") is used to indicate that the task request has been received, and a "second binary value" (such as a logical value of "0") is used to indicate that the task request has not been received or the request is preferred to be skipped. After generating the "first report message", each node server will broadcast it in the distributed system.

[0049] See also Figure 3 In some embodiments, the first report message includes a first report value, and the first report value is equal to the first binary value or the second binary value. Step 102 may include, but is not limited to, steps 301 to 302.

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

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

[0052] In step 301 of some embodiments, each node server in the distributed system will independently check whether it has successfully received and parsed the "task consensus request message". This "task consensus request message" is broadcasted by the proposing node to all node servers at the beginning of the consensus process, and contains detailed information of the task request and a unique sequence number. If a node server confirms that it has received the message, that is, its "receiving status" is "received", then it will generate 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", a "first report value" will be included, and this value is set to the "first binary value". The "first binary value" usually represents logical "true", "affirmation" or "support". In this scenario, it can be understood that the node server preliminarily agrees or supports the execution of this task request. For example, the "first binary value" can be agreed to be the number "1". After generating the "first report message", the node server will "broadcast" it in the distributed system, which means that the message will be sent to all other node servers in the system.

[0053] In step 302 of some embodiments, if a node server has not received the "task consensus request message", that is, its "receiving status" is "not received", it will not immediately generate a report message containing a negative attitude, but will further check a condition: whether it has processed enough (reaching the preset "target number") other task requests with a sequence number larger than the sequence number of the current task request. The "target number" here is usually related to the fault tolerance of the distributed system. Specifically, the "target number" is equal to the total number of node servers in the system (n) minus the maximum number of faulty nodes (f) allowed by the system design, that is, nf. The value of this nf represents the minimum number of node servers that operate normally in the system. If a node server has processed at least nf subsequent requests with a larger sequence number, it means that these subsequent requests have been confirmed and processed by most normal nodes in the system. In this case, even if the node server has not received the current task request, it can be considered that the current request may have been lost. Therefore, when this condition is met, the node server will generate a "first report message" and include a "second binary value" in the message. The "second binary value" usually represents a logical "false", "negation" or "opposition". 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, the "second binary value" can be agreed to be the number "0". After generating the "first report message", the node server will also broadcast it in the distributed system.

[0054] For example, assuming that a distributed system has 5 node servers (n=5), and the design allows up to 2 node failures (f=2), then the "target number" is n - f = 3. If a node server has not received a task request with sequence number 10, but it has processed three task requests with sequence numbers 11, 12, and 13, then the node server will generate a "first report message" containing a "second binary value" (such as 0), indicating that it prefers to skip the request with sequence number 10.

[0055] Through step 301 to step 302, this embodiment introduces the "first report message" mechanism, so that each node server can inform other node servers in the distributed system of its reception status of the "task consensus request message" (or inference based on the processed subsequent request). This mechanism provides basic information for the subsequent consensus negotiation process, so that the nodes can start to exchange opinions and gradually reach a consensus. The design of the "first binary value" and the "second binary value" enables the node server to express two completely different attitudes (support or oppose / skip), thereby introducing the necessary distinction in the consensus process. In particular, the conditional judgment in step 302 fully considers the message delay or loss that may occur in an asynchronous network environment. By using the processed subsequent request information, 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 long waiting time of the entire system due to individual message delays, and ensures that even in the case of partial node failure or network instability, the consensus process can continue to advance and finally reach a consensus, thereby ensuring the overall availability and reliability of the distributed system.

[0056] In step 103 of some embodiments, each node server will continue to receive the "first report message" broadcasted from other node servers. When the "first report message" received by a node server meets the preset "secondary report condition", the node server will generate a "secondary report message". The "secondary report condition" generally includes that the number of "first report messages" received reaches a threshold (for example, exceeds a specific proportion of the total number of system nodes), and these "first report messages" contain both "first binary value" and "second binary value" (indicating that there is a disagreement between nodes). In addition, the "secondary report condition" may also include that the "first report value" previously broadcasted by the node server itself is inconsistent with a "public binary value" preset by the system. When these conditions are met, the node server will generate a "secondary report message" based on the "public binary value", in which the "secondary report value" is also a binary value, and is usually opposite to the "first report value", or directly equal to the "public binary value", depending on the preset rules. After generating the "secondary report message", the node server broadcasts it in the distributed system.

[0057] See also Figure 4 In some embodiments, the distributed system further includes a randomly generated public binary value, and step 103 may include, but is not limited to, steps 401 to 402.

[0058] Step 401, for each node server, if the node server receives the target number of first report messages, and the received first report message contains both the first binary value and the second binary value, and the first report value broadcast by the node server is different from the public binary value, then a secondary report message is generated according to the public binary value.

[0059] Step 402: broadcast a secondary report message in the distributed system.

[0060] In step 401 of some embodiments, each node server will continue to receive the "first report message" broadcasted by other node servers. When the number of "first report messages" received by a node server reaches the "target number", and these received "first report messages" contain both the "first binary value" and the "second binary value", this means that there is a disagreement between the nodes on 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" broadcasted by itself before is the same as the "public binary value". This "public 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" broadcasted by itself before is different from the current "public binary value", it will generate a "second report message". The generation of the "second report message" is based on the "public binary value", and its purpose is to try to change its position in order to reach a consensus with the majority opinion or some randomized trend in the system.

[0061] In step 402 of some embodiments, the node server broadcasts the "secondary report message" generated in step 401 in the distributed system. The "secondary report message" contains a "secondary report value", which can be a "first binary value" or a "second binary value", depending on the "public binary value" in step 401. By broadcasting the "secondary 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"), thereby providing new information for further consensus negotiation.

[0062] For example, 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 "public binary value" of the current round is 1. A node server (for example, 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 has reached the "target number" (4) and contains both 0 and 1, and node A's own "first report value" (9) is different from the "public binary value" (1), node A will generate a "second report message" in which the "second report value" is 1 (the same as the "public binary value"). Then, node A broadcasts this "second report message" to all other nodes.

[0063] Through step 401 to step 402, this embodiment effectively solves the problem of differences of opinion that may occur in the "first report" stage by introducing the "secondary report message" and "public binary value" mechanisms. When there are different opinions between nodes, the "public 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. The node server is required to generate a "secondary report message" only when its own "first report value" is different from the "public binary value". This design avoids unnecessary position changes and reduces the overhead of message transmission. At the same time, since the "secondary report value" is the same as the "public binary value", this actually allows the node server to move closer to the trend represented by the "public binary value", which helps the system converge to a consistent state faster. By broadcasting the "secondary report message", the node server informs 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.

[0064] The formats of the "first report message" and "second report message" are as follows: , b is the reported value, r is the current round, report means this is a report message, and tag here means the number of values ​​reported before this report in this round. A node can report at most twice, so Specifically, tag=0 means that this is the first report of the node in round r, while tag=1 means that this is the second report of the node in round r.

[0065] In step 104 of some embodiments, each node server will comprehensively analyze all the "first report messages" and "second report messages" it has received, and generate 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 to the task request, that is, support (for example, "1") or opposition / skip (for example, "0"). In the process of generating the "current voting message", the node server will also use the concept of "implicit report message". Specifically, if a node server broadcasts a "secondary report message", it can be considered that it implicitly also sends an "implicit report message" that is opposite to the "secondary report value". The node server will comprehensively consider the "first report message", "secondary report message" and "implicit 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.

[0066] See also Figure 5In 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.

[0067] Step 501: for each node server, an implicit report message is generated according to the received secondary report message and the first report message.

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

[0069] Step 503: If the sum of the number of first report messages and the number of second report messages reaches the target number, and the corresponding first report value and second report value are the same, a second voting message is broadcast in the distributed system.

[0070] In step 501 of some embodiments, each node server generates an "implicit report message" based on the received "first report message" and "second report message". The "implicit report message" is not an actual 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 based on the received "second report message", and its value is opposite to the "second report value" actually sent by the node server. For example, if node A receives a message with a "second report value" of 1 from node B, then node A will generate 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 network delays or message losses that may occur 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 delays, node A has not received a message with a "first report value" of 1. At this time, the "implicit report message" mechanism can help node A determine the "first report value" of node B, so as to make voting decisions more accurately.

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

[0072] In step 503 of some embodiments, each node server will count the number of "first report messages" and "second report messages" it has received, and check 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" (nf), and the "first report value" and "second report value" corresponding to these messages are the same (for example, both are 0), then the node server will broadcast a "secondary voting message" in the distributed system. The "secondary voting message" contains a "voting value" that is equal to the corresponding "secondary report value". For example, if the "first report value" and "secondary report value" that meet the voting conditions are both 0, then the "voting value" of the broadcast "secondary voting message" is also 0.

[0073] For example: Assume that 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 message with a "second report value" of 1 from node E. At the same time, node A generates an "implicit report message" with an "implicit report value" of 0 for node E. At this time, the total number of "first report messages" and "implicit report messages" received by node A is 4, reaching the target number, but the corresponding values ​​are not exactly the same (B, C, D are 1, E is 0), so the condition of step 502 is not met, and the "first voting message" will not be broadcast. 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 all 1, so the condition of step 503 is met, and node A will broadcast a "secondary voting message" with a "voting value" of 1.

[0074] In some embodiments, the format of the "first voting message" and the "second voting message" is: , b is the voting value, r is the current round, vote means this is a voting message, tag=0 means this is the first voting message of the node in round r, and tag=1 means this is the second voting message of the node in round r.

[0075] The overall technical effect of the above steps 501 to 503 is that by combining the "first report message", "second report message" and "implicit report message", as well as the "target number" mechanism, reliable voting for task requests is achieved. The introduction of the "implicit report message" mechanism can effectively handle network delays or message loss and improve the accuracy of voting. Voting according to 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 in individual nodes. By requiring the "target number" to be reached before voting can be conducted, the reliability and consistency of the voting results are guaranteed, and the system can operate normally and reach consensus even in the event of partial node failure. This multi-stage voting mechanism effectively improves the fault tolerance of distributed systems in asynchronous network environments and ensures the reliability and consistency of task request processing.

[0076] In step 105 of some embodiments, each node server will continue to collect "first report messages", "second report messages" and "voting messages" (including "first voting messages" and "second voting messages") from other node servers. Based on the collected information, each node server will independently calculate a "current consensus result". This "current consensus result" indicates whether the current round of consensus negotiation has reached a consensus, that is, whether most node servers have reached a consensus on how to handle the task request (submit or skip).

[0077] See also Figure 6 In some embodiments, step 105 may include, but is not limited to, step 601 .

[0078] Step 601, for each node server, when the node server receives the target number of first voting messages containing the same voting value, or the sum of the number of received implicit report messages and first report messages reaches the target number, and the corresponding implicit report value and first report value are 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, a consensus result indicating that a consensus has been reached is generated according to the voting value or the first report value, otherwise it proceeds to the next round.

[0079] In step 601 of some embodiments, each node server will continue to collect voting messages (including "first voting messages" and "secondary voting messages") from other node servers, as well as previously collected "first report messages" and "implicit report messages" generated based on "secondary report messages". Based on this information, the node server will determine whether the conditions for reaching a consensus have been met, and generate a "consensus result" accordingly. Specifically, there are three situations that can trigger the node server to generate a "consensus result": Condition 1, receiving enough identical "first voting messages": If the number of messages containing the same "voting value" in the "first voting messages" received by a node server reaches the "target number" (nf), then the node server considers that a consensus has been reached. At this time, the "consensus result" is the same "voting value". For example, if the "target number" is 4, and a node server receives 4 "first voting messages" with "voting values" all equal to 1, then the "consensus result" it generates is 1.

[0080] Condition 2, "First Report Message" and "Implicit Report Message" meet specific conditions: If the total number of "First Report Message" and "Implicit Report Message" received by a node server reaches the "target number" (nf), and the "First Report Value" and "Implicit Report Value" corresponding to these messages are equal to the "public binary value" of the current round, then the node server also believes that consensus has been reached. At this time, the "consensus result" is this "public binary value". For example, if the "target number" is 4, the "public binary value" of the current round is 0, and a node server receives 3 messages with a "first report value" of 0, and 1 message with an "implicit report value" of 0 (which means it received a message with a "second report value" of 1), then the "consensus result" it generates is 0.

[0081] Condition 3, receiving any "first voting message" that is the same as the "public binary value": If a node server receives any "first voting message" and the "voting value" of this message is equal to the "public binary value" of the current round, then the node server will also think that consensus has been reached. At this time, the "consensus result" is this "public binary value". This condition is designed to speed up the consensus in some cases. Even if not enough voting messages are received, as long as one node clearly expresses an opinion consistent with the "public binary value", this opinion can be directly adopted as the consensus result.

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

[0083] For example, 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. The "public binary value" of the current round is 1.

[0084] Case 1: Node A receives 4 "first voting messages", and the "voting value" of each of them is 1. Condition 1 is met, and Node A generates a "consensus result" of 1.

[0085] Case 2: Node A receives 3 messages with a "first report value" of 1, and 1 message with an "implicit report value" of 1 (from a message with a "second report value" of 0). The values ​​of these 4 messages are all equal to the "public binary value" of 1, satisfying condition 2, and node A generates a "consensus result" of 1.

[0086] Case 3: Node A receives 1 "First Voting Message" with a "Voting Value" of 1, which is equal to the "Public Binary Value" of 1. Condition 3 is met, and Node C generates a "Consensus Result" of 1.

[0087] Case 4: Node A received 2 "First Voting Messages" with "Voting Values" of 0 and 1 respectively. At the same time, it also received 1 message with "First Reporting Value" of 0 and 1 message with "Implicit Reporting Value" of 0. Among these 4 messages, only 3 have the same value as the "Public Binary Value" of 1, which does not meet condition 2. It also did not receive enough identical "First Voting Messages", which does not meet condition 1. It also did not receive any "First Voting Message" with the same "Public Binary Value", which does not meet condition 3. Therefore, node A believes that no consensus has been reached in the current round and needs to move to the next round.

[0088] In some embodiments, when the node server fails to reach a consensus in a round of negotiation, it will enter the next round of negotiation. Before entering a 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 "public binary value" of the new round, and updating its "first report value" according to the voting situation of the previous round. The "public 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 "public binary value" in the same round. After obtaining the new "public binary value", the node server will update its "first report value" according to the voting messages collected in the previous round. The "first report value" is the value contained in the "first report message" broadcast by the node server in the new round of negotiation, which reflects the node server's initial attitude towards the task request. The update rules take into account two situations of the previous round of voting messages: if all the voting messages received in the previous round are "secondary voting messages", it means that the voting in the previous round was mainly based on the "secondary report message". The node server will check the "voting value" of these voting messages. If all the "voting values" are the "public binary value" of the previous round, then the node server will set the "first report value" of the new round to the "public binary value" of the previous round; if the voting message received in the previous round contains the "first report message", then the node server will set the "first report value" of the new round to the first report value in the "first report message" and enter the next round of consensus negotiation cycle.

[0089] Exemplarily, a node server broadcasts a "public binary value" of 1 in the first round of negotiation. At the end of the first round, the node server did not reach a consensus. Before entering the second round, it first obtains the "public binary value" of the second round, assuming it is 1. Then, it checks the voting messages received in the previous round. If it finds that all voting messages are "secondary voting messages" and the voting values ​​are all 1, then its "first report value" in the second round will be set to 1. If it finds that the voting message received in the previous round contains the "first voting message", the "first report value" of the second round is the same as the "first voting message" received in the previous round. After determining the "first report value", the node server generates and broadcasts a new "first report message", and begins to receive and process messages from other nodes to participate in a new round of consensus negotiation.

[0090] In step 106 of some embodiments, each node server determines whether the "current consensus result" calculated in step 105 meets the preset "consensus condition". The "consensus condition" generally includes receiving enough "voting messages" with the same "voting value", or the received "report messages" (including "first report message", "secondary report message" and "implicit report message") meet specific combination and quantity requirements and are related to the "public binary value". If the "consensus condition" is met, it is considered that consensus has been reached, and the node server will decide how to handle the original task request based on 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 reporting, voting and result calculation processes until consensus is reached or the preset maximum round limit is reached.

[0091] See also Figure 7 In some embodiments, step 106 may include, but is not limited to, steps 701 to 702.

[0092] Step 701: In response to the consensus result including the first binary value, submitting the task request.

[0093] Step 702: In response to the consensus result including the second binary value, skip processing of the task request.

[0094] In step 701 of some embodiments, after a series of consensus negotiation processes, the node server will eventually obtain a "consensus result". This "consensus result" is a binary value used to indicate how the node server should process the initial task request. If the "consensus result" contains the "first binary value" (usually agreed to be the number "1"), then the node server will "submit the task request for processing". "Submitting the task" means that the node server will perform the operation specified in the task request, such as executing a piece of code, updating a database record, writing data to a file, etc.

[0095] In step 702 of some embodiments, if the "consensus result" obtained by the node server contains the "second binary value" (usually agreed to be the number "0"), the node server will "skip processing" the task request. "Skip processing" means that the node server will ignore the task request and will not perform the specified operation. Even if the subsequent node server receives the task request again (for example, the request arrives due to network delay), it will directly ignore it and will not repeat the processing.

[0096] See also Figure 8In some embodiments, when the task request is skipped or the consensus result indicates that no consensus has been reached, steps 801 to 805 are also included.

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

[0098] Step 802, for each node server, if the sum of the first confirmation message received, the first report message with the first report value being the first binary value, and the implicit report message 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.

[0099] Step 803 : for each node server, a sequence number with the smallest sequence and which has not been used is reselected from the request sequence set as the second request sequence number of the task request.

[0100] Step 804: Generate a request re-submission message according to the task request sequence number and the second request sequence number, and broadcast the request re-submission message in the distributed system.

[0101] Step 805 , for each node server, in response to receiving the request resubmission message, submit the task request according to the task request sequence number.

[0102] In step 801 of some embodiments, if a node server receives a "task consensus request message" but in the previous consensus negotiation process, the node server has not sent any message indicating "submission", that is, it has not sent a "first report message", "second report message", "first voting message" or "secondary voting message" containing the "first binary value", then the 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 the task request has been received, but no opinion supporting submission has been expressed. This usually occurs when the node server misses to participate in the consensus negotiation due to network delays, high load on itself, etc., or it has always tended to skip the request.

[0103] In step 802 of some embodiments, each node server will continue to collect messages from other node servers, including "first confirmation message", "first report message", "implicit report message", "first voting message" and "secondary voting message". When a node server finds any of the following two situations, it will mark the corresponding task request as "stable state": 1. The number of "first confirmation messages" received, plus the number of "first report messages" with "first report value" as "first binary value", plus the number of "implicit report messages" with "implicit report value" as "first binary value", the sum of these three reaches the "target number" (nf, where n is the total number of nodes and f is the maximum number of fault-tolerant nodes).

[0104] 2. Receive any "first voting message" or "second voting message" whose "voting value" is the "first binary value".

[0105] The stable state indicates that the task request has been correctly received by enough node servers (at least nf). Even if the previous consensus negotiation did not successfully submit the request, it can now be safely considered to be re-proposed without worrying about data inconsistency or repeated execution.

[0106] In step 803 of some embodiments, if a task request is marked as "stable state", but the result of the previous consensus negotiation is to skip the request (or no consensus is reached, that is, no resolution is output), then the node server will try to re-propose the request, and re-select a minimum, unused sequence number in the maintained "request sequence set" as the "second request sequence number" of the task request. This "second request sequence number" is used to identify the re-proposed request, and the original "task request sequence number" is used to associate with the original task request.

[0107] In step 804 of some embodiments, the proposing node generates a "request re-proposing message" based on the original "task request sequence number" and the new "second request sequence number", and broadcasts it in the distributed system. The purpose of the "request re-proposing 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 a "stable state", the "request re-proposing message" only needs to include the original "task request sequence number" and "second request sequence number", and does not need to include the complete task request content. In addition, in order 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-proposing message" to the new request and send it together.

[0108] In step 805 of some embodiments, after any node server receives the "request to resubmit message", it will first check whether the task request corresponding to the original "task request sequence number" contained in the message has been processed (i.e., whether it has been executed). If it has not been processed, the node server will "submit and process" the task request according to the original "task request sequence number", that is, execute the operation specified in the task request. Due to the uniqueness of the "task request sequence number", even if multiple node servers resubmit the same task request at the same time, only one node server will successfully submit it, thereby avoiding repeated execution.

[0109] The overall technical effect of the above steps 801 to 805 is that, by introducing a "fast re-proposal mechanism", the problem that the task request may be accidentally skipped or fail to reach consensus in time during the FTBA consensus negotiation process is effectively solved. Even if the task request fails to be successfully submitted in the initial consensus negotiation due to network delays, node failures or other reasons, as long as the request is eventually correctly received by enough node servers (reaching a "stable state"), it can be processed by re-proposal, thereby avoiding unnecessary waiting and waste of resources. The "first confirmation message" is used to confirm that the node has received the request but has not yet participated in the previous consensus. The determination of the "stable state" ensures that the resubmitted request is safe and will not cause data inconsistency or repeated execution. The "request re-proposition message" provides a concise and efficient way to re-trigger the consensus negotiation on the task request, and further improves the processing efficiency by associating it with the serial number of the new request.

[0110] See also Fig. 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 been agreed upon. The goal of the present invention is to ensure that the logs of all normally operating node servers are completely consistent in content and order. To achieve this goal, the present invention adopts a strategy of cyclically 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. Fig. 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.

[0111] The distributed request processing method based on multi-round message exchange proposed in this application, the node server first broadcasts the task consensus request message, and then gradually reaches a consensus through multiple rounds of message exchange (first report message, second report message, voting message). By introducing a two-stage reporting mechanism, the node server will not change its report value at will, but will only trigger the broadcast of the second report message when the first report message received meets the preset reporting conditions, and may update its own report value in the second report. This design effectively limits the conditions for the node server to change the proposal, and prevents the consensus process from being delayed due to the easy change of the proposal value. In addition, in the voting stage, the node server will comprehensively consider the first report message and the second report message received to vote, and in the consensus result output stage of each round, 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 messages further enhances the reliability and stability of the consensus result and avoids the dominance of a single message type or a few node servers. When the consensus result indicates that a consensus has been reached, the request can be processed according to the consensus result. Unlike synchronous / semi-synchronous consensus algorithms that rely on the upper bound of network delay, this method is an asynchronous consensus algorithm that does not rely on any delay assumptions and is more suitable for actual network environments. Through the above-mentioned two-stage reporting mechanism and comprehensive decision-making mechanism with constraints, 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 while ensuring the correctness of the consensus, reduces unnecessary proposal changes and communication overhead, and reduces the delay in reaching consensus. In summary, the method proposed in this application can improve the efficiency of reaching consensus on task request processing in distributed systems.

[0112] See also Fig.10 The embodiment of the present application further 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: A first broadcast module, configured to generate a task consensus request message according to the task request in response to any of the node servers obtaining the task request, and broadcast the task consensus request message in the distributed system; A second broadcast module is used to determine, for each of the node servers, a 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; A third broadcast module is configured to generate a secondary report message based on the first report message for each of the node servers in response to the received first report message satisfying a preset second report condition, and broadcast the second report message in the distributed system; a fourth broadcast module, configured to generate, for each of the node servers, 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; A consensus module, configured to obtain a current consensus result for each of the node servers according to the first report message, the second report message and the voting message; A processing module is used to perform task request processing on the task request according to the current consensus result in response to the consensus result satisfying a preset consensus condition.

[0113] In a third aspect, an embodiment of the present application provides an electronic device, comprising: a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, it implements a distributed request processing method based on multi-round message exchange as described in any one of the embodiments of the first aspect of the present application.

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

[0115] See also Fig.11 , Fig.11 The hardware structure of an electronic device of another embodiment is illustrated, and the electronic device includes: The processor 1101 may be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (Application Specific Integrated Circuit, ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of the present application; The memory 1102 may 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). The memory 1102 may store an operating system and other application programs. When the technical solution provided in the embodiments of this specification is implemented by software or firmware, the relevant program code is stored in the memory 1102, and the processor 1101 calls and executes the distributed request processing method based on multi-round message exchange in the embodiments of this application; Input / output interface 1103, used to implement information input and output; The communication interface 1104 is used to realize the communication interaction between the device and other devices. The communication can be realized through a wired manner (such as USB, network cable, etc.) or a wireless manner (such as mobile network, WIFI, Bluetooth, etc.); A bus 1105 that transmits information between various components of the device (e.g., the processor 1101, the memory 1102, the input / output interface 1103, and the communication interface 1104); The processor 1101 , the memory 1102 , the input / output interface 1103 and the communication interface 1104 are connected to each other in communication within the device via the bus 1105 .

[0116] An embodiment of the present application also provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the distributed request processing method based on multiple rounds of message exchange is implemented.

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

[0118] The embodiments described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Those skilled in the art will appreciate that with the evolution of technology and the emergence of new application scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0119] Those skilled in the art will appreciate that the technical solutions shown in the figures do not constitute a limitation on the embodiments of the present application, and may include more or fewer steps than shown in the figures, or a combination of certain steps, or different steps.

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

[0121] Those skilled in the art will appreciate that all or some of the steps in the methods disclosed above, and the functional modules / units in the systems and devices may be implemented as software, firmware, hardware, or a suitable combination thereof.

[0122] 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 are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0123] It should be understood that in this application, "at least one (item)" means one or more, and "plurality" means two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the objects associated before and after are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least 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.

[0124] In the several embodiments provided in the present 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 only schematic. For example, the division of the above units is only a logical function division. There may be other division methods in actual implementation, such as 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 mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

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

[0126] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0127] If 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 this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium, including multiple instructions to enable a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (Read-Only Memory, referred to as ROM), random access memory (Random Access Memory, referred to as RAM), disk or optical disk and other media that can store programs.

[0128] The preferred embodiments of the present invention are described above with reference to the accompanying drawings, but the scope of the rights of the present invention is not limited thereto. Any modification, equivalent substitution and improvement made by a person skilled in the art without departing from the scope and essence of the present invention should be within the scope of the rights of the present invention.

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 a plurality of node servers, and the method includes: In response to any of the node servers acquiring 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 a 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 second report condition, generating a second report message based on the first report message, and broadcasting the second report message in the distributed system; 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; 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; 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.

2. The distributed request processing method based on multi-round message exchange according to claim 1 is characterized in that: In response to any of the node servers acquiring 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, including: Get task request; Selecting a sequence number with the smallest sequence and which has not been used from a pre-configured request sequence set as the task request sequence number of the task request; Generate a task consensus request message according to the task request and the task request sequence number; The task consensus request message is broadcasted in the distributed system.

3. The distributed request processing method based on multi-round message exchange according to claim 2 is characterized in that: The first report message includes a first report value, the first report value is equal to a first binary value or a second binary value, and for each of the node servers, determining a 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, including: For each of the node servers, if the receiving 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 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, then the first report message containing the second binary value is broadcast in the distributed system.

4. The distributed request processing method based on multi-round message exchange according to claim 3 is characterized in that: The distributed system also includes a randomly generated public binary value, wherein for each of the node servers, in response to the received first report message satisfying a preset second report condition, a second report message is generated based on the first report message, and the second report message is broadcasted in the distributed system, including: For each of the node servers, if the node server receives the target number of first report messages, and the received first report message includes both the first binary value and the second binary value, and the first report value broadcast by the node server is different from the public binary value, then generating the second report message according to the public binary value; 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.

5. The distributed request processing method based on multi-round message exchange according to claim 4 is characterized in that: The voting message includes a first voting message and a second voting message, and 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, comprises: For each of the node servers, an implicit report message is generated according to the received secondary 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 secondary report message; If the sum of the number of the first report message and the number of the implicit report message reaches the target number, and the corresponding implicit report value is the same as the first report value, 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; 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 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.

6. The distributed request processing method based on multi-round message exchange according to claim 5, characterized in that: The step of obtaining, for each of the node servers, 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 number of first voting messages received by the node server containing the same voting value reaches the target number, or the sum of the number of the received implicit report messages and the first report messages reaches the target number, and the corresponding implicit report value and the first report value are equal to the common binary value of the current round, or a first voting message is received and the voting value is equal to the common binary value of the current round, the consensus result indicating that a consensus has been reached is generated according to the voting value or the first report value, otherwise it proceeds to the next round.

7. The distributed request processing method based on multi-round message exchange according to claim 6 is characterized in that: 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, including: In response to the consensus result including the first binary value, submitting the task request; In response to the consensus result including the second binary value, skipping processing of the task request.

8. The distributed request processing method based on multi-round message exchange according to claim 7 is characterized in that: 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 voting message or the second voting message containing the first binary value, 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 first confirmation message received, the first report message whose first report value is the first binary value, and the implicit report message whose implicit report value is the first binary value reaches the target number, or in response to the server receiving the first voting message or the second voting message whose voting value is the first binary value, the task request is determined to be in a stable state; For each of the node servers, reselect a sequence number with the smallest sequence and which has not been used in the request sequence set as the second request sequence number of the task request; Generate a request re-assignment message according to the task request sequence number and the second request sequence number, and broadcast the request re-assignment message in the distributed system; For each of the node servers, in response to receiving the request resubmission message, the task request is submitted for processing according to the task request sequence number.

9. An electronic device, characterized in that: include: A memory and a processor, wherein 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 as described in any one of claims 1 to 8 is implemented.

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

Images