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

This article mainly introduces "what is the design principle of distributed transaction middleware Seata". In daily operation, I believe that many people have doubts about the design principle of distributed transaction middleware Seata. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubts about "what is the design principle of distributed transaction middleware Seata?" Next, please follow the editor to study!

Under the micro-service architecture, we can design and deploy separately according to the business module, which reduces the pressure of service deployment, decouples the business coupling, and prevents the application from becoming a giant monster, so that it can be easily expanded. when some services fail, it will not affect the normal operation of other services. In a word, micro-service brings us more and more advantages in the rapid development of business, but micro-service is not perfect, so it can not be overused blindly, it has many shortcomings, and it will bring certain complexity to the system. the accompanying distributed transaction problem is not only a pain point to be dealt with under the micro-service architecture, but also an area that the industry has been paying close attention to. As a result, theories such as CAP and BASE have emerged.

At the beginning of this year, Ali opened up a distributed transaction middleware, initially named Fescar, and later renamed Seata. At the beginning of its open source, I knew it would be popular, because this is an open source project to solve the pain point. Seata started out to be non-intrusive to the business and high-performance direction, which is our urgent need to solve the problem of distributed transactions. Because several companies have used micro-service architecture, but they are not elegant in solving the problem of distributed transactions, so I have been following the development of Seata. Today, I will briefly talk about some of its design principles. Later, I will conduct an in-depth source code analysis of its various modules. Interested can continue to follow my official account or blog, do not lose.

What are the solutions for distributed transaction solutions?

At present, the solutions of distributed transactions are mainly non-intrusion and intrusion-free solutions, and the non-intrusion solutions are mainly two-stage commit (2PC) scheme based on database XA protocol. Its advantage is that there is no intrusion to business code, but its disadvantages are also obvious: database support for XA protocol must be required, and because of the characteristics of XA protocol, transaction resources will not be released for a long time. The locking cycle is long, and there is no intervention on the application layer, so its performance is very poor, and its existence is equivalent to "hurting seven points and damaging yourself three points", so this kind of solution is not very popular in Internet projects.

In order to make up for the problem of low performance caused by this solution, bosses have come up with many solutions to solve it, but without exception, they all need to tamper with the application layer, that is, to invade the business, such as the famous TCC solution, and there are many mature frameworks based on TCC, such as ByteTCC, tcc-transaction and so on. And based on the final consistency of reliable messages, such as RocketMQ transaction messages.

The solution of the intrusion code is based on the existing situation. In fact, it is very inelegant to implement. The call of a transaction is usually accompanied by a series of reverse operations on the transaction interface, such as TCC three-stage commit, and the commit logic must be accompanied by the rollback logic. This kind of code will make the project very bloated and expensive to maintain.

The relationship between the modules of Seata

In view of the pain point of the distributed transaction solution mentioned above, it is obvious that our ideal distributed transaction solution must have good performance and no intrusion to the business, and there is no need to care about the constraints of the distributed transaction mechanism on the business layer. Seata is developing in this direction, so it is worth looking forward to, and it will bring a qualitative improvement to our micro-service architecture.

So how does Seata do it? Let's talk about the relationship between its various modules.

The design idea of Seata is that a distributed transaction can be understood as a global transaction, under which there are several branch transactions, and a branch transaction is a local transaction that satisfies ACID, so we can operate distributed transactions as if we were operating local transactions.

Three modules are defined within Seata to handle the relationship and processing of global and branch transactions. These three components are:

Transaction Coordinator (TC): transaction coordinator, which maintains the running state of global transactions and is responsible for coordinating and driving the commit or rollback of global transactions.

Transaction Manager (TM): controls the boundaries of a global transaction, is responsible for opening a global transaction, and ultimately initiates a global commit or global rollback resolution.

Resource Manager (RM): control branch transactions, responsible for branch registration, status reporting, and receive instructions from the transaction coordinator to drive the commit and rollback of branch (local) transactions.

Briefly describe the execution steps of the entire global transaction:

TM applies to TC to open a global transaction. The globally unique XID,XID returned by TC after creating the global transaction will propagate in the context of the global transaction.

RM registers a branch transaction with TC, which belongs to a global transaction with the same XID

TM initiates a global commit or rollback to TC

TC schedules branch transactions under XID to be committed or rolled back.

How is it different from the XA scheme?

The transaction commit mode of Seata is basically the same as the two-stage commit of the XA protocol, so what is the difference between them?

