Local transactions
A Transaction Transaction consists of a set of SQL that has four ACID properties
ACID
Atomicity Is the set of SQL that makes up a transaction, and either all or none of it is partially valid
Consistency The database changes from one state to another after a transaction operation. It can be said that atomicity is described in terms of behavior and consistency in terms of results
Isolation Data objects of isolated transactions are isolated from data objects of other transactions and do not affect each other
When transactions are submitted, their results are permanent, even if downtime (non-disk corruption)
Transaction implementation
For MySQL database (InnoDB storage engine), isolation is realized by locking mechanism of different granularity between transactions. Atomicity, consistency, and persistence are guaranteed by redo log and Undo log rollback logs.
Redo log When a database changes data, the data page in the buffer pool is not the same as the data page in the disk. Buffer pool data pages are called dirty pages. If an abnormal DB restart occurs at this time, the data is not in memory and has not been synchronized to disk files (note that synchronization to disk files is a random IO), which means data loss will occur. When the data page changes in the buffer pool end, the corresponding modification records are recorded in this file (note that the logging is sequential IO). Then, when the DB service crashes, the records in this file can be applied to the disk file again to keep the data consistent.
Undo log The undo log is used to store the values before the data modification. If the modification fails, you can use the undo log to roll back the data to ensure transaction consistency. In addition InnoDB MVCC transaction feature is also based on undo logging implementation. Undo logs are divided into INSERT undo log (generated by insert statements, deleted directly after transaction submission) and Update undo log (generated by delete and UPDATE statements). Because the undo log may be used by MVVC mechanism, Cannot be deleted when the transaction commits.
Problem is introduced into
Theory of CAP
CAP principle, also known as CAP theorem, refers to Consistency, Availability and Partition tolerance in a distributed system. The CAP principle is that, at best, these three elements can achieve two, not all at once. But because fault tolerance of partitions is inevitable in distributed systems, consistency and availability must be compromised.
Traditional DBMSS, such as MySQL, sacrifice some consistency (master-slave delay) in master-slave architecture with read/write separation.
The Base theory of
In the case of a distributed system failure, some available functions can be lost to ensure that core functions are available
Soft State The soft state allows an intermediate state in the system. This state does not affect system availability
Eventually consistent The intermediate state of a system reaches a consistent state after a short period of time
How to solve
Scenario, for example,
Consider A service scenario where system A invokes the refund service of system B to refund money, system A changes the internal refund status, and then invokes the SMS service of system C to notify users.
In such A scenario, due to the inevitable existence of network unreliability, there is A problem of consistency among the three systems A, B and C.
The surface of the earth
According to the above scenario, two tables are designed: refund record table, SMS sending record table and corresponding compensation Job
Specific implementation process:
- Added the refund record form, which is in processing state
- Call the refund service of system B to refund the money
- Update the refund record status to the corresponding status (success/failure)
- If the refund is successful, the SMS sending record is added and the record status is to be sent
- The short message service of system C is invoked to send short messages
- Updated the SMS sending record as sent
Refund compensation Job Queries the records in the refund record table and invokes the refund service of system B. The refund is successfully processed.
- Added SMS sending record, whose status is to be sent
- The short message service of system C is invoked to send short messages
- Updated the SMS sending record as sent
SMS notification compensation Job Queries the SMS sending records to be sent and invokes the SMS service of system C
- The short message service of system C is invoked to send short messages
- Updated the SMS sending record as sent
Note:
- Systems B and C need to support idempotence based on the UUID passed by the caller
- Systems A, B, and C are briefly inconsistent, but eventually consistent
Transaction message
It can be thought of as a two-phase commit message implementation to ensure ultimate consistency in a distributed system. Transactional messages ensure that the execution of local transactions and the sending of messages can be performed atomically.
However, due to the asynchronous nature of transaction messages, the caller can not get the result of the consumer’s processing, which applies to the other party is not concerned about the return result of the other party/the other party is responsible for ensuring the success of the processing
For the above scenario, two transaction messages are added to solve the consistency problem. System A interacts with system B and system C by sending transaction messages
Specific implementation process:
- Sends a transaction message for a refund
- Added a refund record in the processing state
- Commit Refund transaction message
Provide MQ transaction callback
Refund callback query
- Commit if there is a refund record and the process is in progress
- The other is the Rollback
Send SMS callback for query
- If there is a refund record and it succeeds, Commit
- The other is the Rollback
Refund Synchronization Job
Query the records being processed in the refund record form, call the refund query interface of system B to synchronize the status, and the refund is processed successfully:
- Transaction message to send SMS
- Update refund record as successful
- Commit SMS transaction messages
The related theory
Two-stage submission
Two-phase commit is an important theoretical basis for solving distributed transaction problems, but there are also obvious problems:
- Blocking problem, after a participant sends a protocol message to the coordinator, it blocks until a commit or rollback is received, relying only on the coordinator’s timeout mechanism
- Coordinator single point of problem, if the coordinator fails, some participants will never receive commit or rollback messages.
To solve the problem of two-phase commit, there is a three-phase commit:
- Solve the blocking problem: The first phase in 2PC is split in half, providing a CanCommit phase that does not lock resources, which dramatically reduces the blocking probability
- Solve the single point problem: Timeouts are also introduced on the participant side
DTP Model
X/Open Distributed Transaction Processing (DTP) model is a software architecture that has become the de facto behavior standard for Transaction model components. It allows multiple applications to share resources provided by multiple resource managers and allows their work to be coordinated as global transactions.
The ApplicationProgram(AP) application defines transaction boundaries and specifies the operations that make up the transaction
ResourceManager(RM) Manages shared resources that you need to access. ResourceManager refers to relational databases, file storage systems, message queues, and printers
The TransactionManager (TM) transaction manager is a standalone component that assigns identifiers to transactions, monitors their execution, and is responsible for transaction completion and failure recovery
CommunicationResourceManager communication resource manager (CRM) control of one or more of the TM domain communication between distributed applications.
XA Specification
The XA specification is X/Open’s specification for distributed transaction processing (DTP). The specification describes the interface between global transaction managers and local resource managers. The purpose of the XA specification is to allow multiple resources (such as databases, application servers, message queues, and so on) to be accessed in the same transaction so that ACID properties remain valid across applications. XA uses two-phase commit to ensure that all resources commit or roll back any particular transaction at the same time.
The XA specification describes what a resource manager must do to support transactional access.
TCC
saga
In Saga mode, there are multiple participants in distributed transactions, and each participant is a positive compensation service, requiring users to implement forward and reverse rollback operations according to business scenarios.
In the process of distributed transaction execution, the forward operations of each participant are successively executed. If all forward operations are successfully executed, the distributed transaction is committed. If any of the forward actions fail, the distributed transaction goes back and performs the reverse rollback of the previous participants, rolling back the committed participants and returning the distributed transaction to its initial state.
Distributed transactions in Saga mode are usually event-driven and executed asynchronously among participants. Saga mode is a long transaction solution.
The advantages of Saga mode are:
- One-stage commit local database transaction, no lock, high performance;
- Participants can use transaction-driven asynchronous execution with high throughput;
- Compensation service is the “reverse” of forward service, which is easy to understand and realize.
Disadvantages:
- In Saga mode, isolation is not guaranteed because local database transactions have been committed in one phase and no “reserved” action has been taken.
The open source project
seata
Seata is an open source distributed transaction solution dedicated to providing high performance and easy to use distributed transaction services under the microservices architecture. Supports four modes: AT, TCC, SAGA and XA, and is friendly to the micro-service framework.
As shown in the figure below, there are three modules in Seata, which are TM, RM and TC. TM and RM are integrated with the business system as clients of Seata, and TC is deployed independently as server of Seata.
Tc-transaction coordinator maintains the state of global and branch transactions and drives global transaction commit or rollback.
The TM-transaction manager defines the scope of a global transaction: start, commit, or roll back the global transaction.
RM – Resource manager manages resources for branch transaction processing, talks to TCS to register branch transactions and report status of branch transactions, and drives commit or rollback of branch transactions.
In Seata, the execution flow of distributed transactions is:
- TM enables distributed transactions (TM registers global transaction records with TC);
- Schedule intra-transaction resources, such as databases and services, based on service scenarios (RM reports resource readiness status to TC).
- TM ends the distributed transaction and the transaction ends in one phase (TM notifies TC to submit/roll back the distributed transaction);
- TC collects transaction information and decides whether a distributed transaction should be committed or rolled back.
- The TC notifies all RM to commit or roll back resources, and the transaction phase 2 ends.
AT mode
AT pattern is a non-intrusive distributed transaction solution. In AT mode, users only need to focus on their own “business SQL” as a phase, and Seata framework will automatically generate two-phase commit and rollback operations for transactions.
Phase one: Business data and rollback log records are committed in the same local transaction, freeing local locks and connection resources. Phase two: Commit asynchronously, done very quickly. Rollback is compensated in reverse by the rollback log of one phase.
In the first phase, Seata intercepts “business SQL”, parses SQL semantics, finds the business data to be updated by “Business SQL”, saves it as “Before image” before the business data is updated, and then executes “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.
TCC mode
A distributed global transaction, the whole is a two-phase commit model. Global transactions are composed of several branch transactions. Branch transactions should meet the requirements of the two-phase commit model, that is, each branch transaction should have its own:
Phase 1 Prepare Phase 2 Commit or rollback
TCC mode, independent of transaction support for underlying data resources:
- One-stage Prepare behavior: The customized prepare logic is invoked.
- Two-stage COMMIT behavior: Custom commit logic is invoked.
- Two-stage ROLLBACK behavior: Invoke custom ROLLBACK logic.
The TCC pattern supports the integration of custom branch transactions into the management of global transactions.
Saga mode
Currently, the Saga mode provided by SEATA is implemented based on the state machine engine. The mechanism is as follows:
- Define the flow of the service invocation through a state diagram and generate a JSON state language definition file
- A node in a state diagram can invoke a service, and a node can configure its compensation node
- The state graph JSON is executed by the state machine engine. When an exception occurs, the state engine reverse-executes the transaction and the corresponding compensation node of the successful node rolls back the transaction (whether the transaction is compensated when the exception occurs can also be customized by users).
- 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
State machine engine principles
- The state diagram is stateA, then stateB, then stateC
- Execution of “states” is based on event-driven model. After stateA execution is complete, routing messages are generated and put into EventQueue. Event consumers fetch messages from EventQueue and execute stateB
- When the entire state machine is started, Seata Server is called to start a distributed transaction, xids are produced, and “state machine instance” startup events are logged to the local database
- When a “state” is executed, Seata Server is called to register the branch transaction, produce the branchId, and then log the “state instance” to start executing the event to the local database
- When a “state” execution is complete, the “state instance” execution end event is logged to the local database, and the Seata Server is called to report the status of the branch transaction
- When the entire state machine execution is complete, the “state machine instance” execution completion event is logged to the local database, and the Seata Server is called to commit or roll back the distributed transaction