Author: Zhang Hui ride
Foreword
In the micro-services architecture system, we can follow the service module layered design, deployment alone, reducing the pressure to deploy the service, also decouples coupling business, to avoid the application becoming a mammoth monster, which can easily be extended in when some service fails it will not affect the normal operation of other services. In short, more and more micro services to our advantage in the rapid development of business, but it is not perfect micro-services, can not be blind to excessive abuse, it has many shortcomings, and will bring some of the complexity of the system, which distributed transaction attendant question is a sore point at the micro-service architecture system will inevitably need to be addressed, but also the industry has been an area of concern, and therefore there have been theories such as CAP and BASE and so on.
Earlier this year, Ali open source middleware with a distributed transaction, originally named Fescar, later renamed Seata, in the beginning it open, I knew it must be fire, because this is an open source project to address pain points, Seata the beginning is directed at non-invasive and high-performance business direction to go, which is what we are addressing urgent needs of distributed transactions.
Distributed Transaction solution to the problem What?
Currently distributed transaction solution to the problem mainly in the business and have not the qin qin into the program, there are no programs submitted by the qin (2PC) XA database scheme based on two-stage agreement, it has the advantage of not into the business code qin, but its disadvantages are also obvious: the database must support the XA protocol requirements, and because of the characteristics of XA protocol itself, it will result in a transaction not released resources for a long time, locked cycle is long, and can not intervene in the application layer on top of Therefore it is poor performance, it is there as the equivalent of seven injuries Boxing "wounding seven, Lose three points," so the Internet is not very popular item in this solution.
In order to bring this issue to make up for the low performance of this program, bigwigs came up with a variety of solutions to, but without exception, are required by the application layer tricks that the qin business methods, such as very famous the TCC scheme, there are many mature TCC based frameworks, such as ByteTCC, tcc-transaction like. And based on reliable sources of eventual consistency is achieved, as RocketMQ the transaction message.
Qin code into the program is based on existing circumstances "forced" solution was launched, in fact, they do not realize very elegant, calling a transaction is usually accompanied by a series of reverse operation to increase the transaction interfaces, For example, three-TCC submitted, the logic must be accompanied by a rollback of logic, this code will make the project very bloated, high maintenance costs.
The relationship between the modules Seata
For the above mentioned pain points distributed transaction solutions, it is very clear that we have the ideal solution for distributed transactions is certainly better performance but also to the business without the qin, without concern for the constraints of distributed transaction mechanism on the business layer, Seata it go in this direction, so it is worth the wait, it will bring a qualitative improvement to our micro-service architecture.
That Seata is how to do it? Here to talk about the relationship between its various modules.
Design ideas Seata a distributed transaction is to be understood as a global transaction, the following transactions linked to a number of branches, and a branch to meet the ACID transaction is a local transaction, so we can operate as a distributed transaction operations as local affairs.
Seata defines three internal modules to handle the relationship between global transactions and processes the transaction and branches, these three components are:
• Transaction Coordinator (TC): Transaction Coordinator, maintain global transactions running, is responsible for coordinating and driving the global transaction is committed or rolled back.
• Transaction Manager (TM): border control global affairs, is responsible for opening a global transaction, and eventually launch a global resolution to commit or roll back global.
• Resource Manager (RM): Control affairs branch, the branch is responsible for registration, status reports, and receive instruction affairs coordinator, commit and rollback drive branch (local) transaction.
Briefly talk about the steps entire global transaction:
1.TM TC to request the opening of a global transaction, TC returned after creating a globally unique global transaction XID, XID will spread in the context of global affairs;
2.RM registered branch transaction to the TC, the branch attributable to the transaction with the same XID global affairs;
3.TM to initiate a global TC committed or rolled back;
Branch services under 4.TC complete schedule XID committed or rolled back.
What is the difference with the XA program?
Seata two-stage submission with XA transaction protocol submitted on the whole is basically the same, then what is the difference between them?
We all know XA protocol that relies on the database level to guarantee the consistency of affairs, is to say the various branches of XA transactions is driven at the database level, due to the various branches of XA transaction requires XA driver's hand important factors that could cause the database with XA drive coupling, on the other hand it will cause the transaction to the various branches of the locking resource cycle is long, and this is it is not popular in the Internet company.
Based on the above issue XA protocol, Seata another way, since the dependency database layer can cause so many problems, I'll play tricks from the application layer, which had to start from Seata the RM module, front also said the main role of the RM in fact the agent made within the RM layer of database operations, as follows:
Seata made in the data source layer proxy layer, so when we use Seata, we use the data source is actually using a built-in data source Seata agent DataSourceProxy, Seata adding a lot of logic in this layer proxy, primarily resolved the sQL, traffic data for the image data before and after updating organized into rollback logs, log and undo log table undo_log inserted, ensure the service update data sql each have corresponding rolling log exists.
The advantage of this is that local transactions executing the local transaction can release the locked resources immediately, and then reported to the state branch of TC. When the TM global resolution submitted, you do not need a synchronized process, TC will asynchronous scheduling each branch affairs RM delete the corresponding undo log to log, this step can be done very quickly; when the global resolution rollback TM, RM income to rollback request sent by TC, RM find the corresponding undo log rollback logs XID, then rollback logs complete rollback.
As shown above, the program is on the RM XA database layer, it depends on the database XA driver.
Shown above, Seata form of RM actually been placed on the application middleware layer, without relying on the protocol database support, completely peeled distributed transaction required by the protocol of protocol support in the database.
How to branch transaction commit and rollback?
The following explain in detail how the transaction is submitted by the branch and rollback:
•The first stage:
分支事务利用 RM 模块中对 JDBC 数据源代理，加入了若干流程，对业务 SQL 进行解释，把业务数据在更新前后的数据镜像组织成回滚日志，并生成 undo log 日志，对全局事务锁的检查以及分支事务的注册等，利用本地事务 ACID 特性，将业务 SQL 和 undo log 写入同一个事物中一同提交到数据库中，保证业务 SQL 必定存在相应的回滚日志，最后对分支事务状态向 TC 进行上报。
•第二阶段：
TM决议全局提交：
当 TM 决议提交时，就不需要同步协调处理了，TC 会异步调度各个 RM 分支事务删除对应的 undo log 日志即可，这个步骤非常快速地可以完成。这个机制对于性能提升非常关键，我们知道正常的业务运行过程中，事务执行的成功率是非常高的，因此可以直接在本地事务中提交，这步对于提升性能非常显著。
TM决议全局回滚：
当 TM 决议回滚时，RM 收到 TC 发送的回滚请求，RM 通过 XID 找到对应的 undo log 回滚日志，然后利用本地事务 ACID 特性，执行回滚日志完成回滚操作并删除 undo log 日志，最后向 TC 进行回滚结果上报。
业务对以上所有的流程都无感知，业务完全不关心全局事务的具体提交和回滚，而且最重要的一点是 Seata 将两段式提交的同步协调分解到各个分支事务中了，分支事务与普通的本地事务无任何差异，这意味着我们使用 Seata 后，分布式事务就像使用本地事务一样，完全将数据库层的事务协调机制交给了中间件层 Seata 去做了，这样虽然事务协调搬到应用层了，但是依然可以做到对业务的零侵入，从而剥离了分布式事务方案对数据库在协议支持上的要求，且 Seata 在分支事务完成之后直接释放资源，极大减少了分支事务对资源的锁定时间，完美避免了 XA 协议需要同步协调导致资源锁定时间过长的问题。
其它方案的补充
In fact it says is the default mode Seata, also known as AT mode, which is similar to the XA two-stage plan submitted to the Program, and the business is non-invasive, but this mechanism still need to rely on the database local transaction ACID properties, there are not found in the above figure I have emphasized the need to support the ACID properties of a relational database, then the question becomes, or non-relational databases do not support ACID can not be used Seata, and do not panic, Seata stage as we prepared another mode, called MT mode, which is a kind of business of the qin programs, other operations we need to rollback to submit their own definition, business logic needs to be decomposed to prepare / Commit / rollback 3 portion, is formed MT a branch, join the global transaction, meaning its existence is more of a scene for the Seata touch.
But, it is not Seata "flagship" model, it exists only as a supplement to the program, more than from official development vision can be seen, Seata goal is always the qin is no business plan.
Finally,
we welcome the exchange, like the point of a praise yo remember the article, thanks for the support!