分布式事务-seata框架

标签：事务 seata 框架数据库 account freeze TC 分布式

文章目录

分布式事务
0.学习目标
1.分布式事务问题

1.1.本地事务
1.2.分布式事务
1.3.演示分布式事务问题

2.理论基础

2.1.CAP定理

2.1.1.一致性
2.1.2.可用性
2.1.3.分区容错
2.1.4.矛盾

2.2.BASE理论
2.3.解决分布式事务的思路

3.初识Seata

3.1.Seata的架构
3.2.部署TC服务
3.3.微服务集成Seata

3.3.1.引入依赖
3.3.2.配置TC地址
3.3.3.其它服务

4.动手实践

4.1.XA模式

4.1.1.两阶段提交
4.1.2.Seata的XA模型
4.1.3.优缺点
4.1.4.实现XA模式

4.2.AT模式 (Seata默认模式)

4.2.1.Seata的AT模型
4.2.2.流程梳理
4.2.3.AT与XA的区别
4.2.4.脏写问题
4.2.5.优缺点
4.2.6.实现AT模式

4.3.TCC模式

4.3.1.流程分析
4.3.2.Seata的TCC模型
4.3.3.优缺点
4.3.4.事务悬挂和空回滚

1）空回滚
2）业务悬挂

4.3.5.实现TCC模式

1）思路分析
2）声明TCC接口
2.1) 查看一下已经提供好的实体类和Mapper
3）编写实现类
测试

4.4.SAGA模式

4.4.1.原理
4.4.2.优缺点

4.5.四种模式对比

5.高可用

5.1.高可用架构模型
5.2.实现高可用

分布式事务

0.学习目标

1.分布式事务问题

1.1.本地事务

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

分布式事务-seata框架_回滚

1.2.分布式事务

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

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

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

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

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

分布式事务-seata框架_数据库_02

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

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

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

1.3.演示分布式事务问题

链接：https://pan.baidu.com/s/1MsbbF0rseNy74r7lLPbpwQ 提取码：hzan

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

1）创建数据库，名为seata_demo，然后导入课前资料提供的SQL文件：

分布式事务-seata框架_数据库_03

先创建数据库：

create database seata_demo;
use seata_demo;

分布式事务-seata框架_分布式_04

再导入sql文件

分布式事务-seata框架_分布式_05

分布式事务-seata框架_回滚_06

2）导入课前资料提供的微服务：

分布式事务-seata框架_分布式_07

微服务结构如下：

分布式事务-seata框架_分布式事务_08

注意application.yml里数据的密码改成自己的

其中：

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

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

3）启动nacos、所有微服务

项目依赖nacos，所以需要启动nacos
并启动项目下面所有的3个微服务

单机启动nacos

startup.cmd -m standalone

启动3个微服务

分布式事务-seata框架_数据库_09

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

请求如下：

curl --location --request POST 'http://localhost:8082/order?userId=user202103032042012&commodityCode=100202003032041&count=20&money=200'

http://localhost:8082/order?userId=user202103032042012&commodityCode=100202003032041&count=20&money=200

如图：

分布式事务-seata框架_回滚_10

注意改成POST提交，否则： 405, Method Not Allowed

分布式事务-seata框架_分布式_11

分布式事务-seata框架_分布式_12

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

分布式事务-seata框架_数据库_13

(库存不足，库存回滚了，但是余额够的，没有回滚。就导致余额少了，库存却没有少，严重的问题。)

2.理论基础

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

2.1.CAP定理

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

Consistency（一致性）
Availability（可用性）
Partition tolerance （分区容错性）

分布式事务-seata框架_数据库_14

它们的第一个字母分别是 C、A、P。

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

2.1.1.一致性

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

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

分布式事务-seata框架_分布式事务_15

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

分布式事务-seata框架_回滚_16

要想保住一致性，就必须实现node01 到 node02的数据同步：

分布式事务-seata框架_回滚_17

2.1.2.可用性

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

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

分布式事务-seata框架_分布式事务_18

