Distributed Transaction (3) Seata Distributed Transaction Framework-Introduction to AT Mode

Introduction to Seata

Seata is an open source distributed transaction solution dedicated to providing high-performance and easy-to-use distributed transaction services. Seata will provide users with AT, TCC, SAGA and XA transaction modes to create a one-stop distributed solution for users.

In January 2019, the Alibaba middleware team launched the open source project Fescar (Fast & EaSy Commit And Rollback) to build open source distributed transaction solutions with the community. Fescar's vision is to make the use of distributed transactions as simple and efficient as the use of local transactions, and to gradually solve all the problems encountered by developers in distributed transactions.

After Fescar was open sourced, Ant Financial joined the Fescar community to participate in the co-construction, and contributed the TCC mode in Fescar 0.4.0.

In order to create a more neutral, more open, and ecologically richer distributed transaction open source community, after voting by the core members of the community, everyone decided to upgrade the brand of Fescar and renamed it Seata, which means: Simple Extensible Autonomous Transaction Architecture, which is a set One-stop distributed transaction solution.

Seata integrates the accumulation of Alibaba and Ant Financial in distributed transaction technology, and has accumulated rich practical experience in new retail, cloud computing and new finance scenarios, but it must realize the vision that is applicable to all distributed transaction scenarios , There is still a long way to go.

 

Seata AT transaction solution

Seata's AT mode (Automatic Transaction) is a non-intrusive distributed transaction solution. Let's analyze the principle of its execution in combination with specific business scenarios.

Business scene

Order system

When a user places an order, the following three-step process is performed:

1. The order system saves the order
2. The order system calls inventory services to reduce commodity inventory
3. The order system calls the account service to deduct the user's amount

These three steps must be managed as a whole business, either overall success or overall failure.

Basic Principles of Seata AT

The Seata AT transaction is divided into two stages to manage the global transaction: the
first stage:  execute each branch transaction and the
second stage:  control the final commit or rollback of the global transaction

 

The first stage: execute each branch transaction

In the microservice system, each service cannot perceive whether the transaction is successfully executed or not. At this time, a special service is needed to coordinate the running status of each service. This service is called TC (Transaction Coordinator), the transaction coordinator.

Before the order system starts to execute the save order, first start the TM (Transaction Manager), and the TM applies to the TC to start a global transaction:

At this time, TC will generate a global transaction ID , called  XID , and pass the XID back to TM:

This starts the global transaction !

After the global transaction is opened, the business of creating an order is executed. First execute the save order, then an RM (Resource Manager) will be started first, and the XID will be passed to the RM.

RM is responsible for managing branch transactions (that is, local transactions of microservices), communicating with TC, reporting the execution status of branch transactions, and receiving commit or rollback instructions for global transactions.

RM will first use XID to register branch transactions with TC, and bring the branch transactions into the jurisdiction of the corresponding global transactions.

Now you can execute the branch transaction that saves the order. Once the branch transaction is executed successfully, RM will report the transaction status:

After TC receives it, it will pass the status information to TM:

At this point, the process of saving the order is over. The following is to call the inventory service to reduce the inventory of the goods, which is the same as the execution process of the order.

First call the inventory service, start RM, and pass the XID:

The RM of the inventory service uses XID to register with the TC, and it is included in the global affairs:

After the local transaction is successfully executed, the status is reported, and the TC will send the status to TM:

Similarly, complete the account branch transaction:

The second stage: control the final commit of the global transaction

Now, TM (Global Transaction Manager) has collected the success status of all branch transactions, it will make a decision to determine the success of the global transaction, and send the commit request of the global transaction to the TC:

Then, TC will send a commit operation instruction to all RMs, and RM will complete the final commit operation:

The second stage: control the final rollback of the global transaction

The above is the case of successful execution of the global transaction, let's take a look at the case of failed transaction execution.

Assuming that during the execution of the order business, the branch transaction of deducting the account amount fails, the failure status is reported to the TC, and then sent to the TM:

TM will make a decision, determine that the global transaction has failed , and send a rollback request of the global transaction to TC :

Then, TC will send a rollback operation instruction to all RMs, and RM will complete the final rollback operation:

The specific working mechanism of Seata AT

I have understood the basic principles and workflow of Seata AT above, so how does Seata specifically implement the commit and rollback operations of global transactions? Let's analyze the specific working mechanism of Seata.

 

The first stage: execute branch transaction

Take the inventory service in the comprehensive order business as an example, there is a piece of inventory information in the inventory table:

Now we have to perform business operations to reduce inventory, from 50 to 40 pieces:

Before performing the inventory modification operation, the old inventory information will be taken out:

Now you can modify the inventory:

Then, take out the updated new data:

Next, the old data and the new data will be merged and saved to a transaction rollback log table: undo_log table:

At this point, the first stage, the branch transaction is completed, and the status is reported to TC:

The second stage: control the final rollback of the global transaction

If the global transaction fails, the branch transaction that has been committed in the first phase must be rolled back.

First, you will receive a global transaction rollback instruction from TC:

Next, according to the record of the transaction rollback log (undo_log) table, restore the product to the old inventory data:

Then delete the transaction log, and finally complete the second phase of the rollback operation:

The second stage: control the final commit of the global transaction

The above is the global transaction rollback operation. If the global transaction is successful, to complete the final submission, the final submission operation in AT mode is very simple, and only the log data needs to be deleted.

First receive the TC's global transaction commit instruction:

Then, delete the transaction log directly, and complete the second stage commit operation: