1 DTP模型
维基百科：https://zh.wikipedia.org/wiki/X/Open_XA
分布式事务解决方案几乎都是柔性事务，分布式事务的实现有许多种，其中较经典是由Tuxedo提出的XA分布式事务协议，XA协议包含二阶段提交（2PC）和三阶段提交（3PC）两种实现。
其他还有 TCC、MQ 等最终一致性解决方案，至于工作中用哪种方案，需要根据业务场景选取，2PC/3PC、TCC数据强一致性高，而MQ是最终数据一致。
https://www.ibm.com/docs/zh/db2/10.5?topic=managers-designing-xa-compliant-transaction
X/Open DTP(X/Open Distributed Transaction Processing Reference Model) 是X/Open 这个组织定义的一套分布式事务的标准，也就是了定义了规范和API接口，由厂商进行具体的实现X/Open DTP中的角色
AP(Application Program)：应用程序，主要是定义事务边界以及那些组成事务的特定于应用程序的操作。
RM(Resouces Manager)：资源管理器，管理一些共享资源的自治域，如提供对诸如数据库之类的共享资源的访问。譬如：数据库、文件系统等，并且提供了这些资源的访问方式。
TM(Transaction Manager)：事务管理器，管理全局事务，协调事务的提交或者回滚，并协调故障恢复。
DTP模型里面定义了XA协议接口，TM 和 RM 通过XA接口进行双向通信
2 2PC
2PC、3PC，都是基于XA协议的
2.1 方案简介
二阶段提交协议（Two-phase Commit，即2PC）是常用的分布式事务解决方案，即将事务的提交过程分为两个阶段来进行处理：准备阶段和提交阶段。事务的发起者称协调者，事务的执行者称参与者。
在分布式系统里，每个节点都可以知晓自己操作的成功或者失败，却无法知道其他节点操作的成功或失败。当一个事务跨多个节点时，为了保持事务的原子性与一致性，而引入一个协调者来统一掌控所有参与者的操作结果，并指示它们是否要把操作结果进行真正的提交或者回滚（rollback）。
二阶段提交的算法思路可以概括为：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。
核心思想就是对每一个事务都采用先尝试后提交的处理方式，处理后所有的读操作都要能获得最新的数据，因此也可以将二阶段提交看作是一个强一致性算法。
2.2 处理流程
简单一点理解，可以把协调者节点比喻为带头大哥，参与者理解比喻为跟班小弟，带头大哥统一协调跟班小弟的任务执行。
2.2.1 阶段1：准备阶段
1、协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待所有参与者答复。
2、各参与者执行事务操作，将undo和redo信息记入事务日志中（但不提交事务）。
3、如参与者执行成功，给协调者反馈yes，即可以提交；如执行失败，给协调者反馈no，即不可提交。
2.2.2 阶段2：提交阶段
如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(rollback)消息；否则，发送提交(commit)消息；参与者根据协调者的指令执行提交或者回滚操作，释放所有事务处理过程中使用的锁资源。(注意:必须在最后阶段释放锁资源) 接下来分两种情况分别讨论提交阶段的过程。
情况1，当所有参与者均反馈yes，提交事务：
- 1、协调者向所有参与者发出正式提交事务的请求（即commit请求）。
- 2、参与者执行commit请求，并释放整个事务期间占用的资源。
- 3、各参与者向协调者反馈ack(应答)完成的消息。
- 4、协调者收到所有参与者反馈的ack消息后，即完成事务提交。
情况2，当任何阶段1一个参与者反馈no，中断事务：
- 1、协调者向所有参与者发出回滚请求（即rollback请求）。
- 2、参与者使用阶段1中的undo信息执行回滚操作，并释放整个事务期间占用的资源。
- 3、各参与者向协调者反馈ack完成的消息。
- 4、协调者收到所有参与者反馈的ack消息后，即完成事务中断。
2.3 方案总结
2PC是一个强一致性的同步阻塞协议，事务执⾏过程中需要将所需资源全部锁定，也就是俗称的 刚性事务
2PC方案实现起来简单，实际项目中使用比较少，主要因为以下问题：
性能问题 所有参与者在事务提交阶段处于同步阻塞状态，占用系统资源，容易导致性能瓶颈。
可靠性问题 如果协调者存在单点故障问题，如果协调者出现故障，参与者将一直处于锁定状态。
数据一致性问题 在阶段2中，如果发生局部网络问题，一部分事务参与者收到了提交消息，另一部分事务参与者没收到提交消息，那么就导致了节点之间数据的不一致。
3 3PC
3.1 方案简介
三阶段提交协议，是二阶段提交协议的改进版本，与二阶段提交不同的是，引入超时机制。同时在协调者和参与者中都引入超时机制（2PC 中只有协调者有超时机制）。
三阶段提交将二阶段的准备阶段拆分为2个阶段，插入了一个preCommit阶段，使得原先在二阶段提交中，参与者在准备之后，由于协调者发生崩溃或错误，而导致参与者处于无法知晓是否提交或者中止的“不确定状态”所产生的可能相当长的延时的问题得以解决。
3.2 处理流程
3.2.1 阶段1：canCommit
协调者向参与者发送canCommit请求，参与者如果可以提交就返回yes响应(参与者不执行事务操作)，否则返回no响应：
1、协调者向所有参与者发出包含事务内容的canCommit请求，询问是否可以提交事务，并等待所有参与者答复。
2、参与者收到canCommit请求后，如果认为可以执行事务操作，则反馈yes并进入预备状态，否则反馈no。
3.2.2 阶段2：preCommit
协调者根据阶段1 canCommit参与者的反应情况来决定是否可以基于事务的preCommit操作。根据响应情况，有以下两种可能。
情况1，阶段1所有参与者均反馈yes，参与者预执行事务：
- 1、协调者向所有参与者发出preCommit请求，进入准备阶段。
- 2、参与者收到preCommit请求后，执行事务操作，将undo和redo信息记入事务日志中（但不提交事务）。
- 3、各参与者向协调者反馈ack响应或no响应，并等待最终指令。
情况2，阶段1任何一个参与者反馈no，或者等待超时后协调者尚无法收到所有参与者的反馈，即中断事务:
- 1、协调者向所有参与者发出abort请求。
- 2、无论收到协调者发出的abort请求，或者在等待协调者请求过程中出现超时，参与者均会中断事务。
3.3.3 阶段3：do Commit
该阶段进行真正的事务提交，也可以分为以下两种情况：
情况1：阶段2所有参与者均反馈ack响应，执行真正的事务提交：
- 1、如果协调者处于工作状态，则向所有参与者发出do Commit请求。
- 2、参与者收到do Commit请求后，会正式执行事务提交，并释放整个事务期间占用的资源。
- 3、各参与者向协调者反馈ack完成的消息。
- 4、协调者收到所有参与者反馈的ack消息后，即完成事务提交。
阶段2任何一个参与者反馈no，或者等待超时后协调者尚无法收到所有参与者的反馈，即中断事务：
1、如果协调者处于工作状态，向所有参与者发出abort请求。
2、参与者使用阶段1中的undo信息执行回滚操作，并释放整个事务期间占用的资源。
3、各参与者向协调者反馈ack完成的消息。
4、协调者收到所有参与者反馈的ack消息后，即完成事务中断
注意：进入阶段3后，如果协调者出现问题，或者协调者与参与者网络出现问题，都会导致参与者无法接收到协调者发出的do Commit请求或rollback请求。此时，参与者都会在等待超时之后，继续执行事务提交。
阶段三 只允许成功不允许失败，如果服务器宕机或者停电，因为记录的阶段二的数据，重启服务后在提交事务，所以，到了阶段三，失败了也不进行回滚，只允许成功。
