Spring Cloud Distributed transaction Seata

Make writing a habit together! This is the third day of my participation in the “Gold Digging Day New Plan · April More text Challenge”. Click here for more details.

preface

Here’s what you’ll learn from this article:

Seata
Seata Server deployment
Seata transaction grouping

It is easy to understand if you know the following:

Spring Cloud Alibaba
Nacos
Docker Compose

This article is an applied one and will not expound too much theoretical knowledge

The term parse

The following terms are used in this deployment:

Seata Server: The Seata Server is officially called the Transaction Coordinator (TC) and is deployed separately
Seata Client: The Seata Client, officially called Resource Manager (RM), integrates with service systems

Official Glossary: Seata terminology

Technology selection

In the production environment, you are advised to deploy Seata in the following modes: Registry + configuration center + database

The corresponding technology stack is as follows:

Registry: Nacos
Configuration center: Nacos
Database: MySQL 8.0

Deploy Seata Server

Initializing the database

Create database seata-server and its access user Seata

Use the official database script for initialization: seata/script/server/db at develop

Oracle and PostgreSQL are supported in addition to MySQL

Custom configuration files

See the official deployment documentation: Using Docker Compose to quickly deploy Seata Server

Write the registry. Conf server configuration file:

Registry {type = "nacos" nacos {# service name application = "seata-server" serverAddr = "127.0.0.1:8848" # namespace ID namespace = "Spring-cloud-development" group = "SEATA_GROUP" # cluster name cluster = "default"}} config {type = "nacos" nacos { ServerAddr = "127.0.0.1:8848" Namespace = "spring-cloud-development" group = "SEATA_GROUP "seata-server.properties" } }Copy the code

Add seata-server.properties to nacOS and set it to database mode:

store.mode=db
store.db.datasource=druid
store.db.dbType=mysql
store.db.driverClassName=com.mysql.cj.jdbc.Driver
store.db.url=JDBC: mysql: / / 127.0.0.1:3306 / seata - server? useUnicode=true&characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true&useSSL=false
store.db.user=seata
store.db.password=seata
Copy the code

Note: dataId and group should be configured withregistry.confIn the same

Start with Docker-compose

For docker-compose, read the official documentation in the preface

Write the docker – compose. Yaml:

Select the corresponding version of the docker according to your own version
version: "3.1"
services:
  seata-server:
    image: Seataio/seata - server: 1.4.2
    hostname: seata-server
    ports:
      - "8091:8091"
    environment:
      - SEATA_PORT=8091
      - SEATA_IP = 127.0.0.1
      # There is a pit here
      - SEATA_CONFIG_NAME=file:/root/seata-config/registry
    volumes:
      # There is a pit here
      - "./seata-server/config:/root/seata-config"
Copy the code

Here are two potholes caused by the author’s unfamiliarity with Docker:

The environment variable SEATA_CONFIG_NAME refers to the environment inside the container

Therefore, file:/root/seata-config/registry indicates that the registry. Conf configuration file read by the server is the /root/seata-config/registry

Not our native /root/seata-config/registry

So we would like to write their own configuration file mapping to the internal, namely a hole behind: “. / seata – server/config: / root/seata – config”

This means mapping the native path./ seta-server /config to the container internal path /root/seta-config

To sum up, the operations we need to complete are:

indocker-compose.yamlDirectory creationseata-server/configdirectory
willregistry.confFile placement to${docker - compose. Yaml directory} / seata - server/config
Run the commanddocker-compose up -d

If you encounter the io.seata.com mon. Exception. NotSupportYetException: config type can not be null, please carefully read the above content

Business system integration Seata Client

Initializing the database

Add table undo_log to business system:

Note that 0.3.0+ adds a unique index ux_undo_log
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.`ext` varchar(100) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `ux_undo_log` (`xid`.`branch_id`))ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
Copy the code

Custom configuration files

Add client common configuration file seata-client.properties to nacOS:

seata.registry.type=nacos
seata.registry.nacos.server-addr=127.0.0.1:8848
seata.registry.nacos.namespace=spring-cloud-development
seata.registry.nacos.group=SEATA_GROUP
seata.registry.nacos.application=seata-server

seata.config.type=nacos
seata.config.nacos.server-addr=127.0.0.1:8848
seata.config.nacos.namespace=spring-cloud-development
seata.config.nacos.group=SEATA_GROUP
Copy the code

Note: The group configured on the client side should be the same as that configured on the server side

Introduce bootstrap class dependencies

Introduce a dependency on Spring-cloud-starter-alibaba-seata in POP.xml as recommended by the Seata deployment Guide:

<dependency>
    <groupId>io.seata</groupId>
    <artifactId>seata-spring-boot-starter</artifactId>
    <version>The latest version</version>
</dependency>
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
    <version>2.2.1. RELEASE</version>
    <exclusions>
        <exclusion>
            <groupId>io.seata</groupId>
            <artifactId>seata-spring-boot-starter</artifactId>
        </exclusion>
    </exclusions>
</dependency>
Copy the code

You can then introduce the client configuration from the previous section:

spring:
  cloud:
    nacos:
      config:
        shared-configs:
          - data-id: seata-client.properties
            group: SEATA_GROUP
Copy the code

Affairs grouping

The most important thing to learn about a concept is why do you use it

In retrospect, Seata Server is the Transaction Coordinator TC(Transaction Coordinator).

That is, it plays a crucial role in distributed transactions

But how did it die? Or does the network fluctuate?

Therefore, transaction grouping can be interpreted as Seata Server cluster grouping for high availability of TCS

Seata Server configuration

To clarify the group name of the server, modify the registry. Conf file:

Dev cluster = "dev"}}Copy the code

