The Gorgeous Evolution of Distributed Transactions | Jingdong Logistics Technical Team

When it comes to distributed transactions, everyone is no stranger. In actual work, flexible distributed transactions are used more often. Today, I will briefly introduce the scenarios and implementation methods of several flexible distributed transactions used in work, which can also be regarded as flexible distributed transactions. an evolutionary process.

1. The caller guarantees

This method is suitable for use in the business itself. When an exception occurs in the logic of a task in the method, the entire method will be abnormal, and the caller will retry. This method is not suitable for the interaction of external systems, otherwise, it is a dangerous practice to put one's own destiny in the hands of others.

In the above call diagram, between the internal application APP1 and APP2, the method method1 of APP1 calls the method2 method in APP2, and method2 contains distributed transaction logic. When the logic in the distributed transaction is abnormal, the method2 method fails or throws Abnormal, after method1 receives the return value of failure or exception, it needs to retry calling method2 to ensure that method2 executes successfully. method2 itself needs to ensure that the successful logic in the logic is processed correctly when it is called again.

@DistributedTransaction
method2(){
    //write DB
    //send msg
    //RPC invoke
}

This method is not recommended for everyone to use in work. It can be used only to ensure the correctness of distributed transactions. However, from the perspective of Java specifications, this method belongs to the use of exception control process, which is not very standardized. At the same time, if the logic in distributed transactions is to write local libraries, send messages or RPC remote calls, it is generally not recommended to put transactions and message sending or RPC calls into transaction methods to avoid large transactions.

2. Scheduled tasks to scan the business table

This scenario is mainly used in scenarios with low traffic and a single business scenario, or when the business is in the verification stage. In order to quickly verify whether the business is valuable, the business table is directly used as the task table to avoid creating multiple tables. After writing the business table with the local transaction, the transaction can be submitted normally. Query the incremental data of the business table through a scheduled task, and process other business logic in the scheduled task.

@Transaction
void method1(){
    //write DB1 Bueiness Table
    //other business Logic
}

void method2(){
    //查询DB1中的Bueiness Table，时间从上次任务开始执行的时间开始
    //处理自身的业务逻辑
}

This solution is generally used as a transitional solution. After the final business volume comes up, it will be upgraded to the following local task list solution.

3. Local task list

This is a typical distributed transaction solution, that is, in the business library, a task table is created synchronously. The business table and the task table are written in the local transaction at the same time, and then a scheduled task regularly queries the task table, reads the task and processes it according to the business logic requirements.

The business table and task table are in a database, and a transaction controller of the database implements the transaction. In the application, start another scheduled task, and the scheduled task will query the task table, capture the new tasks in the task table, and then execute the business logic that the scheduled task needs to execute.

@Transaction
void method1(){
    //write DB1 Bueiness Table
    //write DB1 Task Table
}

void method2(){
    //定时查询DB1中的Task Table
    //任务抓取后执行自身的业务逻辑
}

When this solution is actually used, we need to pay special attention to the stability of the timing task, which determines the usability of our solution. It is recommended to monitor the execution of scheduled tasks to ensure that problems can be dealt with as soon as possible to avoid affecting business.

4. Component extraction

At present, for the Java language development team, most of the frameworks are based on Spring, so a small component package can be made based on the SpringEvent asynchronous event. The main idea is to send an asynchronous event in the transaction. When the asynchronous event is sent successfully, the transaction submission ends. When the asynchronous event fails to be sent, the asynchronous task falls to the local database and the transaction is submitted again. Then, the task is fetched from the task table through the scheduled task implement.

This solution is based on the SpringEvent asynchronous event as a component. When the SpringEvent asynchronous event sends an exception, it will be downgraded to the local task table to ensure the reliability of the asynchronous task. Even if it is not packaged as a component, in actual work, it is recommended that you use this solution.

@Transaction
void method1(){
    //业务数据写入DB成功
    try{
    //发送SpringEvent事件
    }catch(Exception ex){
    //写入本地任务表
    }
}

void method2(){
    //接收事件或定时任务的数据执行业务逻辑
}

Of course, it’s okay if the Spring framework is not used in the project. With the above ideas, you can adjust it according to the framework you use. As the saying goes, "As long as the thinking does not slip, there are always more solutions than difficulties."

Author: JD Logistics Liao Zongxiong

Source: Reprinted from Yuanqishuo Tech by JD Cloud developer community, please indicate the source