Distributed transaction processing method, electronic device, storage medium, and program product

Abstract

Provided in the embodiments of the present disclosure are a distributed transaction processing method, an electronic device, a storage medium, and a program product. In the embodiments of the present disclosure, the process during which a coordination node persists a transaction state log is offloaded to each participating node, such that each participating node persistently records a transaction state of each transaction in a commit procedure by means of a state storage area and finally maintains a completion state of each transaction; and when a participating node has a fault and recovers again, transaction recovery can be performed on the basis of the transaction state of each transaction persistently recorded by the participating node, such that not only can it be ensured that after any participating node has a fault or a network is interrupted, all participating nodes still have a consistent final state, but the operations that the coordination node perform to persist the transaction state log can also be saved on, thereby reducing the response delay of transaction commit and increasing the throughput.

Description

[0001] Distributed Transaction Processing Method, Electronic Device, Storage Medium, and Program Product This disclosure claims priority to Chinese patent application No. 202410130426.2, filed with the Patent Office of China on January 30, 2024, entitled "Distributed Transaction Processing Method, Electronic Device, Storage Medium, and Program Product," the entire contents of which are incorporated herein by reference. Technical Field This disclosure relates to the field of distributed database technology, and more particularly to a distributed transaction processing method, electronic device, storage medium, and program product. Background: In distributed database systems, a two-phase commit (2PC) protocol is typically used to address transaction consistency issues among participants, ensuring that even if any participant fails (such as a system crash or network outage), all transaction participants can still achieve a consistent final state. The protocol consists of two phases: In the prepare phase, the coordinator sends prepare requests to each participant, and the participants provide feedback on the transaction status to the coordinator for commit or rollback decisions. In the commit phase, the coordinator sends execute requests to each participant, instructing them to commit or rollback the transaction. To implement the 2PC protocol, the current mainstream approach is to persist the coordination log in a coordination log table using a separate transaction. Specifically, before the commit phase, the coordinator initiates a standalone transaction and persistently stores a commit record. This commit record records the final transaction status, allowing participants to recover after a crash or network outage. Persisting commit records increases transaction commit response latency, reduces throughput, and significantly limits the performance and scalability of distributed database transaction commits, particularly in database scenarios like online transaction processing (OLTP), which require high transaction response timeliness. SUMMARY OF THE INVENTION Aspects of the present disclosure provide a distributed transaction processing method, an electronic device, a storage medium, and a program product to reduce response delays in transaction submissions and improve throughput.An embodiment of the present disclosure provides a distributed transaction processing method, applied to a coordinating node in a distributed transaction processing system, comprising: when a target transaction is started, sending a transaction start command to multiple participating nodes associated with the target transaction to instruct the multiple participating nodes to allocate a persistent state storage area for the target transaction, where the multiple participating nodes are divided into a primary participating node and other participating nodes; sending a prepare request to the multiple participating nodes to cause the multiple participating nodes to perform a transaction prepare operation and record the transaction status of the target transaction as a prepared state in the state storage area; sending an execute request to the primary participating node to cause the primary participating node to perform a transaction complete operation and update the transaction status of the target transaction recorded in the state storage area to a completed state; and, when the primary participating node returns an execution completion message, sending the execute request to the other participating nodes to cause the other participating nodes to perform a transaction complete operation and update the transaction status of the target transaction to a completed state, where the completed state is a committed state or a rollback state. An embodiment of the present disclosure provides a distributed transaction processing method, which is applied to a coordinating node in a distributed transaction processing system, and includes: when a target transaction is started, sending a transaction start command to multiple participating nodes associated with the target transaction to instruct the multiple participating nodes to allocate a persistent state storage area for the target transaction, where the identities of the multiple participating nodes are equal; sending a prepare request to the multiple participating nodes to cause the multiple participating nodes to perform a transaction prepare operation and record the transaction state of the target transaction as a prepare state in the state storage area; and sending an execute request to the multiple participating nodes to cause the multiple participating nodes to perform a transaction complete operation and update the transaction state of the target transaction recorded in the state storage area to a complete state, where the complete state is a commit state or a rollback state. An embodiment of the present disclosure provides a distributed transaction processing method, applied to a first participating node in a distributed transaction processing system, comprising: receiving a transaction start command sent by a coordinating node for a target transaction, allocating a persistent state storage area for the target transaction, wherein the state storage area is used to record the transaction state of the target transaction; upon receiving a prepare request sent by the coordinating node, performing a transaction prepare operation and recording the transaction state of the target transaction as a prepare state in the state storage area; and upon receiving an execute request sent by the coordinating node, performing a transaction complete operation and updating the transaction state of the target transaction recorded in the state storage area to a complete state, wherein the complete state is a commit state or a rollback state.The present disclosure also provides an electronic device comprising: a memory and a processor; the memory storing a computer program, the processor coupled to the memory for executing the computer program to implement the steps of the above-described method. The present disclosure also provides a computer-readable storage medium storing the computer program. When the computer program is executed by the processor, the processor implements the steps of the above-described method. The present disclosure also provides a computer program product comprising a computer program / instructions. When the computer program / instructions are executed by the processor, the processor implements the steps of the above-described method. In the present disclosure, the process of persisting the transaction status log of the coordinating node is decentralized to each participating node. Each participating node uses a state storage area to persistently record the transaction status of each transaction during the commit process and ultimately maintains the completion status of each transaction. After a participating node fails and recovers, transaction recovery can be performed based on the transaction status of each transaction persistently recorded by the participating node. This not only ensures that all participating nodes maintain a consistent final state after any participating node fails or the network is interrupted, but also saves the coordinating node from persisting the transaction status log, reduces transaction commit response latency, and improves throughput. BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings described herein are intended to provide a further understanding of the present disclosure and constitute a part of the present disclosure. The exemplary embodiments of the present disclosure and their descriptions are intended to explain the present disclosure and do not constitute undue limitations of the present disclosure. In the accompanying drawings: Figure 1 is a schematic diagram of a traditional two-phase transaction commit process; Figure 2 is a schematic diagram of the structure of a distributed transaction processing system provided by an exemplary embodiment of the present disclosure; Figure 3a is a schematic diagram of the flow of a distributed transaction processing method provided by an exemplary embodiment of the present disclosure; Figure 3b is a schematic diagram of the flow of another distributed transaction processing method provided by another exemplary embodiment of the present disclosure; Figure 4 is a schematic diagram of the flow of yet another distributed transaction processing method provided by yet another exemplary embodiment of the present disclosure; Figure 5 is a schematic diagram of the flow of yet another distributed transaction processing method provided by yet another exemplary embodiment of the present disclosure; Figure 6 is a schematic diagram of the flow of yet another distributed transaction processing method provided by yet another exemplary embodiment of the present disclosure; Figure 7 is a schematic diagram of the structure of yet another distributed transaction processing apparatus provided by yet another exemplary embodiment of the present disclosure; Figure 8 is a schematic diagram of the structure of yet another distributed transaction processing apparatus provided by yet another exemplary embodiment of the present disclosure; Figure 9 is a schematic diagram of the structure of yet another distributed transaction processing apparatus provided by yet another exemplary embodiment of the present disclosure; and Figure 10 is a schematic diagram of the structure of an electronic device provided by yet another exemplary embodiment of the present disclosure.To further clarify the objectives, technical solutions, and advantages of this disclosure, the technical solutions of this disclosure will be described clearly and completely below in conjunction with specific embodiments of this disclosure and the corresponding drawings. Obviously, the described embodiments represent only a portion of the embodiments of this disclosure, and are not exhaustive. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of this disclosure without inventive effort are within the scope of protection of this disclosure. It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, and displayed data, etc.) involved in this disclosure are all authorized by the user or fully authorized by all parties. The collection, use, and processing of such data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or deny. Furthermore, the various models involved in this disclosure (including but not limited to language models or large models) comply with relevant laws and standards. A distributed database refers to a database system that connects multiple database units distributed across multiple independent physical locations via a computer network to form a logically unified system for data sharing and processing. Each database unit may be referred to as a site or node. Distributed databases are managed through a unified management system, known as a distributed database management system (DDBMS). An example of a distributed database system is PolarDB-X, a cloud-native distributed database system designed for ultra-high concurrency, massive storage, and complex query scenarios. PolarDB-X utilizes a shared-nothing architecture with storage and compute separation, supports horizontal scalability, distributed transactions, and mixed workloads, and offers enterprise-grade, cloud-native, high-availability, and high compatibility with the MySQL (My Structured Query Language) system and ecosystem. In a distributed database system, while each node can determine the success or failure of its own transaction operations, it cannot determine the success or failure of transactions on other nodes.When a transaction spans multiple nodes, to maintain the AC ID (Atomicity, Consistency, Isolation, and Durability) properties of transactions, one node must serve as a coordinator to centrally manage the operation results of other nodes (called participating nodes) and ultimately instruct these participating nodes whether to commit the results (e.g., write updated data to disk). AC ID properties include atomicity, consistency, isolation, and durability. Atomicity means that transactions are treated as indivisible, minimal units; all operations within a transaction must either be performed or not. Consistency means that the integrity of the database is not compromised before and after the transaction begins. This means that written data must fully comply with all pre-set rules, including data accuracy, contiguousness, and the ability for the database to continue operating autonomously. Isolation refers to a database's ability to allow multiple concurrent transactions to read, write, and modify its data simultaneously. Isolation prevents data inconsistencies caused by cross-execution of multiple transactions. Transaction isolation is categorized into different levels, including read uncommitted, read committed, repeatable read, and serializability. Persistence means that once a transaction is committed, changes to the database data are permanent and should not be affected by subsequent operations or failures. During transaction commit, the 2PC protocol addresses transaction consistency issues among participating nodes, ensuring that even if any participating node fails (such as a shutdown or network outage), all participating nodes still maintain a consistent final state. The process of ensuring transaction consistency using the 2PC commit protocol is divided into two phases: prepare and commit. Figure 1 illustrates an interactive diagram of a two-phase commit process in a distributed database system, illustrating an exemplary embodiment. As shown in Figure 1, system 100 may include a coordinating node 101 and participating nodes 102. The connection between the coordinating node 101 and the participating nodes 102 may include various types of wired or wireless connections, which are not limited in this disclosure. In FIG. 1 , DN0 and DNn represent different participating nodes 102.As shown in Figure 1, during the prepare phase, the coordinating node 101 sends a prepare request to each participating node 102 to inquire whether each participating node 102 is ready to commit the transaction. Each participating node 102 then feeds back the transaction status to the coordinating node 101 for it to decide whether to commit or rollback the transaction. During the commit phase, the coordinating node 101 sends an execute request to each participating node 102, instructing it to commit or rollback the transaction. The coordinating node 101 determines the execute request based on the transaction status returned by each participating node 102 during the prepare phase. If all participating nodes 102 return positive responses during the prepare phase, the coordinating node 101 sends a commit request to each participating node 102 during the commit phase, instructing it to commit the transaction. If all participating nodes 102 return negative responses during the prepare phase, the coordinating node 101 sends a rollback request to each participating node 102 during the commit phase, instructing it to rollback the transaction. Furthermore, before the commit phase, the coordinating node initiates a stand-alone transaction and persistently stores a commit record. This record records the final transaction status, allowing participating nodes that experience downtime or network interruptions to restore the transaction status after recovery. In the two-phase commit process described above, the communication between coordinating node 101 and participating node 102 has a round-trip time (RTT). The round-trip time represents the total delay from the sender sending data to the sender receiving a response message from the receiver (the receiver immediately returns a response message after receiving the data). In Figure 1, steps ① and ② can be performed simultaneously, and steps ④ and ⑤ can also be performed simultaneously. For ease of discussion, steps ① and ② can be recorded as one RTT, step ③ as one RTT, and steps ④ and ⑤ as one RTT. In other words, a complete transaction commit process in the two-phase commit process shown in Figure 1 requires three RTTs, resulting in low transaction commit efficiency and significant response delays. Furthermore, in practical applications, to ensure zero data loss, a replica database is often used to ensure continued service even after the primary database fails. This means that the transaction status log must be transferred to the replica database, incurring a new round-trip time (RTT). Therefore, the transmission latency of the entire transaction commit process is often higher than three RTTs. Furthermore, the persistence of the transaction status log in step 3 typically involves a complete transaction. This means that persisting the transaction status log itself is relatively expensive, further increasing the overall transaction response latency.Furthermore, the transaction status log in step ③ needs to be inserted into a log table. When this log table contains a large number of records, it needs to be cleaned up, which introduces complexity and instability to maintenance and operations. To address the above technical issues, in an embodiment of the present disclosure, the process of persisting the transaction status log at the coordinating node is decentralized to each participating node. Each participating node uses a state storage area to persistently record the transaction status of each transaction during the submission process and ultimately maintain the completion status of each transaction. After a participating node fails and recovers, transaction recovery can be performed based on the transaction status of each transaction persistently recorded by the participating node. This not only ensures that all participating nodes maintain a consistent final state after any participating node fails or the network is interrupted, but also saves the coordinating node from persisting the transaction status log, reduces transaction submission response latency, and improves throughput. The following, in conjunction with the accompanying drawings, details the technical solutions provided by various embodiments of the present disclosure. Figure 2 is a schematic structural diagram of a distributed transaction processing system provided by an exemplary embodiment of the present disclosure. As shown in Figure 2, the system includes: multiple transaction processing nodes. If the distributed transaction processing system is implemented as a distributed database system, the multiple transaction processing nodes may include management nodes, storage nodes, and computing nodes. If the distributed transaction processing system is implemented as a distributed application system, these transaction processing nodes may include computing nodes that host applications or services. During transaction processing, the multiple transaction processing nodes can be divided into coordinating nodes 201 and participating nodes 202, with multiple participating nodes 202 typically present. For different transactions, different transaction processing nodes may act as coordinating nodes 201, serving as the main body of the transaction submission process, prompting participating nodes 202 to execute transaction operations, thereby ensuring that all participating nodes 202 corresponding to the transaction maintain consistent transaction submission results when submitting the transaction. For example, in a distributed database system, the management node may serve as the coordinating node, or a computing node may serve as the coordinating node; in a distributed application system, a computing node may serve as the coordinating node. In the embodiments of the present disclosure, the implementation form of the distributed transaction processing system is not limited. Taking a target transaction as an example, the system includes a coordinating node 201 and multiple participating nodes 202 corresponding to the target transaction. Coordinating node 201 can be the node responsible for creating the target transaction, such as a management node or a computing node. Other computing nodes and / or storage nodes that need to participate in the target transaction processing serve as participating nodes 202. Coordinating node 201 and multiple participating nodes 202 cooperate with each other to complete the transaction submission process of the target transaction.In this embodiment, an improved two-phase transaction commit process is employed to offload the coordinating node 201's transaction status log persistence process to each participating node 202. In this improved two-phase transaction commit process, the coordinating node 201 primarily sends prepare and execute requests to participating nodes 202 and no longer persists the transaction status log. At the same time, participating nodes 202 are also added with transaction status persistence operations. This not only facilitates transaction recovery after failure recovery, but also reduces transaction commit response latency. In this embodiment, after transaction status persistence operations are offloaded to each participating node, if a participating node 202 experiences a downtime or network interruption during the commit phase and is unable to receive an execute request from the coordinating node 201, transaction recovery can be performed based on the persistently stored transaction status of the participating node 202 after recovery or network restoration. In this embodiment, for ease of description, downtime or network interruption of a participating node 202 is referred to as a failure. In the embodiments of the present disclosure, the implementation method for recovering a participating node 202 that fails during the commit phase based on the persistently stored transaction state of other participating nodes 202 is not limited. Depending on the implementation method of transaction recovery, the improved two-phase transaction commit process provided in the embodiments of the present disclosure may also vary. The embodiments of the present disclosure provide two specific implementations, each of which is described below. In conjunction with the interactive flowchart of a complete transaction processing shown in Figure 3a, one implementation of the first improved two-phase transaction commit process is described. Specifically, see Figure 3a: Phase 1: Transaction Initiation Process: Step 1a: Coordinating node 201 responds to a user request and initiates the target transaction. The type of target transaction depends on the specific application scenario. In banking scenarios, target transactions may include deposit transactions, withdrawal transactions, remittance transactions, and inquiry transactions; in online shopping scenarios, target transactions may include order transactions and payment transactions; and in domestic service scenarios, target transactions may include online recruitment transactions and online settlement transactions. In step 2a, in response to a user request to initiate a target transaction, coordinating node 201 sends a transaction initiation command to multiple participating nodes 202 associated with the target transaction, instructing the participating nodes 202 to allocate a persistent state storage area for the target transaction. In step 3a, the participating nodes 202 receive the transaction initiation command sent by coordinating node 201 for the target transaction and allocate a persistent state storage area for the target transaction. The state storage area is used to record the transaction status of the target transaction.In this embodiment, when coordinating node 201 initiates a target transaction in response to a user request, it may determine multiple participating nodes 202 associated with the target transaction. Furthermore, coordinating node 201 may also divide the multiple participating nodes 202 into a primary participating node and other participating nodes. This embodiment does not limit the manner in which the multiple participating nodes 202 are divided into primary participating nodes and other participating nodes. Optionally, the coordinating node may select a primary participating node from the multiple participating nodes based on performance parameters and / or load information of the multiple participating nodes, and notify the other participating nodes of the identification information of the primary participating node. For example, the coordinating node may select a participating node with relatively stable network performance as the primary participating node based on the performance parameters of the multiple participating nodes, such as the network stability performance of each participating node. Alternatively, the coordinating node may select a participating node with high throughput as the primary participating node based on the throughput performance of each participating node. Alternatively, the coordinating node may select a participating node with a relatively low response delay (e.g., less than a set response delay threshold) as the primary participating node based on the response delay of each participating node. This may occur in various other ways. For another example, the coordinating node may select a participating node with a smaller load (e.g., less than a set load threshold) as the primary participating node based on the load information of multiple participating nodes. Of course, the coordinating node may also select the primary participating node from the multiple participating nodes based on the performance parameters and load information of the multiple participating nodes. In addition to selecting the primary participating node from the multiple participating nodes based on the performance parameters and / or load information of the multiple participating nodes, the coordinating node may also randomly select a node from the multiple participating nodes as the primary participating node and notify the other participating nodes of the identification information of the primary participating node. In this embodiment, the coordinating node 201 sends a transaction start command to the multiple participating nodes 202. This notifies these participating nodes 202 to prepare to participate in the processing of the target transaction. The transaction start command includes the identification information of the target transaction, which uniquely identifies the target transaction. It also instructs these participating nodes 202 to allocate a state storage area for the target transaction that can persistently store the state information of the target transaction. The coordinating node 201 sends the transaction start command to the multiple participating nodes 202 in a parallel process. That is, the transaction start command can be sent to multiple participating nodes 202 simultaneously, and this process consumes one round-trip time (RTT).When a target transaction begins, participating node 202 allocates a state storage area for the target transaction based on the transaction start command. This state storage area can be an area in the persistent storage medium of participating node 202, used to store the transaction state of the target transaction during the transaction commit process. The stored transaction state changes with the target transaction's commit phase until it reaches a completed state, which is either a committed state or a rollback state. In an optional embodiment, the state storage area can reuse the target transaction's transaction slot. When a target transaction begins, participating node 202 allocates a transaction slot for the target transaction. The transaction slot is used to store various information during the execution of the target transaction, including but not limited to target transaction identification information and transaction slot status information. Optionally, to preserve the original function of the transaction slot, a new field can be added to the transaction slot to store the target transaction's transaction state during the two-phase commit process. In the disclosed embodiment, the target transaction's transaction states during the commit process can be categorized into the following: active, prepare, commit, and rollback states. The active state is optional and can serve as the initial state of the target transaction. Specifically, when allocating a state storage area for the target transaction, participating node 202 can add the target transaction's identification information to the state storage area and initialize the target transaction's transaction state in the state storage area to active. The following describes the various transaction storage states, using the example of implementing the state storage area as a transaction slot, in conjunction with Table 1. GTR ID represents the global transaction ID number. Each global transaction has a unique ID number. STATE represents the transaction state during the commit process. For example, 'COMMIT' indicates that the transaction is committed, 'ROLLBACK' indicates that the transaction has been rolled back, and 'ACTIVE' indicates that the transaction has just been activated. The lifecycle management of the transaction slot of any transaction is described as follows:

