本地事务

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

基本概念

事务的概念：事务是逻辑上一组操作，组成这组操作各个逻辑单元，要么一起成功，要么一起失败。

事务的四个特性（ACID）：

  1. 原子性(atomicity)：“原子”的本意是“不可再分”，事务的原子性表现为一个事务中涉及到的多个操作在逻辑上缺一不可。事务的原子性要求事务中的所有操作要么都执行，要么都不执行。
  2. 一致性(consistency)：“一致”指的是数据的一致，具体是指：所有数据都处于满足业务规则的一致性状态。一致性原则要求：一个事务中不管涉及到多少个操作，都必须保证事务执行之前数据是正确的，事务执行之后数据仍然是正确的。如果一个事务在执行的过程中，其中某一个或某几个操作失败了，则必须将其他所有操作撤销，将数据恢复到事务执行之前的状态，这就是回滚。
  3. 隔离性(isolation)：在应用程序实际运行过程中，事务往往是并发执行的，所以很有可能有许多事务同时处理相同的数据，因此每个事务都应该与其他事务隔离开来，防止数据损坏。隔离性原则要求多个事务在并发执行过程中不会互相干扰。
  4. 持久性(durability)：持久性原则要求事务执行完成后，对数据的修改永久的保存下来，不会因各种系统错误或其他意外情况而受到影响。通常情况下，事务对数据的修改应该被写入到持久化存储器中。

隔离级别

事务并发引起一些读的问题：

  • 脏读 一个事务可以读取另一个事务未提交的数据
  • 不可重复读 一个事务可以读取另一个事务已提交的数据 单条记录前后不匹配
  • 虚读（幻读） 一个事务可以读取另一个事务已提交的数据 读取的数据前后多了点或者少了点

并发写：使用mysql默认的锁机制（独占锁）

解决读问题：设置事务隔离级别

  • read uncommitted(0)
  • read committed(2)
  • repeatable read(4)
  • Serializable(8)

隔离级别越高，性能越低。

一般情况下：脏读是不可允许的，不可重复读和幻读是可以被适当允许的。

相关命令

查看全局事务隔离级别：SELECT @@global.tx_isolation

设置全局事务隔离级别：set global transaction isolation level read committed;

查看当前会话事务隔离级别：SELECT @@tx_isolation

设置当前会话事务隔离级别：set session transaction isolation level read committed;

查看mysql默认自动提交状态：select @@autocommit

设置mysql默认自动提交状态：set autocommit = 0;【不自动提交】

开启一个事务：start transaction;

提交事务：commit

回滚事务： rollback

在事务中创建一个保存点：savepoint tx1

回滚到保存点：rollback to tx1

传播行为

事务的传播行为不是jdbc规范中的定义。传播行为主要针对实际开发中的问题

七种传播行为：

REQUIRED 支持当前事务，如果不存在，就新建一个

SUPPORTS 支持当前事务，如果不存在，就不使用事务

MANDATORY 支持当前事务，如果不存在，抛出异常

REQUIRES_NEW 如果有事务存在，挂起当前事务，创建一个新的事务

NOT_SUPPORTED 以非事务方式运行，如果有事务存在，挂起当前事务

NEVER 以非事务方式运行，如果有事务存在，抛出异常

NESTED 如果当前事务存在，则嵌套事务执行（嵌套式事务）

  • 依赖于JDBC3.0提供的SavePoint技术
  • 删除用户 删除订单。在删除订单后，设置savePoint，执行删除用户。删除订单和删除用户在同一事务中，删除用户失败，事务回滚savePoint，由用户控制视图提交还是回滚

这七种事务传播机制最常用的就两种：

REQUIRED：一个事务，要么成功，要么失败

REQUIRES_NEW：两个不同事务，彼此之间没有关系。一个事务失败了不影响另一个事务

伪代码练习

