An information processing method, node, device, medium and product

Abstract

This application provides an information processing method, node, device, medium, and product. The information processing method applied in a coordination node includes: acquiring a first event; sending a first voting request for the first event and a first submission request for a second event to multiple participating nodes; the second event being the previous event of the first event; within a preset time period, upon receiving a first voting submission message sent by the first participating node based on the first voting request, and a first submission result sent by the first participating node based on the first submission request, sending a second submission request for the first event and a second voting request for a third event to the first participating node; until the first participating node has processed all the events; the third event being the next event of the first event; the multiple events include the first event, the second event, and the third event. This application improves the processing efficiency when processing event information based on participants.

Description

Technical Field

[0001] This application relates to the field of distributed technology, and in particular to an information processing method, node, device, medium and product. Background Technology

[0002] Two-Phase Commit (2PC) is a classic distributed transaction commit algorithm that extends local atomic commit behavior to distributed transactions, guaranteeing the atomicity of distributed transaction commits. The protocol consists of two phases: the preparation phase and the commit phase. In the preparation phase, the coordinator sends a preparation request to all participants, who execute transaction operations and log them. If the transaction is ready, they reply "ready." In the commit phase, if all participants reply "ready," the coordinator sends a commit request to all participants, who execute the commit operation and log them.

[0003] In the 2PC protocol, if a participant fails to respond to the coordinator for an extended period, the coordinator will continue to wait. At this time, other participants will also wait and will be unable to perform any other operations. In other words, all participants are in a transaction-blocked state, which reduces the processing efficiency when processing event information based on participants. Summary of the Invention

[0004] This application provides an information processing method, node, device, medium, and product that can improve the processing efficiency of event information processing based on participants.

[0005] The technical solution of this application embodiment is implemented as follows: This application provides an information processing method applied to a coordination node, the method comprising: Get the first event; Send a first vote request for the first event and a first commit request for the second event to multiple participating nodes; the second event is the previous event of the first event; Within a preset time period, if the first participating node among the plurality of participating nodes receives a first voting submission information based on the first voting request and a first submission result based on the first submission request, a second submission request for the first event and a second voting request for the third event are sent to the first participating node; until the first participating node has processed all the events; the third event is the next event after the first event; the plurality of events includes the first event, the second event and the third event.

[0006] This application provides an information processing method applied to participating nodes, including: Upon receiving the first vote request for the first event and the first commit request for the second event sent by the coordinating node, obtain the first commit result corresponding to the second event; If it is determined that the first event can be executed and the participating node is the first participating node, the first submission result and the first vote submission information of the first event are sent to the coordinating node. The system receives a second submission request for the first event and a second voting request for the third event from the coordinating node, executes the third event and obtains the second submission result corresponding to the first event, until all events in the coordinating node have been processed.

[0007] This application provides an electronic device, the electronic device comprising: Memory is used to store executable instructions or computer programs. When a processor executes computer-executable instructions or computer programs stored in the memory, it implements the information processing method provided in the embodiments of this application for use in a coordinating node, or implements the information processing method provided in the embodiments of this application for use in a participating node.

[0008] This application provides a computer-readable storage medium storing a computer program or computer-executable instructions, which, when executed by a processor, implement the information processing method provided in this application for use in a coordinating node, or, when executed by a processor, implement the information processing method provided in this application for use in a participating node.

[0009] This application provides a computer program product, including a computer program or computer executable instructions. When the computer program or computer executable instructions are executed by a processor, they implement the information processing method provided in this application for use in a coordinating node, or the information processing method provided in this application for use in a participating node.

[0010] The embodiments of this application have the following beneficial effects: After sending the first voting request for the first event and the first submission request for the second event to multiple participating nodes, by receiving the first voting submission information sent by the first participating node based on the first voting request and the first submission result sent by the first participating node based on the first submission request within a preset time period, the first participating node can be used to process multiple events. There is no need to wait for a long time for nodes other than the first participating node to be unable to respond to the first voting request and the first submission request due to failure or other reasons. This reduces the time wasted by the participants (participating nodes) when processing event information due to transaction blocking. Moreover, each time a submission request is sent to a participating node, a voting request for the next event is also sent to the participating node, reducing the number of communication interactions between the coordinating node and the participating nodes, reducing the impact of network latency on the processing of multiple events using participants, and improving the processing efficiency when processing event information based on participants. Attached Figure Description

[0011] Figure 1 This application provides an information processing method flow. Figure 1 ; Figure 2 This is an exemplary fault handling diagram provided in an embodiment of this application; Figure 3 This is an exemplary reading view diagram provided in an embodiment of this application. Figure 1 ; Figure 4 This is an exemplary reading view diagram provided in an embodiment of this application. Figure 2 ; Figure 5 This application provides an information processing method flow. Figure 2 ; Figure 6 This is a schematic flowchart of an exemplary information processing method provided in an embodiment of this application; Figure 7 This is a schematic diagram of the composition structure of a coordination node provided in an embodiment of this application; Figure 8 This is a schematic diagram illustrating the composition of an electronic device provided in an embodiment of this application; Figure 9 This is a schematic diagram of the composition structure of a participating node provided in an embodiment of this application.

[0012] It should be noted that the terms "first" and "second" mentioned above are only used to distinguish between different options and do not represent the degree of superiority or inferiority of the options or their priority in the implementation process. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0014] In related technologies, the Two-Phase Commit (2PC) protocol is a classic distributed transaction commit algorithm that extends local atomicity commit behavior to distributed transactions, guaranteeing the atomicity of distributed transaction commits. This protocol consists of two phases: the prepare phase and the commit phase. In the prepare phase, the coordinator sends a prepare request to all participants, who perform transaction operations and log entries. If the transaction can be committed, they reply "ready." In the commit phase, if all participants reply "ready," the coordinator sends a commit request to all participants, who perform the commit operation and log entries. 2PC is simple, practical, and relatively reliable, and has become a de facto industry standard. It can effectively guarantee the consistency of distributed transactions and data, and can effectively recover from failures without losing log records, thus improving the reliability of distributed database systems. Under conditions of stable network, few participants, and relatively simple transactions, 2PC can efficiently complete transaction commits. Because its process is relatively simple, requiring only the prepare and commit phases, it reduces unnecessary communication and coordination costs. Its disadvantages include: a synchronous blocking problem, where a participant cannot perform any other operations while waiting for responses from other participants, meaning all participants are blocked. At this point, when participating nodes hold shared resources, other concurrent transactions attempting to acquire locks on the same object will be blocked. Furthermore, as the distributed database scales, the performance of the two-phase commit protocol begins to decline. Network latency gradually increases, often exceeding the local execution time of transactions. When the number of nodes in the distributed database exceeds a certain threshold, the overall performance growth of the distributed database gradually decreases until it stabilizes at a stable level; the system throughput does not increase linearly with the number of distributed database nodes.

