Seata
Seata is an open source distributed transaction solution dedicated to providing high performance and easy to use distributed transaction services. Seata will provide users with AT, TCC, SAGA and XA transaction modes to create a one-stop distributed solution for users.
Component roles in Seata
- TC (Transaction Coordinator, Transaction Coordinator)Is:
Server
To be deployed separately, maintain the state of global and branch transactions, and drive global transaction commit or rollback; - TM (Transaction Manager)Is:
Client
End, integrated by the business system, defines the global transaction; - RM (Resource Manager)Is:
Client
End, integrated by the business system, manages the resources of branch transaction processing.
A typical lifecycle for distributed transactions managed by Seata:
TM
requirementsTC
Start a new global transaction.TC
Generate objects that represent global transactionsXID
.XID
Propagated through the invocation chain of microservices.RM
Register local transactions asXID
toTC
The corresponding branch of the global transaction.TM
requirementsTC
Commit or rollback the correspondingXID
Global transactions.TC
driveXID
All branch transactions under the corresponding global transaction to complete branch commit or rollback.
Seata transaction mode
Seata provides four different transaction modes for different business scenarios, as follows:
- AT mode:
AT
Phase one, phase two commit, and rollback of the pattern (with the help ofundo_log
Table to implement) bySeata
The framework is automatically generated, and the user only needs to write “business”SQL
“Can easily access distributed transactions,AT
A pattern is a distributed transaction solution without any intrusion into the business. - TTC mode: relative to the
AT
Mode,TCC
Patterns are somewhat intrusive to business code, butTCC
Model noAT
Mode for global row locking,TCC
Performance is better thanAT
The pattern is much higher. Applicable to scenarios with high performance requirements, such as core systems. - SAGA mode:
Sage
Long transaction solutions, transaction-driven, use business scenarios where process auditing exists, such as the financial industry, requiring multiple layers of auditing. - XA mode:
XA
Patterns are distributed, highly consistent solutions with low performance and low usage.
AT mode
AT mode, divided into two phases
- Phase one: Business data and rollback log records are committed in the same local transaction, freeing local locks and connection resources
- Phase 2: Commit asynchrony (or if the transaction fails, rollback is reversed by the rollback log of phase 1)
Phase 1 In phase 1, Seata intercepts the “business SQL”, parses the SQL semantics, finds the business data to be updated by the “Business SQL”, saves it as “Before Image” before the business DATA is updated, and then executes the “Business SQL” to update the business data. After the business data is updated, Save it as “After Image” and generate a row lock. All of the above operations are done within a single database transaction, which ensures atomicity of the one-phase operations.
Phase 2: The execution succeeds and the distributed transaction is committed
businessSQL
“In a phase has been committed to the database, soSeata
The framework only needs to delete snapshot data and row locks saved in one stage to complete data cleaning.
Phase 2: After the service rollback fails, compare current service data in the database with After Image to avoid dirty service write (similar to the CAS operation). After the verification, use Before Image to restore service data and delete intermediate data.
TCC mode
TCC mode can be divided into three stages:
- Try: Performs service check and resource reservation
- Confirm: Confirm the submission
- Cancel: Service execution error The branch transaction service that needs to be rolled back is cancelled and reserved resources are released
The three common exceptions in TCC mode are: 1. Empty rollback Empty rollback is a two-stage Cancel method that is invoked for a distributed transaction without calling the TCC resource Try method (such as machine down or network exception). The Cancel method needs to recognize that this is an empty rollback and return success directly.
The solution requires an additional transaction control table with distributed transaction ids and branch transaction ids, and a record inserted into the first phase Try method to indicate that the first phase has been executed. The Cancel interface reads the record. If the record exists, it is rolled back normally. If the record does not exist, it is a null rollback.
2. Idempotent idempotent means that for the same branch transaction of the same distributed transaction, the interface of the second stage of the branch transaction is repeatedly called. Therefore, the Confirm and Cancel interfaces of the second stage of TCC are required to ensure the idempotent and not reuse or release resources. If idempotent control is not done well, it may lead to serious problems such as capital loss.
The solution records the execution status of each branch transaction. In the pre-execution state, if already executed, then no longer executed; Otherwise, perform normal operations. When we talk about empty rollback, there is already a transaction control table, each record of the transaction control table is associated with a branch transaction, so we can add a status field to this transaction control table, which is used to record the execution status of each branch transaction.
3. Suspend Suspend is a distributed transaction in which the two-stage Cancel interface executes before the Try interface. Because empty rollback is allowed, the Cancel interface considers that the Try interface did not execute, and the empty rollback directly returns success. For the Seata framework, it considers that the two-phase interface of the distributed transaction has been successfully executed, and the entire distributed transaction ends.
When executing phase 2, insert a transaction control record with rollback status, so that when executing phase 1, the record is read first. If the record exists, phase 2 is considered to have been executed. Otherwise, phase 2 is not executed.
Saga mode
Saga mode is a long transaction solution provided by SEATA. In Saga mode:
- In a business process, each participant commits a local transaction, and when one of the participants fails, the previous successful participant is compensated. (The local transaction associated with the failure is rolled back, which can be understood as atomicity)
- Both phase ONE forward service and phase two compensation service are implemented by business development.
Currently, the Saga mode provided by SEATA is implemented based on the state machine engine. The mechanism is as follows:
- The flow of service invocation is defined and generated by a state diagram
json
State language definition file - A node in a state diagram can invoke a service, and a node can configure its compensation node
- State diagram
json
The execution is driven by the state machine engine. When an exception occurs, the state engine reversely executes the corresponding compensation node of the successful node to roll back the transaction - It can realize service choreography requirements, supporting single choice, concurrency, sub-process, parameter conversion, parameter mapping, service execution state judgment, exception capture and other functions
Seata Saga has implemented a state machine, which can orchestrate the calling process of services and compensation services of forward services, generate a state graph defined by JSON file, and the state machine engine drives the operation of this graph. When an exception occurs, the state machine triggers rollback and performs compensation services one by one.
Seata also has problems with empty rollback, idempotent, and suspension.
XA mode
XA pattern is another non-invasive distributed transaction solution that Seata will open source:
- No intrusion
- Pass snapshot data and row locks, etc
XA
The instructions are delegated to the database
XA pattern is a distributed solution with strong consistency, but low performance and low usage.
Modules of the Seata Server
Seata Server plays the role of transaction coordinator (i.e., TC) throughout Seata, maintaining the state of global and branch transactions, and driving global transaction commit or rollback.
It has the characteristics of high availability, high performance and high expansibility.
The components of Seata Server are:
- Coordinator Core: At the bottom of the module is the transaction coordinator core code, mainly used to deal with the transaction coordination logic, such as whether
commit
.rollback
And other coordinated activities. - Store: A storage module used to persist our data and prevent data loss from reboots or downtime.
- Discover: service registration/discovery module for the
Server
The address gave us awayClient
. - Config: used to store and find our server configuration.
- Lock: Locks the module, used to give
Seata
Provides the function of global locking. - Rpc: Used to communicate with other terminals.
- HA-Cluster: High availability cluster, not open source yet. for
Seata
Provides reliable and highly available features.