Multi-database transaction processing method and related apparatus
By generating a global transaction ID and a distributed lock, combined with the transaction coordinator's exception fallback handling and rollback logging, the data consistency problem in multi-database transaction processing is solved, improving system availability and compatibility, and reducing development workload.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CTRIP COMP TECH SHANGHAI
- Filing Date
- 2026-05-07
- Publication Date
- 2026-06-05
AI Technical Summary
In multi-database transaction processing, existing solutions may lead to data inconsistency issues, and the development workload is large, lacking general reusability.
Generate a global transaction ID, acquire a distributed lock, handle exceptions through the transaction coordinator, record rollback logs, execute single-database transactions, and perform global rollback when necessary.
It resolves data consistency risks, reduces development workload, improves system availability and compatibility, and avoids concurrency and dirty read/write issues.
Smart Images
Figure CN122152939A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular to a multi-database transaction processing method and related apparatus. Background Technology
[0002] In the field of database transaction processing, single-service, single-database transaction operations can directly guarantee the ACID properties (Atomicity, Consistency, Isolation, and Durability) of transaction processing through single-machine transaction mechanisms. With the upgrading of enterprise database architecture and the emergence of business table data migration needs, transaction scenarios involving multiple databases in a single service have emerged.
[0003] To ensure the reliability of multi-database transaction processing, the current common approach is to manually implement reverse rollback at the business layer. For example, for the settlement and payment service, after migrating the transaction log from SQL Server to TiDB, the service needs to operate on SQL Server to store settlement data and on TiDB to store settlement transaction logs. This splits the original single-database transaction into a multi-database transaction across SQL Server and TiDB. Based on the existing solution, in the event of a settlement data saving failure, it is necessary to manually execute SQL to roll back the settlement transaction log data.
[0004] Because multi-database transactions involve multiple databases, rollback of existing solutions may result in data inconsistency due to rollback failure of one database. Furthermore, each rollback task requires customized development based on the business scenario, lacking general reusability and resulting in a large development workload. Summary of the Invention
[0005] In view of the above problems, this application provides a multi-database transaction processing method and related apparatus to solve the data inconsistency problem in a single-service multi-database transaction processing task.
[0006] The specific plan is as follows:
[0007] The first aspect of this application provides a multi-database transaction processing method, including:
[0008] Generate a global transaction ID for the pending transaction; the pending transaction is initiated by a single service and involves multiple databases;
[0009] Obtain the distributed lock corresponding to the global transaction ID from the distributed lock cluster;
[0010] A transaction start message carrying the global transaction ID is sent to the transaction coordinator so that the transaction coordinator can perform an exception fallback based on the global transaction ID if it does not receive the transaction finality message of the pending transaction within a timeout period and a preset condition is met. The preset condition includes that the distributed lock corresponding to the global transaction ID has not been released or that the distributed lock corresponding to the global transaction ID has been acquired by the transaction coordinator.
[0011] Execute each individual database transaction that constitutes the transaction to be processed, and record the execution process through a rollback log; the recorded rollback log includes the global transaction ID and data information, the data information being used to indicate the data status before and after the data operation corresponding to the individual database transaction is executed;
[0012] If each single-database transaction is executed successfully, the committed transaction final state is written to each database involved in the pending transaction; otherwise, a global rollback is performed based on the recorded rollback log, and the rolled-back transaction final state is written to each database involved in the pending transaction.
[0013] Release the distributed lock corresponding to the global transaction ID, and send a transaction finality message carrying the global transaction ID to the transaction coordinator.
[0014] In one possible implementation, the individual database transactions constituting the pending transaction are executed, and the execution process is recorded via a rollback log, including:
[0015] Execute non-final transactions and record the execution process of the non-final transactions through the rollback log;
[0016] After all non-final transactions have been executed, the data operations corresponding to the final transactions are performed on the database corresponding to the final transactions, and the transaction status corresponding to the final transactions is written to the database corresponding to the final transactions, so that the transaction coordinator can determine the global transaction direction when performing the exception fallback handling.
[0017] Wherein, the final state transaction is the last single-database transaction executed among the single-database transactions constituting the transaction to be processed, and the non-final state transaction is the single-database transaction other than the final state transaction among the single-database transactions constituting the transaction to be processed.
[0018] In one possible implementation, for each of the non-final transactions, the execution process of the current transaction includes:
[0019] Perform the data operations corresponding to the current transaction on the database corresponding to the current transaction;
[0020] After executing the data operation corresponding to the current transaction, query the post-operation status of the target data to be processed by the current transaction, and write the queried post-operation status to the rollback log of the database corresponding to the current transaction;
[0021] After completing the operation and writing the status, commit the current transaction;
[0022] If the data operation corresponding to the current transaction is a modification operation or a deletion operation, the execution process of the current transaction further includes:
[0023] Before performing the data operation corresponding to the current transaction, query the old data of the target data and write the queried old data to the rollback log of the database corresponding to the current transaction.
[0024] In one possible implementation, if the data operation corresponding to the current transaction is an insert operation, the recorded rollback log of the current transaction also includes the auto-incrementing ID of the database writeback corresponding to the current transaction.
[0025] In one possible implementation, if the data operation corresponding to the current transaction is an insert operation, the recorded rollback log of the current transaction also includes the auto-incrementing ID of the database writeback corresponding to the current transaction.
[0026] In one possible implementation, the fallback rollback duration of the transaction coordinator is less than the preset locking duration of the distributed lock cluster.
[0027] In one possible implementation, sending the transaction start message carrying the global transaction ID to the transaction coordinator includes:
[0028] Send a transaction start message carrying the global transaction ID to the transaction coordinator via message middleware;
[0029] Sending a transaction finality message carrying the global transaction ID to the transaction coordinator includes:
[0030] The message middleware sends a transaction finality message carrying the global transaction ID to the transaction coordinator.
[0031] A second aspect of this application provides a multi-database transaction processing device, comprising at least one processor and a memory connected to the processor, wherein:
[0032] The memory is used to store computer programs;
[0033] The processor is used to execute the computer program to implement the multi-database transaction processing method described in the first aspect above.
[0034] A third aspect of this application provides a storage medium carrying one or more computer programs, which, when executed by an electronic device, enable the electronic device to implement the multi-database transaction processing method described in the first aspect.
[0035] A fourth aspect of this application provides a computer program product including computer-readable instructions that, when executed on an electronic device, enable the electronic device to implement the multi-database transaction processing method described in the first aspect.
[0036] Using the above technical solution, when processing multi-database transactions, this application first generates a global transaction ID for the transaction to be processed, then obtains the distributed lock corresponding to the global transaction ID from the distributed lock cluster, and sends a transaction start message carrying the global transaction ID to the transaction coordinator. This allows the transaction coordinator to perform fallback processing based on the global transaction ID if it does not receive the transaction finality message of the transaction to be processed within a timeout period and meets preset conditions. Then, it executes each individual database transaction constituting the transaction to be processed and records the execution process through rollback logs. If each individual database transaction is executed successfully, the committed transaction finality is written to each database involved in the transaction to be processed. If any individual database transaction fails, a global rollback is performed based on the recorded rollback logs, and the rolled-back transaction finality is written to each database involved in the transaction to be processed. Finally, the distributed lock corresponding to the global transaction ID is released, and a transaction finality message carrying the global transaction ID is sent to the transaction coordinator.
[0037] This application avoids data concurrency and dirty read / write issues through a global distributed lock, enables data rollback traceability by recording rollback logs, and solves the problem of abnormal transaction interruption caused by factors such as server crashes through the TC exception fallback process, thereby resolving the data consistency risk problem caused by the existing manual rollback scheme. Attached Figure Description
[0038] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.
[0039] Figure 1 This is a flowchart illustrating a multi-database transaction processing method according to an embodiment of this application;
[0040] Figure 2 This is a schematic diagram of the structure of a multi-database transaction processing device according to an embodiment of this application. Detailed Implementation
[0041] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is only for explaining specific embodiments and is not intended to limit the application. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.
[0042] This application provides a multi-database transaction processing method and related apparatus, which can be applied to solve multi-database transaction processing tasks in a single service and meet the ACID characteristics of single-service multi-database transaction processing.
[0043] The multi-database transaction processing method provided in this application embodiment can be applied to a business system that includes or connects to at least two databases and is connected to a transaction coordinator (TC).
[0044] Optionally, the system can be integrated with a transaction manager JAR package, which executes the various steps of this scheme.
[0045] Figure 1 This is a flowchart illustrating a multi-database transaction processing method according to an embodiment of this application, combined with... Figure 1 As shown, the method may include the following steps:
[0046] Step S101: Generate a global transaction ID for the transaction to be processed, obtain the distributed lock corresponding to the global transaction ID from the distributed lock cluster, and send a transaction start message carrying the global transaction ID to the transaction coordinator.
[0047] The pending transaction is initiated by a single service and involves multiple databases, where "multiple" means at least two. The business system can respond to a business request from a single service that requires operation on multiple databases and begin executing step S101 and subsequent steps. Step S101 can also be referred to as the global transaction initialization step.
[0048] A global transaction ID is used to uniquely identify a task to be processed within the business system. Optionally, the global transaction ID used in this embodiment can be a UUID.
[0049] The transaction start message is used to indicate to the transaction coordinator TC that the pending transaction has started execution, so that the transaction coordinator can perform fallback processing based on the global transaction ID if it does not receive the transaction finality message of the pending transaction within a timeout period and meets the preset conditions.
[0050] The preset conditions include either the distributed lock corresponding to the global transaction ID not being released or the distributed lock corresponding to the global transaction ID being acquired by the transaction coordinator. It should be noted that the distributed lock can be pre-configured with an automatic timeout release mechanism to avoid situations where the distributed lock is unnecessarily occupied for an extended period due to business system failures. Based on this, to avoid concurrent conflicts and dirty operations during transaction execution, the TC is configured to perform fallback handling only when the pending transaction has not released its held distributed lock or when the distributed lock is held by the TC itself.
[0051] Optionally, a timestamp can be obtained along with the global transaction ID, serving as the start time of the pending transaction. Based on this, the transaction start message can include the global transaction ID and the start time, allowing the TC to begin fallback monitoring timing. In another possible implementation, the TC can also use the time of receiving the transaction start message as the start time of the pending transaction, thereby performing fallback monitoring timing accordingly.
[0052] In one possible implementation, the business system can connect to the TC via a message middleware. Based on this, sending the transaction start message carrying the global transaction ID to the transaction coordinator can include:
[0053] Send a transaction start message carrying the global transaction ID to the transaction coordinator via a message broker.
[0054] Step S102: Execute each single-database transaction that constitutes the transaction to be processed, and record the execution process through the rollback log.
[0055] This step can also be called the single-database transaction execution step with rollback log and undo_log.
[0056] The recorded rollback log may include the global transaction ID and data information, the data information being used to indicate the data status before and after the data operation corresponding to the single database transaction.
[0057] It should be noted that the transaction to be processed can be split into multiple single-database transactions according to the different data sources to be operated on. That is, the transaction to be processed consists of multiple single-database transactions, and different single-database transactions correspond to different databases.
[0058] For a single-database transaction with an undo_log, its execution process can include: performing the data operations corresponding to the transaction, recording the execution process of the operation in the undo_log, such as the state before execution, the operation information, the state after execution, etc., and finally committing the transaction so that the next transaction can begin. In other words, when executing a pending transaction, the individual single-database transactions that constitute the pending transaction can be executed sequentially in a preset order.
[0059] In one possible implementation, the rollback log for a single database transaction can be recorded in the undo_log of the database corresponding to that transaction. This ensures the atomicity of the log and the business data, providing a foundation for improving the execution efficiency of rollback operations.
[0060] Step S103: If all single-database transactions are executed successfully, write the committed transaction final state to each database involved in the pending transaction; otherwise, perform a global rollback based on the recorded rollback log and write the rolled-back transaction final state to each database involved in the pending transaction.
[0061] It should be noted that the system can autonomously determine the global execution result of the transaction to be processed and execute the corresponding process based on the global execution result, such as rollback or commit, without requiring normal transaction processing process decisions using TC parameters.
[0062] For example, performing a global rollback based on the recorded rollback logs may include: reading the recorded rollback logs from all databases involved in the transaction to be processed, and performing reverse update operations in reverse order. After completing the global rollback, the rolled-back transaction final state is then written to all databases involved in the transaction to be processed.
[0063] After the transaction final state is written, step S104 is executed.
[0064] Step S104: Release the distributed lock corresponding to the global transaction ID, and send a transaction finality message carrying the global transaction ID to the transaction coordinator.
[0065] Transaction completion messages can be used to indicate whether a transaction pending in the transaction coordinator (TC) has succeeded or failed. In one possible implementation, the business system can connect to the TC via a message middleware. Based on this, sending a transaction completion message carrying the global transaction ID to the transaction coordinator can include:
[0066] The message middleware sends a transaction finality message carrying the global transaction ID to the transaction coordinator.
[0067] The aforementioned steps S103 and S104 can be referred to as the global transaction termination processing steps.
[0068] Based on the above, the processing flow of pending transactions also includes an exception fallback step executed by TC, which may specifically include: performing exception fallback processing based on the global transaction ID when the transaction final state message of the pending transaction is not received within a timeout and the preset conditions are met.
[0069] The situation where the TC fails to receive the transaction finality message of the pending transaction within a time limit (which can be called the fallback rollback period) refers to the failure to receive the finality message within a preset time period (which can be called the fallback rollback period) starting from the time when the pending transaction was determined to start execution by the TC. This may correspond to scenarios such as service outage or processing timeout even if the service is not down. This application reduces the reliance on the TC by having the TC perform fallback processing only in this case, ensuring that TC failure will not affect the normal execution process of the transaction, thus providing a foundation for improving system availability.
[0070] TC can obtain the single-database transaction status of each database involved in the pending transaction based on the global transaction ID, and then complete the automatic commit or rollback operation of the unfinished transaction to realize the fallback handling of exceptions and improve the reliability of transaction processing in abnormal states.
[0071] This embodiment avoids data concurrency and dirty read / write issues by using a global distributed lock, enables data rollback traceability by recording rollback logs, and solves the problem of abnormal transaction interruption caused by factors such as server crashes through the TC exception fallback process, thereby resolving the data consistency risk problem caused by the existing manual rollback scheme.
[0072] Furthermore, this embodiment has a certain degree of general reusability, which can be adapted to all single-service multi-database business scenarios. It eliminates the need for business developers to manually write reverse process rollback logic, and also eliminates the need to customize inspection and rollback JOBs for different businesses, thus greatly reducing development workload and maintenance costs.
[0073] Furthermore, this embodiment achieves compatibility regardless of database type. Specifically, it abandons the strong restrictions imposed by open-source components on database syntax, and is compatible with various database syntaxes such as SQL Server stored procedures, supporting multiple database types including SQL Server, TiDB, and MySQL. On the other hand, this embodiment is also compatible with existing distributed lock clusters, requiring minimal modification to the existing architecture.
[0074] It should be noted that the time parameters involved in this application, such as the preset lock duration, the fallback rollback duration of TC, the global rollback duration of the business system, and the retention duration of rollback logs, can all be flexibly configured according to the business scenario to adapt to the business needs of single-service multi-database businesses with different complexities.
[0075] In one or more embodiments provided in this application, executing the individual database transactions constituting the pending transaction and recording the execution process through a rollback log may include:
[0076] The first step is to execute non-final transactions and record the execution process of the non-final transactions through the rollback log.
[0077] Among them, the final state transaction is the last single-database transaction executed among the single-database transactions that constitute the transaction to be processed, and the corresponding non-final state transaction is the single-database transaction other than the final state transaction among the single-database transactions that constitute the transaction to be processed.
[0078] The second step is to perform the data operations corresponding to the final state transactions on the database corresponding to the final state transactions after all non-final state transactions have been completed, and write the transaction status corresponding to the final state transactions to the database corresponding to the final state transactions, so that the transaction coordinator can determine the global transaction direction when performing the exception fallback handling.
[0079] By writing the transaction status of the final transaction to the corresponding database, TC can accurately determine the final direction of the global transaction, thereby solving the problem of difficulty in determining the transaction status caused by server crash during the execution of the last single-database transaction.
[0080] Based on the above, since the execution result of the final state transaction directly determines the final state of the global transaction, a global commit is performed on success and a global rollback is required on failure, the final state transaction can record only the success / failure status flags of the transaction without recording the undo_log, thus providing a basis for improving the efficiency of transaction execution.
[0081] Optionally, heavyweight database operations can be treated as final transactions to reduce the impact on performance.
[0082] In one or more embodiments provided in this application, for each of the various non-final transactions, the execution process of the current transaction may include:
[0083] Perform the data operations corresponding to the current transaction on the database corresponding to the current transaction;
[0084] After executing the data operation corresponding to the current transaction, query the post-operation status of the target data to be processed by the current transaction, and write the queried post-operation status to the rollback log of the database corresponding to the current transaction;
[0085] After completing the operation and writing the status, commit the current transaction;
[0086] Based on the above, if the data operation corresponding to the current transaction is a modification operation or a deletion operation, the execution process of the current transaction may further include:
[0087] Before performing the data operation corresponding to the current transaction, query the old data of the target data and write the queried old data to the rollback log of the database corresponding to the current transaction.
[0088] It should be noted that the data operations involved in this application can include insert, update, and delete operations. For each type of operation, the post-operation status of the target data must be queried using a select query or similar method after the operation is executed, and written to the corresponding undo_log for subsequent dirty write detection. For update and delete operations, the corresponding old data must also be obtained before the operation is executed and written to the corresponding undo_log for use during rollback. It should be noted that for insert operations, since there is no old data, the data operation can be started directly.
[0089] In one or more embodiments provided in this application, when the data operation corresponding to the current transaction is an add operation, the recorded rollback log of the current transaction also includes the auto-incrementing ID of the database writeback corresponding to the current transaction.
[0090] Based on the above, no additional undo_log query operation is required, providing a foundation for improving processing efficiency.
[0091] In one or more embodiments provided in this application, in the event of a single-library task that fails to execute, the method may further include:
[0092] If the global rollback process has been performed for longer than the preset global rollback duration, the global rollback process shall be stopped.
[0093] The global rollback duration is shorter than the fallback rollback duration of the transaction coordinator. This avoids the situation where the business system is still performing transaction operations while the TC is performing the fallback rollback, thus preventing data conflict risks.
[0094] The multi-database transaction processing apparatus provided in the embodiments of this application is described below. The multi-database transaction processing apparatus described below can be referred to in correspondence with the multi-database transaction processing method described above.
[0095] The device may include:
[0096] A transaction ID generation unit is used to generate a global transaction ID for a transaction to be processed; the transaction to be processed is initiated by a single service and involves multiple databases.
[0097] A distributed lock control unit is used to obtain the distributed lock corresponding to the global transaction ID from the distributed lock cluster.
[0098] The notification unit is used to send a transaction start message carrying the global transaction ID to the transaction coordinator, so that the transaction coordinator can perform an exception fallback process based on the global transaction ID when it does not receive the transaction finality message of the pending transaction after a timeout and a preset condition is met. The preset condition includes that the distributed lock corresponding to the global transaction ID has not been released or the distributed lock corresponding to the global transaction ID has been acquired by the transaction coordinator.
[0099] The transaction execution unit is used to execute each individual database transaction that constitutes the transaction to be processed, and to record the execution process through a rollback log. The recorded rollback log includes the global transaction ID and data information, wherein the data information is used to indicate the data status before and after the data operation corresponding to the individual database transaction. If each individual database transaction is executed successfully, the committed transaction final state is written to each database involved in the transaction to be processed; otherwise, a global rollback is performed based on the recorded rollback log, and the rolled-back transaction final state is written to each database involved in the transaction to be processed.
[0100] The distributed lock control unit is also used to release the distributed lock corresponding to the global transaction ID;
[0101] The notification unit is also used to send a transaction finality message carrying the global transaction ID to the transaction coordinator.
[0102] Optionally, a more detailed and extended description of the multi-database transaction processing device can be found in the description above.
[0103] This application also provides a multi-database transaction processing device in its embodiments. (See reference...) Figure 2 The diagram illustrates a structural schematic suitable for implementing a multi-database transaction processing device in the embodiments of this application. The device described in the embodiments of this application may include, but is not limited to, fixed terminals such as servers and computers. Figure 2 The multi-database transaction processing device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.
[0104] Combination Figure 2 As shown, the device may include a processing unit (e.g., a central processing unit) 1, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 2 or a program loaded from a storage device 8 into a random access memory (RAM) 3, to implement any of the multi-database transaction processing methods provided in the embodiments of this application. When the multi-database transaction processing device is powered on, the RAM 3 also stores various programs and data required for the operation of the multi-database transaction processing device. The processing unit 1, ROM 2, and RAM 3 are interconnected via a bus 4. An input / output (I / O) interface 5 is also connected to the bus 4.
[0105] Typically, the following devices can be connected to I / O interface 5: input devices 6 including, for example, touchscreens, touchpads, keyboards, mice, cameras, etc.; output devices 7 including, for example, liquid crystal displays (LCDs); storage devices 8 including, for example, memory cards, hard drives, etc.; and communication devices 9. Communication device 9 allows the multi-database transaction processing device to communicate wirelessly or wiredly with other devices to exchange data. While multi-database transaction processing devices with various devices are provided, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.
[0106] This application also provides a storage medium that carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any of the multi-database transaction processing methods provided in this application.
[0107] This application also provides a computer program product including computer-readable instructions, which, when executed on an electronic device, cause the electronic device to implement any of the multi-database transaction processing methods provided in this application.
[0108] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0109] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referred to each other.
[0110] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims
1. A method for multi-database transaction processing, the method comprising: The method includes: Generate a global transaction ID for the pending transaction; the pending transaction is initiated by a single service and involves multiple databases; Obtain the distributed lock corresponding to the global transaction ID from the distributed lock cluster; A transaction start message carrying the global transaction ID is sent to the transaction coordinator so that the transaction coordinator can perform an exception fallback based on the global transaction ID if it does not receive the transaction finality message of the pending transaction within a timeout period and a preset condition is met. The preset condition includes that the distributed lock corresponding to the global transaction ID has not been released or that the distributed lock corresponding to the global transaction ID has been acquired by the transaction coordinator. Execute each individual database transaction that constitutes the transaction to be processed, and record the execution process through a rollback log; the recorded rollback log includes the global transaction ID and data information, the data information being used to indicate the data status before and after the data operation corresponding to the individual database transaction is executed; If each single-database transaction is executed successfully, the committed transaction final state is written to each database involved in the pending transaction; otherwise, a global rollback is performed based on the recorded rollback log, and the rolled-back transaction final state is written to each database involved in the pending transaction. Release the distributed lock corresponding to the global transaction ID, and send a transaction finality message carrying the global transaction ID to the transaction coordinator.
2. The multi-database transaction processing method of claim 1, wherein, Execute the individual database transactions that constitute the pending transaction, and record the execution process through the rollback log, including: Execute non-final transactions and record the execution process of the non-final transactions through the rollback log; After all non-final transactions have been executed, the data operations corresponding to the final transactions are performed on the database corresponding to the final transactions, and the transaction status corresponding to the final transactions is written to the database corresponding to the final transactions, so that the transaction coordinator can determine the global transaction direction when performing the exception fallback handling. Wherein, the final state transaction is the last single-database transaction executed among the single-database transactions constituting the transaction to be processed, and the non-final state transaction is the single-database transaction other than the final state transaction among the single-database transactions constituting the transaction to be processed.
3. The multi-database transaction processing method of claim 2, wherein, For each of the non-final transactions, the execution process of the current transaction includes: Perform the data operations corresponding to the current transaction on the database corresponding to the current transaction; After executing the data operation corresponding to the current transaction, query the post-operation status of the target data to be processed by the current transaction, and write the queried post-operation status to the rollback log of the database corresponding to the current transaction; After completing the operation and writing the status, commit the current transaction; If the data operation corresponding to the current transaction is a modification operation or a deletion operation, the execution process of the current transaction further includes: Before performing the data operation corresponding to the current transaction, query the old data of the target data and write the queried old data to the rollback log of the database corresponding to the current transaction.
4. The multi-database transaction processing method of claim 3, wherein, If the data operation corresponding to the current transaction is an insert operation, the recorded rollback log of the current transaction also includes the auto-incrementing ID of the database writeback corresponding to the current transaction.
5. The multi-database transaction processing method according to any one of claims 1-4, characterized in that, In the case of a single-library task that fails to execute, the method also includes: If the global rollback process has been performed for a duration exceeding the preset global rollback duration, the global rollback process shall be stopped; the global rollback duration shall be less than the fallback rollback duration of the transaction coordinator.
6. The multi-database transaction processing method according to claim 5, characterized in that, The fallback rollback duration of the transaction coordinator is less than the preset locking duration of the distributed lock cluster.
7. The multi-database transaction processing method according to any one of claims 1-4, characterized in that, Sending the transaction start message carrying the global transaction ID to the transaction coordinator includes: Send a transaction start message carrying the global transaction ID to the transaction coordinator via message middleware; Sending a transaction finality message carrying the global transaction ID to the transaction coordinator includes: The message middleware sends a transaction finality message carrying the global transaction ID to the transaction coordinator.
8. A multi-database transaction processing device, characterized in that, It includes at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is used to execute the computer program to enable the multi-database transaction processing device to implement the multi-database transaction processing method as described in any one of claims 1 to 7.
9. A storage medium, characterized in that, The storage medium carries one or more computer programs that, when executed by an electronic device, enable the electronic device to implement the multi-database transaction processing method as described in any one of claims 1 to 7.
10. A computer program product, characterized in that, It includes computer-readable instructions that, when executed on an electronic device, enable the electronic device to implement the multi-database transaction processing method as described in any one of claims 1 to 7.