[0002] 1. When a transaction starts, a transaction slot is allocated for the transaction, the GTR ID information is filled in the transaction slot, and STATE is marked as ACTIVE.

[0003] 2. When the transaction enters the Prepare phase of the commit process, the STATE of the transaction slot is changed to the PREPARE state.

[0004] 3. When the transaction enters the Comm it / Roll Back phase of the commit process, the STATE of the transaction slot is changed to Comm it or ROLLBACK state.

[0005] 4. When the transaction slot is no longer needed, it is cleared and its storage space is reclaimed. Phase 2: Transaction Commit Process: Step 4a: Coordinating node 201 sends a prepare request to multiple participating nodes 202, prompting them to perform a transaction prepare operation and record the target transaction's transaction status as prepared in the status storage area. Step 5a: Upon receiving the prepare request from coordinating node 201, multiple participating nodes 202 perform the transaction prepare operation and record the target transaction's transaction status as prepared in the status storage area. Step 6a: Multiple participating nodes 202 return transaction prepare operation execution result information to coordinating node 201, allowing coordinating node 201 to determine an execution request for the target transaction based on the information. In this case, the coordinating node 201 initiates a prepare request for a target transaction to multiple participating nodes 102, inquiring whether each participating node 202 can commit the target transaction. After receiving the prepare request, each participating node 102 locally performs transaction prepare operations related to the target transaction to determine whether the target transaction can be committed. It also persistently stores the log generated by the transaction prepare operation, referred to as the prepare log, and returns the transaction prepare operation's execution result information to the coordinating node 201. This execution result information may be a positive result indicating that the target transaction can be committed, or a negative result indicating that the target transaction cannot be committed. The prepare log may also be referred to as the first transaction log. It should be noted that the transaction prepare operations vary depending on the target transaction. Transaction prepare operations refer to operations that must be completed before the target transaction is committed. Taking a transfer transaction as an example, the transaction prepare operation includes at least deducting the transfer amount from a first account, adding the corresponding transfer amount to a second account, and generating a log of deducting the transfer amount from the first account and adding the corresponding transfer amount to the second account as the prepare log. The prepare log is then persistently stored. Of course, if the transfer process also involves issuing transfer reminders to users associated with the two accounts, the transaction preparation operation also includes sending a reminder notification to the relevant transfer reminder system so that the transfer reminder system can remind the relevant users when the transfer transaction is successfully submitted, and generating a log for sending the reminder notification to the relevant transfer reminder system. Optionally, if the preparation log is successfully stored, indicating that the transaction preparation operation has been successfully completed and the target transaction has been prepared for submission, a positive result indicating that the target transaction can be submitted is returned to the coordinating node 201. If the preparation log is not successfully stored, indicating that at least part of the transaction preparation operation has not been successfully completed or cannot be completed, and the target transaction cannot be prepared for submission, a negative result indicating that the target transaction can be submitted is returned to the coordinating node 201.In this embodiment, if a participating node 202 is able to return a positive result indicating the target transaction is submitted to the coordinating node, the transaction state of the target transaction recorded in the state storage area may be updated or recorded as the prepared state. If a negative result indicating the target transaction is submitted to the coordinating node is returned, the transaction state of the target transaction recorded in the state storage area may be updated or recorded as the rolled back state. Of course, if a participating node 202 returns a negative result indicating the target transaction is submitted to the coordinating node, the transaction state of the target transaction recorded in the state storage area may remain unchanged, for example, in the empty or active state. Furthermore, it is also possible to uniformly update or record the transaction state of the target transaction recorded in the state storage area as the prepared state, regardless of whether the participating node 202 returns a positive or negative result to the coordinating node 201. If the reference node 202 returns a negative result indicating the target transaction is submitted to the coordinating node but updates or records the transaction state of the target transaction recorded in the state storage area as the prepared state, the prepared state may be updated to the rolled back state during the execution phase. It should be noted that updating or recording the transaction status of the target transaction recorded in the state storage area as prepared can also be considered part of the transaction prepare operation, and of course, it can also be considered an operation independent of the transaction prepare operation. Recording the transaction status of the target transaction as prepared in the state storage area can also be referred to as the process of persisting the prepared state of the target transaction. In some embodiments, recording the transaction status of the target transaction as prepared in the state storage area includes: adding a first operation command to a first transaction log (or prepare log) generated by executing the transaction prepare operation, the first operation command indicating that the transaction status of the target transaction is recorded as prepared in the state storage area; and executing the first operation command during the process of persistently storing the first transaction log to record the transaction status of the target transaction as prepared in the state storage area. Persistently storing the first transaction log refers to storing the first transaction log in a persistent storage medium of a participating node, such as a hard disk or flash memory. In this alternative embodiment, the target transaction's prepare status and transaction log are persisted in the same process. This eliminates the need for additional persistence procedures. This only adds an additional operation command to the transaction log and executes an additional persistence message, resulting in minimal overhead. In the aforementioned process, the coordinating node 201 sends a prepare request to each participating node 202 in parallel. Correspondingly, the multiple participating nodes 202 return execution result information to the coordinating node 201 in parallel. The entire process consumes one round-trip time (RTT).After receiving the execution result information returned by each participating node 202, the coordinating node can perform statistical analysis on the execution result information. If all participating nodes 202 return positive results, it can be determined that the target transaction can be committed, and a commit request is sent to each participating node 202. If the execution result information returned by each participating node 202 includes negative results, it is determined that the target transaction cannot be committed and needs to be rolled back, and a rollback request is sent to each participating node 202. In other words, the execution request in this embodiment can be either a commit request or a rollback request, depending on the execution result information returned by each participating node 202. In the disclosed embodiment, participating nodes 202 are divided into a primary participating node and other participating nodes. Both the primary participating node and other participating nodes can maintain the final completion status of the target transaction. However, the transaction recovery process is based on the final completion status of the target transaction maintained by the primary participating node. Therefore, it is necessary to prioritize ensuring that the primary participating node can successfully maintain the final completion status of the target transaction to avoid inconsistent transaction commit results. Based on the above, in the submission phase, the coordinating node needs to first send an execution request to the primary participating node 202, and then send an execution request to other participating nodes 202 after receiving the execution completion message returned by the primary participating node. For details, see steps 7a-9a and steps 10a-12a. oStep 7a: Coordinating node 202 sends an execution request to the primary participating node, prompting the primary participating node to perform a transaction completion operation and update the transaction status of the target transaction recorded in the status storage area to the completed state. Step 8a: Upon receiving the execution request sent by coordinating node 201, the primary participating node performs a transaction completion operation and updates the transaction status of the target transaction recorded in the status storage area to the completed state, which may be either the committed state or the rollback state. Step 9a: The primary participating node returns an execution completion message to coordinating node 201. Step 10a: Upon receiving the execution completion message from the primary participating node, the coordinating node sends an execution request to the other participating nodes, prompting them to perform a transaction completion operation and update the transaction status of the target transaction to the completed state. Step 11a: Upon receiving the execution request sent by the coordinating node, the other participating nodes perform a transaction completion operation and update the transaction status of the target transaction recorded in the status storage area to the completed state. Step 12a: The other participating nodes return an execution completion message to the coordinating node. In this embodiment, the coordinating node 201 sends an execution request to the primary participating node and other participating nodes, informing each participating node 202 to commit or rollback the target transaction. Accordingly, the transaction completion operation primarily involves executing a commit operation or a rollback operation on the target transaction, persistently storing the log generated by the transaction completion operation, referred to as the completion log, and returning a transaction completion message to the coordinating node 201. The completion log can also be referred to as a secondary transaction log. In this embodiment, participating nodes can also update the preparation state of the target transaction recorded in the state storage area to the completion state, i.e., the commit state or the rollback state. This process can be referred to as persisting the target transaction's completion state. In some embodiments, updating the transaction status of the target transaction recorded in the status storage area to a completed state includes: adding a second operation command to a second transaction log generated by executing a transaction completion operation, the second operation command indicating that the transaction status of the target transaction recorded in the status storage area is updated to a completed state; and executing the second operation command during persistent storage of the second transaction log to update the transaction status of the target transaction recorded in the status storage area to a completed state. Persistent storage of the second transaction log refers to storing the second transaction log in a persistent storage medium of a participating node, such as a hard disk or flash memory. In this optional embodiment, the completion status of the target transaction is persisted in the same process as the transaction log. This does not add any additional persistence processes. It only requires the addition of an operation command to the transaction log and the execution of an additional persistence message, resulting in minimal additional overhead.It should be noted that updating the prepared state of the target transaction recorded in the state storage area to the completed state can also be considered part of the transaction completion operation. Of course, it can also be considered an operation independent of the transaction completion operation. In this embodiment, steps 7a-9a are first executed to send an execution request to the primary participating node and receive an execution completion message returned by the primary participating node, consuming one RTT. Then, steps 10a-12a are executed to send execution requests to other participating nodes and receive execution completion messages returned by them. Sending execution requests to other participating nodes is a parallel operation, and accordingly, the other participating nodes returning execution completion messages are also parallel operations. Steps 10a-12a consume one RTT. An analysis of the second-phase transaction commit process shows that, from the perspective of the primary participating node, transaction commit is completed in two RTTs, saving one RTT compared to the traditional two-phase commit process. From the perspective of other participating nodes, although three RTTs are still required, since steps 7a-9a are simple information exchanges within the same transaction commit process, a new transaction commit process is not restarted, resulting in a simpler and more efficient operation. Therefore, the improved transaction commit process provided by the embodiments of the present disclosure not only solves the problem of inconsistent transaction commit results caused by various factors, but also saves the operation of persisting the transaction status log on the coordinating node, thereby reducing transaction commit response latency and improving transaction commit efficiency. In actual applications, when the coordinating node sends execution requests to other participating nodes, the other participating nodes may experience various failures such as downtime or network interruption, resulting in the inability to receive the execution request sent by the coordinating node and commit or rollback the target transaction, ultimately leading to inconsistent transaction commit results with other participating nodes. After the failed participating node recovers, it can initiate the transaction recovery process to restore the status of each transaction in which it participates. Based on this, the process shown in FIG3a further includes, after step 12a, the following: Phase 3: Transaction Recovery Process: Step 13a: After recovery, for the other participating nodes that experienced the failure, scan the transaction status in each local state storage area to obtain the first transaction in the prepared state; Step 14a: Based on the identification information of the first transaction, send a first transaction status acquisition request to the primary participating node, so that the primary participating node obtains the completion status of the first transaction from the local state storage area responsible for recording the transaction status of the first transaction and returns it; Step 15a: Based on the completion status of the first transaction returned by the primary participating node, perform a commit operation or a rollback operation on the first transaction in executing the transaction recovery process.In this embodiment, each participating node maintains a local state storage area corresponding to each transaction in which it participates. The state storage area stores the transaction status of each transaction. The transaction status of each transaction varies depending on the current commit state of the transaction, and may be active, prepared, committed, or rolled back. By scanning the local state storage areas, the transaction status of each transaction can be obtained, and transactions in the committed and rolled back states can be filtered out to determine transactions in the prepared and active states. For transactions in the active state, a rollback operation can be performed directly. For transactions in the prepared state (referred to as first transactions), there can be one or more first transactions. For any of these first transactions, a first transaction status acquisition request can be sent to the primary reference node, with the first transaction identification information included in the first transaction status acquisition request. The primary reference node can also receive first transaction status acquisition requests from other participating nodes after failure recovery. Based on the first transaction identification information carried in the first transaction status acquisition request, it queries the locally maintained first transaction corresponding state storage area, obtains the completion status of the first transaction from the first transaction corresponding state storage area, and returns this completion status to the other participating nodes after failure recovery. This allows the other participating nodes after failure recovery to perform a commit or rollback operation on the first transaction during the transaction recovery process based on the completion status of the first transaction returned by the primary participating node, thereby achieving consistency in transaction commit results. With reference to the interactive flow chart of complete transaction processing shown in FIG3b, an implementation of the second improved two-phase transaction commit process is described. Specifically, see FIG3b: Phase 1: Transaction Initiation Process: Step 1b: Coordinating node 201 responds to a user request and initiates the target transaction. In step 2b, when initiating a target transaction, the coordinating node 201 sends a transaction initiation command to the multiple participating nodes 202 associated with the target transaction, instructing the participating nodes to allocate a persistent state storage area for the target transaction. In step 3b, the multiple participating nodes 202 receive the transaction initiation command sent by the coordinating node for the target transaction and allocate a persistent state storage area for the target transaction. The state storage area is used to record the transaction state of the target transaction. In this embodiment, when initiating a target transaction in response to a user request, the coordinating node 201 can determine the multiple participating nodes 202 associated with the target transaction. In this embodiment, the multiple participating nodes 202 are not divided; all participating nodes 202 have the same or equal identities.In this embodiment, the coordinating node 201 sends a transaction start command to multiple participating nodes 202. This command notifies these participating nodes 202 to prepare to participate in processing the target transaction. The transaction start command includes identification information of the target transaction, which uniquely identifies the target transaction. It also instructs these participating nodes 202 to allocate a state storage area for the target transaction that can persistently store the state information of the target transaction. The coordinating node 201 sends the transaction start command to multiple participating nodes 202 in a parallel process. That is, the transaction start command can be sent to multiple participating nodes 202 simultaneously. This process consumes one RTTo. A description of the state storage area and transaction status can be found in the previous embodiment and will not be repeated here. Phase 2: Transaction Commit Process: Step 4b: Coordinating node 201 sends a prepare request to multiple participating nodes 202, prompting them to perform a transaction prepare operation and record the target transaction's transaction status as prepared in their state storage area. Step 5b: Upon receiving the prepare request from coordinating node 201, multiple participating nodes 202 perform a transaction prepare operation and record the target transaction's transaction status as prepared in their state storage area. Step 6b: Multiple participating nodes 202 return transaction prepare operation execution result information to coordinating node 201, allowing coordinating node 201 to determine an execution request for the target transaction based on the information. A detailed description of steps 4b-6b can be found in the description of steps 4a-6a in the aforementioned embodiment and will not be repeated here. In step 7b, coordinating node 201 sends an execution request to multiple participating nodes 202, enabling them to perform a transaction completion operation and update the transaction status of the target transaction recorded in the status storage area to a completed state, which can be a committed state or a rollback state. In step 8b, upon receiving the execution request sent by coordinating node 201, multiple participating nodes 202 perform a transaction completion operation and update the transaction status of the target transaction recorded in the status storage area to a completed state. In step 9b, multiple participating nodes 202 return an execution completion message to coordinating node 201. In this embodiment, the identities of the multiple participating nodes 202 are equal. The sending of execution requests by coordinating node 201 to the multiple participating nodes 202 is a parallel process. Accordingly, the returning of execution completion messages by the multiple participating nodes 202 to the coordinating node 201 is also a parallel process. The entire process of steps 7b-9b consumes one RTTo. For other descriptions of steps 7b-9b, refer to the description of steps 7a-12a in the aforementioned embodiment and will not be repeated here.An analysis of the second-phase transaction commit process reveals that, from the perspective of each participating node, transaction commit can be completed in two RTTs, saving one RTT compared to the traditional two-phase commit process. The improved transaction commit process provided by the disclosed embodiments not only addresses the issue of inconsistent transaction commit results caused by various factors, but also reduces the need for the coordinating node to persist the transaction status log, thereby reducing overall transaction commit response latency and improving transaction commit efficiency. In actual applications, while the coordinating node is sending execution requests to other participating nodes, the other participating nodes may experience various failures, such as downtime or network outages. This can result in the inability to receive the execution request sent by the coordinating node and, consequently, the inability to commit or rollback the target transaction, ultimately leading to inconsistent transaction commit results with other participating nodes. Once the failed participating node recovers, it can initiate a transaction recovery process to restore the status of each transaction in which it participated. Based on this, the process shown in FIG3b further includes, after step 9b, the following: Phase 3: Transaction Recovery Process: Step 10b: After recovery, the participating node that experienced the failure scans the transaction status in each local state storage area to obtain the third transaction in the prepared state. Step 11b: Based on the identification information of the third transaction, the participating node sends a third transaction status acquisition request to other participating nodes, so that the other participating nodes can obtain the transaction status of the third transaction from the local state storage area responsible for recording the transaction status of the third transaction and return it. Step 12b: Based on the current transaction status of the third transaction returned by the other participating nodes, the completion status of the third transaction is determined, and based on the completion status of the third transaction, a commit operation or a rollback operation is performed on the third transaction during the transaction recovery process. In this embodiment, each participating node maintains a local state storage area corresponding to each transaction in which it participates. The state storage area stores the transaction status of the corresponding transaction. The transaction status of these transactions varies depending on the current commit status of the transaction and may be active, prepared, committed, or rolled back. By scanning local state stores, the transaction status of each transaction can be obtained. Transactions in the committed and rollback states are filtered out, and transactions in the prepared and active states are identified. Active transactions can be directly rolled back. For transactions in the prepared state (referred to as third transactions), there can be one or more third transactions. For any third transaction, a third transaction status acquisition request can be sent to other participating nodes, with the third transaction identification information included in the third transaction status acquisition request.Other participating nodes can receive a third transaction status acquisition request sent by the recovered participating node. Based on the identification information of the third transaction carried in the third transaction status acquisition request, they can query a locally maintained third transaction corresponding state storage area, obtain the current transaction state of the third transaction from the third transaction corresponding state storage area, and return the current transaction state of the third transaction to the recovered participating node. This allows the recovered participating node to determine the completion state of the third transaction based on the current transaction state of the third transaction returned by the other participating nodes. Based on the completion state of the third transaction, the node can then commit or rollback the third transaction during the transaction recovery process, thereby achieving consistency in transaction commit results. In this embodiment, the term "other participating nodes" refers to participating nodes other than the recovered participating node. This differs from the concept of "other participating nodes" in the embodiment shown in FIG3a , where other participating nodes are non-primary participating nodes relative to the primary participating node. Furthermore, when determining the completion state of the third transaction based on the current transaction state of the third transaction returned by the other participating nodes, the determination can be flexible based on application requirements. Two examples are given below. In one example, if the current transaction status of the third transaction returned by other participating nodes is all in the committed state, the completion status of the third transaction is determined to be the committed state. Conversely, if any of the current transaction statuses of the third transaction returned by other participating nodes is in a non-committed state (such as the prepared state, rolled back state, or active state), the completion status of the third transaction is determined to be the rolled back state. In another example, if any of the current transaction statuses of the third transaction returned by other participating nodes is in the committed state, the completion status of the third transaction is determined to be the committed state. Conversely, if all of the current transaction statuses of the third transaction returned by other participating nodes are in a non-committed state, the completion status of the third transaction is determined to be the rolled back state. For example, after a participating node recovering from a failure enters the transaction recovery process, it first scans the state storage areas corresponding to all transactions and searches for the transaction status of each transaction based on the GTR ID recorded in the state storage area. Transactions in the active state are directly rolled back, and transactions in the prepared state are retrieved from other participating nodes for their transaction status. The transaction status returned by multiple participating nodes may be as follows: 1. The transaction status maintained by at least one participating node is in the COMPIT state; 2. The transaction status maintained by at least one participating node is in the ROLLBACK state; 3. The transaction status maintained by at least one participating node is in the ACTIVE state; 4. The transaction status maintained by all participating nodes is in the PREPARE state.Accordingly, based on the transaction status maintained by other participating nodes, an exemplary manner in which a participating node after failure recovery executes a transaction recovery process for a transaction in the PREPARE state is as follows: 1. If the transaction status maintained by at least one participating node is in the COMPIT state, the transaction in the PREPARE state is driven to COMMIT; 2. If the transaction status maintained by at least one participating node is in the ROLLBACK state, the transaction in the PREPARE state is driven to ROLLBACK; 3. If the transaction status maintained by at least one participating node is in the ACTIVE state, the transaction in the PREPARE state is driven to ROLLBACK; 4. If the transaction status maintained by all participating nodes is in the PREPARE state, the transaction in the PREPARE state is driven to ROLLBACK. It should be noted that the process of a participating node after failure recovery sending a third transaction status acquisition request to other participating nodes is a parallel process, consuming one RTTo. For the participating node after failure recovery, transaction status recovery is performed based on the transaction status maintained by other participating nodes, achieving consistency in transaction commit results. This shows that, while achieving consistency in transaction commit results, the transaction commit process reduces at least one round-trip time (RTT) for each participating node, significantly improving the performance of the distributed database. Testing has shown that the improved solution provided in this embodiment can improve performance by approximately 20% compared to the traditional two-phase transaction commit solution. It should be noted that the two improved solutions provided in the disclosed embodiments utilize a persistent state memory area to store transaction status. During the fault recovery process, since the recovered participating node needs to query each local state memory area, other participating nodes or the master participating node also need to query the corresponding transaction state storage area. This may require more disk I / O operations and slow down the transaction recovery process. Compared to the traditional solution in which the coordinating node persists the transaction state log, during the fault recovery process, all transaction states can be obtained through a single read request to the transaction state log table, eliminating the need for individual queries, which consumes less disk I / O and speeds up the transaction state recovery process. However, the transaction state recovery process is only initiated in rare circumstances, such as crashes or network outages. Therefore, it is valuable to improve the efficiency of the less frequent transaction commit process at the expense of a less frequent transaction state recovery process. Figure 4 is a flow chart of a distributed transaction processing method provided by an exemplary embodiment of the present disclosure. As shown in Figure 4, the method is applied to a coordinating node in a distributed transaction processing system and includes:

[0006] 401. When starting a target transaction, a transaction start command is sent to multiple participating nodes associated with the target transaction to instruct the multiple participating nodes to allocate a persistent state storage area for the target transaction. The multiple participating nodes are divided into a primary participating node and other participating nodes.

[0007] 402. Send a prepare request to multiple participating nodes, so that the multiple participating nodes perform a transaction prepare operation and record the transaction status of the target transaction as a prepare state in a state storage area;

[0008] 403. Send an execution request to the primary participating node, so that the primary participating node executes the transaction completion operation and updates the transaction status of the target transaction recorded in the status storage area to the completed state; and

[0009] 404. When the primary participating node returns an execution completion message, it sends an execution request to other participating nodes, allowing them to perform transaction completion operations and update the transaction status of the target transaction to a completed state, which may be a committed state or a rollback state. Further, optionally, the method further includes: selecting a primary participating node from the multiple participating nodes based on the performance parameters and / or load information of the multiple participating nodes; and notifying the other participating nodes of the identification information of the primary participating node, allowing the other participating nodes to perform a recovery process on the target transaction based on the completion status of the target transaction recorded by the primary participating node. It should be noted that the specific implementation principles of the above steps can be found in the corresponding content of the above-mentioned method embodiments and will not be repeated here. Figure 5 is a flow diagram of another distributed transaction processing method provided by another exemplary embodiment of the present disclosure. As shown in Figure 5, the method is applied to a coordinating node in a distributed transaction processing system and includes:

