Seata is an open source project Fescar initiated by the Ali middleware team, later renamed Seata, it is an open source distributed transaction framework. The problem of traditional 2PC is solved in Seata. It drives the completion of global transactions through the coordination of branch transactions of local relational databases. It is middleware that works at the application layer. The main advantage is that it has better performance and does not occupy connection resources for a long time. It solves the distributed transaction problems faced by microservice scenarios in an efficient and intrusive manner to the business. It currently provides AT mode (ie 2PC) and TCC mode Distributed transaction solution.
Seata's design ideas are as follows:
Seata understands a distributed transaction as a global transaction that contains several branch transactions. The responsibility of the global transaction is to coordinate the branch transactions under its jurisdiction to reach an agreement, either to submit successfully together or fail to roll back together. In addition, usually the branch transaction itself is a local transaction of a relational database. The following figure is the relationship diagram of the global transaction and the branch transaction:
Similar to the traditional 2PC model, Seata defines three components to handle the processing of distributed transactions:
-
Transaction Coordinator (TC): A transaction coordinator, which is an independent middleware that needs to be independently deployed and operated. It maintains the running status of global transactions, receives TM instructions to initiate the submission and rollback of global transactions, and is responsible for coordinating with RM branches Commitment or rollback of transactions.
-
Transaction Manager ™: Transaction manager, TM needs to be embedded in the application program to work, it is responsible for starting a global transaction, and finally initiate a global commit or global rollback instruction to the TC.
-
Resource Manager (RM): controls branch transactions, is responsible for branch registration, status reporting, and receives instructions from the transaction coordinator TC to drive the submission and rollback of branch (local) transactions.
Take new user registration and send points for example Seata's distributed transaction process:
The specific execution process is as follows:
1. The TM of the user service applies to TC to start a global transaction. The global transaction is successfully created and a globally unique XID is generated.
2. The RM of the user service registers a branch transaction with the TC, which executes the newly added user logic in the user service and incorporates it into the jurisdiction of the XID corresponding global transaction.
3. The user service performs a branch transaction and inserts a record into the user table.
4. Logic execution to remote call integration service (XID is propagated in the context of microservice call link). The RM of the points service registers a branch transaction with the TC, and the branch transaction executes the logic of adding points and incorporates it into the jurisdiction of the XID corresponding global transaction.
5. The point service executes branch transactions, inserts a record into the point record table, and returns to the user service after execution.
6. The user service branch transaction is completed.
7. TM initiates a global submission or rollback resolution for XID to TC.
8. TC schedules all branch transactions under XID to complete the commit or rollback request.
### RM execution process
### Seata bank transfer DEMO execution process (see source code 4)
1. Normal submission process
2. Rollback process
