强一致事务要求在任意时刻各节点数据在任意时刻都是一致的。强一致事务的解决方案主要有DTP模型（全局事务模型）、2PC、3PC。

强一致性数据一致性较高，但是存在性能问题，在分布式事务未完全提交和回滚之前，查询不到新的数据，牺牲了可用性，实现也比较复杂，不适合高并发场景。

基于DTP模型典型的解决方案是分布式通信协议的XA规范。Mysql Connector在5.x开始提供对XA规范的支持。XA事务支持不同的数据库，但是需要其都支持XA规范。

1.DTP模型

DTP中几个重要的概念，全局事务，分支事务

全局事务：由事务管理器管理的事务，能够一次操作多个资源管理器

分支事务：每个资源管理器中的独立事务

AP：应用程序

RM：资源管理器，可以理解为数据库

TM：事务管理器，负责协调和管理DTP模型中的事务，提供应用程序编程接口，同时管理资源管理器

 

2.2PC

2PC模型是指两阶段提交模型，它将事务流程分为prepare阶段和commit阶段。

prepare阶段：事务管理器给参与全局事务的资源管理器发送prepare消息，资源管理器要么返回失败，要么在本地执行本地事务，将事务写入本地的redolog文件和undolog文件，此时事务并没有真正提交。

commit阶段：事务管理器收到所有参与事务的资源管理器返回的消息来决定是进行全局事务提交或者回滚

 

2PC存在的问题

　　1.同步阻塞：事务执行过程，参与事务的节点都会对其占用的公共资源枷锁，导致其他访问受阻

　　2.单点故障：事务管理器发生故障，会导致资源一致阻塞

　　3.数据不一致：如果在commit阶段由于网络或部分资源管理器发生故障，会导致部分资源管理器未收到commit消息，导致数据不一致

　　4.无法解决的问题：如果如果commit阶段，事务管理器发出commit消息后宕机，并且唯一收到commit消息的资源管理器也宕机了，则无法确认事务是否已经提交

 

3.3PC

3PC是三阶段提交是2PC的改进版本，它将prepare分成了两个阶段多出了一个canCommit阶段，是否可以提交，再执行doCommit/doRollback。

3PC模型中资源管理器无法收到来自事务管理器发出的消息，资源管理会自己执行事务的提交，不会一致持有造成阻塞，但是这也会导致数据的不一致。

以上主要的问题还是会存在数据的不一致，如果解决这个问题。我们可以记录日志，每个分支事务执行流程中的状态信息。以供发生异常情况之后可以恢复事务。比如Atomikos框架。

后续Atomikos实战...