According to the official document Seata transaction grouping, there is a pit here

You need to add a configuration for the transaction group name corresponding to the cluster name in NACOS

For example, you need to add service.vgroup-mapping.${group name} to set cluster name to dev

This is due to the following code in RegistryService:

public interface RegistryService<T> {

    String PREFIX_SERVICE_MAPPING = "vgroupMapping.";

    String PREFIX_SERVICE_ROOT = "service";

    String CONFIG_SPLIT_CHAR = ".";

    default String getServiceGroup(String key) {
        // Suppose the group name is group-dev
        / / will seek dataId for service in the nacos vgroupMapping. Group - dev configuration
        key = PREFIX_SERVICE_ROOT + CONFIG_SPLIT_CHAR + PREFIX_SERVICE_MAPPING + key;
        if(! SERVICE_GROUP_NAME.contains(key)) { ConfigurationCache.addConfigListener(key); SERVICE_GROUP_NAME.add(key); }returnConfigurationFactory.getInstance().getConfig(key); }}Copy the code

Can not get cluster name in registry config ‘service.vgroupMapping.xx’ please make sure registry config correct

Please read the above carefully

Seata Client configuration

Add the following content to the project configuration:

seata:
  tx-service-group: group-dev
Copy the code

The result is that the transaction group group-dev uses the TC named dev

Application scenarios

A good example is provided by seata.io: Transaction grouping and High availability

conclusion

The paper comes to light

There is also a technology gap like Docker /nacos between understanding Seata and actually deploying Seata

Finally, summarize the overall process of using Seata:

Deploy Seata Server
Group transactions
Business system integration Seata Client

I’m Houtaroy, and any line of code that helps someone else is a lifetime honor

Spring Cloud Distributed transaction Seata

preface

The term parse

Technology selection

Deploy Seata Server

Initializing the database

Custom configuration files

Start with Docker-compose

Business system integration Seata Client

Initializing the database

Custom configuration files

Introduce bootstrap class dependencies

Affairs grouping

Seata Server configuration

Seata Client configuration

Application scenarios

conclusion

Related Posts

Hadoop source code – DataNode initialization and registration process

JVM parameters introduction and a bit of advice

Logical volume LVM and disk quota management