分布式事务 ~ seata。

lyfGeek

已于 2023-10-20 10:27:36 修改

阅读量259

点赞数

文章标签：分布式数据库 java

于 2023-04-09 06:30:00 首次发布

本文链接：https://blog.csdn.net/lyfgeek/article/details/130001546

版权

分布式事务。

文章目录

- 分布式事务。

1. 分布式事务问题。

1.1. 本地事务。

本地事务，也就是传统的单机事务。在传统数据库事务中，必须要满足四个原则。

在这里插入图片描述

1.2. 分布式事务。

分布式事务，就是指不是在单个服务或单个数据库架构下，产生的事务，例如。

跨数据源的分布式事务。
跨服务的分布式事务。
综合情况。

在数据库水平拆分、服务垂直拆分之后，一个业务操作通常要跨多个数据库、服务才能完成。例如电商行业中比较常见的下单付款案例，包括下面几个行为。

创建新订单。
扣减商品库存。
从用户账户余额扣除金额。

在这里插入图片描述

完成上面的操作需要访问三个不同的微服务和三个不同的数据库。

订单的创建、库存的扣减、账户扣款在每一个服务和数据库内是一个本地事务，可以保证 ACID 原则。

但是当我们把三件事情看做一个"业务"，要满足保证“业务”的原子性，要么所有操作全部成功，要么全部失败，不允许出现部分成功部分失败的现象，这就是分布式系统下的事务了。

此时 ACID 难以满足，这是分布式事务要解决的问题。

1.3. 演示分布式事务问题。

我们通过一个案例来演示分布式事务的问题。

1）创建数据库，名为 seata_demo，建表。

CREATE SCHEMA `seata_demo` DEFAULT CHARACTER SET utf8mb4 ;

CREATE TABLE `seata_demo`.`account_tbl` (
    `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '主键 id。',
    `user_id` VARCHAR(45) NULL COMMENT '账户 id。',
    `money` INT UNSIGNED NULL COMMENT '账户余额。',
    PRIMARY KEY (`id`)
)  ENGINE=INNODB DEFAULT CHARACTER SET=UTF8MB4 COMMENT='account。';

INSERT INTO `seata_demo`.`account_tbl` (`user_id`, `money`) VALUES ('user2023123456789', '1000');

CREATE TABLE `seata_demo`.`order_tbl` (
    `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '主键 id。',
    `user_id` VARCHAR(255) NULL COMMENT '账户 id。',
    `commodity_code` VARCHAR(255) NULL COMMENT '商品编码。',
    `count` INT UNSIGNED NULL COMMENT '商品数量。',
    `money` INT UNSIGNED NULL COMMENT '金额。',
    PRIMARY KEY (`id`)
)  ENGINE=INNODB DEFAULT CHARACTER SET=UTF8MB4 COMMENT='order。';

