The background,

With the development of services, single systems cannot meet service requirements, and distributed architecture becomes the first choice for large Internet platforms. The problem is that the local transaction scheme has been unable to meet the requirements of distributed transaction related specifications and frameworks.

In this case, large vendors implement different distributed frameworks according to distributed transaction implementation specifications to simplify business developers’ work related to distributed transactions and allow them to focus on core business development.

Seata is such a distributed transaction processing framework, Seata is open source by Ali, formerly known as Fescar, through brand upgrade into Seata.

2. Distributed transaction specification

1. Concepts related to distributed transactions

Transaction: A unit of program execution that is a user-defined sequence of operations required to satisfy the ACID property.

** Local transactions: ** transactions are managed by the local resource manager.

** Distributed transactions: ** transactions operate on different nodes.

** Branch transactions: ** In distributed transactions, local transactions managed by resource managers.

** Global transactions: ** Transactions that operate on multiple resource managers at once and consist of a set of branch transactions.

2. Distributed transaction implementation specification

For local transactions, the DBMS system can be used to manage the transactions, but for distributed transactions, it is powerless. For distributed transactions, there are two main ideas: strong consistency specification of XA protocol and final consistency specification of flexible transactions.

2.1 the XA

XA is an interface standard designed based on the two-phase commit protocol. Resource managers that implement the XA specification can participate in XA global transactions. The application takes on the task of transaction manager TM and the database takes on the task of resource manager RM. TM generates global transaction IDS and controls the commit and rollback of RM.

2.2 Final consistency of flexible transactions

There are three main implementations of the specification: TCC, MQ transaction messages, and local message tables. (There are other less commonly used implementations such as Saga).

**TCC: ** Try /confirm/cancel: Lock the resource in the try phase, commit the resource in the confirm phase, and release the resource in the Cancel phase if the lock fails.

**MQ transaction messages: ** The system needs to support transactions such as RocketMQ. Before the local transaction is executed, send the transaction message prepare, the local transaction is executed successfully, and send the transaction message COMMIT to achieve the final consistency of distributed transactions. If the transaction message commit fails, RocketMQ checks back to the message sender to ensure that the message is properly committed. If Step 5 fails, retry to achieve final consistency.

** Local message table: ** Similar to MQ transaction messages, except that MQ does not support transaction messages and requires the transaction management capabilities of a local database. In Step 1, the message to be sent is submitted to DB along with the local transaction, and DB’s transaction management ensures message persistence. Step 2 Scan the local message table and retry sending the message to ensure that the message can be successfully sent.

3. Seata architecture

1. System composition

Seata has three core components:

  • Transaction Coordinator(TC)

    Maintains the state of global and branch transactions and drives global transaction commit or rollback.

  • Transaction Manager(TM, Transaction Manager)

    Define the scope of a global transaction, start the transaction, commit the transaction, and roll back the transaction.

  • Resource Manager(RM) :

    Manage the resources of branch transactions, register branch transactions with TC, report the status of branch transactions, and drive the submission 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 the default working mode of Seata. Need to be based on a relational database that supports local ACID transactions, Java application, database access via JDBC.

2.1.1 Overall mechanism

This pattern is an evolution of the XA protocol, which is based on a resource manager implementation, 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, freeing local locks and connection resources.

  • Phase 2: Commit asynchronously, very fast; Rollback is compensated in reverse by the rollback log of one phase.

In the following figure, step 1 enable global transactions. Step 2 Register a branch transaction, which corresponds to a phase. Step 3 Commit or roll back the branch transaction, which corresponds to two phases.

2.1.2 characteristics

  • ** Advantages: ** no intrusion on the code; High concurrency, local locks will be released in one stage; Database support for the XA protocol is not required.

  • Disadvantages: ** can only be used in relational databases that support ACID; SQL parsing does not yet support the full syntax.

2.2 TCC

This mode works in three stages: Prepare, commit, and Cancel.

2.2.1 Overall mechanism

  • TM applies for a global transaction XID from TC, which is propagated to each child call.

  • The TM of the sub-call registers the branch transaction with the TC, executes the local prepare, and reports the result to the TC.

  • TC determines whether to perform COMMIT or ROLLBACK in the second phase according to the results of each branch transaction.

2.2.2 characteristics

  • ** Advantages: ** does not depend on local transactions.

  • ** Disadvantages: ** rollback logic relies on manual encoding; Services are highly intrusive.

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 on how to deal with a long Lived Transaction. A Saga is a collection of long-running transactions that can be broken up into sub-transactions that can run interleaved. The paper is here.

In simple terms, Saga breaks a long transaction (T) into a series of Sub transactions (Ti), each of which has a corresponding compensation action (Ci) to undo the effects of the Ti transaction. Sub transactions are committed directly to the library, and when exceptions occur, they are compensated in reverse.

There are therefore two types of Saga transactions:

  • T1, T2, T3, … , Tn

  • T1, T2, … , Tj, Cj,… , C2, C1, where 0 < j < n

The first is the normal commit case, the second is the commit Tj transaction exception, start the reverse compensation case.