[0010] 501. When starting a target transaction, a transaction start command is sent to multiple participating nodes associated with the target transaction to instruct the multiple participating nodes to allocate a persistent state storage area for the target transaction. The identities of the multiple participating nodes are equal.

[0011] 502. Send a prepare request to multiple participating nodes, so that the multiple participating nodes perform a transaction prepare operation and record the transaction state of the target transaction as a prepare state in a state storage area;

[0012] 503. Send an execution request to multiple participating nodes, so that the participating nodes execute the transaction completion operation and update the transaction status of the target transaction recorded in the status storage area to a completed state, where the completed state is either a rollback state or a rollback state. It should be noted that the specific implementation principles of the above steps can be found in the corresponding content of the above-mentioned method embodiments and will not be repeated here. FIG6 is a flow diagram of another distributed transaction processing method provided in another exemplary embodiment of the present disclosure. As shown in FIG6, the method is applied to a first participating node in a distributed transaction processing system and includes:

[0013] 601. Receive a transaction start command sent by a coordinating node for a target transaction, allocate a persistent state storage area for the target transaction, and use the state storage area to record the transaction state of the target transaction.

[0014] 602. Upon receiving the prepare request sent by the coordinating node, execute the transaction prepare operation and record the transaction state of the target transaction as prepared in the state storage area;

