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

This article shows you the example analysis of Seata distributed transaction XA and AT, the content is concise and easy to understand, it will definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

Seata is an open source distributed transaction solution with a star of 19200 and a high level of community activity. It is committed to providing high-performance and easy-to-use distributed transaction services under the micro-service architecture.

1. What is the XA mode?

First of all, as brother Xuan said, it is clear at a glance to understand what is XA and what is the transaction mode defined by Seata.

1.1 what is XA

In very official terms

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: 1.TM initiates (Begin), commits (Commit), and rolls back (Rollback) global transactions to TC requests. 2.TM binds the XID that represents the global transaction to the branch transaction. 3.RM registers with TC to associate the branch transaction with the global transaction represented by XID. 4.RM reports the execution result of the branch transaction to TC. (optional) 5.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 stages: execution phase: executing branch transactions and ensuring 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 TC, and TC commands RM to drive branch transactions to 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: the execution phase: how to execute and ensure that the execution results are Rollbackable and Durable. Completion phase: rollback / commit the transaction after receiving the command from TC

two。 So what is the Seata XA mode?

XA mode: within the distributed transaction framework defined by Seata, using transaction resources (database, message service, etc.) to support XA protocol, and using 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 persistence is guaranteed by the resource's support for the XA protocol: after the XA branch is completed, the XA prepare is executed, and similarly, the resource's support for the XA protocol ensures persistence (that is, no later accident will cause a non-rollback) completion phase: branch commit: execute the commit branch rollback of the XA branch: execute the rollback of the XA branch

The following is a picture of the design model of the XA pattern in the transaction mode defined by Seata

2.1 what is the Seata AT (TXC) mode?

Last January, Seata opened up the AT model. AT mode is a non-intrusive distributed transaction solution. In AT mode, users only need to focus on their own "business SQL", and the user's "business SQL" as a phase, the Seata framework will automatically generate two-phase commit and rollback operations of the transaction.

Through the brief introduction, we can find the characteristics of AT mode. We only need to pay attention to our own business sql, which is a distributed transaction mode that does not invade the business. So we should know how he managed not to invade the business?

2.2 how can the AT model be non-intrusive to the business?

The first phase of AT mode

First of all, in the components of Seata, if you want to start distributed transactions, you should add @ GlobalTransactional annotations to your business entry or transaction initiation entry

If you are in AT mode, you should be a data source proxy (automatic proxy is fully supported after seata1.0) and be used by sqlsessionfactroy (or use the proxied data source for direct jdbc operations).

You can find the key asynchronous, the difference from other patterns is the proxy data source, and what is the secret of the proxy data source?

As shown in the figure above, after your data source is proxied, and after being proxied by DataSourceProxy, the sql you executed will be extracted, parsed, saved before the image, and then run the business sql, and then saved after the image, in order to carry out a two-stage rollback operation with subsequent exceptions.

2.3 how does AT mode ensure isolation

First of all, let's get the documents displayed on the official website to describe it more intuitively:

You can find out from the figure above:

Before committing a first-phase local transaction, you need to make sure that you get the global lock first.

Cannot get global lock, cannot commit local transaction.

The attempt to get the global lock is limited to a certain range, which is abandoned, and the local transaction is rolled back, releasing the local lock.

Two global transactions, tx1 and tx2, update the m field of table a with an initial value of 1000.

Tx1 starts first, opens the local transaction, gets the local lock, and updates the operation m = 1000-100,900.

Before the local transaction commits, get the global lock of the record, and the local commit releases the local lock.

Start after tx2, open the local transaction, get the local lock, and update the operation m = 900,100,800.

Before the local transaction commits, try to get the global lock of the record, before the tx1 global commit

The global lock of the record is held by tx1, and tx2 needs to retry to wait for the global lock, such as the timeout of tx2 wait, then tx2 rolls back the local transaction so that it does not generate dirty data.

AT mode two-phase commit

If the second phase is a submission, because the "business SQL" has been submitted to the database in the first phase, the Seata framework only needs to delete the snapshot data and row locks saved in the first phase and complete the data cleaning.

AT mode two-phase rollback

If the second phase is a rollback, Seata needs to roll back the "business SQL" that has been executed in the first phase to restore the business data. The rollback method is to restore business data with "before image". However, dirty writing should be verified before restore. Comparing "database current business data" and "after image", if the two data are exactly the same, there is no dirty writing, and business data can be restored. If there is inconsistency, it means dirty writing. If dirty writing occurs, it needs to be transferred to manual processing.

