随着并发量、数据量越来越大及业务已经细化到不能再按照业务划分，我们不得不使用分布式数据库提高系统的性能。在分布式系统中，各个节点在物理上都是相对独立的，每个节点上的数据操作都可以满足 acid。但是，各独立节点之间无法知道其他节点事务的执行情况，如果想让多台机器中的数据保存一致，就必须保证所有节点上的数据操作要么全部执行成功，要么全部不执行，比较常规的解决方法是引入“协调者”来统一调度所有节点的执行。
x/open 组织（即现在的 open group）定义了分布式事务处理模型。x/open dtp 模型（1994）包括应用程序（ap）、事务管理器（tm）、资源管理器（rm）、通信资源管理器（crm）四部分。事务管理器（tm）是交易中间件，资源管理器（rm）是数据库，通信资源管理器（crm）是消息中间件。通常把一个数据库内部的事务处理看作本地事务，而分布式事务处理的对象是全局事务。全局事务是指在分布式事务处理环境中，多个数据库可能需要共同完成一个工作，这个工作就是一个全局事务。在一个事务中可能更新几个不同的数据库，此时一个数据库对自己内部所做操作的提交不仅需要本身的操作成功，还需要全局事务相关的其他数据库的操作成功。如果任一数据库的任一操作失败，则参与此事务的所有数据库所做的所有操作都必须回滚。xa就是x/open dtp 定义的交易中间件与数据库之间的接口规范（即接口函数），交易中间件用它来通知数据库事务的开始、结束、提交、回滚等，xa 接口函数由数据库厂商提供，根据这一思想衍生出二阶段提交协议和三阶段提交协议。
所谓的两个阶段是指准备阶段和提交阶段。
准备阶段指事务协调者（事务管理器）向每个参与者（资源管理器）发送准备消息，每个参与者要么直接返回失败消息（如权限验证失败），要么在本地执行事务，写本地的 redo 和undo日志但不提交，可以进一步将准备阶段分为以下三步。
（1）协调者节点向所有参与者节点询问是否可以执行提交操作（vote），并开始等待各参与者节点的响应。
（2）参与者节点执行询问发起为止的所有事务操作，并将 undo 信息和 redo 信息写入日志。
（3）各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功，则它返回一个“同意”消息；如果参与者节点的事务操作实际执行失败，则它返回一个“中止”消息。
提交阶段指如果协调者收到了参与者的失败消息或者超时，则直接向每个参与者发送回滚（rollback）消息，否则发送提交（commit）消息，参与者根据协调者的指令执行提交或者回滚操作，释放所有事务在处理过程中使用的锁资源。
二阶段提交所存在的缺点如下。
（1）同步阻塞问题，在执行过程中所有参与节点都是事务阻塞型的，当参与者占用公共资源时，其他第三方节点访问公共资源时不得不处于阻塞状态。
（2）单点故障，由于协调者的重要性，一旦协调者发生故障，则参与者会一直阻塞下去。
（3）数据不一致，在二阶段提交的第 2 个阶段中，当协调者向参与者发送 commit 请求之后发生了局部网络异常或者在发送 commit 请求的过程中协调者发生了故障，则会导致只有一部分参与者接收到了 commit 请求，而在这部分参与者在接收到 commit 请求之后就会执行commit操作，其他部分未接收到 commit 请求的机器则无法执行事务提交，于是整个分布式系统便出现了数据不一致的现象。
由于二阶段提交存在诸如同步阻塞、单点问题、数据不一致、宕机等缺陷，所以，研究者们在二阶段提交的基础上做了改进，提出了三阶段提交。
三阶段提交（three-phase commit，3pc），也叫作三阶段提交协议（three-phase commitprotocol），是二阶段提交（2pc）的改进版本。三阶段提交把二阶段提交的准备阶段再次一分为二，这样三阶段提交就有 cancommit、precommit、docommit 三个阶段。
（1）cancommit 阶段：三阶段提交的 cancommit 阶段其实和二阶段提交的准备阶段很像，协调者向参与者发送 commit 请求，参与者如果可以提交就返回 yes 响应，否则返回 no 响应。
（2）precommit 阶段：协调者根据参与者的反应情况来决定是否可以记录事务的 precommit操作。根据响应情况，有以下两种可能。
假如协调者从所有参与者那里获得的反馈都是 yes 响应，则执行事务。
假如有任何一个参与者向协调者发送了 no 响应，或者等待超时之后协调者都没有接到参与者的响应，则执行事务的中断。
（3）docommit阶段：该阶段进行真正的事务提交，也可以分为执行提交、中断事务两种执行情况。
执行提交的过程如下。
协调者接收到参与者发送的ack响应后，将从预提交状态进入提交状态，并向所有参与者发送docommit请求。
事务提交参与者接收到docommit请求之后，执行正式的事务提交，并在完成事务提交之后释放所有的事务资源。
事务提交完之后，向协调者发送ack响应。
协调者接收到所有参与者的ack响应之后，完成事务。中断事务的过程如下。
协调者向所有参与者发送abort请求。
参与者接收到 abort 请求之后，利用其在第 2 个阶段记录的 undo 信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。
参与者完成事务回滚之后，向协调者发送 ack 消息。
协调者接收到参与者反馈的 ack 消息之后，执行事务的中断。
mycat在1.6版本以后已经完全支持 xa 分布式强事务类型了，先通过一个简单的示例来了解mycat中xa的用法。
用户应用侧（ap）的使用流程如下：
（1）set autocommit=0
在应用层需要设置事务不能自动提交；
（2）set xa=on
在 sql 中设置 xa 为开启状态；
（3）执行 sql
insert into travelrecord(id,name) values(1,’n’),(6000000,’a’),(321,’d’),(13400000,’c’),(59,’e’);
（4）commit 或者 rollback
对事务进行提交（提交成功或者回滚异常）。
完整的流程图如图所示。
mycat 内部实现侧的实现流程如下：
将 mysqlconnection 中的 autocommit 设置为 false；
在mycat中开启 xa 事务管理器，用 mycatserver.getinstance().genxatxid()生成 xid，用xa start xid 命令进行 xa 事务开始标记，继续拼装 sql 业务（mycat 会将上面的 insert 数据分片到不同的节点上），拼装 xa end xid，xa prepare xid 最后进行 1pc 提交并记录日志到 tm.log 中，如果 1pc 阶段有异常，则直接回滚事务 xa rollback xid。
（3）在多节点 mysql 中全部进行 2pc 提交（xa commit），提交成功后，事务结束；如果有异常，则对事务进行重新提交或者回滚。
mycat 中的 xa 分布式事务的异常处理流程如下：
（1）一阶段 commit 异常：如果 1pc 提交任意一个 mysql 节点无法提交或者异常，则全部节点的事务进行回滚，抛出异常给应用侧事务回滚。
（2）mycat crash recovery
mycat 崩溃以后，根据 tm.log 事务日志再进行重启恢复，mycat 启动后执行事务日志查找各个节点中已经 prepared 的 xa 事务，进行 commit 或者 rollback。
通过用户应用侧发送 set xa = on ; sql 开启 mycat 内部 xa 事务管理器的功能，事务管理器将对 mysql 数据库进行 xa 方式的事务管理，具体事务管理功能的实现代码如下：
mysqlconnection：数据库连接。
nonblockingsession：用户连接 session。
multinodecoordinator：协调者。
commitnodehandler：分片提交处理。
rollbacknodehandler：分片回滚处理。
xa 事务启动的源码如下：
用户应用侧设置手动提交以后，mycat 会在当前连接中加入
将该语句加入到 stringbuffer 中，等待提交到数据库。
用户连接 session 的源码如下：
用户应用侧发送该语句到 mycat 中，由 sql 语句解析器解析后交由 sethandle 进行处理c.getsession2().setxatxenabled (true);
调用 nonblocksession 中的 setxatxenable d 方法设置 xa 开关启动，并生成 xid,代码如下：
另外，nonblocksession 会接收来自于用户应用侧的 commit, 调用 commit 方法进行处理事务提交的逻辑。
在 commit()方法中，首先会 check 节点个数，一个节点和多个节点分为不同的处理过程，这里只讲下多个节点的处理方法 checkdistritransaxandexecute();
该方法会对多个节点的事务进行提交。
协调者的源码如下：
在 nonblocksession 的 checkdistritransaxandexecute()方法中， nonblocksession 会话类会调用专门进行多节点协同的 multinodecoordinator 类进行具体的处理，在 multinodecoordinator类中，executebatchnodecmd 方法加入 xa 1pc 提交的处理，代码片段如下：
在 multinodecoordinator 类的 okresponse 方法中，则进行 2pc 的事务提交
分片事务提交处理的源码如下：
在 mycat 中同样支持单节点 mysql 数据库的 xa 事务处理，在 commitnodehandler 类中就是对单节点的 xa 二阶段处理，处理方式与 multinodecoordinator 类同，通过 commit 方法进行 1pc 的提交，而通过 okresponse 的方法进行 2pc 阶段的事务提交。
分片事务回滚处理的源码如下：
在 rollbacknodehandler 的 rollback 方法中加入了对 xa 事务的 rollback 处理，用户应用侧发起的 rollback 会在这个方法中进行处理。
同样，该方法会对所有的 mysql 数据库节点发起 xa rollback 指令。