分布式事务概述

在微服务架构中，不同的服务具有各自独立的数据库，而以往单体应用的事务控制是基于连接之上的，即每次连接到数据库后所有操作为一个事务。这在分布式微服务中显然不适用，因为多个数据库导致了一个事务具有多个数据库连接，这个时候就需要分布式地处理事务

Seata

概述

Seata全称Simple Extensible Autonomous Transaction Architecture，即简单可扩展自主事务架构。seata是一个高性能、易使用、针对微服务架构的分布式事务解决方案，支持XA，TCC(MT)，AT，SAGA事务模式
在Seata看来，分布式事务就是一批分支事务组成的一个全局事务，通常分支事务就是本地事务(即通过数据库连接来控制的事务)

Seata针对分布式事务的解决方案

• TC(Transaction Coordinator)：事务协调者，维护全局和分支事务的状态，驱动全局事务的提交或回滚，由Seata提供
• TM(Transaction Manager)：事务管理器，定义全局事务的范围：开始全局事务、提交或回滚全局事务，由开发者指定(在事务开始的地方加注解)
• RM(Resource Manager)：资源管理器，管理分之事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚

Seata解决分布式事务—AT模式

1. 下载地址
2. 注册中心与配置中心的配置：打开seata/conf/registory.conf，将registory的type改为nacos，进行nacos配置，config改为file(以本地文件来配置)
3. 数据库配置：打开file.conf，将mode改为db，进行数据库的连接配置
4. 创建新的数据库seata，在该库中创建如下三张表

-- 全局表
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;

-- 分支表
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;

-- 全局锁
CREATE TABLE IF NOT EXISTS `lock_table`
(
    `row_key`        VARCHAR(128) NOT NULL,
    `xid`            VARCHAR(128),
    `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;

5. 在每一个参与事务的数据库中加入如下这张表

CREATE TABLE IF NOT EXISTS `undo_log`
(
    `branch_id`     BIGINT(20)   NOT NULL COMMENT 'branch transaction id',
    `xid`           VARCHAR(100) NOT NULL COMMENT 'global transaction id',
    `context`       VARCHAR(128) NOT NULL COMMENT 'undo_log context,such as serialization',
    `rollback_info` LONGBLOB     NOT NULL COMMENT 'rollback info',
    `log_status`    INT(11)      NOT NULL COMMENT '0:normal status,1:defense status',
    `log_created`   DATETIME(6)  NOT NULL COMMENT 'create datetime',
    `log_modified`  DATETIME(6)  NOT NULL COMMENT 'modify datetime',
    UNIQUE KEY `ux_undo_log` (`xid`, `branch_id`)
) ENGINE = InnoDB
  AUTO_INCREMENT = 1
  DEFAULT CHARSET = utf8 COMMENT ='AT transaction mode undo table';

6. 先启动nacos再启动seata，查看seata是否注册成功
7. 在服务中添加spring-cloud-starter-alibaba-seata依赖
8. 在file.conf中加入以下配置，将file.conf与registory.conf拷贝到各个项目项目类路径，每个服务都要配置自己的本地事务

service{
    
# 事务组，my_tx_group为自定义的事务组的名称，同一个事务组的分支事务组成一个全局事务
vgroupMapping.my_tx_group = "default"
# seata服务的地址
default.grouplist = "127.0.0.1:8091"
# 开启全局事务
disableGlobalTransaction = false
}

8. 在application.yml中配置seata的事务组

spring:
  cloud:
    alibaba:
     seata:
       tx-service-group: my_tx_group

9. 在事务开启的方法上添加注解@GlobalTransactionl

上述1~6为配置TC，7~8为配置RM，9为指定TM

AT模式工作流程

1. TM请求TC开启一个全局事务，TC会产生一个XID来表示这个全局事务
2. XID会通过服务调用链来传播到各个RM
3. RM通过XID来讲本地事务作为一个分支事务注册到TC上
4. 出现**异常(spring整合mybatis后，事务的回滚是指捕获到Runtime Exception或Error时，Spring会将底层的各种数据库操作异常包装成一个DataAccessException)**或事务完成时，TM会通过XID向TC请求回滚或提交对应的事务
5. TC驱使所有通过对应XID注册的分支事务完成分支的提交或回滚

数据回滚工作机制

事务在开始时undo_log中会保存原数据镜像，在事务出现回滚时通过这个日志表中的镜像对数据进行恢复，结束之后undo_log中数据会自动删除

分布式事务解决方案

基于XA协议的二阶段提交方案

1. Application：应用程序，使用DTP(分布式事务处理)的程序
2. RM：资源管理器，应用程序通过资源管理器对资源进行控制，资源必须实现XA定义的接口
3. TM：事务管理器，第三方提供，负责协调和管理事务，提供给应用的程序变成接口以及管理资源管理器

工作流程

1. 第一阶段是准备阶段，所有参与者都将本事务能否成功的信息反馈给协调者
2. 第二阶段是提交阶段，协调者根据所有参与者的反馈，通知所有参与者，步调一致地在所有分支上提交或回滚

所有事务都是同时提交或者回滚，第一阶段准备时事务被挂起，造成性能低的问题

基于TCC(Try-Confirm-Cancel)协议的三阶段提交方案

try部分完成业务的准备工作，判断事务能否开启；confirm部分完成业务的提交；cancel部分完成业务的回滚（Confirm和Cancel是事务的反向补偿）

TCC的优缺点

优点：

相对于二阶段的提交，三阶段提交主要解决单点故障问题，并减少了阻塞时间，因为一旦参与者无法及时收到协调者的信息之后会默认执行commit，而不会一致持有事务资源并处于阻塞状态

缺点

1. 对应用侵入性强，业务逻辑每个分支都要实现try、confirm、cancel三个操作，改造成本高
2. 实现难度大，需要按照网络状态，系统故障等不同失败原因实习那不同的回滚策略。为了满足一致性的要求，confirm和cencel必须实现幂等

基于MQ的最终一致性方案

通过消息中间件保证上下游应用数据操作的最终一致性。将本地操作和发送消息放在一个事务中(rabbitMQ不支持事务消息，考虑使用rocketMQ)，保证本地操作和消息发送要么两者都成功或者都是失败。
本质上来说是将分布式事务转换成两个本地事务，然后依靠下游业务的重试机制达到最终一致性。
如果下游不成功，考虑保存上游原始镜像，定时任务来判断下游是否成功，如果不成功恢复上游的数据