[0015] Cautious Grouped Two-Phase Commit (pg2pc) is an optimized improvement on the traditional two-phase commit (2PC) protocol. It improves the performance and reliability of distributed transaction commits by packaging multiple transactions into transaction groups and incorporating partial commit and coordinator backup mechanisms, while reducing communication overhead. Since the coordinator backup mechanism can operate independently of the entire system, this article does not discuss coordinator node blocking. The pg2pc protocol also consists of two phases: the preparation phase and the commit phase. In the preparation phase, the coordinator sequentially numbers the transactions in the transaction group and sends preparation requests to all participants. Participants execute the transactions in the group sequentially based on the execution results of their local transactions and the attributes of the transaction group (whether a full commit is required). After execution, they return a preparation result. If a transaction can be committed, they reply "Ready"; otherwise, they return "Abort". In the commit phase, the coordinator summarizes the response messages from all participants. If all transactions can be committed or the conditions for partial commit are met, the coordinator sends a commit request to all participants, who execute the commit operation and log the changes. If there are transactions that cannot be committed, the coordinator sends an abort request to all participants, who execute a rollback operation and log the changes. pg2pc, building upon traditional 2PC, reduces transaction communication overhead by introducing transaction grouping and partial commit mechanisms. This protocol effectively addresses the performance bottleneck of traditional 2PC in high-transaction-volume scenarios, significantly improving the throughput and resource utilization efficiency of distributed database systems. However, while the partial commit mechanism in pg2pc reduces communication overhead, it also introduces challenges related to consistency. In scenarios involving multiple related tables or complex business logic, partial commits can lead to data inconsistencies, requiring more sophisticated mechanisms to handle such situations. Similar to traditional 2PC, during the preparation phase of pg2pc, participants must wait for the coordinator's preparation request. If the coordinator fails or there is network latency, participants will remain blocked and waiting. Its disadvantages include: synchronous blocking (similar to traditional 2PC, in the preparation phase of pg2pc, participants need to wait for the coordinator's preparation request; if the coordinator fails or there is network latency, the participants will be blocked and waiting indefinitely) and partial commit consistency challenges (although the partial commit mechanism introduced by pg2pc can reduce communication overhead, it also brings challenges in terms of consistency. When a transaction that supports partial commit meets the conditions and commits, while other transactions are aborted, how to ensure the data consistency of the entire distributed system is a complex problem. Especially in scenarios involving multiple related data tables or complex business logic, partial commit may lead to data inconsistency, requiring more complex mechanisms to handle this situation).

[0016] Other Existing Technologies: Compared to 2PC, other common existing technologies are analyzed. 3PC primarily reduces blocking risk and offers better fault tolerance for coordinator failures; however, its protocol is more complex than 2PC, increasing network communication overhead and transaction latency, thus reducing overall system performance. TCC offers better flexibility and scalability, allowing for customized business logic based on specific scenarios; however, business developers must implement the three-phase logic themselves, and poorly designed business logic can easily lead to inconsistencies. The Saga pattern uses a series of local transactions to implement distributed transactions. Compared to the synchronous blocking processing of 2PC, it improves system throughput and response speed, making it more suitable for long transaction scenarios. However, multiple independent local transactions increase the risk of data inconsistency and are weaker in atomicity compared to 2PC. Its disadvantages include: 3PC involves three rounds of interaction between the coordinator and participants, resulting in poor system performance; TCC is prone to business inconsistencies; and Saga transactions have weak atomicity.

[0017] Based on the technical problems existing in the related technologies, the methods in the following embodiments can be used to solve them.

[0018] This application provides an information processing method applied to a coordination node. Figure 1 A flowchart of an information processing method provided in an embodiment of this application is shown below. Figure 1 As shown, information processing methods may include: S101, Obtain the first event.

[0019] The information processing method provided in this application embodiment is applicable to scenarios where participating nodes process acquired events.

[0020] In the embodiments of this application, the coordination node can be implemented in various forms. For example, the coordination node described in this application may include cloud, server, terminal, etc., and the specific coordination node can be determined according to the actual situation. The embodiments of this application do not limit this.

[0021] In the embodiments of this application, the coordinating node can also be called the coordinator node or the coordinator.

[0022] In this embodiment of the application, the first event can be obtained from the client, from other devices, or through other means. The specific method of obtaining the first event can be determined according to the actual situation, and this embodiment of the application does not limit it.

[0023] In the embodiments of this application, the first event can be a single event or a group of events, such as an event group including event a, event b, event c, and event d. The specific first event can be determined according to the actual situation, and the embodiments of this application do not limit it.

[0024] In the embodiments of this application, the first event can be an information storage event, a balance change event, or other events. The specific first event can be determined according to the actual situation, and the embodiments of this application do not limit it.

[0025] S102, Send the first vote request for the first event and the first commit request for the second event to multiple participating nodes.

[0026] In this embodiment of the application, upon obtaining the first event, a first vote request for the first event and a first submission request for the second event are sent to multiple participating nodes.

[0027] In the embodiments of this application, the participating node can also be referred to as a participant node or a participant.

[0028] It should be noted that the number of participating nodes can be determined according to the actual situation, and this application embodiment does not limit this.

[0029] In this embodiment of the application, the process of sending a first voting request for a first event and a first submission request for a second event to multiple participating nodes includes: sending a first voting request for a first event and a first submission request for a second event to each of the multiple participating nodes.

[0030] For example, the number of participating nodes is 6, that is, a first vote request and a first commit request are sent to each of the 6 participating nodes.

[0031] For example, the first voting request and the first submission request can be sent to multiple participating nodes via broadcast, or they can be sent to multiple participating nodes via other means. The specific implementation method for sending the first voting request and the first submission request to multiple participating nodes can be determined according to the actual situation, and this application embodiment does not limit it.

[0032] It should be noted that the second event is the event preceding the first event. That is, the second event is the event that was acquired before the first event was acquired.

[0033] For example, the event that the coordinating node obtains after obtaining the second event is considered the first event.

[0034] It should be noted that the second event can be a single event or a group of events. The specific first event can be determined according to the actual situation, and this application embodiment does not limit this.

[0035] It should be noted that the first voting request can be a preparation request for the first event sent to the participating nodes. The first commit request can be a commit request for the second event sent to the participating nodes.

[0036] In this embodiment of the application, the first voting request may be a request generated based on the first event, or it may be a request obtained through other means. The specific way of obtaining the first voting request can be determined according to the actual situation, and this embodiment of the application does not limit it.

[0037] In this embodiment of the application, the first submission request may be a request generated based on the second event, or it may be a request obtained through other means. The specific method of obtaining the first submission request can be determined according to the actual situation, and this embodiment of the application does not limit it.