[0015] 603. Upon receiving the execution request sent by the coordinating node, perform a transaction completion operation and update the transaction status of the target transaction recorded in the status storage area to a completed state, where the completed state is either a committed state or a rolled back state. Further, optionally, after allocating a persistent status storage area for the target transaction, the method further includes: adding identification information of the target transaction to the status storage area, and initializing the transaction status of the target transaction to an active state in the status storage area. In some embodiments, recording the transaction status of the target transaction as a prepared state in the status storage area includes: adding a first operation command to a first transaction log generated by executing the transaction prepare operation, the first operation command indicating that the transaction status of the target transaction is recorded as a prepared state in the status storage area; and executing the first operation command during persistent storage of the first transaction log to record the transaction status of the target transaction as a prepared state in the status storage area. In some embodiments, updating the transaction status of the target transaction recorded in the status storage area to a completed state includes: adding a second operation command to a second transaction log generated by executing a transaction completion operation, the second operation command indicating that the transaction status of the target transaction recorded in the status storage area is updated to a completed state; and executing the second operation command during persistent storage of the second transaction log to update the transaction status of the target transaction recorded in the status storage area to a completed state. Furthermore, optionally, the multiple participating nodes associated with the target transaction are divided into a primary participating node and other participating nodes. When the first participating node is another participating node, the method further includes: after failure recovery, scanning the transaction status in each local status storage area of ​​the first participating node to obtain a first transaction in a prepared state; sending a first transaction status acquisition request to the primary participating node based on identification information of the first transaction, for the primary participating node to obtain the completion status of the first transaction from the local status storage area responsible for recording the transaction status of the first transaction and return the request; and performing a commit operation or a rollback operation on the first transaction during the transaction recovery process based on the completion status of the first transaction returned by the primary participating node. Further optionally, the multiple participating nodes associated with the target transaction are divided into a primary participating node and other participating nodes. In a case where the first participating node is the primary participating node, the method further includes: receiving a second transaction status acquisition request sent by a second participating node, the second transaction status acquisition request including identification information of the second transaction, and the second participating node being one of the other participating nodes; acquiring, according to the second transaction status acquisition request, a completion status of the second transaction from a local status storage area responsible for recording the transaction status of the second transaction; and sending the completion status of the second transaction to the second participating node, so that the second participating node can perform a commit operation or a rollback operation on the second transaction during a transaction recovery process.Further optionally, for identity objects of multiple participating nodes associated with the target transaction, the method further includes: after failure recovery, scanning transaction states in each local state storage area of ​​the first participating node to obtain a third transaction in a prepared state; sending a third transaction state acquisition request to other participating nodes among the multiple participating nodes based on identification information of the third transaction, so that the other participating nodes obtain the current transaction state of the third transaction from a local state storage area responsible for recording the transaction state of the third transaction and return the request; determining a completion state of the third transaction based on the current transaction state of the third transaction returned by the other participating nodes; and performing a commit operation or a rollback operation on the third transaction in a transaction recovery process based on the completion state of the third transaction. In some embodiments, determining the completion status of the third transaction based on the current transaction status of the third transaction returned by other participating nodes includes: if the current transaction status of the third transaction returned by other target participating nodes is all in the committed state, determining the completion status of the third transaction to be the committed state; otherwise, determining the completion status of the third transaction to be the rollback state; or if any of the current transaction statuses of the third transaction returned by other participating nodes is in the committed state, determining the completion status of the third transaction to be the committed state; otherwise, determining the completion status of the third transaction to be the rollback state. It should be noted that the specific implementation principles of the above steps can be found in the corresponding content of the above-mentioned method embodiments and will not be further elaborated here. Figure 7 is a schematic structural diagram of a distributed transaction processing device provided by an exemplary embodiment of the present disclosure. As shown in FIG7 , the apparatus includes: a sending module 72 configured to, when the starting module 71 starts the target transaction, send a transaction start command to multiple participating nodes associated with the target transaction to instruct the multiple participating nodes to allocate a persistent state storage area for the target transaction. The multiple participating nodes are divided into a primary participating node and other participating nodes; the sending module 72 is further configured to send a prepare request to the multiple participating nodes, so that the multiple participating nodes perform a transaction prepare operation and record the transaction state of the target transaction as a prepared state in the state storage area; the sending module 72 is further configured to send an execute request to the primary participating node, so that the primary participating node performs a transaction complete operation and updates the transaction state of the target transaction recorded in the state storage area to a completed state; and the sending module 72 is further configured to, when the primary participating node returns an execution completion message, send an execute request to the other participating nodes, so that the other participating nodes perform a transaction complete operation and update the transaction state of the target transaction to a completed state, where the completed state is either a committed state or a rollback state.Further optionally, the system further includes a selection module 73 configured to select a master participating node from the multiple participating nodes based on the performance parameters and / or load information of the multiple participating nodes; and to notify the other participating nodes of the identification information of the master participating node, so that the other participating nodes can execute a recovery process for the target transaction based on the completion status of the target transaction recorded by the master participating node. It should be noted that the specific implementation principles of each of the above modules or units can be found in the corresponding content of the above method embodiments and will not be further described here. FIG8 is a schematic structural diagram of another distributed transaction processing device provided by another exemplary embodiment of the present disclosure. As shown in FIG8 , the apparatus includes: a sending module 82 configured to, when the target transaction is initiated by the initiating module 81, send a transaction initiation command to multiple participating nodes associated with the target transaction, instructing the participating nodes to allocate a persistent state storage area for the target transaction. The identities of the participating nodes are equal. The sending module 82 is further configured to send a prepare request to the participating nodes, instructing them to perform a transaction prepare operation and record the transaction status of the target transaction in the state storage area as prepared. The sending module 82 is further configured to send an execute request to the participating nodes, instructing them to perform a transaction complete operation and update the transaction status of the target transaction recorded in the state storage area to completed, where the completed state is either committed or rolled back. It should be noted that the specific implementation principles of the above modules or units can be found in the corresponding content of the above method embodiments and will not be further elaborated here. FIG9 is a schematic structural diagram of yet another distributed transaction processing apparatus provided by yet another exemplary embodiment of the present disclosure. As shown in FIG9 , the apparatus includes: a receiving module 91 configured to receive a transaction start command sent by a coordinating node for a target transaction, and allocate a persistent state storage area to the target transaction via an allocation module 92. The state storage area is used to record the transaction status of the target transaction; an execution module 93 configured to, upon receiving a prepare request sent by the coordinating node, perform a transaction prepare operation and record the transaction status of the target transaction as prepared in the state storage area; and further configured to, upon receiving an execute request sent by the coordinating node, perform a transaction complete operation and update the transaction status of the target transaction recorded in the state storage area to completed, where the completed status is either a rollback state or a rollback state. Optionally, after the allocation module 92 allocates the persistent state storage area to the target transaction, the execution module 93 is further configured to add identification information of the target transaction to the state storage area and initialize the transaction status of the target transaction in the state storage area to active.In some embodiments, when recording the target transaction's transaction status as prepared in the status storage area, the execution module 93 is specifically configured to: add a first operation command to a first transaction log generated by executing a transaction prepare operation, the first operation command indicating that the target transaction's transaction status is recorded as prepared in the status storage area; and, during persistent storage of the first transaction log, execute the first operation command to record the target transaction's transaction status as prepared in the status storage area. In some embodiments, when updating the target transaction's transaction status recorded in the status storage area to completed, the execution module 93 is specifically configured to: add a second operation command to a second transaction log generated by executing a transaction complete operation, the second operation command indicating that the target transaction's transaction status recorded in the status storage area is updated to completed; and, during persistent storage of the second transaction log, execute the second operation command to update the target transaction's transaction status recorded in the status storage area to completed. Further optionally, the multiple participating nodes associated with the target transaction are divided into a primary participating node and other participating nodes. In the case where the first participating node is another participating node, the execution module 93 is further configured to: after failure recovery, scan the transaction status in each local state storage area of ​​the first participating node to obtain the first transaction in the prepared state; send a first transaction status acquisition request to the primary participating node based on the identification information of the first transaction, so that the primary participating node obtains the completion status of the first transaction from the local state storage area responsible for recording the transaction status of the first transaction and returns the request; and perform a commit operation or a rollback operation on the first transaction in executing the transaction recovery process based on the completion status of the first transaction returned by the primary participating node. Further optionally, the multiple participating nodes associated with the target transaction are divided into a primary participating node and other participating nodes. When the first participating node is the primary participating node, the execution module 93 is further configured to: receive a second transaction status acquisition request sent by a second participating node, where the second transaction status acquisition request includes identification information of the second transaction, and the second participating node is one of the other participating nodes; obtain, according to the second transaction status acquisition request, the completion status of the second transaction from a local status storage area responsible for recording the transaction status of the second transaction; and send the completion status of the second transaction to the second participating node, so that the second participating node can perform a commit operation or a rollback operation on the second transaction during the transaction recovery process.Further optionally, for the identity objects of the multiple participating nodes associated with the target transaction, the execution module 93 is further configured to: after failure recovery, scan the transaction status in each local state storage area of ​​the first participating node to obtain a third transaction in a prepared state; send a third transaction status acquisition request to other participating nodes among the multiple participating nodes based on the identification information of the third transaction, so that the other participating nodes obtain the current transaction status of the third transaction from the local state storage area responsible for recording the transaction status of the third transaction and return the request; determine the completion status of the third transaction based on the current transaction status of the third transaction returned by the other participating nodes; and perform a commit operation or a rollback operation on the third transaction in executing the transaction recovery process based on the completion status of the third transaction. In some embodiments, when determining the completion status of the third transaction based on the current transaction status of the third transaction returned by other participating nodes, the execution module 93 is specifically configured to: if the current transaction status of the third transaction returned by the other target participating nodes is all in the committed state, determine the completion status of the third transaction as the committed state; otherwise, determine the completion status of the third transaction as the rollback state; or if the current transaction status of the third transaction returned by the other participating nodes is in the committed state, determine the completion status of the third transaction as the committed state; otherwise, determine the completion status of the third transaction as the rollback state. It should be noted that the specific implementation principles of each of the above modules or units can be found in the corresponding content of the above method embodiments and will not be repeated here. Figure 10 is a schematic structural diagram of an electronic device provided by an exemplary embodiment of the present disclosure. As shown in FIG10 , the electronic device includes: a memory 100a and a processor 100b; the memory 100a stores a computer program, and the processor 100b is coupled to the memory 100a and configured to execute the computer program to perform the following steps: when a target transaction is initiated, sending a transaction initiation command to multiple participating nodes associated with the target transaction to instruct the multiple participating nodes to allocate a persistent state storage area for the target transaction, where the multiple participating nodes are divided into a primary participating node and other participating nodes; sending a prepare request to the multiple participating nodes to cause the multiple participating nodes to perform a transaction prepare operation and record the transaction state of the target transaction in the state storage area as a prepared state; sending an execute request to the primary participating node to cause the primary participating node to perform a transaction complete operation and update the transaction state of the target transaction recorded in the state storage area to a completed state; and when the primary participating node returns an execution completion message, sending an execute request to the other participating nodes to cause the other participating nodes to perform a transaction complete operation and update the transaction state of the target transaction to a completed state, where the completed state is either a committed state or a rollback state.Further optionally, the processor 100b is further configured to: select a master participating node from the multiple participating nodes according to performance parameters and / or load information of the multiple participating nodes; and notify other participating nodes of identification information of the master participating node, so that the other participating nodes can execute a recovery process for the target transaction based on the completion status of the target transaction recorded by the master participating node. Accordingly, based on the same composition structure as the above-mentioned electronic device, the electronic device still includes: a memory 100a and a processor 100b; the memory 100a stores a computer program, and the processor 100b is coupled to the memory 100a and configured to execute the computer program to perform the following steps: when a target transaction is initiated, sending a transaction start command to multiple participating nodes associated with the target transaction to instruct the multiple participating nodes to allocate a persistent state storage area for the target transaction, where the identities of the multiple participating nodes are equal; sending a prepare request to the multiple participating nodes to enable the multiple participating nodes to perform a transaction prepare operation and record the transaction state of the target transaction as a prepare state in the state storage area; and sending an execute request to the multiple participating nodes to enable the multiple participating nodes to perform a transaction complete operation and update the transaction state of the target transaction recorded in the state storage area to a completed state, where the completed state is a committed state or a rollback state. Accordingly, based on the same composition structure as the above-mentioned electronic device, the electronic device still includes: a memory 100a and a processor 100b; the memory 100a stores a computer program, and the processor 100b is coupled to the memory 100a and configured to execute the computer program to perform the following steps: receiving a transaction start command sent by the coordinating node for a target transaction, allocating a persistent state storage area for the target transaction, where the state storage area is used to record the transaction state of the target transaction; upon receiving a prepare request sent by the coordinating node, performing a transaction prepare operation and recording the transaction state of the target transaction as prepared in the state storage area; upon receiving an execute request sent by the coordinating node, performing a transaction complete operation and updating the transaction state of the target transaction recorded in the state storage area to completed, where the completed state is either committed or rolled back. Further, optionally, after allocating the persistent state storage area for the target transaction, the processor 100b is further configured to: add identification information of the target transaction to the state storage area, and initialize the transaction state of the target transaction in the state storage area to active.In some embodiments, to record the transaction status of the target transaction as prepared in the status storage area, the processor 100b is further configured to: add a first operation command to a first transaction log generated by executing a transaction prepare operation, the first operation command indicating that the transaction status of the target transaction is recorded as prepared in the status storage area; and, during persistent storage of the first transaction log, execute the first operation command to record the transaction status of the target transaction as prepared in the status storage area. In some embodiments, to update the transaction status of the target transaction recorded in the status storage area to completed, the processor 100b is further configured to: add a second operation command to a second transaction log generated by executing a transaction complete operation, the second operation command indicating that the transaction status of the target transaction recorded in the status storage area is updated to completed; and, during persistent storage of the second transaction log, execute the second operation command to update the transaction status of the target transaction recorded in the status storage area to completed. Further optionally, the multiple participating nodes associated with the target transaction are divided into a primary participating node and other participating nodes. In a case where the first participating node is another participating node, the processor 100b is further configured to: after failure recovery, scan the transaction status in each local state storage area of ​​the first participating node to obtain a first transaction in a prepared state; send a first transaction status acquisition request to the primary participating node based on identification information of the first transaction, so that the primary participating node obtains the completion status of the first transaction from a local state storage area responsible for recording the transaction status of the first transaction and returns the request; and perform a commit operation or a rollback operation on the first transaction in a transaction recovery process based on the completion status of the first transaction returned by the primary participating node. Further optionally, the multiple participating nodes associated with the target transaction are divided into a primary participating node and other participating nodes. In a case where the first participating node is the primary participating node, the processor 100b is further configured to: receive a second transaction status acquisition request sent by a second participating node, where the second transaction status acquisition request includes identification information of the second transaction, and the second participating node belongs to the other participating nodes; acquire, according to the second transaction status acquisition request, the completion status of the second transaction from a local status storage area responsible for recording the transaction status of the second transaction; and send the completion status of the second transaction to the second participating node, so that the second participating node can perform a commit operation or a rollback operation on the second transaction during a transaction recovery process.Further optionally, for the identity objects of multiple participating nodes associated with the target transaction, the processor 100b is further configured to: after failure recovery, scan the transaction status in each local state storage area of ​​the first participating node to obtain a third transaction in a prepared state; send a third transaction status acquisition request to other participating nodes among the multiple participating nodes based on the identification information of the third transaction, so that the other participating nodes obtain the current transaction status of the third transaction from the local state storage area responsible for recording the transaction status of the third transaction and return the request; determine the completion status of the third transaction based on the current transaction status of the third transaction returned by the other participating nodes; and perform a commit operation or a rollback operation on the third transaction in a transaction recovery process based on the completion status of the third transaction. In some embodiments, the completion status of the third transaction is determined based on the current transaction status of the third transaction returned by other participating nodes. The processor 100b is further configured to: if the current transaction status of the third transaction returned by the other target participating nodes is all in the committed state, determine the completion status of the third transaction as the committed state; otherwise, determine the completion status of the third transaction as the rollback state; or if the current transaction status of the third transaction returned by the other participating nodes is in the committed state, determine the completion status of the third transaction as the committed state; otherwise, determine the completion status of the third transaction as the rollback state. Furthermore, as shown in FIG10 , the electronic device further includes other components, such as a communication component 100c, a display 100d, a power supply component 100e, and an audio component 100f. FIG10 schematically illustrates only some components and does not imply that the electronic device includes only the components shown in FIG10 . It should be noted that the specific implementation principles of each of the above modules or units can be found in the corresponding content of the above method embodiments and will not be further elaborated here. An exemplary embodiment of the present disclosure further provides a computer-readable storage medium storing a computer program / instructions. When the computer program / instructions are executed by a processor, the processor is enabled to implement the steps of the above-described method. An exemplary embodiment of the present disclosure further provides a computer program product. The computer program product includes the computer program / instructions. When the computer program / instructions are executed by a processor, the processor is enabled to implement the steps of the above-described method.The aforementioned memory may be implemented by any type of volatile or non-volatile memory device, or a combination thereof, such as static random-access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The aforementioned communication component is configured to facilitate wired or wireless communication between the device in which the communication component is located and other devices. The device containing the communication component can access a wireless network based on a communication standard, such as WiFi, 2G, 3G, 4G / LTE, 5G, or other mobile communication networks, or a combination thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication component also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID), infrared data association (IRDA), ultra-wideband (UWB), Bluetooth (BT), or other technologies. The aforementioned display includes a screen, which can include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, it can be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, slides, and gestures on the touch panel. The touch sensors can detect not only the boundaries of a touch or slide action, but also the duration and pressure associated with the touch or slide action. The aforementioned power supply assembly provides power to various components of the device in which it resides.The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power for the device in which the power supply component resides. The aforementioned audio component may be configured to output and / or input audio signals. For example, the audio component may include a microphone (MIC) configured to receive external audio signals when the device in which the audio component resides is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals may be further stored in a memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals. Those skilled in the art will appreciate that embodiments of the present disclosure may be provided as methods, systems, or computer program products. Therefore, the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present disclosure may take the form of a computer program product implemented on one or more computer-readable storage media (including but not limited to magnetic disk storage, compact disc read-only memory (CD-ROM), optical storage, etc.) containing computer-usable program code. The present disclosure is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present disclosure. It should be understood that each process flow and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts 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, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, such that the instructions, when executed by the processor of the computer or other programmable data processing device, produce means for implementing the functions specified in one or more processes in the flowcharts and / or one or more blocks in the block diagrams. These computer program instructions can also be stored in a computer-readable memory capable of directing the computer or other programmable data processing device to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means that implement the functions specified in one or more processes in the flowcharts and / or one or more blocks in the block diagrams. These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory. Memory may include non-permanent storage in computer-readable media, random access memory (RAM), and / or non-volatile memory, such as read-only memory (ROM) or flash memory. Memory is an example of a computer-readable medium. Computer-readable media, including permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media such as modulated data signals and carrier waves. It should also be noted that the terms "comprise," "include," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, product, or apparatus comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, product, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising a..." does not preclude the presence of additional identical elements in the process, method, product, or apparatus comprising the element. The foregoing are merely examples of the present disclosure and are not intended to limit the present disclosure. Various modifications and variations of the present disclosure will readily occur to those skilled in the art.Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of this disclosure should be included in the scope of the claims of this disclosure.