A complete model diagram of AT in the transaction mode developed by Seata:

3. Why is XA supported?

First of all, we should judge from AT why Seata still supports XA when it has AT mode.

From the perspective: first of all, let's summarize the AT mode. First of all, everything is initiated from TM (not only AT) and the data read and submitted can only be effective in the application (the system developed by the user). The view of resources cannot be done in all aspects, and XA can make resources feel that they are already in a global transaction, and the isolation of resources can be realized by the database itself to meet global consistency.

From the point of view of intrusiveness and database support: business without intrusion is more thorough. For operations with less than 2 services, consistency can be achieved only by using local transactions, while AT requires global locks to ensure isolation, so global transactions need to be enabled for 1 service, single database operation, or n services to ensure isolation. For database support, if AT needs to support databases other than mysql,pgsql,oracle, it needs to be adapted, and the parsing cost of complex sql is higher, the development efficiency is low, and the number of sql supported is small. XA can fully support the sql statement multilingual support of the database. If you have java applications that have used seata xa, then the local database has helped us ensure isolation. Even if the rest of the seata does not support languages and java parallel processing, the data will not be inconsistent.

4. Why does Seata support XA mode?

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

AT mode uses global locks to guarantee basic write isolation, which actually locks data, but locks on the TC side centrally manage the problem of high unlocking efficiency and no blocking, and the XA local database may hold gap locks, resulting in larger lock granularity and locking more innocent data.

Deadlock (protocol blocking): after XA prepare, the branch transaction enters the blocking phase and must block waiting before receiving the XA commit or XA rollback. If there is no reliable coordinator, for example, if the data of the three abc libraries is decided to be committed by the second phase, and the instruction received by ab, the c library dies after receiving the instruction, and the xa transaction is not committed, or the coordinator fails to retry in the second phase, then the uncommitted xa transaction will always hold the lock, resulting in a deadlock

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, the lock conflict of concurrent transaction data reduces throughput. In fact, the main reason is that the above blocking and data locking are caused, because the first phase of xa is not commit, if all phases are commit scenarios, because of the one-phase commit of At mode, the performance of at is better than that of xa, because it is locked on the side of tc and released centrally, and there is no need for multiple libraries to release locks locally.

The relationship between AT and XA

First of all, we should make it clear that both AT and XA take advantage of the transaction features inherent in the database to ensure data consistency and isolation.

For example, AT one-phase commit and two-phase rollback perform local transactions. For example, the first and second phases of XA also take advantage of the transaction characteristics of the database itself.

So should we mine the relationship between AT and XA at the database level?

First of all, at this time, we must find the same, different from the same. AT is the first to bear the brunt. He has an essential item, that is, undolog table, undolog, which must be known to students who believe that they know the database. There are six kinds of logs in the database: redo log (redo log), rollback log (undo log), binary log (binlog), error log (errorlog), slow query log (slow query log), general query log (general log), relay log (relay log)

So what is the undolog of the database for? undolog keeps a version of the data before the transaction, which can be used for rollback and can provide MVCC under multi-version concurrency control.

It can be found that the undolog of the database coincides with the undolog of the seata at mode, so it can be judged that the undolog of the at mode is the undolog in the role of the local transaction, using his principle to achieve the distributed transaction, to ensure the transaction consistency under the distributed transaction.

So when we're done, what about undolog,redolog?

The function of Redolog is to prevent dirty pages from being written to disk at the point of failure, and to redo them according to redo log when the mysql service is restarted, so as to achieve transaction persistence.

So why doesn't the Seata AT mode see the existence of redolog? In fact, it is very simple, this redolog is hidden very deeply, that is, the first phase of AT mode submission, so that the database as our redolog, to ensure that the first phase of the data is accurate.

Do you think of LCN transaction mode at this time? His undolog is guaranteed by the database, without the existence of a redolog. In fact, you don't have to think about LCN transactions. If you change AT to one-phase non-commit, two-phase commit, the front mirror is undolog and the back mirror is redolog, that is to say, AT is actually not at the database level, according to database transaction ideas and implementation principles, to achieve the consistency of distributed transactions.

