Transaction distributed processing method and system, transaction management node and program product

Abstract

The invention relates to a distributed transaction processing method and system, a transaction management node and a program product, and relates to the technical field of data management. The distributed transaction processing method is executed by a transaction management node, and comprises the following steps: determining a plurality of transaction participation nodes according to a target transaction submitted by a client, and determining whether the plurality of transaction participation nodes support processing of the target transaction; under the condition that the multiple transaction participation nodes support processing of the target transaction, according to the identifier of the target transaction submitted by the client, one target transaction participation node is determined in the multiple transaction participation nodes, and the target transaction participation node is used for recording a log of the target transaction; and performing distributed processing on the target transaction according to the recording condition of the log of the target transaction.

Description

Technical Field

[0001] This disclosure relates to the field of data management technology, and in particular to a distributed transaction processing method, system, transaction management node, and program product. Background Technology

[0002] With the rapid development of the Internet, distributed processing methods for transactions are becoming increasingly common. In the process of distributed transaction processing, achieving stable and efficient transaction processing is a key issue. Summary of the Invention

[0003] Research has found that in related technologies, the logs of all transactions are stored in a global coordinating node (or component) during the distributed processing of transactions. When this global coordinating node fails, the distributed processing of all transactions will fall into an infinite wait. Therefore, how to ensure the stability and efficiency of the distributed processing of transactions is a problem that needs to be solved.

[0004] In view of the above, this disclosure proposes a distributed transaction processing method. According to some embodiments of the first aspect of this disclosure, a distributed transaction processing method is provided, executed by a transaction management node, comprising: determining multiple transaction participant nodes based on a target transaction submitted by a client, and determining whether the multiple transaction participant nodes support processing the target transaction; if the multiple transaction participant nodes support processing the target transaction, determining a target transaction participant node among the multiple transaction participant nodes based on the identifier of the target transaction submitted by the client, wherein the target transaction participant node is used to record a log of the target transaction; and performing distributed processing on the target transaction based on the recording status of the target transaction's log.

[0005] In some embodiments, determining a target transaction participant node among multiple transaction participant nodes based on the identifier of the target transaction submitted by the client includes: determining the target transaction participant node corresponding to the identifier of the target transaction among multiple transaction participant nodes according to the mapping rules between the transaction identifier and the transaction participant nodes used to record transaction logs.

[0006] In some embodiments, determining the target transaction participant node corresponding to the target transaction identifier among multiple transaction participant nodes according to the mapping rules between the transaction identifier and the transaction participant nodes used to record the transaction log includes: calculating the remainder between the target transaction identifier and the number of multiple transaction participant nodes; and determining the target transaction participant node among multiple transaction participant nodes according to the correspondence between the remainder and the target transaction participant node.

[0007] In some embodiments, distributed processing of a target transaction based on the log records of the target transaction includes: periodically scanning at least one of the multiple transaction participant nodes to obtain the scan result of the target transaction; determining whether the target transaction is an aborted transaction based on the scan result of the target transaction; and, if the target transaction is an aborted transaction, performing distributed processing of the target transaction among the multiple transaction participant nodes based on the log records of the target transaction.

[0008] In some embodiments, distributed processing of the target transaction in multiple transaction participant nodes based on the log recording status of the target transaction includes: if the target transaction participant node successfully records the log of the target transaction, performing consistency processing on the target transaction in multiple transaction participant nodes based on the log of the target transaction.

[0009] In some embodiments, the log of the target transaction includes the identifier of the target transaction and the status of the target transaction. The status of the target transaction includes success and termination. According to the log of the target transaction, the consistency processing of the target transaction among multiple transaction participant nodes includes: sending a processing request to multiple transaction participant nodes when the status of the target transaction is success; and sending a rollback request to multiple transaction participant nodes when the status of the target transaction is termination, so that the multiple transaction participant nodes can perform a rollback operation on the target transaction.

[0010] In some embodiments, the distributed processing of the target transaction among multiple transaction participant nodes based on the log recording status of the target transaction further includes: sending an instruction to the target transaction participant node to determine the status of the target transaction as terminated if the target transaction participant node fails to record the log of the target transaction, so that the target transaction participant node records the log of the target transaction.

[0011] In some embodiments, the transaction management node includes a new transaction management node selected in the event of an anomaly in the original transaction management node, and the transaction participant node includes a new transaction participant node selected in the event of an anomaly in the original transaction participant node.

[0012] In some embodiments, determining whether a target transaction is an aborted transaction based on the scan result of the target transaction includes: if the scan result is the first scan result, determining that the target transaction is an aborted transaction in response to the scan result including the target transaction; if the scan result is not the first scan result, determining whether the target transaction is an aborted transaction based on the scan result at the current time and the scan result at the previous time.

[0013] In some embodiments, determining whether a target transaction is an aborted transaction based on the scan result at the current moment and the scan result at the previous moment includes: in response to the scan result at the current moment including the target transaction and the scan result at the previous moment including the target transaction, determining that the target transaction is an aborted transaction.

[0014] In some embodiments, determining multiple transaction participant nodes based on the target transaction submitted by the client, and determining whether the multiple transaction participant nodes support processing the target transaction, includes: determining multiple transaction participant nodes based on the target transaction submitted by the client; sending preparation requests to the multiple transaction participant nodes; and determining whether the multiple transaction participant nodes support processing the target transaction based on the response information of the preparation requests returned by the multiple transaction participant nodes.

[0015] In some embodiments, the distributed transaction processing method further includes: when there is a transaction participant node among the multiple transaction participant nodes that does not support processing the target transaction, sending a rollback request to the multiple transaction participant nodes so that the multiple transaction participant nodes can perform a rollback operation on the target transaction.

[0016] In some embodiments, the transaction management node is determined based on the target transaction submitted by the client.

