一、简介
分布式事务概念：
- 数据库内部的分布式事务
某些分布式数据库（例如那些标配支持复制和分区的数据库）支持跨数据库节点的内部事务。
例如，VoltDB和MySQL Cluster的 NDB 存储引擎就是支持这样的内部分布式事务
此时，所有参与节点都运行着相同的数据库软件
- 异构分布式事务
在异构分布式事务中，存在两种或两种以上不同的参与者实现技术。
例如来自不同供应商的数据库，甚至是非数据库系统（如消息中间件）。
即使是完全不同的系统，跨系统的分布式事务也必须确保原子提交。
（1）问题
1）什么是 XA？
X/Open XA（eXtended Architecture, XA）是异构环境下实施两阶段提交的一个工业标准。
XA 并不是一个网络协议，而是一个与事务协调者进行通信的C API。
XA 是 DTP(Distributed Transaction Processing Reference Model)模型定义 TM 和 RM 之前通讯的接口规范。
Open Group定义了一套DTP分布式模型，主要含有：
- AP（Application Program, 应用程序）：使用DTP分布式事务的程序
- TM（Transaction Manager, 事务管理器）:负责协调和管理事务，事务管理器控制着全局事务，管理事务生命周期，并协调各个RM。全局事务是指分布式事务处理环境中，需要操作多个数据库共同完成一个工作，这个工作即是一个全局事务。
- RM（Resource Manager, 资源管理器）：通常指数据库，通过资源管理器对该数据库进行控制，资源管理器控制着分支事务。
- CRM（通讯资源管理器）：通常指消息中间件
XA 接口函数由数据库厂商提供。TM交易中间件用它来通知数据库事务的开始、结束以及提交、回滚等。
XA 模型如图：
二、限制（存在问题）
核心的事务协调者（TM）本身就是一种数据库（存储事务的投票结果）
限制如下：
（1）非高可用
如果事务协调者不支持数据复制，而是在单节点上运行，那么它就是整个系统的单节点故障（因为它的故障导致了很多应用阻塞在停顿事务所持有的锁上）
现实情况是，有许多事务协调者的实现默认情况下非高可用，或者只支持最基本的复制
（2）事务协调者所在的应用服务器不再是无状态
许多服务器应用程序都倾向于无状态模式，而所有的持有状态都保存在数据库中，这样应用服务器可以轻松地添加或删除实例。
但是，当事务协调者就是应用服务器的一部分时，部署方式就发生了根本的变化。
协调者的日志成为可靠系统的重要组成部分，它要求与数据库本身一样重要（需要协调者日志恢复那些有疑问的事务）。
（3）无法检测死锁
由于 XA 需要与各种数据系统保持兼容，它最终其实是多系统可兼容的最低标准。
它无法深入检查不同系统之间的死锁条件（因为这就将需要另一个标准化协议，使得多个系统交换事务所等待的锁信息）
（4）容错
2PC要成功提交事务还是存在潜在的限制，它要求必须所有参与者都投票赞成，如果有任何部分发生故障，整个事务只能失败。
所以分布式事务有扩大事务失败的风险，这与我们构建容错系统的目标有些背道而驰
