Shulou(Shulou.com)05/31 Report--

This article introduces how Seata-AT ensures the consistency of distributed transactions. The content is very detailed. Interested friends can use it for reference. I hope it will be helpful to you.

Seata is an open source distributed transaction solution, star up to 18100 million, high community activity, committed to providing high-performance and easy-to-use distributed transaction services in the micro-service architecture, the following will analyze the implementation principle of Seata-AT, so that users have a better understanding of AT mode.

What is the Seata transaction mode?

1. Seata's definition of transaction

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 TC. > TC commands 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 >: rollback / commit the transaction after receiving the command from TC.

two。 How the other two-phase transactions operate under the framework of Seata transactions

1) TCC transaction mode

First, let's look at how TCC transactions are integrated into the Seata transaction framework:

You can find that, in fact, it looks very similar to the transaction framework diagram of Seata, but the difference is that RM is responsible for managing the one-stage try execution and the two-phase confirm/cancel, which is also the Begin (initiated) of the transaction carried out by TM. RM is called by TM and executes the one-phase Try method. When the call link is finished, TM informs TC of the two-phase resolution. At this time, TC executes the two-phase implementation of the RM driver (issuing notification, RM executes confirm/cancel).

2) XA transaction mode

As shown in the figure, the XA mode is actually the bottom layer of Seata that uses the XA interface to deal with it automatically during the first and second stages. For example, in the first phase, the RM of XA creates the XAConnection by proxying the user data source, and starts the XA transaction (XA start) and XA-prepare (in this case, any operation of the XA will be persisted and can be recovered even if the downtime occurs). In the second phase, TC notifies the RM to perform the Commit/Rollback operation of the XA branch.

What is the AT mode?

First of all, let's look at an example.

1. One stage

Business sql:update product set name = 'GTS' where name =' TXC'.

The execution process of the first phase is imperceptible to the user, and the business sql on the user side remains the same, but what happens in the next phase of the AT mode? Next, let's talk about it briefly.

Parse the sql and query to get the previous image: select id, name, since from product where name = 'TXC'.

Execute the business sql.

The data after query execution is mirrored as select id, name, since from product where id = 1.

two。 The second stage