[0038] In this embodiment, each time the coordinating node sends a voting request (i.e., a preparation request) for event B to multiple participating nodes, it also carries a commit request for event A (i.e., the previous event of event B). If event B is the first event that the coordinating node processes using multiple participating nodes, it first sends a voting request for event B to the multiple participating nodes. Upon receiving voting commit information (i.e., "ready" information) from the multiple participating nodes based on the voting request, it sends a commit request for event B and a voting request for event C (the next event of event B) to the multiple participating nodes, until all events have been processed using multiple participating nodes.

[0039] In this embodiment of the application, the process of sending a first voting request for a first event and a first submission request for a second event to multiple participating nodes includes: using a conflict handling module to determine whether there is a conflict between the first event and the second event; and, if it is determined that there is no conflict between the first event and the second event, sending a first voting request for the first event and a first submission request for the second event to multiple participating nodes.

[0040] In this embodiment of the application, the coordinating node includes a conflict handling module. When the coordinating node obtains the event transmitted by the client using the conflict handling module, it first uses the conflict handling module to determine whether there is a conflict between the event and the previous event. If it is determined that there is no conflict, it sends a first vote request for the first event and a first submission request for the second event to multiple participating nodes.

[0041] It should be noted that the conflict resolution module can be used to determine the correlation between the first event and the second event. If there is a correlation between the first event and the second event, then the first event and the second event are determined to be in conflict. If there is no correlation between the first event and the second event, then the first event and the second event are determined to be in conflict.

[0042] For example, specific conflict handling rules can be set according to business characteristics, such as conflict detection of timestamps and operation order: assign a unique timestamp to each transaction block to mark the start time of the transaction block. When detecting conflicts, compare the timestamps and operation order of different transaction blocks.

[0043] It should also be noted that if the execution result of the second event affects the execution of the first event, then it is determined that there is a relationship between the first event and the second event, that is, it is determined that the first event and the second event conflict. Other methods can also be used to determine whether the first event and the second event conflict. The specific method for determining whether the first event and the second event conflict can be determined according to the actual situation, and this application embodiment does not limit it.

[0044] In this embodiment, the coordinating node may not include a conflict handling module. In this case, the coordinating node can obtain events transmitted by the client from the conflict handling module. When the conflict handling module receives an event transmitted by the client, it first determines whether there is a conflict between the event and the previous event. If no conflict is found, the event is transmitted to the coordinating node. The specific relationship between the conflict handling module and the coordinating node can be determined according to the actual situation, and this embodiment does not limit it.

[0045] In this embodiment of the application, after the conflict handling module determines whether there is a conflict between the first event and the second event, if a conflict is determined between the first event and the second event, a second voting request for the third event and a first submission request for the second event are sent to multiple participating nodes until multiple events are processed by multiple participating nodes.

[0046] It should be noted that the third event is the next event after the first event; that is, the third event is the first event obtained after the first event is obtained.

[0047] For example, the event that the coordinating node obtains after the first event is the third event.

[0048] It should be noted that the third event can be a single event or a group of events. The specific third event can be determined according to the actual situation, and this application does not limit it in this way.

[0049] In this embodiment of the application, if it is determined that there is a conflict between the first event and the second event, the first event is removed, and the second voting request corresponding to the obtained third event and the first submission request of the second event are sent to multiple participating nodes, that is, the second voting request and the first submission request are sent to each of the multiple participating nodes.

[0050] It should be noted that, if a conflict is found between the first event and the second event, after removing the first event, the first event can be placed at the end of the multiple events, that is, the first event is the last event among the multiple events.

[0051] In this embodiment of the application, the second voting request may be a request generated based on a third event, or it may be a request obtained through other means. The specific way of obtaining the second voting request can be determined according to the actual situation, and this embodiment of the application does not limit it.

[0052] In this embodiment of the application, if there is no conflict between event A and time B (i.e. the next event after event A), a submission request for event A is sent to multiple participating nodes each time, and a voting request for event B is also sent to multiple coordinators. If it is determined that there is a conflict between event A and time B, a submission request for event A is sent to multiple participants, and a voting request for event C (i.e. the next event after event B) is also sent to multiple coordinators, until all events (i.e. multiple events) are processed by multiple participants.

[0053] In this embodiment, after sending a first voting request for a first event and a first submission request for a second event to multiple participating nodes, upon receiving voting end information sent by at least one of the multiple participating nodes based on the first voting request, and multiple first submission results from the multiple participating nodes for the second event, a global abort instruction corresponding to the first event and a second voting request for a third event are sent to the multiple participating nodes; upon receiving multiple second voting submission messages sent by the multiple participating nodes based on the second voting request, and a rollback completion message for the global abort instruction, a third submission request for a third event and a third voting request for a fourth event are sent to the multiple participating nodes, until the multiple events are processed by the multiple participating nodes.

[0054] It should be noted that the fourth event is the event following the third event; that is, the fourth event is the first event obtained after the third event is obtained.

[0055] For example, the event that the coordinating node obtains after the third event is the fourth event.

[0056] It should be noted that the fourth event can be a single event or a group of events. The specific fourth event can be determined according to the actual situation, and this application embodiment does not limit this.

[0057] In this embodiment of the application, the voting end information sent based on the first voting request is the information returned by the at least one participating node because it is unable to process the first event.

[0058] It should be noted that if at least one participating node sends a voting end message based on the first voting request, it is determined that the at least one participating node cannot handle the first event. At this time, the coordinating node informs multiple participating nodes that it will no longer execute the first event, that is, it sends a global abort instruction corresponding to the first event to multiple participating nodes. At the same time, it also sends a second voting request for the third event to multiple participating nodes.

[0059] It should be noted that the coordination node also includes a fault handling module, which can send a global abort command corresponding to the first event to multiple participants.

[0060] It should also be noted that the coordinating node can also receive voting end information sent by at least one participating node based on the first voting request through the fault handling module.

[0061] In this embodiment, the method by which the coordinating node sends a second voting request for a third event to multiple participating nodes can be determined according to the actual situation, and this embodiment does not limit this.

[0062] In this embodiment, the global abort instruction can be an instruction generated based on the first event, or it can be an instruction obtained by the coordinating node through other means. The specific way of obtaining the global abort instruction can be determined according to the actual situation, and this embodiment does not limit it.

[0063] It should be noted that the global abort instruction includes either the abort message or the Global-abort message.

[0064] In this embodiment of the application, after the coordinating node sends a global abort instruction corresponding to the first event to multiple participating nodes, the multiple participating nodes respectively execute a rollback operation for the first event, and after the rollback operation is completed, the multiple participants respectively send a rollback completion message to the coordinator.

[0065] In this embodiment of the application, when the coordinating node receives multiple second voting submission messages sent by multiple participating nodes based on the second voting request, and a rollback completion message for the global abort instruction, it continues to use multiple participating nodes to process the event, that is, it sends a third submission request for the third event and a third voting request for the fourth event to multiple participating nodes until multiple events have been processed by multiple participating nodes.

