Shulou(Shulou.com)06/01 Report--

How to solve the distributed transaction problem with Spring Boot integrated Seata? aiming at this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

Introduction to seata

Seata is Alibaba's open source distributed transaction solution in 2019, which is committed to providing high-performance and easy-to-use distributed transaction services under the micro-service architecture. Before the open source of Seata, the internal version of Seata has always played the role of distributed consistency middleware in Ali, helping Ali through the Singles Day holiday over the years and providing a strong support for various businesses. After years of precipitation and accumulation, 2019.1 Seata officially announced open source. Currently, Seata 1.0 is already GA.

Distributed transaction problems in Micro Services

Let's imagine a traditional monolithic application whose business consists of three modules that use a single local data source. Naturally, local transactions will ensure data consistency.

The microservice architecture has changed. The three modules mentioned above are designed for three services. Local transactions naturally ensure data consistency in each service. But what is the scope of the entire business logic?

What about Seata?

We say that a distributed transaction is a global transaction consisting of a batch of branch transactions, usually a local transaction.

Seata has three basic components:

Transaction coordinator (TC): maintains the state of global and branch transactions and drives global commit or rollback.

Transaction manager TM: define the scope of the global transaction: start the global transaction, commit or roll back the global transaction.

Resource manager (RM): manages resources for branch transactions that are being processed, talks to TC to register branch transactions and report the status of branch transactions, and drives the commit or rollback of branch transactions.

Typical lifecycle of distributed transactions managed by Seata:

TM requires TC to start a new global transaction. TC generates a XID that represents a global transaction.

XID propagates through the call chain of microservices.

RM registers the local transaction as a branch of the corresponding global transaction from XID to TC.

TM requires TC to commit or roll back the corresponding XID global transaction.

TC drives all branch transactions under the corresponding global transaction of XID to complete branch commit or rollback.

Quick start use case

The business logic of the user's purchase of goods. The entire business logic is supported by three microservices:

Warehousing service: deducting the quantity of storage for a given commodity.

Order service: create orders according to purchase requirements.

Account service: deduct the balance from the user's account.

Step 1: set up the database # db_seataDROP SCHEMA IF EXISTS db_seata;CREATE SCHEMA db_seata;USE db_seata;# AccountCREATE TABLE `account_ tbl` (`id` INT (11) NOT NULL AUTO_INCREMENT, `user_ id` VARCHAR (255) DEFAULT NULL, `money` INT (11) DEFAULT 0, PRIMARY KEY (`id`)) ENGINE = InnoDB DEFAULT CHARSET = utf8;INSERT INTO account_tbl (id, user_id, money) VALUES (1, '1001), 10000) INSERT INTO account_tbl (id, user_id, money) VALUES (2, '1002); # OrderCREATE TABLE `order_ tbl` (`id`INT (11) NOT NULL AUTO_INCREMENT, `user_ id`VARCHAR (10000) DEFAULT NULL, `commodity_ code` VARCHAR (25585) DEFAULT NULL, `count`INT (11) DEFAULT' 0requests, `money`INT (11) DEFAULT '0cycles, PRIMARY KEY (`id`)) ENGINE = InnoDB DEFAULT CHARSET = utf8 # StorageCREATE TABLE `commodity_ tbl` (`id` INT (11) NOT NULL AUTO_INCREMENT, `commodity_ code` VARCHAR (255th) DEFAULT NULL, `count` INT (11) DEFAULT '0mm, PRIMARY KEY (`id`), UNIQUE KEY `commodity_ code` (`commodity_ code`) ENGINE = InnoDB DEFAULT CHARSET = utf8;INSERT INTO storage_tbl (id, commodity_code, count) VALUES (1,' 2001 code`, 1000) CREATE TABLE `undo_ log` (`id`bigint (20) NOT NULL AUTO_INCREMENT, `branch_ id` bigint (20) NOT NULL, `xid` varchar (100) NOT NULL, `context`varchar (128) NOT NULL, `rollback_ info` longblob NOT NULL, `log_ status` int (11) NOT NULL, `log_ created` datetime NOT NULL, `log_ modified`datetime NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `ux_undo_ log` (`xid`, `branch_ id`) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8)

The seata AT schema requires undo_log tables, and the other three are business tables.

Step 2: start Seata Server

There are two Server storage modes (store.mode): file and db (raft will be introduced later). The file mode can be started without change. The db schema needs to import three tables that store the global transaction call back information.

