前述
本篇标题是MySQL分布式事务，但MySQL分布式事务只是对相关理论的实现，所以会花很大篇幅介绍分布式相关理论、解决方案，最后再讲解MySQL对XA协议的实现。
分布式事务理论
什么是分布式事务呢？
分布式事务是很多网络主机参与的事务，支持事务的事务管理器，资源管理器位于不同的网络节点上。
CAP定理
所谓CAP定理，是指在一个分布式系统中，无法同时满足一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance），最多只能满足其中两个。下面解释下这三个分布式指标。
-
一致性（Consistence）：对于分布式系统的任何节点做更新，其他节点应该同步更新，多个节点读取到的数据不应该存在差异。
-
可用性（Availability）：可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作，请求总是能够在有限的时间内返回结果，如果超过了这个时间范围，那么系统就被认为是不可用的。“有限的时间内”是在系统的运行指标，不同系统会有差别。“返回结果”是可用性的另一个重要指标，它要求系统完成对用户请求的处理后，返回一个正常的响应结果，要明确的反映出对请求处理的成功或失败。
-
分区容错性（Partition Tolerance）：当分布式系统各节点网络不可达成独立的部分时，每个独立部分就叫一个分区。分区容错性要求各节点不连通时，能独立的提供完整的功能。因此要求每个分区有其他分区的数据复制。
对于实际应用，分区容错性是需要保证的。提高分区容错性，要求将数据复制到多个节点。然后，数据复制到多个节点，就会存在数据一致性问题。如果强制写同步，就会造成客户端请求阻塞时间变长，可能导致有限时间不能返回结果，从而影响可用性。
综上，CAP是不可能同时满足的，实际应用都是CA和CP。当然，大部分生产环境，都更看中可用性，而弱化一致性。一致性可以通过消息通信、补偿等机制，达到最终一致便可。
BASE定理
正如上一小节所讲，实际应用大部分情况都是弱化一致性，达到最终一致性即可。最终一致性便是BASE定理，是CAP定理的延伸。下面看看BASE定理的三个指标。
-
基本可用：指分布式系统在出现故障的时候，允许损失部分可用性（例如响应时间、功能上的可用性）。
-
软状态：指允许分布式系统出现中间状态。如异步主从复制，允许数据同步的延时。
-
最终一致性：最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。
以上内容参考CAP和BASE理论
分布式事务实现方案
2PC方案
2PC分两个阶段，第一阶段准备阶段，第二阶段提交和回滚。下面分别介绍下这两个阶段。
1）准备阶段
在准备阶段，事务管理器（下面称协调者）向所有资源管理器（下面称参与者）下发prepare指令，参与者收到指令后，锁定所需要的资源，并把undo和redo写入日志。
2）提交或回滚阶段
如果第一阶段所有参与者都像协调者确认成功，那么协调者会向所有参与者发送commit指定，事务提交。否则，只要第一个阶段有一个参与者没有确认成功，就发送rollback指令，事务回滚。
由于2PC没有超市机制，在准备阶段，如果其中一台参与者宕机，就会造成协调者一直阻塞等待，影响并发性能。而且并发性能，又性能最低的参与者决定。
3PC方案
3PC（三阶段协议方案）是对2PC的改进。它分CanCommit，PreCommit，DoCommit三个阶段。
1）CanCommit
协调者向所有参与者询问是否可以进行事务提交。
2）PreCommit
如果第一阶段所有参与者都能进行事务提交，协调者下发PreCommit指令。协调者锁定资源，等待下一步指令。如果第一阶段有一个或以上参与者不能进行事务提交，下达中断指令。
3）DoCommit
如果第二阶段所有参与者都确认成功，下达Docommit指令，事务提交。否则下达事务回滚指令。
三阶段提交对比两阶段，引入超时机制减少事务阻塞，解决单点故障。在第三阶段，一旦参与者无法接受到协调者信号时，等待超时之后，参与者默认执行 commit，释放资源。
三阶段任然不能解决数据一致性问题。若协调者发出回滚命令，但是由于网络问题，参与者在等待时间内都无法接收到，这时参与者默认提交事务，而其他事务进行了回滚，造成事务不一致。
TCC
2PC和3PC都是数据资源库资源层的实现方案，TCC则是业务层面的实现方案，是对BASE定理的很好解决方案。
TCC是Try、Confirm和Cancel三个单词的首字母，它们相当于编程语言的异常机制。尝试执行某些语句，成功则提交，失败则做一些清除工作。下面介绍三个情况。
TCC实现的一个方案就是维护本地消息列表，对每个事务记录日志，定期扫描日志，对失败的事务重新提交或撤销，以保证所有参与者数据最终一致。
参考资料：分布式事务的图文详解
MQ事务消息
很好的实现方案是阿里开源的RocketMQ，这里不再介绍，可以查看相关资料。
参考资料：分布式事务解决方案
MySQL分布式事务的实现
MySQL是资源管理器（参与者），因此它实现的是XA协议（2PC和3PC），MySQL有内部XA事务和外部XA事务。
内部XA事务
MySQL的各存储引擎是独立的，因此需要XA事务协调。对于二进制日志的操作，写需要XA事务。此时MySQL数据库服务器相当于协调者，而各存储引擎或二进制日志写线程作为参与者。
外部XA事务
这种情况MySQL作为一个完整的参与者组成分布式系统。MySQL对XA协议支持并不是很完整，因此更多的是通过其他解决方案，这里不再介绍。
后述
分布式系统的CAP问题，是计算机的难点问题。如何保证数据的一致性和可用性，更多的情况是采取弱一致性，基于本地消息补偿实现最终一致。阿里的RocketMQ也是一种很好的方案。