强一致性事务概述
分布式事务领域，最早采用的是符合CAP理论的强一致性事务方案来解决分布式事务问题，强一致性分布式事务要求在任意时刻查询参与全局事务的各个节点的数据都是一致的
典型案例：
包括DTP模型（全局事务模型）、2PC模型（两阶段提交模型）和3PC模型（三阶段提交模型）
优点：
- 数据一致性比较高
- 在任何时刻都能够查询到最新写入的数据
缺点：
- 存在性能问题，在分布式事务未完全提交和回滚之前，应用程序不会查询到最新的数据
- 实现复杂
- 牺牲了可用性
- 不适合高并发场景
DTP模型
DTP模型是X/open组织定义的一套分布式事务标准，这套标准主要定义了实现分布式事务的规范和API，具体的实现交由相应的厂商来实现，其中定义了几个重要的概念，分别是事务、全局事务、分支事务、控制线程
- 事务：一个事务就是一个完整的工作单元，具备ACID特性
- 全局事务：有事务管理器管理的事务，能够一次性操作多个资源管理器
- 分支事务：有事务管理器管理的全局事务中，每个资源管理器中独立执行的事务
- 控制线程：执行全局事务的线程，用来关联应用程序，事务管理器和资源管理器之间三者的关系，也就是表示全局事务和分支事务的关系，通常称为事务上下文环境
DTP模型的执行流程
DTP模型定义了实现分布式事务的规范和API，主要执行流程如下：
主要定义了3个核心组件，分别为AP、TM、RM
- AP：应用程序（Application Program）可以理解为参与DTP分布式事务模型的应用程序
- RM：资源管理器（Resource Manager）可以理解为数据库管理系统或消息服务管理器，应用程序可以通过资源管理器对相应的资源进行有效的控制
- TM：事务管理器（Transaction Manager）负责协调和管理DTP模型中的事务，为应用程序提供编程接口，同事管理资源管理器
其中，AP可以跟TM、RM通信，TM和RM互相之间可以通信，DTP模型定义了XA接口，TM和RM能够通过XA接口进行双向通信。TM控制着全局事务，管理事务的生命周期并协调资源。RM控制和管理实际的资源
2PC模型
2PC模型是指两阶段提交协议模型，这种模型将整个事务流程分为Prepare阶段和Commit阶段，
P是指Prepare，即准备，C指的是Commit，即提交
- Prepare阶段：事务管理器给每个参与全局事务的资源管理器发送Prepare消息，资源管理器要么返回失败，要么在本地执行相应的事务，将事务写入本地的Redo Log文件和Undo Log 文件，此时，事务并没有提交
- Commit阶段：如果事务管理器收到了参与全局事务的资源管理器返回的失败消息，则直接给Prepare阶段执行成功的资源管理器发送回滚消息，否则，向每个资源管理器发送Commit消息，相应的资源管理器根据事务管理器发送过来的消息指令，执行对应的事务回滚或事务提交操作，并且释放事务处理过程中使用的锁资源
执行成功流程：
执行失败流程：
2PC模型存在的问题：
- 同步阻塞问题：事务的执行过程中，所有参与事务的节点都会对其占用的公共资源加锁，导致其他访问公共资源的进程或者线程阻塞
- 单点故障问题：如果事务管理器发生故障，则资源管理器会一直阻塞
- 数据不一致问题：如果在Commit阶段，由于网络或者部分资源管理器发生故障，导致部分资源管理器没有收到事务管理器发送过来的Commit消息，会引起数据不一致的问题
- 无法解决的问题：如果在Commit阶段，事务管理器发起Commit消息后宕机，并且唯一接收到这条Commit消息的资源管理器也宕机了，则无法确认事务是否已经提交
3PC模型
3PC模型指的是三阶段提交，是在2PC模型的基础上改进的版本，3PC模型把2PC模型中的Prepare阶段一分为二，最终形成3个阶段：CanCommit阶段、PreCommit阶段和doCommit或者doRollback阶段，同样也分为事务执行成功和事务执行失败2种情况
事务执行成功的流程
事务执行失败的流程：
3PC模型中存在的问题：
与2PC相比3PC主要解决了单点故障问题，并减少了事务执行过程中产生的阻塞现象，在3PC模型中，如果资源管理器无法及时收到来自事务管理器发出的消息，那么资源管理器就会执行提交事务的操作，而不是一直持有事务的资源并处于阻塞状态，但是这种机制会导致数据不一致的问题
如果由于网络故障等原因，导致资源管理器没有及时收到事务管理器发出的Abort消息，则资源管理器会在一段时间后提交事务，这就导致了与其他接收到Abort消息并执行了事务回滚的资源管理器的数据不一致