[0066] In this embodiment, when the coordinating node receives rollback completion messages from multiple participating nodes regarding the global abort command, it uses the conflict handling module to feed back the voting end information for the first event to the client. For example, as shown... Figure 2 As shown, when the coordinating node receives a rollback completion message from multiple participating nodes for the global abort instruction of the first event (such as transaction c in transaction block 3), it feeds back the voting end information of the first event (such as transaction c) to the client through the conflict handling module.

[0067] In this embodiment, when participating nodes can interact with the coordinating node, a fault handling module can be used to transmit a "voting end" message (voting end information) to the coordinating node. Participants can roll back their transactions upon receiving a Global-abort message from the coordinator via the fault handling module. Because a conflict resolution mechanism (i.e., a conflict resolution module) already exists, even with transaction block blind spots, adjacent transaction blocks remain independent. The coordinator can send an abort message for a transaction block and a preparation message for the next transaction block to the participants, continuing the consensus transaction block process.

[0068] S103. Within a preset time period, if the first participating node sends a first voting submission message based on a first voting request and the first participating node sends a first submission result based on a first submission request, the first participating node sends a second submission request for the first event and a second voting request for the third event to the first participating node; until the first participating node has processed all the events.

[0069] In this embodiment of the application, after sending a first voting request for a first event and a first submission request for a second event to multiple participating nodes, within a preset time period, if the first participating node sends a first voting submission information based on the first voting request and a first submission result based on the first submission request, a second submission request for the first event and a second voting request for the third event are sent to the first participating node; until the first participating node has processed multiple events.

[0070] It should be noted that the multiple events include the first event, the second event, the third event, and the fourth event.

[0071] In this embodiment, the preset time period can be information configured in the coordination node, information transmitted to the coordination node by other devices, or information obtained by the coordination node through other means. The specific way in which the coordination node obtains the preset time period can be determined according to the actual situation, and this embodiment does not limit it.

[0072] In this embodiment of the application, the length of the preset time period can be 20ms, 30ms, or other lengths. The specific length of the preset time period can be determined according to the actual situation, and this embodiment of the application does not limit it.

[0073] It should be noted that the start time of the preset time period can be the time when the first voting request and the first submission request are issued, and the end time of the preset time period is the end time after the start time has elapsed for the preset time period.

[0074] In this embodiment, the first participating node is a subset of the multiple participating nodes. The number of the first participating nodes can be more than half the number of the multiple participating nodes. For example, if the number of multiple participating nodes is 2n+1, then the number of the first participating nodes can be n+1.

[0075] It should be noted that the number of first participating nodes can also be half the number of multiple participating nodes. The specific relationship between the number of first participating nodes and the number of multiple participating nodes can be determined according to the actual situation, and this application embodiment does not limit this.

[0076] In this embodiment of the application, if, within a preset time period, some of the participating nodes (i.e., the first participating node, n+1) among the multiple participating nodes (a number of 2n+1) receive the first voting submission information sent based on the first voting request, and the first participating node sends the first submission result based on the first submission request, then the second participating node among the multiple participating nodes (i.e., the participating node other than the first participating node among the multiple participating nodes) may be unable to reply to the message due to hardware failure, software error, network, or other reasons. At this time, the second submission request for the first event and the second voting request for the third event are sent to the first participating node, that is, the first participating node is used to continue processing the obtained events until the multiple events are processed using the first participating node.

[0077] In this embodiment, if a participating node is unable to reply to a message due to hardware failure, software error, network issues, or other reasons, the coordinating node, following the set timeout procedure, receives replies from a majority of f+1 (total number of participating nodes is 2f+1) participating nodes within the specified time of the commit phase (i.e., within a preset time period, it receives the first vote commit information sent by the first participating node based on the first vote request, and the first commit result sent by the first participating node based on the first commit request), and will continue the transaction processing flow. When a problematic participating node recovers, it is added to the subsequent transaction processing using a node recovery mechanism.

[0078] In this embodiment of the application, after sending a first voting request for a first event and a first submission request for a second event to multiple participating nodes, if multiple first voting submission information sent by multiple participating nodes based on the first voting request and multiple first submission results sent based on the first submission request are received within a preset time period, a second submission request and a second voting request are sent to multiple participating nodes until multiple events are processed by multiple participating nodes.

[0079] In this embodiment, under normal network conditions, if the current transaction block (first event) is transaction block J, the next transaction block (third event) is transaction block K, and the order of the four adjacent data blocks is I (second event), J, K, L (fourth event). During the initialization or preparation phase, the coordinating node first receives transaction block J after it has passed through the conflict resolution module and records it in its local log. Then, the coordinating node sends a "vote" message (first vote request) for transaction block J to the participating nodes, inquiring whether a commit operation can be performed. The participating nodes check and execute transaction block J (execute the first event, and determine whether the first event can be executed based on its execution result; if the execution result is successful, the first event can be executed; otherwise, the first event cannot be executed). Each participating node responds to the coordinating node. If the participating node's transaction operation is successful, it returns a "vote commit" message (first vote commit information) and enters a ready state, waiting for further messages from the coordinating node. If a participating node's transaction operation fails (voting ends), the failure message is logged, and the process proceeds to the fault handling module, which then returns a "voting abort" message (global abort instruction) to the coordinating node. In Phase 1, if the coordinating node receives feedback from all participating nodes, all participating nodes will return "voting committed" (first vote commit message). Specifically, Phase 1 includes a commit phase and a prepare phase. Since transaction block J has already been executed in the prepare phase, the commit phase of transaction block J and the prepare phase of transaction block K can proceed simultaneously, as follows: Figure 3As shown, the specific steps include: the coordinating node records the commit message of transaction block J sent by the participating nodes to the log; the coordinating node sends a "Global-commit" message for transaction block J (the second commit request of the first event) and the preparation phase information for the next transaction block K (the second voting request of the third event) to the participating nodes; the participants release the system resources occupied during the entire transaction (i.e., transaction block J), check and execute transaction block K (execute the event corresponding to transaction block K, and determine whether transaction block K can be executed based on the execution result), and record the commit information of transaction block J to the log; each participating node sends a commit completion message for transaction block J (the commit result of the first event) and the execution result of transaction block K (the second voting commit information) to the coordinating node; the coordinating node receives the commit completion messages from all participating nodes, completes transaction J, records the log, and enters the commit phase of transaction block K. During the commit and prepare phases, if the coordinating node receives feedback information from all nodes, one or more participants will provide feedback information as "voting ended" (voting end information). Figure 4 As shown, the coordinator node logs the abort message (global abort instruction) of transaction block K; the coordinator node transmits the abort message of transaction block K to the conflict handling module; after the conflict handling module aborts transaction block K, it determines the next transaction block L; the coordinator node sends the "Global-abort" message of transaction block K and the preparation message of transaction block L to all participant nodes; after receiving the Global-abort message of transaction block K and the preparation phase information of transaction block L (i.e., the voting request corresponding to transaction block L), the participant nodes roll back transaction block K and then enter the fault handling module, which records that the rollback operation of transaction block K has been completed. After the rollback is completed, the system resources occupied during the entire transaction K are released; the participant nodes execute transaction block L.