当有部分节点因为网络故障或其它原因无法访问时，代表节点不可用：（下面node03就失去了可用性）

分布式事务-seata框架_分布式_19

2.1.3.分区容错

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

分布式事务-seata框架_分布式_20

Tolerance（容错）：在集群出现分区时，整个系统也要持续对外提供服务

容错滴话，访问node03和访问node01&02的结果肯定不一样，失去了一致性
当然可以让node03暂停服务一会儿，等到网络恢复和node01&02的访问，保证了一致性；但是等待途中，node03失去了可用性
所以一致性和分区容错性这里就不能同时满足，验证了CAP 定理。

2.1.4.矛盾

在分布式系统中，系统间的网络不能100%保证健康，一定会有故障的时候，而服务有必须对外保证服务。因此Partition Tolerance不可避免。 (P既然一定要实现，分区问题也一定会发生，根据CAP原理，C和A只能选择其一了)

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

分布式事务-seata框架_分布式事务_21

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

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

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

小结

P必须保证，CA只能保证一个，但是C和A都很重要，我一个都不想放弃，怎么办？BASE理论可以解决这个问题啦

2.2.BASE理论

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

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

BASE就是在做取和舍，一阴一阳谓之道，万物都有得有失

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

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

AP模式：各子事务分别执行和提交，允许出现结果不一致(软状态)，然后采用弥补措施恢复数据即可，实现最终一致。（都执行完后各个微服务之间通个气，都成功了吗？不好，有人失败了，已经提交了怎么办？再改回来呗，执行一个相反的操作比如恢复快照）
CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中(部分不可用)，处于弱可用状态。

Consistency（一致性）
Availability（可用性）
Partition tolerance （分区容错性）

但不管是哪一种模式，都需要在子系统事务之间互相通讯，协调事务状态，也就是需要一个事务协调者(TC)：

分布式事务-seata框架_分布式_22

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

小结

3.初识Seata

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

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

https://seata.io/zh-cn/index.html

分布式事务-seata框架_数据库_23

3.1.Seata的架构

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

TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。
TM (Transaction Manager) - 事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务。
RM (Resource Manager) - 资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。 (TC发现都成功了，就通知他们提交，发现至少有一个失败，就通知他们都回滚)

整体的架构如图：

分布式事务-seata框架_分布式事务_24

上面只是基本模型，并不是最终解决方案，解决方案有下面4种(根据不同的策略实施的，eg:强一致、最终一致)

Seata基于上述架构提供了四种不同的分布式事务解决方案：

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

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

3.2.部署TC服务

参考这篇博客： seata 的部署和集成

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>

${seata.version} 是父工程的pom.xml里配置的变量

3.3.2.配置TC地址

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

seata:
  registry: # TC服务注册中心的配置，微服务根据这些信息去注册中心获取tc服务地址
    type: nacos # 注册中心类型 nacos
    nacos:
      server-addr: 127.0.0.1:8848 # nacos地址 127.0.0.1就是localhost
      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文件中都能找到：

分布式事务-seata框架_分布式_25

namespace为空，就是默认的public

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

修改完成后重启，若报错

Error creating bean with name 'globalTransactionScanner' defined in class path resource [io/seata/spring/boot/autoconfigure/SeataAutoConfiguration.class]: Bean instantiation via factory method failed; nested

请切换到jdk8。不要用jdk17，很多类被弃用了

3.3.3.其它服务

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

同时重启3个微服务，会看到3个RM和3个TM的注册信息，TM注册比较慢，请耐心等待

4.动手实践

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

4.1.XA模式

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

4.1.1.两阶段提交

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

正常情况：

分布式事务-seata框架_分布式事务_27

第一阶段：TC通知RM执行事务，但是RM执行完不要提交，而是返回给TC一个就绪状态

第二阶段：TC收到了所有RM的就绪状态，那么就可以通知所有的RM提交事务了

