The design concept of Seata's strong consistency transaction mode XA

Undertake the above distributed transaction Seata-AT mode

XA规范是什么?

  • It is the standard of Distributed Transaction Processing (DTP).
  • It is a specification describing the interface between the global transaction manager and the local resource manager.
  • Allow multiple resources (such as databases, application services, message queues) to be accessed in the same transaction, keeping ACID properties in order across applications.
  • In essence, it can be understood as 2PC, using the 2PC protocol to ensure that all resources commit or roll back specific transactions at the same time.
  • The database itself supports local transaction ACID, and XA allows ACID to be applied outside the library.

DTP模式定义的几个角色?

  • AP application
  • RM resource manager, transaction participants, specific data sources corresponding to microservices one by one.
  • TM Transaction Manager, which manages the entire transaction lifecycle and coordinates the various RMs.

  • AP applications, such as order service, inventory service.
  • The RM resource manager can be understood as a database mysql, the application connects through JDBC, and the AP controls resources through RM, and the resources must implement the interface defined by XA.
  • The TM transaction manager is responsible for assigning a unique identifier for a transaction, monitoring the execution progress of a transaction, and responsible for committing or rolling back a transaction.

TM is generally embedded in the application program. For example, AP holds two data sources of order library and product library. The application program notifies the order library and product library through TM to create orders and deduct inventory. The specific two RMs are The transaction is not committed, the data is locked, and it has not been committed yet, so the commodity and order resources are locked at this time.

In fact, RM proxies the previous database submission operation, and RM tells TM that I am ready.

Both RMs send to TM to say that I am ready, and TM receives notifications from all RMs, and then TM sends the next command to notify all RMs to make a real submission, and then release resources, that is, the two RMs release the locks respectively .

In fact, this mode is 2PC. AT mode has an undolog for recording the previous data, and XA mode has no undolog.

XA模式的核心

If an RM resource participating in the global transaction loses connection and cannot receive the end command of the branch transaction, the data locked by it will be locked forever, and deadlock may occur. This is the core problem to be solved by the XA protocol. It is also the problem that Seata introduces the XA mode to solve.

The essence of the XA specification is 2PC, which uses the CRUD of the database itself for proxying.

Seata事务模式的原型

DTP mode includes AP, RM, TM.

Seata XA mode includes TC transaction coordinator, TM transaction manager, RM resource manager, and TC is defined by Seata itself.

Seata defines a global transaction framework, and a global transaction can be defined as the overall coordination of several branch transactions.

TM starts the global transaction, is responsible for the global commit or rollback request to TC, and TM will create the xid of the global transaction.

TM如何把分支的事务定义在一个全局事务中的?

Specify a unified id for the specific branch transactions in the entire global transaction. For example, the xid of the current RM transaction participant is 1, and the xid of the other RM is also 1, which means that the two RMs are in a global transaction.

TM creates an xid to specify which branch transactions belong to the current global transaction.

TM initiates a request to TC to commit or roll back the global transaction, and binds the global transaction id to the branch transaction, which means it is in a global transaction.

The specific RM needs to register with the TC, tell the TC my current execution status, whether it succeeds or fails, and then the TC tells the RM whether to commit or roll back. This is the entire Seata XA transaction mode.

Seata XA transaction mode is also 2PC mode,

  • Execution phase: Execute branch transactions and guarantee the execution results and satisfy rollback and persistence
  • Completion phase: TM forms a decision based on the results of the execution phase. The application initiates a global commit or rollback request to TC through TM, and TC instructs RM to drive branch transactions to commit or roll back.

回顾AT事务模式

AT mode is a variant of 2PC. TM commits and rolls back global transactions. TM adds xid to specific branch transactions to tell that the current branch transaction belongs to this global transaction. This part of AT and XA are the same.

AT mode parses sql statements, so in the first stage (execution stage), parse the current sql results and record the undolog log.

First, the RM branch transaction is registered in the TC, and the TC is told whether the execution result of the current branch transaction is yes or no.

In the end, the TC tells the branch transaction that whoever fails needs to roll back. The undolog is used in the rollback, and the reverse compensation update is performed according to the data before the modification recorded in the undolog. This is the second stage. If they are all yes, submit as a whole. TM is responsible for global transaction opening, committing, and rollback operations, and TC tells specific branch transactions whether to commit or rollback.

1. Implementation phase

  • Rollback: According to the sql analysis result, record the rollback log undolog
  • Persistence: log records to the database