[0080] It should be noted that after initialization, participating nodes and coordinating nodes will continuously repeat the "phase one" steps, because this saves one round of interaction between the coordinating node and participating nodes (each time the coordinator sends a submit request for an event and a vote request for the next event to the participants), which can support a larger scale of nodes.

[0081] In this application embodiment, frequent transaction (event) rollbacks can prolong transaction processing time, and the accumulation of such rollbacks can significantly degrade system performance. Furthermore, the pipelined commit (voting request and commit request) method in this application can create transaction block blind spots, potentially increasing the probability of transaction conflicts. To address this issue, a time-based conflict handling module is proposed. The conflict handling module improves system performance by reducing rollback events caused by conflicts. If the previous transaction block has finished committing and the next transaction block has not yet successfully committed, such as... Figure 3 As shown: In the case of read view C2, transaction block K generates read view C4 during commit. There is a read view blind zone C3 in between. Because transaction block J commits and generates read view C3, the possibility of conflict between transaction block K and transaction block J increases. Once a conflict occurs, transaction block K must be rolled back, leading to a decrease in system performance. Introducing a conflict handling mechanism avoids such conflicts from entering the transaction commit process, effectively reducing transaction block rollback events caused by conflicts arising from read view blind zones. When the conflict handling module receives a transaction initiated by the client, it performs conflict handling based on the successful read view of the previous transaction block, similar to an optimistic locking strategy. If the previous transaction block fails, the conflict handling module will perform conflict handling on the already processed transaction and the newly generated transaction based on the even earlier transaction block, generating a new transaction block and sending it to the coordinator node.

[0082] Understandably, after sending the first vote request for the first event and the first commit request for the second event to multiple participating nodes, the system can utilize the first participating node to process multiple events by receiving the first vote commit information and the first commit result sent by the first participating node based on the first vote request within a preset time period. This eliminates the need to wait for other participating nodes to respond to the first vote request and the first commit request due to faults or other reasons. It reduces the time wasted by transaction blocking when using participants (participating nodes) to process event information. Furthermore, each time a commit request is sent to a participating node, a vote request for the next event is also sent to the participating node, reducing the number of communication interactions between the coordinating node and participating nodes. This reduces the impact of network latency on using participants to process multiple events and improves the processing efficiency when processing event information based on participants.

[0083] This application embodiment also provides an information processing method, which is applied to participating nodes. Figure 5 A flowchart of an information processing method provided in an embodiment of this application is shown below. Figure 5 As shown, information processing methods may include: S201. Upon receiving the first vote request for the first event and the first commit request for the second event sent by the coordinating node, obtain the first commit result corresponding to the second event.

[0084] The information processing method provided in this application embodiment is applicable to scenarios where voting requests and submission requests for events sent by coordinating nodes are processed.

[0085] In the embodiments of this application, participating nodes can be implemented in various forms. The specific participating nodes can be determined according to the actual situation, and the embodiments of this application do not limit this.

[0086] In the embodiments of this application, participating nodes may be referred to as participant nodes or participants. Coordinating nodes may also be referred to as coordinator nodes or coordinators.

[0087] It should be noted that the first event can be a single event or a group of events, such as an event group including event a, event b, event c, and event d. The specific first event can be determined according to the actual situation, and this application embodiment does not limit it.

[0088] In the embodiments of this application, the first event can be an information storage event, a balance change event, or other events. The specific first event can be determined according to the actual situation, and the embodiments of this application do not limit it.

[0089] It should be noted that the first voting request can be a preparation request for the first event sent by the coordinating node. The first commit request can be a commit request for the second event sent by the coordinating node.

[0090] In this embodiment of the application, the method of receiving the first voting request for the first event and the first submission request for the second event sent by the coordinating node can be determined according to the actual situation, and this embodiment of the application does not limit it.

[0091] In this embodiment, the participating node executes the second event upon receiving a voting request for the second event. The method of executing the second event is existing technology, and this embodiment does not limit the specific implementation.

[0092] It should be noted that once a participating node successfully executes the second event, it is determined that the second event can be executed. Conversely, if a participating node fails to execute the second event, it is determined that the second event cannot be executed.

[0093] In this embodiment, upon receiving a first vote request for a first event, a participating node executes the first event; if the first event is not successfully executed, it determines that the first event cannot be executed. If it is determined that the first event cannot be executed, the participating node sends a voting end message for the first event to the fault handling module in the coordinating node; sends a first commit result to the coordinating node; upon receiving a second vote request for a third event from the coordinating node, a global abort instruction sent by the fault handling module, and determining that the third event can be executed, the participating node sends a second vote commit message for the third event and a rollback completion message for the first event to the coordinator; receives a third commit request for the third event and a third vote request for the fourth event from the coordinator, executes the fourth event, and continues until all events in the coordinating node have been processed.

[0094] In this embodiment, the method by which participating nodes determine whether the first event can be executed is existing technology, and the specific embodiments of this application do not limit this.

[0095] In this embodiment, the method of sending the voting end information of the first event to the fault handling module in the coordination node can be determined according to the actual situation, and this embodiment does not limit it.

[0096] In this embodiment of the application, voting end information and first submission result of the first event can be sent to the fault handling module in the coordination node.

[0097] In this embodiment, upon receiving a second vote request for a third event from the coordinating node and a global abort instruction from the coordinating node based on the fault handling module, the participating node determines whether the third event can be executed. If it determines that the third event can be executed, it sends the second vote commit information for the third event and the rollback completion message for the first event to the coordinator. Subsequently, the participating node continues to receive a third commit request for the third event and a third vote request for the fourth event from the coordinator, and executes the fourth event until the coordinating node has processed multiple events within the coordinating node using the participating nodes.

[0098] S202. If it is determined that the first event can be executed and the participating node is the first participating node, send the first commit result and the first vote commit information of the first event to the coordinating node.

[0099] In this embodiment of the application, after obtaining the first submission result corresponding to the second event, if it is determined that the first event can be executed and the participating node is the first participating node, the first submission result and the first vote submission information of the first event are sent to the coordinating node.

[0100] It should be noted that the first participating node is a participating node that can execute the first event and can communicate normally with the coordinating node.

