Getting to Know Seata (Distributed Transaction Service)

Seata overview

Download Seata

Releases · set/set · GitHub

https://github.com/seata/seata/releases/download/v1.4.2/seata-server-1.4.2.zip

What is Seata

Seata is an open source distributed transaction solution, dedicated to providing high-performance and easy-to-use distributed transaction services under the microservice architecture

It is also a component provided by Spring Cloud Alibaba

Seata Official Documentation

Set

More information can be obtained through the official documentation

Why do you need Seata

We have previously learned about transactions in a single project

The technology used is called Spring declarative transaction

It can ensure that all operations on the database in a business either succeed or fail to ensure the data integrity of the database

But in the microservice project, the business logic layer involves remote calls, the current module is abnormal, and the remote server cannot be rolled back

At this time, if you want to make remote calls also support transaction functions, you need to use the distributed transaction component Seata

Four characteristics of transactions: ACID characteristics

  • atomicity
  • consistency
  • isolation
  • permanent

Seata guarantees the atomicity of microservice remote call business

Seata will provide users with AT, TCC, SAGA and XA transaction modes to create a one-stop distributed solution for users.

The operating principle of Seata (AT mode)

Observe the following transaction model

The above structure is a typical remote call structure

If the account fails to operate the database, the order module and the storage module need to undo (roll back) the operation

Declarative transactions cannot complete this operation

Need to use Seata to solve

Seata components include

  • Transaction Coordinator TC
  • Transaction ManagerTM
  • Resource Manager RM

Our project uses AT (automatic) mode to complete the solution of distributed transactions

AT mode operation process

1. The initiator (TM) of the transaction will apply for a global transaction id from the transaction coordinator (TC) and save it

2. Seata will manage the data sources of all relevant participants in the transaction, and save the mirror image before and after the data operation in the undo_log table. This table is the table specified by the seata component. Without it, the effect cannot be achieved. Rely on it to Implement the operation of submitting (commit) or rolling back (roll back)

3. The initiator (TM) of the transaction will run the method in the resource manager (RM) through remote calls together with the global id

4. RM receives the global id, runs the specified method, and sends the status of the running result to TC

5. If all branches are running normally, TC will notify all branches to submit, which will really affect the database content,

On the contrary, if any branch in all branches is abnormal, TC will notify all branches to roll back, and the database data will be restored to the content before running

Introduction to other modes of Seata

In the last class, we explained the operation process of Seata software AT mode

There is a very obvious prerequisite for the operation of AT mode. If this condition is not met, AT mode cannot be used.

This condition is that all transaction branches must operate relational databases (Mysql\MariaDB\Oracle)

Because relational databases only support submission and rollback, other non-relational databases directly affect data (such as Redis)

So if we have a node operating Redis or other non-relational databases in the business process, we cannot use AT mode

In addition to AT mode, there are TCC, SAGA and XA transaction modes

TCC mode

Simply put, the TCC mode is to write code to complete the commit and rollback of the transaction

In the TCC mode, we need to write a set of 3 methods for the business logic involved in the transaction

(prepare\commit\rollback)

prepare: prepare

commit: commit

rollback: rollback

  • The prepare method is the method that every module will run
  • When the prepare method of all modules is running normally, run commit
  • When there is an exception in the prepare method run by any module, run rollback

In this case, all commit or rollback code is written by yourself

Advantages: Although the code is written by yourself, the mechanism for committing or rolling back the transaction as a whole is still available (still scheduled by TC)

Disadvantages: Each business needs to write 3 methods to correspond, the code is redundant, and the amount of business intrusion is large

SAGA mode

The idea of ​​SAGA mode is to write a new class corresponding to each business logic layer, and you can set the code in the newly written class to run when an exception occurs in the specified business logic layer method

It is equivalent to defining the rollback method in the TCC mode in a new class

Writing code in this way does not affect the already written business logic code

Generally used to modify old code that has been written

The disadvantage is that each transaction branch needs to write a class to roll back the business,

It will result in a large number of classes and a large amount of development

XA mode

Database distributed transactions that support the XA protocol, less used

Guess you like

Origin blog.csdn.net/weixin_71583566/article/details/127062620