At this point, the relationship between XA and AT should be clear. To be exact, it should be said that it is the relationship between distributed transactions and database local transactions. It can be said that the shortcomings of XA result in the birth of AT mode, locking on multiple sides (multiple libraries), resource blocking, and poor performance.

And AT is like in order to put the decision-making power of transactions from the database to Seata, self-implementation of sql parsing, self-implementation of undolog (redolog), since we have no way to directly optimize the problems of the database under distributed transactions, then it is better to create a new model, get rid of its dross and take its essence.

The advantages and disadvantages of Seata AT and XA

In fact, the above bits and pieces also mentioned a lot of their respective advantages and disadvantages. Now let's sum up and compare them in three points.

Sql support

Isolation

Invasiveness

Let's start with the first point. As we have summed up above, AT is actually a self-implemented XA transaction, so we can know that AT's sql support is far less than the XA pattern of local transactions. Since AT needs to do sql parsing, then the implementation can only be solved on its own, that is, it depends on the contributors of the Seata community to contribute the solution. This is a long-term key problem. However, there are still many users who choose to rewrite sql to get support for AT transaction mode. XA is undoubtedly a complete victory in sql support.

The second point is isolation. Seata AT mode obtains the primary key id involved by parsing sql to generate row locks, that is, the isolation of AT mode is guaranteed by global locks, the granularity is as fine as row level, and the lock information is stored on the Seata-Server side. The isolation of the XA schema is guaranteed by the local database, and the locks are stored in each local database. Because once the XA mode executes prepare, it can no longer reenter the XA transaction or share locks with other XA transactions. Because the XA protocol, only through XID to start a xa transaction, itself there is no so-called branch transaction theory, its ability is just a XA transaction, that is to say, it only cares about itself. At this time, the students may have questions, why do I see the XA branch transaction in branch_table? In fact, according to the above what is the Seata transaction mode, we can see that the Seata transaction mode is composed of global transactions, branch transactions, and lock information. The branch transaction of XA exists only as a participant, that is to say, this XA branch is defined as a branch transaction in Seata and recorded as branch information, which can also be sent two-phase decision information after downtime. And AT because the lock is self-implemented, compared with XA, I just need to know whether the data involved in the user sql is under the global transaction, and as long as I default, he can use the lock, which solves the problem of reentry. We can conclude that XA isolation is global, while AT isolation is more flexible and relatively global (ensuring that all writes to data are overwritten by Seata transactions). The third point, intrusiveness, through our above information, we can actually find out who is at the bottom and who is less invasive, so there is no doubt that the XA mode supported by the database itself has the least invasion and the lowest cost.

In fact, at this point, you may think that XA mode feels so much better than AT. Although he does not support lock reentry, I can avoid this situation. At this time, I will draw a picture, and you may understand it better.

In the figure above, figure 1 on the right shows the at mode runtime and figure 2 shows the xa mode runtime. Obviously, the performance degradation caused by xa blocking is very serious, especially when you have so many branch transactions that each resource must be released separately by the database of each branch before subsequent transactions can be entered. Although the non-invasion brought by XA is very high, the performance degradation is too great, which led to the birth of AT, and now the acceptance of AT,TCC,SAGA mode is also higher and higher, which also shows the developers' requirements for performance. AT can be seen as a self-developed XA model optimized by the Seata community. The most important feature is that it solves the problem of poor performance of the XA model. TCC two-phase status notification is determined by Seata, which uses full authority to entrust the user, and the performance is only 2 local transactions + a little rpc overhead. SAGA the whole transaction link, the transaction processing is entrusted to the user to arrange, and the performance is completely guaranteed by the user. As the helper of the transaction, Seata records the running status of the global transaction. It can be seen that the more intrusive model, the more optimization points can be behind, and the less invasive, that is, it will be limited, which can only rely on component developers to carry out irregular optimization to ensure performance.

Summary

In the current technological development, the current distributed transaction is to play the role of Dongfeng, a large number of distributed, micro-service, the performance improvement is very obvious, but the lack of a favorable guarantee, I believe Seata is to assume such a role, so that everything is ready. The core values of the Seata project are:

Build a standardized platform to comprehensively solve the problem of distributed transactions.

Based on Seata, the upper application architecture can flexibly choose the appropriate distributed transaction solution according to the needs of the actual scenario.

The above is a sample analysis of Seata distributed transactions XA and AT. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

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.