WO2016180164A1

WO2016180164A1 - Method and apparatus for rolling back distributed transaction

Info

Publication number: WO2016180164A1
Application number: PCT/CN2016/079487
Authority: WO
Inventors: 张宗禹; 贾新华; 陈河堆; 白涛; 郭龙波
Original assignee: 中兴通讯股份有限公司
Priority date: 2015-09-29
Filing date: 2016-04-15
Publication date: 2016-11-17
Also published as: CN106557514A

Abstract

A method and apparatus for rolling back a distributed transaction. The method comprises: a transaction manager initiates a request for submitting branch transactions of a first transaction, to resource managers of database nodes related to the first transaction; and when receiving a response that is sent by any resource manager and that indicates that the submission of the branch transactions of the first transaction fails, the transaction manager initiates a request for rolling back the branch transactions of the first transaction, to other resource managers that are submitting the branch transactions of the first transaction or have successfully submitted the branch transactions of the first transaction.

Description

Distributed transaction rollback method and device

Technical field

This document relates to, but is not limited to, the field of distributed databases, and in particular, to a distributed transaction rollback method and apparatus.

Background technique

Transaction is the unit of concurrency control, which is a user-defined sequence of operations. These operations are either done or not done and are an inseparable unit of work. Distributed transaction processing means that a transaction may involve multiple database operations. The key to distributed transaction processing is that there must be a way to know all the actions that the transaction does anywhere. The decision to commit or roll back the transaction must produce uniform results. (all submitted or all rolled back).

At present, most mainstream stand-alone databases can guarantee the characteristics of transactions well, but implementing distributed transactions in distributed databases faces many challenges. One of the key problems is how to effectively roll back distributed transactions. The biggest difference between distributed transactions and stand-alone transactions is that they are committed at the same time on multiple database nodes. If they are successful, no further operations are required. However, once a database node fails to submit due to some abnormality, then Other database nodes also ensure that transactions submitted to them can be stopped or rolled back in time. Due to the randomness of the database nodes and the types of exceptions, how to effectively roll back distributed transactions becomes a key issue to ensure transaction consistency.

The most commonly used in the industry is the X/Open DTP (Distributed Transaction Processing) model defined by the X/Open organization. There are three roles in this model:

AP (Application), which is the business layer. Which operations belong to a transaction, which is defined by the AP.

RM (Resource Manager), generally a database, or other resource managers, such as message queues, such as JMS (Java Message Service) data sources, file systems, and so on.

TM (Transaction Manager), receiving AP transaction requests, managing global transactions, managing transaction branch status, coordinating RM processing, notifying RM which operations belong to which global transactions and transaction branches. It is the core part of the entire transaction scheduling model.

The XA protocol is a two-phase commit protocol defined by the X/Open DTP organization that uses a two-phase commit approach to manage distributed transactions.

In the first phase, the TM requests all RMs to prepare to commit (ie, pre-submit) their respective transaction branches to confirm if all relevant RMs can submit their respective transaction branches. When the partial RM receives the pre-submission, if it can submit its own transaction branch, it will record the operation itself in the transaction branch and give the TM a consent to submit the reply. At this time, the RM will no longer be in the Any operation is added to the transaction branch, but at this time the RM does not actually commit the transaction, and the RM operation on the shared resource has not been released (ie, it is in a locked state). If for some reason RM is unable to commit its own transaction branch, it will roll back all of its operations, release the lock on the shared resource, and return to the TM failure response.

In the second phase, the TM reviews all pre-submitted results returned by the RM. If all RMs can be submitted, the TM will require all RMs to be formally submitted so that the global transaction is committed. And if any RM pre-reply returns fail, the TM will ask all other RMs to roll back their operations so that the global transaction is rolled back.

However, this model has several obvious shortcomings. First of all, although this two-phase commit method is adopted, it is still impossible to avoid the abnormality of the database node in the second phase, which leads to data inconsistency. Secondly, since each transaction is adopted Two-phase commit, so the system will generate an interaction process for each related database node when committing the transaction, which will reduce the submission performance. Moreover, the use of this mode must ensure that all database nodes support the XA protocol.

Summary of the invention

The following is an overview of the topics detailed in this document. This Summary is not intended to limit the scope of the claims.

The embodiment of the invention provides a novel distributed transaction rollback solution, which can effectively solve the defects of the current distributed transaction commit rollback technology, thereby improving the reliability and submission of distributed transactions. effectiveness.

The embodiments of the present invention adopt the following technical solutions.

A distributed transaction rollback method, comprising:

The transaction manager initiates a commit request for the branch transaction of the first transaction to the resource manager of the database node associated with the first transaction;