[0017] According to some embodiments of the second aspect of this disclosure, a transaction management node is provided, comprising: a first determining unit configured to determine multiple transaction participating nodes based on a target transaction submitted by a client, and to determine whether the multiple transaction participating nodes support processing the target transaction; a second determining unit configured to, if the multiple transaction participating nodes support processing the target transaction, determine a target transaction participating node among the multiple transaction participating nodes based on the identifier of the target transaction submitted by the client, wherein the target transaction participating node is used to record a log of the target transaction; and a processing unit configured to perform distributed processing of the target transaction based on the recording status of the target transaction's log.

[0018] According to some embodiments of the third aspect of this disclosure, a transaction management node is provided, including: a memory and a processor coupled to the memory, the processor being configured to execute the transaction distributed processing method of any of the above embodiments based on instructions stored in the memory.

[0019] According to some embodiments of the fourth aspect of this disclosure, a transaction distributed processing system is provided, comprising: a transaction management node as described in any of the above embodiments; and multiple transaction participant nodes, including a target transaction participant node, wherein the target transaction participant node is configured to record a log of a target transaction.

[0020] According to some embodiments of the fifth aspect of this disclosure, a computer-readable storage medium is provided that stores computer instructions thereon, which, when executed by a processor, implement the transaction distributed processing method of any of the above embodiments.

[0021] According to some embodiments of the sixth aspect of this disclosure, a computer program product is provided, including computer instructions that, when executed by a processor, implement the transaction distributed processing method of any of the above embodiments.

[0022] In the above embodiments, based on the target transaction submitted by the client, multiple transaction participant nodes are determined, and it is determined whether these nodes support the target transaction. If multiple nodes support the target transaction, a target transaction participant node is selected from among them based on the identifier of the target transaction submitted by the client. This target node is used to record the target transaction's log. Finally, based on the log recording status, the target transaction is processed in a distributed manner. By writing the target transaction's log to the target transaction participant node corresponding to the target transaction's identifier, decentralized recording of logs for different transactions is achieved. This reduces the risk of the distributed transaction processing falling into an infinite wait due to problems with the centrally recording node, thus ensuring the stability of the distributed transaction processing. Furthermore, by selecting only one target transaction participant node to record the target transaction's log, the risk of redundant recording during the distributed transaction processing is reduced, as this would occur if all transaction participant nodes recorded the target transaction's log, ensuring the performance and efficiency of the distributed transaction processing. In addition, by determining whether multiple transaction participants support processing the target transaction, it helps to ensure the stability of distributed transaction processing and reduces the risk that the atomicity and consistency of the target transaction cannot be satisfied due to a transaction participant not supporting processing the target transaction. Attached Figure Description

[0023] The accompanying drawings, which form part of this specification, illustrate embodiments of this disclosure and, together with the specification, serve to explain the principles of this disclosure.

[0024] This disclosure can be more clearly understood with reference to the accompanying drawings and the following detailed description.

[0025] Figure 1 Schematic diagrams illustrating some embodiments of the transaction distributed processing method of this disclosure are shown.

[0026] Figure 2 Schematic diagrams illustrating some embodiments of the methods for determining and handling the termination of transactions disclosed herein.

[0027] Figure 3 Schematic diagrams illustrating some other embodiments of the transaction distributed processing method of this disclosure are shown.

[0028] Figure 4 The diagram illustrates some embodiments of the transaction management node of this disclosure.

[0029] Figure 5 Schematic diagrams illustrating other embodiments of the transaction management node of this disclosure are shown.

[0030] Figure 6 Schematic diagrams illustrating some embodiments of the transaction distributed processing system of this disclosure are shown. Detailed Implementation

[0031] Various exemplary embodiments of the present disclosure will now be described in detail with reference to the accompanying drawings. It should be noted that, unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps set forth in these embodiments do not limit the scope of the present disclosure.

[0032] At the same time, it should be understood that, for ease of description, the dimensions of the various parts shown in the accompanying drawings are not drawn according to actual scale.

[0033] The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit this disclosure or its application or use.

[0034] Techniques, methods, and equipment known to those skilled in the art may not be discussed in detail, but where appropriate, they should be considered part of the specification.

[0035] In all examples shown and discussed herein, any specific values ​​should be interpreted as merely exemplary and not as limitations. Therefore, other examples of exemplary embodiments may have different values.

[0036] It should be noted that similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be discussed further in subsequent figures.

[0037] In related technologies, transactions are processed by multiple participating nodes to achieve distributed transaction processing. Multi-round communication controls the commit or rollback of all participating nodes to achieve atomicity and consistency in a distributed environment. Atomicity means that all operations within a transaction either succeed completely or fail completely, while consistency means that the data state of the transactions eventually remains consistent. Furthermore, introducing a global coordinating node to record logs of all transactions helps to achieve atomicity and consistency (transaction consistency means that after one or more transactions are executed, the previously consistent data and the database remain consistent). However, centralizing all transaction logs in the global coordinating node means that if the global coordinating node fails (e.g., the machine hosting the global coordinating node crashes), all participating nodes will enter an indefinite waiting period, significantly impacting the stability and efficiency of the distributed transaction processing.

[0038] To address the issue of how transaction management nodes can ensure the stability and efficiency of distributed transaction processing, this disclosure proposes a distributed transaction processing method, as follows.

[0039] Figure 1 Schematic diagrams illustrating some embodiments of the transaction distributed processing method of this disclosure are shown.

[0040] like Figure 1 As shown, the distributed transaction processing method includes steps 110 to 130, which are executed by the transaction management node. The transaction management node is primarily responsible for initiating, committing, or rolling back transactions across multiple transaction participant nodes (databases). The transaction participant nodes are primarily responsible for receiving and executing instructions or commands (including prepare, commit, rollback, etc.) from the transaction management node and providing feedback on the transaction execution results. Additionally, the transaction management node can also be called a transaction manager (TM) or transaction administrator, and the transaction participant nodes can also be called transaction participants (Resource Manager, RM).

[0041] In step 110, based on the target transaction submitted by the client, multiple transaction participant nodes are identified, and it is determined whether the multiple transaction participant nodes support processing the target transaction.

