Shulou(Shulou.com)06/02 Report--

This article introduces the relevant knowledge of "what is the transaction mode of Seata". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

1. What is the XA mode?

Here are two basic pre-concepts:

What is XA?

What is the so-called transaction pattern defined by Seata?

Based on these two points, it is natural to understand the XA pattern.

1.1 what is XA?

The XA specification is a distributed transaction processing (DTP,Distributed Transaction Processing) standard defined by the X/Open organization.

The XA specification describes the interface between global transaction managers and local resource managers. The purpose of the XA specification is to allow multiple resources (such as databases, application servers, message queues, etc.) to be accessed in the same transaction, so that the ACID property remains valid across applications.

The XA specification uses a two-phase commit (2PC last Twilight Commit) to ensure that all resources commit or roll back any particular transaction at the same time.

The XA specification was proposed in the early 1990s. At present, almost all major databases provide support for the XA specification.

1.2 what is the transaction mode of Seata?

Seata defines the framework for global transactions.

A global transaction is defined as the overall coordination of several branch transactions:

TM initiates (Begin), commits (Commit), and Rollback (Rollback) global transactions to the TC request.

TM binds the XID that represents the global transaction to the branch transaction.

RM registers with TC to associate the branch transaction with the global transaction represented by XID.

RM reports the execution result of the branch transaction to TC. (optional)

TC sends a branch commit (Branch Commit) or branch rollback (Branch Rollback) command to RM.

The global transaction process of Seata is divided into two phases:

Execution phase: execute branch transactions and ensure that the execution results are Rollbackable and Durable.

Completion phase: according to the resolution formed by the result of the execution phase, the request for global commit or rollback issued through TM is applied to the TC,TC command RM to drive branch transactions for Commit or Rollback.

The so-called transaction mode of Seata refers to the behavior mode of branch transactions running under the framework of Seata global transactions. To be exact, it should be called branch transaction mode.

The difference between different transaction modes is that branch transactions use different ways to achieve the goal of the two phases of the global transaction. That is, answer the following two questions:

Execution phase: how to execute and ensure that the execution results are Rollbackable and Durable.

Completion phase: how to commit or roll back the branch after receiving the command from TC?

Take our Seata AT pattern and TCC pattern as examples to understand:

AT mode

Execution phase:

Rollback: record the rollback log based on the SQL parsing result

Persistence: rollback logs and business SQL commit to the database in the same local transaction

Completion phase:

Branch submission: asynchronously delete rollback log records

Branch rollback: reverse compensation updates based on the rollback log

TCC mode

Execution phase:

Call the Try method of the business definition (rollback and persistence are guaranteed entirely at the business level)

Completion phase:

Branch commit: call the Confirm method defined by each transaction branch

Branch rollback: call the Cancel method defined by each transaction branch

1.3 what is the XA mode of Seata?

XA mode:

Within the distributed transaction framework defined by Seata, a transaction mode that uses transaction resources (database, message service, etc.) to support XA protocol and uses the mechanism of XA protocol to manage branch transactions.

Execution phase:

Rollback: the business SQL operation is carried out in the XA branch, and the rollback is guaranteed by the resource's support for XA protocol

Persistence: after the XA branch is completed, the XA prepare is executed, and again, persistence is guaranteed by the resource's support for the XA protocol (that is, any subsequent accidents do not cause a situation that cannot be rolled back)

Completion phase:

Branch submission: commit that executes the XA branch

Branch rollback: execute the rollback of the XA branch

two。 Why is XA supported?

Why add XA mode to Seata? What is the point of supporting XA?

2.1 the problem of compensatory transaction mode

In essence, the three transaction modes already supported by Seata: AT, TCC, and Saga are all compensatory.

The compensated transaction mechanism is built on the transaction resource (either at the middleware level or at the application level), and the transaction resource itself is not aware of the distributed transaction.

There is a fundamental problem that transaction resources do not perceive distributed transactions: it is impossible to achieve true global consistency.

For example, an inventory record, during a compensatory transaction, is deducted from 100 to 50. At this point, the warehouse administrator connects to the database, queries the statistical inventory, and sees the current 50. After that, the inventory will be compensated and rolled back to 100 because the transaction is rolled back. Obviously, 50% of the statistics obtained by the warehouse administrator are dirty data.

