SpringCloudAlibaba项目之Seata分布式事务

SpringCloudAlibaba随笔目录

一、SpringCloudAlibaba项目之父工程搭建

二、SpringCloudAlibaba项目之Nacos搭建及服务注册

三、SpringCloudAlibaba项目之生产者与消费者

四、SpringCloudAlibaba项目之Ribbon负载均衡

五、SpringCloudAlibaba项目之OpenFeign远程调用

六、SpringCloudAlibaba项目之Nacos-config配置中心

七、SpringCloudAlibaba项目之Sentinel流量控制

八、SpringCloudAlibaba项目之Seata分布式事务

九、SpringCloudAlibaba项目之GateWay网关

十、SpringCloudAlibaba项目之SkyWalking链路跟踪

SpringCloudAlibaba项目之Seata分布式事务

1、分布式事务

 　　事务是数据库的概念，数据库事务（ACID：原子性、一致性、隔离性和持久性）；

　　分布式事务的产生，是由于数据库的拆分和分布式架构(微服务)带来的，在常规情况下，我们在一个进程中操作一个数据库，这属于本地事务，如果在一个进程中操作多个数据库，或者在多个进程中操作一个或多个数据库，就产生了分布式事务；

（1）数据库分库分表就产生了分布式事务；

 （2）项目拆分服务化也产生了分布式事务；

2、Seata简介

　　Seata 是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务。

　　Seata为用户提供了AT、TCC、SAGA和XA事务模式，为用户打造一站式的分布式解决方案；

四种事务模式中，XA模式正在开发中…，其他事务模式已经实现；

目前使用的流行度情况是：AT > TCC > Saga；

我们可以参看seata各公司使用列表：

https://github.com/seata/seata/issues/1246 大部分公司都采用的AT事务模式；

Seata已经在国内很多团队开始落地，其中不乏有大公司；

Github：https://github.com/seata/seata/releases

官网文档：https://seata.io/zh-cn/docs/overview/what-is-seata.html

在Seata的架构中，一共有三个角色：

TC (Transaction Coordinator) – 事务协调者

维护全局和分支事务的状态，驱动全局事务提交或回滚；

TM (Transaction Manager) – 事务管理器

定义全局事务的范围：开始全局事务、提交或回滚全局事务；

RM (Resource Manager) – 资源管理器

管理分支事务处理的资源，与TC交互以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚；

其中TC为单独部署的 Server 服务端，TM和RM为嵌入到应用中的 Client 客户端；

在Seata中，一个分布式事务的生命周期如下：

TM请求TC开启一个全局事务，TC会生成一个XID作为该全局事务的编号，XID会在微服务的调用链路中传播，保证将多个微服务的子事务关联在一起；

RM请求TC将本地事务注册为全局事务的分支事务，通过全局事务的XID进行关联；

TM请求TC告诉XID对应的全局事务是进行提交还是回滚；

TC驱动RM将XID对应的自己的本地事务进行提交还是回滚；

3、Seata服务端部署（TC事务协调者）

　　因为TC需要进行全局事务和分支事务的记录，所以需要对应的存储，目前，TC有三种存储模式( store.mode )：

file模式：适合单机模式，全局事务会话信息在内存中读写，并持久化本地文件 root.data，性能较高；

db模式：（mysql 5.7+）适合集群模式，全局事务会话信息通过 db 共享，相对性能差点；

redis模式：解决db存储的性能问题；

 这里使用windows系统演示db模式；

（1）下载安装包

seata下载地址：https://github.com/seata/seata/releases

（2）修改配置文件

 （3）创建数据库表

 官网已经为我们创建好了脚本，只需要引入使用即可：https://github.com/seata/seata/tree/1.4.0/script/server/db

 运行mysql.sql文

-- -------------------------------- The script used when storeMode is "db" --------------------------------
-- the table to store GlobalSession data
CREATE TABLE IF NOT EXISTS `global_table`
(
    `xid`                       VARCHAR(128) NOT NULL,
    `transaction_id`            BIGINT,
    `status`                    TINYINT      NOT NULL,
    `application_id`            VARCHAR(32),
    `transaction_service_group` VARCHAR(32),
    `transaction_name`          VARCHAR(128),
    `timeout`                   INT,
    `begin_time`                BIGINT,
    `application_data`          VARCHAR(2000),
    `gmt_create`                DATETIME,
    `gmt_modified`              DATETIME,
    PRIMARY KEY (`xid`),
    KEY `idx_gmt_modified_status` (`gmt_modified`, `status`),
    KEY `idx_transaction_id` (`transaction_id`)
) ENGINE = InnoDB
  DEFAULT CHARSET = utf8;

-- the table to store BranchSession data
CREATE TABLE IF NOT EXISTS `branch_table`
(
    `branch_id`         BIGINT       NOT NULL,
    `xid`               VARCHAR(128) NOT NULL,
    `transaction_id`    BIGINT,
    `resource_group_id` VARCHAR(32),
    `resource_id`       VARCHAR(256),
    `branch_type`       VARCHAR(8),
    `status`            TINYINT,
    `client_id`         VARCHAR(64),
    `application_data`  VARCHAR(2000),
    `gmt_create`        DATETIME(6),
    `gmt_modified`      DATETIME(6),
    PRIMARY KEY (`branch_id`),
    KEY `idx_xid` (`xid`)
) ENGINE = InnoDB
  DEFAULT CHARSET = utf8;

-- the table to store lock data
CREATE TABLE IF NOT EXISTS `lock_table`
(
    `row_key`        VARCHAR(128) NOT NULL,
    `xid`            VARCHAR(96),
    `transaction_id` BIGINT,
    `branch_id`      BIGINT       NOT NULL,
    `resource_id`    VARCHAR(256),
    `table_name`     VARCHAR(32),
    `pk`             VARCHAR(36),
    `gmt_create`     DATETIME,
    `gmt_modified`   DATETIME,
    PRIMARY KEY (`row_key`),
    KEY `idx_branch_id` (`branch_id`)
) ENGINE = InnoDB
  DEFAULT CHARSET = utf8;