CN110716793B - Method, device, equipment and storage medium for executing distributed transaction - Google Patents
Method, device, equipment and storage medium for executing distributed transaction Download PDFInfo
- Publication number
- CN110716793B CN110716793B CN201910959082.5A CN201910959082A CN110716793B CN 110716793 B CN110716793 B CN 110716793B CN 201910959082 A CN201910959082 A CN 201910959082A CN 110716793 B CN110716793 B CN 110716793B
- 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.)
- Active
Links
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 preparation instruction for indicating to submit a target transaction to each first resource manager; if the confirmation information of each first resource manager is received, a preset instruction is sent to the second resource manager to instruct the second resource manager to submit the target transaction and record the transaction mark after the successful submission; after the second resource manager commits successfully, a commit instruction indicating to commit the target transaction is sent to the first resource manager; if error information returned by any one of the first resource managers is received, a rollback instruction indicating a rollback target transaction is sent to each resource manager; each first resource manager inquires whether a corresponding transaction mark exists when the first resource manager is in a state of preparing to submit a target transaction for a preset time period, and submits the target transaction if the corresponding transaction mark exists, or rolls back the target transaction if the corresponding transaction mark exists. The data consistency of each resource manager is effectively ensured.
Description
Technical Field
The present application relates to the 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 the distributed XA transaction by the database management system (DBMS, database Management System), a situation may occur that one or a plurality of resource managers processing the distributed XA transaction are abnormal when the distributed XA transaction is ready to be submitted or rolled back, and thus the data consistency of each resource manager executing the distributed XA transaction cannot be ensured.
Content of the 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 for 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 a resource manager cluster to instruct the corresponding first resource manager to enter a state of preparing to submit a target transaction; wherein the resource manager cluster is composed of a second resource manager and at least one first resource manager;
If the confirmation information returned by each first resource manager is received, a preset instruction is sent 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 second resource manager submits the target transaction successfully; after the second resource manager commits successfully, a commit instruction for indicating to commit the target transaction is sent to each first resource manager;
if error information returned by any one of the first resource managers is received, a rollback instruction for indicating to rollback the target transaction is sent to each resource manager in the resource manager cluster;
and each first resource manager inquires whether a transaction mark corresponding to the target transaction exists when the first resource manager is in a state of being ready for submitting the target transaction for a preset time period, if so, the target transaction is submitted, and otherwise, the target transaction is rolled back.
In still another aspect, the present application further provides an execution apparatus for a distributed transaction, including:
the first sending module is used for: sending a preparation instruction to each first resource manager in a resource manager cluster to instruct the corresponding first resource manager to enter a state of preparing to submit a target transaction; wherein 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 the confirmation information returned by each first resource manager is received, a preset instruction is sent 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 second resource manager submits the target transaction successfully; after the second resource manager commits successfully, a commit instruction for indicating to commit the target transaction is sent 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 for indicating to rollback the target transaction is sent to each resource manager in the resource manager cluster;
and each first resource manager inquires whether a transaction mark corresponding to the target transaction exists when the first resource manager is in a state of being ready for submitting the target transaction for a preset time period, if so, the target transaction is submitted, and otherwise, the target transaction is rolled back.
In yet another aspect, the present application further provides a device for executing a distributed transaction, 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 also provides a computer readable storage medium having stored thereon a computer program which, when executed by a processor, implements the steps of the method of executing a distributed transaction as described above.
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 instruct the second resource manager to submit the target transaction and record a transaction mark of the target transaction after the successful submission, and after the successful submission of the second resource manager, an instruction for indicating to submit the target transaction is sent to each first resource manager for realizing the data consistency of each resource manager; after any first resource manager returns error information, sending a rollback target transaction instruction to each resource manager in order to ensure the data consistency of 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 time period, if so, the target transaction is submitted, and otherwise, the target transaction is rolled back. Therefore, the application changes the two-stage submission of the second resource manager into one-stage submission by the preset instruction, specifically, the second resource manager is converted from the preparation instruction and the submission instruction which need to be executed respectively into the transaction submission and the mark record which need to be executed only by the preset instruction, 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 is in a state of ready for submission and lasts for a hanging transaction with preset time length, the target transaction can be submitted or rolled back only by inquiring whether the transaction mark is recorded or not, so that the target transaction which becomes the hanging transaction is submitted when the target transaction is submitted successfully by the second resource manager, and the target transaction which becomes the hanging transaction is rolled back when the target transaction cannot be submitted by the second resource manager, and the consistency of data in each resource manager is effectively ensured.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings that are required to be used in the embodiments or the description of the prior art will be briefly described below, and it is obvious that the drawings in the following description are only embodiments of the present application, and that other drawings can be obtained according to the provided drawings without inventive effort for a person skilled in the art.
FIG. 1 is a block diagram of a system to which a method for executing distributed transactions according to an embodiment of the present application is applicable;
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 flow chart of 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 flow chart of sending a preparation instruction and a commit instruction to each first resource and sending a preset instruction to a second resource manager in the execution method of a distributed transaction according to the embodiment of the present application;
FIG. 5 is a flowchart of a suspended transaction recovery function implemented by a first resource manager 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 a distributed transaction execution device 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 of a database management system and consists of a finite sequence of database operations. When a transaction is submitted to the database management system, the database management system needs to ensure that all operations in the transaction are completed successfully and the results are permanently stored in the database, and if some operations in the transaction are not completed successfully, all operations in the transaction need to be rolled back to a state before the transaction is executed; while the transaction has no effect on the execution of the database or other transactions, it can be considered that all transactions are running independently.
A distributed transaction is a transaction that runs in a distributed environment, for which each operational step of the transaction is serviced running on a different node (machine); the key to distributed transactions is that there must be a way to know all actions that the transaction is doing anywhere, and the decision to commit or rollback the transaction must produce a uniform result (either all commit or all rollback). Specifically, in a distributed system having a distributed environment, each node can learn that its operation is successful or failed, but cannot learn that the operation of other nodes is successful or failed; thus, when a transaction spans multiple nodes, in order to maintain the ACID (atomicity, consistency, isolation, durability, atomicity, consistency, isolation, durability) property of the transaction, a component is introduced as a coordinator to uniformly handle the operation results of all participant nodes and ultimately indicate whether the nodes are to actually commit the operation results, i.e., to implement a two-phase commit (2 PC). The algorithmic idea of two-phase commit (2 PC) can be summarized as: the participants inform the coordinator of the success or failure of the operation, and the coordinator decides whether each participant is about to submit the operation or stop the operation according to the feedback information of all the participants.
The XA protocol is an interface standard of a Resource Manager (RM) and a transaction Manager (TM, transaction Manager), and provides a standard interface for communication between the Resource Manager and the transaction Manager, and manages distributed transactions in a two-phase commit manner, where the distributed transactions may be referred to as distributed XA transactions (hereinafter referred to as distributed XA transactions). The transaction manager can convert the common transaction into a distributed XA transaction to interact with the resource manager; specifically, when the transaction manager receives the action of opening the transaction by the application (or the application layer), the transaction opened by the application is converted into the distributed XA transaction and issued to each resource manager, and each resource manager is controlled to start executing, ending executing, preparing for submitting and submitting/rolling back the received distributed XA transaction in a mode of sending corresponding instructions. In the actual execution process, software and hardware anomalies may occur in each stage of TM and RM interaction, and other steps can directly rollback corresponding distributed XA transactions when anomalies occur, but if anomalies occur in preparation for commit, rollback, such as node faults and the like, a resource manager in a state of preparation for commit needs to know how other resource managers process the distributed XA transactions, so as to determine whether the distributed XA transactions in the state of preparation for commit need to be committed or rolled back.
In the prior art, each step of transaction operation in the transaction manager is recorded with an operation log, so that when a fault occurs, the state (commit or rollback) of the current transaction can be judged through the operation log, but too many operation logs are recorded, the performance of the transaction manager is greatly lost (more than 80%), and if the machine of the transaction manager is necrotized, the judgment of the transaction state cannot be realized, so that the data consistency of each resource manager cannot be realized. The other is that the corresponding operation log is written into the resource manager after the resource manager prepares to commit and before commit through the asynchronous thread, so that the existence 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 the data consistency of each resource manager cannot be realized.
In view of the above-mentioned problems existing at present, the present application proposes a technical solution for executing distributed transactions, by which the data consistency of each resource manager can be ensured while the performance is ensured.
For easy understanding, a system architecture to which the technical solution of the present application is applied is described below. Referring to FIG. 1, a block diagram of a system architecture to which the method of executing distributed transactions of the present application is applicable is shown.
As shown in fig. 1, a composition architecture of a system to which the distributed transaction execution method of the present application is applicable may include TM terminals 10, RM terminals 20, and application terminals 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 are not specifically limited herein; in fig. 1, the TM terminal 10 and the RM terminal 20 are both computer devices, and the application terminal 30 is shown as an implementation of an intelligent terminal.
For TM terminal 10, in a possible case, TM terminal 10 may include TM, where the TM may perform data interaction with RM terminal 20 and application terminal 30 respectively, specifically, when receiving a transaction opening action of application terminal 30, TM may convert the transaction opening action of 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 implementation of the distributed transaction, and return a corresponding execution result to application terminal 30 after the implementation is completed.
In one possible scenario, TM terminal 10 may include a monitor program that may monitor the TM for its corresponding functionality; in the process of realizing transaction conversion and data interaction with other terminals, a monitoring program monitors operations 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 operations on the TM after knowing the prompt information.
In a possible case, the TM terminal 10 may further include a man-machine interaction interface, where the man-machine interaction interface may be used for displaying the prompt information to the outside, and may further allow an outside operator to input a corresponding instruction for the repair operation on the man-machine interaction interface, so as to implement TM repair under the control of the instruction.
For RM terminal 20, RM terminal 20 may comprise an RM for enabling execution of the distributed transaction, in particular, the RM may execute the received distributed transaction under the direction of instructions sent by the TM terminal after receiving the distributed transaction distributed by the TM terminal.
In one possible case, the RM terminal may include a thread pool, where the thread pool may include a plurality of threads for executing distributed transactions, so that after receiving a plurality of distributed transactions allocated by the TM terminal, the threads may be obtained from the thread pool, and further, the execution of the distributed transactions is implemented in parallel by using the plurality of threads, 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 start a transaction, thereby controlling the TM terminal to implement execution of the transaction.
In one possible case, the application terminal 30 may include an instruction response program, where the instruction response program may implement a corresponding operation after receiving a corresponding instruction inputted from the outside, where the corresponding instruction inputted from the outside may be an instruction to open or close an application included in the application terminal 30, or an instruction to install or uninstall an application included in the application terminal 30.
Referring to fig. 2, a flowchart of a method for executing a distributed transaction according to an embodiment of the present application is shown, where the 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 commit the target transaction (or the target transaction enters a state of preparing to commit); wherein the resource manager cluster is composed of a second resource manager and at least one first resource manager; each first resource manager inquires 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 period, and submits the target transaction if the transaction mark corresponding to the target transaction exists, otherwise rolls back the target transaction.
The execution main body of the execution method of the distributed transaction provided by the embodiment of the application can be a corresponding execution device, and the execution device can be arranged in a transaction manager, so that the execution main body of the execution method of the distributed transaction provided by the embodiment of the application can be the transaction manager; the following description will be made with the execution subject as a transaction manager when 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 distributed with the distributed transaction, the distributed transaction can be a distributed XA transaction or other distributed transactions needing to be executed by using the plurality of resource managers, and the distributed transaction is specifically explained in the embodiments of the application; the transaction manager in this embodiment may use TenDB Cluster (a distributed database solution maintained for game scenario development), while the resource manager may use TenDB (a MySQL branch version maintained for game scenario development); the XA instruction of MySQL to perform a distributed XA transaction may include (where xid represents the tag of the transaction):
XA START xid: opening a transaction, placing the transaction in an ACTIVE state, and placing the SQL statement executed thereafter in the transaction;
XA END xid: after executing a series of DMLs on the transaction in the ACTIVRE state, executing XA END xid 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 preparation xid: after SQL operation is completed in the transaction, preparing work for submitting the transaction is carried out through XA PREPARE xid, and the transaction is placed in a PREPARED state;
XA COMMIT xid: after all resource managers are in a PREPARE state, respectively executing XA COMMIT xid to finally submit the transaction and complete persistence;
XA ROLLBACK xid: when the XA PREPARE xid has an exception or actively gives up the transaction, the XA ROLLBACK xid is executed to roll back the transaction.
XA RECOVER-transactions that see the PREPARED state present in MySQL.
Correspondingly, assuming that two resource managers (respectively denoted as RM1 and RM 2) are mounted in the resource manager cluster, the process of converting the distributed XA transaction into the distributed XA transaction to the resource manager by the transaction manager may be as shown in fig. 3 (assuming that all operations performed and returned are correct information, there is no information transfer from the transaction manager to the application and no information transfer from the resource manager to the transaction manager in the flowchart), and 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 XA START xid to RM1 and RM2, respectively, to indicate to begin executing the target transaction; receiving operation instructions (insert intro t1 (c 1) values (1); update t2 set c2=3where c1=2; and distributing the corresponding operation instructions to RM1 and RM2 for execution (RM 1: insert intro xxx; RM2: update t2 xxx); the TM receives an instruction sent by an application and indicating submission (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 instruct RM1 and RM2 to COMMIT the target transaction.
In practical applications, an application-generic transaction 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 common transaction into a distributed XA transaction to interact with the resource manager, and as shown in FIG. 2, when the transaction manager receives the action of starting the transaction by the application, the XA transaction mark xid is set; upon receiving a DML request of an application, the transaction manager sends an XA START xid to each resource manager executing the distributed XA transaction, and executes the DML request in the corresponding resource manager; when the transaction manager receives a request of submitting the transaction of the application, XA END xid and XA PREPARE xid are sequentially executed on each resource manager; 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 both 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, which is different from each other in that the first resource manager and the second resource manager receive and execute the instructions issued by the transaction manager. After each resource manager in the resource manager cluster sequentially issues XA START xid and XA END xid, and no exception exists, that is, the transaction manager sends a preparation instruction (XA PREPARE xid) to each first resource manager at the END of the first phase of the two-phase commit (the transaction manager corresponds to a coordinator in the two-phase commit, and the first resource manager receiving the preparation instruction enters a state of preparing to commit a target transaction, wherein the target transaction can be any distributed XA transaction to be executed.
S102: if the confirmation information returned by each first resource manager is received, a preset instruction is sent to the second resource manager to instruct the second resource manager to submit the target transaction and record the transaction mark corresponding to the target transaction after the second resource manager submits the target transaction successfully; and after the second resource manager commits successfully, a commit instruction indicating a commit target transaction is sent to each first resource manager.
After the transaction manager sends a preparation instruction to each first resource manager, each first resource manager performs preparation and submission work under the triggering of the instruction, enters a state of preparing and submitting target transaction after the completion of the preparation and submission work, returns confirmation information to the transaction manager if the completion of the preparation and submission work is normal, and indicates that the target transaction can be submitted by the information returned by each first resource manager if the transaction manager receives the confirmation information returned by each first resource manager; at this time, a preset instruction (XA COMMIT xid ONE PHASE) is sent to the second resource manager, two-stage submission to be implemented by the second resource manager is retired into one-stage submission through the preset instruction, that is, a preparation instruction and a submission instruction which need to be issued to the second resource manager are converted into preset instructions, so that the second resource manager directly submits the distributed XA transaction after receiving the preset instruction, if the result of submitting the distributed XA transaction by the second resource manager is successful, a transaction mark corresponding to the target transaction is recorded, specifically, a transaction mark corresponding to the target transaction is recorded in the local storage by the second resource manager, and if the result of submitting the distributed XA transaction by the second resource manager is failed in submission, a transaction mark corresponding to the target transaction is not required to be recorded.
In addition, the second resource manager can return the successful information of the commit to the transaction manager after the successful commit of the target transaction, or the transaction manager can acquire the successful information of the target transaction of the second resource manager through other modes set according to actual needs, which are all within the protection scope of the application. After the transaction manager acquires that the second resource manager submits the target transaction successfully, a submitting instruction (XA COMMIT xid) is sent to each first resource manager, so that each first resource manager submits the target transaction after receiving the submitting instruction, and 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 that each target transaction returns acknowledgement information, the flow of sending the preparation 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 order of the instructions, that is, 1.1 to 1.4 is executed first and then 1.1 to 1.3 is executed.
S103: and if error information returned by any one of the first resource managers is received, a rollback instruction indicating a rollback target transaction is sent 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 preparation and submission work under the triggering of the instruction, enter a state of preparation and submission target transaction after the completion of the preparation and submission work, and return error information to the transaction manager if the preparation and submission work is abnormal; if the transaction manager receives error information returned by at least one first resource manager, the information returned by the first resource manager indicates that the target transaction needs to be rolled back, and in order to keep data consistency of all resource managers in the resource manager cluster, a ROLLBACK instruction (XA ROLLBACK) needs to be sent to all resource managers in the resource manager cluster, and after each resource manager receives the ROLLBACK instruction, the target transaction is rolled back to return to a state before each resource manager executes the target transaction.
For the fact that each first resource manager inquires whether a transaction mark corresponding to a target transaction exists when the first resource manager is in a state of preparing to submit target transactions for a preset duration, if yes, submitting the target transaction, otherwise, rolling back the target transaction, it is to be noted that each first resource manager has a hanging transaction recovery function, the hanging transaction is a transaction in a state of preparing to submit for a long time, in this embodiment, the transaction in the state of preparing to submit is set for the hanging transaction when the state of preparing to submit is in the preset duration and the preset duration is exceeded (the preset duration can be set according to actual needs, such as 30 seconds or 1 minute, etc.), generally, the situation is caused by node faults of TM or RM, including that the transaction manager does not successfully send a submit instruction or a rollback instruction to the resource manager, the resource manager does not successfully receive the submit instruction or the rollback instruction sent by the transaction manager, and the resource manager submits or rollback the transaction is unsuccessful, etc.; in this case, in order to ensure the data consistency of each resource manager for the same transaction, the suspended transaction needs to be processed correspondingly. Specifically, in this embodiment, each resource manager may query in real time or at regular time whether a transaction whose state is ready to be submitted lasts for a preset duration, or each resource manager may query in real time or at regular time whether itself is in a state ready to be submitted for a preset duration, and if so, it is necessary to process a transaction having the above characteristics, that is, a suspension transaction. After determining that the target transaction is the suspension transaction, inquiring whether a transaction mark corresponding to the target transaction is recorded, if so, indicating that the information returned by each first resource manager in response to the preparation instruction to the transaction manager is confirmation information, and that the second resource manager submits the target transaction successfully, so that the suspension transaction needs to be submitted in order to ensure the data consistency; if not, the description may be that the information returned by each first resource manager in response to the preparation instruction to the transaction manager has error information, or that the information returned by each first resource manager in response to the preparation instruction to the transaction manager is acknowledgement information, and that the second resource manager fails to submit the target transaction, or that other abnormal conditions are caused by the node failure of the TM or RM occur, so in order to ensure data consistency, rollback is required to be performed on the suspended transaction.
It should be noted that, in this embodiment, the suspended transaction recovery function provided by each first resource manager may be implemented by a background thread deployed on each first resource manager, and whether a suspended transaction exists in the resource manager to which the background thread belongs is detected, and if the existence is detected, whether the suspended transaction is submitted or rolled back is determined by querying whether a transaction tag corresponding to the suspended transaction is recorded. In addition, a flowchart of the first resource manager implementing the suspended transaction resume 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 instruct the second resource manager to submit the target transaction and record a transaction mark of the target transaction after the successful submission, and after the successful submission of the second resource manager, an instruction for indicating to submit the target transaction is sent to each first resource manager for realizing the data consistency of each resource manager; after any first resource manager returns error information, sending a rollback target transaction instruction to each resource manager in order to ensure the data consistency of 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 time period, if so, the target transaction is submitted, and otherwise, the target transaction is rolled back. Therefore, the application changes the two-stage submission of the second resource manager into one-stage submission by the preset instruction, specifically, the second resource manager is converted from the preparation instruction and the submission instruction which need to be executed respectively into the transaction submission and the mark record which need to be executed only by the preset instruction, 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 suspension transaction in a ready-to-commit state for a preset duration, the target transaction can be determined to be committed or rolled back only by inquiring whether a transaction mark is recorded, so that the target transaction which becomes the suspension transaction is committed when the target transaction is successfully committed by the second resource manager, and the target transaction which becomes the suspension transaction is rolled back when the target transaction is not committed by the second resource manager, and the consistency of data in each resource manager is effectively ensured; meanwhile, the application does not introduce asynchronous threads and does not need to record the operation log of each transaction operation, thereby ensuring the execution performance of distributed transactions and avoiding the situation that the data consistency of each resource manager cannot be realized due to the machine necrosis of the transaction manager or the execution failure of external threads.
In a specific implementation manner, a flowchart of a method for executing a distributed transaction according to an embodiment of the present application may be shown in fig. 6, and may specifically 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 other resource managers except the second resource manager in the resource manager cluster are all 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, which are all within the protection scope of the present application.
S105: corresponding numbers are set 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 sequentially sending preparation instructions to each first resource manager in the resource manager cluster 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 is randomly selected from the resource manager cluster to be used as the second resource manager, and the other resource managers are the first resource manager; in this case, the determination of the first resource manager and the second resource manager can be implemented by the above manner for each distributed XA transaction to be executed, and then the partitions of the resource managers corresponding to different distributed XA transactions may be different, so that the partition of the resource managers is more flexible. Because the determination of the first resource manager and the second resource manager is random, when the first resource manager needs to query the transaction mark, the resource manager where the transaction mark is located cannot be determined, so that the first resource manager can realize the query of the transaction mark in each transaction manager in turn, and further determine whether the corresponding transaction mark is recorded.
On the basis, corresponding numbers can be set for each first resource manager, and the corresponding numbers can be specifically set according to actual needs, for example, each first resource manager is set as RM1 to RMn (n is the number of resource managers) respectively; when the preparation instructions are sent to the first resource managers, the preparation instructions can be sequentially sent to the first resource managers from large to small or from small to large according to the numbers set for the first resource managers, so that missing sending or repeated sending when the preparation instructions are sent can be avoided; and because the number of the second resource manager is only one, after corresponding numbers are set for each first resource manager, the second resource manager without the number can be determined, and then a corresponding instruction is sent to the second resource manager; of course, a number different from the first resource manager can also be set for the second resource manager, and the number is further directly utilized to locate the second resource manager to realize the transmission of the corresponding instruction; are within the scope of the present application. In addition, other instructions to be sent to the first resource manager can be sent according to the sequence of the numbers, such as a start instruction, an end instruction, a commit instruction, a rollback instruction and the like, are realized to the first resource manager, so that missing sending or repeated sending of the instructions is further avoided.
In another specific implementation manner, a flowchart of a method for executing a distributed transaction according to an embodiment of the present application may be shown in fig. 7, and may specifically include:
s106: calling preset number record information; the number recording information comprises numbers 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 sequentially sending preparation instructions to each preset first resource manager in the resource manager cluster 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 hanging the transaction. In addition, a corresponding number can be preset for each resource manager, and number record information representing 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 be convenient for management and inquiry; correspondingly, when the preparation instructions are sent to each first resource manager, the preparation instructions can be sequentially sent to each first resource manager from large to small or from small to large according to the sequence of the numbers of all the first resource managers in the number recording information, so that omission or repetition of the first resource manager when the preparation instructions are sent can be avoided; in addition, other instructions to be sent to the first resource manager can be sent according to the sequence of the numbers, such as a start instruction, an end instruction, a commit instruction, a rollback instruction and the like, are realized to the first resource manager, so that missing sending or repeated sending of the instructions is further avoided.
In still another specific implementation manner, a flowchart of a method for executing a distributed transaction according to an embodiment of the present application may be shown in fig. 8, and may specifically include:
s201: before the second resource manager records the transaction mark corresponding to the target transaction, the second resource manager invokes a locally preset commit log table.
Since 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 submits the target transaction and records the transaction mark of the target transaction after the target transaction is submitted successfully, which may be specifically recorded in the commit log (xa_commit_log) of the commit log table. Therefore, through the setting of the submitted log list, not only is the storage of the submitted log convenient, but also the management and the inquiry of the submitted log are convenient to realize.
S202: and after the second resource manager submits the target transaction successfully, the second resource manager records the transaction mark corresponding to the target transaction into a submission log table.
S203: after the second resource manager submits the target transaction successfully, the second resource manager recognizes the current time as the submitting time of the target transaction, and records the submitting time to a position corresponding to the transaction mark of the target transaction in the submitting log table.
In this embodiment, when the transaction mark is recorded, the time of successful submitting the target transaction may be recorded at the same time, specifically, after the second resource manager submits the target transaction successfully, the time at the current time is recorded as the time of submitting the target transaction, so that the transaction mark and the time of submitting the target transaction are recorded in the submitting log table, so that when the corresponding information is required to be queried, the successfully submitted transaction and the time of successfully submitting the transaction can be obtained only by calling the submitting log table. 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 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 efficiency of information recording is improved; of course, other settings may be performed according to actual needs, which are all within the scope of the present application, and in a specific example, the log marks and the corresponding commit logs may be recorded respectively as follows:
in still another specific implementation manner, the method for executing a distributed transaction provided by the embodiment of the present application may further include:
After receiving a preparation instruction, the first resource manager records the time at 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 first resource manager judging whether the state of the first resource manager in preparing to submit the target transaction lasts for a preset time length or not may include:
the first resource manager judges whether the time period from the recorded starting time to the current moment reaches the preset duration in real time.
In order to ensure that the suspended transaction can be automatically recovered when an abnormality occurs, the application defines that a certain transaction is in a state of ready for commit for a preset period of time and is the suspended transaction which needs to be automatically recovered (the state of entering a target transaction of ready for commit is the state of entering the target transaction of ready for commit); in order to determine whether the target transaction is a suspension 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 may be recorded as the start time of the state of preparing and submitting the target transaction to be stored locally, and further, whether the state of preparing and submitting the target transaction lasts for the preset duration may be determined only by judging in real time whether the time elapsed from the recorded start time to the current time reaches the preset duration. In another case, in order to reduce the resource waste, it may also be that it is determined at regular time whether or not the time elapsed from the recorded start time to the current time reaches the preset time length. In a specific example, increasing the start time of a task in a first resource manager may be as follows:
In still another specific implementation manner, the method for executing a distributed transaction provided by 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 being ready to commit the target transaction for a preset period of time, returning to the step of executing the commit or rollback target transaction until the commit or rollback target transaction is successful.
It should be noted that, when the target transaction is in a state of being ready for commit exceeds a preset duration, the target transaction also belongs to a suspension transaction, so in order to further ensure consistency of data in each resource manager, in this embodiment, when the first resource manager is in a state of being ready for commit for a preset duration, whether the target transaction is committed or rolled back, if the result is failure, the step of directly returning to execute or executing the committed or rolled back target transaction is performed or after a certain time interval set in advance according to actual needs, that is, if the committed target transaction fails, the step of returning to execute is performed as the committed target transaction, and if the rolled back target transaction fails, the step of returning to execute is performed as the rolled back target transaction; until the commit or rollback target transaction is successful.
In addition, three return results, namely SUCCESS, FAILURE and TIMEOUT, are respectively returned to the application when the defined transaction is executed on the transaction manager; wherein, success indicates that the transaction execution process is normal, and finally the relevant resource manager executes the commit instruction; failure indicates that expected errors occur in the transaction execution process, and finally the relevant resource managers execute rollback instructions; a timeout indicates an unexpected exception (e.g., a software or hardware failure) in the execution of the transaction, where the transaction may be in a non-consistent state, requiring a period of time for application before querying whether the transaction was successful or failed. In this way, the application is thus enabled to learn directly about the execution of the transaction.
For easy understanding, please refer to fig. 9, an application scenario of the present solution is described below, in which the transaction manager is TenDB Cluster, the resource manager is TenDB, and the application is a game application, as an application scenario, to describe the execution process of the distributed XA transaction. Wherein, it is assumed that RM1 represents a first resource manager, RM2 represents a second resource manager, and the number of the first resource managers is not limited; and assuming that the target transaction is normal before entering 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, transaction mark xid), and distributes the target transaction into RM1 and RM2 for execution; respectively sending XA START xid to each TenDB to indicate to START executing the target transaction; receiving operation instructions (insert intro t1 (c 1) values (1); update t2 set c2=3where c1=2; and distributing the corresponding instructions to each TenDB for execution (RM 1: insert intro xxx; RM2: update t2 xxx); the TenDB Cluster receives instructions sent by the game application and indicating submission, sends XA END xid to each TenDB, and sends XA PREPARE xid to RM 1; if RM1 returns acknowledgement information, then send XA COMMIT xid ONE PHASE to RM2 to instruct RM2 to record the corresponding transaction tag into the local log commit table if the commit target transaction is successful; after RM2 is submitted successfully, XA COMMIT xid is sent to RM 1; if RM1 returns error information, XA ROLLBACK xid is sent to each TenDB. In addition, RM1 will query RM2 if there is a transaction tag for the target transaction when it is in a state ready for commit for 30 seconds, commit the target transaction if queried, and rollback the target transaction otherwise.
After the first resource managers return confirmation information based on the preparation instructions, the second resource manager executes XA COMMIT xid ONE PHASE WITH LOG, and the atomic access operation ensures that corresponding transaction marks can be recorded in the second resource manager when the transaction is submitted successfully, and the transaction is not recorded when the transaction is submitted successfully. The background thread deployed in the first resource manager queries the suspended transaction with the current ready-to-commit state lasting for a preset time period and queries the transaction mark corresponding to the suspended transaction, so that the suspended transaction is automatically arbitrated to be committed or rolled back, the XA distribution flow is optimized, the suspended distributed XA transaction is efficiently recovered, and the final consistency requirement of RM data in an abnormal scene is ensured.
The embodiment of the application also provides a device for executing the distributed transaction, as shown in fig. 10, which may include:
a first transmitting module 111, configured to: 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; wherein the resource manager cluster is composed of a second resource manager and at least one first resource manager;
A second transmitting module 112, configured to: if the confirmation information returned by each first resource manager is received, a preset instruction is sent to the second resource manager to instruct the second resource manager to submit the target transaction and record the transaction mark corresponding to the target transaction after the second resource manager submits the target transaction successfully; after the second resource manager submits successfully, a submitting instruction indicating a submitting target transaction is sent to each first resource manager;
a third sending module 113, configured to: if error information returned by any one of the first resource managers 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 inquires 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 period, and submits the target transaction if the transaction mark exists, otherwise rolls back the target transaction.
In one possible implementation manner, the method may further include:
a setting module, configured 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 contained in the resource manager cluster as a second resource manager, and determining that all other resource managers except the second resource manager in the resource manager cluster are the first resource managers; setting corresponding numbers for each first resource manager;
Correspondingly, the first sending module may include:
a first transmitting unit configured to: and sequentially sending preparation instructions to each first resource manager in the resource manager cluster according to the sequence of the set numbers.
In another possible implementation manner, the method may further include:
the calling module is used for: before sending a preparation instruction to each first resource manager in the resource manager cluster, invoking preset number record information; the number recording information comprises numbers preset for each resource manager in the resource manager cluster;
correspondingly, the first sending module may include:
a second transmitting unit configured to: and sequentially sending preparation instructions to each preset first resource manager in the resource manager cluster according to the sequence of the numbers recorded in the number recording information.
Further, an embodiment of the present application further provides a device for executing a distributed transaction, which may include:
a memory for storing a computer program;
a processor, configured to implement the steps of the method for executing a distributed transaction disclosed in any of the foregoing embodiments when executing a computer program.
Specifically, the execution device may be the terminal 40 as shown in fig. 11, and fig. 11 is a block diagram of the execution device according to an exemplary embodiment, and the contents of the drawing should not be construed as any limitation on 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 application, and the terminal 40 may specifically include, but is not limited to, a smart phone, a tablet computer, a notebook computer, a desktop computer, or the like.
Generally, 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, etc., among others. The processor 41 may be implemented in at least one hardware form of DSP (Digital Signal Processing ), FPGA (Field-Programmable Gate Array, field programmable gate array), PLA (Programmable Logic Array ). The processor 41 may also comprise a main processor, which is a processor for processing data in an awake state, also called CPU (Central Processing Unit ); a coprocessor is a low-power processor for processing data in a standby state. In some embodiments, the processor 41 may integrate a GPU (Graphics Processing Unit, image processor) for rendering and drawing of content required to be displayed by the display screen. In some embodiments, the processor 41 may also include an AI (Artificial Intelligence ) processor for processing computing 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, where the computer program, when executed by the processor 41, can implement relevant steps in the method for executing a distributed transaction disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 42 may further include an operating system 422 and data 423, where the storage may be transient storage or permanent storage. Operating system 422 may include, among other things, 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 further include a display 43, an input-output interface 44, a communication interface 45, a sensor 46, a power supply 47, and a communication bus 48.
Those skilled in the art will appreciate that the structure shown in fig. 11 is not limiting of the terminal 40 and may include more or fewer components than shown.
Further, the embodiment of the application also discloses a computer readable storage medium, and a computer program is stored on the computer readable storage medium, and when the computer program is executed by a processor, the steps of the method for executing the distributed transaction disclosed in any of the previous embodiments are realized.
It should be noted that the foregoing is only a preferred embodiment of the present application, and is not intended to limit the present application, but any modification, equivalent replacement, improvement, etc. which fall within the spirit and principles of the present application should be included in the scope of the present application.
In this specification, each embodiment is described in a progressive manner, and each embodiment is mainly described in a different point from other embodiments, so that the same or similar parts between the embodiments are referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant points refer to the description of the method section.
The foregoing describes in detail the method, apparatus, device and storage medium for executing distributed transactions, and specific examples are applied to illustrate the principles and embodiments of the present application, and the above examples are only used to help understand the method and core idea of the present application; meanwhile, as those skilled in the art will vary in the specific embodiments and application scope according to the idea of the present application, the present disclosure should not be construed as limiting the present application in summary.
Claims (10)
1. A method for executing a distributed transaction, comprising:
sending a preparation instruction to each first resource manager in a resource manager cluster to instruct the corresponding first resource manager to enter a state of preparing to submit a target transaction; wherein the resource manager cluster is composed of a second resource manager and at least one first resource manager;
if the confirmation information returned by each first resource manager is received, a preset instruction is sent 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 second resource manager submits the target transaction successfully; after the second resource manager commits successfully, a commit instruction for indicating to commit the target transaction is sent to each first resource manager;
if error information returned by any one of the first resource managers is received, a rollback instruction for indicating to rollback the target transaction is sent to each resource manager in the resource manager cluster;
and each first resource manager inquires whether a transaction mark corresponding to the target transaction exists when the first resource manager is in a state of being ready for submitting the target transaction for a preset time period, if so, the target transaction is submitted, and otherwise, the target transaction is rolled back.
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 the resource managers contained in the resource manager cluster as a second resource manager, and determining that other resource managers except the second resource manager in the resource manager cluster are all first resource managers;
setting corresponding numbers for the first resource managers;
the sending a preparation instruction to each first resource manager in the resource manager cluster includes:
and sequentially sending preparation instructions to each first resource manager in the resource manager cluster 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 record information; the number recording information comprises numbers preset for each resource manager in the resource manager cluster;
the sending a preparation instruction to each first resource manager in the resource manager cluster includes:
And sequentially sending preparation instructions to each preset first resource manager in the resource manager cluster according to the sequence of the numbers recorded in the number recording information.
4. A method according to claim 2 or 3, wherein before the second resource manager records the transaction tag corresponding to the target transaction, further comprising:
the second resource manager invokes a locally preset commit 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 commit log table.
5. The method as recited in claim 4, further comprising:
after the second resource manager successfully submits the target transaction, identifying the time at the current moment as the submitting time of the target transaction;
the second resource manager records the commit time to a location in the commit log table corresponding to a transaction tag of the target transaction.
6. The method as recited in claim 5, further comprising:
after receiving the preparation instruction, the first resource manager records the time at the current moment as the corresponding starting time of the first resource manager entering the state of preparing to submit the target transaction;
The first resource manager determining whether the state of the first resource manager in preparation for submitting the target transaction lasts for a preset time period, including:
and the first resource manager judges whether the time period from the recorded starting time to the current moment reaches the preset duration in real time.
7. The method as recited in claim 6, further comprising:
and if the first resource manager fails to commit or rollback the target transaction when the first resource manager is in a state of being ready to commit the target transaction for a preset period of time, returning to execute the step of commit or rollback the target transaction until the target transaction is successfully committed or rolled back.
8. An apparatus for executing a distributed transaction, comprising:
the first sending module is used for: sending a preparation instruction to each first resource manager in a resource manager cluster to instruct the corresponding first resource manager to enter a state of preparing to submit a target transaction; wherein 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 the confirmation information returned by each first resource manager is received, a preset instruction is sent 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 second resource manager submits the target transaction successfully; after the second resource manager commits successfully, a commit instruction for indicating to commit the target transaction is sent 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 for indicating to rollback the target transaction is sent to each resource manager in the resource manager cluster;
and each first resource manager inquires whether a transaction mark corresponding to the target transaction exists when the first resource manager is in a state of being ready for submitting the target transaction for a preset time period, if so, the target transaction is submitted, and otherwise, the target transaction is rolled back.
9. An execution device for a distributed transaction, comprising:
a memory for storing a computer program;
a processor for implementing the steps of the method of executing a distributed transaction as claimed in any one of claims 1 to 7 when executing said computer program.
10. A computer readable storage medium, characterized in that it has stored thereon a computer program which, when executed by a processor, implements the steps of the method of executing a distributed transaction according to any of claims 1 to 7.
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 CN110716793A (en) | 2020-01-21 |
| CN110716793B true 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) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| 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 |
| CN112711466B (en) * | 2021-03-25 | 2021-08-10 | 北京金山云网络技术有限公司 | Hanging affair inspection method and device, electronic equipment and storage medium |
| CN113505110B (en) * | 2021-07-08 | 2024-03-15 | 中国工商银行股份有限公司 | Double-log-surface anti-duplicate method and device for cross-day cut period |
| CN114328613B (en) * | 2022-03-03 | 2022-07-05 | 阿里云计算有限公司 | Method, device and system for processing distributed transactions in Structured Query Language (SQL) database |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| 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 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9361190B2 (en) * | 2014-04-24 | 2016-06-07 | International Business Machines Corporation | Recovery of a transaction after XA end |
-
2019
- 2019-10-10 CN CN201910959082.5A patent/CN110716793B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| 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 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110716793A (en) | 2020-01-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110716793B (en) | Method, device, equipment and storage medium for executing distributed transaction | |
| EP2932370B1 (en) | System and method for performing a transaction in a massively parallel processing database | |
| US11016956B2 (en) | Database management system with database hibernation and bursting | |
| EP2816467B1 (en) | Method and device for checkpoint and restart of container state | |
| US7900085B2 (en) | Backup coordinator for distributed transactions | |
| CN110046039A (en) | Method for scheduling task and system, control centre's server and storage medium | |
| CN103581225A (en) | Distributed system node processing task method | |
| CN103559245A (en) | Distributed transaction committing failure handling method, device and system | |
| CN111488255A (en) | Multithreading concurrent monitoring method, device, equipment and storage medium | |
| CN107682460B (en) | Distributed storage cluster data communication method and system | |
| US9298765B2 (en) | Apparatus and method for handling partially inconsistent states among members of a cluster in an erratic storage network | |
| US8301750B2 (en) | Apparatus, system, and method for facilitating communication between an enterprise information system and a client | |
| CN105373563B (en) | Database switching method and device | |
| CN110740145A (en) | Message consumption method, device, storage medium and electronic equipment | |
| CN113658351B (en) | Method and device for producing product, electronic equipment and storage medium | |
| CN113157411B (en) | Celery-based reliable configurable task system and device | |
| CN115328664B (en) | Message consumption method, device, equipment and medium | |
| CN106407264A (en) | High-availability and high-consistency database cluster system and command processing method thereof | |
| US8819481B2 (en) | Managing storage providers in a clustered appliance environment | |
| CN115185787A (en) | Method and device for processing transaction log | |
| US8359602B2 (en) | Method and system for task switching with inline execution | |
| CN110661869B (en) | Node online method, system, device, equipment and computer storage medium | |
| US11381642B2 (en) | Distributed storage system suitable for sensor data | |
| CN114095343A (en) | Disaster recovery method, device, equipment and storage medium based on double-active system | |
| CN109034768B (en) | Financial reconciliation method, apparatus, computer device and storage medium |
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 | ||
| 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. |