XA是非常早的一个标准，所以几乎主流数据库，如mysql、oracle, 都已经实现了XA标准。也就是数据库本身已经实现了RM了，这也是为何之前控制台有显示TM、RM注册成功的日志了，数据库已经实现了，不需要我们实现了，我们直接用就行了。

异常情况：

分布式事务-seata框架_回滚_28

第一阶段：TC通知RM执行事务，但是RM执行完不要提交，而是返回给TC一个就绪状态

第二阶段：TC收到了有RM的失败状态，那么就可以通知所有就绪的RM都回滚了

一阶段：

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

二阶段：

事务协调者基于一阶段的报告来判断下一步操作

如果一阶段都成功，则通知所有事务参与者，提交事务
如果一阶段任意一个参与者失败，则通知所有事务参与者回滚事务

XA就是基于数据库本身的特性做的分布式事务
满足ACID,是为强一致性

4.1.2.Seata的XA模型

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

Seata和数据库都有RM，所以Seata的RM这里就只是做一下代理(代理一下数据库RM的请求)，提交给TC，剩下的都交给RM来做（如何和TC交互我得重写一下，也就是做了些优化）

分布式事务-seata框架_数据库_29

执行sql,提交or回滚，都是数据库的RM来做的，RM最幸苦，一线工人
不看TM和XA其实就完全一样了，只是单纯多了一个TM，进行事务注册、管理，变得更加健壮了

RM一阶段的工作：

① 注册分支事务到TC

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

③ 报告执行状态到TC

TC二阶段的工作：

TC检测各分支事务执行状态
a.如果都成功，通知所有RM提交事务
b.如果有失败，通知所有RM回滚事务

RM二阶段的工作：

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

4.1.3.优缺点

XA模式的优点是什么？

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

XA模式的缺点是什么？

因为一阶段需要锁定数据库资源，等待二阶段结束才释放(一直占用着数据库锁)，性能较差
依赖关系型数据库实现事务 (Redis数据库就没法做了)

4.1.4.实现XA模式

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

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

seata:
  data-source-proxy-mode: XA

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

本例中是OrderServiceImpl中的create方法.

分布式事务-seata框架_分布式事务_30

实现起来其实很简单
1）一行配置，开启XA模式的分布式事务
2）将原来的@Transactional注解换成@GlobalTransactional 开启全局事务
就OK啦

3）重启服务并测试

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

分布式事务-seata框架_分布式_31

库存和订单微服务直接抛异常

分布式事务-seata框架_回滚_32

账户管理微服务，先是扣款成功，后来又回滚了

分布式事务-seata框架_回滚_33

查看数据库，所有数据都没变

4.2.AT模式 (Seata默认模式)

AT模式：最终一致的分阶段事务模式，无业务侵入，也是Seata的默认模式

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

4.2.1.Seata的AT模型

基本流程图：

分布式事务-seata框架_回滚_34

阶段一RM的工作：

注册分支事务
记录undo-log（数据快照）(2. 执行完sql直接提交，万一有其他分支事务失败了，也没办法回滚了，怎么办？恢复到这里记录的快照就行了哇)
执行业务sql并提交（1. RM执行完sql直接提交事务，而不是等待对方执行，不用等待也就不用占用数据库锁了，牺牲了一点一致性(弱状态)，但是解决XA性能差的问题）
报告事务状态

阶段二提交时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

流程图：

分布式事务-seata框架_数据库_35

以上所有过程都是0倾入的，框架自动完成，程序员不用管这些非业务需求。多好，懂原理会面试即可，实际开发时直接用就行了。

4.2.3.AT与XA的区别

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

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

4.2.4.脏写问题

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

分布式事务-seata框架_回滚_36

原因：整体上两组事务之间没有隔离。
解决：两组事务之间做下隔离就行了，也就是弄一个全局锁
全局锁保证了数据库某行数据只能被某一个事务操作，其他事务在全局锁释放之前不允许操作（两个锁，同时工作，解决脏写问题）（两个锁同时使用可能造成死锁问题，这里的解决方式是全局锁等待300ms还获取不到自动放弃，自动回滚，死锁就自动解除了）

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

