Distributed transaction processing system and method
Through the coordinated work of transaction coordinator, transaction manager and resource manager in distributed transaction processing system, generate rollback logs and release resource locks, solving the performance bottlenecks and complexity of traditional XA transaction protocols in large distributed systems. Problems, improve concurrency performance and reduce complexity, ensuring consistency of distributed transactions.
Patent Information
- Application Number
- CN202411056169.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-08-02
- Publication Date
- 2024-12-06
AI Technical Summary
The performance bottlenecks and complexity of traditional XA transaction protocols when handling a large number of concurrent transactions limit their application in large distributed systems and are difficult to meet performance and stability requirements.
A distributed transaction processing system is designed, including a transaction coordinator, a transaction manager and a resource manager. Through the registration and coordination of global transaction identifiers and branch transaction identifiers, a rollback log is generated and resource locks are released after the first stage of submission. , asynchronously delete rollback logs to achieve improved concurrency performance and reduced complexity.
It improves the concurrency performance of distributed transaction processing systems, reduces complexity, ensures the consistency of distributed transactions, and solves the blocking and performance overhead problems in the traditional two-stage commit protocol.
Smart Images

Figure CN119088510A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of data processing, and in particular to a distributed transaction processing system and method. Background Art
[0002] With the rapid development of Internet technology, distributed systems have become the preferred architecture for large-scale data processing and services. However, transaction processing in distributed systems has always been one of the technical challenges. In distributed systems, transaction processing is a complex and critical issue. Although the traditional XA transaction protocol can provide strong consistency guarantees, its performance bottleneck and complexity limit its application in large distributed systems when processing a large number of concurrent transactions. Therefore, there is an urgent need for a distributed transaction processing solution that can combine the advantages of XA transactions while improving concurrency performance and reducing complexity. Summary of the invention
[0003] In view of at least one of the above technical problems, an embodiment of the present invention provides a distributed transaction processing system and method.
[0004] In a first aspect, a distributed transaction processing system provided by an embodiment of the present invention includes a transaction coordinator, a transaction manager, and multiple resource managers; wherein:
[0005] The transaction manager is used to: register a global transaction with the transaction coordinator when there is a business processing requirement;
[0006] The transaction coordinator is used to: create a global transaction identifier for the global transaction; and create a corresponding branch transaction identifier for each branch transaction under the global transaction identifier;
[0007] The resource manager is used to: register the branch transaction under the global transaction with the transaction coordinator according to the business processing demand; obtain the business processing statement in the branch transaction corresponding to the business processing demand of the resource manager, execute the business processing statement, obtain the updated business data, generate a rollback log according to the updated business data and the business data before the update, submit the updated business data and the rollback log to the database to complete the commit operation of the resource manager in the first stage, and release the resources used for the commit operation;
[0008] The transaction coordinator is also used to: determine whether the commit operations of each branch transaction corresponding to each branch transaction identifier under the global transaction identifier are all successful in the first phase; if they are all successful, notify the transaction manager so that the transaction manager initiates a global commit confirmation request in the second phase; after receiving the global commit confirmation request, asynchronously notify each resource manager corresponding to each branch transaction corresponding to each branch transaction identifier under the global transaction identifier to delete the rollback log.
[0009] In one embodiment, each resource manager executes the business processing statement to obtain updated business data, and generates a rollback log based on the updated business data and the pre-update business data, including: searching for the pre-update business data corresponding to the business processing statement according to the business processing statement, saving the pre-update business data as a pre-update image, executing the business processing statement to obtain updated business data, saving the updated business data as an updated image, and saving the pre-update image and the post-update image as a rollback log.
[0010] In one embodiment, each resource manager is also used to: generate a row lock when obtaining the rollback journal, lock the rollback journal through the row lock, and submit the row lock together with the updated business data and the rollback journal to the database; wherein, the rollback journal cannot be rolled back through the rollback journal in a locked state.
[0011] In one embodiment, the updated business data is stored in a business table in the database, the rollback log is stored in a log table in the database, and the row lock is stored in a lock table in the database.
[0012] In one embodiment, the transaction coordinator is also used to: when asynchronously notifying each resource manager corresponding to each branch transaction corresponding to each branch transaction identifier under the global transaction identifier to delete the rollback log, notify each resource manager corresponding to each branch transaction corresponding to each branch transaction identifier under the global transaction identifier to delete the row lock.
[0013] In one embodiment, the transaction coordinator is also used to: if the commit operation of at least one branch transaction in the first phase is unsuccessful, notify the transaction manager so that the transaction manager initiates a global rollback request in the second phase; after receiving the global rollback request, notify each resource manager corresponding to each branch transaction corresponding to each branch transaction identifier under the global transaction identifier, so that each resource manager opens its own rollback log through its own row lock, generates a reverse business processing statement based on its own rollback log, executes the reverse business processing statement to obtain the business data before the update, and deletes its own rollback log and its own row lock.
[0014] In one embodiment, the resource manager is also used to: before generating a reverse business processing statement based on its own rollback log, determine whether the current business data in the database is consistent with the updated image in the rollback log; if they are consistent, generate a reverse business processing statement based on its own rollback log; otherwise, notify manual data rollback operation.
[0015] In one embodiment, the resource manager is further used to: after performing a rollback operation, delete the corresponding updated business data, the rollback log and the row lock in the database.
[0016] In one embodiment, the business processing requirement requires multiple microservices to implement, and each microservice corresponds to a resource manager; when the business processing requirement calls each microservice during the implementation process, the resource manager corresponding to the microservice will register a branch transaction with the transaction coordinator.
[0017] According to a second aspect, a distributed transaction processing method provided by an embodiment of the present invention is implemented based on the distributed transaction processing system provided by the first aspect, and the method includes:
[0018] S110, registering a global transaction with the transaction coordinator through the transaction manager when there is a business processing demand; creating a global transaction identifier for the global transaction through the transaction coordinator;
[0019] S120, registering the branch transaction under the global transaction with the transaction coordinator according to the business processing requirements through the resource manager; creating a corresponding branch transaction identifier for each branch transaction under the global transaction identifier through the transaction coordinator;
[0020] S130, obtaining, through the resource manager, a business processing statement of the business processing requirement in the branch transaction corresponding to the resource manager, executing the business processing statement to obtain updated business data, generating a rollback log according to the updated business data and the business data before the update, submitting the updated business data and the rollback log to the database to complete the commit operation of the resource manager in the first phase, and releasing the resources used for the commit operation;
[0021] S140. The transaction coordinator determines whether the commit operations of the branch transactions corresponding to the branch transaction identifiers under the global transaction identifier are all successful in the first phase; if they are all successful, the transaction manager is notified so that the transaction manager initiates a global commit confirmation request in the second phase; after receiving the global commit confirmation request, the resource managers corresponding to the branch transactions corresponding to the branch transaction identifiers under the global transaction identifier are asynchronously notified to delete the rollback log.
[0022] The distributed transaction processing system and method provided by the embodiments of the present invention, when there is a business processing demand, the transaction manager registers a global transaction with the transaction coordinator, so that the transaction coordinator creates a global transaction identifier for the global transaction; the resource manager registers a branch transaction under the global transaction with the transaction coordinator according to the business processing demand, so that the transaction coordinator creates a corresponding branch transaction identifier for each branch transaction under the global transaction identifier. After obtaining the business processing statement of the business processing requirement in the branch transaction corresponding to the resource manager, the resource manager executes the business processing statement to obtain the updated business data, generates a rollback log according to the updated business data and the business data before the update, and submits the updated business data and the rollback log to the database to complete the submission operation of the resource manager in the first phase and release the resources used for the submission operation; the transaction coordinator determines whether the submission operation of each branch transaction corresponding to each branch transaction identifier under the global transaction identifier is successful in the first phase; if all are successful, the transaction manager is notified, so that the transaction manager initiates a global submission confirmation request in the second phase; after receiving the global submission confirmation request, the resource manager corresponding to each branch transaction corresponding to each branch transaction identifier under the global transaction identifier is asynchronously notified to delete the rollback log. Since the rollback log is generated in the first phase, and the resources locked by the branch transaction will be released immediately after the first phase is submitted, it can be seen that the resources do not need to be locked to the second phase, but the lock on the resources is released in the first phase after the rollback log is obtained, which reduces the lock range and improves efficiency. Even if an exception occurs in the second stage and a rollback is required, it is only necessary to find the rollback log and reverse parse it into SQL to achieve the rollback purpose. In addition, each resource manager asynchronously deletes the rollback log to improve processing efficiency. It can be seen that the operations of each branch transaction can be executed in parallel, thereby improving the concurrency performance of the distributed transaction processing system. The entire process is implemented based on the above three core components. The functions of each component are different and the division of labor is clear, which can reduce the complexity of distributed transaction processing. The embodiment of the present invention is suitable for scenarios with high requirements for performance and stability, and improves the blocking and performance overhead problems in the traditional two-phase commit protocol, while ensuring the consistency of distributed transactions. BRIEF DESCRIPTION OF THE DRAWINGS
[0023] Figure 1 A block diagram of a distributed transaction processing system according to an embodiment of the present invention;
[0024] Figure 2 A schematic diagram of the interaction between three components in one embodiment of the present invention;
[0025] Figure 3 is a processing flow chart of a resource manager in the first stage in one embodiment of the present invention;
[0026] Figure 4 A schematic diagram of deleting corresponding data in a database in one embodiment of the present invention;
[0027] Figure 5 A flowchart of a process of rolling back a resource manager in one embodiment of the present invention;
[0028] Figure 6 The figure is a flow chart of a distributed transaction processing method in one embodiment of the present invention. DETAILED DESCRIPTION
[0029] The transactions involved in the embodiments of the present invention are transactions based on database operations and have ACID properties: atomicity, consistency, isolation and persistence. The generation of distributed transactions is due to the splitting and distributed architecture of the database. Under normal circumstances, operating a database in a process is a local transaction. If multiple databases are operated in one process, or one or more databases are operated in multiple processes, a distributed transaction is generated. Global transactions and branch transactions are involved in the process of distributed transaction processing.
[0030] Among them, a global transaction refers to a transaction completed by operating multiple resource managers at one time, which consists of a group of branch transactions, namely local transactions.
[0031] Among them, branch transactions are local transactions. Local transactions are managed by local resource managers (usually database management systems DBMS, such as MySQL, Oracle, etc.), strictly support ACID characteristics, and are efficient and reliable. Local transactions do not have the processing capabilities of distributed transactions, and the smallest unit of isolation is limited by the resource manager, that is, local transactions can only control the operations of their own databases, and are powerless for the operations of other databases.
[0032] The implementation of the embodiment of the present invention is based on a relational database that supports local transactions, such as MySQL and Oracle. Java applications can access the relational database through JDBC.
[0033] In a first aspect, an embodiment of the present invention provides a distributed transaction processing system, see Figure 1 The system includes a transaction coordinator, a transaction manager, and a plurality of resource managers; wherein:
[0034] The transaction manager is used to: register a global transaction with the transaction coordinator when there is a business processing requirement;
[0035] The transaction coordinator is used to: create a global transaction identifier for the global transaction; and create a corresponding branch transaction identifier for each branch transaction under the global transaction identifier;
[0036] The resource manager is used to: register the branch transaction under the global transaction with the transaction coordinator according to the business processing demand; obtain the business processing statement in the branch transaction corresponding to the business processing demand of the resource manager, execute the business processing statement, obtain the updated business data, generate a rollback log according to the updated business data and the business data before the update, submit the updated business data and the rollback log to the database to complete the commit operation of the resource manager in the first stage, and release the resources used for the commit operation;
[0037] The transaction coordinator is also used to: determine whether the commit operations of each branch transaction corresponding to each branch transaction identifier under the global transaction identifier are all successful in the first phase; if they are all successful, notify the transaction manager so that the transaction manager initiates a global commit confirmation request in the second phase; after receiving the global commit confirmation request, asynchronously notify each resource manager corresponding to each branch transaction corresponding to each branch transaction identifier under the global transaction identifier to delete the rollback log.
[0038] It can be seen that the embodiment of the present invention mainly involves three core components: transaction coordinator, transaction manager and resource manager. It also involves the global transaction identifier XID, which is the unique identifier of the global transaction, and can be passed in the service call link and bound to the service transaction context.
[0039] Among them, the transaction coordinator, Transaction Coordinator, abbreviated as TC, is used to connect the resource manager and the transaction manager, create a global transaction identifier for the global transaction, and create a branch transaction identifier for the branch transaction. Manage and record the status of each branch transaction. In the first stage, after the resource manager performs the commit operation, it determines whether the commit of each branch transaction corresponding to each branch transaction identifier under the global transaction identifier is successful. If all are successful, it notifies the transaction manager, so that the transaction manager issues a global commit confirmation request. When at least one branch transaction fails to commit, the transaction manager will also be notified, so that the transaction manager issues a global rollback request. The transaction manager performs corresponding operations after receiving the global commit confirmation request or the global rollback request. It can be seen that TC is equivalent to the middleman between the resource manager and the transaction manager.
[0040] Among them, the transaction manager, TM for short, is the initiator of the global transaction, and when receiving the notification that the commit of each branch transaction is successful, it sends a global commit confirmation request to TC. When the commit of at least one branch transaction fails, it sends a global rollback request to TC. It can be seen that TM is equivalent to issuing orders.
[0041] Among them, the Resource Manager, or RM for short, is responsible for registering the branch transactions under the global transaction with the transaction coordinator; executing business processing statements, obtaining updated business data, generating rollback logs based on the updated business data and the business data before the update, and then submitting the updated business data and the rollback logs to the database, thereby completing the first phase of submission. In the second phase, if each branch transaction is successfully submitted, its own rollback log will be deleted. If at least one branch transaction fails to submit, a rollback operation will be performed to recover the data. It can be seen that RM is equivalent to doing the specific work.
[0042] Based on the above system, see Figure 2 , the transaction processing process can generally include:
[0043] (1) When there is a business processing requirement, the transaction manager registers the global transaction with the transaction coordinator, so that the transaction coordinator creates a global transaction identifier for the global transaction.
[0044] (2) In response to the business processing requirements, the resource manager registers the branch transaction under the global transaction with the transaction coordinator, so that the transaction coordinator creates a branch transaction identifier for the branch transaction;
[0045] (3) The resource manager executes the business processing statement to obtain updated business data; generates a rollback log according to the updated business data and the business data before the update; submits the updated business data and the rollback log to the database to complete the submission operation of the resource manager in the first stage, and releases the resources used for the submission operation;
[0046] (4) The transaction coordinator determines whether the commit operations of the branch transactions corresponding to the branch transaction identifiers under a global transaction identifier are all successful in the first phase; if they are all successful, the transaction manager is notified, so that the transaction manager initiates a global commit confirmation request in the second phase;
[0047] (5) After receiving the global commit confirmation request, the transaction coordinator asynchronously notifies each resource manager corresponding to each branch transaction corresponding to each branch transaction identifier under the global transaction identifier to delete the rollback log to implement a data cleanup operation.
[0048] In one embodiment, each resource manager executes the business processing statement to obtain updated business data, and generates a rollback log based on the updated business data and the pre-update business data, including: searching for the pre-update business data corresponding to the business processing statement according to the business processing statement, saving the pre-update business data as a pre-update image, executing the business processing statement to obtain updated business data, saving the updated business data as an updated image, and saving the pre-update image and the post-update image as a rollback log.
[0049] That is, see Figure 3 The process of generating a rollback log by the resource manager includes: searching for pre-update business data corresponding to the business processing statement, saving the pre-update business data as a pre-update image, obtaining post-update business data, saving the post-update business data as a post-update image, and saving the pre-update image and the post-update image as a rollback log.
[0050] It can be seen that the rollback log includes the image before the update and the image after the update.
[0051] In one embodiment, each resource manager can also be used to: generate a row lock when obtaining the rollback journal, lock the rollback journal through the row lock, and submit the row lock together with the updated business data and the rollback journal to the database; wherein, the rollback journal cannot be rolled back through the rollback journal in a locked state.
[0052] That is to say, when the resource manager generates a rollback log, it also generates a row lock. The role of the row lock is to lock the rollback log, so that the rollback operation cannot be performed based on the rollback log. When submitting, the row lock, the updated business data, and the rollback log are submitted to the database together. Only when the row lock is open can the rollback operation be performed based on the rollback log.
[0053] The updated business data is stored in a business table in the database, the rollback log is stored in a log table in the database, and the row lock is stored in a lock table in the database.
[0054] It can be seen that different types of data are stored in different data tables in the database, achieving isolation between different types of data.
[0055] In one embodiment, the transaction coordinator is also used to: when asynchronously notifying each resource manager corresponding to each branch transaction corresponding to each branch transaction identifier under the global transaction identifier to delete the rollback log, notify each resource manager corresponding to each branch transaction corresponding to each branch transaction identifier under the global transaction identifier to delete the row lock.
[0056] It can be seen that when the resource manager deletes the rollback mechanism, it will also delete the row lock to achieve data cleanup.
[0057] In one embodiment, the transaction coordinator can also be used to: if the commit operation of at least one branch transaction in the first phase is unsuccessful, notify the transaction manager so that the transaction manager initiates a global rollback request in the second phase; after receiving the global rollback request, notify each resource manager corresponding to each branch transaction corresponding to each branch transaction identifier under the global transaction identifier, so that each resource manager opens its own rollback log through its own row lock, generates a reverse business processing statement based on its own rollback log, executes the reverse business processing statement to obtain the business data before the update, and deletes its own rollback log and its own row lock.
[0058] That is to say, if the commit operation of at least one branch transaction fails, the transaction coordinator will notify the transaction manager, so that the transaction manager will issue a global rollback notification. After receiving the global rollback notification, the transaction coordinator will notify each resource manager corresponding to each branch transaction corresponding to each branch transaction identifier under the global transaction identifier, so that each resource manager will open its own rollback log through its own row lock, generate a reverse business processing statement based on its own rollback log, execute the reverse business processing statement, thereby obtaining the business data before the update, realizing data rollback, and deleting its own rollback log and its own row lock.
[0059] In one embodiment, the resource manager is also used to: before generating a reverse business processing statement based on its own rollback log, determine whether the current business data in the database is consistent with the updated image in the rollback log; if they are consistent, generate a reverse business processing statement based on its own rollback log; otherwise, notify manual data rollback operation.
[0060] Visible, see Figure 5 Before rolling back, the source manager will determine whether the current business data in the database is consistent with the updated image in the rollback log. If the two copies of data are completely consistent, it means there is no dirty write and the business data can be restored. If they are inconsistent, it means there is dirty write and dirty write needs to be handled manually.
[0061] In one embodiment, see Figure 4 The resource manager can also be used to: after a rollback operation, delete the corresponding updated business data, the rollback log and the row lock in the database.
[0062] That is, after the rollback, the updated business data, rollback log, and row locks in the database will be deleted together.
[0063] In one embodiment, the business processing requirement requires multiple microservices to implement, and each microservice corresponds to a resource manager; when the business processing requirement calls each microservice during the implementation process, the resource manager corresponding to the microservice will register a branch transaction with the transaction coordinator.
[0064] That is to say, a business processing requirement often uses multiple microservices, and a microservice is provided by a resource manager. Therefore, when a microservice needs to be called during the implementation of the business processing requirement, the resource manager of the microservice will register a branch transaction with the transaction coordinator.
[0065] Among them, in the first stage, the proxy data source of the microservice can intercept the business processing statements of the business processing requirements, so that the microservice can obtain the business processing statements, thereby achieving a non-intrusive effect on the business.
[0066] It is understandable that after the branch transaction commits in the first phase, the resources locked by the branch transaction are released immediately. This is also the difference between the processing of branch transactions and the traditional processing of XA transactions. The two-phase commit often needs to lock the resources until the confirmation commit or rollback operation in the second phase. In the embodiment of the present invention, after the rollback log is available, the lock on the resources can be released in the first phase, which reduces the lock range and improves efficiency. Even if an exception occurs in the second phase and a rollback is required, it is only necessary to find the rollback log and reverse parse it into SQL to achieve the purpose of rollback. It can be seen that the embodiment of the present invention not only retains the strong consistency guarantee of XA transactions, but also improves concurrency performance and reduces complexity.
[0067] Among them, XA transactions are transactions based on the XA protocol. The XA protocol was first proposed by Tuxedo and handed over to the X / Open organization as the interface standard between resource managers and transaction managers. All major database manufacturers provide support for XA. The XA protocol uses a two-phase commit method to manage distributed transactions. The XA interface provides a standard interface for communication between resource managers and transaction managers. The XA protocol includes two sets of functions, functions starting with xa_ and functions starting with ax_. Depending on the context, XA has multiple meanings. The XA protocol is a specification for distributed transaction processing, which mainly defines the interface between the transaction manager TransactionManager and the resource manager Resource Manager. The following functions enable the transaction manager to perform operations on the resource manager:
[0068] (1)xa_open, xa_close: establish and close the connection with the resource manager.
[0069] (2)xa_start, xa_end: start and end a local transaction.
[0070] (3)xa_prepare, xa_commit, xa_rollback: pre-commit, commit, and rollback a local transaction.
[0071] (4)xa_recover: Rolls back a pre-committed transaction.
[0072] (5) Functions beginning with ax_ enable the resource manager to dynamically register with the transaction manager.
[0073] (6) ax_reg, ax_unreg: Allow a resource manager to dynamically register or unregister with a transaction coordinator.
[0074] The embodiments of the present invention have the following beneficial effects:
[0075] (1) High transparency: Each node does not need to worry about the coordination and management of distributed transactions, but only needs to execute business logic, which reduces the complexity of the system.
[0076] (2) Low performance overhead: Since unnecessary communication and coordination overhead are reduced, it has better performance than the traditional XA transaction protocol.
[0077] (3) Low complexity: It simplifies the complexity of distributed transaction processing and reduces the difficulty of development and maintenance.
[0078] (4) High reliability: The consistency and reliability of distributed transactions are ensured through the unified coordination and decision-making of the transaction manager.
[0079] (5) Strong scalability: The embodiments of the present invention are applicable to distributed systems of different scales and complexities and have good scalability.
[0080] (6) Strong consistency guarantee: Distributed transactions based on the XA protocol still maintain strong consistency guarantees, ensuring data consistency and transaction correctness in the distributed system.
[0081] In summary, the present invention is applicable to distributed transaction processing scenarios in distributed systems such as microservice architecture and cloud computing, and is particularly applicable to scenarios with high requirements for performance and stability. It improves the blocking and performance overhead problems in the traditional two-phase commit protocol while ensuring the consistency of distributed transactions.
[0082] In a second aspect, an embodiment of the present invention provides a distributed transaction processing method, which is implemented based on the system provided in the first aspect. Figure 6 , the method comprising:
[0083] S110, registering a global transaction with the transaction coordinator through the transaction manager when there is a business processing demand; creating a global transaction identifier for the global transaction through the transaction coordinator;
[0084] S120, registering the branch transaction under the global transaction with the transaction coordinator according to the business processing requirements through the resource manager; creating a corresponding branch transaction identifier for each branch transaction under the global transaction identifier through the transaction coordinator;
[0085] S130, obtaining, through the resource manager, a business processing statement of the business processing requirement in the branch transaction corresponding to the resource manager, executing the business processing statement to obtain updated business data, generating a rollback log according to the updated business data and the business data before the update, submitting the updated business data and the rollback log to the database to complete the commit operation of the resource manager in the first phase, and releasing the resources used for the commit operation;
[0086] S140. The transaction coordinator determines whether the commit operations of the branch transactions corresponding to the branch transaction identifiers under the global transaction identifier are all successful in the first phase; if they are all successful, the transaction manager is notified so that the transaction manager initiates a global commit confirmation request in the second phase; after receiving the global commit confirmation request, the resource managers corresponding to the branch transactions corresponding to the branch transaction identifiers under the global transaction identifier are asynchronously notified to delete the rollback log.
[0087] It is understandable that the explanation of the relevant contents, specific implementation methods, beneficial effects, examples, etc. in the method provided in the embodiment of the present invention can be found in the corresponding parts of the system provided in the first aspect, and will not be repeated here.
[0088] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.
[0089] Those skilled in the art should be aware that in one or more of the above examples, the functions described in the present invention can be implemented by hardware, software, widgets, or any combination thereof. When implemented by software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or codes on a computer-readable medium.
[0090] The specific implementation methods described above further illustrate the objectives, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above description is only a specific implementation method of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc. made on the basis of the technical solution of the present invention should be included in the scope of protection of the present invention.
Claims
1. A distributed transaction processing system, characterized in that: It includes a transaction coordinator, a transaction manager, and multiple resource managers; among them: The transaction manager is used to: register a global transaction with the transaction coordinator when there is a business processing requirement; The transaction coordinator is used to: create a global transaction identifier for the global transaction; and create a corresponding branch transaction identifier for each branch transaction under the global transaction identifier; The resource manager is used to: register the branch transaction under the global transaction with the transaction coordinator according to the business processing demand; obtain the business processing statement in the branch transaction corresponding to the business processing demand of the resource manager, execute the business processing statement, obtain the updated business data, generate a rollback log according to the updated business data and the business data before the update, submit the updated business data and the rollback log to the database to complete the commit operation of the resource manager in the first stage, and release the resources used for the commit operation; The transaction coordinator is also used to: determine whether the commit operations of each branch transaction corresponding to each branch transaction identifier under the global transaction identifier are all successful in the first phase; if they are all successful, notify the transaction manager so that the transaction manager initiates a global commit confirmation request in the second phase; after receiving the global commit confirmation request, asynchronously notify each resource manager corresponding to each branch transaction corresponding to each branch transaction identifier under the global transaction identifier to delete the rollback log.
2. The system according to claim 1, characterized in that Each resource manager executes the business processing statement to obtain updated business data, and generates a rollback log based on the updated business data and the pre-update business data, including: searching for the pre-update business data corresponding to the business processing statement according to the business processing statement, saving the pre-update business data as a pre-update image, executing the business processing statement to obtain updated business data, saving the updated business data as an updated image, and saving the pre-update image and the post-update image as a rollback log.
3. The system according to claim 1, characterized in that Each resource manager is also used to: generate a row lock when obtaining the rollback journal, lock the rollback journal through the row lock, and submit the row lock together with the updated business data and the rollback journal to the database; wherein, the rollback journal cannot be rolled back through the rollback journal in a locked state.
4. The system according to claim 3, characterized in that The updated business data is stored in the business table in the database, the rollback log is stored in the log table in the database, and the row lock is stored in the lock table in the database.
5. The system according to claim 3, characterized in that The transaction coordinator is also used to: when asynchronously notifying each resource manager corresponding to each branch transaction corresponding to each branch transaction identifier under the global transaction identifier to delete the rollback log, notify each resource manager corresponding to each branch transaction corresponding to each branch transaction identifier under the global transaction identifier to delete the row lock.
6. The system according to claim 3, characterized in that The transaction coordinator is further used to: if the commit operation of at least one branch transaction in the first phase is unsuccessful, notify the transaction manager so that the transaction manager initiates a global rollback request in the second phase; After receiving the global rollback request, each resource manager corresponding to each branch transaction corresponding to each branch transaction identifier under the global transaction identifier is notified, so that each resource manager opens its own rollback log through its own row lock, generates a reverse business processing statement based on its own rollback log, executes the reverse business processing statement to obtain the business data before the update, and deletes its own rollback log and its own row lock.
7. The system according to claim 6, characterized in that The resource manager is also used to: before generating a reverse business processing statement based on its own rollback log, determine whether the current business data in the database is consistent with the updated image in the rollback log; if consistent, generate a reverse business processing statement based on its own rollback log; otherwise, notify manual data rollback operation.
8. The system according to claim 7, characterized in that The resource manager is further used to delete the corresponding updated business data, the rollback log and the row lock in the database after performing a rollback operation.
9. The system according to claim 1, characterized in that The business processing requirement requires multiple microservices to implement, and each microservice corresponds to a resource manager; when each microservice is called during the implementation of the business processing requirement, the resource manager corresponding to the microservice will register a branch transaction with the transaction coordinator.
10. A distributed transaction processing method, characterized in that: The method is implemented based on the system according to any one of claims 1 to 9, and the method comprises: S110, registering a global transaction with the transaction coordinator through the transaction manager when there is a business processing demand; creating a global transaction identifier for the global transaction through the transaction coordinator; S120, registering the branch transaction under the global transaction with the transaction coordinator according to the business processing requirements through the resource manager; creating a corresponding branch transaction identifier for each branch transaction under the global transaction identifier through the transaction coordinator; S130, obtaining, through the resource manager, a business processing statement of the business processing requirement in the branch transaction corresponding to the resource manager, executing the business processing statement to obtain updated business data, generating a rollback log according to the updated business data and the business data before the update, submitting the updated business data and the rollback log to the database to complete the commit operation of the resource manager in the first phase, and releasing the resources used for the commit operation; S140. The transaction coordinator determines whether the commit operations of the branch transactions corresponding to the branch transaction identifiers under the global transaction identifier are all successful in the first phase; if they are all successful, the transaction manager is notified so that the transaction manager initiates a global commit confirmation request in the second phase; after receiving the global commit confirmation request, the resource managers corresponding to the branch transactions corresponding to the branch transaction identifiers under the global transaction identifier are asynchronously notified to delete the rollback log.
Citation Information
Cited By
Service processing method and device
CN119557365A
TCC distributed transaction performance optimization method and device and medium
CN121524144A
A performance optimization method, device and medium for a TCC distributed transaction
CN121524144B
