强一致性分布式事务XA 浅析_xa事务

一、前言

分布式事务：分布式条件下,多个节点操作的整体事务一致性。

特别是在微服务场景下,业务 A 和业务 B 关联,事务 A 成功,事务 B 失败,由于跨系统, 就会导致不被感知。 此时从整体来看,数据是不一致的。

分布式事务中的两大基本理论：CAP 理论 与 Base 理论。

分布式事务解决方案可以分为：

• 强一致性分布式事务解决方案：基于 CAP 理论
• 最终一致性分布式事务解决方案：基于 Base 理论

强一致性分布式解决方案

在强一致性事务解决方案中，典型的方案包括：

• DTP 模型（全局事务模型）：基于 DTP 模型，典型的解决方案是分布式通信协议 XA 规范
• 2PC 模型（二阶段提交模型）
• 3PC 模型（三阶段提交模型）

（1）DTP 模型

DTP 模型是 X/Open 组织定义的一套分布式事务标准，这套标准主要定义了实现分布式事务的规范和 API。

DTP 模型的重要概念：

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

在 DTP 模型中，定义了 3个核心组件：

1. 应用程序（AP）：参与 DTP 分布式事务模型的应用程序。
2. 事务管理器（TM）：负责协调和管理 DTP 模型中的事务，为应用程序提供编程接口，同时管理资源管理器。
3. 资源管理器（RM）：数据库管理系统或消息服务管理器。

（2）2PC 模型

两阶段提交（Two-phase Commit, 2PC）算法，经常用来实现分布式事务。

2PC 模型两阶段执行流程：

1. Prepare 准备阶段：在本地执行相应的事务，但事务并没有提交。
2. Commit 提交阶段：发送 回滚消息 或者 提交消息。

2PC 模型存在的问题：

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

（3）3PC 模型

3PC 模型是指三阶段提交模型，是在 2PC 模型的基础上改进的版本。

3PC 模型把 2PC 模型中的 Prepare 阶段一分为二，形成 3个阶段：

1. CanCommit 阶段：询问是否能够执行事务。
2. PreCommit 阶段：执行事务操作。
3. doCommit / doRollback 阶段：正式提交事务。

3PC 模型主要解决了 单点故障问题，并减少了事务执行过程中产生的阻塞现象。

 

二、XA 强一致性分布式事务原理

XA 规范：

• xa_start: 负责开启或者恢复一个事务分支，并且管理 XID 到调用线程。

• xa_end: 负责取消当前线程与事务分支的关联。

• xa_prepare: 询问 RM 是否准备好提交事务分支。

• —————— 第一阶段提交 —————————

  如果是单机，可以直接跳过 prepare 和第二阶段，输入 one phase commit 事务id 直接进行提交即可。

• xa_commit: 通知 RM 提交事务分支。

• xa_rollback: 通知 RM 回滚事务分支。

• xa_recover: 需要恢复的 XA 事务。

• —————— 第二阶段提交 —————————

XA 二阶段提交：

• 一阶段：执行 XA PREPARE 语句。
• 二阶段：执行 XA