[0042] For example, a transaction management node includes a new transaction management node selected when the original transaction management node fails, and a transaction participant node includes a new transaction participant node selected when the original transaction participant node fails. The new transaction management node is primarily used to manage abnormal transactions (e.g., aborted transactions) caused by the failure of the original transaction management node.

[0043] A distributed database cluster deploys multiple computing nodes, all of which have the ability to recover from transaction anomalies (such as transaction abort). New transaction management nodes can be determined, for example, through the Raft consensus algorithm.

[0044] In some embodiments, the transaction management node is determined based on the target transaction submitted by the client.

[0045] In step 120, when multiple transaction participant nodes support processing the target transaction, a target transaction participant node is determined among the multiple transaction participant nodes based on the identifier of the target transaction submitted by the client. The target transaction participant node is used to record the log of the target transaction.

[0046] By identifying the target transaction, a target transaction participant node is determined among multiple transaction participant nodes to record the target transaction's log. This target transaction participant node serves as the transaction coordination log (similar to WAL (Write-Ahead Logging)). The target transaction log recorded by the target transaction participant node is the cornerstone of ensuring data persistence and system reliability. Considering that the target transaction log can be sequentially written, optimized, and has crash recovery capabilities, it ensures consistency in the distributed transaction processing process to a certain extent.

[0047] In some embodiments, if there is a transaction participant node among the multiple transaction participant nodes that does not support processing the target transaction, the transaction management node will send a rollback request to the multiple transaction participant nodes so that all multiple transaction participant nodes will perform a rollback operation on the target transaction.

[0048] In step 130, the target transaction is processed in a distributed manner based on the log records of the target transaction.

[0049] In the above embodiments, the distributed transaction processing method implements a distributed processing method that separates computation and storage. Based on the target transaction submitted by the client, multiple transaction participant nodes are determined, and it is determined whether these nodes support the target transaction. If multiple participant nodes support the target transaction, a target transaction participant node is selected from among the multiple participant nodes based on the identifier of the target transaction submitted by the client. This target node is used to record the target transaction's log. Finally, based on the recorded log information, the target transaction is processed in a distributed manner. By writing the target transaction's log to the target transaction participant node corresponding to the target transaction's identifier, decentralized recording of logs for different transactions is achieved. This reduces the risk of the distributed transaction processing falling into an infinite wait state due to problems with the centrally recorded node, thus ensuring the stability of the distributed transaction processing process. Furthermore, by selecting only one target transaction participant node to record the target transaction's log, the risk of redundant recording during the distributed transaction processing process is reduced, as this would occur if all participant nodes recorded the target transaction's log, ensuring the performance and efficiency of the distributed transaction processing process. Furthermore, by determining whether multiple transaction participant nodes support processing the target transaction, the stability of distributed transaction processing is ensured. This reduces the risk that the atomicity and consistency of the target transaction cannot be satisfied due to a participant node's inability to handle it, thus contributing to the guarantee of atomicity and consistency in distributed transaction processing. Moreover, compared to recording all transaction logs in a single global coordinating node, where all participant nodes need to communicate with that global coordinating node, the distributed transaction processing method reduces the number of communications during the distributed transaction processing process, ensuring efficiency. Because the distributed transaction processing method assigns different target participant nodes to different transactions, an anomaly in one target participant node will not affect the target participant nodes of other transactions, reducing the risk of resource locking due to an anomaly in the global coordinating node, which could affect the processing of all transactions.

[0050] In some embodiments, regarding determining multiple transaction participant nodes based on the target transaction submitted by the client, and determining whether the multiple transaction participant nodes support processing the target transaction, the specific steps are as follows: determining multiple transaction participant nodes based on the target transaction submitted by the client; sending preparation requests to the multiple transaction participant nodes; and determining whether the multiple transaction participant nodes support processing the target transaction based on the response information of the preparation requests returned by the multiple transaction participant nodes.

[0051] By sending preparation requests to multiple transaction participant nodes to determine whether they support processing the target transaction, the consistency of the transaction is guaranteed during the distributed processing of the transaction. This reduces the risk of data inconsistency or state splitting of the target transaction due to a transaction participant node not supporting the processing of the target transaction.

[0052] In some embodiments, a target transaction participant node is determined among multiple transaction participant nodes based on the identifier of the target transaction submitted by the client. For example, the target transaction participant node corresponding to the identifier of the target transaction is determined among multiple transaction participant nodes according to the mapping rules between the transaction identifier and the transaction participant nodes used to record the transaction log.

[0053] For example, the mapping rule between the transaction identifier and the transaction participant nodes used to record the transaction log can be the correspondence between the remainder between the transaction identifier and the total number of transaction participant nodes of the transaction and the target transaction participant node of the transaction.

[0054] By mapping the transaction identifier to the transaction participant nodes used to record the transaction log, the target transaction participant node can be determined based on the identifier of the target transaction, thus providing a feasibility for decentralized recording of logs for different transactions.

[0055] In some embodiments, regarding the mapping rules between the transaction identifier and the transaction participant nodes used to record the transaction, the target transaction participant node corresponding to the identifier of the target transaction is determined among multiple transaction participant nodes. For example, the remainder between the identifier of the target transaction and the number of multiple transaction participant nodes is calculated; and the target transaction participant node is determined among multiple transaction participant nodes based on the correspondence between the remainder and the target transaction participant node.

[0056] In some embodiments, regarding the distributed processing of the target transaction based on the log records of the target transaction, the transaction management node can periodically scan at least one of the multiple transaction participant nodes to obtain the scan result of the target transaction; based on the scan result of the target transaction, it is determined whether the target transaction is an aborted transaction; if the target transaction is an aborted transaction, the target transaction is processed in a distributed manner among the multiple transaction participant nodes based on the log records of the target transaction.

[0057] Scanning the transaction participants reveals transactions that have completed the preparation phase but not the commit phase. Specifically, if all relevant transaction participants support processing a transaction, it is considered to have completed the preparation phase. If at least one relevant transaction participant fails to process (or commit) a transaction, it is considered to have not completed the commit phase. Furthermore, the scan result for the target transaction indicates whether it is a transaction that has completed the preparation phase but not the commit phase; that is, whether the target transaction is included among the scanned transactions that have completed the preparation phase but not the commit phase.