We all know that XA protocol relies on the database level to ensure the consistency of transactions, that is to say, each branch transaction of XA is driven at the database level. Because each branch transaction of XA needs XA driver, on the one hand, it will lead to the coupling of database and XA driver, on the other hand, it will lead to long locking cycle of transaction resources of each branch, which is also an important factor that it is not popular in Internet companies.

Based on the above problems of the XA protocol, Seata takes a different approach. Since relying on the database layer will cause so many problems, I will start with the RM module of Seata. I also mentioned the main role of RM. In fact, RM has done an internal proxy layer for database operations, as follows:

Seata has a proxy layer in the data source, so when we use Seata, the data source we use is actually the data source proxy that comes with Seata. DataSourceProxy,Seata adds a lot of logic to this proxy, mainly parsing SQL, organizing the data mirrors of business data before and after updates into rollback logs, and inserting undo log logs into the undo_log table to ensure that there is a corresponding rollback log for each updated business sql.

The advantage of this is that the resources locked by the local transaction can be released immediately after the local transaction is executed, and then the branch status is reported to the TC. When TM decides to commit globally, it does not need synchronous coordination. TC will asynchronously schedule each RM branch transaction to delete the corresponding undo log log, which can be completed very quickly. When TM decides to roll back globally, RM receives the rollback request sent by TC, and RM finds the corresponding undo log rollback log through XID, and then performs the rollback log to complete the rollback operation.

As shown in the figure above, the RM of the XA scheme is placed at the database layer, which relies on the XA driver of the database.

As shown in the figure above, the RM of Seata is actually placed on the application layer in the form of middleware, which does not depend on the protocol support of the database, and completely strips off the requirements of the distributed transaction solution on the protocol support of the database.

How are branch transactions committed and rolled back?

The following details on how branch transactions are committed and rolled back:

The first stage:

The branch transaction uses the JDBC data source agent in the RM module, adds several processes, interprets the business SQL, organizes the data mirror of the business data before and after the update into a rollback log, and generates the undo log log, checks the global transaction lock and registers the branch transaction, etc., using the local transaction ACID feature, the business SQL and undo log are written into the same transaction and submitted to the database together. Ensure that there must be a corresponding rollback log for the business SQL, and finally report the branch transaction status to the TC.

The second stage:

The TM resolution is submitted as a whole:

When the TM resolution is submitted, there is no need for synchronous coordination processing. TC will asynchronously schedule each RM branch transaction to delete the corresponding undo log log, which can be completed very quickly. This mechanism is very critical for performance improvement. We know that during normal business operation, the success rate of transaction execution is very high, so it can be committed directly in the local transaction, which is very significant for improving performance.

TM decides to roll back as a whole:

When TM decides to roll back, RM receives a rollback request sent by TC. RM finds the corresponding undo log rollback log through XID, then uses the local transaction ACID feature to perform the rollback log to complete the rollback operation and delete the undo log log, and finally reports the rollback result to TC.

The business is not aware of all the above processes, the business does not care about the specific commit and rollback of global transactions, and the most important point is that Seata decomposes the synchronous coordination of two-segment commit into branch transactions, which is no different from ordinary local transactions, which means that after we use Seata, distributed transactions are like using local transactions. The transaction coordination mechanism of the database layer is completely handed over to the middleware layer Seata, so that although the transaction coordination is moved to the application layer, it can still achieve zero intrusion into the business, thus stripping off the requirements of the distributed transaction scheme on the protocol support of the database, and Seata releases resources directly after the completion of the branch transaction, which greatly reduces the locking time of the branch transaction to the resources. It perfectly avoids the problem that the resource locking time is too long due to synchronous coordination in XA protocol.

Additions to other options

What is mentioned above is actually the default mode of Seata, also known as AT schema. It is a two-stage commit scheme similar to the XA scheme, and it is non-intrusive to the business, but this mechanism still needs to rely on the ACID feature of the local transaction of the database. Have you found that, in the above diagram, I have emphasized that it must be a relational database that supports ACID features? then the problem comes. Non-relational databases or databases that do not support ACID cannot use Seata. Don't panic. Seata has prepared another model for us at this stage, called MT mode, which is an intrusive solution to the business. Operations such as submission and rollback need to be defined by ourselves. Business logic needs to be divided into Prepare/Commit/Rollback 3 parts to form a MT branch to join global transactions. The purpose of its existence is to reach more scenarios for Seata.

At this point, the study on "what is the design principle of distributed transaction middleware Seata" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.