传播行为伪代码模拟：有a,b,c,d,e等5个方法，a中调用b,c,d,e方法的传播行为在小括号中标出

1
2
3
4
5
6
7
a(required){
	b(required);
	c(requires_new);
	d(required);
	e(requires_new);
	// a方法的业务
}

问题：

  1. a方法的业务出现异常，会怎样？a,b,d回滚 c,e不回滚
  2. d方法出现异常，会怎样？a,b,d回滚 c,e不回滚
  3. e方法出现异常，会怎样？a,b,d,e回滚 c不回滚，e方法出异常会上抛影响到上级方法
  4. b方法出现异常，会怎样？a,b回滚 c,d,e未执行

加点难度：

1
2
3
4
5
6
7
8
9
10
11
12
13
a(required){
	b(required){
		f(requires_new);
		g(required)
	}
	c(requires_new){
		h(requires_new)
		i(required)
	}
	d(required);
	e(requires_new);
	// a方法的业务
}

问题：

  1. a方法业务出异常
  2. e方法出异常
  3. d方法出异常
  4. h,i方法分别出异常
  5. i方法出异常
  6. f,g方法分别出异常

改造商品新增代码

现在商品保存的方法结构如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
@Override
public void bigSave(SpuVo spuVo) {
    /// 1.保存spu相关
    // 1.1. 保存spu基本信息 spu_info
    Long spuId = saveSpu(spuVo);

    // 1.2. 保存spu的描述信息 spu_info_desc
    saveSpuDesc(spuVo, spuId);

    // 1.3. 保存spu的规格参数信息
    saveBaseAttr(spuVo, spuId);

    /// 2. 保存sku相关信息
    saveSku(spuVo, spuId);
}

/**
 * 保存sku相关信息及营销信息
 * @param spuInfoVO
 */
private void saveSku(SpuVo spuVo, Long spuId) { 。。。 }

/**
 * 保存spu基本属性信息
 * @param spuInfoVO
 */
private void saveBaseAttr(SpuVo spuVo, Long spuId) { 。。。 }

/**
 * 保存spu描述信息（图片）
 * @param spuInfoVO
 */
private void saveSpuDesc(SpuVo spuVo, Long spuId) { 。。。 }

/**
 * 保存spu基本信息
 * @param spuInfoVO
 */
private void saveSpu(SpuVo spuVo) {  。。。 }

为了测试事务传播行为，我们在SpuInfoService接口中把saveSkuInfoWithSaleInfo、saveBaseAttrs、saveSpuDesc、saveSpuInfo声明为service接口方法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public interface SpuInfoService extends IService<SpuInfoEntity> {

    PageVo queryPage(QueryCondition params);

    PageVo querySpuInfo(QueryCondition condition, Long catId);

    void saveSpuInfoVO(SpuInfoVO spuInfoVO);

    void saveSku(SpuVo spuVo, Long spuId);

    void saveBaseAttr(SpuVo spuVo, Long spuId);

    void saveSpuDesc(SpuVo spuVo, Long spuId);

    Long saveSpu(SpuVo spuVo);
}

再把SpuInfoServiceImpl实现类的对应方法改成public：

测试1：同一service + requires_new

springboot 1.x使用事务需要在引导类上添加@EnableTransactionManagement注解开启事务支持

springboot 2.x可直接使用@Transactional玩事务，传播行为默认是REQUIRED

添加事务：

这时，在保存商品的主方法中制造异常：

由于保存商品描述方法使用的是requires_new，spu应该会回滚，spu_desc应该保存成功。

清空pms_spu_desc表，再添加一个spu保存。

结果pms_spu_desc表中依然没有数据。

但是控制台打印了新增pms_spu_desc表的sql语句：

说明saveSpuDesc方法的事务回滚了，也就是说该方法配置的事务传播机制没有生效。

解决方案：

  1. 把service方法放到不同的service中
  2. 使用动态代理对象调用该方法

