强一致性事务概述

      在分布式领域中，最早采用的是符合 CAP 理论的强一致性事务方案来解决分布式事务。强一致性分布式事务要求在任意时刻查询参与全局事务的各节点的数据都是一致的。

典型方案

      在强一致性事务解决方案中，典型的方案包括 DTP模型(全局事务模型)、2PC模型(二阶段提交模型)和3PC模型(三阶段提交模型)。

适用场景

      强一致性事务主要用于对数据一致性要求比较高，在任意时刻都要查询到最新写入数据的场景。

优缺点

      强一致性事务解决方案存在如下优点：

1. 数据一致性要求比较高
2. 在任意时刻都能够查询到最新写入的数据

      强一致性事务解决方案也存在着如下缺点：

1. 存在性能问题，在分布式事务未完全提交和回滚之前，应用程序不会查询到最新的数据
2. 实现复杂
3. 牺牲了可用性
4. 不适合高并发场景

DTP 模型

      DTP 模型是 X/Open 组织定义的一套分布式事务标准，这套标准主要定义了实现分布式事务的规范和 API，具体的实现则交给相应的厂商来实现。

DTP 模型的重要概念

      DTP 模型中定义了几个重要的概念，分别为事务、全局事务、分支事务和控制线程。

1. 事务：一个事务就是一个完整的工作单元，具备 ACID 特性
2. 全局事务：由事务管理器管理的事务，能够一次性操作多个资源管理器
3. 分支事务：由事务管理器管理的全局事务中，每个资源管理器中独立执行的事务
4. 控制线程：执行全局事务的线程，这个线程用来关联应用程序、事务管理器和资源管理器三者之间的关系，也就是表示全局事务和分支事务的关系，通常称为事务上下文环境。

DTP 模型的执行流程

      DTP 模型定义了实现分布式事务的规范和 API，主要的执行流程如下图所示：

      在 DTP 模型中，主要定义了3个核心组件，分别为 AP、TM、RM。

1. AP：应用程序(Application Program)可以理解为参与 DTP 分布式事务模型的应用程序；
2. RM：资源管理器(Resource Manager)可以理解为数据库管理系统或消息服务管理器。应用程序可以通过资源管理器对相应的资源进行有效的控制。相应的资源需要实现 XA 定义的接口。
3. TM：事务管理器(Transaction Manager)负责协调和管理 DTP 模型中的事务，为应用程序提供编程接口，同时管理资源管理器。

      AP 可以和 TM、RM 通信，TM 和 RM 互相之间可以通信，DTP 模型定义了 XA 接口，TM 和 RM 能够通过 XA 接口进行双向通信。TM 控制着全局事务，管理事务的声明周期并协调资源。RM 控制和管理实际的资源。

2PC 模型

      2PC 模型是指两阶段提交协议模型，这种模型将整个事务流程分为 Prepare 阶段和 Commit 阶段。

2PC 模型的执行流程

      Prepare 阶段：事务管理器给每个参与全局事务的资源管理器发送 Prepare 消息，资源管理器要么返回失败，要么在本地执行相应的事务，将事务写入本地的 Redo Log 文件和 Undo Log 文件，此时，事务并未提交。
      Commit 阶段：如果事务管理器收到了参与全局事务的资源管理器返回的失败消息，则直接给 Prepare 阶段执行成功的资源管理器发送回滚消息，否则，向每个资源管理器发送 Commit 消息。相应的资源管理器根据事务管理器发送过来的消息指令，执行对应的事务回滚或事务提交操作，并且释放事务处理过程中使用的锁资源。

2PC 模型存在的问题

      2PC 模型存在如下缺点：

1. 同步阻塞问题：事务的执行过程中，所有参与事务的节点都会对其占用的公共资源加锁，导致其他访问公共资源的进程或者线程阻塞
2. 单点故障问题：如果事务管理器发生故障，则资源管理器会一直阻塞
3. 数据不一致问题：如果在 Commit 阶段，由于网络或者部分资源管理器发生故障，导致部分资源管理器没有接收到事务管理器发送过来的 Commit 消息，会引起数据不一致的问题
4. 无法解决的问题：如果在 Commit 阶段，事务管理器发出 Commit 消息后宕机，并且唯一接收到这条 Commit 消息的资源管理器也宕机了，则无法确认事务是否已经提交

3PC 模型

      3PC 模型是指三阶段提交模型。它将2PC模型中的 Prepare 阶段一分为二，最终形成3个阶段：CanCommit 阶段、PreCommit 阶段和 doCommit 或者 doRollback 阶段。

事务执行成功的流程

      如下图，在事务执行成功的 CanCommit 阶段，事务管理器向参与全局事务的资源管理器发送 CanCommit 消息，资源管理器收到 CanCommit 消息，认为能够执行事务，会向事务管理器响应 Yes 消息，进入预备状态。

      在事务执行成功的 PreCommit 阶段，事务管理器会向参与全局事务的资源管理器发送 PreCommit 消息，资源管理器收到 PreCommit 消息后，执行事务操作，将 Undo 和 Redo 信息写入事务日志，并向事务管理器响应 Ack 状态，但此时不会提交事务。

      在事务执行成功的 doCommit 阶段，事务管理器会向参与全局事务的资源管理器发送 doCommit 消息，资源管理器接收到 doCommit 消息后，正式提交事务，并释放执行事务期间占用的资源，同时向事务管理器响应事务已提交的状态。事务管理器收到资源管理器响应的事务已提交的状态，完成事务的提交。

事务执行失败的流程

      如下图，在事务执行失败的 CanCommit 阶段，事务管理器会向参与全局事务的资源管理器发送 CanCommit 消息，如果资源管理器收到 CanCommit 消息后，认为不能执行事务，则会向事务管理器响应 No 状态。

      在事务执行失败的 PreCommit 阶段，事务管理器会向参与全局事务的资源管理器发送 Abort 消息，资源管理器收到 Abort 消息 或者期间出现超时，都会中断事务的执行。

      在事务执行失败的 doRollback 阶段，事务管理器会向参与全局事务的资源管理器发送 Rollback 消息，资源管理器会利用 Undo Log 日志信息回滚事务，并释放执行事务期间占用的资源，向事务管理器返回事务已回滚的状态。事务管理器收到资源管理器返回的事务已回滚的消息，完成事务回滚。

3PC 模型中存在的问题

      在3PC模型中，如果资源管理器无法及时收到来自事务管理器发出的消息，那么资源管理器就会执行提交事务的操作，而不是一直持有事务的资源并处于阻塞状态，但是这种机制会导致数据不一致的问题。

版权属于：带翅膀的猫

本文链接：https://www.chengpengper.cn/archives/231/

转载时须注明出处及本声明