Author: ptti

Source: Hang Seng LIGHT Cloud Community

With the introduction to SeATA and seata-Service deployment and validation, we have set up seata-Service and performed simple validation. We know that SEATA defines three roles, TC, TM, and RM

The general process can be seen as follows:

  • 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.

AT pattern is a non-intrusive distributed transaction solution. In AT mode, users only need to focus on their own “business SQL” as a phase, and Seata framework will automatically generate two-phase commit and rollback operations for transactions. You can refer to the official SEATA documentation for a brief technical introduction to the AT pattern.

SEATA. IO/useful – cn/docs /…

We summarize the following characteristics of the AT pattern, which is based on the evolution of the two-phase transaction commit protocol. It ensures atomicity of transactions in a distributed environment by rolling back transactions transparently (non-intrusive) through a proxy to JDBC access, and improves design in the following areas:

  • The business database saves certain transaction state and reduces communication overhead.
  • Asynchronize the commit action; The throughput of the system is improved to better allocate resources.

Detailed execution steps:

A phase

1, first parse SQL statement, get table name, condition, SQL type, and other information 2, get the front mirror: according to the condition information obtained by parsing, generate query statement, locate the data. 4. Mirroring after query: Locate data by primary key based on the result of the former mirroring. 5. Insert rollback log: Create a rollback log record of mirror data and service SQL information and insert it into the UNDO_LOG table. 6. Before submission, register branch with TC: apply for a global lock whose primary key is equal to the primary key value of target data. 7. Local transaction submission: The service data is updated and the UNDO LOG generated in the previous step is submitted together.

Phase two – Commit

9. After receiving the branch submission request from TC, put the request into an asynchronous task queue and immediately return the result of successful submission to TC. 10. Branch submission requests in the asynchronous task phase will asynchronously and batch delete corresponding UNDO LOG records.

Phase 2 – Rollback

9. After receiving the branch rollback request from the TC, start a local transaction and perform the following operations: 10. Find the UNDO LOG based on the XID and Branch ID. 11. Data verification: Compare the mirror in UNDO LOG with the current data. If there is a difference, it indicates that the data was modified by an action other than the current global transaction. In this case, you need to handle it according to the configuration policy, which is detailed in another document. Generate and execute the rollback statement based on the UNDO LOG information about the former mirror and the service SQL. In addition, the execution result of the local transaction (that is, the rollback result of the branch transaction) is reported to the TC.

From the above steps, we can see the advantages over traditional XA(2PC) :

These are also disadvantages of the XA protocol (traditional 2PC)

Faster:

Phase two is an asynchronous commit that does not require XA to wait until all operations are completed before committing. The so-called two-phase asynchronous commit of a branch transaction is the asynchronous deletion of undoLog. Because local transactions have already been committed in phase one, phase two is very fast.

High availability:

It has coordinators independently deployed in distributed transactions and can be highly available (multiple SEATA services can be turned on)

Dirty reads do not occur:

Because the global lock is held by itself until the end of the current global transaction, dirty writes do not occur.

Of course, AT mode also has some self-generated problems and considerations, so there are some best practices, which will be discussed in the future.

Want to learn more from the tech gurus? Where are problems encountered during development discussed? How to access the massive resources of fintech?

Hang Seng LIGHT Cloud community, a professional fintech community platform built by Hang Seng Electronics, shares practical technology dry goods, resource data, and fintech industry trends, embracing all financial developers.