The transaction manager, when receiving a response from any of the resource managers that fails to submit the branch transaction of the first transaction, commits to the other branch transaction that is submitting the first transaction, or submits the A branch transaction of a transaction A successful resource manager initiates a rollback request for a branch transaction of the first transaction.

Optionally, the transaction manager further includes: before the resource manager of the database node associated with the first transaction initiates the submit request of the branch transaction of the first transaction:

The transaction manager generates a globally unique transaction identifier for the first transaction;

The method further includes: the transaction manager carrying a transaction identifier of the first transaction in a commit request of a branch transaction of the first transaction; carrying a location in a rollback request of a branch transaction of the first transaction The transaction identifier of the first transaction, and the time of submitting the request for the branch transaction of the first transaction.

Optionally, after the rollback request of the branch transaction of the first transaction is initiated by the resource manager that successfully submits the branch transaction of the first transaction or the branch transaction that submits the first transaction, the method further includes:

The transaction manager summarizes the rollback result fed back by the resource manager; if there is a resource manager that fails to roll back, the connection corresponds to the database node corresponding to the failed resource manager, and locks the table involved in the rollback failure.

A distributed transaction rollback method, comprising:

After the resource manager receives the rollback request of the branch transaction of the first transaction sent by the transaction manager, if the branch transaction of the first transaction has been committed, the transaction log corresponding to the branch transaction of the first transaction is filtered out;

According to the data and execution statement recorded in the filtered transaction log, a reverse execution statement is generated, and the generated reverse execution statement is executed in reverse order as a transaction.

Optionally, the reverse execution statement refers to a statement that implements the opposite function to the original execution statement; the reverse execution refers to an execution order opposite to that at the time of submission.

Optionally, the rollback request of the branch transaction of the first transaction carries the transaction identifier of the first transaction, and the time when the submission request of the branch transaction of the first transaction is initiated;

The transaction log corresponding to the branch transaction that filters out the first transaction includes:

The time at which the commit request of the branch transaction of the first transaction is initiated in the parsed request, the start position of each transaction log block and the time when the first event occurs in the transaction log block Select the transaction log block in the list to determine the starting position of the selected transaction log block;

Scanning is started from the determined start position of the transaction log block, and the transaction log block corresponding to the transaction identifier of the first transaction is found.

Optionally, after the executing the reverse execution statement as a transaction reverse order, the method further includes:

When the reverse execution statement is all executed successfully, feeding back to the transaction manager a rollback result indicating that the rollback is successful; when the reverse execution statement is not all executed successfully, feeding back to the transaction manager Rolls the failed rollback result and carries the reverse execution statement that failed the execution and the tables involved.

Optionally, the executing the reverse execution statement as a transaction in reverse order includes:

The resource manager connects to the corresponding database node, and submits the generated reverse execution statement in units of transactions;

The resource manager executes the generated reverse execution statement in reverse order on the corresponding database node, and receives an execution result of the reverse execution statement from the database node.

Optionally, before the resource manager receives the rollback request of the branch transaction of the first transaction sent by the transaction manager, the method further includes:

After receiving the commit request of the branch transaction initiated by the transaction manager, the resource manager submits the branch transaction to the corresponding database node, and feedbacks the branch transaction execution result response to the transaction according to the result of executing the branch transaction. Manager.

A distributed transaction rollback device, which is set in a transaction manager, and includes:

Submitting an initiating module, configured to initiate a commit request of a branch transaction of the first transaction to a resource manager of the database node associated with the first transaction;

Rollback initiation module, configured to, when receiving a response from any of the resource managers that fails to submit the first transaction, to another branch transaction or submitting the first transaction The resource manager of the first transaction of the first transaction initiates a rollback request for the branch transaction of the first transaction.

Optionally, the identifier generating module is configured to generate a globally unique transaction identifier for the first transaction;

The commit initiating module is further configured to carry a transaction identifier of the first transaction in a commit request of a branch transaction of the first transaction;

The rollback initiation module is further configured to carry a transaction identifier of the first transaction and a time of initiating a submission request of a branch transaction of the first transaction in a rollback request of a branch transaction of the first transaction.

Optionally, the device further includes:

The rollback result processing module is configured to summarize the rollback result fed back by the resource manager; if there is a resource manager that fails to roll back, the database node corresponding to the resource manager that fails to roll back the connection, the lock rollback failure is involved Table.

A distributed transaction rollback device, which is set in the resource manager, and includes:

Selecting a module, configured to receive a rollback request of a branch transaction of the first transaction sent by the transaction manager, and if the branch transaction of the first transaction has been committed, filter out a transaction corresponding to the branch transaction of the first transaction Log

The execution module is rolled back, and is set to generate a reverse execution statement according to the data and the execution statement recorded in the filtered transaction log, and execute the generated reverse execution statement as a transaction in reverse order.