Claims

Claims 1. A distributed transaction processing method, applied to a coordinating node in a distributed transaction processing system, the method comprising: In the case of starting a target transaction, a transaction start command is sent to multiple participating nodes associated with the target transaction to instruct the multiple participating nodes to allocate a persistent state storage area for the target transaction, where the multiple participating nodes are divided into a master participating node and other participating nodes; a prepare request is sent to the multiple participating nodes to cause the multiple participating nodes to perform a transaction prepare operation and record the transaction state of the target transaction as prepared in the state storage area; Sending an execution request to the primary participating node so that the primary participating node performs a transaction completion operation and updates the transaction status of the target transaction recorded in the status storage area to a completed state; and in a case where the primary participating node returns an execution completion message, sending the execution request to the other participating nodes so that the other participating nodes perform a transaction completion operation and update the transaction status of the target transaction to a completed state, where the completed state is a committed state or a rollback state.

2. The method according to claim 1, further comprising: selecting a master participating node from the plurality of participating nodes according to performance parameters and / or load information of the plurality of participating nodes; Notify the other participating nodes of the identification information of the primary participating node, so that the other participating nodes can perform a recovery process on the target transaction based on the completion status of the target transaction recorded by the primary participating node.

3. A distributed transaction processing method, applied to a coordinating node in a distributed transaction processing system, the method comprising: In the case of starting a target transaction, a transaction start command is sent to multiple participating nodes associated with the target transaction to instruct the multiple participating nodes to allocate a persistent state storage area for the target transaction, where the identities of the multiple participating nodes are equal; a prepare request is sent to the multiple participating nodes to enable the multiple participating nodes to perform a transaction prepare operation and record the transaction state of the target transaction as a prepare state in the state storage area; and an execute request is sent to the multiple participating nodes to enable the multiple participating nodes to perform a transaction complete operation and update the transaction state of the target transaction recorded in the state storage area to a completed state, where the completed state is a commit state or a rollback state.