[0058] A transaction aborts when either the transaction management node or a participating node malfunctions, preventing the completion of the transaction operation. For example, if the transaction management node malfunctions, participating nodes will remain blocked, unable to receive instructions from the transaction management node. Furthermore, if the transaction management node malfunctions during the commit phase, it can lead to data inconsistency. For instance, some participating nodes might receive the commit request (i.e., process the request) and complete the commit, while other participating nodes fail to receive the commit request and cannot execute the transaction commit, resulting in data inconsistency. Based on the meaning of transaction aborts, to ensure transaction consistency during distributed transaction processing, aborted transactions need to be handled in a distributed manner.

[0059] Determining whether the target transaction is an aborted transaction helps in subsequent distributed processing of aborted transactions, reducing the risk of inconsistency in distributed processing caused by aborted transactions, ensuring consistency and stability of transactions in distributed processing.

[0060] In some embodiments, the transaction management node can periodically scan at least one of the multiple transaction participants to obtain the scan result of the target transaction. This can be achieved by the transaction management node sending a scan command to the transaction participants in the cluster, causing the transaction participants in the cluster to scan themselves to obtain the scan result of the target transaction. The transaction management node can periodically send scan commands to the transaction participants, or it can send a scan command to the transaction management node once, and then the transaction participants perform periodic scans.

[0061] In some embodiments, determining whether a target transaction is an aborted transaction based on the scan results of the target transaction is as follows: if the scan result is the first scan result, in response to the scan result including the target transaction, the target transaction is determined to be an aborted transaction; if the scan result is not the first scan result, the target transaction is determined to be an aborted transaction based on the scan result at the current moment and the scan result at the previous moment.

[0062] Regarding determining whether a target transaction is an aborted transaction based on the scan results at the current moment and the scan results at the previous moment, for example, if both the current scan result and the scan result at the previous moment include the target transaction, then the target transaction is determined to be an aborted transaction. If at least one of the following occurs: the current scan result does not include the target transaction, or the scan result at the previous moment does not include the target transaction, then the target transaction is determined not to be an aborted transaction.

[0063] In some embodiments, the time required from the stage of "determining whether multiple transaction participant nodes support processing the target transaction" to the stage of "multiple transaction participant nodes processing (committing) the target transaction" is generally in the millisecond range, while the scanning period for transaction participant nodes is in the second range (e.g., scanning once every x seconds, where x can be set to a range of 1 to 10). Considering the above scanning characteristics, it is also necessary to determine whether the target transaction is an aborted transaction based on the scanning results of the target transaction, and to determine whether the target transaction is an aborted transaction based on whether it is the first scan, as follows.

[0064] The process of periodically scanning transaction participants and determining whether the target transaction is aborted, and then performing distributed processing on the target transaction if it is aborted, can be called a transaction exception recovery task. If the target transaction is scanned twice consecutively during a non-first execution of the transaction exception recovery task, it is determined to be an aborted transaction. If the target transaction is scanned during the first execution of the transaction exception recovery task, it is determined to be an aborted transaction.

[0065] For example, aborting a transaction can also be called suspending a transaction.

[0066] By determining whether a target transaction is aborted based on whether the transaction exception recovery task is being executed for the first time, different methods are used to ensure the accuracy of determining whether a target transaction is aborted, and also to ensure the stability of the distributed transaction processing.

[0067] The following describes how to determine the logging status of a target transaction. For example, the transaction management node can quickly locate the participating nodes corresponding to the target transaction using the target transaction's identifier, and determine whether those participating nodes have logged the target transaction. Because the location of the participating nodes corresponding to the target transaction can be quickly determined, the efficiency of the distributed transaction processing is ensured.

[0068] In some embodiments, if the target transaction is an aborted transaction, and the participating nodes of the target transaction successfully record the target transaction log, the transaction management node can perform consistency processing on multiple participating nodes based on the target transaction log.

[0069] For example, the target transaction log includes the target transaction identifier (XID) and the target transaction state (State), where the target transaction state includes success (succeed) and aborted (aborted). The target transaction identifier includes a timestamp, logical database name, and shard name, and the logical database name and shard name in the target transaction identifier are metadata information of the target transaction.

[0070] In some embodiments, the log of the target transaction may further include the identifier (DTID) of the sub-target transaction, the address of the node participating in the target transaction (Server_Addr), the number of shards (Shard_Cnt) (i.e., the total number of data shards involved in the target transaction), and the shard list (Shards) (wherein, the shard list is used to record the specific shard identifier of the target transaction operation, such as the database name or table name of the sharded database / table). The data type of the fields for the identifier of the target transaction, the identifier of the sub-target transaction, and the address of the node participating in the target transaction is a variable-length string, which can store a maximum of 512 characters. The data type of the number of shards is an integer, the data type of the shard list is a variable-length string, which can store a maximum of 1024 characters, and the data type of the target transaction status is an enumeration.

[0071] In some embodiments, if the target transaction is in a successful state, the transaction management node will send a processing request to multiple transaction participant nodes. If the target transaction is in a terminated state, the transaction management node will send a rollback request to multiple transaction participant nodes so that the multiple transaction participant nodes can perform a rollback operation on the target transaction.

[0072] For example, if the log of the target transaction is successfully recorded and the status of the target transaction is terminated (where the target transaction is determined to be an aborted transaction by scanning one of the transaction participant nodes among multiple transaction participant nodes), before determining that the status of the target transaction is terminated, it is possible that when scanning other transaction participant nodes of the target transaction, it is determined that the log of the target transaction has failed to be recorded successfully, and the status of the target transaction is recorded as terminated in the log of the target transaction through the target transaction participant node of the target transaction.

