table of Contents
1. Introduction
1.1, the concept of distributed transactions
Distributed transaction means that the participants of the transaction, the server that supports the transaction, the resource server, and the transaction manager are located on different nodes of different distributed systems;
1.2. Examples
For example, in a distributed e-commerce system, if a user purchases a product, under normal circumstances, an order data will be added to the order system, and the quantity of the product will be subtracted from the inventory system by 1, and the two systems will maintain Data consistency;
then when there is an exception in the system cluster, the order system adds data, but the inventory system does not subtract the quantity of goods, which will lead to data inconsistency, and this accident is formally caused by the control of distributed transactions .
Two, XA two-phase submission
2.1 Introduction to XA
The XA protocol was first proposed by Oracle Tuxedo and handed over to the X/Open organization as the interface standard between the resource manager (database) and the transaction manager. Currently, major database vendors such as Oracle, Informix, DB2, and Sybase 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 the resource manager and the transaction manager.
XA is the interface specification (ie interface function) between the transaction middleware and the database defined by X/Open DTP. The transaction middleware uses it to notify the database transaction of the start, end, commit, rollback, etc. XA interface functions are provided by database vendors.
The X/Open organization (now Open Group) defined a distributed transaction processing model. The X/Open DTP model (1994) includes four parts: application (AP), transaction manager (TM), resource manager (RM), and communication resource manager (CRM). Generally, a common transaction manager (TM) is a transaction middleware, a common resource manager (RM) is a database, and a common communication resource manager (CRM) is a message middleware.
2.2, one-stage submission
Advantages
1) Relatively simple
2) No need to interact with other services, better performance
Disadvantages
1) Cannot support multi-data source transactions (in a distributed system)
2.3, two-phase commit
The two-phase protocol changes the two layers into three layers, adding an intermediate manager role, thereby coordinating the relationship between multiple data sources. The two-phase commit protocol is divided into two phases. The
first phase: the transaction manager informs to participate in the Each resource manager of the transaction informs them to start preparing the transaction. After receiving the message, the resource manager starts the preparation phase, writes the transaction log and executes the transaction, but does not commit, and then returns the message whether it is ready to the transaction manager;
second Stage: After the transaction manager accepts each message, it begins to analyze. If any one of them fails, it sends a rollback command, otherwise it sends a commit command;
advantages
1) Two-stage support for distributed system transactions;
2) Two-stage commit protocol In order to ensure the consistency of the transaction, whether it is the transaction manager or each resource manager, every step of the operation will be recorded in a log to prepare the basis for recovery after a failure;
disadvantages
1) The disadvantage of the two-phase commit protocol is blocking. Because the transaction manager needs to collect the response messages of each resource manager, if one or more of them do not return messages, the transaction manager has been waiting, and the application is blocked, or even permanently;
2) Two-phase commit theory One widespread industrial application is the XA protocol. At present, almost all commercial databases that charge fees support the XA protocol. The XA protocol has been mature in the industry for decades, but at present, in the application scenario of massive Internet traffic, the throughput bottleneck becomes very fatal, so it is rarely used;
Three, TCC program
3.1 Introduction
TCC is a flexible distributed transaction solution solution provided by Alipay architects. It mainly includes three steps:
1) Try: reserve business resources/data validation
2) Confirm: confirm the execution of the business operation
3) Cancel: cancel the execution of the business operating
3.2 Principle
TCC schemes are widely used in e-commerce and financial fields. The TCC plan is actually an improvement submitted in two stages. It explicitly divides each branch of the entire business logic into three operations: Try, Confirm, and Cancel. The Try part completes the preparation of the business, the confirm part completes the submission of the business, and the cancel part completes the rollback of the transaction.
When the transaction starts, the business application will register the startup transaction with the transaction coordinator. After that, the business application will call the try interface of all services to complete a stage of preparation. After that, the transaction coordinator will decide to call the confirm interface or the cancel interface according to the return of the try interface. If the interface call fails, a retry will be made;
microservices advocate lightweight and easy deployment of services, and many transaction processing logics in the TCC solution need to be implemented by their own coding, which is complex and has a large amount of development;
3.3, advantages and disadvantages
Advantages
1) Let the application define the granularity of database operations, which makes it possible to reduce lock conflicts and improve throughput.
Disadvantages
1) Intrusive to the application. Each branch of the business logic needs to implement the three operations of try, confirm, and cancel. The application is more intrusive and the transformation cost is high.
2) It is difficult to implement. Different rollback strategies need to be implemented according to different failure reasons such as network status and system failure. In order to meet the requirements of consistency, the confirm and cancel interfaces must be idempotent