[0101] In this embodiment of the application, the coordinating node will simultaneously send the submission request for event A and the voting request for event B (the next event after event A) to the participating nodes. After the participating nodes determine the result corresponding to the voting request (such as the voting submission information) and the execution result of the submission request (such as the submission result), they will send the submission result and the voting submission information to the coordinating node in one communication process.

[0102] In this embodiment, the specific method of sending the first submission result and the first vote submission information of the first event to the coordination node can be determined according to the actual situation, and this embodiment does not limit it.

[0103] S203. Receive the second commit request for the first event and the second vote request for the third event sent by the coordinating node, execute the third event and obtain the second commit result corresponding to the first event, until multiple events in the coordinating node are processed.

[0104] In this embodiment of the application, after sending the first submission result and the first vote submission information of the first event to the coordinating node, the third event is executed and the second submission result corresponding to the first event is obtained after receiving the second submission request of the first event and the second vote request of the third event sent by the coordinating node, until the multiple events in the coordinating node are processed.

[0105] It should be noted that the multiple events include the first event, the second event, the third event, and the fourth event.

[0106] In this embodiment, the method by which participating nodes receive the second submission request for the first event and the second voting request for the third event sent by the coordinating node can be determined according to the actual situation, and this embodiment does not limit this.

[0107] In this embodiment, after receiving the second commit request for the first event and the second vote request for the third event sent by the coordinating node, if the participating node is the second participating node and has received the previous commit request for the previous event and the current vote request for the current event sent by the coordinating node, the current number of the current event is determined; the first number of the last event executed by the second participating node before the failure is obtained; based on the current number and the first number, the event number corresponding to the event that the second participating node did not process during the failure is determined; and the event information corresponding to the event number is obtained from the first participating node and stored.

[0108] In this embodiment, the coordinating node also assigns a number to each of the multiple events and adds this number to the voting request or submission request corresponding to that event. Participating nodes can determine the number information corresponding to the event based on the voting request or submission request.

[0109] In this embodiment, the second participating node is any participating node other than the first participating node among multiple participating nodes. The number of second participating nodes can be one or more, and the specific number of second participating nodes can be determined according to the actual situation. This embodiment does not limit this.

[0110] In this embodiment, the second participating node may be unable to respond to the coordinating node's messages due to hardware failure, software errors, network issues, or other reasons, causing the coordinating node to be interrupted while processing multiple events using the second participating node. After the second participating node recovers, upon receiving the previous commit request for the previous event and the current vote request for the current event from the coordinating node, the second participating node determines the current event's current number. Specifically, the current event's current number can be determined from the current vote request. The second participating node can also obtain the first number of the last event executed before the failure (i.e., during the period when it was unable to respond to the coordinating node's messages due to hardware failure, software errors, network issues, or other reasons). Since multiple event numbers are consecutive, the second participating node can determine the event numbers between the current number and the first number. The second participating node interacts with the first participating node to obtain and store the event information corresponding to the event number from the first participating node.

[0111] It should be noted that the previous event is the event preceding the current event.

[0112] It should be noted that the method by which the second participating node stores the event information corresponding to the event number can be determined according to the actual situation, and this application embodiment does not limit this.

[0113] In this embodiment, each transaction can be assigned an ID. The second participating node waits for the coordinator node's next transaction information, then confirms the latest transaction block ID (i.e., the second participating node determines the current event number after receiving the coordinator node's previous commit request for the previous event and the current vote request for the current event). The second participating node communicates with the first participating node to find the normal node with the latest transaction block ID (searching for the first participating node), and overwrites the normal node information in the participating node to be restored (the first participating node retrieves the event information corresponding to the event number). After all rewriting is completed, the formally participating transaction block is executed and information is returned. At this time, the system remains active when at least f+1 participating nodes are normal.

[0114] For example, such as Figure 6 As shown, the first event transmitted by the client is first sent to the conflict handling module in the coordinating node. The conflict handling module determines whether there is a conflict between the first event and the second event (the event preceding the first event). If no conflict is found, the first voting request (sending a transaction block) for the first event and the first commit request (sending a transaction block) for the second event are sent to all participating nodes. Participating nodes determine whether they can execute the first event (whether they are ready to commit) and obtain the first commit result corresponding to the second event. If a second participating node determines that it cannot execute the first event (no), it transmits voting end information and the first commit result of the second event to the fault handling module of the coordinating node. The coordinating node waits to receive responses from all participating nodes and determines whether to "abort" the transaction commit based on the responses from all participating nodes. Since the coordinating node has received responses from any participating node... If the voting end information for the first event is sent, it is determined that the transaction needs to be "aborted". Then, the coordinating node uses the fault handling module to send a global abort instruction corresponding to the first event and a second voting request for the third event to all participating nodes. The participating nodes determine whether to execute the third event. Since the global abort instruction corresponding to the first event has been received, the first participating node determines that the transaction needs to be rolled back and performs a rollback operation on the first event. If it is determined to execute the third event, it sends a second voting commit request for the third event and a rollback completion message for the first event to the fault handling module of the coordinating node. The coordinating node then sends a third commit request for the third event and a third voting request for the fourth event to multiple participating nodes until multiple events have been processed by multiple participating nodes. The fourth event is the next event after the third event. Once the first participating node determines that it can execute the first event (Yes) and is ready, it sends the first vote commit message (vote commit) for the first event and the first commit result for the second event to the coordinating node. The coordinating node waits to receive responses from all participating nodes and determines whether to "abort" the transaction based on the responses from all participating nodes. Since all participating nodes have sent the first vote commit message and the first commit result, it determines that it is not necessary to "abort" the transaction (No). After logging, it sends the second commit request (Global-commit) for the first event and the second vote request for the third event to all participating nodes. If the participants determine that they can execute the third event and have executed the first event, they determine that they will not perform a transaction rollback operation (No) and continue to process the third event and the first event until all events have been processed.

[0115] The distributed database commit method in this application aims to improve the performance of distributed databases in high-concurrency scenarios. This application optimizes the 2PC method based on pipelining, improving system resource utilization and increasing overall system throughput, thus better adapting to high-concurrency business demands. Fault handling in the pipelining commit method is analyzed, and system activity and stability are ensured through timeout processing and fault node recovery mechanisms. The system of this invention, based on the pipelining-optimized 2PC commit method, not only improves database throughput but also ensures data consistency and system stability under high-concurrency conditions, meeting the needs of high-performance distributed databases in actual production.

[0116] Understandably, this application can improve resource utilization and reduce average transaction response time. Specifically, while ensuring efficient transaction commits and atomicity, the pipelined pattern allows each node (coordinator and participant) to schedule work more efficiently, reducing resource idleness. As a participant node, the database server, after pipeline modification, can begin processing the preparation phase of the next transaction while handling the commit phase of one. This allows for more efficient utilization of CPU, disk I / O, and other resources, unlike traditional 2PC where resources are idle during the waiting phase. From the perspective of overall transaction processing, because multiple transactions can be interleaved, transaction queuing time is reduced, thereby lowering the average transaction response time. At the same performance level, it can support larger-scale distributed database systems compared to traditional 2PC, and provides higher concurrency performance within the same distributed system scale.