It can be seen that the compensated distributed transaction mechanism cannot guarantee data consistency from a global perspective outside the transaction framework because it does not require the participation of the transaction resource itself (such as the database).

2.2 the value of XA

Unlike the compensation type, the XA protocol requires the transaction resources themselves to provide support for specifications and protocols.

Because transaction resources are aware of and participate in distributed transaction processing, transaction resources (such as databases) can ensure effective isolation of data access from any perspective and meet global data consistency.

For example, in the inventory update scenario mentioned in the previous section, during the XA transaction, 50% of the intermediate data inventory is guaranteed by the database itself and will not be seen by the warehouse administrator's query statistics. (of course, the isolation level needs to read the submitted above)

In addition to the fundamental value of global consistency, there are several benefits to supporting XA:

Business non-intrusive: like AT, the XA pattern will be business-free and will not impose additional burden on application design and development.

Database support is extensive: the XA protocol is widely supported by mainstream relational databases and can be used without additional adaptation.

Multilingual support is easy: because it does not involve SQL parsing, XA patterns require less RM of Seata, and developing SDK for different languages will be thinner and easier than AT schemas.

Migration of traditional XA-based applications: traditional, XA-based applications migrate to the Seata platform, using XA mode will be smoother.

2.3 issues widely questioned by XA

There is no distributed transaction mechanism that can perfectly adapt to all scenarios and meet all requirements.

XA specification was proposed as early as the early 1990s to solve the problems in the field of distributed transaction processing.

Now, no matter AT pattern, TCC pattern or Saga pattern, these patterns are essentially derived from the inability of the XA specification to meet the requirements of some scenarios.

There are some widely questioned problems in the distributed transaction processing mechanism defined by XA specification. How do we think about these problems?

1. Data locking: data is locked before the end of the entire transaction, and reads and writes are constrained by the definition of the isolation level.

Think about:

Data locking is the price to pay for greater isolation and global consistency.

The compensated transaction mechanism completes the commit of branch (local) transactions in the execution phase and does not lock the data (at the resource level). And this is at the expense of isolation.

In addition, AT mode uses global locks to ensure basic write isolation, which actually locks data, but locks are managed centrally on the TC side, resulting in high unlocking efficiency and no blocking problems.

two。 Protocol blocking: after XA prepare, the branch transaction enters the blocking phase and must block and wait before receiving the XA commit or XA rollback.

Think about:

The blocking mechanism of the protocol itself is not a problem, the key problem is that the protocol blocking encounters data locking.

If a resource participating in a global transaction is "lost" (unable to receive the command to end the branch transaction), the data it locks will always be locked. In turn, it may even lead to deadlocks.

This is not only the core pain point of XA protocol, but also the key problem to be solved when Seata introduces XA mode.

The basic idea is two aspects: avoiding "loss of contact" and adding "self-unlocking" mechanism. (there are a lot of technical details involved here, which will not be expanded for the time being, but will be specifically discussed in the subsequent evolution of the XA pattern.)

3. Poor performance: the loss of performance mainly comes from two aspects: on the one hand, the transaction coordination process increases the RT; of a single transaction, on the other hand, lock conflicts of concurrent transaction data reduce throughput.

Think about:

There is no doubt that performance is degraded compared to run scenarios that do not use distributed transaction support.

In essence, the transaction (whether local or distributed transaction) mechanism is to sacrifice part of the performance in exchange for the simplicity of the programming model.

Compared with the non-invasive AT model of the same business:

First, because it also runs under the distributed transaction framework defined by Seata, the XA pattern does not generate more communication overhead for transaction coordination.

Second, lock conflicts occur between concurrent transactions if there are hot spots in the data, which also exists in AT mode (global locks are used by default).

Therefore, in the two main aspects that affect performance, the XA mode does not have a very obvious disadvantage over the AT mode.

The performance advantage of AT mode mainly lies in the centralized management of global data locks, the release of locks does not need the participation of RM, and the release of locks is very fast; in addition, the global committed transactions are asynchronized in the completion phase.

3. How to implement and use the XA pattern?

3.1Design of XA pattern

3.1.1 Design objectives

There are two main aspects of the basic design goals of the XA pattern:

From the scenario, it meets the requirements of global consistency.

In terms of application, it is consistent with the AT mode without invasion.