Saga mode is a long transaction solution provided by Seata. For example, when an external system is involved in a global transaction and cannot manage its resource manager, it is not feasible to convert it to TCC.

2.3.2 Overall mechanism

In the Saga model, each participant in the business process commits a local transaction, and when one of the participants fails, the previous successful participants are compensated. Both the one-phase forward service and the two-phase compensation service are implemented by the business development.

In the figure above, for multiple branch transactions, the repeated step 2.* is omitted. In the case of service application breakdown during global transaction execution, peer nodes in the service application cluster recover the state machine by obtaining related sessions from the TC and loading details from the DB.

2.3.3 characteristics

  • ** Advantages: ** One-stage commit local transaction, no lock, high performance; Event-driven architecture with asynchronous execution by participants and high throughput; Compensation services are easy to implement.

  • Disadvantages: ** does not guarantee isolation.

2.4 the XA mode

XA is an interface standard based on a two-phase commit design. For XA-enabled resource managers, the XA schema of the Seata framework makes XA schemes easier to use. Prerequisites: The branch database must support XA transactions, be a Java application, and use JDBC to access the database.

2.4.1 Overall mechanism

In the distributed transaction framework defined by Seata, using transaction resources (database, message service, etc.) to support XA protocol, a transaction mode to manage branch transactions by XA protocol mechanism.

  • ** Execution stage: ** The business SQL is executed in the XA branch, managed by the RM manager of the branch transaction, and then XA Prepare is executed.

  • ** Completion phase: **TM informs all branches to perform XA COMMIT or XA rollback through TCS based on the execution results of each branch.

2.4.2 characteristics

  • ** Advantages: ** inherits the advantages of the XA protocol and has strong transaction consistency.

  • ** Disadvantages: ** also inherits XA protocol disadvantages, because branch transactions are open for a long time, the concurrency is low.

2.5 Comparison of Seata modes

Distributed transaction schemes have no silver bullet and choose the appropriate pattern according to their business characteristics. For example, in pursuit of strong consistency, you can choose AT and XA, have docking with external systems, choose Saga mode, can not rely on local transactions, can use TCC and so on. Combine the advantages and disadvantages of each mode to select.

4. Core implementation of AT mode

Considering that Seata supports many patterns and its default pattern is AT, to save space, the core module implementation related to AT pattern is analyzed below.

1. Startup of the transaction coordinator

The TC (Transaction Coordinator) is started as a separate service that acts as a Server, maintains the state of global and branch transactions, and drives global transaction commit or rollback. The following is the TC startup process:

2. Start the transaction manager

The TM (Transaction Manager) integration is started in the application and is responsible for defining the scope of global transactions, starting transactions, committing transactions, and rolling back transactions. Applications need to configure the TM is GlobalTransactionScannerbean in application startup when the initialization process as follows:

3. Start the resource manager

The RM (Resource manager) integration is started in the application. It manages resources on branch transactions, registers branch transactions with TCS, reports the status of branch transactions, and drives the submission or rollback of branch transactions. In the application where RM resides, you need to configure GlobalTransactionScanner to start RMClient, and configure DataSourceProxy to access the data source. The data source agent implements SQL parsing → generating undo-log → local submission of business SQL and undo-log.

4. Workflow of global transactions

Here is a simple example to illustrate how global transactions work:

  • ** Initiate purchase service

  • **StorageService: ** Inventory management service

The purchase operation is implemented in BusinessService. purchase. The purchase method is implemented on the GlobalTransaction annotation via the Dubbo service and invokes the inventory service deduct method method as shown in the following example:

@GlobalTransactional(timeoutMills = 300000, name = "dubbo-demo-tx")
public void purchase(String userId, String commodityCode, int orderCount) {
    storageService.deduct(commodityCode, orderCount);
    // throw new RuntimeException("xxx");
}
Copy the code

4.1 Successful global transaction process

4.2 Successful global transaction process

After the BusinessService successfully calls the StorageService, a local exception occurs.

5. Write isolation implementation

If the global transaction has not committed but the branch transaction has committed locally (assuming that resource A has been modified), how to prevent other transactions from modifying resource A at this time? Seata is implemented using global locking, which flows as follows:

6. Read isolation implementation

Based on the database local isolation level of read committed or above, Seata provides read uncommitted, which makes sense because branch transactions are committed locally before global transactions are committed. If you want to implement read commit, add for update to the SELECT statement.

Five, the summary

Seata is a powerful distributed transaction framework in the Java world that supports multiple patterns. The DEFAULT AT mode, compared with the traditional 2PC protocol (database based XA protocol), solves the problem of long-term resource lock by 2PC and improves the concurrency. Among the patterns supported by Seata, the AT pattern implements distributed transactions with zero business intrusion and is more developer-friendly. In addition, Seata servers can adopt cluster mode when selecting proper storage media to reduce the impact of single points of failure.

This article mainly refers to the official website and part of the blog, AT the same time to read the implementation of the source code, if there is a wrong place, please point out, discuss and exchange.

Six, reference

  • Seata’s Saga mode

  • Generate the proxy class according to the GlobalTransactional annotation

  • Seata project address

  • Use Seata

Author: Development team of Vivo official website mall