[0073] Taking two transaction participants (transaction participant 1 and transaction participant 2) as an example, at the previous moment, transaction participant 1 is scanned and it is determined that the transaction is aborted and the transaction log has not been successfully recorded. At this time, the transaction management node will send an instruction to the target transaction participant node to record the status of the transaction as terminated, so that the target transaction participant node records the transaction log (where the transaction status is terminated). At the current moment, transaction participant 2 is scanned and it is determined that the transaction is aborted. At this time, the transaction log has been successfully recorded at the previous moment, and the status of the transaction is determined to be terminated. The transaction management node will send a rollback request to transaction participant 2, so that transaction participant 2 performs a rollback operation on the transaction.

[0074] If the target transaction is aborted and its log is successfully recorded, different consistency processing is applied to the target transaction based on its state (if the target transaction is successful, commit the target transaction; if the target transaction is terminated, roll back the target transaction), thus ensuring consistency during the distributed processing of transactions.

[0075] In some embodiments, after the transaction management node sends a processing request to multiple transaction participant nodes, if a transaction participant node fails to process (or commits) the target transaction, the transaction participant node will still return an indication message indicating successful processing to the transaction management node. Subsequent periodic scans will scan for transactions that have completed the preparation phase but have not completed the processing node (i.e., aborted transactions) and recommit the aborted transactions.

[0076] By returning a success indication to transactions that fail to commit, and then resubmitting those failed transactions through subsequent scans, consistency of transactions is ensured during distributed transaction processing.

[0077] In some embodiments, if the target transaction is an aborted transaction and the participating nodes of the target transaction fail to record the target transaction log, the transaction management node will send an instruction to the participating nodes of the target transaction to determine the status of the target transaction as terminated, so that the participating nodes of the target transaction record the target transaction log.

[0078] If the target transaction participant node fails to successfully record the target transaction log, it means that the transaction management node has not yet sent processing requests to multiple transaction participant nodes, and therefore there are no transaction participant nodes that have successfully processed the target transaction. Therefore, directly sending an instruction to the target transaction participant node to determine the status of the target transaction as terminated helps to directly roll back the target transaction based on its status (i.e., terminated) when the target transaction is scanned in other transaction participant nodes in the future, which helps to ensure the consistency of transactions in distributed transaction processing.

[0079] Figure 2 Schematic diagrams illustrating some embodiments of the methods for determining and handling the termination of transactions disclosed herein.

[0080] like Figure 2 As shown, the method for judging and handling the termination of transactions includes steps 201 to 210, based on the occurrence of an anomaly in the transaction management node (for example, the machine where the transaction management node is located crashes), as detailed below.

[0081] In step 201, the determination to abort the transaction begins.

[0082] In step 202, a new transaction management node is selected to update the transaction management node that has encountered an error. The new transaction management node is preset. If a new transaction management node cannot be selected, step 210 is executed directly.

[0083] In step 203, the updated transaction management node sends a scan command to multiple transaction participant nodes, so that each transaction participant node periodically scans itself to obtain transactions that have completed the preparation phase. If multiple transaction participant nodes of a certain transaction support processing the transaction, then the transaction has completed the preparation phase.

[0084] In step 204, the updated transaction management node determines whether there are any aborted transactions among the transactions that have completed the preparation phase. The aborted transactions may include the target transaction. If there are no aborted transactions among the transactions that have completed the preparation phase, step 210 is executed directly. If there are aborted transactions among the transactions that have completed the preparation phase, step 205 is executed.

[0085] In step 205, the updated transaction management node determines whether the target transaction participant node corresponding to the aborted transaction has successfully recorded the log of the aborted transaction. If the target transaction participant node corresponding to the aborted transaction has successfully recorded the log of the aborted transaction, then step 206 is executed. If the target transaction participant node corresponding to the aborted transaction has not successfully recorded the log of the aborted transaction, then step 208 is executed directly.

[0086] In some embodiments, the updated transaction management node can determine the target transaction participant node corresponding to the aborted transaction based on the identifier of the aborted transaction.

[0087] In step 206, the updated transaction management node determines the status (success or termination) of the aborted transaction in the log of the aborted transaction. If the status of the aborted transaction in the log of the aborted transaction is success, then step 207 is executed. If the status of the aborted transaction in the log of the aborted transaction is termination, then step 209 is executed directly.

[0088] In step 207, the updated transaction management node sends a commit request (or commit transaction request) to the multiple transaction participant nodes corresponding to the aborted transaction, so that the multiple transaction participant nodes commit the aborted transaction, and then directly execute step 210.

[0089] In step 208, the updated transaction management node sends an instruction to the target transaction participant node of the aborted transaction to determine the status of the aborted transaction as terminated, so that the target transaction participant node of the aborted transaction records the log of the aborted transaction and records the status of the aborted transaction as terminated in the log.

[0090] In step 209, the updated transaction management node sends a rollback request (or rollback transaction request) to the multiple transaction participants corresponding to the aborted transaction, so that the multiple transaction participants perform a rollback operation on the aborted transaction, and then directly executes step 210.

[0091] In step 210, the processing of the aborted transaction is terminated.

[0092] In the event of an anomaly in the transaction management node, the system scans the participating nodes to identify aborted transactions. Based on the log records of these aborted transactions (if the logs are successfully recorded), different actions are taken for each aborted transaction. This ensures that all aborted transactions are either committed or rolled back. In other words, during distributed processing, operations on aborted transactions either all succeed or all fail. This approach guarantees the stability and efficiency of distributed transaction processing, as well as the consistency of transactions during distributed processing, even when the transaction management node malfunctions.

[0093] Figure 3 Schematic diagrams illustrating some other embodiments of the transaction distributed processing method of this disclosure are shown.

[0094] like Figure 3 As shown, taking two transaction participants as an example, the distributed transaction processing method includes steps 310 to 380. Here, the first transaction participant is taken as the target transaction participant node.

[0095] In step 310, the client (or user) submits the target transaction to the transaction management node.

[0096] In step 320, the transaction management node sends a preparation request to the first transaction participant node and the second transaction participant node.

[0097] In step 330, the transaction management node receives a first success indication message sent by the first transaction participant node and the second transaction participant node, wherein the first success indication message is used to indicate that the transaction participant nodes (the first transaction participant node and the second transaction participant node) support processing the target transaction.