In terms of mechanism, it adapts to the characteristics of distributed micro-service architecture.

Overall thinking:

Same as the AT pattern: build branch transactions to the XA pattern at the granularity of local transactions in the application.

Through the data source agent, outside the scope of the local transaction of the application, the interaction mechanism of the XA protocol is packaged at the framework level to make the XA programming model transparent.

The 2PC of XA is taken apart, and XA prepare is carried out at the end of the branch transaction execution phase, which perfectly integrates the XA protocol into the transaction framework of Seata, reducing a round of RPC interaction.

3.1.2 Core Design

1. Overall operation mechanism

The XA mode runs within the transaction framework defined by Seata:

Execution phase (E xecute):

XA start/XA end/XA prepare + SQL + Registration Branch

Completion phase (F inish):

XA commit/XA rollback

two。 Data source agent

XAConnection is required for XA mode.

There are two ways to obtain XAConnection:

Method 1: require developers to configure XADataSource

Method 2: create according to the developer's normal DataSource

The first approach, which adds a cognitive burden to developers, needs to specifically learn and use XA data sources for XA patterns, which runs counter to the design goal of a transparent XA programming model.

The second way is more developer-friendly, like the AT model, developers do not have to care about any problems at the XA level, just keep the local programming model.

We give priority to the design and implementation of the second way: the data source agent creates the corresponding XAConnection based on the ordinary JDBC connection obtained from the ordinary data source.

The data source proxy mechanism of the AT schema is analogous as follows:

However, the second method has its limitations: the correctness of compatibility cannot be guaranteed.

In fact, this approach is doing what the database driver does. Different vendors and different versions of the database driver implementation mechanism are private to the manufacturer, we can only ensure that the fully tested driver is correct, and the difference in the driver version used by developers is likely to cause the failure of the mechanism.

This is evident on Oracle.

Considering comprehensively, the data source agent design of XA pattern needs to support the first way: proxy based on XA data source.

The data source proxy mechanism of the AT schema is analogous as follows:

3. Branch registration

XA start requires a Xid parameter.

This Xid needs to be associated with the XID and BranchId of the Seata global transaction so that TC drives the commit or rollback of the XA branch.

At present, the BranchId of Seata is uniformly generated by TC during the branch registration process, so the time for branch registration of XA mode needs to be before XA start.

A possible optimization direction in the future:

Postpone branch registration as much as possible. Similar to the AT pattern, the branch is registered before the local transaction is committed, avoiding meaningless branch registration if the branch fails to execute.

This optimization direction needs to be matched by changes in the BranchId generation mechanism. BranchId is not generated through the branch registration process, but is generated and then registers the branch with BranchId.

Summary

Here are only a few important core designs to illustrate the basic working mechanism of the XA pattern.

In addition, there are important aspects, including connection maintenance, exception handling, and so on, which you can learn more from the project code if you are interested.

In the future, I will write it out one after another to communicate with you.

3.1.3 Evolution Planning

The overall evolution plan of the XA model is as follows:

Step 1 (completed): the first version (1.2.0) runs through the XA pattern prototype mechanism. Make sure you only add, don't modify, and don't introduce new problems to other models.

Step 2 (scheduled to be completed in May): necessary integration and refactoring with the AT model.

Step 3 (scheduled to be completed in July): improve the exception handling mechanism and carry out the necessary polishing for production.

Step 4 (scheduled to be completed in August): performance optimization.

Step 5 (planned to be completed within 2020): build cloud native capabilities with the ongoing Transaction Mesh design for cloud natives in the Seata project.

3.2 use of XA mode

In terms of the programming model, the XA pattern is exactly the same as the AT pattern.

You can refer to the example of Seata's official website: seata-xa

The sample scenario is a classic Seata scenario, which involves the ordering business of three micro-services: inventory, order and account.

In the sample, the upper programming model is exactly the same as the AT pattern. You only need to modify the data source agent to switch between XA mode and AT mode.

@ Bean ("dataSourceProxy") public DataSource dataSource (DruidDataSource druidDataSource) {/ / DataSourceProxy for AT mode / / return new DataSourceProxy (druidDataSource); / / DataSourceProxyXA for XA mode return new DataSourceProxyXA (druidDataSource);} "what is the transaction mode of Seata". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.