方案1：基于 DTP 模型的 XA 全局事务

全局事务基于 DTP 模型实现。DTP 是由 X/Open 组织提出的一种分布式事务模型——X/Open Distributed Transaction Processing Reference Model。它规定了要实现分布式事务，需要三种角色：

• AP：Application 应用系统

  它就是我们开发的业务系统，在我们开发的过程中，可以使用资源管理器提供的事务接口来实现分布式事务。

• TM：Transaction Manager 事务管理器

  • 分布式事务的实现由事务管理器来完成，它会提供分布式事务的操作接口供我们的业务系统调用。这些接口称为 TX 接口。
  • 事务管理器还管理着所有的资源管理器，通过它们提供的 XA 接口来同一调度这些资源管理器，以实现分布式事务。
  • DTP 只是一套实现分布式事务的规范，并没有定义具体如何实现分布式事务，TM 可以采用2PC、3PC、Paxos 等协议实现分布式事务。

• RM：Resource Manager 资源管理器

  • 能够提供数据服务的对象都可以是资源管理器，比如：数据库、消息中间件、缓存等。大部分场景下，数据库即为分布式事务中的资源管理器。
  • 资源管理器能够提供单数据库的事务能力，它们通过 XA 接口，将本数据库的提交、回滚等能力提供给事务管理器调用，以帮助事务管理器实现分布式的事务管理。
  • XA 是 DTP 模型定义的接口，用于向事务管理器提供该资源管理器(该数据库)的提交、回滚等能力。
  • DTP 只是一套实现分布式事务的规范，RM 具体的实现是由数据库厂商来完成的。

实际方案：基于 XA 协议的两阶段提交

XA 是一个分布式事务协议，由 Tuxedo 提出。

XA 中大致分为两部分：事务管理器 TM 和本地资源管理器 RM。其中本地资源管理器往往由数据库实现，比如 Oracle、DB2 这些商业数据库都实现了 XA 接口，而事务管理器作为全局的调度者，负责各个本地资源的提交和回滚。

XA 分布事务过程

总的来说，XA 协议比较简单，而且一旦商业数据库实现了 XA 协议，使用分布式事务的成本也比较低。

但是，XA 也有致命的缺点，那就是性能不理想，特别是在交易下单链路，往往并发量很高，XA 无法满足高并发场景。XA 目前在商业数据库支持的比较理想，在 mysql 数据库中支持的不太理想，mysql 的 XA 实现，没有记录 prepare 阶段日志，主备切换回导致主库与备库数据不一致。许多 nosql 也没有支持 XA，这让 XA 的应用场景变得非常狭隘。

方案2：基于可靠消息服务的分布式事务（事务消息中间件）

这种实现分布式事务的方式需要通过消息中间件来实现。假设有 A 和 B 两个系统，分别可以处理任务 A 和任务 B。此时系统 A 中存在一个业务流程，需要将任务 A 和任务 B 在同一个事务中处理。下面来介绍基于消息中间件来实现这种分布式事务。