12_分布式事务

1.什么是分布式事务?
分布式事务指在单个服务或单个数据库架构下产生的事务
比如：
跨数据源的分布式事务
跨服务的分布式事务
综合情况
在数据库水平拆分、服务垂直拆分之后，一个业务操作通常要跨多个数据库、服务才能完成。要满足业务的原子性，要么所有操作全部成功，要么全部失败，不允许出现部分成功部分失败的现象，这就是分布式事务下的事务。

2.什么是CAP理论?
分布式系统有三个指标：

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

一致性(C)、可用性(A)、分区容错性(P)
而这三个指标不可能同时做到，这个结论就叫做CAP定理。

一致性：用户访问分布式系统中的任意节点，得到的数据必须一致。
可用性：用户访问集群中的任意健康节点，必须能够得到响应，而不是超时或拒绝。
分区：因为网络故障或其他原因导致分布式系统中的部分节点与其他节点失去连接，心更独立分区。
容错：在集群出现分区时，整个系统也要持续对外提供服务。

在分布式系统中，系统间的网络不能100%保证健康，一定会有故障的时候，而服务有必须对外保证服务。因此分区容错不可避免。
在P一定会出现的情况下，A和C只能实现一个。

3.什么是BASE理论?
BASE理论是对CAP的一种解决思路，包含了三个思想：

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

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

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

两种模式都需要在子系统事物之间相互通讯吗，协调事务状态，需要一个事务协调者（TC）：

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

5.简单介绍一下seata框架?
Seata是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。致力于提供高性能和简单易用的分布式事务服务，为用户打造一站式的分布式解决方案。
官网地址：http://seata.io/，其中的文档、播客中提供了大量的使用说明、源码分析。

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

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

整体架构图：

6.如何使用seata解决分布式事务?

Seata提供了四种不同的分布式事务解决方案：

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

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

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

异常情况：

一阶段：

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

二阶段：

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

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

RM一阶段的工作：
① 注册分支事务到TC
② 执行分支业务sql但不提交
③ 报告执行状态到TC
TC二阶段的工作：

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

RM二阶段的工作：

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

XA模式的优缺点：
XA模式的优点是什么？

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

XA模式的缺点是什么？

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

具体实现：Seata的starter已经完成了XA模式的自动装配，实现非常简单，步骤如下：
1）修改application.yml文件（每个参与事务的微服务），开启XA模式。
seata:
data-source-proxy-mode: XA
2）给发起全局事务的入口方法添加@GlobalTransactional注解。

7.介绍一下seata AT模式的工作原理?
AT模式同样是分阶段提交的事务模型，不过缺弥补了XA模型中资源锁定周期过长的缺陷。
Seata AT模型
基本流程图：

阶段一RM的工作：

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

阶段二提交时RM的工作：

• 删除undo-log即可

阶段二回滚时RM的工作：

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

8.请详细说明一下AT模式具体是如何实现事务回滚的?
AT模式下，当前分支事务执行流程如下：
一阶段：
1）TM发起并注册全局事务到TC
2）TM调用分支事务
3）分支事务准备执行业务SQL
4）RM拦截业务SQL，根据where条件查询原始数据，形成快照。
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模式最终一致

9.seataAT模式是否有脏读问题，如何解决?
在多线程并发访问AT模式的分布式事务时，有可能出现脏读问题
数据库在本地事务隔离级别是读已提交或以上级别，Seata AT模式默认全局隔离级别是读未提交，
在应用的特定场景下，需要读已提交，目前seata的方式是通过SELECT FOR UPDATE 语句的代理。开启全局锁，避免脏读。

10.seataAT模式是否有脏写问题，如何解决?
在多线程并发访问AT模式的分布式事务时，有可能出现脏写问题

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

AT模式的优点：

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

AT模式的缺点：

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

11.项目中的实际业务场景?

Seata提供了四种不同的分布式事务解决方案：

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

四种模式对比：