[0098] Steps 320 and 330 constitute the preparation phase of the transaction distributed processing method.

[0099] In step 340, the transaction management node sends a recording instruction to the first transaction participant node (i.e., the target transaction participant node). The recording instruction is used to instruct the first transaction participant node to record the target transaction in the log, and the target transaction status in the target transaction log is "succeed".

[0100] In step 350, the first transaction participant node sends a second success indication message to the transaction management node, wherein the second success indication message is used to instruct the first transaction participant node to successfully record the log of the target transaction.

[0101] In step 360, the transaction management node sends a processing request to the first transaction participant node and the second transaction participant node. The processing request can also be called a commit request. The processing request is used to instruct the transaction participant nodes (the first transaction participant node and the second transaction participant node) to process (commit) the target transaction.

[0102] In step 370, the transaction participating nodes (the first transaction participating node and the second transaction participating node) send a third success indication message to the transaction management node, wherein the third success indication message is used to indicate that the transaction participating nodes (the first transaction participating node and the second transaction participating node) have successfully processed the target transaction.

[0103] Steps 360 and 370 constitute the commit phase of the transaction distributed processing method.

[0104] In step 380, the transaction management node sends a fourth success indication message to the client, wherein the fourth success indication message is used to indicate that the target transaction has been successfully processed.

[0105] By determining whether multiple participating nodes support processing the target transaction, the transaction management node helps ensure the stability of distributed transaction processing. This reduces the risk of failing to meet the atomicity and consistency requirements of the target transaction due to a participating node's lack of support, thus contributing to the assurance of atomicity and consistency. Furthermore, by selecting a target participating node to record the target transaction's log, the risk of redundant records during distributed transaction processing is reduced, ensuring performance and efficiency. Finally, success indications from participating nodes are required during both the preparation and commit phases, guaranteeing the atomicity and consistency of transactions throughout the distributed transaction process.

[0106] Figure 4 The diagram illustrates some embodiments of the transaction management node of this disclosure.

[0107] like Figure 4 As shown, the transaction management node 40 includes a first determining unit 41, a second determining unit 42, and a processing unit 43.

[0108] The first determining unit 41 is configured to determine multiple transaction participating nodes based on the target transaction submitted by the client, and to determine whether the multiple transaction participating nodes support processing the target transaction.

[0109] In some embodiments, the transaction management node includes a new transaction management node selected in the event of an anomaly in the original transaction management node, and the transaction participant node includes a new transaction participant node selected in the event of an anomaly in the original transaction participant node.

[0110] In some embodiments, the transaction management node is determined based on the target transaction submitted by the client.

[0111] The second determining unit 42 is configured to determine a target transaction participant node among the multiple transaction participant nodes based on the identifier of the target transaction submitted by the client when multiple transaction participant nodes support processing the target transaction, wherein the target transaction participant node is used to record the log of the target transaction.

[0112] Processing unit 43 is configured to perform distributed processing on the target transaction based on the log records of the target transaction.

[0113] In the above embodiments, the transaction management node determines multiple transaction participant nodes based on the target transaction submitted by the client, and determines whether these nodes support the target transaction. If multiple nodes support the target transaction, a target transaction participant node is selected from among them based on the identifier of the target transaction submitted by the client. This target node is used to record the target transaction's log. Finally, the target transaction is processed in a distributed manner based on the recorded log information. By writing the target transaction's log to the target transaction participant node corresponding to the target transaction's identifier, decentralized recording of logs for different transactions is achieved. This reduces the risk of the distributed transaction processing falling into an infinite wait due to problems with the centrally recording node, thus ensuring the stability of the distributed transaction processing. Furthermore, by selecting only one target transaction participant node to record the target transaction's log, the risk of redundant recording during the distributed transaction processing is reduced, as this would occur if all transaction participant nodes recorded the target transaction's log. This ensures the performance and efficiency of the distributed transaction processing. In addition, by determining whether multiple transaction participants support processing the target transaction, it helps to ensure the stability of distributed transaction processing and reduces the risk that the atomicity and consistency of the target transaction cannot be satisfied due to a transaction participant not supporting processing the target transaction.

[0114] In some embodiments, the first determining unit 41 is further configured to determine multiple transaction participating nodes based on the target transaction submitted by the client; send preparation requests to the multiple transaction participating nodes; and determine whether the multiple transaction participating nodes support processing the target transaction based on the response information of the preparation requests returned by the multiple transaction participating nodes.

[0115] In some embodiments, the second determining unit 42 is further configured to determine, among a plurality of transaction participating nodes, the target transaction participating node corresponding to the identifier of the target transaction based on the mapping rules between the transaction identifier and the transaction participating nodes used to record the transaction log.

[0116] In some embodiments, the second determining unit 42 is further configured to calculate the remainder between the identifier of the target transaction and the number of multiple transaction participating nodes; and determine the target transaction participating node among the multiple transaction participating nodes according to the correspondence between the remainder and the target transaction participating node.

[0117] In some embodiments, the processing unit 43 is further configured to periodically scan at least one of the multiple transaction participants to obtain the scan result of the target transaction; determine whether the target transaction is an aborted transaction based on the scan result of the target transaction; and, if the target transaction is an aborted transaction, perform distributed processing on the target transaction among the multiple transaction participants based on the log record of the target transaction.

[0118] In some embodiments, the processing unit 43 is further configured to, when the scan result is the first scan result, determine that the target transaction is an aborted transaction in response to the scan result including the target transaction; and when the scan result is not the first scan result, determine whether the target transaction is an aborted transaction based on the scan result at the current moment and the scan result at the previous moment.

[0119] In some embodiments, the processing unit 43 is further configured to determine the target transaction as an aborted transaction in response to the current scan result including the target transaction and the previous scan result including the target transaction.

[0120] In some embodiments, if the target transaction participant node successfully records the target transaction log, the processing unit 43 is further configured to perform consistency processing on the target transaction among multiple transaction participant nodes based on the target transaction log.