Note: file mode is stand-alone mode, and the global transaction session information reads and writes in memory and persists the local file root.data, which has high performance.

Db mode is highly available, and global transaction session information is shared through db, resulting in poor performance.

You can start Seata Server directly through the bash script or through the Docker image, but Docker only supports file mode, and does not support registering Seata-Server with registries such as Eureka or Nacos.

Start by script

Download the corresponding version of Seata Server in https://github.com/seata/seata/releases, decompress it and execute the following command to start it. Here, file configuration is used.

Launch docker run through Docker-- name seata-server-p 8091 seataio/seata-server:latest project introduction project name address description sbm-account-service127.0.0.1:8081 account service sbm-order-service127.0.0.1:8082 order service sbm-storage-service127.0.0.1:8083 warehousing service sbm-business-service127.0.0.1:8084 main business seata-server172.16.2.101:8091seata-server core code

In order not to be too long, only part of the code is given here, and the source code address is given at the end of the detailed code.

Maven introduces seata's dependent eata-spring-boot-starter

Io.seata seata-spring-boot-starter 1.0.0 warehousing Service application.propertiesspring.application.name=account-serviceserver.port=8081spring.datasource.url=jdbc:mysql://172.16.2.101:3306/db_seata?useSSL=false&serverTimezone=UTCspring.datasource.username=rootspring.datasource.password=123456seata.tx-service-group=my_test_tx_groupmybatis.mapper-locations=classpath*:mapper/*Mapper.xmlseata.service.grouplist=172.16.2.101:8091logging.level.io.seata=infologging.level.io.seata.samples.account.persistence .AccountMapper = debugStorageServicepublic interface StorageService {/ * deducted storage quantity * / void deduct (String commodityCode Int count) } order service public interface OrderService {/ * create order * / Order create (String userId, String commodityCode, int orderCount);} account service public interface AccountService {/ * lend * / void debit (String userId, int money) from user account;} main business logic

You just need to use an @ GlobalTransactional annotation on the business method.

@ GlobalTransactionalpublic void purchase (String userId, String commodityCode, int orderCount) {LOGGER.info ("purchase begin... xid:" + RootContext.getXID ()); storageClient.deduct (commodityCode, orderCount); orderClient.create (userId, commodityCode, orderCount);} XID delivery

The cross-service delivery of the global transaction ID needs to be implemented by ourselves, here in the way of interceptors. Each service needs to add the following two classes.

SeataFilter@Componentpublic class SeataFilter implements Filter {@ Override public void init (FilterConfig filterConfig) throws ServletException {} @ Override public void doFilter (ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {HttpServletRequest req = (HttpServletRequest) servletRequest; String xid = req.getHeader (RootContext.KEY_XID.toLowerCase ()); boolean isBind = false; if (StringUtils.isNotBlank (xid)) {RootContext.bind (xid); isBind = true } try {filterChain.doFilter (servletRequest, servletResponse);} finally {if (isBind) {RootContext.unbind ();}} @ Override public void destroy () {}} SeataRestTemplateAutoConfiguration@Configurationpublic class SeataRestTemplateAutoConfiguration {@ Autowired (required = false) private Collection restTemplates; @ Autowired private SeataRestTemplateInterceptor seataRestTemplateInterceptor Public SeataRestTemplateAutoConfiguration () {} @ Bean public SeataRestTemplateInterceptor seataRestTemplateInterceptor () {return new SeataRestTemplateInterceptor ();} @ PostConstruct public void init () {if (this.restTemplates! = null) {Iterator var1 = this.restTemplates.iterator (); while (var1.hasNext ()) {RestTemplate restTemplate = (RestTemplate) var1.next () List interceptors = new ArrayList (restTemplate.getInterceptors ()); interceptors.add (this.seataRestTemplateInterceptor); restTemplate.setInterceptors (interceptors);} Test success scenario: curl-X POST http://127.0.0.1:8084/api/business/purchase/commit

The returned result is: true

Test failure scenario:

When a user with a UserId of 1002 places an order, sbm-account-service throws an exception and the transaction rolls back

Http://127.0.0.1:8084/api/business/purchase/rollback

The returned result is: false

Looking at the log or primary key of undo_log, you can see that the data is saved during execution.

If you look at the self-incremented value of the primary key, the value will change before and after execution, which is 1 before execution and 7 after execution.

This is the answer to the question about how to solve the distributed transaction problem of Spring Boot integration Seata. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.