CREATE TABLE `seata_demo`.`storage_tbl` (
    `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '主键 id。',
    `commodity_code` VARCHAR(255) NULL COMMENT '商品编码。',
    `count` INT UNSIGNED NULL COMMENT '数量。',
    PRIMARY KEY (`id`),
    UNIQUE INDEX `unique_key_storage_commodity_code` (`commodity_code` ASC)
)  ENGINE=INNODB DEFAULT CHARACTER SET=UTF8MB4 COMMENT='storage。';

INSERT INTO `seata_demo`.`storage_tbl` (`commodity_code`, `count`) VALUES ('1', '10');

2）创建微服务。

微服务结构如下。

其中。

seata-demo：父工程，负责管理项目依赖。

account-service：账户服务，负责管理用户的资金账户。提供扣减余额的接口。
storage-service：库存服务，负责管理商品库存。提供扣减库存的接口。
order-service：订单服务，负责管理订单。创建订单时，需要调用 account-service 和 storage-service

3）启动 nacos、所有微服务。

4）测试下单功能，发出 Post 请求。

请求如下。

curl --location --request POST ‘http://localhost:8082/order?userId=user2023123456789&commodityCode=1&count=20&money=200’

测试发现，当库存不足时，如果余额已经扣减，并不会回滚，出现了分布式事务问题。

2. 理论基础。

解决分布式事务问题，需要一些分布式系统的基础知识作为理论指导。

CAP 定理。
BASE 理论。

2.1. CAP 定理。

1998 年，加州大学的计算机科学家 Eric Brewer 提出，分布式系统有三个指标。

Consistency（一致性）。

Availability（可用性）。

Partition Tolerance （分区容错性）。

在这里插入图片描述
它们的第一个字母分别是 C、A、P。

Eric Brewer 说，这三个指标不可能同时做到。这个结论就叫做 CAP 定理。

2.1.1. 一致性。

Consistency（一致性）：用户访问分布式系统中的任意节点，得到的数据必须一致。

比如现在包含两个节点，其中的初始数据是一致的。

在这里插入图片描述

当我们修改其中一个节点的数据时，两者的数据产生了差异。

在这里插入图片描述
要想保住一致性，就必须实现 node01 到 node02 的数据同步。

在这里插入图片描述

2.1.2. 可用性。

Availability （可用性）：用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝。

如图，有三个节点的集群，访问任何一个都可以及时得到响应。

在这里插入图片描述

当有部分节点因为网络故障或其它原因无法访问时，代表节点不可用。

在这里插入图片描述

2.1.3. 分区容错。

Partition（分区）：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。

在这里插入图片描述
Tolerance（容错）：在集群出现分区时，整个系统也要持续对外提供服务。

2.1.4. 矛盾。

在分布式系统中，系统间的网络不能 100% 保证健康，一定会有故障的时候，而服务又必须对外保证服务。因此 Partition Tolerance 不可避免。

当节点接收到新的数据变更时，就会出现问题了。

在这里插入图片描述
如果此时要保证一致性，就必须等待网络恢复，完成数据同步后，整个集群才对外提供服务，服务处于阻塞状态，不可用。

如果此时要保证可用性，就不能等待网络恢复，那 node01、node02 与 node03 之间就会出现数据不一致。

也就是说，在 P 一定会出现的情况下，A 和 C 之间只能实现一个。

分布式系统节点通过网络连接，一定会出现分区问题（P）。
当分区出现时，系统的一致性（C）和可用性（A）就无法同时满足。

2.2. BASE 理论。

BASE 理论是对 CAP 的一种解决思路，包含三个思想。

Basically Available（基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态。
Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。

2.3. 解决分布式事务的思路。

分布式事务最大的问题是各个子事务的一致性问题，因此可以借鉴 CAP 定理和 BASE 理论，有两种解决思路。

AP 模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。
CP 模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。

但不管是哪一种模式，都需要在子系统事务之间互相通讯，协调事务状态，也就是需要一个事务协调者（TC, Transaction Coordinator）。

在这里插入图片描述
这里的子系统事务，称为分支事务；有关联的各个分支事务在一起称为全局事务。

3. 初识 Seata。

Seata 是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。致力于提供高性能和简单易用的分布式事务服务，为用户打造一站式的分布式解决方案。

官网地址：http://seata.io/zh-cn/index.html，其中的文档、博客中提供了大量的使用说明、源码分析。

3.1. Seata 的架构。

Seata 事务管理中有三个重要的角色。

TC（Transaction Coordinator）- 事务协调者： 维护全局和分支事务的状态，协调全局事务提交或回滚。
TM（Transaction Manager）- 事务管理器： 定义全局事务的范围、开始全局事务、提交或回滚全局事务。
RM（Resource Manager）- 资源管理器： 管理分支事务处理的资源，与 TC 交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

整体的架构如图。

在这里插入图片描述
Seata 基于上述架构提供了四种不同的分布式事务解决方案。

XA 模式：强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入。
TCC 模式：最终一致的分阶段事务模式，有业务侵入。
AT 模式：最终一致的分阶段事务模式，无业务侵入，也是 Seata 的默认模式。
SAGA 模式：长事务模式，有业务侵入。

无论哪种方案，都离不开 TC，也就是事务的协调者。

3.2. 部署 TC 服务。

部署 Seata 的 tc-server。

下载。

首先我们要下载 seata-server 包，地址在 http://seata.io/zh-cn/blog/download.html。

解压。

在非中文目录解压缩这个 zip 包。

在这里插入图片描述

修改配置。

原配置。

registry {
  # file 、nacos 、eureka、redis、zk、consul、etcd3、sofa
  type = "file"

  nacos {
    application = "seata-server"
    serverAddr = "127.0.0.1:8848"
    group = "SEATA_GROUP"
    namespace = ""
    cluster = "default"
    username = ""
    password = ""
  }
  eureka {
    serviceUrl = "http://localhost:8761/eureka"
    application = "default"
    weight = "1"
  }
  redis {
    serverAddr = "localhost:6379"
    db = 0
    password = ""
    cluster = "default"
    timeout = 0
  }
  zk {
    cluster = "default"
    serverAddr = "127.0.0.1:2181"
    sessionTimeout = 6000
    connectTimeout = 2000
    username = ""
    password = ""
  }
  consul {
    cluster = "default"
    serverAddr = "127.0.0.1:8500"
    aclToken = ""
  }
  etcd3 {
    cluster = "default"
    serverAddr = "http://localhost:2379"
  }
  sofa {
    serverAddr = "127.0.0.1:9603"
    application = "default"
    region = "DEFAULT_ZONE"
    datacenter = "DefaultDataCenter"
    cluster = "default"
    group = "SEATA_GROUP"
    addressWaitTime = "3000"
  }
  file {
    name = "file.conf"
  }
}

config {
  # file、nacos 、apollo、zk、consul、etcd3
  type = "file"

  nacos {
    serverAddr = "127.0.0.1:8848"
    namespace = ""
    group = "SEATA_GROUP"
    username = ""
    password = ""
    dataId = "seataServer.properties"
  }
  consul {
    serverAddr = "127.0.0.1:8500"
    aclToken = ""
  }
  apollo {
    appId = "seata-server"
    ## apolloConfigService will cover apolloMeta
    apolloMeta = "http://192.168.1.204:8801"
    apolloConfigService = "http://192.168.1.204:8080"
    namespace = "application"
    apolloAccesskeySecret = ""
    cluster = "seata"
  }
  zk {
    serverAddr = "127.0.0.1:2181"
    sessionTimeout = 6000
    connectTimeout = 2000
    username = ""
    password = ""
    nodePath = "/seata/seata.properties"
  }
  etcd3 {
    serverAddr = "http://localhost:2379"
  }
  file {
    name = "file.conf"
  }
}

修改 conf 目录下的 registry.conf 文件。

registry {
  # file 、nacos 、eureka、redis、zk、consul、etcd3、sofa
#  type = "file"
  type = "nacos"

  nacos {
    # seata tc 服务注册到 nacos 的服务名称，可以自定义。
    application = "seata-tc-server"
    serverAddr = "127.0.0.1:8848"
    group = "DEFAULT_GROUP"
    namespace = ""
    cluster = "SH"
    username = "nacos"
    password = "nacos"
  }

}

config {
  # file、nacos 、apollo、zk、consul、etcd3
#  type = "file"
    # 读取 tc 服务端的配置文件的方式，这里是从 nacos 配置中心读取，这样如果 tc 是集群，可以共享配置。
  type = "nacos"

  nacos {
    serverAddr = "127.0.0.1:8848"
    namespace = ""
    group = "SEATA_GROUP"
    username = "nacos"
    password = "nacos"
    dataId = "seataServer.properties"
  }

}

在 nacos 添加配置。

特别注意，为了让 tc 服务的集群可以共享配置，我们选择了 nacos 作为统一配置中心。因此服务端配置文件 seataServer.properties 文件需要在 nacos 中配好。

格式如下。

在这里插入图片描述
http://seata.io/zh-cn/docs/user/configurations.html

配置内容如下。

# 数据存储方式，db 代表数据库。
#store.mode=db需要以下配置。
store.mode=db
store.db.driverClassName=com.mysql.jdbc.Driver
store.db.url=jdbc:mysql://192.168.142.186:3307/seata?useUnicode=true&rewriteBatchedStatements=true
store.db.user=root
store.db.password=root

# db 模式数据源类型。dbcp、druid、hikari；无默认值，store.mode=db 时必须指定。
store.db.datasource=druid
# db 模式数据库类型。mysql、oracle、db2、sqlserver、sybaee、h2、sqlite、access、postgresql、oceanbase；无默认值，store.mode=db 时必须指定。 	
store.db.dbType=mysql

# store.db.driverClassName  # db 模式数据库驱动。store.mode=db 时必须指定。
# store.db.url  # db 模式数据库 url。store.mode=db 时必须指定，在使用 mysql 作为数据源时，建议在连接参数中加上 rewriteBatchedStatements=true（详细原因请阅读附录 7）。
# store.db.user  # db 模式数据库账户。store.mode=db 时必须指定。
# store.db.password  # db 模式数据库账户密码。store.mode=db 时必须指定。

# db 模式数据库初始连接数。默认 1。
store.db.minConn=5
# db 模式数据库最大连接数。默认 20。
store.db.maxConn=30
# db 模式获取连接时最大等待时间。默认 5000，单位毫秒。
store.db.maxWait=5000
# db 模式全局事务表名。默认 global_table。
store.db.globalTable=global_table
# db 模式分支事务表名。默认 branch_table。
store.db.branchTable=branch_table
# db 模式全局锁表名。默认 lock_table。
store.db.lockTable=lock_table
# db 模式查询全局事务一次的最大条数。默认 100。
store.db.queryLimit=100
# db 模式 Sever 端事务管理全局锁存储表名。默认 distributed_lock，多 Sever 集群下保证同时只有一个 Sever 处理提交或回滚。1.5.1 版本新增。
#store.db.distributedLockTable

# 客户端与服务端传输方式。
# client 和 server 通信编解码方式。seata(ByteBuf)、protobuf、kryo、hession、fst，默认seata。
transport.serialization=seata
# client 和 server 通信数据压缩方式。none、gzip、zip、sevenz、bzip2、lz4、deflater、zstd。默认 ~ none。1.2.0 之前 ~ gzip。1.2.0 ~ zip、sevenz、bzip2。1.3.0 ~ lz4。1.4.1 ~ deflater。1.5.1 ~ zstd。
transport.compressor=none

# 是否启用 Metrics。默认 false 关闭，在 false 状态下，所有与 Metrics 相关的组件将不会被初始化，使得性能损耗最低。
metrics.enabled=false
# 指标注册器类型。Metrics 使用的指标注册器类型，默认为内置的 compact（简易）实现，这个实现中的 Meter 仅使用有限内存计数，性能高足够满足大多数场景；目前只能设置一个指标注册器实现。
metrics.registryType=compact
# 指标结果 Measurement 数据输出器列表。默认 prometheus，多个输出器使用英文逗号分割，例如"prometheus,jmx"，目前仅实现了对接 prometheus 的输出器。
metrics.exporterList=prometheus
# prometheus 输出器 Client 端口号。默认 9898。
metrics.exporterPrometheusPort=9898

# 事务、日志等配置。
# undo 保留天数。默认 7 天。log_status=1（附录 3）和未正常清理的 undo。
server.undo.logSaveDays=7
# undo 清理线程间隔时间。默认 86400000，单位毫秒。
server.undo.logDeletePeriod
# 二阶段提交重试超时时长，单位 ms, s, m, h, d, 对应毫秒，秒，分，小时，天，默认毫秒。默认值 -1 表示无限重试。公式: timeout >= now - globalTransactionBeginTime，true表示超时则不再重试（注: 达到超时时间后将不会做任何重试，有数据不一致风险，除非业务自行可校准数据，否者慎用)。
server.maxCommitRetryTimeout=-1
# 二阶段回滚重试超时时长，同 commit。
server.maxRollbackRetryTimeout=-1
# 二阶段提交未完成状态全局事务重试提交线程间隔时间，默认 1000，单位毫秒。
server.recovery.committingRetryPeriod=1000
# 二阶段异步提交状态重试提交线程间隔时间，默认 1000，单位毫秒。
server.recovery.asynCommittingRetryPeriod=1000
# 二阶段回滚状态重试回滚线程间隔时间，默认 1000，单位毫秒。
server.recovery.rollbackingRetryPeriod=1000
# 超时状态检测重试线程间隔时间，默认 1000，单位毫秒，检测出超时将全局事务置入回滚会话管理器。
server.recovery.timeoutRetryPeriod=1000
# 二阶段回滚超时后是否释放锁。默认 false。
server.rollbackRetryTimeoutUnlockEnable=false
# server.distributedLockExpireTime  # Sever 端事务管理全局锁超时时间。默认 10000，单位毫秒。1.5.1 版本新增。
# server.server.xaerNotaRetryTimeout  # 防止 XA 分支事务悬挂的重试超时时间。默认 60000，单位毫秒。1.5.1 版本新增。
# server.session.branchAsyncQueueSize  # 分支事务 Session 异步删除线程池队列大小。默认 5000。1.5.1 版本新增。
# server.session.enableBranchAsyncRemove	 # 分支事务 Session 异步删除开关。默认 false。1.5.1 版本新增。
# server.enableParallelRequestHandle  # 对于批量请求消息的并行处理开关。默认 false。1.5.2 版本新增。

创建数据库表。

特别注意：tc 服务在管理分布式事务时，需要记录事务相关数据到数据库中，你需要提前创建好这些表。

新建一个名为 seata 的数据库，运行 sql。

CREATE SCHEMA `seata` DEFAULT CHARACTER SET utf8mb4 ;

https://github.com/seata/seata/blob/develop/script/server/db/mysql.sql

这些表主要记录全局事务（global_table）、分支事务（branch_table）。
全局锁信息（lock_table）。

-- -------------------------------- 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_status_gmt_modified` (`status` , `gmt_modified`),
    KEY `idx_transaction_id` (`transaction_id`)
) ENGINE = InnoDB
  DEFAULT CHARSET = utf8mb4;

-- 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 = utf8mb4;

-- the table to store lock data
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),
    `status`         TINYINT      NOT NULL DEFAULT '0' COMMENT '0:locked ,1:rollbacking',
    `gmt_create`     DATETIME,
    `gmt_modified`   DATETIME,
    PRIMARY KEY (`row_key`),
    KEY `idx_status` (`status`),
    KEY `idx_branch_id` (`branch_id`),
    KEY `idx_xid` (`xid`)
) ENGINE = InnoDB
  DEFAULT CHARSET = utf8mb4;

CREATE TABLE IF NOT EXISTS `distributed_lock`
(
    `lock_key`       CHAR(20) NOT NULL,
    `lock_value`     VARCHAR(20) NOT NULL,
    `expire`         BIGINT,
    primary key (`lock_key`)
) ENGINE = InnoDB
  DEFAULT CHARSET = utf8mb4;

INSERT INTO `distributed_lock` (lock_key, lock_value, expire) VALUES ('AsyncCommitting', ' ', 0);
INSERT INTO `distributed_lock` (lock_key, lock_value, expire) VALUES ('RetryCommitting', ' ', 0);
INSERT INTO `distributed_lock` (lock_key, lock_value, expire) VALUES ('RetryRollbacking', ' ', 0);
INSERT INTO `distributed_lock` (lock_key, lock_value, expire) VALUES ('TxTimeoutCheck', ' ', 0);

启动 TC 服务。

进入 bin 目录，运行其中的 seata-server.bat 即可。

启动成功后，seata-server 应该已经注册到 nacos 注册中心了。

打开浏览器，访问 nacos 地址：http://localhost:8848，然后进入服务列表页面，可以看到 seata-tc-server 的信息。

在这里插入图片描述

3.3. 微服务集成 Seata。

我们以 order-service 为例来演示。

3.3.1. 引入依赖。

首先，在 order-service 中引入依赖。

<!-- seata。-->
<dependency>
  <groupId>com.alibaba.cloud</groupId>
  <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
  <exclusions>
    <!-- 版本较低，1.3.0，因此排除。-->
    <exclusion>
      <artifactId>seata-spring-boot-starter</artifactId>
      <groupId>io.seata</groupId>
    </exclusion>
  </exclusions>
</dependency>

<dependency>
	<groupId>io.seata</groupId>
	<artifactId>seata-spring-boot-starter</artifactId>
	<!-- seata starter 采用 1.4.2 版本。-->
	<version>${seata.version}</version>
</dependency>

3.3.2. 配置 TC 地址。

在 order-service 中的 application.yaml 中，配置 TC 服务信息，通过注册中心 nacos，结合服务名称获取 TC 地址。

seata:
  registry: # TC 服务注册中心的配置，微服务根据这些信息去注册中心获取 tc 服务地址。
    type: nacos # 注册中心类型 nacos。
    nacos:
      server-addr: 127.0.0.1:8848 # nacos 地址。
      namespace: "" # namespace，默认为空。
      group: DEFAULT_GROUP # 分组，默认是 DEFAULT_GROUP
      application: seata-tc-server # seata 服务名称。
      username: nacos
      password: nacos
  tx-service-group: seata-demo # 事务组名称。
  service:
    vgroup-mapping: # 事务组与 cluster 的映射关系。
      seata-demo: SH

微服务如何根据这些配置寻找 TC 的地址呢？

我们知道注册到 Nacos 中的微服务，确定一个具体实例需要四个信息。

namespace：命名空间。
group：分组。
application：服务名。
cluster：集群名。

以上四个信息，在刚才的 yaml 文件中都能找到。

在这里插入图片描述
namespace 为空，就是默认的 public。

结合起来，TC 服务的信息就是：public@DEFAULT_GROUP@seata-tc-server@SH，这样就能确定 TC 服务集群了。然后就可以去 Nacos 拉取对应的实例信息了。

可以看到 seata 日志。

INFO — [rverHandlerThread_1_1_500] i.s.c.r.processor.server.RegRmProcessor : RM register success,message:RegisterRMRequest{resourceIds=‘jdbc:mysql://192.168.142.186:3307/seata_demo’, applicationId=‘order-service’, transactionServiceGroup=‘seata-demo’},channel:[id: 0x0adf2a2f, L:/192.168.142.1:8091 - R:/192.168.142.1:57898],client version:1.4.2

3.3.3. 其它服务。

其它两个微服务也都参考 order-service 的步骤来做，完全一样。

4. 动手实践。

下面我们就一起学习下 Seata 中的四种不同的事务模式。

4.1. XA 模式。

XA 规范是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准，XA 规范描述了全局的 TM 与局部的 RM 之间的接口，几乎所有主流的数据库都对 XA 规范提供了支持。

4.1.1. 两阶段提交。

XA 是规范，目前主流数据库都实现了这种规范，实现的原理都是基于两阶段提交。

正常情况。

在这里插入图片描述
异常情况。

在这里插入图片描述
一阶段。

事务协调者通知每个事物参与者执行本地事务。
本地事务执行完成后报告事务执行状态给事务协调者，此时事务不提交，继续持有数据库锁。

二阶段。

事务协调者基于一阶段的报告来判断下一步操作。
- 如果一阶段都成功，则通知所有事务参与者，提交事务。
- 如果一阶段任意一个参与者失败，则通知所有事务参与者回滚事务。

4.1.2. Seata 的 XA 模型。

Seata 的 XA 模型对原始的 XA 模式做了简单的封装和改造，以适应自己的事务模型，基本架构如图。

在这里插入图片描述
RM 一阶段的工作。

① 注册分支事务到 TC。

② 执行分支业务 sql 但不提交。

③ 报告执行状态到 TC。

TC 二阶段的工作。

TC 检测各分支事务执行状态。

a.如果都成功，通知所有 RM 提交事务。

b.如果有失败，通知所有 RM 回滚事务。

RM 二阶段的工作。

接收 TC 指令，提交或回滚事务。

4.1.3. 优缺点。

XA 模式的优点是什么？

事务的强一致性，满足 ACID 原则。
常用数据库都支持，实现简单，并且没有代码侵入。

XA 模式的缺点是什么？

因为一阶段需要锁定数据库资源，等待二阶段结束才释放，性能较差。
依赖关系型数据库实现事务。

4.1.4. 实现 XA 模式。

Seata 的 starter 已经完成了 XA 模式的自动装配，实现非常简单，步骤如下。

1）修改 application.yml 文件（每个参与事务的微服务），开启 XA 模式。

seata:
  data-source-proxy-mode: XA

2）给发起全局事务的入口方法添加 @GlobalTransactional 注解。

本例中是 OrderServiceImpl 中的 create(); 方法。

在这里插入图片描述
3）重启服务并测试。

重启 order-service，再次测试，发现无论怎样，三个微服务都能成功回滚。

http://localhost:8082/order?userId=user2023123456789&commodityCode=1&count=20&money=200

04-09 01:31:15:297 INFO 5720 — [nio-8083-exec-3] c.g.a.service.impl.AccountServiceImpl : ~ AccountServiceImpl ~ deduct; ~ 扣款成功。
04-09 01:31:15:357 INFO 5720 — [h_RMROLE_1_4_16] i.s.c.r.p.c.RmBranchRollbackProcessor : rm handle branch rollback process:xid=192.168.142.1:8091:4224755455536721954,branchId=4224755455536721958,branchType=XA,resourceId=jdbc:mysql://192.168.142.186:3307/seata_demo,applicationData=null
04-09 01:31:15:357 INFO 5720 — [h_RMROLE_1_4_16] io.seata.rm.AbstractRMHandler : Branch Rollbacking: 192.168.142.1:8091:4224755455536721954 4224755455536721958 jdbc:mysql://192.168.142.186:3307/seata_demo
04-09 01:31:15:360 INFO 5720 — [h_RMROLE_1_4_16] i.s.rm.datasource.xa.ResourceManagerXA : 192.168.142.1:8091:4224755455536721954-4224755455536721958 was rollbacked
04-09 01:31:15:360 INFO 5720 — [h_RMROLE_1_4_16] io.seata.rm.AbstractRMHandler : Branch Rollbacked result: PhaseTwo_Rollbacked

4.2. AT 模式。

AT 模式同样是分阶段提交的事务模型，不过缺弥补了 XA 模型中资源锁定周期过长的缺陷。

4.2.1. Seata 的 AT 模型。

基本流程图。

在这里插入图片描述
阶段一 RM 的工作。

注册分支事务。
记录 undo-log（数据快照）。
执行业务 sql 并提交。
报告事务状态。

阶段二提交时 RM 的工作。

删除 undo-log 即可。

阶段二回滚时 RM 的工作。

根据 undo-log 恢复数据到更新前。

4.2.2. 流程梳理。

我们用一个真实的业务来梳理下 AT 模式的原理。

比如，现在又一个数据库表，记录用户余额。

id	money
1	100

其中一个分支业务要执行的 SQL 为

update tb_account
set money = money - 10
where id = 1

AT 模式下，当前分支事务执行流程如下。

一阶段。

1）TM 发起并注册全局事务到 TC。

2）TM 调用分支事务。

3）分支事务准备执行业务 SQL。

4）RM 拦截业务 SQL，根据 where 条件查询原始数据，形成快照。

{
  "id": 1,
  "money": 100
}

5）RM 执行业务 SQL，提交本地事务，释放数据库锁。此时 money = 90。

6）RM 报告本地事务状态给 TC。

二阶段。

1）TM 通知 TC 事务结束。

2）TC 检查分支事务状态。

a）如果都成功，则立即删除快照。

b）如果有分支事务失败，需要回滚。读取快照数据（{"id": 1, "money": 100}），将快照恢复到数据库。此时数据库再次恢复为 100。

流程图。

在这里插入图片描述

4.2.3. AT 与 XA 的区别。

简述 AT 模式与 XA 模式最大的区别是什么？

XA 模式一阶段不提交事务，锁定资源；AT 模式一阶段直接提交，不锁定资源。
XA 模式依赖数据库机制实现回滚；AT 模式利用数据快照实现数据回滚。
XA 模式强一致；AT 模式最终一致。

4.2.4. 脏写问题。

在多线程并发访问 AT 模式的分布式事务时，有可能出现脏写问题，如图。

在这里插入图片描述
解决思路就是引入了全局锁的概念。在释放 DB 锁之前，先拿到全局锁。避免同一时刻有另外一个事务来操作当前数据。

在这里插入图片描述
如果事务 2 是非 seata 管理的全局事务，会保存 before-image（100）和 after-image（90）两份快照。如果当前（80）和恢复后（after-image, 90）不一致，后人工介入。

4.2.5. 优缺点。

AT 模式的优点。

一阶段完成直接提交事务，释放数据库资源，性能比较好。
利用全局锁实现读写隔离。
没有代码侵入，框架自动完成回滚和提交。

AT 模式的缺点。

两阶段之间属于软状态，属于最终一致。
框架的快照功能会影响性能，但比 XA 模式要好很多。

4.2.6. 实现 AT 模式。

AT 模式中的快照生成、回滚等动作都是由框架自动完成，没有任何代码侵入，因此实现非常简单。

只不过，AT 模式需要一个表来记录全局锁、另一张表来记录数据快照 undo_log。

1）导入数据库表，记录全局锁。

导入 sql 文件：seata-at.sql，其中 lock_table 导入到 TC 服务关联的数据库，undo_log 表导入到微服务关联的数据库。


-- the table to store lock data
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),
    `status`         TINYINT      NOT NULL DEFAULT '0' COMMENT '0:locked ,1:rollbacking',
    `gmt_create`     DATETIME,
    `gmt_modified`   DATETIME,
    PRIMARY KEY (`row_key`),
    KEY `idx_status` (`status`),
    KEY `idx_branch_id` (`branch_id`),
    KEY `idx_xid` (`xid`)
) ENGINE = InnoDB
  DEFAULT CHARSET = utf8mb4;

-- 注意此处 0.3.0+ 增加唯一索引 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;

2）修改 application.yml 文件，将事务模式修改为 AT 模式即可。

seata:
  data-source-proxy-mode: AT  # 默认就是 AT。

3）重启服务并测试。