2. Completion stage

  • Asynchronously delete the rollback log when submitting
  • When rolling back, reverse compensation according to the rollback log

Seata XA模式

The Seata XA mode is a mechanism that integrates the XA protocol into Seata. Within the distributed transaction architecture defined by Seata, it uses the XA support of databases and message services to manage distributed transactions through the mechanism of the XA protocol.

Seata XA, AT, SAGA, and TCC all follow the entire Seata transaction mode.

The XA mode is turned on, sql is executed, and the XA mode ends. This is the preparation phase of XA, and the second phase is XA committing or rolling back.

The difference between Seata's XA mode and AT is that XA has no undolog.

AT records undolog, and reverse compensation according to undolog to achieve final consistency.

XA is strongly consistent, enforced by ACID of the database, and has no intermediate state.

There is an intermediate state in the eventual consistency, and there is no intermediate state in XA, and XA is strongly consistent.

The first stage is the execution stage, which guarantees rollback and persistence. After the XA mode parses the SQL, it tells the TC the current execution status of each branch transaction, and the TC decides whether to commit or roll back.

Replace AT with XA, the entire Seata's distributed transaction framework remains unchanged, except that AT becomes XA with strong consistency.

Rollback refers to the execution of business SQL in the XA branch, and the database resource supports the XA protocol to ensure rollback, that is, it relies on the transaction ACID of the data source to perform rollback.

Persistence means that after the execution of the XA branch is completed, that is, after the XA start and end are completed, the database resources are used for persistence, which can ensure that any accidents will not cause the situation that cannot be rolled back, thus solving the core pain point of the XA protocol.

Both mysql and oracle support the XA protocol and local transactions, which can guarantee data persistence under any circumstances.

XA的价值

Seata already supports three major transaction modes AT, SAGA, and TCC, why should it support XA?

These three are compensation types, and there are intermediate states.

Models built on transactional resources are either implemented at the middleware level or at the application level. Transactional resources themselves are unaware of distributed transactions.

The so-called transaction resources are local transactions. Local transactions are unaware of branch transactions and cannot achieve true global consistency, that is, there is an intermediate state.

For example, an inventory is currently 100, 50 is deducted, and 50 is left. The warehouse manager connects to the database to check the current result and reads 50. Due to a problem with the current transaction, it is rolled back, and 50 is rolled back to 100.

When the warehouse administrator reads 50, a dirty read occurs. The so-called dirty data is an intermediate state. The administrator can connect to the database again to get the data after the rollback. Data 50 is the intermediate state, and 100 is the final consistent state.

AT mode: After the order is placed, 100 inventory deducts 1 and there are 99 remaining. The order creation fails and the entire global rollback is required. The previous value of 100 will be recorded in the undolog, but during the transaction execution process, there will be 99 state. If the inventory is reduced by 1, the order is not actually created. At this time, when the inventory is read, it is indeed 99. This 99 is the so-called intermediate state, and this is dirty reading.

AT, SAGA, and TCC are all compensation types, and dirty reads will occur. Of course, Seata itself has preventive measures, but these problems do exist: dirty data may be obtained, and final consistency allows intermediate states. It also explains why Seata supports XA, because XA is strongly consistent.

XA has no undolog logs and does not expose intermediate states.

Different from the compensation type, the transaction resource itself provides support for the XA specification and protocol, and the transaction resource perceives and participates in the process of distributed transaction processing.

Data resources (databases) can ensure that database access from any perspective can be effectively isolated and meet the consistency of global transactions.

The compensation-type transaction model will have an intermediate state, and XA is needed when strong consistency is desired.

XA is guaranteed by the database itself, and there will be no situation where the warehouse administrator queries to see the intermediate state, which is guaranteed by the local transaction isolation.

In addition to the advantages of strong consistency, there are no business intrusion, extensive database support, multi-language support, no SQL parsing involved, XA mode has relatively few RM requirements for Seata, and traditional XA mode applications can be smoothly migrated to the Seata platform advantage.

System design constraints such as consistency, reliability, usability, and performance require different transaction processing mechanisms to complete. Seata provides a standardized platform for comprehensively solving distributed transaction problems.

Those without business intrusion include AT and XA, and those with business intrusion include TCC and SAGA. The addition of XA mode complements Seata's gap in global consistency.

Guess you like

Origin blog.csdn.net/qq_16485855/article/details/130305341