测试2：不同service + requires_new

把saveSpuDesc方法放到SpuDescService中：

在实现类中实现该方法，可以把之前的实现copy过来：

改造SpuServiceImpl中保存商品的方法，调用SpuDescServiceImpl的saveSpuDesc方法：

再次重启gmall-pms，虽然控制台依然报错，但是数据可以保存成功，说明没有在一个事务中。

为什么测试1的事务传播行为没有生效，而测试2的事务传播行为生效了？

spring的事务是声明式事务，而声明式事务的本质是Spring AOP，SpringAOP的本质是动态代理。

事务要生效必须是代理对象在调用。

测试1：通过this调用同一个service中的方法，this是指service实现类对象本身，不是代理对象，就相当于方法中的代码粘到了大方法里面，相当于还是一个方法。

测试2：通过其他service对象（spuDescService）调用，这个service对象本质是动态代理对象

接下来debug，打个断点看看：

  1. spuDescService：

  2. this:

在同一个service中使用传播行为

只需要把测试1中的this.方法名()替换成this代理对象.方法名()即可。

问题是怎么在service中获取当前类的代理对象？

在类中获取代理对象分三个步骤：

  1. 导入aop的场景依赖：spring-boot-starter-aop
  2. 开启AspectJ的自动代理，同时要暴露代理对象：@EnableAspectJAutoProxy(exposeProxy=true)
  3. 获取代理对象：SpuInfoService proxy = (SpuInfoService) AopContext.currentProxy();

具体如下：

1
2
3
4
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-aop</artifactId>
</dependency>

重启后测试：先清空pms_spu_info_desc表中数据

表中数据新增成功，说明saveSpuDesc方法走的是自己的事务，传播行为生效了。

debug可以看到，spuInfoService是一个代理对象。

回滚策略

事务很重要的另一个特征是程序出异常时，会回滚。但并不是所有的异常都会回滚。

默认情况下的回滚策略：

  • 运行时异常：不受检异常，没有强制要求try-catch，都会回滚。例如：ArrayOutOfIndex，OutofMemory，NullPointException
  • 编译时异常：受检异常，必须处理，要么try-catch要么throws，都不回滚。例如：FileNotFoundException

可以通过@Transactional注解的下面几个属性改变回滚策略：

rollbackFor：指定的异常必须回滚

noRollbackFor：发生指定的异常不用回滚

测试编译时异常不回滚

在商品保存方法中制造一个编译时异常：

重启测试，注意pms_spu表中数据：

控制台报异常：

pms_spu表中的数据新增成功了。

也就证明了编译时异常不回滚。

定制回滚策略

经过刚才的测试，我们知道：

  1. ArithmeticException异常（int i = 1/0）会回滚
  2. FileNotFoundException异常（new FileInputStream(“xxxx”)）不回滚

接下来我们来改变一下这个策略：

测试：

  1. FileNotFoundException：在程序中添加new FileInputStream(“xxxx”)，然后测试。

    还是id还是17，说明回滚了（回滚也会占用id=18）

  2. ArithmeticException：在程序中添加int i = 1/0; 然后测试。

    id是19，说明没有回滚。

超时事务

@Transactional注解，还有一个属性是timeout超时时间，单位是秒。

timeout=3：是指第一个sql开始执行到最后一个sql结束执行之间的间隔时间。

即：超时时间（timeout）是指数据库超时，不是业务超时。

改造之前商品保存方法：SpuInfoServiceImpl类中

重启测试：控制台出现事务超时异常

只读事务

@Transactional注解最后一个属性是只读事务属性

如果一个方法标记为readOnly=true事务，则代表该方法只能查询，不能增删改。readOnly默认为false

给商品新增的事务标记为只读事务：

测试：

分布式事务

演示分布式事务问题

代码地址

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

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

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

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

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

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

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

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

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

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

CAP定理

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

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

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

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

一致性

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

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

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

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