04-09 02:14:54:383  INFO 17928 --- [h_RMROLE_1_1_16] i.s.c.r.p.c.RmBranchRollbackProcessor    : rm handle branch rollback process:xid=192.168.142.1:8091:4224755455536721970,branchId=4224755455536721972,branchType=AT,resourceId=jdbc:mysql://192.168.142.186:3307/seata_demo,applicationData=null
04-09 02:14:54:385  INFO 17928 --- [h_RMROLE_1_1_16] io.seata.rm.AbstractRMHandler            : Branch Rollbacking: 192.168.142.1:8091:4224755455536721970 4224755455536721972 jdbc:mysql://192.168.142.186:3307/seata_demo
04-09 02:14:54:439  INFO 17928 --- [h_RMROLE_1_1_16] i.s.r.d.undo.AbstractUndoLogManager      : xid 192.168.142.1:8091:4224755455536721970 branch 4224755455536721972, undo_log deleted with GlobalFinished
04-09 02:14:54:440  INFO 17928 --- [h_RMROLE_1_1_16] io.seata.rm.AbstractRMHandler            : Branch Rollbacked result: PhaseTwo_Rollbacked
04-09 02:14:54:471  INFO 17928 --- [nio-8082-exec-2] i.seata.tm.api.DefaultGlobalTransaction  : Suspending current transaction, xid = 192.168.142.1:8091:4224755455536721970
04-09 02:14:54:471  INFO 17928 --- [nio-8082-exec-2] i.seata.tm.api.DefaultGlobalTransaction  : [192.168.142.1:8091:4224755455536721970] rollback status: Rollbacked
04-09 02:14:54:472 ERROR 17928 --- [nio-8082-exec-2] o.a.c.c.C.[.[.[/].[dispatcherServlet]    : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is java.lang.RuntimeException: {"timestamp":"2023-04-08T18:14:54.272+00:00","status":500,"error":"Internal Server Error","message":"","path":"/storage/1/20"}] with root cause

4.3. TCC 模式。

TCC 模式与 AT 模式非常相似，每阶段都是独立事务，不同的是 TCC 通过人工编码来实现数据恢复。需要实现三个方法。

Try：资源的检测和预留。
Confirm：完成资源操作业务；要求 Try 成功 Confirm 一定要能成功。
Cancel：预留资源释放，可以理解为 try 的反向操作。

4.3.1. 流程分析。

举例，一个扣减用户余额的业务。假设账户 A 原来余额是 100，需要余额扣减 30 元。

阶段一（Try）：检查余额是否充足，如果充足则冻结金额增加 30 元，可用余额扣除 30。

初始余额。

在这里插入图片描述
余额充足，可以冻结。

在这里插入图片描述
此时，总金额 = 冻结金额 + 可用金额，数量依然是 100 不变。事务直接提交无需等待其它事务。

阶段二（Confirm）：假如要提交（Confirm），则冻结金额扣减 30。

确认可以提交，不过之前可用金额已经扣减过了，这里只要清除冻结金额就好了。

在这里插入图片描述
此时，总金额 = 冻结金额 + 可用金额 = 0 + 70 = 70 元。

阶段二（Canncel）：如果要回滚（Cancel），则冻结金额扣减 30，可用余额增加 30，需要回滚，那么就要释放冻结金额，恢复可用金额。

在这里插入图片描述

4.3.2. Seata 的 TCC 模型。

Seata 中的 TCC 模型依然延续之前的事务架构，如图。

在这里插入图片描述

4.3.3. 优缺点。

TCC 模式的每个阶段是做什么的？

Try：资源检查和预留。
Confirm：业务执行和提交。
Cancel：预留资源的释放。

TCC 的优点是什么？

一阶段完成直接提交事务，释放数据库资源，性能好。
相比 AT 模型，无需生成快照，无需使用全局锁，性能最强。
不依赖数据库事务，而是依赖补偿操作，可以用于非事务型数据库。

TCC 的缺点是什么？

有代码侵入，需要人为编写 try、Confirm 和 Cancel 接口，太麻烦。
软状态，事务是最终一致。
需要考虑 Confirm 和 Cancel 的失败情况，做好幂等处理。

4.3.4. 事务悬挂和空回滚。

1）空回滚。

当某分支事务的 try 阶段阻塞时，可能导致全局事务超时而触发二阶段的 cancel 操作。在未执行 try 操作时先执行了 cancel 操作，这时 cancel 不能做回滚，就是空回滚。

如图。

在这里插入图片描述
执行 cancel 操作时，应当判断 try 是否已经执行，如果尚未执行，则应该空回滚。

2）业务悬挂。

对于已经空回滚的业务，之前被阻塞的 try 操作恢复，继续执行 try，就永远不可能 confirm 或 cancel，事务一直处于中间状态，这就是业务悬挂。

执行 try 操作时，应当判断 cancel 是否已经执行过了，如果已经执行，应当阻止空回滚后的 try 操作，避免悬挂。

4.3.5. 实现 TCC 模式。

解决空回滚和业务悬挂问题，必须要记录当前事务状态，是在 try、还是 cancel？

1）思路分析。

这里我们定义一张表。

CREATE TABLE `account_freeze_tbl` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键 id。',
  `xid` varchar(45) NOT NULL COMMENT '全局事务 id。',
  `user_id` varchar(45) NOT NULL COMMENT '用户 id。',
  `freeze_money` int(11) NOT NULL DEFAULT '0' COMMENT '冻结金额。',
  `state` int(1) NOT NULL DEFAULT '-1' COMMENT '事务状态。0 ~ try，1 ~ confirm，2 ~ cancel。',
  `db_insert_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 'db_insert_time。',
  `db_update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 'db_update_time。',
  `db_deleted` int(1) NOT NULL DEFAULT '0' COMMENT '逻辑删除。',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

其中。

xid：是全局事务 id。
freeze_money：用来记录用户冻结金额。
state：用来记录事务状态。

那此时，我们的业务该怎么做呢？

Try 业务。
- 记录冻结金额和事务状态到 account_freeze 表。
- 扣减 account 表可用金额。
Confirm 业务。
- 根据 xid 删除 account_freeze 表的冻结记录。
Cancel 业务。
- 修改 account_freeze 表，冻结金额为 0，state 为 2。
- 修改 account 表，恢复可用金额。
如何判断是否空回滚？
- cancel 业务中，根据 xid 查询 account_freeze，如果为 null 则说明 try 还没做，需要空回滚。
如何避免业务悬挂？
- try 业务中，根据 xid 查询 account_freeze ，如果已经存在则证明 Cancel 已经执行，拒绝执行 try 业务。

接下来，我们改造 account-service，利用 TCC 实现余额扣减功能。

2）声明 TCC 接口。

TCC 的 Try、Confirm、Cancel 方法都需要在接口中基于注解来声明，

我们在 account-service 项目中的 com.geek.account.service 包中新建一个接口，声明 TCC 三个接口。

package com.geek.account.service;

import io.seata.rm.tcc.api.BusinessActionContext;
import io.seata.rm.tcc.api.BusinessActionContextParameter;
import io.seata.rm.tcc.api.LocalTCC;
import io.seata.rm.tcc.api.TwoPhaseBusinessAction;

/**
 * @author geek
 */
@LocalTCC
public interface IAccountTccService {

    /**
     * try 逻辑。
     * void deduct(String userId, Integer money);
     * // @TwoPhaseBusinessAction 中的 name 属性要与当前方法名一致，用于指定 try 逻辑对应的方法。
     *
     * @param userId
     * @param money
     */
    @TwoPhaseBusinessAction(name = "business", commitMethod = "commitMethodName", rollbackMethod = "rollbackMethodName")
    void business(@BusinessActionContextParameter(paramName = "userId") String userId,
                  @BusinessActionContextParameter(paramName = "money") Integer money);

    /**
     * 二阶段 confirm 确认方法。
     * 可以另命名，但要保证 commitMethod 一致。
     *
     * @param businessActionContext 上下文，可以传递 try 方法的参数。
     * @return 执行是否成功。
     */
    boolean commitMethodName(BusinessActionContext businessActionContext);

    /**
     * 二阶段回滚方法，要保证与 rollbackMethod 一致。
     *
     * @param businessActionContext
     * @return
     */
    boolean rollbackMethodName(BusinessActionContext businessActionContext);

}

3）编写实现类。

在 account-service 服务中的 com.geek.account.service.impl 包下新建一个类，实现 TCC 业务。

package com.geek.account.service.impl;

import com.geek.account.dataobject.AccountFreeze;
import com.geek.account.mapper.IAccountFreezeMapper;
import com.geek.account.mapper.IAccountMapper;
import com.geek.account.service.IAccountTccService;
import io.seata.core.context.RootContext;
import io.seata.rm.tcc.api.BusinessActionContext;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

import java.util.Objects;

/**
 * @author geek
 */
@Slf4j
@Service
public class AccountTccServiceImpl implements IAccountTccService {

    @Autowired
    private IAccountMapper accountMapper;
    @Autowired
    private IAccountFreezeMapper accountFreezeMapper;

    /**
     * try 逻辑。
     * void deduct(String userId, Integer money);
     * // @TwoPhaseBusinessAction 中的 name 属性要与当前方法名一致，用于指定 try 逻辑对应的方法。
     *
     * @param userId
     * @param money
     */
    @Override
    public void business(String userId, Integer money) {
        // 获取事务 id。
        String xid = RootContext.getXID();
        log.info(" ~ AccountTccServiceImpl ~ business; ~ xid ~ {}" + "\r\n ~ [userId ~ {}, money ~ {}]",
                xid, userId, money);

        // 判断 accountFreeze 中是否有冻结记录。如果有，一定是 CANCEL 执行过了，拒绝业务。
        AccountFreeze accountFreezeDb = this.accountFreezeMapper.selectById(xid);
        log.info(" ~ AccountTccServiceImpl ~ business; ~ accountFreezeDb ~ {}" + "\r\n ~ xid ~ {}" + "\r\n ~ [userId ~ {}, money ~ {}]",
                accountFreezeDb, xid, userId, money);
        if (!Objects.isNull(accountFreezeDb)) {
            // CANCEL 执行过了，拒绝业务。
            return;
        }

        // 扣减可用余额。
        Integer deduct = this.accountMapper.deduct(userId, money);
        log.info(" ~ AccountTccServiceImpl ~ business; ~ deduct ~ {}" + "\r\n ~ [userId ~ {}, money ~ {}]",
                deduct, userId, money);
        // 记录冻结金额，事务状态。
        AccountFreeze accountFreeze = new AccountFreeze();
        accountFreeze.setUserId(userId);
        accountFreeze.setFreezeMoney(money);
        accountFreeze.setState(AccountFreeze.State.TRY);
        accountFreeze.setXid(xid);
        int insert = this.accountFreezeMapper.insert(accountFreeze);
        log.info(" ~ AccountTccServiceImpl ~ business; ~ insert ~ {}" + "\r\n ~ accountFreeze ~ {}" + "\r\n ~ [userId ~ {}, money ~ {}]",
                insert, accountFreeze, userId, money);
    }

    /**
     * 二阶段 confirm 确认方法。
     * 可以另命名，但要保证 commitMethod 一致。
     *
     * @param businessActionContext 上下文，可以传递 try 方法的参数。
     * @return 执行是否成功。
     */
    @Override
    public boolean commitMethodName(BusinessActionContext businessActionContext) {
        // 获取事务 id。
        String xid = businessActionContext.getXid();
        log.info(" ~ AccountTccServiceImpl ~ confirm; ~ xid ~ {}" + "\r\n ~ [businessActionContext ~ {}]",
                xid, businessActionContext);
        // 根据 id 删除冻结记录。
        int deleteById = this.accountFreezeMapper.deleteById(xid);
        log.info(" ~ AccountTccServiceImpl ~ confirm; ~ deleteById ~ {}" + "\r\n ~ [businessActionContext ~ {}]",
                deleteById, businessActionContext);
        return deleteById == 1;
    }

    /**
     * 二阶段回滚方法，要保证与 rollbackMethod 一致。
     *
     * @param businessActionContext
     * @return
     */
    @Override
    public boolean rollbackMethodName(BusinessActionContext businessActionContext) {
        // 查询冻结记录。
        String xid = businessActionContext.getXid();
        log.info(" ~ AccountTccServiceImpl ~ cancel; ~ xid ~ {}" + "\r\n ~ [businessActionContext ~ {}]",
                xid, businessActionContext);
        AccountFreeze accountFreeze = this.accountFreezeMapper.selectById(xid);
        log.info(" ~ AccountTccServiceImpl ~ cancel; ~ accountFreeze ~ {}" + "\r\n ~ [businessActionContext ~ {}]",
                accountFreeze, businessActionContext);
        // 空回滚判断。判断 accountFreeze 是否为 null。为 null 证明 try 没有执行，需要空回滚。
        if (Objects.isNull(accountFreeze)) {
            // 证明 try 没有执行，需要空回滚。

            AccountFreeze accountFreeze1 = new AccountFreeze();
            Object userId = businessActionContext.getActionContext("userId");
            accountFreeze1.setUserId(userId.toString());
            accountFreeze1.setFreezeMoney(0);
            accountFreeze1.setState(AccountFreeze.State.CANCEL);
            accountFreeze1.setXid(xid);
            int insert = this.accountFreezeMapper.insert(accountFreeze1);
            log.info(" ~ AccountTccServiceImpl ~ rollbackMethodName; ~ insert ~ {}" + "\r\n ~ accountFreeze1 ~ {}" + "\r\n ~ [businessActionContext ~ {}]",
                    insert, accountFreeze1, businessActionContext);
            return true;
        }

        // 幂等。
        if (accountFreeze.getState() == AccountFreeze.State.CANCEL) {
            // 已经处理过一次 CANCEL 了，无需重复处理。
            return true;
        }

        // 恢复可用余额。
        Integer refund = this.accountMapper.refund(accountFreeze.getUserId(), accountFreeze.getFreezeMoney());
        log.info(" ~ AccountTccServiceImpl ~ cancel; ~ refund ~ {}" + "\r\n ~ accountFreeze ~ {}" + "\r\n ~ [businessActionContext ~ {}]",
                refund, accountFreeze, businessActionContext);
        // 将冻结金额清零，状态改为 CANCEL。
        accountFreeze.setFreezeMoney(0);
        accountFreeze.setState(AccountFreeze.State.CANCEL);
        int updateById = this.accountFreezeMapper.updateById(accountFreeze);
        log.info(" ~ AccountTccServiceImpl ~ cancel; ~ updateById ~ {}" + "\r\n ~ accountFreeze ~ {}" + "\r\n ~ [businessActionContext ~ {}]",
                updateById, accountFreeze, businessActionContext);
        return updateById == 1;
    }

}

package com.geek.account.mapper;

import com.baomidou.mybatisplus.core.mapper.BaseMapper;
import com.geek.account.dataobject.Account;
import org.apache.ibatis.annotations.Param;
import org.apache.ibatis.annotations.Update;

/**
 * @author geek
 */
public interface IAccountMapper extends BaseMapper<Account> {

    @Update("update `account_tbl` set `money` = `money` - #{money} where `user_id` = #{userId}")
    Integer deduct(@Param("userId") String userId, @Param("money") Integer money);

    @Update("update `account_tbl` set `money` = `money` + #{money} where `user_id` = #{userId}")
    Integer refund(@Param("userId") String userId, @Param("money") Integer money);

}

package com.geek.account.controller;

import com.geek.account.service.IAccountService;
import com.geek.account.service.IAccountTccService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

/**
 * @author geek
 */
@RestController
@RequestMapping("/account")
public class AccountController {

    @Autowired
    private IAccountTccService accountTccService;

    @Autowired
    private IAccountService accountService;

    @RequestMapping("/{userId}/{money}")
    public ResponseEntity<Void> deduct(@PathVariable("userId") String userId,
                                       @PathVariable("money") Integer money) {
        this.accountService.deduct(userId, money);
        return ResponseEntity.noContent().build();
    }

    @RequestMapping("businessTCC/{userId}/{money}")
    public ResponseEntity<Void> business(@PathVariable("userId") String userId,
                                         @PathVariable("money") Integer money) {
        this.accountTccService.business(userId, money);
        return ResponseEntity.noContent().build();
    }

}

4.4. SAGA 模式。

Saga 模式是 Seata 即将开源的长事务解决方案，将由蚂蚁金服主要贡献。

其理论基础是 Hector & Kenneth 在 1987 年发表的论文Sagas。

Seata 官网对于 Saga 的指南：https://seata.io/zh-cn/docs/user/saga.html。

4.4.1. 原理。

在 Saga 模式下，分布式事务内有多个参与者，每一个参与者都是一个冲正补偿服务，需要用户根据业务场景实现其正向操作和逆向回滚操作。

分布式事务执行过程中，依次执行各参与者的正向操作，如果所有正向操作均执行成功，那么分布式事务提交。如果任何一个正向操作执行失败，那么分布式事务会去退回去执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。

在这里插入图片描述
Saga 也分为两个阶段。

一阶段：直接提交本地事务。
二阶段：成功则什么都不做；失败则通过编写补偿业务来回滚。

4.4.2. 优缺点。

优点。

事务参与者可以基于事件驱动实现异步调用，吞吐高。
一阶段直接提交事务，无锁，性能好。
不用编写 TCC 中的三个阶段，实现简单。

缺点。

软状态持续时间不确定，时效性差。
没有锁，没有事务隔离，会有脏写。

4.5. 四种模式对比。

我们从以下几个方面来对比四种实现。

一致性：能否保证事务的一致性？强一致还是最终一致？
隔离性：事务之间的隔离性如何？
代码侵入：是否需要对业务代码改造？
性能：有无性能损耗？
场景：常见的业务场景。

	XA	AT	TCC	SAGA
一致性	强一致	弱一致	弱一致	最终一致
隔离性	完全隔离	基于全局锁隔离	基于资源预留隔离	无隔离
代码侵入	无	无	有，要编写三个接口	有，要编写状态机和补偿业务
性能	差	好	非常好	非常好
场景	对一致性、隔离性有高要求的业务。	基于关系型数据库的大多数分布式事务场景都可以。	* 对性能要求较高的事务。 * 有非关系型数据库要参与的事务。	* 业务流程长、业务流程多。 * 参与者包含其它公司或遗留系统服务，无法提供 TCC 模式要求的三个接口。