SpringBoot's distributed transaction solution based on Dubbo and Seata

1. A preliminary exploration of distributed transactions

Generally speaking, the current databases on the market support local transactions , that is, in your application, operations under a database connection can easily implement transaction operations.

But at present, based on the idea of ​​SOA, after most projects adopt the micro-service architecture, there will be cross-service transaction requirements, which is called distributed transaction .

This article assumes that you already understand the operating mechanism of transactions. If you do not understand transactions, then I suggest to read the articles related to transactions first, and then read this article.

1.1 What is a distributed transaction

For traditional monolithic applications, the implementation of local transactions can rely on Spring's @Transactional annotation identification method, and the implementation of transactions is very simple.

We take the most common e-commerce system as an example, and simply split it into user client, order service, inventory service, commodity service, etc. During the user's ordering process, each service needs to be called at the same time, but each service is Independently deployed, the database connection is not shared, so to ensure that all these operations are executed, or all are not executed, the support of distributed transactions is required .

1.2 Distributed transaction solution

• Global transaction, based on DTP model implementation, requires three roles, namely Application application system, Transaction Manager transaction manager, Resource Manager resource manager;

• Distributed transaction based on reliable message service, through message queue to achieve transaction consistency;

• TCC, namely Try, Confirm, Cancel, is a compensating distributed transaction, Try: try the transaction to be executed, Confirm: execute the transaction, Cancel: cancel the executed transaction;

1.3 Introduction to Seata

Seata is an open source distributed transaction solution dedicated to providing high-performance and easy-to-use distributed transaction services under a microservice architecture. Seata was officially open sourced in 2019.1, and its predecessor was TXC (Taobao Transaction Constructor), which was born by Alibaba in 2014. The following are the featured services introduced on Seata's official website:

image.png

Seata will provide users with AT, TCC and XA transaction modes to create a one-stop distributed solution for users. For more information about Seata, please refer to its official website.

2. Spring Boot, Dubbo and Seata realize distributed transaction case

2.1 Environmental preparation

To run this test, you need to prepare the following software operating environment in advance:

This case mainly imitates the simple process of placing an order to deduct inventory. The structure diagram is as follows:

2.2 Seata management terminal

Download the latest version of Seata and unzip it, enter the seata/bin directory, and start:

sh seata-server.sh 8091 file

Observe whether port 8091 is enabled.

2.3 Data storage

For this test service, two tables need to be created, namely the order table and the inventory table:

2.4 Build Spring Boot Service

The sample code can refer to the Github warehouse, the directory structure of the warehouse is as follows:

• springboot-base: Stores the publicly called base class interface, mapper interface, and Model layer classes, etc., which can be called by other three modules after mvn install.

• springboot-dubbo-storage: inventory service;

• springboot-dubbo-order: order service;

• springboot-dubbo-client: RPC consumer, providing external interface;

To build a Dubbo service based on Spring Boot, please refer to the previous blog post "Spring Boot (5) Integrated Dubbo Deployment RPC Service", the process of building this project will not be repeated.

After adding Seata components, the difference from ordinary Dubbo projects is

1. Configure Seata data source

2. Seata initialization

/** 
 * Configure the global transaction scanner. There are two parameters, one is the application name, the other is the transaction group 
 * 
 * @return 
 */ 
@Bean 
public GlobalTransactionScanner globalTransactionScanner() { 
    return new GlobalTransactionScanner("springboot-dubbo-storage", "my_test_tx_group"); 
}

3. Configure the registry. The currently available configuration centers are file, nacos, apollo, zk, consul. The file type itself does not have the dynamic discovery and dynamic configuration functions of the registry. The official original intention is to configure the registry without relying on a third party. Quickly integrate and test the seata function based on it. The configuration content is in file.conf and registry.conf.

4. Annotations mark transaction methods. Add @GlobalTransactional annotations to methods that require distributed transactions.

2.5 Testing

After starting Seata, springboot-dubbo-storage, springboot-dubbo-order, springboot-dubbo-client in turn, open the postman test and configure the test parameters as:

As you can see, after addOrder reports an error, there will be a rollback process for the global transaction.

3. Reference

• Seat

• How to use Seata to ensure consistency between Dubbo microservices

• SpringBoot+Dubbo+Seata distributed transaction actual combat

• Choice of Distributed Transaction Selection

• Commonly used distributed transaction solutions

The above content is all about Spring-Boot's distributed transaction solution based on Dubbo and Seata. Thank you for reading here!