[0117] Understandably, this application enhances the system's fault tolerance and liveness, preventing the spread of congestion: the specific fault handling mechanism enables the system to continue transaction consensus without affecting overall transaction processing after a participant node fails, and the failed node can rejoin the system after recovering communication. By assigning a transaction block ID, the failed node can determine the latest transaction block, then communicate with other normal nodes and overwrite the data to recover. This approach ensures that when a node fails, the system can still operate normally as long as at least f+1 nodes are normal, preventing the entire system from being blocked due to the failure of a few nodes. For example, in a highly available distributed system, even if some nodes are temporarily unable to work due to hardware failure or network problems, other normal nodes can still continue to process transactions, and the failed node can quickly rejoin the system after recovery, avoiding the blocking impact of the failed node on the entire system and maintaining the system's liveness.

[0118] Understandably, when the participating node is specifically the first participating node, the coordinating node receives the first voting submission information and the first submission result sent by the first participating node based on the first voting request within a preset time period. Based on the interaction with the first participating node among multiple participating nodes, the coordinating node uses the first participating node to process multiple events. This eliminates the need to wait for long periods of time for nodes other than the first participating node to respond to the first voting request and the first submission request due to failures or other reasons. It reduces the time wasted by transaction blocking when using participants (participating nodes) to process event information. Furthermore, each time a participating node receives a submission request from the coordinating node, it also receives a voting request for the next event from the coordinating node. This reduces the number of communication interactions between the coordinating node and participating nodes, reduces the impact of network latency on using participants to process multiple events, and improves the processing efficiency when processing event information based on participants.

[0119] Based on the same inventive concept as the above-described information processing method, this application provides a coordination node 1, corresponding to an information processing method; Figure 7 This is a schematic diagram of the composition structure of a coordination node provided in an embodiment of this application. The coordination node 1 may include: The first acquisition unit 11 is used to acquire the first event; The first sending unit 12 is configured to send a first voting request for the first event and a first submission request for the second event to multiple participating nodes; the second event is the previous event of the first event; within a preset time period, if the first participating node sends a first voting submission information based on the first voting request and a first submission result based on the first submission request, the unit sends a second submission request for the first event and a second voting request for the third event to the first participating node; until the first participating node has processed all the events; the third event is the next event of the first event; the multiple events include the first event, the second event, and the third event.

[0120] In some embodiments of this application, the first sending unit 12 is configured to send a global abort instruction corresponding to the first event and a second voting request for the third event to the plurality of participating nodes when it receives voting end information sent by at least one of the plurality of participating nodes based on the first voting request and multiple first submission results of the plurality of participating nodes for the second event; and to send a third submission request for the third event and a third voting request for the fourth event to the plurality of participating nodes when it receives multiple second voting submission information sent by the plurality of participating nodes based on the second voting request and a rollback completion message for the global abort instruction, until the plurality of participating nodes have processed the plurality of events, wherein the fourth event is the next event after the third event.

[0121] In some embodiments of this application, the coordination node further includes a first determining unit; The first determining unit is used to determine, using the conflict handling module, whether there is a conflict between the first event and the second event; The first sending unit 12 is used to send a first voting request for the first event and a first submission request for the second event to multiple participating nodes when it is determined that there is no conflict between the first event and the second event.

[0122] In some embodiments of this application, the first sending unit 12 is configured to send the second voting request of the third event and the first submission request of the second event to the plurality of participating nodes when it is determined that there is a conflict between the first event and the second event, until the plurality of participating nodes have processed the plurality of events.

[0123] It should be noted that, in practical applications, the first acquisition unit 11 and the first transmission unit 12 can be implemented by the processor 21 on the electronic device, specifically by a CPU (Central Processing Unit), MPU (Microprocessor Unit), DSP (Digital Signal Processor), or FPGA (Field Programmable Gate Array), etc.; the data storage can be implemented by the memory 22 on the electronic device.

[0124] This application also provides an electronic device, such as... Figure 8As shown, the electronic device includes a processor 21, a memory 22, and a communication bus 23. The memory 22 communicates with the processor 21 through the communication bus 23. The memory 22 stores programs executable by the processor 21. When the program is executed, the processor 21 performs the information processing method as described above.

[0125] In practical applications, the aforementioned memory 22 can be volatile memory, such as random-access memory (RAM); or non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD); or a combination of the above types of memory, and provide instructions and data to the processor 21.

[0126] This application provides a computer-readable storage medium having a computer program thereon, which, when executed by a processor 21, implements the information processing method as described above.

[0127] For example, this application also provides a computer program product, including a computer program that can be executed by a processor 21 in an electronic device to perform the steps described in the aforementioned information processing method.

[0128] Understandably, after sending the first vote request for the first event and the first commit request for the second event to multiple participating nodes, the system can utilize the first participating node to process multiple events by receiving the first vote commit information and the first commit result sent by the first participating node based on the first vote request within a preset time period. This eliminates the need to wait for other participating nodes to respond to the first vote request and the first commit request due to faults or other reasons. It reduces the time wasted by transaction blocking when using participants (participating nodes) to process event information. Furthermore, each time a commit request is sent to a participating node, a vote request for the next event is also sent to the participating node, reducing the number of communication interactions between the coordinating node and participating nodes. This reduces the impact of network latency on using participants to process multiple events and improves the processing efficiency when processing event information based on participants.

[0129] Based on the same inventive concept as the above information processing method, this application provides a participating node 2, corresponding to an information processing method; Figure 9 This is a schematic diagram of the composition structure of a participating node provided in an embodiment of this application. The participating node 2 may include: The second acquisition unit 31 is configured to, upon receiving a first voting request for a first event and a first submission request for a second event sent by the coordinating node, acquire a first submission result corresponding to the second event; and acquire a second submission result corresponding to the first event. The second sending unit 32 is used to send the first submission result and the first vote submission information of the first event to the coordinating node when it is determined that the first event can be executed and the participating node is the first participating node; Receiving unit 33 is used to receive the second submission request for the first event and the second voting request for the third event sent by the coordinating node; Execution unit 34 is used to execute the third event until multiple events in the coordination node are processed.

[0130] In some embodiments of this application, the second sending unit 32 is configured to, when it is determined that the first event cannot be executed, send voting end information of the first event to the fault handling module in the coordination node; send the first submission result to the coordination node; and, when it receives the second voting request of the third event sent by the coordination node, based on the global abort instruction sent by the fault handling module, and determines that the third event can be executed, send the second voting submission information of the third event and the rollback completion message of the first event to the coordinator. The receiving unit 33 is used to receive the third submission request for the third event and the third voting request for the fourth event sent by the coordinator. The execution unit 34 is used to execute the third event; The second acquisition unit 31 is used to acquire the third submission result corresponding to the third event until multiple events in the coordination node are processed.

