1. Background
With the development of business, a single system gradually cannot meet the needs of the business, and the distributed architecture has gradually become the first choice for large-scale Internet platforms. The concomitant problem is that the local transaction plan can no longer be satisfied, and the related specifications and frameworks for distributed transactions have emerged.
In this case, large manufacturers have implemented different distributed frameworks according to the distributed transaction implementation specifications to simplify business developers' handling of distributed transaction-related work and allow developers to focus on core business development.
Seata is such a distributed transaction processing framework. Seata is open sourced by Ali, formerly known as Fescar, and transformed into Seata after a brand upgrade.
2. Distributed transaction specification
1. Distributed transaction related concepts
Transaction: A program execution unit is a set of user-defined operation sequences that need to meet ACID attributes.
Local affairs: The affairs are managed by the local resource manager.
Distributed transaction: The operations of the transaction are located on different nodes.
Branch transaction: In a distributed transaction, a local transaction managed by the resource manager.
Global transaction: A transaction completed by multiple resource managers at one time, consisting of a set of branch transactions.
2. Distributed transaction implementation specifications
For local transactions, you can use the DBMS system to achieve transaction management, but for distributed transactions, it can do nothing. For distributed transactions, there are currently two main ideas: the strong consistency specification of the XA protocol and the ultimate consistency specification of flexible transactions.
2.1 XA
XA is an interface standard designed based on the 2-phase commit protocol. A resource manager that implements the XA specification can participate in XA global transactions. The application undertakes the work of the transaction manager TM, the database undertakes the work of the resource manager RM, TM generates a global transaction id, and controls the commit and rollback of the RM.
2.2 Eventual consistency of flexible transactions
This specification mainly has 3 kinds of realization ways, TCC, MQ transaction message, local message table. (There are other less commonly used implementations such as Saga).
TCC: try/confirm/cancel, lock the resource in the try phase, submit it in the confirm phase, and release the resource in the cancel phase if the resource lock fails.
MQ transaction message: The prerequisite message system needs to support transactions such as RocketMQ. Before the local transaction is executed, the transaction message prepare is sent, and the local transaction is executed successfully, and the transaction message commit is sent to achieve the final consistency of distributed transactions. If the transaction message commit fails, RocketMQ will check the message sender to ensure that the message is submitted normally. If the execution of step 5 fails, retry is performed to achieve final consistency.
Local message table: similar to MQ transaction messages, the difference is that MQ does not support transaction messages and needs to use the transaction management capabilities of the local database. In step 1, the message to be sent is submitted to the DB together with the local transaction, and the message is persisted with the help of DB transaction management. Step 2 The application scans the local message table and retries sending to ensure that the message can be sent successfully.
Three, Seata architecture
1. ** System composition**
Seata has three core components:
-
Transaction Coordinator (TC, transaction coordinator)
Maintain the status of global transactions and branch transactions, drive global transaction commit or rollback.
-
Transaction Manager (TM, transaction manager)
Define the scope of the global transaction, start a transaction, commit a transaction, and roll back a transaction.
-
Resource Manager (RM, resource manager):
Manage resources on branch transactions, register branch transactions with TC, report the status of branch transactions, and drive the commit or rollback of branch transactions.
The three components cooperate with each other. TC is deployed independently in the form of Server, and TM and RM are integrated and started in the application. The overall interaction is as follows:
2. Working mode
Seata supports four working modes:
2.1 AT（Auto Transaction）
AT mode is Seata's default working mode. It needs to be based on relational databases that support local ACID transactions, Java applications, and database access through JDBC.
2.1.1 Overall mechanism
This mode is an evolution of the XA protocol. The XA protocol is implemented based on the resource manager, while AT is not. The two stages of AT are:
-
Phase 1: Business data and rollback log records are committed in the same local transaction, and local locks and connection resources are released.
- The second stage: the submission is asynchronous and completed very quickly; the rollback is compensated in the reverse direction through the rollback log of the first stage.
In the figure below, step 1 opens the global transaction; step 2 registers the branch transaction, which corresponds to the first phase; step 3 commits or rolls back the branch transaction, corresponds to the second phase.
2.1.2 Features
-
Advantages: no intrusion into the code; high concurrency, the local lock will be released in one stage; no database support for the XA protocol is required.
- Disadvantages: Can only be used in relational databases that support ACID; SQL parsing cannot yet support all syntax.
2.2 TCC
The work of this mode is divided into three stages: prepare/commit/cancel.
2.2.1 Overall mechanism
-
TM applies for global transaction XID from TC, and propagates to each sub-call.
-
The TM where the sub-call is located registers the branch transaction with the TC, executes the local prepare, and reports the execution result to the TC.
- TC determines whether the second stage is to execute commit or rollback according to the execution results of each branch transaction.
2.2.2 Features
-
Advantages: Does not rely on local affairs.
- Disadvantages: The rollback logic relies on manual coding; the business is more invasive.
2.3 Saga mode
2.3.1 What is Saga?
In 1987, Hector Garcia-Molina and Kenneth Salem of Princeton University published a Paper Sagas about how to deal with long lived transactions. Saga is a long-lived transaction that can be decomposed into a collection of sub-transactions that can be interleaved. See the paper here.
Simply put, Saga decomposes a long transaction (T) into a series of Sub transactions (Ti), and each Sub transaction has a corresponding compensation action (Ci) to undo the impact of the Ti transaction. Sub transactions are directly submitted to the library, and when an exception occurs, the reverse is compensated.
Therefore, there are two types of Saga transactions:
-
T1, T2, T3, ..., Tn
- T1, T2, ..., Tj, Cj,..., C2, C1, where 0 <j <n
The first is the case of normal submission, and the second is the case where an exception occurs when the Tj transaction is submitted and reverse compensation is started.
Saga mode is a long transaction solution provided by Seata. For example, an external system is involved in a global transaction, and its resource manager cannot be managed, and it is not easy to transform it into a TCC. This type of solution can be used at this time.
2.3.2 Overall mechanism
In the Saga model, each participant in the business process submits a local transaction. When a participant fails, it compensates the previously successful participant. Both the first-phase forward service and the second-phase compensation service are implemented by business development.
For multiple branch transactions in the above figure, the 2.* step that appears multiple times is omitted. For business application downtime during the execution of the global transaction, the peer node in the business application cluster will retrieve the relevant session from the TC and load the detailed information from the DB to restore the state machine.
2.3.3 Features
-
Advantages: One-stage submission of local transactions, no locks, high performance; event-driven architecture, participants can execute asynchronously, high throughput; compensation services are easy to implement.
- Disadvantages: Isolation is not guaranteed.
2.4 XA mode
XA is an interface standard based on the two-phase submission design. For resource managers that support XA, the XA mode of the Seata framework will make the XA solution easier to use. Prerequisite for use: The branch database is required to support XA transactions, the application is a Java application, and JDBC is used to access the database.
2.4.1 Overall mechanism
In the distributed transaction framework defined by Seata, a transaction mode that uses transaction resources (database, message service, etc.) to support the XA protocol, and uses the XA protocol mechanism to manage branch transactions.
-
Execution stage: Business SQL is executed in the XA branch, managed by the RM manager of the branch transaction, and then XA prepare is executed.
- Completion stage: TM notifies each branch to execute XA commit or XA rollback through TC according to the execution result of each branch.
2.4.2 ** Features**
-
Advantages: Inherit the advantages of the XA protocol, and the transaction has strong consistency.
- Disadvantages: It also inherits the disadvantages of the XA protocol. Because branch transactions are opened for a long time, the concurrency is low.
2.5 Comparison of Seata's modes
There is no silver bullet in the distributed transaction solution. Choose the appropriate model according to your own business characteristics. For example, in pursuit of strong consistency, you can choose AT and XA, exist to interface with external systems, you can choose Saga mode, you can't rely on local transactions, you can use TCC, etc. Choose according to the advantages and disadvantages of each mode.
Fourth, the core realization of AT mode
In view of the fact that Seata supports many modes, and its default mode is AT, in order to save space, the following analysis of its related core module implementation around the AT mode.
1. Start the transaction coordinator
TC (transaction coordinator) starts as an independent service, as a server, maintains the status of global transactions and branch transactions, and drives global transaction commit or rollback. The following is the startup process of TC:
2. ** Startup of Transaction Manager**
TM (Transaction Manager) is integrated and started in the application, responsible for defining the scope of the global transaction, starting a transaction, committing a transaction, and rolling back a transaction.
The GlobalTransactionScannerbean needs to be configured in the application where TM is located, and the following initialization process will be performed when the application starts:
3 . Start Explorer
RM (resource manager) is integrated and started in the application, responsible for managing resources on branch transactions, registering branch transactions with TC, reporting the status of branch transactions, and driving the commit or rollback of branch transactions.
In the application where RM is located, in addition to configuring GlobalTransactionScanner to start RMClient like TM, it also needs to configure DataSourceProxy to implement the proxy for data source access. The data source agent implements operations such as sql parsing → generating undo-log → business sql and undo-log are submitted locally.
4. Workflow of global affairs
Here is a simple example to illustrate the working principle of global transactions:
-
BusinessService: initiate a purchase service
- StorageService: inventory management service
The purchase operation is implemented in businessService.purchase. The purchase method is annotated through GlobalTransaction, and the inventory service deduct method is called through the Dubbo service. The sample is as follows:
@GlobalTransactional(timeoutMills = 300000, name = "dubbo-demo-tx")
public void purchase(String userId, String commodityCode, int orderCount) {
storageService.deduct(commodityCode, orderCount);
// throw new RuntimeException("xxx");
}4.1 Successful global transaction process
4.2 Successful global transaction process
It is set here that after BusinessService successfully calls StorageService, an exception occurs locally.
5. Write isolation realization
When the global transaction is not committed and the branch transaction has been committed locally (assuming that resource A is modified), how to avoid other transactions from modifying resource A at this time? Seata uses a global lock to achieve, and its process is as follows:
6. Read isolation realization
On the basis that the database local isolation level is read committed or above, Seata provides read uncommitted. This is well understood. The branch transaction has been committed locally before the global transaction is committed. If you want to read submitted, you need to add for update to the select statement.
Five, summary
Seata is a powerful distributed transaction framework in the Java field, which supports multiple modes. Among them, the AT mode supported by default, compared with the traditional 2PC protocol (database-based XA protocol), solves the problem of 2PC long-term lock resources and improves concurrency. Among the various modes supported by Seata, the AT mode implements distributed transactions for zero business operations, which is more friendly to developers. In addition, Seata's Server can be clustered when selecting a suitable storage medium to reduce the impact of single points of failure.
This article mainly refers to the official website and some blogs. At the same time, I read the source code of the AT mode. If there is something wrong, I hope to point it out and discuss and exchange together.
Six, reference
Author: vivo official website mall development team