1 Background
Common distributed transaction solutions such as 2pc/3pc, tcc, and saga are common on the market, but the actual implementation of the framework is relatively heavy, the design and development are relatively cumbersome, and it is not easy to develop quickly. This paper provides a simple and easy-to-use distributed transaction design scheme based on flexible transaction design, which is used to solve common scenarios of distributed transactions.
2 Common distributed transaction scenarios
2.1 Synchronization scene
In a common scenario, the method relies on multiple synchronization interfaces of external microservices, and the subsequent logic is expanded after the synchronization interface returns, as described in Figure 1 below.
Figure 1 Distributed transaction synchronization scenario
Existing problem: After B/C fails, A/B cannot be rolled back, resulting in inconsistent data?
2.2 Asynchronous scenarios
The method relies on multiple synchronous interfaces of external microservices. At the same time, the local transaction commits and sends out asynchronous MQ, as described in Figure 2 below.
Figure 2 Distributed transaction asynchronous scenario
Existing problems: The inquiry system cannot guarantee that the local transaction and the sending of the mq message succeed or fail at the same time, which will cause data inconsistency.
3 Solutions
3.1 Data Model Design
Transaction table: record the status of each synchronization method execution, including: 1- in progress (synchronization method execution starts), 2-completed (synchronization method execution succeeds), 3-failure (synchronization method execution fails), 4-returned rollback (the rollback method was executed successfully);
Method call table: Record the input parameters before execution of all methods in a complete transaction, the synchronization method interface, the rollback interface, the rollback input parameters, and the method execution sequence, as described in Figure 3 below:
Figure 3 Transaction Service Data Model
3.2 Design principle
Principle: In a complete transaction, 1. First, each method provides a rollback interface, and secondly, when each synchronization method is executed in the transaction, the input data is preferentially maintained in the transaction table to facilitate subsequent rollback compensation; 2. Within the entire transaction When a method fails, end the entire transaction and update the transaction table status = failure; 3. The transaction table calls the rollback interface by polling the status=3 (failure) transaction, and uses the rollback input parameter for interface compensation; 4 .Rollback logic: Find the sequence value of the failed execution method in the transaction table, only call all the rollback interfaces and input parameters that are smaller than the failure sequence value, pay attention not to rollback the interface of the failed value, and perform the interface rollback according to the reverse order compensate.
Figure 4 Schematic diagram of rollback
3.3 Execution Timing
Figure 5 Rollback execution sequence diagram
3.4 Failed rollback solution:
- High availability guarantee of transaction services: The premise of flexible transactions is to ensure high availability of transaction services, and key guarantees;
- Rollback service retry mechanism: rollback interface failure retry mechanism to ensure data consistency;
- In order to avoid architectural complexity, log records, alarms, and manual processing are done.
4 Pay attention to the problem
- The idempotency of the rollback service: Do a good job of business and system anti-duplication during rollback to prevent inconsistencies in business data caused by rollback;
- Dirty data: The execution of a method in the entire transaction fails, and the data of the previously called method is used as dirty data. Simple solution: rely on the entire transaction execution state of the transaction table to determine whether dirty data can be used. But the disadvantage is that this will couple business logic;
- Centralization: The maintenance of the entire transaction is completely dependent on the transaction service, and the high availability of the transaction service needs to be guaranteed;
- Real-time: Transaction maintenance This solution is maintained through scheduled tasks. If the business scenario has real-time requirements, the method can be changed to: when a method fails to execute in the entire transaction, the catch is abnormal, and the update task status in the catch succeeds, and directly returns Roll logic call.
5 Summary
In addition to ensuring transaction integrity through conventional local large transactions, this solution provides a method based on flexible transaction rollback compensation to ensure distributed transactions. By maintaining the transaction service and the corresponding data table of the transaction service center, the entire distributed transaction is guaranteed. transactional integrity. The implementation method is simple, lightweight, and easy to operate, and it can easily solve common distributed transaction scenarios.
Author: Zheng Penghui