前言：虽然本文归属到MySQL系列专题下，但实际内容不限于MySQL。本文更偏向于理论，实际应用部分可以查看Seata基础使用-分布式事务。

零、本文纲要

一、事务

1. 本地事务
2. 分布式事务
3. CAP理论
4. BASE理论

二、分布式事务解决方案-2PC

1. 2PC（两阶段提交）概念
2. 2PC-XA方案
3. Seata
4. Seata-AT模式

三、分布式事务解决方案-TCC

四、分布式事务解决方案-可靠消息最终一致性

1. 基础概念
2. 解决方案-本地消息表方案（eBay）
3. 解决方案-RocketMQ事务消息方案

五、分布式事务解决方案-最大努力通知

1. 基础概念
2. 最大努力通知 对比 可靠消息最终一致性
   六、分布式事务解决方案-对比

一、事务

1. 本地事务

基于关系型数据库的事务。

2. 分布式事务

① 跨JVM & 跨数据库实例：微服务之间通过远程调用完成事务操作；
② 跨数据库实例：单体系统访问多个数据库实例；
③ 跨JVM：多服务访问同一个数据库实例；

3. CAP理论

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

• ① Consistency（一致性）

TimeLine01-事务A：修改主数据库，锁住从数据库；
TimeLine02-事务B：查询从数据库，查到最新数据；

分布式系统一致性的特点：
a、由于存在数据同步的过程，写操作的响应有一定延迟；
b、为了保证数据一致性会对资源暂时锁定，待数据同步完成释放锁定资源；
c、如果请求数据暂未完成同步的节点则会返回错误信息，【一定不会返回旧数据】。

要么响应错误，要么响应最新数据，不能是旧数据。

• ② Availability （可用性）

TimeLine01-事务A：修改主数据库；
TimeLine02-事务B：查询从数据库，查到旧/新数据；

分布式系统可用性的特点：
a、所有请求都有响应，且不会出现超时或者响应错误。

• ③ Partition tolerance（分区容错）

主数据库-从数据库 数据同步失败，但不影响对外提供读写服务。
实现分区容错，从主之间数据同步采用异步操作。

分布式系统分区容忍性的特点：
a、分区容忍性是分布式系统具备的【基本能力】。

• ④ CAP组合方式

a、AP组合（最常见）
追求可用性、分区容忍性，放弃一致性。

b、CP组合
追求一致性、分区容忍性，放弃可用性。（ZooKeeper就是强一致性）

c、CA组合
追求一致性、可用性，放弃分区容忍性。（非标准的分布式系统）

4. BASE理论

AP舍弃一致性，而实际需要一致性。曲线救国，最终一致性。——“柔性事务”

Basically Available （基本可用） / Soft State（软状态） / Eventually Consistent（最终一致性）

二、分布式事务解决方案-2PC

1. 2PC（两阶段提交）概念

准备阶段（Prepare phase） / 提交阶段（Commit phase）

角色：事务管理器、事务参与者

阶段一：
事务管理器 发送Prepare消息给 事务参与者；
事务参与者 在本地执行事务(写 undo/redo log)，但不提交事务；

说明：
undo log 是记录【修改前】的数据，也称撤销日志；
redo log 是记录【修改后】的数据，也称重做日志。

阶段二：
事务参与者 执行失败/超时， 事务管理器 发送Rollback消息；
事务参与者 执行成功， 事务管理器 发送Commit消息。

2. 2PC-XA方案

• ① XA方案概念

XA方案，基于数据库的XA协议来实现的2PC。

DTP模型：X/Open Distributed Transaction Processing (DTP) Model (X/Open XA), 是一个名叫 The Open Group 的组织提出的分布式事务处理规范。

角色：AP-应用程序 / TM-事务管理器 / RM-资源管理器（事务参与者）

TimeLine01：AP 通过 TM 通知 RM1 & RM2 执行事务操作；
TimeLine02：TM 收到 RM1 & RM2 执行回复；如果存在失败，则回滚；反之，则提交。

TM 和 RM 之间通讯接口规范称作 XA 。

• ② XA方案问题

a、需要本地数据库支持XA协议，MySQL、Oracle均支持；
b、资源锁需要等到两阶段结束才释放，性能较差。

3. Seata

角色：
TC (Transaction Coordinator) - 事务协调者 / TM (Transaction Manager) - 事务管理器 / RM (Resource Manager) - 资源管理器

TC (Transaction Coordinator) - 事务协调者
维护全局和分支事务的状态，驱动全局事务提交或回滚。
接收TM发起全局事务的提交/回滚，负责与RM通信协调各个分支事务的提交/回滚，需要独立部署运行。

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

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

4. Seata-AT模式

AT模式 vs XA模式：基于 undo log 实现效率提升。

TimeLine01：TM 向 TC 申请开启全局事务，并生产全局唯一事务ID XID；
TimeLine02：RM 向 TC 主从分支事务，纳入 XID 全局事务管理，并执行提交事务；
TimeLine03：TM 向 TC 发送提交/回滚消息，进行提交/回滚。

