分布式事务解决办法之两阶段提交

1 X/OpenDTP模型
X/Open是一个组织机构,定义了一套分布式事务标准,定义了规范的API接口。DTP模型就是这套分布式事务的架构模型，分为AP，TM，RM三个组件，其含义如下：
AP(Application Program)：也就是应用程序，可以理解为使用DTP的程序
RM(Resource Manager)：资源管理器，这里可以理解为一个DBMS系统，或者消息服务器管理系统，应用程序通过资源管理器对资源进行控制。资源必须实现XA定义的接口
TM(Transaction Manager)：事务管理器，负责协调和管理事务，提供给AP应用程序编程接口以及管理资源管理器
其中，AP 可以和TM 以及 RM 通信，TM 和 RM 互相之间可以通信，DTP模型里面定义了XA接口，TM 和 RM 通过XA接口进行双向通信，例如:TM通知RM提交事务或者回滚事务，RM把提交结果通知给TM。AP和RM之间则通过RM提供的Native API 进行资源控制，这个没有进行约API和规范，各个厂商自己实现自己的资源控制，比如Oracle自己的数据库驱动程序。

其中在DTP定了以下几个概念：
事务：一个事务是一个完整的工作单元，由多个独立的计算任务组成，这多个任务在逻辑上是原子的。
全局事务：对于一次性操作多个资源管理器的事务，就是全局事务
分支事务：在全局事务中，某一个资源管理器有自己独立的任务，这些任务的集合作为这个资源管理器的分支任务
控制线程：用来表示一个工作线程，主要是关联AP,TM,RM三者的一个线程，也就是事务上下文环境。简单的说，就是需要标识一个全局事务以及分支事务的关系。其中包含了两个协议分别如下：
TX协议：应用或应用服务器与事务管理器的接口
XA协议：全局事务管理器与资源管理器的接口
简单来说就是应用程序要发起一个分布式事务通过TX协议与事务管理器进行交互，而与这个全局事务相关联的分支事务是由对应的资源管理器来控制，事务管理器通过XA协议来控制各个资源管理器的协调运行，从而达到解决分布式事务的目的。
2 两阶段提交(2PC)
基于上述DTP模型出现了许多的方案，其中比较出名就是两阶段提交，也称为2PC。它分为两个执行阶段，如下：
（1）准备阶段
事务协调者，向所有事务参与者发送事务内容，询问是否可以提交事务，并等待参与者回复。事务参与者收到事务内容，开始执行事务操作，将 undo 和 redo 信息记入事务日志中（但此时并不提交事务）。如果参与者执行成功，给协调者回复yes,表示可以进行事务提交。如果执行失败，给协调者回复no,表示不可提交。
（2）提交阶段
如果协调者收到了参与者的失败信息或超时信息，直接给所有参与者发送回滚（rollback）信息进行事务回滚，否则，发送提交（commit）信息。参与者根据协调者的指令执行提交或者回滚操作，释放所有事务处理过程中使用的锁资源。(注意：必须在最后阶段释放锁资源) 接下来分两种情况分别讨论提交阶段的过程。
原理图如下：

3.两阶段提交的缺点
（1）同步阻塞 所有事务参与者在等待其它参与者响应的时候都处于同步阻塞状态，无法进行其它操作。
（2）单点问题 协调者在 2PC 中起到非常大的作用，发生故障将会造成很大影响。特别是在阶段二发生故障，所有参与者会一直等待状态，无法完成其它操作。
（3）数据不一致 在阶段二，如果协调者只发送了部分 Commit 消息，此时网络发生异常，那么只有部分参与者接收到 Commit 消息，也就是说只有部分参与者提交了事务，使得系统数据不一致。
（4）太过保守 任意一个节点失败就会导致整个事务失败，没有完善的容错机制。

参考链接：
https://www.cnblogs.com/aigongsi/archive/2012/10/11/2718313.html
https://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html
https://www.cnblogs.com/monkeyblog/p/10449363.html
https://www.cnblogs.com/szlbm/p/5588543.html