4. A distributed transaction processing method, applied to a first participating node in a distributed transaction processing system, comprising: receiving a transaction start command sent by a coordinating node for a target transaction, and allocating a persistent state storage area for the target transaction, wherein the state storage area is used to record a transaction state of the target transaction; Upon receiving the prepare request sent by the coordinating node, executing a transaction prepare operation, and recording in the state storage area that the transaction state of the target transaction is a prepare state; When receiving the execution request sent by the coordinating node, the transaction completion operation is performed, and the transaction status of the target transaction recorded in the status storage area is updated to a completion status, where the completion status is a commit status or a rollback status.

5. The method according to claim 4, further comprising, after allocating a persistent state storage area for the target transaction: The identification information of the target transaction is added to the state storage area, and the transaction state of the target transaction is initialized to an active state in the state storage area.

6. The method according to claim 4 or 5, wherein recording the transaction status of the target transaction as a prepared state in the status storage area comprises: Add a first operation command to the first transaction log generated by executing the transaction preparation operation, wherein the first operation command table indicating that the transaction state of the target transaction recorded in the state storage area is a prepared state; During persistent storage of the first transaction log, the first operation command is executed to record the transaction state of the target transaction in the state storage area as a preparation state.

7. The method according to any one of claims 4 to 6, updating the transaction status of the target transaction recorded in the status storage area to a completed state, comprising: Adding a second operation command in a second transaction log generated by executing a transaction completion operation, wherein the second operation command indicates updating the transaction status of the target transaction recorded in the status storage area to a completed state; During the process of persistently storing the second transaction log, the second operation command is executed to update the transaction status of the target transaction recorded in the status storage area to a completed state.

