Detailed introduction of fescar distributed transactions (picture and text)

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

1. Transaction Coordinator (TC): Transaction Coordinator, maintains the running status of global transactions, is responsible for coordinating and driving Commit or rollback of global transactions.

2. 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.

3. 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.

1.4.2. What is the difference from XA?

1. 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).

2. 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.

3. This design strips away the requirements of the distributed transaction scheme on the database's protocol support

1.4.3 . Two-phase commit

1.4.3.1. 2PC process for XA

1. 2PC process for XA
   

2. 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.

1.4.3.2. 2PC process of fescar

1. 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.

2. At the same time, as the local transaction ends, the

   connection is also released.

3. The data in the branch transaction

   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.

4. This design greatly reduces the locking time of branch transactions on resources (data and connections), providing a foundation for improving overall concurrency and throughput.

1.4.4. How to commit and rollback branch transactions? (Key point)

1. First of all, the application needs to use

   Fescar’s JDBC data source proxy, which is Fescar’s RM
   

2. 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.

3. In this way, it can be guaranteed that any update of submitted business data must have a corresponding rollback logexists
   

4. 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.

5. 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.

1.4.5. Transaction propagation mechanism

1. 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.

2. 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.

1.4.6. Basic behavior pattern of branches

A branch transaction that is part of the global transaction, in addition to its own business logic, contains 4 interactions with the coordinator Behavior:

1. 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.

2. Status reporting: After the data operation of the branch transaction is completed, its execution results need to be reported to the transaction coordinator.

3. Branch submission: Respond to the branch transaction submission request issued by the coordinator and complete the branch submission.

4. Branch rollback: Respond to the branch transaction rollback request issued by the coordinator and complete the branch rollback.
   

   1.4.7. Behavior mode of AT mode branch

5. Business logic does not need to pay attention to the transaction mechanism, and the interaction process between branches and global transactions is automatic Proceed
   

1.4.8. Behavioral pattern of MT pattern branch

1. Business logic needs to be decomposed into Prepare/Commit /Rollback 3 parts form a MT branch and join the global transaction.
   

1.4.9. Mixed mode

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.

1.5. Preliminary version planning

v0.1.0

• ## Microservice framework support: Dubbo

• Database support: MySQL

• Annotation based on Spring AOP

• Transaction coordinator: stand-alone version

v0.5.x

• Microservice framework supports: Spring Cloud

• MT mode

• Support TCC mode transaction adaptation

• Dynamic configuration and service discovery

• Transaction coordinator: high availability cluster version

v0.8.x

• Metrics

##Console: Monitoring/Deployment/Upgrade/Capacity expansion
v1.0.0

General Availability: Applicable to production environment
v1.5.x

Database support: Oracle/PostgreSQL/OceanBase
Does not rely on Spring AOP’s Annotation
Hotspot data Optimized processing mechanism
RocketMQ transaction messages are incorporated into global transaction management
NoSQL is incorporated into the adaptation mechanism of global transaction management
Support HBase
Support Redis
v2.0.0

• Support
  

1.6. Summary

 After reading the overview, I spit out blood. It is clearly stated that it supports any microservice RPC framework. Now I want to distribute it in a way that is suitable for Spring Cloud. Choose one of the transaction solutions. You tell me that Spring Cloud is expected to be integrated in the next version. If you are a passing expert, please recommend one

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!