[0121] In some embodiments, the log of the target transaction includes the identifier of the target transaction and the status of the target transaction. The status of the target transaction includes success and termination. The processing unit 43 is further configured to send a processing request to multiple transaction participants when the status of the target transaction is success; and to send a rollback request to multiple transaction participants when the status of the target transaction is termination, so that the multiple transaction participants can perform a rollback operation on the target transaction.

[0122] In some embodiments, the processing unit 43 is further configured to send an instruction to the target transaction participant node to determine the status of the target transaction as terminated if the target transaction participant node fails to record the log of the target transaction, so that the target transaction participant node records the log of the target transaction.

[0123] In some embodiments, the processing unit 43 is further configured to send a rollback request to multiple transaction participants if there is a transaction participant that does not support processing the target transaction, so that the multiple transaction participants can perform a rollback operation on the target transaction.

[0124] Figure 5 Schematic diagrams illustrating other embodiments of the transaction management node of this disclosure are shown.

[0125] like Figure 5As shown, the transaction management node 40 of this embodiment includes a memory 51 and a processor 52 coupled to the memory 51. The processor 52 is configured to execute the transaction distributed processing method of any of the foregoing embodiments based on instructions stored in the memory 51.

[0126] The memory 51 may include, for example, system memory, fixed non-volatile storage media, etc. The system memory stores, for example, the operating system, application programs, boot loader, and other programs.

[0127] The transaction management node 40 may also include input / output interfaces 53, network interfaces 54, and storage interfaces 55. These interfaces 53, 54, and 55, as well as the memory 51 and processor 52, can be connected via, for example, a bus 56. Specifically, the input / output interface 53 provides a connection interface for input / output devices such as monitors, mice, keyboards, touchscreens, microphones, and speakers. The network interface 54 provides a connection interface for various networked devices. The storage interface 55 provides a connection interface for external storage devices such as SD cards and USB flash drives.

[0128] In the above embodiments, the transaction management node determines multiple transaction participant nodes based on the target transaction submitted by the client, and determines whether these nodes support the target transaction. If multiple nodes support the target transaction, a target transaction participant node is selected from among them based on the identifier of the target transaction submitted by the client. This target node is used to record the target transaction's log. Finally, the target transaction is processed in a distributed manner based on the recorded log information. By writing the target transaction's log to the target transaction participant node corresponding to the target transaction's identifier, decentralized recording of logs for different transactions is achieved. This reduces the risk of the distributed transaction processing falling into an infinite wait due to problems with the centrally recording node, thus ensuring the stability of the distributed transaction processing. Furthermore, by selecting only one target transaction participant node to record the target transaction's log, the risk of redundant recording during the distributed transaction processing is reduced, as this would occur if all transaction participant nodes recorded the target transaction's log. This ensures the performance and efficiency of the distributed transaction processing. In addition, by determining whether multiple transaction participants support processing the target transaction, it helps to ensure the stability of distributed transaction processing and reduces the risk that the atomicity and consistency of the target transaction cannot be satisfied due to a transaction participant not supporting processing the target transaction.

[0129] Figure 6 Schematic diagrams illustrating some embodiments of the transaction distributed processing system of this disclosure are shown.

[0130] like Figure 6 As shown, the transaction distributed processing system 60 includes the transaction management node 40 and multiple transaction participant nodes 61 in any of the above embodiments.

[0131] The multiple transaction participant nodes 61 include a target transaction participant node, wherein the target transaction participant node is configured to record a log of the target transaction.

[0132] In the above embodiments, the transaction management node determines multiple transaction participant nodes based on the target transaction submitted by the client, and determines whether these nodes support the target transaction. If multiple nodes support the target transaction, a target transaction participant node is selected from among them based on the identifier of the target transaction submitted by the client. This target node is used to record the target transaction's log. Finally, the target transaction is processed in a distributed manner based on the recorded log information. By writing the target transaction's log to the target transaction participant node corresponding to the target transaction's identifier, decentralized recording of logs for different transactions is achieved. This reduces the risk of the distributed transaction processing falling into an infinite wait due to problems with the centrally recording node, thus ensuring the stability of the distributed transaction processing. Furthermore, by selecting only one target transaction participant node to record the target transaction's log, the risk of redundant recording during the distributed transaction processing is reduced, as this would occur if all transaction participant nodes recorded the target transaction's log. This ensures the performance and efficiency of the distributed transaction processing. In addition, by determining whether multiple transaction participants support processing the target transaction, it helps to ensure the stability of distributed transaction processing and reduces the risk that the atomicity and consistency of the target transaction cannot be satisfied due to a transaction participant not supporting processing the target transaction.

[0133] In some embodiments, a computer program product is protected, comprising a computer program or instructions that, when executed by a processor, implement the transaction-distributed processing method described above. The computer program product includes a computer program carried on a computer-readable medium, containing program code for performing the methods shown in the flowchart. In such embodiments, the computer program can be downloaded and installed from a network via a transaction management node, or installed from a storage device, or installed from ROM. When the computer program is executed by the CPU, it performs the functions defined in the methods of embodiments of this disclosure.

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

[0135] This concludes the detailed description of the distributed transaction processing method, system, transaction management node, and program product of this disclosure. To avoid obscuring the concept of this disclosure, some details known in the art have not been described. Those skilled in the art can fully understand how to implement the technical solutions disclosed herein based on the above description.

[0136] The methods and systems of this disclosure may be implemented in many ways. For example, they may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order of steps for the methods is for illustrative purposes only, and the steps of the methods of this disclosure are not limited to the order specifically described above unless otherwise specifically stated. Furthermore, in some embodiments, this disclosure may also be implemented as a program recorded on a recording medium, the program including machine-readable instructions for implementing the methods according to this disclosure. Thus, this disclosure also covers recording media storing programs for performing the methods according to this disclosure.

[0137] While specific embodiments of this disclosure have been described in detail by way of example, those skilled in the art should understand that the examples are for illustrative purposes only and not intended to limit the scope of this disclosure. Those skilled in the art should understand that modifications can be made to the above embodiments without departing from the scope and spirit of this disclosure. The scope of this disclosure is defined by the appended claims.