8. The method according to any one of claims 4 to 7, wherein the plurality of participating nodes associated with the target transaction are divided into a primary participating node and other participating nodes, and when the first participating node is the other participating node, the method further comprises: After the failure is recovered, scanning the transaction status in each local status storage area of the first participating node to obtain the first transaction in the prepared state; Sending a first transaction status acquisition request to the primary participating node according to the identification information of the first transaction, so that the primary participating node acquires the completion status of the first transaction from a local status storage area responsible for recording the transaction status of the first transaction and returns the completed status; According to the completion status of the first transaction returned by the primary participating node, a commit operation or a rollback operation is performed on the first transaction in a transaction recovery process.

9. The method according to any one of claims 4 to 7, wherein the plurality of participating nodes associated with the target transaction are divided into a primary participating node and other participating nodes, and when the first participating node is the primary participating node, the method further comprises: receiving a second transaction status acquisition request sent by a second participating node, the second transaction status acquisition request including identification information of the second transaction, and the second participating node belonging to the other participating nodes; acquiring, based on the second transaction status acquisition request, a completion status of the second transaction from a local status storage area responsible for recording the transaction status of the second transaction; and sending the completion status of the second transaction to the second participating node, so that the second participating node can perform a commit operation or a rollback operation on the second transaction during a transaction recovery process.

10. The method according to any one of claims 4 to 7, wherein the identity objects of multiple participating nodes associated with the target transaction further comprise: After the failure is recovered, scanning the transaction status in each local status storage area of the first participating node to obtain a third transaction in a prepared state; sending, based on the identification information of the third transaction, a third transaction status acquisition request to other participating nodes among the plurality of participating nodes, so that the other participating nodes obtain the current transaction status of the third transaction from a local status storage area responsible for recording the transaction status of the third transaction and return the information; determining a completion status of the third transaction based on the current transaction status of the third transaction returned by the other participating nodes; According to the completion status of the third transaction, a commit operation or a rollback operation is performed on the third transaction in the transaction recovery process.

11. The method according to claim 10, wherein determining the completion status of the third transaction according to the current transaction status of the third transaction returned by the other participating nodes comprises: If the current transaction states of the third transaction returned by the other participating nodes are all in the committed state, determining the completion state of the third transaction to be the committed state; otherwise, determining the completion state of the third transaction to be the rollback state; Alternatively, if the current transaction status of the third transaction returned by the other participating nodes is in the committed state, the completion state of the third transaction is the committed state; otherwise, the completion state of the third transaction is determined to be the rollback state.

12. An electronic device, comprising: memory and processor; The memory stores a computer program, and the processor is coupled to the memory and configured to execute the computer program to implement the steps of the method according to any one of claims 1 to 2 or 3 or 4 to 11.

13. A computer-readable storage medium storing a computer program / instruction, which, when executed by a processor, enables the processor to implement the steps of the method according to any one of claims 1 to 2 or 3 or 4 to 11.

14. A computer program product, comprising a computer program / instruction, which, when executed by a processor, causes the processor to implement the steps of the method according to any one of claims 1 to 2 or 3 or 4 to 11.

Images