Commit: just delete the transaction-related information (in theory, it's okay not to delete it).

Rollback: the mirror image is rolled back before it is removed.

Through the simple example above, we can find that the AT mode is an automatic compensation transaction, so what exactly does AT do? We will talk about it below.

How does AT ensure the consistency of distributed transactions?

Let's take a look at this picture:

Many people may have doubts about the above picture, but this is actually a schematic diagram of the non-intrusive AT model. First of all, the user enters through the interface and reaches the initiator of the transaction. For the business developer, the initiator entry is just a business interface, which executes the business sql as well as return the response information to the client without any change. Behind it, the user's sql is hosted by the Seata agent, and the Seata-AT mode can perceive all the user's sql and operate on it to ensure consistency.

How does Seata-AT make it non-invasive?

As shown in the figure, when the application starts, Seata will automatically put the user's DataSource agent. Users who are familiar with JDBC operations are actually quite familiar with DataSource. If you get DataSource, you will be able to master the data source connection and do some "small actions" behind your back. At this time, it is also unaware and non-intrusive for users.

After that, the business has a request to come in. When the business sql is executed, the Seata parses the user's sql, extracts the table metadata, generates the pre-image, and then saves the post-image after the execution of the sql by executing the business sql (which will be discussed later). After the row lock is generated, it is carried to the Seata-Server, that is, the TC side, when registering the branch.

So far, the first phase of the operation on the Client side has been completed, with no perception and no intrusion. If you think about it at this time, you will find that there is actually a row lock. What is this row lock for? This is to go on to talk about how Seata-AT ensures transaction isolation in a distributed environment. Here, take the example of the official website.

1. Write isolation

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.

An example is given to illustrate:

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 and wait for the global lock.

Tx1 two-stage global commit to release the global lock. Tx2 gets the global lock and commits the local transaction.

If the two-stage global rollback of tx1, tx1 needs to re-acquire the local lock of the data, update the operation of reverse compensation, and realize the rollback of the branch.

At this point, if tx2 is still waiting for the global lock of the data and holds the local lock, the branch rollback of tx1 will fail. The rollback of the branch will be retried until the global lock such as tx2 times out, the global lock is discarded and the local transaction is rolled back to release the local lock, and the tx1 branch rollback is finally successful.

Because the global lock of the entire process is held by the tx1 until the end of the tx1, the problem of dirty writing does not occur.

At this time, you must have understood the isolation, and I believe you have understood most of the operations at this stage. Next, let's move on to the next stage of analysis.

2. AT mode two-stage processing

As can be seen from the figure above, during the two-phase commit, TC only issues a notice: delete the undoLog recorded in the previous stage, and delete the relevant transaction information, such as row locks, and then allow transactions blocked because of competitive locks to proceed smoothly.

When the second stage is a rollback, more processing should be done.

First of all, when the Client side is told by TC that the second phase is rollback, it will look up the undolog of the corresponding transaction, take out the image, and compare the current data (because SeataAT protects the distributed transaction from the business application level, if the information in the database is directly modified at this time, the row lock of SeataAT does not play an isolated role). If there is a data modification other than the global transaction, it is determined to be dirty. Because Seata cannot perceive how this dirty write occurs, it can only print logs and trigger exception notifications to inform users of the need for human intervention (standard modification of data entry to avoid dirty writing).

If there is no dirty writing, it will be relatively simple. If you take out the pre-mirror, it is well known that the transaction needs to be atomic, either it occurs together or it does not happen at all. At this time, the pre-mirror records the data before it occurs, and after rollback, it achieves the atomic effect similar to that of the local transaction. After the rollback, delete the transaction-related information, such as undolog, row locks. The two-stage rollback is over.

Now that we have introduced the principles and ways of thinking of the first and second phases of the AT pattern, what is AT like under the distributed transaction framework of Seata?

As you can see, AT and other transaction patterns have an extra undolog table in the Seata transaction framework (relative to the intrusion points of other schemas), but beyond that, it is almost zero intrusive for the business, which is why the AT pattern has a wide audience in Seata.

3. The difference between AT mode and other two-stage modes supported by Seata

First of all, it should be understood that so far, there is no one kind of distributed transaction that can satisfy all scenarios.

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.

At present, there are three points to make a comparison:

Data locking

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.

TCC mode has no lock and makes use of the exclusive lock feature of local transaction to reserve resources to perform corresponding operations after the global transaction resolution.

The XA pattern locks the data involved before the end of the entire transaction, and reads and writes are constrained by the definition of the isolation level.

Deadlock (protocol blocking)

After the XA mode prepare (in the old version of the database, the prepare is issued after XA END is needed), the branch transaction enters the blocking phase and must block and wait before receiving the XA commit or XA rollback.

AT can support degradation, because the lock is stored on the TC side. If bug or other problems occur in the Seata, it can be degraded directly, without any impact on the subsequent business call chain.

TCC does not have this problem.

Performance

The loss of performance mainly comes from two aspects: on the one hand, transaction-related processing and coordination process, increasing the RT; of a single transaction, on the other hand, lock conflicts of concurrent transaction data, reducing throughput. In fact, the main reason is the above protocol blocking and data locking.

XA mode does not commit for one phase, and in large concurrency scenarios, locks are stored in multiple resource parties (databases, etc.), which aggravates performance consumption.

The granularity of AT mode lock is fine to the row level (primary key is required), and all transaction locks are stored on the TC side, so the unlocking is efficient and fast.

TCC mode has the best performance, requiring only a little RPC overhead and the performance overhead of two local transactions, but it needs to be in line with the resource reservation scenario and is highly intrusive to the business (requires business developers to divide each interface into three, one try,2 for two-phase confirm and cancel).

Many students may not have a good understanding of XA and AT lock-protocol blocking, so take a look at the following figure:

Can you try to guess which one is XA? In fact, the figure below is XA, because it brings larger lock granularity and longer locking time, resulting in poor concurrency performance compared to the AT transaction model, so the popularity of XA mode is not too high so far.

Seata short-term planning

Console

First of all, the console is a problem that Seata users have exposed for a long time, without a visual interface, which makes users doubt the reliability of Seata, and because there is no console, it limits the possibility of manually intervening in distributed transactions on Seata, so the 1.5.0 version in the future will bring the console to join, and more students are welcome to join us!

Raft integration

The reasons for Raft integration may not be particularly known to most users. First of all, you should know that the transaction information on the TC side is stored in external storage, such as database, redis, mongodb (PR phase). As a result, if the external storage is down, the Seata-Server cluster is completely unavailable. Even if the Server is a cluster deployment, with 10 or more nodes, it will be unavailable, which is unacceptable.

Therefore, Raft is introduced to make the transaction information of each Seata-Server consistent, even if a node is down, it will not destroy the accuracy of transaction information, so that the consistency of distributed transactions can be better guaranteed. (the implementation of Seata-Server raft will be shared in a new chapter later. )

UndoLog compression

This is 1.5.0 AT mode relatively large performance optimization, as a result of the operation of a lot of data and large, because Seata in the back for the user to insert undolog information, which may also become large, resulting in the possibility of slow storage, so to compress the undolog, so that the insertion of undolog is no longer an AT transaction in a large amount of branch data to become a big myocardial infarction overhead.

So much for sharing about how Seata-AT ensures the consistency of distributed transactions. I hope the above content can be helpful to you and learn more knowledge. If you think the article is good, you can share it for more people to see.

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.