This article brings you an introduction to fescar distributed transactions (pictures and texts). It has certain reference value. Friends in need can refer to it. I hope it will be helpful to you.
1. fescar distributed transaction (overview)
1.1. Overview
Fescar is Alibaba’s open source distributed transaction middleware , solve the distributed transaction problems faced in microservice scenarios in an efficient and zero-intrusion way to the business.
1.2. The development history of Fescar
In 2014, the Alibaba middleware team released TXC (Taobao Transaction Constructor) to provide distributed transaction services for applications within the group.
In 2016, TXC underwent product transformation and landed on Alibaba Cloud as GTS (Global Transaction Service), becoming the only cloud distributed transaction product in the industry at that time. In Ayun's public cloud, In the proprietary cloud solution, it began to serve many external customers.
Since 2019, based on the technology accumulation of TXC and GTS, Alibaba middleware team has launched the open source project Fescar (Fast & EaSy Commit And Rollback, FESCAR) to build this distributed transaction solution together with the community.
1.3. Original design intention
No intrusion into business
High performance
1.4. Principle and design
1.4.1. Design Concept diagram
Transaction Coordinator (TC): Transaction Coordinator, maintains the running status of global transactions, is responsible for coordinating and driving Commit or rollback of global transactions.
Transaction Manager (TM): Controls the boundaries of global transactions , is responsible for opening a global transaction , and ultimately initiates a global commit or global return The resolution to roll.
Resource Manager (RM): Control branch transactions, responsible for branch registration, status reporting, receiving instructions from the transaction coordinator, and driving branch (local) transactions Commit and rollback.
The RM of the XA solution is actually in the database layer. The RM is essentially the database itself (by providing driver for use by the application).
Fescar's RM is deployed as a middleware layer in the form of a second-party package on the side of the application, does not depend on the database itself Support for the protocol, of course does not require the database to support the XA protocol. This is very important for a microservice-based architecture: the application layer does not need to adapt to two different sets of database drivers for local transactions and distributed transactions.
This design strips away the requirements of the distributed transaction scheme on the database's protocol support
2PC process for XA
Regardless of whether Phase2's resolution is commit or rollback, the lock on transactional resources must be maintained until Phase2 is completed before being released.
Assuming a normally running business, there is a high probability that more than 90% of transactions will be successfully submitted in the end. Can we submit local transactions in Phase1? In this way, in more than 90% of cases, the lock-holding time of Phase 2 can be saved, and the overall efficiency can be improved.
Local of data in branch transaction The lock is managed by the local transaction and is released at the end of the branch transaction Phase1.
connection is also released.
Global lock is managed on the transaction coordinator side. When the Phase2 global commit is decided, the global lock can be released immediately. Only when a global rollback is resolved, the global lock is held until the end of Phase 2 of the branch.
Fescar’s JDBC data source proxy, which is Fescar’s RM
Fescar's JDBC data source agent parses the business SQL and organizes the data mirroring of the business data before and after the update into a rollback log , using local transactions's ACID feature commits business data updates and rollback log writes in the same local transaction.
In this way, it can be guaranteed that any update of submitted business data must have a corresponding rollback logexists
If the resolution is a global commit, the branch transaction has been submitted at this time, and no synchronous coordination is required (only asynchronous cleaning up the rollback log is required), Phase2 can be completed very quickly.
If the resolution is a global rollback, RM receives the rollback request from the coordinator, finds the corresponding rollback log record through the XID and Branch ID, and generates feedback through the rollback record. Update the SQL and execute it to complete the rollback of the branch.
XID is the unique identifier of a global transaction. What the transaction propagation mechanism has to do is to put the XID in It is passed through the service call link and bound to the transaction context of the service. In this way, the database update operations in the service link will register branches with the global transaction represented by the XID and be included in the jurisdiction of the same global transaction.
Based on this mechanism, Fescar can support any microservice RPC framework. Just find a mechanism in a specific framework that can propagate XID transparently, such as Dubbo's Filter RpcContext.
A branch transaction that is part of the global transaction, in addition to its own business logic, contains 4 interactions with the coordinator Behavior:
Branch registration: Before the data operation of the branch transaction is carried out, it needs to be registered with the coordinator to include the upcoming branch transaction data operation into an already opened global transaction. In the management, data operations can only be performed after the branch registration is successful.
Status reporting: After the data operation of the branch transaction is completed, its execution results need to be reported to the transaction coordinator.
Branch submission: Respond to the branch transaction submission request issued by the coordinator and complete the branch submission.
Branch rollback: Respond to the branch transaction rollback request issued by the coordinator and complete the branch rollback. 
Business logic does not need to pay attention to the transaction mechanism, and the interaction process between branches and global transactions is automatic Proceed
Business logic needs to be decomposed into Prepare/Commit /Rollback 3 parts form a MT branch and join the global transaction. 
Because the branches of AT and MT modes are fundamentally consistent in behavior, they are fully compatible. , that is, In a global transaction, branches of AT and MT can exist at the same time. In this way, the purpose of comprehensive coverage of business scenarios can be achieved: if AT mode can be supported, use AT mode; if AT mode cannot be supported temporarily, use MT mode instead. In addition, naturally, non-transactional resources managed by MT mode can also be included in the same distributed transaction management together with relational database resources that support transactions.
v0.1.0
Support
1.7. Github open source address
https://github.com/alibaba/fescar/The above is the detailed content of Detailed introduction of fescar distributed transactions (picture and text). For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