The selection module filters out the transaction log corresponding to the branch transaction of the first transaction, including:

The selecting module saves the first event in the start position of each transaction log block and the transaction log block by the time of initiating the submit request of the branch transaction of the first transaction in the parsed request Selecting a transaction log block in the list of occurrence moments, determining a start position of the selected transaction log block; starting from the determined start position of the transaction log block, finding a transaction corresponding to the transaction identifier of the first transaction The log is chunked.

Optionally, the device further includes:

a feedback module, configured to: when the reverse execution statement is all executed successfully, feed back to the transaction manager a rollback result indicating that the rollback is successful; and when the reverse execution statement is not all executed successfully, to the transaction The manager feedback indicates that the rollback result of the rollback failed, and carries the reverse execution statement that failed the execution and the table involved.

Optionally, the rollback execution module executes the generated reverse execution statement as a transaction in reverse order, including:

The rollback execution module connects the corresponding database node, submits the generated reverse execution statement in units of transactions, executes the generated reverse execution statement in reverse order on the corresponding database node, and receives the reverse statement from the database node. The execution result to the execution statement.

Optionally, the device further includes:

And submitting an execution module, configured to submit the branch transaction to the corresponding database node after receiving the branch transaction commit request initiated by the transaction manager, and feedback the branch transaction execution result response to the transaction according to the result of executing the branch transaction Manager.

A computer readable storage medium storing computer executable instructions for performing the above method.

Compared with the distributed transaction commit and rollback method in the related art, the beneficial effects of the embodiment of the present invention mainly reflect three aspects:

(1) Increase in the submission performance of normal transactions. The embodiment of the invention adopts a direct submission method, The original two-phase commit method of distributed transactions is abandoned, which reduces the redundant message interaction overhead and fundamentally improves the submission performance.

(2) Guarantee the consistency and reliability of distributed transactions. The use of direct commit transactions and the rollback of other branch transactions when branch transaction commit fails, thus avoiding the risks that may occur when the second commit of the XA two-phase commit protocol is initiated, thus further ensuring the entire distributed The consistency of transactions improves the reliability of distributed transactions.

(3) It can be implemented without the need for a database node to support the XA protocol.

Other aspects will be apparent upon reading and understanding the drawings and detailed description.

BRIEF abstract

1 is a schematic flowchart of a distributed transaction rollback method according to Embodiment 1;

2 is a schematic flowchart of a distributed transaction rollback method in Embodiment 2;

3 is a schematic flowchart of a distributed transaction commit and rollback method in Embodiment 3;

4 is a schematic diagram of a distributed transaction rollback apparatus of Embodiment 4;

5 is a schematic diagram of a distributed transaction rollback device of Embodiment 5;

6 is a schematic diagram of a distributed transaction rollback system of Embodiment 6.

Embodiments of the invention

It should be noted that the embodiments of the present invention and the various features in the embodiments may be combined with each other if they do not conflict. Additionally, although logical sequences are shown in the flowcharts, in some cases the steps shown or described may be performed in a different order than the ones described herein.

Embodiment 1 A distributed transaction rollback method, as shown in FIG. 1, includes:

S110, the transaction manager initiates a commit request of the branch transaction of the first transaction to the resource manager of the database node associated with the first transaction; it can be seen that the embodiment discards the two-phase commit method and uses the direct commit method;

S120. When the transaction manager receives a response from any of the resource managers that fails to submit the branch transaction of the first transaction, to the other branch transaction that is submitting the first transaction, Or the resource manager that successfully submits the branch transaction of the first transaction initiates a rollback request of the branch transaction of the first transaction.

In this embodiment, if the transaction manager receives a response from all resource managers submitting the branch transaction of the first transaction successfully, it determines that the entire first transaction is successfully submitted.

Optionally, before the transaction manager of the database node associated with the first transaction initiates the commit request of the branch transaction of the first transaction, the transaction manager further includes: the transaction manager generating a global unique for the first transaction Transaction ID (identification);

The method further includes: the transaction manager carrying a transaction ID of the first transaction in a commit request of a branch transaction of the first transaction; carrying a location in a rollback request of a branch transaction of the first transaction The transaction identifier of the first transaction, and the time of submitting the request for the branch transaction of the first transaction.

Optionally, after the step S120, the transaction manager further summarizes the rollback result fed back by the resource manager, and summarizes the result and feeds back to the client.

The transaction manager summarizes the rollback result of the resource manager feedback (only the resource manager feedback rollback result of receiving the rollback request), and if all the rollback is successful, returning to the client, indicating that the rollback is successful As a result, the process ends; optionally, if there is a resource manager that fails to roll back, the transaction manager connection rolls back the database node corresponding to the failed resource manager, locks the table involved in the rollback failure, and waits for manual intervention, so that Ensure transactional consistency.

