Distributed transaction framework Seata
1. What is seata
- Under the microservice architecture, due to the splitting of database and application services, multiple DML operations in one transaction unit
have become multiple DML operations across processes or multiple transaction units across databases,
while traditional database Transactions cannot solve such problems, so the concept of distributed transactions is introduced. - The essence of distributed transactions is to solve the data consistency problem of multiple transactions across network nodes.
There are two common solutions in the industry
. a. Strong consistency, that is, all transaction participants either all succeed or all fail , the global transaction coordinator
needs to know the execution status of each transaction participant, and then decide to submit or
roll back data according to the status!
b. Final consistency, also known as weak consistency, means that the data of multiple network nodes is allowed to be inconsistent
, but at a certain point in time, data consistency will be reached.
Based on the CAP theorem, we can know that the strong consistency scheme will have an impact on the performance and availability of the application, so
for scenarios that do not require high data consistency, the final consistency algorithm will be used. - In the implementation of distributed transactions, for strong consistency, we can implement it through two-phase commit based on the XA protocol
, and for weak consistency, we can implement it based on TCC transaction model, reliability message model and other schemes
. - There are many distributed transaction frameworks for these theoretical models on the market, and we can integrate these frameworks in applications
to realize distributed transactions. Seata is one of them. It is Ali's open source distributed transaction solution, which provides high-performance and easy-to-use distributed transaction services.
Two, seata module
TC (Transaction Coordinator) - transaction coordinator
Maintain the state of global and branch transactions, and drive global transaction commit or rollback.
TM (Transaction Manager) - transaction manager
Define the scope of a global transaction: start a global transaction, commit or rollback a global transaction.
RM (Resource Manager) - Resource Manager
Manage resources for branch transactions, talk to TCs to register branch transactions and report the status of branch transactions, and drive branch transactions to commit or rollback.
In Seata, the life cycle of a distributed transaction is as follows:
TM requests TC to start a global transaction. TC will generate an XID as the number of the global transaction.
XID will be propagated in the call link of microservices, ensuring that the sub-transactions of multiple microservices are associated together.
RM requests TC to register the local transaction as a branch transaction of the global transaction, which is associated through the XID of the global transaction.
TM requests TC to tell XID whether to commit or rollback the global transaction corresponding to it.
TC drives RMs to commit or roll back their own local transactions corresponding to XID.
Seata's XA model:
RM Phase One:
1) TM starts the global transaction
2) TM calls branch RM, RM registers branch to TC, RM executes SQL (but does not submit!), RM reports execution status to TC
TC Phase II:
1) TM submits global transactions
2) TC counts the status of each branch, and if all are successful, it notifies RM to submit. If it fails, the RM is notified to roll back.
Seata AT model:
Phase 1: TM starts global transactions, TM calls branches, RM registers branch transactions, RM records undolog logs, RM commits transactions, and TCC records the status of each branch
Phase two: TM notifies the commit/rollback of the global transaction, and TC checks the transaction status of each branch. If successful, the undolog log will be deleted; if it fails, the undolog log will be rolled back.
Dirty write problem:
If a transaction A executes sql and commits, and another B transaction also executes a commit, and A transaction rolls back at this time, it will roll back the undolog log recorded for A, while the update and modification records of B transaction will be ignored, and a dirty Write questions.
Solution: Introduce a global lock and apply for a global lock before transaction A increases the price and releases the DB lock. At this time, if transaction B performs operation modification, it will obtain the global lock before performing the update database operation. If the acquisition fails, it cannot be updated and continues Retry, but don't let it retry all the time, otherwise A's attempt to acquire the DB lock occupied by B will cause a deadlock. Generally, let it retry for 30 seconds, and if it fails, it will give up the DB lock it owns, and the execution will fail. At this time, the A lock can acquire the DB lock, perform a rollback, and then release the global lock.
Another new question arises: What if it is another transaction that is not under the management of seata? Global lock failed!
XA also automatically brings the solution:
1) First record the record before the update
2) Record the updated record.
The complete and correct execution process is as follows:
1) The original data is assumed to be 100, and undolog records the value of 100.
2) Transaction A obtains the DB lock and modifies the data to 90, and undolog records this 90 at this time.
3) A transaction acquires the global lock, and submits the transaction to release the DB database lock
4) Transaction A is rolled back. Before the rollback is 100, it will compare whether the data at this time is 90. Assume that the B transaction not managed by Seata does not need to acquire the global lock, and then successfully acquires the DB lock and modifies the data to 80. At this time, the A transaction compares 90 (after A modification) with 80 (B modification), and returns Roll failed.
Seata TCC model:
Try: Determine whether there is available data, and freeze the available data if it is enough.
Confirm: Complete the resource operation business; if the try is required to be successful, the confirm must be successful.
Cancel: Reserved resources are released, which can be understood as an operation in the try direction.
Phase 1: Check whether the resource is sufficient, freeze the resource if it is sufficient, and execute the try method
Phase 2: If the execution is successful, execute the Confirm method to delete the frozen resource. Execution fails, Canel logic is executed, and frozen resources are restored.
The advantages and disadvantages of the four types of transactions are introduced:
XA: Strong consistency, no code intrusion, but if the transaction is not committed in the first stage, resources will be locked, resulting in low performance. Need to rely on the transaction characteristics of the database.
AT: default, weak consistency, no code intrusion, one-stage transactions are submitted directly, and if they fail, they will be rolled back according to the undolog log. Isolation introduces global locks, but the concurrency probability is low, so the performance will be better than XA.
TCC: No need to rely on relational databases, based on resource reservation isolation. Try, confirm, and canel need to be manually written, and need to consider empty suspension, empty rollback, and idempotent judgments. They are relatively complicated and have the best performance, but the cost is too high.
Seaga: Suitable for long transaction types, without too many application scenarios.