Claims

1. A distributed transaction processing method, executed by a transaction management node, comprising: Based on the target transaction submitted by the client, identify multiple transaction participating nodes and determine whether the multiple transaction participating nodes support processing the target transaction; When the plurality of transaction participating nodes support processing the target transaction, a target transaction participating node is determined from the plurality of transaction participating nodes according to the identifier of the target transaction submitted by the client, wherein the target transaction participating node is used to record the log of the target transaction; Based on the log records of the target transaction, the target transaction is processed in a distributed manner.

2. The transaction distributed processing method according to claim 1, wherein, The step of determining a target transaction participant node from among the plurality of transaction participant nodes based on the identifier of the target transaction submitted by the client includes: Based on the mapping rules between the transaction identifier and the transaction participant nodes used to record the transaction log, the target transaction participant node corresponding to the identifier of the target transaction is determined among the plurality of transaction participant nodes.

3. The transaction distributed processing method according to claim 2, wherein, The step of determining the target transaction participant node corresponding to the identifier of the target transaction from among the plurality of transaction participant nodes according to the mapping rules between the transaction identifier and the transaction participant nodes used to record the transaction log includes: Calculate the remainder between the identifier of the target transaction and the number of the multiple transaction participating nodes; Based on the correspondence between the remainder and the target transaction participant node, the target transaction participant node is determined among the plurality of transaction participant nodes.

4. The transaction distributed processing method according to claim 1, wherein, The step of performing distributed processing on the target transaction based on the log records of the target transaction includes: At least one of the multiple transaction participants is periodically scanned to obtain the scan result of the target transaction; Based on the scan results of the target transaction, determine whether the target transaction is an aborted transaction; If the target transaction is the aborted transaction, the target transaction is processed in a distributed manner among the multiple transaction participating nodes according to the log record of the target transaction.

5. The transaction distributed processing method according to claim 4, wherein, The step of distributing the target transaction among the multiple transaction participating nodes according to the log records of the target transaction includes: If the target transaction participant node successfully records the target transaction log, the target transaction among the multiple transaction participant nodes is made consistent based on the target transaction log.

6. The transaction distributed processing method according to claim 5, wherein, The log of the target transaction includes the identifier of the target transaction and the status of the target transaction, which includes success and termination. The step of performing consistency processing on the target transaction among the multiple transaction participating nodes based on the log of the target transaction includes: If the target transaction is successful, a processing request is sent to the multiple transaction participating nodes; If the target transaction is in a terminated state, a rollback request is sent to the plurality of transaction participants so that the plurality of transaction participants can perform a rollback operation on the target transaction.

7. The transaction distributed processing method according to claim 5, wherein, The step of distributing the target transaction among the multiple transaction participating nodes based on the log records of the target transaction further includes: If the participating node of the target transaction fails to record the log of the target transaction, an instruction to determine the status of the target transaction as terminated is sent to the participating node of the target transaction, so that the participating node of the target transaction records the log of the target transaction.

8. The transaction distributed processing method according to claim 1, wherein, The transaction management node includes a new transaction management node selected when the original transaction management node fails, and the transaction participant node includes a new transaction participant node selected when the original transaction participant node fails.

9. The transaction distributed processing method according to claim 4, wherein, The step of determining whether the target transaction is an aborted transaction based on the scan results of the target transaction includes: If the scan result is the initial scan result, and the scan result includes the target transaction, the target transaction is determined to be the aborted transaction; If the scan result is not the first scan result, it is determined whether the target transaction is the aborted transaction based on the scan result at the current moment and the scan result at the previous moment.

10. The transaction distributed processing method according to claim 9, wherein, The step of determining whether the target transaction is the aborted transaction based on the scan results at the current moment and the scan results at the previous moment includes: In response to the fact that the scan result at the current moment includes the target transaction and the scan result at the previous moment includes the target transaction, the target transaction is determined to be the aborted transaction.

11. The transaction distributed processing method according to any one of claims 1 to 10, wherein, The step of determining multiple transaction participant nodes based on the target transaction submitted by the client, and determining whether the multiple transaction participant nodes support processing the target transaction, includes: Based on the target transaction submitted by the client, the multiple transaction participating nodes are determined; A preparation request is sent to the plurality of transaction participant nodes, and based on the response information of the preparation request returned by the plurality of transaction participant nodes, it is determined whether the plurality of transaction participant nodes support processing the target transaction.

12. The transaction distributed processing method according to any one of claims 1 to 10, further comprising: If any of the multiple transaction participants does not support processing the target transaction, a rollback request is sent to the multiple transaction participants so that the multiple transaction participants can perform a rollback operation on the target transaction.

13. The transaction distributed processing method according to any one of claims 1 to 10, wherein, The transaction management node is determined based on the target transaction submitted by the client.

14. A transaction management node, comprising: The first determining unit is configured to determine multiple transaction participating nodes based on the target transaction submitted by the client, and to determine whether the multiple transaction participating nodes support processing the target transaction; The second determining unit is configured to, when the plurality of transaction participating nodes support processing the target transaction, determine a target transaction participating node among the plurality of transaction participating nodes based on the identifier of the target transaction submitted by the client, wherein the target transaction participating node is used to record the log of the target transaction; The processing unit is configured to perform distributed processing on the target transaction based on the log records of the target transaction.

15. A transaction management node, comprising: Memory; and A processor coupled to the memory, the processor being configured to execute the transaction distributed processing method of any one of claims 1 to 13 based on instructions stored in the memory.

16. A transaction-distributed processing system, comprising: The transaction management node as described in claim 14 or 15; Multiple transaction participant nodes, including a target transaction participant node, wherein the target transaction participant node is configured to record a log of the target transaction.

17. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the transaction distributed processing method of any one of claims 1 to 13.

18. A computer program product comprising computer instructions that, when executed by a processor, implement the transaction distributed processing method of any one of claims 1 to 13.

Images