分布式事务-seata框架_分布式_37

中间的死锁状态：事务1持有全局锁，等待获取DB锁；事务2持有DB锁，等待获取全局锁
解决死锁：获取全局锁300ms后还未获取到，自动释放，直接回滚，也就是事务2自我放弃了这次事务
全局上看：事务1执行对改行数据的操作时，其他任何seata事务都不要来干扰，直到我删除快照
注意：
全局锁是TC管理的锁，粒度比DB锁(数据库管理的锁)细多了，只会阻止seata里的事务，不会阻止其他事务，其他事务修改这张表的其他字段是可以的。数据库锁一旦锁定，所有其他业务都无法访问这行数据任何字段了。
这种细粒度锁的设计，确实可能存在其他非seata事务修改了事务1的money字段，但是可能性太低了。低也不行啊，需要避免。AT当然做了避免啦

避免其他非seata事务，不受TC全局锁的约束，提交和恢复中间修改了数据，导致了脏写。
方法：保存两个快照，更新前和更新后的快照，恢复快照之前将当前值和更新后的快照对比，不一样发现中途有别的事务修改了数据，不能直接恢复了（再恢复就脏写了），抛异常提醒用户吧

分布式事务-seata框架_分布式_38

4.2.5.优缺点

AT模式的优点：

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

AT模式的缺点：

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

4.2.6.实现AT模式

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

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

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

导入课前资料提供的Sql文件：seata-at.sql，其中lock_table导入到TC服务关联的数据库，undo_log表导入到微服务关联的数据库：

分布式事务-seata框架_数据库_39

先在TC的数据库里新建lock_table表 (用来记录全局锁)

TC是一个本地软件，但是也注册到nacos注册中心了，并且TC的配置文件也给nacos管理(nacos端新建了一个配置文件seataServer.properties)，nacos端配置文件里配置了这个数据库的地址(以及各种连接信息)，TC协调分布式事务时需要保存一些信息，就保存在这个表里

分布式事务-seata框架_数据库_40

