CN110716793A - Execution method, device, equipment and storage medium of distributed transaction - Google Patents

Execution method, device, equipment and storage medium of distributed transaction Download PDF

Info

Publication number
CN110716793A
CN110716793A CN201910959082.5A CN201910959082A CN110716793A CN 110716793 A CN110716793 A CN 110716793A CN 201910959082 A CN201910959082 A CN 201910959082A CN 110716793 A CN110716793 A CN 110716793A
Authority
CN
China
Prior art keywords
resource manager
transaction
target transaction
resource
instruction
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201910959082.5A
Other languages
Chinese (zh)
Other versions
CN110716793B (en
Inventor
韩全安
陈福荣
崔玉明
夏晓健
邢颖
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Cloud Computing Beijing Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN201910959082.5A priority Critical patent/CN110716793B/en
Publication of CN110716793A publication Critical patent/CN110716793A/en
Application granted granted Critical
Publication of CN110716793B publication Critical patent/CN110716793B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/466—Transaction processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21—Design, administration or maintenance of databases

Abstract

The application discloses a method, a device, equipment and a storage medium for executing distributed transactions, wherein the method comprises the following steps: sending a prepare instruction to each first resource manager indicating to commit the target transaction; if the confirmation information of each first resource manager is received, sending a preset instruction to the second resource manager to indicate the second resource manager to submit the target transaction and record a transaction mark after successful submission; after the second resource manager successfully submits, sending a submission instruction indicating to submit the target transaction to the first resource manager; if error information returned by any first resource manager is received, a rollback instruction indicating a rollback target transaction is sent to each resource manager; and each first resource manager queries whether a corresponding transaction mark exists when the first resource manager is in a state of preparing to submit the target transaction for a preset time, if so, the target transaction is submitted, and otherwise, the target transaction is rolled back. The data consistency of each resource manager is effectively ensured.

Description

Execution method, device, equipment and storage medium of distributed transaction
Technical Field
The present application relates to the technical field of database management systems, and in particular, to a method, an apparatus, a device, and a storage medium for executing a distributed transaction.
Background
In the process of implementing distributed XA transactions in a Database Management System (DBMS), one or more resource managers that process the distributed XA transactions may occur due to a certain fault, and an exception may occur when preparing to commit the distributed XA transactions or rollback the XA transactions, so that data consistency of each resource manager that executes the distributed XA transactions cannot be guaranteed.
Content of application
The application aims to provide a method, a device, equipment and a storage medium for executing distributed transactions, which can ensure the data consistency of each resource manager executing the distributed transactions.
To achieve the above object, in one aspect, the present application provides a method for executing a distributed transaction, including:
sending a preparation instruction to each first resource manager in the resource manager cluster to indicate the corresponding first resource manager to enter a state of preparing to submit a target transaction; the resource manager cluster is composed of a second resource manager and at least one first resource manager;
if receiving confirmation information returned by each first resource manager, sending a preset instruction to the second resource manager to instruct the second resource manager to submit the target transaction and record a transaction mark corresponding to the target transaction after the target transaction is successfully submitted; after the second resource manager successfully submits, sending a submission instruction indicating that the target transaction is submitted to each first resource manager;
if error information returned by any one of the first resource managers is received, a rollback instruction indicating to rollback the target transaction is sent to each resource manager in the resource manager cluster;
and each first resource manager queries whether a transaction mark corresponding to the target transaction exists when the first resource manager is in a state of preparing to submit the target transaction for a preset time duration, submits the target transaction if the transaction mark exists, and rolls back the target transaction if the transaction mark does not exist.
In another aspect, the present application further provides an apparatus for executing a distributed transaction, including:
a first sending module configured to: sending a preparation instruction to each first resource manager in the resource manager cluster to indicate the corresponding first resource manager to enter a state of preparing to submit a target transaction; the resource manager cluster is composed of a second resource manager and at least one first resource manager;
a second sending module, configured to: if receiving confirmation information returned by each first resource manager, sending a preset instruction to the second resource manager to instruct the second resource manager to submit the target transaction and record a transaction mark corresponding to the target transaction after the target transaction is successfully submitted; after the second resource manager successfully submits, sending a submission instruction indicating that the target transaction is submitted to each first resource manager;
a third sending module, configured to: if error information returned by any one of the first resource managers is received, a rollback instruction indicating to rollback the target transaction is sent to each resource manager in the resource manager cluster;
and each first resource manager queries whether a transaction mark corresponding to the target transaction exists when the first resource manager is in a state of preparing to submit the target transaction for a preset time duration, submits the target transaction if the transaction mark exists, and rolls back the target transaction if the transaction mark does not exist.
In another aspect, the present application further provides a distributed transaction execution device, including:
a memory for storing a computer program;
and the processor is used for realizing the steps of the execution method of the distributed transaction when executing the computer program.
In yet another aspect, the present application further provides a computer readable storage medium having stored thereon a computer program which, when executed by a processor, implements the steps of the aforementioned method for performing distributed transactions.
In the technical scheme disclosed by the application, a preparation instruction for preparing to submit a target transaction is sent to each first resource manager in a resource manager cluster, after each first resource manager returns confirmation information, a preset instruction is sent to a second resource manager to indicate the second resource manager to submit the target transaction and record a transaction mark of the target transaction after successful submission, and after the second resource manager succeeds submission, an instruction for indicating to submit the target transaction is sent to each first resource manager to realize data consistency of each resource manager; after any first resource manager returns error information, in order to ensure the data consistency of each resource manager, an instruction of rolling back a target transaction is sent to each resource manager; meanwhile, each first resource manager can inquire whether a transaction mark corresponding to the target transaction is recorded when the first resource manager is in a state of preparing to submit the target transaction for a preset duration, if so, the target transaction is submitted, and otherwise, the target transaction is rolled back. Therefore, the two-stage submission of the second resource manager is degenerated into one-stage submission through the preset instruction, and particularly, the second resource manager is converted from the condition that the preparation instruction needs to be executed and the submission instruction needs to be executed to the condition that the preset instruction only needs to be executed to realize transaction submission and marking record, so that the interaction between the resource manager and the transaction manager is reduced, and the transaction execution flow is simplified; and when the target transaction in the first resource manager becomes a suspended transaction which is in a state of being ready to be submitted and lasts for a preset duration, the target transaction can be confirmed to be submitted or rolled back only by inquiring whether the transaction mark is recorded, so that the target transaction which becomes the suspended transaction is submitted when the second resource manager successfully submits the target transaction, and the target transaction which becomes the suspended transaction is rolled back when the second resource manager cannot realize the submission of the target transaction, thereby effectively ensuring the consistency of data in each resource manager.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly introduced below, it is obvious that the drawings in the following description are only embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to the provided drawings without creative efforts.
Fig. 1 is a block diagram of a system to which a method for executing a distributed transaction according to an embodiment of the present disclosure is applied;
fig. 2 is a first flowchart of a method for executing a distributed transaction according to an embodiment of the present application;
fig. 3 is a schematic flowchart illustrating a transaction manager converting a transaction into a distributed XA transaction to a resource manager in a method for executing a distributed transaction according to an embodiment of the present application;
fig. 4 is a schematic flowchart illustrating a process of sending a preparation instruction and a commit instruction to each first resource and sending a preset instruction to a second resource manager in a distributed transaction execution method according to an embodiment of the present application;
fig. 5 is a flowchart illustrating that a first resource manager implements a suspended transaction recovery function in a method for executing a distributed transaction according to an embodiment of the present application;
fig. 6 is a second flowchart of a method for executing a distributed transaction according to an embodiment of the present application;
fig. 7 is a third flowchart of a method for executing a distributed transaction according to an embodiment of the present application;
fig. 8 is a fourth flowchart of a method for executing a distributed transaction according to an embodiment of the present application;
fig. 9 is an interaction diagram of a method for executing a distributed transaction in a specific application scenario according to an embodiment of the present application;
fig. 10 is a schematic structural diagram of an execution apparatus for a distributed transaction according to an embodiment of the present application;
fig. 11 is a schematic structural diagram of a distributed transaction execution device according to an embodiment of the present application.
Detailed Description
A transaction is a logical unit in the execution process of a database management system and is composed of a limited database operation sequence. When a transaction is submitted to a database management system, the database management system needs to ensure that all operations in the transaction are successfully completed and the result is permanently stored in a database, and if some operations in the transaction are not successfully completed, all operations in the transaction need to be rolled back to a state before the transaction is executed; meanwhile, the transaction has no influence on the execution of the database or other transactions, and all the transactions can be considered to be operated independently.
A distributed transaction is a transaction that runs in a distributed environment, for which each operation step of the transaction is a service running on a different node (machine); the key to distributed transaction processing is that there must be a way to know all the actions a transaction does anywhere, and the decision to commit or rollback a transaction must produce a uniform result (either all commits or all rollbacks). Specifically, in a distributed system having a distributed environment, although each node can know that its own operation is successful or failed, it cannot know the success or failure of the operation of other nodes; therefore, when a transaction spans multiple nodes, in order to maintain the ACID (atomicity, consistency, isolation, persistence) characteristics of the transaction, a component serving as a coordinator needs to be introduced to uniformly master the operation results of all participant nodes and finally indicate whether the nodes need to actually commit the operation results, that is, to implement two-phase commit (2 PC). The algorithm idea of two-phase submission (2PC) can be summarized as follows: the participants inform the coordinator of the success or failure of the operation, and the coordinator determines whether each participant needs to submit the operation or suspend the operation according to the feedback information of all the participants.
The XA protocol is an interface standard between a Resource Manager (RM) and a Transaction Manager (TM), the XA interface of the XA protocol provides a standard interface for communication between the Resource Manager and the transaction Manager, and the XA protocol manages distributed transactions by means of two-phase commit, and at this time, the distributed transactions are referred to as distributed XA transactions (hereinafter, the referred transactions, and the XA transactions are all distributed XA transactions). Wherein, the transaction manager can convert the common transaction into a distributed XA transaction to interact with the resource manager; specifically, when receiving a behavior that an application (or application layer) opens a transaction, the transaction manager converts the transaction opened by the application into a distributed XA transaction and sends the distributed XA transaction to each resource manager, and controls each resource manager to perform operations of starting execution, ending execution, preparing to commit, committing/rolling back on the received distributed XA transaction in a manner of sending a corresponding instruction. In the actual execution process, software and hardware exceptions may occur in each phase of TM and RM interaction, and other steps may directly rollback a corresponding distributed XA transaction when an exception occurs, but if an exception occurs during preparation for commit, or rollback, such as a node failure occurs in a transaction manager or a resource manager, a resource manager in a state of preparation for commit needs to know how other resource managers process the distributed XA transaction, and can determine whether to commit or rollback the distributed XA transaction in the state of current preparation for commit.
One of the existing technical solutions to solve the above problems is to record an operation log in each transaction operation in the transaction manager, so that when a fault occurs, the state (commit or rollback) of the current transaction can be judged through the operation log, but this may result in recording too many operation logs, which greatly loses the performance of the transaction manager (by more than 80%), and if the machine of the transaction manager is necrotic, the judgment of the transaction state cannot be implemented, and thus the data consistency of each resource manager cannot be implemented. The other method is that the corresponding operation log is written into the resource manager after the resource manager prepares to commit and before the resource manager commits through the asynchronous thread, so that the state of the current transaction is judged through the operation log in the resource manager when a fault occurs, but the external thread loses a part of performance, and if the external thread fails to execute, the current transaction is in an intermediate semantic state which can be committed and can be rolled back, and further the data consistency of each resource manager cannot be realized.
In view of the above problems existing at present, the present application provides a technical solution for executing distributed transactions, and through the technical solution, the data consistency of each resource manager can be ensured while the performance is ensured.
For ease of understanding, a system architecture to which the technical solution of the present application is applicable is described below. Referring to fig. 1, a component architecture of a system to which a distributed transaction execution method of the present application is applicable is shown.
As shown in fig. 1, one component architecture of the system to which the distributed transaction execution method of the present application is applied may include a TM terminal 10, an RM terminal 20, and an application terminal 30, where the number of RM terminals 20 is at least two, and fig. 1 shows an implementation manner in which the number of RM terminals 20 is 3.
The TM terminal 10, the RM terminal 20, and the application terminal 30 may be computer devices, intelligent terminals, or other terminals that can be implemented by using computer programs, and the TM terminal 10, the RM terminal 20, and the application terminal 30 may be the same terminal or different terminals, which is not limited herein; fig. 1 shows an implementation mode in which the TM terminal 10 and the RM terminal 20 are both computer devices, and the application terminal 30 is an intelligent terminal.
For the TM terminal 10, in a possible case, the TM terminal 10 may include a TM, and the TM may perform data interaction with the RM terminal 20 and the application terminal 30, specifically, when receiving a behavior that the application terminal 30 starts a transaction, the TM may convert the transaction started by the application terminal 30 into a distributed transaction, set a corresponding transaction flag xid, distribute the distributed transaction to each RM terminal 20, send a corresponding instruction to each RM terminal to control the execution of the distributed transaction, and return a corresponding execution result to the application terminal 30 after the execution is completed.
In one possible scenario, the TM terminal 10 may include a monitoring program, and the monitoring program may monitor the TM to implement the corresponding function; in the process that the TM realizes transaction conversion and performs data interaction with other terminals, the monitoring program monitors the operation performed by the TM in real time so as to output corresponding prompt information when the transaction conversion fails or the data transmission fails or the data reception fails, and the like, so that a worker can perform corresponding repair operation on the TM after knowing the prompt information.
In a possible case, the TM terminal 10 may further include a human-machine interaction interface, where the human-machine interaction interface may be used for displaying the prompt information to the outside, and may further allow an external worker to input a corresponding instruction for a repair operation on the human-machine interaction interface, so as to implement the repair of the TM under the control of the instruction.
For the RM terminal 20, the RM terminal 20 may include an RM, and the RM is configured to implement the distributed transaction, and in particular, the RM may execute the received distributed transaction under the instruction sent by the TM terminal after receiving the distributed transaction distributed by the TM terminal.
In a possible case, the RM terminal may include a thread pool, and the thread pool may include a plurality of threads for executing the distributed transaction, so that after receiving the plurality of distributed transactions allocated by the TM terminal, the plurality of threads may be acquired from the thread pool, and then the plurality of threads are used to implement the execution of the distributed transactions in parallel, thereby improving the transaction execution efficiency.
For the application terminal 30, the application terminal 30 may include at least one application, and the application may open a transaction, thereby controlling the TM terminal to implement execution of the transaction.
In a possible case, the application terminal 30 may include an instruction response program, and the instruction response program may implement a corresponding operation after receiving a corresponding instruction input from the outside, where the corresponding instruction input from the outside may be an instruction to open or close a certain application included in the application terminal 30, or an instruction to install or uninstall a certain application included in the application terminal 30.
Referring to fig. 2, a flowchart of an execution method of a distributed transaction according to an embodiment of the present application is shown, where the execution method may include:
s101: sending a preparation instruction to each first resource manager in the resource manager cluster to instruct the corresponding first resource manager to enter a state of preparing to submit a target transaction (or a state of preparing to submit a target transaction); the resource manager cluster is composed of a second resource manager and at least one first resource manager; and each first resource manager queries whether a transaction mark corresponding to the target transaction exists when the first resource manager is in a state of preparing to submit the target transaction for a preset time, if so, the target transaction is submitted, and otherwise, the target transaction is rolled back.
An execution subject of the execution method for a distributed transaction provided in the embodiment of the present application may be a corresponding execution device, and the execution device may be disposed in a transaction manager, so that the execution subject of the execution method for a distributed transaction provided in the embodiment of the present application may be a transaction manager; the following description will be made with the execution principal as the transaction manager, if necessary.
The distributed transaction relates to a transaction manager and a plurality of resource managers, wherein the first resource manager and the second resource manager are both resource managers which are allocated with the distributed transaction, the distributed transaction can be specifically a distributed XA transaction, and can also be other distributed transactions which need to be executed by using a plurality of resource managers; in this embodiment, the transaction manager may use TenDBCluster (a distributed database solution for development and maintenance of a game scenario), and the resource manager may use TenDB (a MySQL branch version for development and maintenance of a game scenario); MySQL corresponds to an XA instruction that executes a distributed XA transaction, which may include (where xid represents a marker for the transaction):
XA START xid: starting a transaction, and putting the transaction in an ACTIVE state, and then putting the executed SQL statement in the transaction;
XAEND xid: executing XA END xid after executing a series of DMLs on the transaction in the ACTIVE state to place the transaction in an IDLE state, wherein the IDLE state represents that SQL statements in the transaction are completed corresponding to SQL operations;
XA PREPARE xid: after SQL operation is completed in the transaction, the preparation work of transaction submission is carried out through XA PREPARE xid, and the transaction is placed in a PREPARED state;
XA COMMIT xid: after all the resource managers are in a PREPARE state, respectively executing XA COMMITxid to finally submit the transaction and finish persistence;
XA ROLLBACK xid: when an exception exists in XA PREPARE xid or the transaction is voluntarily abandoned, XAROLLBACK xid is executed to roll back the transaction.
XA RECOVER: transaction to see PREPARED status present in MySQL.
Correspondingly, assuming that two resource managers (denoted as RM1 and RM2, respectively) are mounted in the resource manager cluster, and a distributed XA transaction is executed on a transaction manager, the flow of the transaction manager converting the distributed XA transaction into the distributed XA transaction to the resource manager may be as shown in fig. 3 (assuming that all operations are executed with correct information, and therefore no information is passed from the transaction manager to the application or from the resource manager to the transaction manager in the flow chart), which specifically may include:
when an Application (Application) opens (begin) transaction, the TM converts the transaction into a distributed XA transaction (target transaction, transaction labeled xid), and distributes the target transaction to RM1 and RM2 for execution; sending XASTART xid to RM1 and RM2, respectively, to indicate the start of execution of the target transaction; receiving operation instructions (insert inter t1(c1) values (1); update t2 set c2 ═ 3 where c 1;) sent by an application, and allocating the corresponding operation instructions to RM1 and RM2 respectively for execution (RM1: insert inter xxx; RM2: update t2 xxx); the TM receives an instruction sent by an application and indicating commit (commit), and sends XA END xid and XA PREPARE xid to RM1 and RM2 respectively; if both RM1 and RM2 return acknowledgement information, XA COMMIT xid is sent to RM1 and RM2, respectively, to indicate RM1 and RM2 to COMMIT the target transaction.
In practical applications, a transaction that is common to an application may be as follows:
begin；
insert into t1(c1,c2)values(1,2)；
update t2 set c2＝3 where c1＝2；
commit；
when processing the transaction started by the application, the transaction manager can convert the normal transaction into a distributed XA transaction to interact with the resource manager, as shown in FIG. 2, when the transaction manager receives the action of starting the transaction by the application, the transaction manager sets an XA transaction flag xid; when receiving a DML request of an application, a transaction manager sends XA START xid to each resource manager executing a distributed XA transaction, and executes the DML request in the corresponding resource manager; when the transaction manager receives a transaction submitting request of an application, executing XA END xid and XA PREPARE xid to each resource manager in sequence; if the execution of the distributed XA transaction is normal, the transaction manager executes XA COMMIT xid to each resource manager node; if there is a return error, the transaction manager executes XA ROLLBACK xid to the respective resource manager.
In this embodiment, the resource manager cluster includes a plurality of (greater than 1) resource managers, where the resource managers in the resource manager cluster are all a first resource manager or a second resource manager, and the first resource manager and the second resource manager may be the same resource manager, except that the instructions sent by the transaction manager, which are received and executed by the first resource manager and the second resource manager, are different. After the transaction manager issues XASTART xid and XA END xid in sequence to each resource manager in the resource manager cluster, and when there is no exception, that is, at the END of the first phase of the two-phase commit (the transaction manager corresponds to the coordinator in the two-phase commit, and the resource manager corresponds to the participant in the two-phase commit), a PREPARE instruction (XA PREPARE xid) is sent to each first resource manager, and the first resource manager receiving the PREPARE instruction enters a state of preparing to commit a target transaction, where the target transaction may be any distributed XA transaction to be executed.
S102: if receiving confirmation information returned by each first resource manager, sending a preset instruction to the second resource manager to instruct the second resource manager to submit the target transaction and record a transaction mark corresponding to the target transaction after successful submission; and after the second resource manager successfully commits, sending a commit instruction indicating that the target transaction is committed to each first resource manager.
After the transaction manager sends a preparation instruction to each first resource manager, each first resource manager can perform work to be submitted under the trigger of the instruction, and enters a state of preparing to submit a target transaction after the work to be submitted is completed, if the work to be submitted is completed normally, confirmation information is returned to the transaction manager, and if the transaction manager receives the confirmation information returned by each first resource manager, the information returned by each first resource manager indicates that the target transaction can be submitted; at this time, a preset instruction (XA COMMIT PHASE) is sent to the second resource manager, the two-PHASE COMMIT degradation that the second resource manager should implement is a ONE-PHASE COMMIT through the preset instruction, that is, the preparation instruction and the COMMIT instruction that need to be issued to the second resource manager are converted into the preset instruction, so that the second resource manager directly COMMITs the distributed XA transaction after receiving the preset instruction, if the result of committing the distributed XA transaction by the second resource manager is successful, the transaction token corresponding to the target transaction is recorded, specifically, the second resource manager records the transaction token corresponding to the target transaction in the local storage, and if the result of committing the distributed XA transaction by the second resource manager is failed, the transaction token corresponding to the target transaction does not need to be recorded.
In addition, the second resource manager may return information of successful submission to the transaction manager after the target transaction is successfully submitted, or the transaction manager may obtain the information of successful submission of the target transaction by the second resource manager through other manners set according to actual needs, which is within the protection scope of the present application. After learning that the second resource manager successfully submits the target transaction, the transaction manager sends a COMMIT instruction (XA COMMIT xid) to each first resource manager, so that each first resource manager submits the target transaction after receiving the COMMIT instruction, and therefore each resource manager in the resource manager cluster submits the target transaction, and data consistency is achieved.
Assuming that the number of resource managers involved in the target transaction is four, and all the target transactions return acknowledgement information, the flow of sending the prepare instruction and the commit instruction to each first resource and sending the preset instruction to the second resource manager in this embodiment may be as shown in fig. 4, where the number in front of each instruction indicates the execution sequence of the instruction, that is, 1.1 to 1.4 are executed first, and then 1.1 to 1.3 are executed.
S103: and if error information returned by any first resource manager is received, sending a rollback instruction indicating a rollback target transaction to each resource manager in the resource manager cluster.
After the transaction manager sends a preparation instruction to each first resource manager, each first resource manager can perform the work to be submitted under the trigger of the instruction, and enters a state of preparing to submit a target transaction after the work to be submitted is completed, and if the work to be submitted is abnormal, error information is returned to the transaction manager; if the transaction manager receives error information returned by at least one first resource manager, the transaction manager indicates that the target transaction needs to be rolled back by the information returned by the first resource manager, in order to maintain the data consistency of each resource manager in the resource manager cluster, a roll-back instruction (XA roll back) needs to be sent to all the resource managers in the resource manager cluster, and each resource manager rolls back the target transaction after receiving the roll-back instruction so as to return to a state before each resource manager executes the target transaction.
For the fact that "each first resource manager queries whether a transaction flag corresponding to a target transaction exists when the first resource manager is in a state of preparing to commit the target transaction for a preset duration, and commits the target transaction if the transaction flag exists, and rolls back the target transaction if the transaction flag exists, it should be noted that each first resource manager has a suspended transaction recovery function, where a suspended transaction is a transaction in a state of preparing to commit for a long time, and in this embodiment, a transaction in a state of preparing to commit the transaction for a preset duration and a transaction in a state of preparing to commit for a longer time than the preset duration is set as a suspended transaction (the preset duration may be set according to actual needs, such as 30 seconds or 1 minute, and the case is usually caused by a node failure occurring in the TM or RM, including that the transaction manager fails to send a commit instruction or a rollback instruction to the resource manager, The resource manager does not successfully receive a commit instruction or a rollback instruction sent by the transaction manager, the resource manager does not successfully commit or rollback the transaction, and the like; at this time, in order to ensure data consistency of each resource manager for the same transaction, corresponding processing needs to be performed on the pending transaction. Specifically, in this embodiment, each resource manager may query in real time or at regular time whether there is a transaction with a state of being ready to commit and lasting for a preset duration, or each resource manager may query in real time or at regular time whether it is in a state of being ready to commit for a preset duration, and if so, the transaction with the above characteristics, that is, the pending transaction, needs to be processed. After the target transaction is determined to be the suspension transaction, whether a transaction mark corresponding to the target transaction is recorded or not can be inquired, if yes, the information returned to the transaction manager by each first resource manager responding to the preparation instruction is confirmation information, and the second resource manager successfully submits the target transaction, so that the suspension transaction needs to be submitted in order to ensure data consistency; if not, it indicates that there may be error information in the information returned to the transaction manager by each first resource manager in response to the preparation instruction, that the information returned to the transaction manager by each first resource manager in response to the preparation instruction is all confirmation information, and that the second resource manager fails to submit the target transaction, or that other abnormal conditions are caused by node failure of the TM or RM, and therefore, in order to ensure data consistency, the suspended transaction needs to be rolled back.
It should be noted that, in this embodiment, the suspended transaction recovery function of each first resource manager may be implemented by a background thread deployed on each first resource manager, and the background thread is used to detect whether a suspended transaction exists in the resource manager to which the suspended transaction belongs, and determine whether to submit or rollback the suspended transaction by querying whether a transaction flag corresponding to the suspended transaction is recorded as long as the suspended transaction exists. Additionally, a flow diagram of the first resource manager implementing the pending transaction recovery function may be as shown in FIG. 5.
In the technical scheme disclosed by the application, a preparation instruction for preparing to submit a target transaction is sent to each first resource manager in a resource manager cluster, after each first resource manager returns confirmation information, a preset instruction is sent to a second resource manager to indicate the second resource manager to submit the target transaction and record a transaction mark of the target transaction after successful submission, and after the second resource manager succeeds submission, an instruction for indicating to submit the target transaction is sent to each first resource manager to realize data consistency of each resource manager; after any first resource manager returns error information, in order to ensure the data consistency of each resource manager, an instruction of rolling back a target transaction is sent to each resource manager; meanwhile, each first resource manager can inquire whether a transaction mark corresponding to the target transaction is recorded when the first resource manager is in a state of preparing to submit the target transaction for a preset duration, if so, the target transaction is submitted, and otherwise, the target transaction is rolled back. Therefore, the two-stage submission of the second resource manager is degenerated into one-stage submission through the preset instruction, and particularly, the second resource manager is converted from the condition that the preparation instruction needs to be executed and the submission instruction needs to be executed to the condition that the preset instruction only needs to be executed to realize transaction submission and marking record, so that the interaction between the resource manager and the transaction manager is reduced, and the transaction execution flow is simplified; when the target transaction in the first resource manager becomes a suspended transaction which is in a state of being ready to be submitted and lasts for a preset duration, the target transaction can be confirmed to be submitted or rolled back only by inquiring whether the transaction mark is recorded or not, so that the target transaction which becomes the suspended transaction is submitted when the second resource manager successfully submits the target transaction, and the target transaction which becomes the suspended transaction is rolled back when the second resource manager cannot realize the submission of the target transaction, thereby effectively ensuring the consistency of data in each resource manager; meanwhile, asynchronous threads are not introduced, and operation logs of each step of transaction operation do not need to be recorded, so that the execution performance of distributed transactions is guaranteed, and the condition that the data consistency of each resource manager cannot be realized due to machine necrosis of the transaction manager or failure of external thread execution is avoided.
In a specific implementation manner, a flowchart of a method for executing a distributed transaction provided in an embodiment of the present application may be as shown in fig. 6, and specifically may include:
s104: and randomly selecting one resource manager from the resource managers contained in the resource manager cluster as a second resource manager, and determining that all the resource managers except the second resource manager in the resource manager cluster are the first resource managers.
It should be noted that in each embodiment of the present application, the number of the second resource managers may be one, and of course, other settings may be performed according to actual needs, and all of them are within the protection scope of the present application.
S105: and setting corresponding numbers for the first resource managers.
Correspondingly, the step of sending the preparation instruction to each first resource manager in the resource manager cluster in step S101 may include:
and sending a preparation instruction to each first resource manager in the resource manager cluster in sequence according to the sequence of the set numbers.
In this embodiment, the determination of the first resource manager and the second resource manager may be implemented in a random manner, that is, one resource manager in the resource manager cluster is randomly selected as the second resource manager, and the other resource managers are the first resource managers; in this case, the first resource manager and the second resource manager may be determined for each distributed XA transaction to be executed in the foregoing manner, and the resource managers corresponding to different distributed XA transactions may be divided differently, so that the resource managers may be divided more flexibly. Because the first resource manager and the second resource manager are determined randomly, the resource manager where the transaction mark is located cannot be determined when the first resource manager needs to query the transaction mark, and therefore the first resource manager can sequentially query the transaction mark in each transaction manager, and determine whether the corresponding transaction mark is recorded.
On this basis, corresponding numbers may be set for the first resource managers, specifically, the setting may be performed according to actual needs, for example, each first resource manager is set to RM1 to RMn (n is the number of resource managers); therefore, when the preparation instructions are sent to the first resource managers, the preparation instructions can be sent to the first resource managers in sequence according to the sequence of the serial numbers set for the first resource managers from large to small or from small to large, and therefore missing sending or repeated sending during issuing of the preparation instructions can be avoided; since there is only one second resource manager, after setting corresponding numbers for each first resource manager, it can be determined that the resource manager without the number is the second resource manager, and then corresponding instructions are sent to the second resource manager; certainly, a number different from that of the first resource manager can also be set for the second resource manager, and then the number is directly used for positioning to the second resource manager to realize the sending of the corresponding instruction; are all within the scope of the present application. In addition, the sending of other instructions that need to be sent to the first resource manager may also be implemented according to the order of the numbers, for example, a start instruction, an end instruction, a commit instruction, a rollback instruction, and the like are implemented to the first resource manager, so that missed sending or repeated sending of the instructions is further avoided.
In another specific implementation, a flowchart of a method for executing a distributed transaction provided in an embodiment of the present application may be as shown in fig. 7, and specifically may include:
s106: calling preset number recording information; the number recording information comprises numbers which are preset for all resource managers in the resource manager cluster.
Correspondingly, the step of sending the preparation instruction to each first resource manager in the resource manager cluster in step S101 may include:
and sending a preparation instruction to each preset first resource manager in the resource manager cluster in sequence according to the sequence of the numbers recorded in the number recording information.
In this embodiment, the first resource manager and the second resource manager may be predetermined, so that the first resource manager and the second resource manager corresponding to different transactions are the same, and thus, when the first resource manager needs to query the transaction mark, the first resource manager can directly query the unique second resource manager, thereby improving the processing efficiency of the pending transaction. Moreover, a corresponding number can be preset for each resource manager, and number record information which represents the corresponding relation between the resource manager and the corresponding number can be obtained, and the number record information can be recorded in a preset information table so as to facilitate management and query; correspondingly, when the preparation instruction is sent to each first resource manager, the preparation instruction can be sent to each first resource manager in sequence according to the sequence from large to small or from small to large of the numbers of all the first resource managers in the number recording information, so that omission or repetition of the first resource managers can be avoided when the preparation instruction is issued; in addition, the sending of other instructions that need to be sent to the first resource manager may also be implemented according to the order of the numbers, for example, a start instruction, an end instruction, a commit instruction, a rollback instruction, and the like are implemented to the first resource manager, so that missed sending or repeated sending of the instructions is further avoided.
In another specific implementation, a flowchart of a method for executing a distributed transaction provided in an embodiment of the present application may be as shown in fig. 8, and specifically may include:
s201: before the second resource manager records the transaction mark corresponding to the target transaction, the second resource manager calls a local preset submission log table.
Because the preset instruction is introduced into the transaction manager, a function corresponding to the preset instruction needs to be implemented in the second resource manager, that is, the second resource manager commits the target transaction and needs to record the transaction flag of the target transaction after the target transaction is successfully committed, which may be recorded in a commit log (xa _ commit _ log) of the commit log table. Therefore, through the setting of the submitted log table, the submitted log is convenient to store, and the submitted log is convenient to manage and query.
S202: and after the second resource manager successfully submits the target transaction, the second resource manager records the transaction mark corresponding to the target transaction into the submission log table.
S203: after the second resource manager successfully submits the target transaction, the second resource manager identifies the time at the current moment as the submission time of the target transaction, and records the submission time to a position corresponding to the transaction mark of the target transaction in the submission log table.
In this embodiment, when the transaction mark is recorded, the time of successfully submitting the target transaction may also be recorded at the same time, specifically, after the second resource manager successfully submits the target transaction, the time of the current time is recorded as the submission time of the target transaction, and then both the transaction mark and the submission time of the target transaction are recorded in the submission log table, so that when corresponding information query needs to be performed, only the submission log table needs to be called to obtain the successfully submitted transaction and the time of successfully submitting the transaction. In addition, as shown in this embodiment, after the transaction mark corresponding to the target transaction is recorded in the commit log table, the commit time of the target transaction is committed to the position corresponding to the transaction mark of the target transaction, so as to implement the identification of the corresponding relationship between the two; the transaction mark and the commit time of the target transaction can be recorded to the corresponding position in the commit log table at the same time, so that the information recording efficiency is improved; of course, other settings may be performed according to actual needs, all of which are within the protection scope of the present application, and in a specific example, the respective log marks and the corresponding submission logs may be as follows:
in another specific implementation, the method for executing a distributed transaction provided in the embodiment of the present application may further include:
after receiving the preparation instruction, the first resource manager records the time of the current moment as the starting time of the corresponding first resource manager entering the state of preparing to submit the target transaction;
correspondingly, the determining, by the first resource manager, whether the state in which the first resource manager is ready to commit the target transaction lasts for the preset duration may include:
and the first resource manager judges whether the time period from the recorded starting time to the current time reaches a preset time length in real time.
It should be noted that, in order to ensure that the suspended transaction can be automatically recovered when an exception occurs, in the present application, a suspended transaction that needs to be automatically recovered when a state of preparing to commit continues for a preset time duration is defined (a state of entering a state of preparing to commit a target transaction is a state of entering a state of preparing to commit a target transaction); in order to determine whether the target transaction is a suspended transaction in an effective and simple manner, in this embodiment, after the first resource manager receives the preparation instruction, the time at the current moment is recorded as the start time of the state of the target transaction ready for submission to be stored locally, and then it is determined whether the state of the target transaction ready for submission lasts for the preset time length only by judging whether the elapsed time from the recorded start time to the current moment reaches the preset time length in real time. In another case, in order to reduce the resource waste, it may be determined whether the time elapsed from the recorded start time to the current time reaches a preset time period at regular time. In one specific example, increasing the start time of a task in the first explorer may be as follows:
Figure BDA0002228327790000151
Figure BDA0002228327790000161
in another specific implementation, the method for executing a distributed transaction provided in the embodiment of the present application may further include:
if the first resource manager fails to commit or rollback the target transaction when the first resource manager is in a state of preparing to commit the target transaction for a preset time, returning to the step of performing the commit or rollback of the target transaction until the commit or rollback of the target transaction is successful.
It should be noted that, when the target transaction is in the state ready for submission and exceeds the preset time duration, the target transaction also belongs to a pending transaction, so as to further ensure the consistency of data in each resource manager, in this embodiment, when the first resource manager is in the state ready for submission of the target transaction and continues for the preset time duration, regardless of whether the target transaction is submitted or rolled back, if the result is a failure, the step of directly returning to execute or returning to execute the step of submitting or rolling back the target transaction after a certain time interval preset according to actual needs, that is, if the target transaction is submitted to a failure, the step of returning to execute as the step of submitting the target transaction is returned, and if the target transaction is rolled back to a failure, the step of returning to execute as the step of rolling back the target transaction is returned; until the commit or rollback target transaction is successful.
In addition, three return results which are returned to the application when the transaction is executed on the transaction manager are defined, namely SUCCESS, FAILURE and TIMEOUT; wherein, success indicates that the transaction execution process is normal, and finally the related resource managers execute the commit instruction; failure represents that expected errors occur in the transaction execution process, and finally, all related resource managers execute a rollback instruction; the timeout indicates unexpected exception (such as software and hardware failure) in the transaction execution process, at this time, the transaction may be in a non-consistent state, and it needs to be queried whether the transaction is successful or failed after a period of time elapses. In this way, the application can directly know the execution condition of the transaction.
For ease of understanding, referring to fig. 9, an application scenario of the present solution is described, and the execution process of the distributed XA transaction is described below as an application scenario in which the transaction manager is TenDB Cluster, the resource manager is TenDB, and the application is a game application. Wherein, it is assumed that RM1 represents a first resource manager and RM2 represents a second resource manager, the number of the first resource managers is not limited; and assuming that the target transaction is normal until it enters the ready-to-commit state.
When the game application starts a transaction, the TenDB Cluster converts the transaction into a distributed XA transaction (target transaction, which is marked as xid), and distributes the target transaction to RM1 and RM2 for execution; sending XASTART xid to each TenDB to indicate the start of execution of the target transaction; receiving operation instructions (insert inter t1(c1) values (1); update t2 set c2 ═ 3 where c 1;) sent by a game application, and allocating the corresponding instructions to each TenDB for execution (RM1: insert inter xxx; RM2: update t2 xxx); the TenDB Cluster receives an instruction which is sent by the game application and indicates submission, sends XA END xid to each TenDB, and sends XA PREPARE xid to RM 1; if RM1 returns an acknowledgement, send XA COMMIT xid ONE PHASE to RM2 to indicate RM2 to record the corresponding transaction marker into the local log COMMIT table if the COMMIT target transaction is successful; and after RM2 COMMITs successfully, sending XA COMMIT xid to RM 1; if RM1 returns an error message, XA ROLLBACK xid is sent to each TenDB. Additionally, RM1 queries RM2 for a transaction flag for the target transaction when the target transaction is in a ready-to-commit state for 30 seconds, and commits the target transaction if queried, otherwise rolls back the target transaction.
According to the method and the system, after the first resource managers return the confirmation information based on the preparation instruction, the second resource manager executes XA COMMIT xid ONE PHASE WITH LOG, and the atomic access operation ensures that the corresponding transaction mark can be recorded in the second resource manager when the transaction is successfully submitted, and the transaction is not recorded when the transaction is unsuccessfully submitted. And a background thread deployed in the first resource manager inquires the suspended transaction with the current ready-to-commit state lasting a preset duration and automatically arbitrates to commit or rollback the suspended transaction by inquiring a transaction mark corresponding to the suspended transaction, so that an XA distribution flow is optimized, the suspended distributed XA transaction is efficiently recovered, and the final consistency requirement of RM data under an abnormal scene is ensured.
An embodiment of the present application further provides an apparatus for executing a distributed transaction, as shown in fig. 10, where the apparatus may include:
a first sending module 111 configured to: sending a preparation instruction to each first resource manager in the resource manager cluster to indicate the corresponding first resource manager to enter a state of preparing to submit a target transaction; the resource manager cluster is composed of a second resource manager and at least one first resource manager;
a second sending module 112, configured to: if receiving confirmation information returned by each first resource manager, sending a preset instruction to the second resource manager to instruct the second resource manager to submit the target transaction and record a transaction mark corresponding to the target transaction after successful submission; after the second resource manager successfully submits, sending a submission instruction indicating to submit the target transaction to each first resource manager;
a third sending module 113, configured to: if error information returned by any first resource manager is received, a rollback instruction indicating a rollback target transaction is sent to each resource manager in the resource manager cluster;
and each first resource manager queries whether a transaction mark corresponding to the target transaction exists when the first resource manager is in a state of preparing to submit the target transaction for a preset time, submits the target transaction if the transaction mark exists, and rolls back the target transaction if the transaction mark does not exist.
In one possible implementation, the method may further include:
a setup module to: before sending a preparation instruction to each first resource manager in the resource manager cluster, randomly selecting one resource manager from the resource managers included in the resource manager cluster as a second resource manager, and determining that all the other resource managers except the second resource manager in the resource manager cluster are the first resource managers; setting corresponding numbers for the first resource managers;
correspondingly, the first sending module may include:
a first sending unit configured to: and sending a preparation instruction to each first resource manager in the resource manager cluster in sequence according to the sequence of the set numbers.
In another possible implementation manner, the method may further include:
a retrieval module to: calling preset number recording information before sending a preparation instruction to each first resource manager in the resource manager cluster; the number recording information comprises numbers which are preset for all resource managers in the resource manager cluster;
correspondingly, the first sending module may include:
a second transmitting unit configured to: and sending a preparation instruction to each preset first resource manager in the resource manager cluster in sequence according to the sequence of the numbers recorded in the number recording information.
Further, an embodiment of the present application further provides a distributed transaction execution device, which may include:
a memory for storing a computer program;
a processor for implementing the steps of the method for executing distributed transactions disclosed in any of the foregoing embodiments when executing the computer program.
Specifically, the execution device may be the terminal 40 shown in fig. 11, fig. 11 is a block diagram of the execution device shown according to an exemplary embodiment, and the content in the diagram cannot be considered as any limitation to the scope of use of the present application.
Fig. 11 is a schematic structural diagram of an execution device according to an embodiment of the present disclosure, where the terminal 40 may specifically include, but is not limited to, a smart phone, a tablet computer, a notebook computer, or a desktop computer.
In general, the terminal 40 in this embodiment includes: a processor 41 and a memory 42.
Processor 41 may include one or more processing cores, such as a 4-core processor, an 8-core processor, and so forth. The processor 41 may be implemented in at least one hardware form of a DSP (Digital Signal Processing), an FPGA (Field-Programmable Gate Array), and a PLA (Programmable Logic Array). The processor 41 may also include a main processor and a coprocessor, the main processor is a processor for processing data in an awake state, and is also called a Central Processing Unit (CPU); a coprocessor is a low power processor for processing data in a standby state. In some embodiments, the processor 41 may be integrated with a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content required to be displayed on the display screen. In some embodiments, processor 41 may further include an AI (Artificial Intelligence) processor for processing computational operations related to machine learning.
Memory 42 may include one or more computer-readable storage media, which may be non-transitory. Memory 42 may also include high speed random access memory, as well as non-volatile memory, such as one or more magnetic disk storage devices, flash memory storage devices. In this embodiment, the memory 42 is at least used for storing a computer program 421, wherein when the computer program is executed by the processor 41, the relevant steps in the execution method of the distributed transaction disclosed in any of the foregoing embodiments can be implemented. In addition, the resources stored by the memory 42 may also include an operating system 422, data 423, and the like, and the storage may be transient storage or persistent storage. Operating system 422 may include Windows, Unix, Linux, etc. Data 423 may include, but is not limited to, test instruction data, user identity data, and the like.
In some embodiments, the terminal 40 may also include a display 43, an input/output interface 44, a communication interface 45, sensors 46, a power source 47, and a communication bus 48.
Those skilled in the art will appreciate that the configuration shown in fig. 11 is not intended to be limiting of terminal 40 and may include more or fewer components than those shown.
Further, an embodiment of the present application also discloses a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of the execution method of the distributed transaction as disclosed in any of the foregoing embodiments are implemented.
It should be noted that the above-mentioned embodiments are only preferred embodiments of the present application, and are not intended to limit the present application, and any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present application should be included in the protection scope of the present application.
The embodiments are described in a progressive manner, each embodiment focuses on differences from other embodiments, and the same or similar parts among the embodiments are referred to each other. The device disclosed by the embodiment corresponds to the method disclosed by the embodiment, so that the description is simple, and the relevant points can be referred to the method part for description.
The above detailed description is provided for a method, an apparatus, a device, and a storage medium for executing a distributed transaction, and a specific example is applied in this document to explain the principle and the implementation of the present application, and the description of the above embodiment is only used to help understand the method and the core idea of the present application; meanwhile, for a person skilled in the art, according to the idea of the present application, there may be variations in the specific embodiments and application scope, and in summary, the content of the present specification should not be construed as a limitation to the present application.

Claims (10)

1. A method for executing a distributed transaction, comprising:
sending a preparation instruction to each first resource manager in the resource manager cluster to indicate the corresponding first resource manager to enter a state of preparing to submit a target transaction; the resource manager cluster is composed of a second resource manager and at least one first resource manager;
if receiving confirmation information returned by each first resource manager, sending a preset instruction to the second resource manager to instruct the second resource manager to submit the target transaction and record a transaction mark corresponding to the target transaction after the target transaction is successfully submitted; after the second resource manager successfully submits, sending a submission instruction indicating that the target transaction is submitted to each first resource manager;
if error information returned by any one of the first resource managers is received, a rollback instruction indicating to rollback the target transaction is sent to each resource manager in the resource manager cluster;
and each first resource manager queries whether a transaction mark corresponding to the target transaction exists when the first resource manager is in a state of preparing to submit the target transaction for a preset time duration, submits the target transaction if the transaction mark exists, and rolls back the target transaction if the transaction mark does not exist.
2. The method of claim 1, wherein prior to sending the prepare instruction to each first resource manager in the cluster of resource managers, further comprising:
randomly selecting one resource manager from resource managers contained in the resource manager cluster as a second resource manager, and determining that all the resource managers except the second resource manager in the resource manager cluster are first resource managers;
setting a corresponding number for each first resource manager;
the sending a preparation instruction to each first resource manager in the resource manager cluster includes:
and sending a preparation instruction to each first resource manager in the resource manager cluster in sequence according to the sequence of the set numbers.
3. The method of claim 1, wherein prior to sending the prepare instruction to each first resource manager in the cluster of resource managers, further comprising:
calling preset number recording information; the number recording information comprises numbers which are preset for all resource managers in the resource manager cluster;
the sending a preparation instruction to each first resource manager in the resource manager cluster includes:
and sending a preparation instruction to each preset first resource manager in the resource manager cluster in sequence according to the sequence of the numbers recorded in the number recording information.
4. The method according to claim 2 or 3, wherein before the second resource manager records the transaction flag corresponding to the target transaction, further comprising:
the second resource manager calls a locally preset submission log table;
the second resource manager records a transaction mark corresponding to the target transaction, and the transaction mark comprises:
and the second resource manager records the transaction mark corresponding to the target transaction into the submission log table.
5. The method of claim 4, further comprising:
after the second resource manager successfully submits the target transaction, recognizing the time of the current moment as the submission time of the target transaction;
and the second resource manager records the commit time to a position corresponding to the transaction mark of the target transaction in the commit log table.
6. The method of claim 5, further comprising:
after the first resource manager receives the preparation instruction, recording the time of the current moment as the starting time of the state of the corresponding first resource manager entering the preparation submission target transaction;
the method for judging whether the state of the first resource manager in preparation for submitting the target transaction lasts for a preset duration includes the following steps:
and the first resource manager judges whether the time period from the recorded starting time to the current time reaches the preset time length in real time.
7. The method of claim 6, further comprising:
if the first resource manager fails to commit or rollback the target transaction when the first resource manager is in a state of preparing to commit the target transaction for a preset time, returning to the step of performing the commit or rollback of the target transaction until the target transaction is successfully committed or rolled back.
8. An apparatus for performing a distributed transaction, comprising:
a first sending module configured to: sending a preparation instruction to each first resource manager in the resource manager cluster to indicate the corresponding first resource manager to enter a state of preparing to submit a target transaction; the resource manager cluster is composed of a second resource manager and at least one first resource manager;
a second sending module, configured to: if receiving confirmation information returned by each first resource manager, sending a preset instruction to the second resource manager to instruct the second resource manager to submit the target transaction and record a transaction mark corresponding to the target transaction after the target transaction is successfully submitted; after the second resource manager successfully submits, sending a submission instruction indicating that the target transaction is submitted to each first resource manager;
a third sending module, configured to: if error information returned by any one of the first resource managers is received, a rollback instruction indicating to rollback the target transaction is sent to each resource manager in the resource manager cluster;
and each first resource manager queries whether a transaction mark corresponding to the target transaction exists when the first resource manager is in a state of preparing to submit the target transaction for a preset time duration, submits the target transaction if the transaction mark exists, and rolls back the target transaction if the transaction mark does not exist.
9. An apparatus for executing a distributed transaction, comprising:
a memory for storing a computer program;
a processor for implementing the steps of the method of performing a distributed transaction according to any of claims 1 to 7 when executing said computer program.
10. A computer-readable storage medium, characterized in that a computer program is stored on the computer-readable storage medium, which computer program, when being executed by a processor, carries out the steps of the method of execution of a distributed transaction according to any one of claims 1 to 7.
CN201910959082.5A 2019-10-10 2019-10-10 Method, device, equipment and storage medium for executing distributed transaction Active CN110716793B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910959082.5A CN110716793B (en) 2019-10-10 2019-10-10 Method, device, equipment and storage medium for executing distributed transaction

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910959082.5A CN110716793B (en) 2019-10-10 2019-10-10 Method, device, equipment and storage medium for executing distributed transaction

Publications (2)

Publication Number Publication Date
CN110716793A true CN110716793A (en) 2020-01-21
CN110716793B CN110716793B (en) 2023-09-15

Family

ID=69211367

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910959082.5A Active CN110716793B (en) 2019-10-10 2019-10-10 Method, device, equipment and storage medium for executing distributed transaction

Country Status (1)

Country Link
CN (1) CN110716793B (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112286909A (en) * 2020-10-29 2021-01-29 平安科技（深圳）有限公司 Execution state determination method, device, server and storage medium
CN112596867A (en) * 2021-03-03 2021-04-02 北京金山云网络技术有限公司 Suspension transaction processing method and distributed database system
CN112711466A (en) * 2021-03-25 2021-04-27 北京金山云网络技术有限公司 Hanging affair inspection method and device, electronic equipment and storage medium
CN113505110A (en) * 2021-07-08 2021-10-15 中国工商银行股份有限公司 Double-log-surface anti-duplication method and device during cross-day cutting
CN114328613A (en) * 2022-03-03 2022-04-12 阿里云计算有限公司 Method, device and system for processing distributed transactions in Structured Query Language (SQL) database

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150309889A1 (en) * 2014-04-24 2015-10-29 International Business Machines Corporation Recovery of a transaction after xa end
CN106156119A (en) * 2015-04-07 2016-11-23 阿里巴巴集团控股有限公司 A kind of distributed transaction communication means, system and device
CN106557514A (en) * 2015-09-29 2017-04-05 中兴通讯股份有限公司 A kind of distributed transaction rollback method and device

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150309889A1 (en) * 2014-04-24 2015-10-29 International Business Machines Corporation Recovery of a transaction after xa end
CN106156119A (en) * 2015-04-07 2016-11-23 阿里巴巴集团控股有限公司 A kind of distributed transaction communication means, system and device
CN106557514A (en) * 2015-09-29 2017-04-05 中兴通讯股份有限公司 A kind of distributed transaction rollback method and device

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112286909A (en) * 2020-10-29 2021-01-29 平安科技（深圳）有限公司 Execution state determination method, device, server and storage medium
CN112286909B (en) * 2020-10-29 2023-09-05 平安科技（深圳）有限公司 Execution state determining method, device, server and storage medium
CN112596867A (en) * 2021-03-03 2021-04-02 北京金山云网络技术有限公司 Suspension transaction processing method and distributed database system
CN112711466A (en) * 2021-03-25 2021-04-27 北京金山云网络技术有限公司 Hanging affair inspection method and device, electronic equipment and storage medium
CN112711466B (en) * 2021-03-25 2021-08-10 北京金山云网络技术有限公司 Hanging affair inspection method and device, electronic equipment and storage medium
WO2022199229A1 (en) * 2021-03-25 2022-09-29 北京金山云网络技术有限公司 Suspended transaction inspection method and apparatus, electronic device and storage medium
CN113505110A (en) * 2021-07-08 2021-10-15 中国工商银行股份有限公司 Double-log-surface anti-duplication method and device during cross-day cutting
CN113505110B (en) * 2021-07-08 2024-03-15 中国工商银行股份有限公司 Double-log-surface anti-duplicate method and device for cross-day cut period
CN114328613A (en) * 2022-03-03 2022-04-12 阿里云计算有限公司 Method, device and system for processing distributed transactions in Structured Query Language (SQL) database
CN114328613B (en) * 2022-03-03 2022-07-05 阿里云计算有限公司 Method, device and system for processing distributed transactions in Structured Query Language (SQL) database

Also Published As

Publication number Publication date
CN110716793B (en) 2023-09-15

Similar Documents

Publication Publication Date Title
CN110716793A (en) Execution method, device, equipment and storage medium of distributed transaction
US5923833A (en) Restart and recovery of OMG-compliant transaction systems
US11016956B2 (en) Database management system with database hibernation and bursting
JP4637842B2 (en) Fast application notification in clustered computing systems
US9798595B2 (en) Transparent user mode scheduling on traditional threading systems
CN111897638B (en) Distributed task scheduling method and system
US8365193B2 (en) Recoverable asynchronous message driven processing in a multi-node system
CN110046039A (en) Method for scheduling task and system, control centre's server and storage medium
CN111488255A (en) Multithreading concurrent monitoring method, device, equipment and storage medium
CN110413687B (en) Distributed transaction fault processing method and related equipment based on node interaction verification
CN107682460B (en) Distributed storage cluster data communication method and system
US9170837B2 (en) Transaction concurrent execution control system, method and program for carrying out a control of concurrently executing a transaction, including measuring execution time from starting to ending of transaction execution
CN115994053A (en) Parallel playback method and device of database backup machine, electronic equipment and medium
CN112346834A (en) Database request processing method and device, electronic equipment and medium
US8301750B2 (en) Apparatus, system, and method for facilitating communication between an enterprise information system and a client
CN113157411B (en) Celery-based reliable configurable task system and device
CN111541762A (en) Data processing method, management server, device and storage medium
CN115328664B (en) Message consumption method, device, equipment and medium
CN106407264A (en) High-availability and high-consistency database cluster system and command processing method thereof
CN115827265A (en) Transaction processing method, device, equipment and storage medium
US8615769B2 (en) Data processing system, data processing method, and data processing program
US8359602B2 (en) Method and system for task switching with inline execution
US11381642B2 (en) Distributed storage system suitable for sensor data
CN109857523B (en) Method and device for realizing high availability of database
WO2003003244A1 (en) Method of rapidly eliminating different information in databases

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right

Effective date of registration: 20230920

Address after: 100190 Beijing Haidian District Zhichun Road 49 No. 3 West 309

Patentee after: TENCENT CLOUD COMPUTING (BEIJING) Co.,Ltd.

Address before: 518000 Tencent Building, No. 1 High-tech Zone, Nanshan District, Shenzhen City, Guangdong Province, 35 Floors

Patentee before: TENCENT TECHNOLOGY (SHENZHEN) Co.,Ltd.

TR01 Transfer of patent right