Embodiment 2 A distributed transaction rollback method, as shown in FIG. 2, includes:

S210. After receiving the rollback request of the branch transaction of the first transaction sent by the transaction manager, if the branch transaction of the first transaction has been submitted, filtering the transaction corresponding to the branch transaction of the first transaction. Log

S220: Generate a reverse execution statement according to the data and the execution statement recorded in the selected transaction log, and execute the reverse execution statement as a transaction in reverse order, thereby completing rollback of the local resource.

The execution statement may be, but not limited to, a SQL (Structured Query Language) statement.

Wherein, the reverse execution statement may refer to a statement that implements the opposite function from the original execution statement; for example, if the original execution statement is plus 5, the corresponding reverse execution statement is subtracted by 5; and if the original execution statement is saved, the corresponding The reverse execution statement is read.

The reverse execution may be performed in the reverse order of execution, such as executing SQL statements in sequence: X, Y, Z; the reverse SQL statement generated for X is X', and the reverse SQL statement generated for Y is Y', the reverse SQL statement generated for Z is Z', and the reverse execution means sequential execution: Z', Y', X'.

The resource manager scans the transaction log when idle, and generates an index file according to the block size of the transaction log, records the start position of each transaction log block and the time when the first event in the transaction log block occurs. , thus forming a list in memory that saves these records in chronological order.

Determining, by the parsed, the request for submitting the branch transaction of the first transaction in the rollback request, selecting a transaction log block in the list to determine a starting position of the selected transaction log block; Limited to scanning the list from back to front;

Scanning is started from the start position of the determined transaction log block, and the transaction log block corresponding to the transaction ID of the first transaction is found.

Optionally, after step S220, the method may further include:

If all the generated reverse execution statements are successfully executed, it indicates that the rollback operation is successful, and the rollback result indicating that the rollback is successful is sent to the transaction manager; if the generated reverse execution statement is not all executed successfully, it indicates The rollback operation fails to execute, sending a rollback result indicating that the rollback failed to the transaction manager, and carrying the reverse execution statement that failed the execution and the table involved.

The resource manager performs the generated reverse verbs in reverse order on the corresponding database node a sentence, and receiving an execution result of the reverse execution statement from the database node.

After receiving the commit request of the branch transaction initiated by the transaction manager, the resource manager submits the branch transaction to the corresponding database node, and feedbacks the branch transaction execution result response according to the result of executing the branch transaction (ie, submitting The branch transaction successfully responds or submits a response to the branch transaction failure) to the transaction manager.

Embodiment 3 This embodiment takes the MariaDB distributed system as an example. The process of distributed transaction submission and rollback is as follows, as shown in FIG. 3, including steps 301-306:

301. After receiving the request for executing the transaction, the transaction manager first generates a globally unique transaction ID for the operation, and then obtains the node information list and the branch transaction of each database node according to the distribution policy, and directly to the resource manager of the related database node. Request to submit their own branch transaction. In this embodiment, it is assumed that there are two branch transactions corresponding to the database node 1 and the database node 2 respectively; the transaction manager initiates a branch transaction commit request to the resource manager 1 of the database node 1 and the resource manager 2 of the database node 2, respectively. . The resource manager 1 submits a branch transaction to the database node 1, and the resource manager 2 submits a branch transaction to the database node 2.

302. The resource manager 1 feeds back a response of the branch transaction execution result (assuming that the commit branch transaction succeeds) to the transaction manager according to the result of executing the branch transaction by the database node 1, and the resource manager 2 performs the branch feedback result of the branch transaction according to the database node 2. The transaction execution result (assuming the commit branch transaction failed) is sent to the transaction manager.

303. In the case that the branch transaction of a database node fails to be submitted, the transaction manager will initiate a distributed transaction back to the resource manager of the database node that has successfully submitted and is submitting (the branch transaction execution result response is not received). In the embodiment, the rollback request is initiated to the resource manager 1; the rollback request mainly carries the transaction ID to be rolled back and the initiation time of the submission request (using the time to determine the transaction log range).

304. The resource manager 1 connects to the database node 1, and submits the generated reverse SQL statement in units of transactions.

In the daily monitoring, the resource manager periodically scans MariaDB's current transaction log, binlog, logically splits the transaction log according to the size, records the starting position of each partition and the time of the first event, thus forming a memory. Save a list of these records in chronological order.

The process of resource manager 1 generating reverse SQL statements is as follows:

When the resource manager 1 receives the rollback request for the database node 1 it is listening to, firstly, according to the initiation time in the rollback request, the transaction log block that needs to be scanned and analyzed is initially determined from the above list (can be in the form of a list) Save) and the starting position of each transaction log partition determined.

The binlog log is scanned according to the initially determined start position of the transaction log block, and the corresponding transaction log is filtered in the initially determined transaction log block by rolling back the transaction ID in the request.

According to the data and execution statements recorded in the transaction log, a reverse SQL statement is generated and written into the memory or file in units of transactions.

305. Perform the reverse SQL statement in reverse order on the database node 1, and the database node 1 feeds back the execution result of the reverse SQL statement to the resource manager 1.

306. The resource manager 1 feeds back the rollback result to the transaction manager: if all the reverse SQL statements are executed successfully, the resource manager 1 replies to the transaction manager to roll back the success command. If the reverse SQL statement fails to execute, the transaction manager will be replied to the reverse SQL statement and related table that failed to execute.

The transaction manager collects the rollback results of all resource manager feedback that initiates the rollback request. If there is a rollback failure message, the related table is locked to ensure transaction consistency.

The above embodiment will be further explained below with four embodiment examples.

Implementation example 1. An online payment system based on the MySQL distributed cluster database.

In this system, when the A account initiates a payment operation to the B account, since the A account amount is reduced and the B account is increased by the same amount, both operations must be completed, and all failures must be rolled back. Therefore, it should be executed as a transaction. If the A and B account data are distributed on different database nodes, it involves distributed transactions.

In the implementation details of this embodiment example, the operational transaction will be divided into two branch transactions of the deduction of the A account and the addition of the B account, and the transaction manager first generates a globally unique transaction ID for the operational transaction, and then simultaneously to A, The resource manager of the database node where the B account is located directly initiates the corresponding score A commit request for a transaction, which carries the transaction ID.

If there is a database node that fails to execute the branch transaction, such as the execution failure when the B account executes the increased amount, the transaction manager will initiate a rollback request to the resource manager of the database node where the A account that has successfully submitted the A account, and the rollback request carries this The transaction ID of the secondary branch transaction and the time point t1 at which the commit request is initiated.

After receiving the rollback request, the resource manager obtains the transaction log partition to be scanned according to t1 and the determined start position of each transaction log block, and then filters the filtered transaction log block by the transaction ID. Corresponding transaction log; analyze the transaction log sequentially, and generate reverse SQL statements based on the data and execution statements recorded in the transaction log, stored in memory or file (depending on the size of the reverse SQL statement), and finally by transaction These SQL statements are reversed for the unit to complete the rollback operation of the A account, and the transaction manager returns successfully after completion.

Implementation example 2. Ticket online ticketing system based on MariaDB distributed cluster database.

In this system, when an account initiates a ticket purchase operation, it is necessary to ensure that the number of remaining tickets of the relevant train and the ticket associated with the account are simultaneously updated.

In the implementation details of the present embodiment, if the number of remaining ticket information and the association information of the account and the ticket are distributed on different database nodes, the operation transaction will be divided into an update of the number of remaining tickets of the relevant train and an update of the ticket information of the account purchase. Two branch transactions, the transaction manager first generates a globally unique transaction ID for the operation transaction, and then simultaneously initiates a commit request for the corresponding branch transaction to the resource managers of the two database nodes, and the commit request carries the transaction ID.

If a database node fails to perform a branch transaction, such as the failure to perform the update of the purchase ticket information for the account, the transaction manager will initiate a rollback request to the resource manager of the database node where the remaining number of votes of the relevant train has been successfully submitted, and roll back The request carries the transaction ID of the branch transaction and the time point t1 at which the commit request is initiated.

After receiving the rollback request, the resource manager obtains the transaction log partition to be scanned according to t1 and the determined start position of each transaction log block, and then filters the filtered transaction log block by the transaction ID. Obtain the corresponding transaction log; analyze the transaction log sequentially, and generate reverse SQL statements based on the data and execution statements recorded in the transaction log, that is, increase the number of remaining tickets for the corresponding train The added statement is saved in the memory or file, and finally the reverse SQL statement is executed as a transaction (because it belongs to the branch transaction), thereby completing the rollback operation of the remaining ticket information of the relevant train, and replying to the transaction management after completion The rollback was successful.

Implementation Example 3, an online shopping system based on Oracle's distributed cluster database.

In this system, when an optional merchandise operation occurs, it is necessary to ensure that the user orders the merchandise and the remaining merchandise while updating.

In the implementation details of the present embodiment, if the user subscription relationship and the remaining item quantity are distributed on different database nodes, the operation transaction will be divided into an update of the remaining item quantity and a save of the user and the item's one order relationship. Transaction, the transaction manager first generates a globally unique transaction ID for the operation transaction, and then simultaneously requests the resource manager of the database node where the relationship and the remaining commodity quantity are respectively in the user to initiate the submission request of the corresponding branch transaction, and the transaction is carried in the submission request. ID.