可用性

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

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

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

分区容错

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

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

矛盾

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

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

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

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

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

BASE理论

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

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

解决分布式事务的思路

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

  • AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。

  • CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。

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

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

初识Seata以及Seata的架构

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

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

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

  • TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。

  • TM (Transaction Manager) - 事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务。

  • RM (Resource Manager) - 资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

整体的架构如图：

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

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

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

分布式事务解决方案(包含seata中的四种事务模式)

XA模式

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

两阶段提交（2PC）

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

正常情况：

异常情况：

一阶段：

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

二阶段：

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

Seata的XA模型

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

RM一阶段的工作：

​ ① 注册分支事务到TC

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

​ ③ 报告执行状态到TC

TC二阶段的工作：

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

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

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

RM二阶段的工作：

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

优缺点

XA模式的优点是什么？

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

XA模式的缺点是什么？

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

实现XA模式

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

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

1
2
seata:
  data-source-proxy-mode: XA

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

本例中是OrderServiceImpl中的create方法.

3）重启服务并测试

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

AT模式

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

Seata的AT模型

基本流程图：

阶段一RM的工作：

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

阶段二提交时RM的工作：

  • 删除undo-log即可

阶段二回滚时RM的工作：

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

流程梳理

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

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

idmoney
1100

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

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

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

一阶段：

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

2）TM调用分支事务

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

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

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

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

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

二阶段：

1）TM通知TC事务结束

2）TC检查分支事务状态

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

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

流程图：

AT与XA的区别

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

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

脏写问题

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

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

优缺点

AT模式的优点：

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

AT模式的缺点：

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

实现AT模式

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

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

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

导入seata-at.sql文件：https://github.com/behappy-spring-study/seata-demo-by-heima/blob/master/sql/seata-at.sql，其中lock_table导入到TC服务关联的数据库(**seata**)，undo_log表导入到微服务关联的数据库(**account-service**)：

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

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

3）重启服务并测试

TCC模式

具体demo学习内容可以查看：https://seata.io/zh-cn/blog/integrate-seata-tcc-mode-with-spring-cloud.html

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

  • Try：资源的检测和预留；

  • Confirm：完成资源操作业务；要求 Try 成功 Confirm 一定要能成功。

  • Cancel：预留资源释放，可以理解为try的反向操作。

流程分析

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

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

初识余额：

余额充足，可以冻结：

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

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

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

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

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

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

Seata的TCC模型

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

优缺点

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

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

TCC的优点是什么？

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

TCC的缺点是什么？

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

事务悬挂和空回滚

1）空回滚

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

如图：

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

2）业务悬挂

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

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

在Seata1.5.x之后的TCC模式中，如果在@TwoPhaseBusinessAction注解中设置useTCCFence=true且额外建立一张表tcc_fence_log，那么Seata会帮助开发人员处理幂等性、资源悬挂、空回滚等问题

1
2
3
4
5
6
7
8
9
10
11
12
13
CREATE TABLE IF NOT EXISTS `tcc_fence_log`
(
    `xid`           VARCHAR(128)  NOT NULL COMMENT 'global id',
    `branch_id`     BIGINT        NOT NULL COMMENT 'branch id',
    `action_name`   VARCHAR(64)   NOT NULL COMMENT 'action name',
    `status`        TINYINT       NOT NULL COMMENT 'status(tried:1;committed:2;rollbacked:3;suspended:4)',
    `gmt_create`    DATETIME(3)   NOT NULL COMMENT 'create time',
    `gmt_modified`  DATETIME(3)   NOT NULL COMMENT 'update time',
    PRIMARY KEY (`xid`, `branch_id`),
    KEY `idx_gmt_modified` (`gmt_modified`),
    KEY `idx_status` (`status`)
) ENGINE = InnoDB
DEFAULT CHARSET = utf8mb4;