DROP TABLE IF EXISTS `lock_table`;
CREATE TABLE `lock_table`  (
  `row_key` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
  `xid` varchar(96) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `transaction_id` bigint(20) NULL DEFAULT NULL,
  `branch_id` bigint(20) NOT NULL,
  `resource_id` varchar(256) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `table_name` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `pk` varchar(36) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `gmt_create` datetime NULL DEFAULT NULL,
  `gmt_modified` datetime NULL DEFAULT NULL,
  PRIMARY KEY (`row_key`) USING BTREE,
  INDEX `idx_branch_id`(`branch_id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;

分布式事务-seata框架_分布式事务_41

再在微服务关联的数据库里新建undo_log表（用来记录数据快照）

分布式事务-seata框架_分布式_42

DROP TABLE IF EXISTS `undo_log`;
CREATE TABLE `undo_log`  (
  `branch_id` bigint(20) NOT NULL COMMENT 'branch transaction id',
  `xid` varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT 'global transaction id',
  `context` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci 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 INDEX `ux_undo_log`(`xid`, `branch_id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci COMMENT = 'AT transaction mode undo table' ROW_FORMAT = Compact;

分布式事务-seata框架_分布式事务_43

2）修改application.yml文件，将事务模式修改为AT模式即可：（所有的3个微服务都要改）

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

虽然原理复杂，但是用起来好简单，提供必备的数据库，然后配置+注解就行了

3）重启服务并测试

postman测试

分布式事务-seata框架_数据库_44

查看数据库，所有数据正常：数据没有任何变化，说明事务生效了 (undo_log也没有新数据，为什么？快照删除了呗，非要看得打断点的形式看了。 seata数据库下所有表的数据都是，事务结束都会被删除，想看，自己打断点了)
查看IDEA日志：
StorageApplication库存微服务肯定报错

分布式事务-seata框架_分布式事务_45

OrderApplication订单微服务也报错

分布式事务-seata框架_回滚_46

AccountApplication扣款微服务没有保存，但是回滚了：

分布式事务-seata框架_数据库_47

XA和AT模式都加了锁，都有性能的损失，TCC模式主要就是为了追求极致的性能，就没有锁了。

4.3.TCC模式

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

Try：资源的检测和预留； (我需要修改某个资源时，先给他拿过来留着，你们都先别动)
Confirm：完成资源操作业务；要求 Try 成功 Confirm 一定要能成功。
Cancel：预留资源释放，可以理解为try的反向操作。

AT要先生成快照，性能损失了，这点上TCC胜过AT

上面说得比较抽象，下面举例说明：

4.3.1.流程分析

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

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

初始余额：

分布式事务-seata框架_回滚_48

余额充足，可以冻结：

分布式事务-seata框架_分布式_49

此时，总金额 = 冻结金额 + 可用金额，数量依然是100不变。事务直接提交无需等待其它事务。

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

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

分布式事务-seata框架_分布式_50

此时，总金额 = 冻结金额 + 可用金额 = 0 + 70 = 70元

阶段二(Canncel)：如果要回滚（Cancel），则冻结金额扣减30，可用余额增加30

需要回滚，那么就要释放冻结金额，恢复可用金额：

分布式事务-seata框架_分布式事务_51

核心：把资源分为两部分，eg: 总金额资源分为，冻结金额和可用余额
第一阶段完成资源预留(冻结金额划分)之后，第二阶段不管confirm还是canncel都是在操作自己预留这部分(各自操作自己的，天然做到了事务隔离)，这是TCC和AT很大的一个差别
TCC和AT都是分支事务各自提交自己的事务，中间不一致，最终一致；AT通过锁来实现事务隔离，TCC不需要锁，因为冻结了资源，下次再有事务来，冻结的会是另一部分资源(另外的30块)，跟我这次事务自动就隔离开了
TCC通过一阶段的资源预留，二阶段各自操作各自预留的资源，互不影响，天然隔离，不需要锁。不需要锁也能完成事务隔离，性能上好了很多。

4.3.2.Seata的TCC模型

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

分布式事务-seata框架_分布式_52

1.4 资源预留(Try)也是一个单独的事务，会直接提交(会释放数据库锁，性能就非常好)
Try、Confirm、cancel 需要自己编码实现

4.3.3.优缺点

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

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

TCC的优点是什么？

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

TCC的缺点是什么？

有代码侵入，需要人为编写try、Confirm和Cancel接口，太麻烦
软状态，事务是最终一致
需要考虑Confirm和Cancel的失败情况，做好幂等处理 (幂等处理：同一个操作不管你操作多少次结果是一样的）（失败了seata可能会去重试，得考虑健壮性，无论重复多少次，最终结果和执行一次是一样的)
(一句话：性能特别好，就是太浪费程序员了)

并不是所有事务都适合TCC模式，比如下单的订单，是新增操作，谈不上资源预留，TCC模式就不适合这种业务
这里的扣款，和扣库存适合TCC模式管理业务，但是只演示一个扣款了
Seata内部，TCC模式和AT模式可以混着用，没问题

TCC里有一个问题，不注意就会出事儿，所以先搞定一下这个问题吧：事务悬挂和空回滚

4.3.4.事务悬挂和空回滚

1）空回滚

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

如图：

分布式事务-seata框架_回滚_53

执行cancel操作时，应当判断try是否已经执行，如果尚未执行，则应该空回滚。

2）业务悬挂

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

执行try操作时，应当判断cancel是否已经执行过了，如果已经执行，应当阻止空回滚后的try操作，避免悬挂（业务早都结束了，还try个毛哇）

空回滚：执行cancel是检查try是否执行过
业务悬挂：执行try时检查cancel是否执行过
(所以cancel和try需要可以互相检查对方状态)

4.3.5.实现TCC模式

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

1）思路分析

这里我们定义一张表：

CREATE TABLE `account_freeze_tbl` (
  `xid` varchar(128) NOT NULL,
  `user_id` varchar(255) DEFAULT NULL COMMENT '用户id',
  `freeze_money` int(11) unsigned DEFAULT '0' COMMENT '冻结金额',
  `state` int(1) DEFAULT NULL COMMENT '事务状态，0:try，1:confirm，2:cancel',
  PRIMARY KEY (`xid`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=COMPACT;

分布式事务-seata框架_回滚_54

注意money字段在建表时就已经设置为unsigned类型了，一旦减为负，数据库就会报错，所以其实money字段不需要再过多写代码判断了

注意是微服务数据库里，和业务表一样

分布式事务-seata框架_回滚_55

分布式事务-seata框架_回滚_56

分布式事务-seata框架_分布式事务_57

其中：

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项目中的cn.whu.account.service包中新建一个接口，声明TCC三个接口方法：

package cn.whu.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;

@LocalTCC
public interface AccountTCCService {

    // 声明try方法
    @TwoPhaseBusinessAction(name = "deduct",commitMethod = "confirm",rollbackMethod = "cancel")
    void deduct(@BusinessActionContextParameter(paramName = "userId") String userId,
                @BusinessActionContextParameter(paramName = "userId") int money);
    // @BusinessActionContextParameter注解注明的参数 会传到BusinessActionContext中 下面两个方法就能获取使用了

    boolean confirm(BusinessActionContext context);

    boolean cancel(BusinessActionContext context);
}

2.1) 查看一下已经提供好的实体类和Mapper

分布式事务-seata框架_分布式_58

Account.java

@Data
@TableName("account_tbl")
public class Account {
    @TableId
    private Long id;
    private String userId;
    private Integer money;
}

AccountFreeze.java

@Data
@TableName("account_freeze_tbl")
public class AccountFreeze {
    @TableId(type = IdType.INPUT)
    private String xid;
    private String userId;
    private Integer freezeMoney;
    private Integer state;

    public static abstract class State {
        public final static int TRY = 0;
        public final static int CONFIRM = 1;
        public final static int CANCEL = 2;
    }
}

AccountFreezeMapper.java

public interface AccountFreezeMapper extends BaseMapper<AccountFreeze> {
}

AccountMapper.java

public interface AccountMapper extends BaseMapper<Account> {

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

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

3）编写实现类

分布式事务-seata框架_分布式_59

在account-service服务中的cn.whu.account.service.impl包下新建一个类，实现TCC业务：

（第一版本，没有实现空回滚和解决业务悬挂）

package cn.whu.account.service.impl;

import cn.whu.account.entity.AccountFreeze;
import cn.whu.account.mapper.AccountFreezeMapper;
import cn.whu.account.mapper.AccountMapper;
import cn.whu.account.service.AccountTCCService;
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 org.springframework.transaction.annotation.Transactional;


@Slf4j
@Service
public class AccountTCCServiceImpl implements AccountTCCService {

    @Autowired
    private AccountMapper accountMapper;

    @Autowired
    private AccountFreezeMapper freezeMapper;


    @Override
    @Transactional
    public void deduct(String userId, int money) {
        // 0. 获取全局事务id
        String xid = RootContext.getXID();//有api 可以直接获取 account_freeze_tbl表的主键得设置为他 TCC模式得seata框架才会认识

        // 1. 扣减可用余额 (account_tbl表的money字段为unsigned类型，若不足直接这里报错，不会往下执行了，要知道，能大大简化逻辑)
        accountMapper.deduct(userId, money);
        // 加了@Transactional 将来一旦抛出异常，spring事务就会自动回滚

        // 2. 记录冻结金额，事务状态
        AccountFreeze freeze = new AccountFreeze();
        freeze.setUserId(userId);
        freeze.setFreezeMoney(money);//money扣了钱  这里加了钱  相当于余额转移到冻结金额里了  方便了直接提交事务后恢复
        freeze.setState(AccountFreeze.State.TRY);//抽象静态内部类 写好了枚举 不错
        freeze.setXid(xid);
        freezeMapper.insert(freeze);

    }

    @Override
    public boolean confirm(BusinessActionContext context) {
        // confirm 说明事务没问题 money确实该扣 直接把辅助表(account_freeze_tbl)冻结金额记录删除就行了

        // 1.获取事务id
        String xid = context.getXid(); // context里也有事务id   所以这里context或者RootContex里拿都行

        // 2.根据id删除冻结记录
        int count = freezeMapper.deleteById(xid);

        return count == 1; //确实删除了那条记录 就成功了 返回true
    }

    // 恢复可用余额  冻结金额清0  状态修改为cancel
    // !!千万注意不能删除记录，将来try恢复时还需要查这行记录判断是否要try，解决事务悬挂问题!!
    @Override
    public boolean cancel(BusinessActionContext context) {
        // 0. 获取参数 (查询冻结记录  或者直接到context里拿  这里选择查询数据库的方式了)
        String xid = context.getXid();
        AccountFreeze freeze = freezeMapper.selectById(xid);

        // 1. 恢复可用余额
        accountMapper.refund(freeze.getUserId(), freeze.getFreezeMoney());
        // 2. 将冻结金额清0，状态改为CANCEL
        freeze.setFreezeMoney(0);
        freeze.setState(AccountFreeze.State.CANCEL);
        int count = freezeMapper.updateById(freeze);//注意是updateById不是update update是全表操作
        return count == 1;
    }
}

（第二版本：加上了空回滚和业务悬挂）

分布式事务-seata框架_回滚_60

分布式事务-seata框架_分布式事务_61

package cn.whu.account.service.impl;

import cn.whu.account.entity.AccountFreeze;
import cn.whu.account.mapper.AccountFreezeMapper;
import cn.whu.account.mapper.AccountMapper;
import cn.whu.account.service.AccountTCCService;
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 org.springframework.transaction.annotation.Transactional;


@Slf4j
@Service
public class AccountTCCServiceImpl implements AccountTCCService {

    @Autowired
    private AccountMapper accountMapper;

    @Autowired
    private AccountFreezeMapper freezeMapper;


    @Override
    @Transactional
    public void deduct(String userId, int money) {
        // 0. 获取全局事务id
        String xid = RootContext.getXID();//有api 可以直接获取 account_freeze_tbl表的主键得设置为他 TCC模式得seata框架才会认识

        // A. 业务悬挂判断
        AccountFreeze oldFreeze = freezeMapper.selectById(xid);
        if(oldFreeze!=null){
            // 肯定是已经空回滚过了 我的try没必要执行了  否则会导致业务悬挂
            return;
        }

        // 1. 扣减可用余额 (account_tbl表的money字段为unsigned类型，若不足直接这里报错，不会往下执行了，要知道，能大大简化逻辑)
        accountMapper.deduct(userId, money);
        // 加了@Transactional 将来一旦抛出异常，spring事务就会自动回滚

        // 2. 记录冻结金额，事务状态
        AccountFreeze freeze = new AccountFreeze();
        freeze.setUserId(userId);
        freeze.setFreezeMoney(money);//money扣了钱  这里加了钱  相当于余额转移到冻结金额里了  方便了直接提交事务后恢复
        freeze.setState(AccountFreeze.State.TRY);//抽象静态内部类 写好了枚举 不错
        freeze.setXid(xid);
        freezeMapper.insert(freeze);

    }

    @Override
    public boolean confirm(BusinessActionContext context) {
        // confirm 说明事务没问题 money确实该扣 直接把辅助表(account_freeze_tbl)冻结金额记录删除就行了

        // 1.获取事务id
        String xid = context.getXid(); // context里也有事务id   所以这里context或者RootContex里拿都行

        // 2.根据id删除冻结记录
        int count = freezeMapper.deleteById(xid);//删除逻辑 天生幂等，无需判断

        return count == 1; //确实删除了那条记录 就成功了 返回true
    }

    // 恢复可用余额  冻结金额清0  状态修改为cancel
    // !!千万注意不能删除记录，将来try恢复时还需要查这行记录判断是否要try，解决事务悬挂问题!!
    @Override
    public boolean cancel(BusinessActionContext context) {

        // 0. 获取参数 (查询冻结记录  或者直接到context里拿  这里选择查询数据库的方式了)
        String xid = context.getXid();
        AccountFreeze freeze = freezeMapper.selectById(xid);

        // A. 空回滚判断
        if(freeze == null){//说明没执行try,需要空回滚
            String userId = (String) context.getActionContext("userId");
            // 空回滚也要插入记录代表本次空回滚了 (freeze表里面每次只要有异常就一定会有新记录的)
            freeze = new AccountFreeze();
            freeze.setUserId(userId);
            freeze.setFreezeMoney(0);
            freeze.setState(AccountFreeze.State.CANCEL);
            freeze.setXid(xid);
            freezeMapper.insert(freeze);

            return true;
        }
        // B. 幂等处理
        // 万一freeze执行一半超时了，seata会重复执行的，第二次freeze就不为空了，就能恢复可用余额了，咋办?
        // 简单想法：CANCEL只能执行一次
        if(freeze.getState() == AccountFreeze.State.CANCEL){
            return true;//处理过了 无需重复处理 直接返回
        }

        // 1. 恢复可用余额
        accountMapper.refund(freeze.getUserId(), freeze.getFreezeMoney());
        // 2. 将冻结金额清0，状态改为CANCEL
        freeze.setFreezeMoney(0);
        freeze.setState(AccountFreeze.State.CANCEL);
        int count = freezeMapper.updateById(freeze);//注意是updateById不是update update是全表操作
        return count == 1;
    }
}

测试

AccountController里的AccountService换成AccountTCCService即可

分布式事务-seata框架_数据库_62

分布式事务-seata框架_分布式事务_63

分布式事务-seata框架_分布式事务_64

查看数据库，相比较于发送请求之前，只有account_freeze_tbl表里多了一条记录

分布式事务-seata框架_数据库_65

状态为2，说明执行空回滚了

4.4.SAGA模式

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

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

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

4.4.1.原理

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

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

分布式事务-seata框架_分布式_66

Saga也分为两个阶段：

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

4.4.2.优缺点

优点：

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

缺点：

软状态持续时间不确定，时效性差
没有锁，没有事务隔离，会有脏写 (也没有TCC的资源预留而带来的天然隔离)

适合事务跨度比较大的情况，例如跨银行调用，等个一两天
目前。使用场景非常少，不怎么用了
用得最多的就是AT，偶尔用TCC和XA进行补充。 saga不重要，就不显示了

4.5.四种模式对比

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

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

如图：

分布式事务-seata框架_回滚_67

5.高可用

Seata的TC服务作为分布式事务核心，一定要保证集群的高可用性。

5.1.高可用架构模型

如何实现高可用：搭建集群即可，多实例+负载均衡，不就高可用了吗

搭建TC服务集群非常简单，启动多个TC服务，注册到nacos即可。

但集群并不能确保100%安全，万一集群所在机房故障怎么办？所以如果要求较高，一般都会做异地多机房容灾。

比如一个TC集群在上海，另一个TC集群在杭州：

分布式事务-seata框架_分布式_68

微服务基于事务组（tx-service-group)与TC集群的映射关系，来查找当前应该使用哪个TC集群。当SH集群故障时，只需要将vgroup-mapping中的映射关系改成HZ。则所有微服务就会切换到HZ的TC集群了。

修改配置文件，就需要重启服务器，很麻烦
所以引入了事务组（tx-service-group)；事务组与TC服务cluster的映射关系也写成nacos的配置，给nacos管理，这样就能实现配置热更新了，就不需要重启服务了，自动可以切换

5.2.实现高可用

具体实现请参考这篇博客：seata 的部署和集成&TC服务的高可用和异地容灾

第三章节：

分布式事务-seata框架_分布式_69

标签：事务,seata,框架,数据库,account,freeze,TC,分布式
From： https://blog.51cto.com/u_15798167/7399380