preface

1. Seata overview

Seata is short for Simple Extensible Autonomous Transaction Architecture, renamed feasCAR.

Seata is ali open source distributed transaction framework, which belongs to two-phase commit mode.

Github currently has 12,267 stars and is very active, with many of the latest submissions coming in a few days ago.

Let’s first review that in a singleton application, for example, a business calls three modules, all of which use the same data source and rely on local transactions to ensure transaction consistency.

Distributed interview address: gold, silver, four questions summary collection

However, in the microservice architecture, these three modules will become three independent microservices, each with its own data source, and the call logic will become:

How does Seata handle this?

Business is a Business entry that is annotated in the application to indicate that it is a global transaction, in which case its role is TM (transaction manager).

Business asks the TC (transaction Coordinator, a standalone service) to start a global transaction, and the TC generates a global transaction ID (XID) and returns it to Business.

After Business gets the XID, it starts calling microservices, such as Storage.

(Same as the above image, easy to view, in case you can’t see the above image when you roll here)

The Storage receives the XID and knows that its transaction belongs to this global transaction. Storage Executes its own service logic and operates the local database.

The Storage registers its transaction with the TC as a branch transaction under the XID and tells the TC the result of its transaction execution.

In this case, the role of the Storage is RM (resource manager). The resource refers to the local database.

The execution logic of Order and Account is the same as that of Storage.

After each microservice is executed, TC can know the execution result of each branch transaction under XID, and TM (Business) can also know.

If Business finds that the local transactions of each microservice are successfully executed, it requests the TC to commit to the XID, otherwise it will be rolled back.

After receiving the request, the TC sends the request to all branch transactions under the XID.

After receiving TC’s request, each micro service executes the corresponding instruction and reports the execution result to TC.

Important mechanism

(1) How is the rollback of global transactions implemented?

Seata has an important mechanism: rollback logs.

Each branch transaction requires a rollback log table UNDO_LOG in the database. Before modifying the database record, the value of the record before modification is recorded for later rollback.

After the rollback request is received, it is executed according to the SQL statement that UNDO_LOG generates the rollback operation.

If a commit request is received, the corresponding record in UNDO_LOG is deleted.

(2) How does RM automatically interact with TC?

JDBC interception is implemented by monitoring. For example, if a local transaction is monitored, the SYSTEM automatically registers with the TC, generates rollback logs, and reports the execution result to the TC.

(3) What if phase-2 rollback fails?

For example, when the TC command is rolled back, if one microservice fails, all normal microservices will not be rolled back. After the microservice runs properly again, the TC will perform global rollback again.

1.3 Core Components

To review the core components:

  • Transaction coordinator TC

Maintains the status of global and branch transactions, indicating global commit or rollback.

  • Transaction Manager TM

Start, commit, or roll back a global transaction.

  • Resource Manager RM

Manage the resources that execute branch transactions, register branch transactions with TCS, report branch transaction status, and control the commit or rollback of branch transactions.

1.4 Specific working process

Let’s review the working process of Seata from a macro perspective:

  • TM requests TC to start a new global transaction, for which TC generates an XID.
  • The XID is passed through the invocation chain of the microservice to other microservices.
  • RM registers the local transaction with the TC as a branch transaction of this XID.
  • TM requests TC to commit or roll back this XID.
  • TC directs all branch transactions under this XID to commit and roll back.

2. Seata detailed workflow examples

Let’s take a look at the Seata workflow through the execution of a branch transaction.

For example, if there is a business table product(ID,name), branch transaction business logic:

update product set name = 'GTS' where name = 'TXC';
Copy the code

2.1 one phase

(1) Parse SQL

Get SQL type (UPDATE), table (product), condition (where name = ‘TXC’), etc.

(2) Query the former mirror

According to the condition information obtained from the analysis, query statements are generated to locate the data.

select id, name from product where name = 'TXC';
Copy the code

Get the front image:

(3) Execute business SQL

Execute your own business logic:

update product set name = 'GTS' where name = 'TXC';
Copy the code

Change the name to GTS.

(4) Mirroring after query

Based on the result of the front mirror, the data is located by the primary key.

select id, name from product where id = 1;
Copy the code

After obtaining the mirror image:

(5) Insert rollback logs

Insert a rollback log record into the UNDO_LOG table composed of front and back mirror data and business SQL related information.

(6) Before submission, register branch with TC: Apply for global lock of records in product table whose primary key value is equal to 1.

(7) Local transaction submission: the update of business data is submitted together with the UNDO LOG generated in the previous steps.

(8) Report the result of local transaction submission to TC.

2.2 Phase 2: Rollback

(1) After receiving the branch rollback request from the TC, start a local transaction and perform the following operations:

(2) Find the corresponding UNDO LOG based on the XID and Branch ID.

(3) Data verification

Compare the mirror in the UNDO LOG with the current data and determine whether to roll back based on the verification result.

(4) Generate and execute the rollback statement according to the former mirror and service SQL information in UNDO LOG:

update product set name = 'TXC' where id = 1;
Copy the code

(5) Submit local transactions

In addition, the execution result of the local transaction (that is, the rollback result of the branch transaction) is reported to the TC.

Phase two – Commit

(1) After receiving TC’s branch submission request, put the request into an asynchronous task queue and immediately return the result of successful submission to TC.

(2) The branch submission request in the asynchronous task stage will delete the corresponding UNDO LOG records asynchronously and in batches.

3. Summary

The ABOVE is Seata’s AT pattern, which is to automate transactions and is very simple to use and non-intrusive to business code.

The deficiency is that the current document is less, the relevant materials on the Internet is not a lot, so the use of problems may need to view the source code, analysis principle.

Seata also supports TCC and Saga modes, but the main mode of support is AT.