SpringCloud分布式事务

最新推荐文章于 2024-01-26 20:58:45 发布

屿-Yu

最新推荐文章于 2024-01-26 20:58:45 发布

阅读量579

点赞数 6

本文链接：https://blog.csdn.net/qinhuarong/article/details/134484654

版权

分布式事务

1.在理解分布式事务之前，让我们先了解一下什么是事务？

我们所说的一般事务就是就是本地事务，也就是传统的事务，在事务中都要满足4个基本原则
- 原子性A：要么都成功，那么都失败，不存在成功和失败的情况！
- 一致性C：保证数据库的内部完整性！
- 隔离性I：不可能同时都能操作同意资源的额失误！
- 持久性D：对所有的操作都会永久保存，不管是否出现故障！
说完了本地事务，我们来说一下分布式事务，其实分布式事务也就是不在单个服务或者当个数据库的下，产生的事务，说白了也是可以操作多个数据库！
- 比如：电商行业中比较常见的下单付款案例
  - 1.创建新订单
  - 2.扣减商品库存
  - 3.从用户余额中空金额
- 要完成这三部操作，需要操作三张表，也就对应三个数据库和三个微服务
- 订单的创建、库存的扣减、账户扣款在每一个服务和数据库内是一个本地事务，可以保证ACID原则
- 但是当我们把三件事情看做一个"业务"，要满足保证“业务”的原子性，要么所有操作全部成功，要么全部失败，不允许出现部分成功部分失败的现象，这就是分布式系统下的事务了。

2.CAP定理

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

简单的理解为三选二，不可能同时满足，这就是CAP定理
- Consistency（一致性）
  - 用户访问分布式系统中的任意节点，得到的数据必须一致。
  - 当我们修改其中一个节点的数据时，要想保住一致性，必须要数据同步
- Availability（可用性）
  - 用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝。
- Partition tolerance （分区容错性）
  - Partition（分区）：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。
  - Tolerance（容错）：在集群出现分区时，整个系统也要持续对外提供服务
矛盾：在分布式系统中，系统间的网络不能100%保证健康，一定会有故障的时候，而服务有必须对外保证服务。因此Partition Tolerance不可避免。
- 当节点接收到新的数据变更时，就会出现问题了：
- 如果此时要保证一致性，就必须等待网络恢复，完成数据同步后，整个集群才对外提供服务，服务处于阻塞状态，不可用。
- 如果此时要保证可用性，就不能等待网络恢复，那服务之间就会出现数据不一致。
- 也就是说，在P一定会出现的情况下，A和C之间只能实现一个，这就是ACP定理

2.BASE理论

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

2.1解决分布式事务的思路

分布式事务最大的问题是各个子事务的一致性问题，因此可以借鉴CAP定理和BASE理论
1. AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。
2. CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。
3. 正是因为这样，所有不管是哪一种模式，都需要在子系统事务之间互相通讯，协调事务状态，也就是需要一个事务协调者(TC)

3.分布式事务的TC的解决者：Seata

3.1.理解Seata的架构

Seata事务管理中有三个重要的角色：
- TC (Transaction Coordinator) - **事务协调者：**维护全局和分支事务的状态，协调全局事务提交或回滚。
- TM (Transaction Manager) - **事务管理器：**定义全局事务的范围、开始全局事务、提交或回滚全局事务。
- RM (Resource Manager) - **资源管理器：**管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

3.1.2.四种不同的分布式事务解决方案

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

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

3.2，当我们把seata注册到nacos中，那我们应该怎么去nacos配置中心中获取呢？

注册到Nacos中的微服务，确定一个具体实例需要四个信息：
- namespace：命名空间
- group：分组
- application：服务名
- cluster：集群名
这样就能确定TC服务集群了。然后就可以去Nacos拉取对应的实例信息了。

4.对XA模式的深入理解：

XA 规范是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准，XA 规范描述了全局的TM与局部的RM之间的接口，几乎所有主流的数据库都对 XA 规范提供了支持。
XA模式是两阶段提交事务
- 一阶段：
  - 事务协调者(TC)通知每个事物参与者执行本地事务
  - 本地事务执行完后会报告执行的状态给TC，此时的事务不会提交，会继续持有数据库的锁，不会释放
- 二阶段：
  - 事务协调者基于一阶段的报告来判断下一步操作
  - 如果一阶段都成功，此时TC会通知事务的参与者，提交事务
  - 如果第一阶段不成功，任意一个参与者失败，就会通知所有事务参与者回滚事务
Seata的XA模型
1. RM一阶段的工作：
  - 注册分支事务到TC
  - 执行分支业务sql但不提交
  - 报告执行状态到TC
2. TC二阶段的工作：
  1. TC检测各分支事务执行状态
    - TC检测各分支事务执行状态
      - a.如果都成功，通知所有RM提交事务
      - b.如果有失败，通知所有RM回滚事务
  2. RM二阶段的工作：
    - 接收TC指令，提交或回滚事务

优缺点：

XA模式的优点是什么？

事务有强一致性，满足了ACID原则
但是XA需要依赖于数据库的支持，实现比较的简单，没有代码的入侵

XA模式的缺点是什么？

因为一阶段没有提交事务，会持有数据库的锁，不会释放，所以性能比较差
依赖于数据库实现事务

4.1.实现XA模式

application.ym，开启XA模式：

seata:
  data-source-proxy-mode: XA

2.全局事务的入口方法添加@GlobalTransactional注解

