XA事务就是两阶段提交的一种实现方式
XA规范主要定义了事务管理器TM，和资源管理器RM之间的接口
根据2PC的规范，将一次事务分割成两个阶段
1. prepare阶段
TM向所有RM发送prepare指令，RM接受到指令后执行数据修改和日志记录等操作，然后返回 可以提交/不可提交 给TM
（按照我的理解应该类似于MySQL在开启一个事务之后，只差最后的COMMIT或者ROLLBACK的状态）
2. commit阶段
TM接受到所有RM的prepare结果
如果有RM返回是 不可提交 或者超时，那么向所有RM发送ROLLBACK命令
如果所有RM都返回可以提交，那么向所有RM发送COMMIT命令
XA的异常情况处理
MySQL与XA事务的关系有两种情况
1. 内部XA
在使用innodb作为存储引擎，并且开启binlog的情况下，MySQL同时维护了binlog日志与innodb的redo log
为了保证这两个日志的一致性，MySQL使用了XA事务，由于只在单机上工作，所以被称为内部XA
2. 外部XA
就是一般谈论的分布式事务了
MySQL支持XA START/END/PREPARE/COMMIT这些sql语句，通过使用这些命令，我们是可以完成分布式事务的
状态转移图如下
（我有点不能理解的是，为什么一定需要XA END这个语句，直接XA PREPARE不行吗）
在MySQL5.7.7之前，XA事务是有bug的
如果有一个XA事务处于PREPARE状态
1. 如果连接关闭，或者MySQL服务器正常退出，这个事务会被回滚（但是根据XA规范，这个事务应该被保留）
2. 如果MySQL服务器被强制结束，在重启之后，用XA RECOVER命令可以看到这个事务，这个事务也可以被XA COMMIT所提交，但是相关的binlog记录会丢失，这样就会导致数据库引擎中的数据与binlog中的数据不一致 （参考资料）
这两个bug被提出了十年之久，终于在5.7.7中被修正了（第一个bug阿里自己也搞了个修正）
就目前来看，MySQL的XA事务现在做得还不错，应该是可用的
还是有一些不能理解的地方
1. 官方文档中强调：在使用分布式事务的时候，需要使用串行隔离级别，为什么？
原因：为了尽可能提高分布式事物的隔离级别，如果分库上使用MySQL默认的RR，那么导致总的分布式事务的隔离级别为RU
参考资料
1. MySQL binlog 组提交与 XA(两阶段提交)
2. MySQL redolog与组提交资料1 资料2 资料3 资料4
3. MySQL官方的XA文档
4. XA事务的隔离级别