2PC、3PC、XA规范、SAGA
XA规范
X/Open组织（现在的OpenGroup）定义了分布式事务的处理模型，X/Open DTP模型（1994）包括：
- 应用程序（AP）
- 事务管理器（TM），交易中间件
- 资源管理器（RM），数据库
- 通信资源管理器（CRM），消息中间件
本地事务 是指数据库内多表操作。
全局事务 是指分布式事务处理环境中，多个数据库共同完成一个工作。
XA 就是 X/Open DTP 定义的交易中间件与数据库之间的接口规范（即接口函数），交易中间件用它来通知数据库事务的开始、结束以及提交、回滚等。 XA 接口函数由数据库厂商提供。
2PC协议
二阶段提交(Two-phaseCommit)是指，在计算机网络以及数据库领域内，为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法(Algorithm)。
二阶段提交的算法思路可以概括为：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。
缺点
- 同步阻塞，所有参与节点都是事务阻塞型的。
- 单点故障，协调者发生故障参与者会阻塞西区。（可以选举一个新的协调者，但是无法解决因为协调者宕机导致的参与制处于阻塞状态的问题）
- 数据不一致，
- 二阶段无法解决的问题：协调者再发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。
3PC协议
与两阶段提交不同的是：
- 引入超时机制，同时在协调者和参与者中都引入超时机制。
- 在第一阶段和第二阶段中插入一个准备阶段。保证了再最后提交阶段之前个参与节点的状态是一致的。
TCC型
TCC型事务（Try/Confirm/Cancel）可以归为补偿型；TCC思路是：尽早施放锁；在Try成功的情况下如果事务要回滚，Cancel将作为一个补偿机制，回滚Try操作；
TCC各操作事务本地化，且尽早提交（放弃两阶段约束）；当全局事务要求回滚时，通过另一个本地事务实现“补偿”行为；
TCC是将资源层的两阶段提交协议转换到业务层，称为业务模型的一部分。
- Try：尝试执行业务
完成所有业务检查（一致性）预留必须业务资源（准隔离性） - Confirm：确认执行业务
真正执行业务 不做任何业务检查只使用Try阶段预留的业务资源Confirm操作满足幂等性。 - Cancel：取消执行业务
施放Try阶段预留的业务资源，Cancel操作要满足幂等要求。
与2PC区别
- TCC位于业务服务层而非资源层
- TCC没有单独的准备（Prepare）阶段，Try操作兼备资源操作与准备能力 Try操作可以灵活选择业务资源的锁定力度。
- TCC有较高开发成本
本地消息表(异步确保）
源于eBay，使用较多，核心思想：将分布式事务拆分成本地事务进行处理。
基本思路
- 消息生产方，维护业务数据+成功消息表（本地事务）
- 消息消费方，维护业务数据+失败消息表（本地事务），消费消息并处理业务，业务处理失败时向生产方发消息给生产方。
- 生产方、消费方，定时扫描本地消息表，确保消息发送成功。
优点避免分布式事务，实现最终一致性。
缺点消息表耦合到业务系统中，封装不好的话杂活很多。
MQ事务消息
RocketMQ支持事务消息，思路大致：
- 第一阶段Prepared消息，会拿到消息的地址。
- 第二阶段执行本地事务，
- 第三阶段通过第一阶段拿到的地址去访问消息，并修改状态
- 异常处理：第3阶段失败了的话，RMQ会向业务方询问业务结果。
SAGA模式
1987年普林斯顿大学发表，柔性事务。
思路
- 每个Saga由一系列sub-transaction Ti 组成
- 每个Ti 都有对应的补偿动作Ci，补偿动作用于撤销Ti造成的结果
2种执行顺序
- T1、T2、T3…Tn
- T1、T2、…Tj,Cj,…C2、C1
对ACID的保证
- 通过saga log 可以保证一致性（C）、持久性（D）
- 不能保证原子性（A）、隔离性（I）
2种流行实现方式：
- 基于事件的方式。这种方式没有协调中心，整个模式的工作方式就像舞蹈一样，各个舞蹈演员按照预先编排的动作和走位各自表演，最终形成一只舞蹈。处于当前Saga下的各个服务，会产生某类事件，或者监听其它服务产生的事件并决定是否需要针对监听到的事件做出响应。
- 基于命令的方式。这种方式的工作形式就像一只乐队，由一个指挥家（协调中心）来协调大家的工作。协调中心来告诉Saga的参与方应该执行哪一个本地事务。