4.2.AT模式

AT模式同样是分阶段提交的事务模型，不过缺弥补了XA模型中资源锁定周期过长的缺陷。
- 一阶段：
  - 注册分支事务
  - 记录undo.log（数据快照）
  - 执行业务sql并提交
  - 报告事务的状态
- 二阶段提交时RM：
  - 删除undo-log
- 二阶段回滚时RM：
  - 根据undo-log恢复数据到更新前

例如：我们用一个真实的业务来梳理下AT模式的原理。比如，现在又一个数据库表，记录用户余额：

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

一阶段

TM发起请求注册到全局事务到TC
TM调用分支事务
分支事务准备执行业务SQL
RM拦截业务SQL，根据where条件查询原始数据，形成快照。
）RM执行业务SQL，提交本地事务，释放数据库锁。此时 money = 90
RM报告本地事务状态给TC

2、二阶段：

TM通知TC事务结束
TC检查分支事务状态
- a）如果都成功，则立即删除快照
- b）如果有分支事务失败，需要回滚。读取快照数据（{"id": 1, "money": 100}），将快照恢复到数据库。此时数据库再次恢复为100

AT与XA的区别？

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

1.正是因为AT是最终一致，会出现中途出现脏写的情况：

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

AT模式优缺点：

AT模式的优点:
- 一阶段完成直接提交事务，释放数据库资源，性能比较好
- 利用全局锁实现读写隔离
- 没有代码侵入，框架自动完成回滚和提交
AT模式的缺点：
- 两阶段之间属于软状态，属于最终一致
- 框架的快照功能会影响性能，但比XA模式要好很多

实现AT模式

application.yml文件，将事务模式修改为AT模式即可：
```
seata:
  data-source-proxy-mode: AT # 默认就是AT
```

4.3.TCC模式

TCC模式与AT模式非常相似，每阶段都是独立事务，不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法：
- Try：资源的检测和预留；
- Confirm：完成资源操作业务；要求 Try 成功 Confirm 一定要能成功。
- Cancel：预留资源释放，可以理解为try的反向操作。

4.3.3.TCC优缺点

TCC的优点是什么？

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

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

事务悬挂和空回滚

空回滚
- 当某分支事务的try阶段阻塞时，可能导致全局事务超时而触发二阶段的cancel操作。在未执行try操作时先执行了cancel操作，这时cancel不能做回滚，就是空回滚
执行cancel操作时，应当判断try是否已经执行，如果尚未执行，则应该空回滚。

业务悬挂

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

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

实现TCC模式：

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

@LocalTCC
public interface AccountTCCService {

    @TwoPhaseBusinessAction(name = "deduct", commitMethod = "confirm", rollbackMethod = "cancel")
    void deduct(@BusinessActionContextParameter(paramName = "userId") String userId,
                @BusinessActionContextParameter(paramName = "money")int money);

    boolean confirm(BusinessActionContext ctx);

    boolean cancel(BusinessActionContext ctx);
}

4.4.SAGA模式

Saga 模式是 Seata 即将开源的长事务解决方案，将由蚂蚁金服主要贡献。
Saga 模式下，分布式事务内有多个参与者，每一个参与者都是一个冲正补偿服务，需要用户根据业务场景实现其正向操作和逆向回滚操作。
分布式事务执行过程中，依次执行各参与者的正向操作，如果所有正向操作均执行成功，那么分布式事务提交。如果任何一个正向操作执行失败，那么分布式事务会去退回去执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。
Saga也分为两个阶段：
- 一阶段：直接提交本地事务
- 二阶段：成功则什么都不做；失败则通过编写补偿业务来回滚

优缺点

优点：

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

缺点：

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

四种模式对比：

一致性：XA是强一致性，AT，TCC，SAGA是弱一致性

隔离性：XA是完全隔离，AT是基于全局锁的隔离，TCC是基于预留资源。SAGA无隔离

代码入侵：XA、AT无代码入侵，TCC有，哟啊编写三个接口，SAGA有，要编写状态机核补偿业务

性能：XA性能差，AT好，TCC、SAGA非常好

场景：

XA：对强一致性，隔离性需求高的业务用
AT：基于关系型数据库的大多数分布式事务都可以解决
TCC：对性能要求高的事务，对飞关系型数据库的参与的事务
SAGA：业务流程长，业务流程多，参与其他公司或者遗留的系统服务，无法提供TCC模式要求的三个接口

高可用

搭建TC服务集群非常简单，启动多个TC服务，注册到nacos即可。
但集群并不能确保100%安全，万一集群所在机房故障怎么办？所以如果要求较高，一般都会做异地多机房容灾。
比如一个TC集群在上海，另一个TC集群在杭州
微服务基于事务组（tx-service-group)与TC集群的映射关系，来查找当前应该使用哪个TC集群。当SH集群故障时，只需要将vgroup-mapping中的映射关系改成HZ。则所有微服务就会切换到HZ的TC集群了。

屿-Yu

关注

6
点赞
踩
2

收藏

觉得还不错? 一键收藏
打赏
1
评论
SpringCloud分布式事务

XA 规范是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准，XA 规范描述了全局的TM与局部的RM之间的接口，几乎所有主流的数据库都对 XA 规范提供了支持。对于已经空回滚的业务，之前被阻塞的try操作恢复，继续执行try，就永远不可能confirm或cancel ，事务一直处于中间状态，这就是。**资源管理器：**管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。
复制链接

扫一扫