与传统XA方案不同的地方，阶段一既已提交事务，有效简短资源锁时间。

TM 向 TC提交注册；
@GlobalTransactional注解开启全局事务，TC 返回 XID；

RM1 携带 XID 向 TC 提交注册，TC 返回 branchId1；
RM1 写入undo log，执行事务，写入业务数据，提交分支事务，上报事务执行结果；

Fegin远程调用，携带 XID 至 RM2（通过 Seata 框架的拦截器实现）；
RM2 携带 XID 向 TC 提交注册，TC 返回 branchId2；
RM2 写入undo log，执行事务，写入业务数据，提交分支事务，上报事务执行结果；

TM 发起提交全局事务，TC 发起提交事务，RM1、RM2 删除 undo log。
TM 发起回滚全局事务，TC 发起回滚事务，RM1、RM2 解析 undo log，如有提交则执行反向操作，删除 undo log。

三、分布式事务解决方案-TCC

1. Seata-TCC模式

Try（预处理） / Confirm（确认） / Cancel（撤销）

Try（预处理）：业务检查，【预留资源】
Confirm（确认）：Try 阶段都成功，业务操作确认；若Confirm阶段出现异常，则需要重试/人工介入；
Cancel（撤销）：Try 阶段存在失败，回滚操作；若Cancel阶段出现异常，也需要重试/人工介入；

空回滚 / 幂等/ 悬挂

Ⅰ 空回滚

存在问题：调用失败的 RM 并没有成功执行 Try ，此时 Cancel 进行事务回滚即产生空回滚。
解决方法：插入一条 Try 的记录，进而可以判断是否执行了 Try。

Ⅱ 幂等

存在问题：Confirm & Cancel均存在重试逻辑，需要保证多次提交结果一致。
解决方法：插入一条 执行状态 的记录，每次执行前查询该状态。

Ⅲ 悬挂

存在问题：RPC远程调用 RM 执行 Try 调用超时，此时 TM 通知 RM 执行 Cancel 进行回滚。回滚后，RM 又收到 Try 执行指令。
解决方法：Try 执行前判断 Confirm 与 Cancel 是否存在执行记录，有则不执行，反之。

• ① 业务实现

RM1

Ⅰ try 方法
是全局事务的入口方法。
需要实现：
a、幂等校验（避免Try重复执行）；
b、悬挂处理（避免已经执行了Confirm/Cancel，而重复执行Try）；
c、具体业务（如：减少金额等）；
d、远程调用其他微服务（此处为RM2）。

Ⅱ confirm 方法

Ⅲ cancel 方法
需要实现：
a、幂等校验（避免Cancel重复执行）；
b、空回滚处理（避免Try未执行，而执行了Cancel）；
c、具体业务相反的操作（如：增加金额等）。

RM2

Ⅰ try 方法

Ⅱ confirm 方法

需要实现：
a、幂等校验（避免Confirm重复执行）；
b、具体业务（如：增加金额等）。

Ⅲ cancel 方法

四、分布式事务解决方案-可靠消息最终一致性

注意：该方案只要消息发出，事务参与者接收到消息就要将事务执行成功，不存在回滚的要求。

1. 基础概念

事务发起者完成本地事务并发送一条消息，事务参与方一定能接收消息并处理事务成功。
只要消息发送给事务参与方，最终事务要达到一致。

事务发起方 → 网络 → 消息中间件 → 网络 → 事务参与方

需处理的问题：
a、本地事务与消息发送的原子性问题；
b、事务参与方必须要能够接收到消息；
c、消息重复消费的问题。

2. 解决方案-本地消息表方案（eBay）

交互流程：
RM1 → 新增用户 → 增加积分消息日志（使用本地表）
定时任务触发 → 扫描未发送积分消息 → 发送积分增加消息
RM2 → 增加用户积分

3. 解决方案-RocketMQ事务消息方案

RocketMQ事务消息-事务回查实现RocketMQLocalTransactionLisnter接口

五、分布式事务解决方案-最大努力通知

注意：发起通知方执行事务后将结果通知给事务参与者，事务参与者执行失败也不会导致通知发起方回滚。

1. 基础概念

发起通知方通过一定的机制，最大努力将业务处理结果通知到接收方。

a、有一定的消息重复通知机制
常见的比如1、3、6分钟等按阶梯递增方式来重复通知；
b、消息校对机制
提供可由接收方主动向通知方查询消息信息的接口。

实际应用：支付宝、微信支付等。

2. 最大努力通知 对比 可靠消息最终一致性

可靠消息最终一致性：消息可靠性由【消息发起方】来保证，如使用MQ事务消息；
最大努力通知：消息可靠性由【通知接收方】来保证，通知发起方尽量将消息发送给通知接收方，接收不到的情形可由通知接收方主动查询通知发起方。

六、分布式事务解决方案-对比

七、结尾

以上即为分布式事务的基础内容，感谢阅读。