If a database node fails to perform a branch transaction, such as the failure to save the subscription relationship between the user and the commodity, the transaction manager will initiate a rollback request to the resource manager of the database node where the remaining commodity quantity information has been successfully submitted. The rollback request carries the transaction ID of the branch transaction and the time point t1 at which the commit request is initiated.

After receiving the rollback request, the resource manager obtains the transaction log partition to be scanned according to t1 and the determined start position of each transaction log block, and then filters the filtered transaction log block by the transaction ID. Corresponding transaction log; analyze the transaction log sequentially, and generate reverse SQL statements according to the data and execution statements recorded in the transaction log, that is, delete the SQL statement of the subscription relationship between the user and the commodity, and save the reverse SQL statement in In the memory or file, the reverse SQL statement is executed in reverse by the transaction unit, thereby completing the rollback operation on the remaining item quantity information, and the global transaction manager returns successfully after completion.

Implementation example 4, an online stock trading system based on PosgreSQL distributed cluster database.

In this system, when an account initiates a stock purchase operation, at least the increase in the stock held by the account and the decrease in the remaining funds of the account are simultaneously updated.

In the implementation details of the present embodiment, if the account holding stock and the remaining funds of the account are distributed on different database nodes, the operational transaction will be divided into two branch transactions in which the account holds the stock and the remaining funds of the account are reduced. The transaction manager first generates a globally unique transaction ID for the operational transaction, and then directly initiates a commit request for the corresponding branch transaction to the resource manager of the database node where the account holding stock and the remaining funds of the account are located, and the commit request carries the transaction ID. .

If there is a database node performing a branch transaction failure, such as the failure of the account's remaining funds to fail to execute, the transaction manager will initiate a rollback request to the resource manager of the database node where the account has the stock quantity information that has been successfully submitted, and roll back the request. The transaction ID of the branch transaction and the time point t1 at which the commit request is initiated.

After receiving the rollback request, the resource manager obtains the transaction log partition to be scanned according to t1 and the determined start position of each transaction log block, and then filters the filtered transaction log block by the transaction ID. Corresponding transaction log; analyze the transaction log sequentially, and generate reverse SQL statements according to the data and execution statements recorded in the transaction log, that is, clear the SQL statement of the number of shares purchased by the user from the user account, and the reverse SQL The statement is stored in the memory or file, and finally these reverse SQL statements are reversely executed in units of transactions, thereby completing the rollback operation of the stock quantity information held by the account, and the global transaction manager returns successfully after completion.

Embodiment 4 is a distributed transaction rollback device, which is disposed in a transaction manager, as shown in FIG. 4, and includes:

The commit initiating module 41 is configured to initiate a commit request of the branch transaction of the first transaction to the resource manager of the database node associated with the first transaction;

The rollback initiation module 42 is configured to, when receiving a response from any of the resource managers that fails to submit the branch transaction of the first transaction, to another branch transaction that is submitting the first transaction, or submit The resource manager of the branch transaction of the first transaction initiates a rollback request for the branch transaction of the first transaction.

Optionally, the device further includes:

An identifier generation module configured to generate a globally unique transaction identifier for the first transaction;

The commit initiation module 41 is further configured to submit a request for a branch transaction of the first transaction Carrying the transaction identifier of the first transaction;

The rollback initiation module 42 is further configured to carry a transaction identifier of the first transaction and a time of initiating a submission request of the branch transaction of the first transaction in a rollback request of a branch transaction of the first transaction.

Optionally, the device further includes:

The fifth embodiment is a distributed transaction rollback device, which is disposed in the resource manager, as shown in FIG. 5, and includes:

The selecting module 51 is configured to: after receiving the rollback request of the branch transaction of the first transaction sent by the transaction manager, if the branch transaction of the first transaction has been submitted, filtering out the branch transaction corresponding to the first transaction Transaction log

The rollback execution module 52 is configured to generate a reverse execution statement according to the data and the execution statement recorded in the filtered transaction log, and execute the generated reverse execution statement as a transaction reverse order.

The selection module 51 filters out the transaction log corresponding to the branch transaction of the first transaction, including:

The selection module 51, by parsing the time of submitting the commit request of the branch transaction of the first transaction in the rollback request, saves the first position in the start position of each transaction log block and the first in the transaction log block Selecting a transaction log block in the list of times when the event occurs, determining a start position of the selected transaction log block; starting from the determined start position of the transaction log block, finding a transaction identifier corresponding to the first transaction The transaction log is chunked.

Optionally, the device further includes:

Optionally, the rollback execution module 52 executes the generated reverse execution statement as a transaction in reverse order, including:

The rollback execution module 52 connects the corresponding database node, submits the generated reverse execution statement in units of transactions, executes the generated reverse execution statement in reverse order on the corresponding database node, and receives the reverse from the database node. Execute the execution result of the statement.

Optionally, the device further includes:

Embodiment 6 A distributed transaction rollback system, as shown in FIG. 6, includes:

The transaction manager 61 is configured to receive a transaction request of the upper layer service, manage the global transaction, manage the transaction branch state, coordinate the processing of the resource manager 62, notify the resource manager 62 of which global transactions and transaction branches belong to, and the like. Transaction manager 61 is also a core part of the overall transaction scheduling model. The transaction manager 61 also includes the distributed transaction rollback device of the fourth embodiment in this embodiment.

A plurality of resource managers 62: usually upper layer agents of database nodes, are local database monitoring programs that perform complex operations on the corresponding database nodes 63 in response to upper layer requests. In this embodiment, the resource manager 62 further includes the distributed transaction rollback device in the fifth embodiment.

In this embodiment, after receiving the transaction request, the transaction manager 61 initiates a branch transaction commit request to the branch manager at the resource manager 62 of the database node 63, and receives the branch transaction execution result; when there is a branch transaction that fails to commit A resource rollback request is initiated to the resource manager 62 that submitted the success and is being submitted; the resource manager 62 that received the rollback request performs a rollback operation on the corresponding database node 63 and feeds back the rollback result to the transaction manager 61.

Embodiment 7 A computer readable storage medium storing computer executable instructions for performing the methods of Embodiment 1 and/or Embodiment 2 above.

One of ordinary skill in the art will appreciate that all or a portion of the steps described above can be accomplished by a program that instructs the associated hardware, such as a read-only memory, a magnetic or optical disk, and the like. Alternatively, all or part of the steps of the above embodiments may also be implemented using one or more integrated circuits. Correspondingly, each module/unit in the foregoing embodiment may be implemented in the form of hardware or in the form of a software function module. The invention is not limited to any specific form of combination of hardware and software.

Industrial applicability

The embodiment of the invention adopts the direct submission method, and discards the original two-phase commit mode of the distributed transaction, thereby reducing redundant message interaction overhead, and fundamentally improving the submission performance; and adopting the direct commit transaction method and the branch transaction The practice of rolling back other branch transactions when the submission fails, thus avoiding the risks that may occur when the second phase of the XA two-phase commit protocol initiates the real commit, thereby further ensuring the consistency of the entire distributed transaction and improving the distributed transaction. Reliability; in addition, it can be implemented without the need for a database node to support the XA protocol.

Claims

A distributed transaction rollback method, comprising:

The transaction manager initiates a commit request for the branch transaction of the first transaction to the resource manager of the database node associated with the first transaction;

The transaction manager, when receiving a response from any of the resource managers that fails to submit the branch transaction of the first transaction, commits to the other branch transaction that is submitting the first transaction, or submits the A branch transaction of a transaction A successful resource manager initiates a rollback request for a branch transaction of the first transaction.
The method of claim 1, wherein the transaction manager further includes: before the resource manager of the database node associated with the first transaction initiates the submit request of the branch transaction of the first transaction:

The transaction manager generates a globally unique transaction identifier for the first transaction;

The method further includes: the transaction manager carrying a transaction identifier of the first transaction in a commit request of a branch transaction of the first transaction; carrying a location in a rollback request of a branch transaction of the first transaction The transaction identifier of the first transaction, and the time of submitting the request for the branch transaction of the first transaction.
The method of claim 1, wherein the resource manager that successfully submits the branch transaction of the first transaction or the branch transaction that successfully submits the first transaction initiates a rollback request of the branch transaction of the first transaction include:

The transaction manager summarizes the rollback result fed back by the resource manager; if there is a resource manager that fails to roll back, the connection corresponds to the database node corresponding to the failed resource manager, and locks the table involved in the rollback failure.
A distributed transaction rollback method, comprising:

After the resource manager receives the rollback request of the branch transaction of the first transaction sent by the transaction manager, if the branch transaction of the first transaction has been committed, the transaction log corresponding to the branch transaction of the first transaction is filtered out;

Generate a reverse execution statement based on the data and execution statements recorded in the filtered transaction log. The generated reverse execution statement is executed in reverse order as a transaction.
The method of claim 4 wherein:

The reverse execution statement refers to a statement that implements the opposite function to the original execution statement; the reverse execution refers to the reverse of the execution order at the time of submission.
The method of claim 4 wherein:

The rollback request of the branch transaction of the first transaction carries the transaction identifier of the first transaction, and the time when the commit request of the branch transaction of the first transaction is initiated;

The transaction log corresponding to the branch transaction that filters out the first transaction includes:

The time at which the commit request of the branch transaction of the first transaction is initiated in the parsed request, the start position of each transaction log block and the time when the first event occurs in the transaction log block Select the transaction log block in the list to determine the starting position of the selected transaction log block;

Scanning is started from the determined start position of the transaction log block, and the transaction log block corresponding to the transaction identifier of the first transaction is found.
The method of claim 4, wherein the executing the reverse execution statement as a transaction in reverse order further comprises:

When the reverse execution statement is all executed successfully, feeding back to the transaction manager a rollback result indicating that the rollback is successful; when the reverse execution statement is not all executed successfully, feeding back to the transaction manager Rolls the failed rollback result and carries the reverse execution statement that failed the execution and the tables involved.
The method of claim 4 wherein said executing the reverse execution statement as a transaction in reverse order comprises:

The resource manager connects to the corresponding database node, and submits the generated reverse execution statement in units of transactions;

The resource manager executes the generated reverse execution statement in reverse order on the corresponding database node, and receives an execution result of the reverse execution statement from the database node.
The method of claim 4, wherein the resource manager further comprises: before receiving the rollback request of the branch transaction of the first transaction sent by the transaction manager:

After receiving the commit request of the branch transaction initiated by the transaction manager, the resource manager submits the branch transaction to the corresponding database node, and feedbacks the branch transaction execution result response to the transaction according to the result of executing the branch transaction. Manager.
A distributed transaction rollback device, which is set in a transaction manager, and includes:

Submitting an initiating module, configured to initiate a commit request of a branch transaction of the first transaction to a resource manager of the database node associated with the first transaction;

Rollback initiation module, configured to, when receiving a response from any of the resource managers that fails to submit the first transaction, to another branch transaction or submitting the first transaction The resource manager of the first transaction of the first transaction initiates a rollback request for the branch transaction of the first transaction.
The apparatus of claim 10 further comprising:

An identifier generation module configured to generate a globally unique transaction identifier for the first transaction;

The commit initiating module is further configured to carry a transaction identifier of the first transaction in a commit request of a branch transaction of the first transaction;

The rollback initiation module is further configured to carry a transaction identifier of the first transaction and a time of initiating a submission request of a branch transaction of the first transaction in a rollback request of a branch transaction of the first transaction.
The apparatus of claim 10 further comprising:

The rollback result processing module is configured to summarize the rollback result fed back by the resource manager; if there is a resource manager that fails to roll back, the database node corresponding to the resource manager that fails to roll back the connection, the lock rollback failure is involved Table.
A distributed transaction rollback device, which is set in the resource manager, and includes:

Selecting a module, configured to receive a rollback request of a branch transaction of the first transaction sent by the transaction manager, and if the branch transaction of the first transaction has been committed, filter out the score of the first transaction The transaction log corresponding to the branch transaction;

The execution module is rolled back, and is set to generate a reverse execution statement according to the data and the execution statement recorded in the filtered transaction log, and execute the generated reverse execution statement as a transaction in reverse order.
The apparatus of claim 13 wherein:

The reverse execution statement refers to a statement that implements the opposite function to the original execution statement; the reverse execution refers to the reverse of the execution order at the time of submission.
The apparatus of claim 13 wherein:

The rollback request of the branch transaction of the first transaction carries the transaction identifier of the first transaction, and the time when the commit request of the branch transaction of the first transaction is initiated;

The selection module filters out the transaction log corresponding to the branch transaction of the first transaction, including:

The selecting module saves the first event in the start position of each transaction log block and the transaction log block by the time of initiating the submit request of the branch transaction of the first transaction in the parsed request Selecting a transaction log block in the list of occurrence moments, determining a start position of the selected transaction log block; starting from the determined start position of the transaction log block, finding a transaction corresponding to the transaction identifier of the first transaction The log is chunked.
The apparatus of claim 13 further comprising:

a feedback module, configured to: when the reverse execution statement is all executed successfully, feed back to the transaction manager a rollback result indicating that the rollback is successful; and when the reverse execution statement is not all executed successfully, to the transaction The manager feedback indicates that the rollback result of the rollback failed, and carries the reverse execution statement that failed the execution and the table involved.
The apparatus of claim 13 wherein said rollback execution module executing the generated reverse execution statement as a transaction in reverse order comprises:

The rollback execution module connects the corresponding database node, submits the generated reverse execution statement in units of transactions, executes the generated reverse execution statement in reverse order on the corresponding database node, and receives the reverse statement from the database node. The execution result to the execution statement.
The apparatus of claim 13 further comprising:

And submitting an execution module, configured to submit the branch transaction to the corresponding database node after receiving the branch transaction commit request initiated by the transaction manager, and feedback the branch transaction execution result response to the transaction according to the result of executing the branch transaction Manager.