[0131] In some embodiments of this application, the participating node further includes a second determining unit and a storage unit; The second determining unit is configured to, when the participating node is the second participating node and the coordinating node sends a previous submission request for the previous event and a current vote request for the current event, determine the current number of the current event; and based on the current number and the first number, determine the event number corresponding to the event that the second participating node did not process during the fault. The second acquisition unit 31 is used to acquire the first number of the last event executed before the failure of the second participating node; and to acquire the event information corresponding to the event number from the first participating node; The storage unit is used to store the event information corresponding to the event number.

[0132] It should be noted that, in practical applications, the second acquisition unit 31, the second transmission unit 32, the receiving unit 33, and the execution unit 34 can be implemented by the processor 21 on the electronic device, specifically by a CPU (Central Processing Unit), MPU (Microprocessor Unit), DSP (Digital Signal Processor), or FPGA (Field Programmable Gate Array), etc.; the data storage can be implemented by the memory 22 on the electronic device.

[0133] This application also provides an electronic device, such as... Figure 8 As shown, the electronic device includes a processor 21, a memory 22, and a communication bus 23. The memory 22 communicates with the processor 21 through the communication bus 23. The memory 22 stores programs executable by the processor 21. When the program is executed, the processor 21 performs the information processing method as described above.

[0134] In practical applications, the aforementioned memory 22 can be volatile memory, such as random-access memory (RAM); or non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD); or a combination of the above types of memory, and provide instructions and data to the processor 21.

[0135] This application provides a computer-readable storage medium having a computer program thereon, which, when executed by a processor 21, implements the information processing method as described above.

[0136] For example, this application also provides a computer program product, including a computer program that can be executed by a processor 21 in an electronic device to perform the steps described in the aforementioned information processing method.

[0137] Understandably, when the participating node is specifically the first participating node, the coordinating node receives the first voting submission information and the first submission result sent by the first participating node based on the first voting request within a preset time period. Based on the interaction with the first participating node among multiple participating nodes, the coordinating node uses the first participating node to process multiple events. This eliminates the need to wait for long periods of time for nodes other than the first participating node to respond to the first voting request and the first submission request due to failures or other reasons. It reduces the time wasted by transaction blocking when using participants (participating nodes) to process event information. Furthermore, each time a participating node receives a submission request from the coordinating node, it also receives a voting request for the next event from the coordinating node. This reduces the number of communication interactions between the coordinating node and participating nodes, reduces the impact of network latency on using participants to process multiple events, and improves the processing efficiency when processing event information based on participants.

[0138] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of hardware embodiments, software embodiments, or embodiments combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage and optical storage) containing computer-usable program code.

[0139] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0140] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0141] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0142] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. An information processing method, characterized in that, Applied to a coordinating node, the method includes: Get the first event; Send a first vote request for the first event and a first commit request for the second event to multiple participating nodes; the second event is the previous event of the first event; Within a preset time period, if the first participating node among the plurality of participating nodes receives a first voting submission information based on the first voting request and a first submission result based on the first submission request, a second submission request for the first event and a second voting request for the third event are sent to the first participating node; until the first participating node has processed all the events; the third event is the next event after the first event; the plurality of events includes the first event, the second event and the third event.

2. The method according to claim 1, characterized in that, After sending the first voting request for the first event and the first commit request for the second event to multiple participating nodes, the method further includes: Upon receiving voting end information sent by at least one of the plurality of participating nodes based on the first voting request, and the plurality of first submission results of the plurality of participating nodes for the second event, a global abort instruction corresponding to the first event and a second voting request for the third event are sent to the plurality of participating nodes. Upon receiving multiple second vote submission messages sent by the multiple participating nodes based on the second vote request, and a rollback completion message for the global abort instruction, a third submission request for the third event and a third vote request for the fourth event are sent to the multiple participating nodes until the multiple events are processed by the multiple participating nodes, wherein the fourth event is the next event after the third event.

3. The method according to claim 1, characterized in that, Sending the first vote request for the first event and the first commit request for the second event to multiple participating nodes includes: The conflict resolution module is used to determine whether a conflict exists between the first event and the second event; If it is determined that there is no conflict between the first event and the second event, a first vote request for the first event and a first commit request for the second event are sent to multiple participating nodes.

4. The method according to claim 3, characterized in that, After determining whether a conflict exists between the first event and the second event using the conflict handling module, the method further includes: If a conflict is determined between the first event and the second event, the second voting request for the third event and the first submission request for the second event are sent to the multiple participating nodes until the multiple participating nodes have processed the multiple events.

5. An information processing method, characterized in that, Applied to participating nodes, the method includes: Upon receiving the first vote request for the first event and the first commit request for the second event sent by the coordinating node, obtain the first commit result corresponding to the second event; If it is determined that the first event can be executed and the participating node is the first participating node, the first submission result and the first vote submission information of the first event are sent to the coordinating node. The system receives a second submission request for the first event and a second voting request for the third event from the coordinating node, executes the third event and obtains the second submission result corresponding to the first event, until all events in the coordinating node have been processed.

6. The method according to claim 5, characterized in that, After obtaining the first submission result corresponding to the second event, the method further includes: If it is determined that the first event cannot be executed, a voting termination message for the first event is sent to the fault handling module in the coordination node; Send the first submission result to the coordinating node; Upon receiving the second vote request for the third event sent by the coordinating node, the global abort instruction sent by the fault handling module, and determining that the third event can be executed, the coordinator sends the second vote submission information for the third event and the rollback completion message for the first event to the coordinator. The system receives the third submission request for the third event and the third vote request for the fourth event sent by the coordinator, executes the fourth event and obtains the third submission result corresponding to the third event, until multiple events in the coordinating node are processed.

7. The method according to claim 5, characterized in that, After receiving the second commit request for the first event and the second vote request for the third event sent by the coordinating node, the method further includes: If the participating node is the second participating node and has received the previous submission request for the previous event and the current vote request for the current event sent by the coordinating node, determine the current number of the current event; Obtain the first number of the last event executed before the failure of the second participating node; Based on the current number and the first number, determine the event number corresponding to the event that the second participating node did not process during the fault; Obtain and store the event information corresponding to the event number from the first participating node.

8. An electronic device, characterized in that, The electronic device includes: Memory is used to store executable instructions or computer programs. A processor, when executing computer-executable instructions or computer programs stored in the memory, implements the method according to any one of claims 1 to 7.

9. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.

10. A computer program product, comprising a computer program, characterized in that, The computer program, when executed by a processor, implements the method according to any one of claims 1 to 7.

Images