关于seata是如何解决这些问题的可查看：https://seata.io/zh-cn/blog/seata-tcc-fence.html

实现TCC模式

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

1）思路分析

这里我们定义一张表：

1
2
3
4
5
6
7
8
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;

其中：

  • 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.itcast.account.service包中新建一个接口，声明TCC三个接口：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
package cn.itcast.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一定需要注解在接口上
 * @LocalTCC 适用于SpringCloud+Feign模式下的TCC
 * @TwoPhaseBusinessAction 注解try方法，其中name为当前tcc方法的bean名称，写方法名便可（全局唯一），commitMethod指向提交方法，rollbackMethod指向事务回滚方法。指定好三个方法之后，seata会根据全局事务的成功或失败，去帮我们自动调用提交方法或者回滚方法。@BusinessActionContextParameter 注解可以将参数传递到二阶段（commitMethod/rollbackMethod）的方法。BusinessActionContext 便是指TCC事务上下文
 */
@LocalTCC
public interface AccountTCCService {

    @TwoPhaseBusinessAction(name = "deduct", commitMethod = "confirm", rollbackMethod = "cancel")
    void deduct(@BusinessActionContextParameter(paramName = "userId") String userId,
                @BusinessActionContextParameter(paramName = "money")int money);
    
    /**
     * 确认方法、可以另命名，但要保证与commitMethod一致
     * context可以传递try方法的参数
     *
     * @param ctx 上下文
     * @return boolean
     */
    boolean confirm(BusinessActionContext ctx);
    
    /**
     * 二阶段取消方法
     *
     * @param ctx 上下文
     * @return boolean
     */
    boolean cancel(BusinessActionContext ctx);
}

3）编写实现类

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
package cn.itcast.account.service.impl;

import cn.itcast.account.entity.AccountFreeze;
import cn.itcast.account.mapper.AccountFreezeMapper;
import cn.itcast.account.mapper.AccountMapper;
import cn.itcast.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;

@Service
@Slf4j
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();
        // 1.扣减可用余额
        accountMapper.deduct(userId, money);
        // 2.记录冻结金额，事务状态
        AccountFreeze freeze = new AccountFreeze();
        freeze.setUserId(userId);
        freeze.setFreezeMoney(money);
        freeze.setState(AccountFreeze.State.TRY);
        freeze.setXid(xid);
        freezeMapper.insert(freeze);
    }

    @Override
    public boolean confirm(BusinessActionContext ctx) {
        // 1.获取事务id
        String xid = ctx.getXid();
        // 2.根据id删除冻结记录
        int count = freezeMapper.deleteById(xid);
        return count == 1;
    }

    @Override
    public boolean cancel(BusinessActionContext ctx) {
        // 0.查询冻结记录
        String xid = ctx.getXid();
        AccountFreeze freeze = freezeMapper.selectById(xid);

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

SAGA模式

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

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

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

原理

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

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

Saga也分为两个阶段：

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

优缺点

优点：

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

缺点：

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

四种模式对比

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

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

如图：

消息事务+最终一致性(补)

基于消息中间件的两阶段提交往往用在高并发场景下，将一个分布式事务拆成一个消息事务（A系统的本地操作+发消息）+B系统的本地操作，其中B系统的操作由消息驱动，只要消息事务成功，那么A操作一定成功，消息也一定发出来了，这时候B会收到消息去执行本地操作，如果本地操作失败，消息会重投，直到B操作成功，这样就变相地实现了A与B的分布式事务。

虽然上面的方案能够完成A和B的操作，但是A和B并不是严格一致的，而是最终一致的，我们在这里牺牲了一致性，换来了性能的大幅度提升。当然，这种玩法也是有风险的，如果B一直执行不成功，那么一致性会被破坏，具体要不要玩，还是得看业务能够承担多少风险。

此种方案适用于高并发最终一致

低并发基本一致：二阶段提交

高并发强一致：没有解决方案