分布式事务

---

一、分布式事务相关概念

1.分布式事务架构图

2.理解本地事务相关概念

1 本地事务4大特性：AICD(原子性、隔离性、一致性、持久性)
2 隔离级别：读未提交、读已提交、可重复读、序列化
3 不同隔离级别出现的问题：脏读、幻读等
4 事务的7大传播行为：略

3.理解分布式事务相关概念

1.CAP理论

核心理念

C：一致性
A：可用性
P：分区容错性

在分布式场景中只存在两种情况：AP、CP
选用分布式解决方案时，根据业务需求对AP或CP进行选择

2.刚性事务（CP）与柔性事务（AP）

刚性事务：也称强一致性，比如ACID理论
实现方案：Seata XA/AT、3PC、LCN等

柔性事务：基本可用、最终一致性，如BASE理论
实现方案：通知型（MQ事务消息、本地消息表方案）与补偿型（TCC、SAGA）

柔性事务：业务场景，抢购（扣库存、生成订单、发物流），支付回调等
刚性事务：业务场景，特定一些结算或金融业务要求强一致性的场景

3.基于AP模型衍生下的BASE理论

核心理念：

1.基本可用
2.软状态
3.最终一致性

4 .如何从大方向选择分布式事务？

业务规避 > BASE柔性事务 > CP刚性事务

如果 能用业务规避避免分布式事务，那最好了。
其次 先用BASE柔性事物
最后 考虑用CP刚性事务

5 .分布式事务DTP模型：3大角色

AP：应用程序。如订单服务、库存服务
RM：资源管理器。如mysql或redis等；必须实现XA定义的接口
TM：事务管理器。负责分配事务唯一标识，监控事务执行进度并负责事务提交或回滚

6.XA规范协议：

XA规范了TM（事务管理器）与RM（资源管理器）之间的通信接口，是TM与RM通讯的桥梁

二、分布式事务实现方案及原理

1.2pc提交协议（刚性事务，强一致性）

2pc两阶段提交协议基本过程：
1.准备阶段：（投票阶段）检查库存是否足够
2.提交阶段 ：根据参与者的准备阶段返回值进行判断是回滚还是提交事务

角色：
事务协调器+事务参与者

优缺点：

优点：
1.各事务参与者的事务由数据库自身实现，业务侵入少
缺点：
1.同步阻塞，需要等待其中参与者执行最长的事务时间，并发能力下降
2.事务管理器故障，导致整个分布式事务无法使用
3.网络问题可能导致事务协调器没有通知到所有事务参与者
4.占用比较高的资源

通信故障解决：

2pc事务协调者通信故障如何解决
1.协调者设定超时时间，超过时间默认参与者执行失败
2.协调者心跳机制，定期判断参与者是否存活
3.预备提交，参与者发送消息到协调者，如果协调者没有收到消息，默认失败通知参与者回滚
4.备份协调者，监控协调者状态
5.消息队列，参与者将消息写到mq，事务协调者去mq获取事务日志

2.3PC三阶段提交

优化2PC：同步阻塞和单点故障问题

1.conCommit阶段：协调者通知每个参与者是否可以提交，都返回yes进入下一个阶段
2.preCommit阶段（预提交）：执行事务不提交，都成功则进入下一个阶段（写binlog）；协调者和参与者都引入了超时机制
3.doCommit阶段：提交或回滚阶段；此阶段失败会执行undolog；如果是网络问题超时参与者没有收到协调者的提交信息，也会被默认提交；

3.AT事务（基于2pc做了补偿）自动事务

工作流程：

第一阶段：此阶段生成before 快照->执行sql（写undolog relaylog）->after 快照->对数据行加行锁

第二阶段：成功

第二阶段：失败

优点：业务代码无入侵
缺点：
第二阶段事务失败可能会有脏数据，需要记录下来人为干预

4.TCC（try confirm cancel）

不会像2PC和3PC阻塞资源，引入补偿机制，把资源转换成业务逻辑形式提高系统性能

try阶段：对资源检测及锁定
comfirm阶段：执行真正的业务；失败后会进行重试；需要考虑幂等性
cancel：失败进行业务回滚；需要考虑幂等性

try阶段：
锁定资源：设置预备状态或冻结某一部分资源；如冻结库存，预增积分等

comfirm阶段：
提交：冻结库存清零，实际库存更改；预加积分进行实际累加

cancel阶段：
预备阶段的数据进行恢复：如冻结减库存进行回退；预增积分进行清零等

优点：性能高
缺点：实现复杂；每个步骤都需要代码实现

5.saga

思想：复杂的事务拆分成多个小事务

流程：

T1完成事务后会以事件方式通知下一个事务T2

实现方式：1.基于事件 2,基于命令的方式

5.1 基于事件：

回滚：某个服务失败，会生成一个回滚事件，其他执行完事务的服务监听并且进行补偿（程序员写代码）回滚；

优缺点：

优点：简单容易理解；各参与方无直接沟通，完全解耦。没有事务协调器；比较适合只有2-4个服务参与的分布式事务场景
缺点： 参与者较多时，容易比较失控。各个参与方可以随意监听对方的消息，以至于最后没人知道到底有哪些系统监听哪些消息。更严重的是，可能产生环形监听，如两个服务相互监听对方产生的事件；

基于命令的方式就出现了

5.1 基于命令：

特点：1 .定义一个协调器服务，2.不需要事件监听

6.rocketmq实现分布式事务

基于rocketmq的事务消息

7.最大努力通知

适用于外部系统，敏感度低的场景；
1.A向银行B发起扣钱请求
2.B扣钱
3.B扣钱成功后通知A扣钱成功