下图是个典型的分库分表场景，前端是一个Proxy后面带若干个MySQL实例，每个实例是一个分区。

假设一个表test定义如下，Proxy根据主键”a”算Hash决定一条记录应该分布在哪个节点上：

应用发到Proxy的一个事务如下：

  2. insert into test values (1, 1);
  3. update test set b = 1 where a = 10;
  4. commit;

Proxy收到这个事务需要将它转成XA事务发送到后端的数据库以保证这个事务能够安全的提交或回滚，一般的Proxy的处理步骤 如下：

  1. Proxy先收到begin，它只需要设置一下自己的状态不需要向后端数据库发送
  2. Proxy就会向分库1上发送语句xa start ‘xid1’，开启一个XA事务，这里xid1是Proxy自动生成的一个全局事务ID；同时原来 的insert语句insert into values(1,1)也会一并发送到分库1上。
  3. 这时Proxy遇到了update语句，Proxy会解析 where条件主键的值来决定该条语句会被发送到哪个节点上，这里假设是“分库2”
  4. Proxy就会向分库2上发送语句xa start ‘xid1’，开启一个XA事务，这里xid1是Proxy之前已经生成的一个全局事务ID；同时原来 的update语句update test set b = 1 where a = 10也会一并发送到分库2上。
  5. 最后当Proxy解析到commit语句时，就知道一个用户事务已经结束了，就开启提交流程
  6. Proxy会向分库1和分库2发送 xa end ‘xid1’;xa prepare ‘xid1’语句，当收到执行都成功回复后，则继续进行到下一步，如果任何一个分 库返回失败，则向分库1和分库2 发送 xa rollback ‘xid1’，回滚整个事务
  7. 当 xa prepare ‘xid1’都返回成功，那么 proxy会向分库1和分库2上发送 xa commit ‘xid1’，来最终提交事务。

从以上分库分表场景下分布式事务的处理过程来看，整个分布式事务的安全性依赖是XA Prepare了的事务的可靠性，也就是在 数据库节点上 XA Prepare了的事务必须是持久化了的，这样当XA Commit发来时才可以提交。设想如下场景：

  1. Proxy已经向分库1和分库2上发送完了 xa prepare ‘xid1’语句，并得到了成功的回复
  2. Proxy向分库1上发送了 ‘xa commit ‘xid1’语句，并已经成功返回
  3. 当 Proxy向分库2上发送 ‘xa commit ‘xid1’时，网络断开了，或者分库2的数据库实例被kill了
  4. 当网络恢复（这时相关的Session已经退出了）或数据库实例再启动后（或切换到备库），XA prepare了的事务已经回滚了， 当Proxy XA commit ‘xid1’发过来后数据库实例根本找不到xid1这个xa事务

上面的过程就导致了分布式事务的不一致：分库1提交了事务，分库2回滚了事务，整个事务提交了一半，回滚了一半。

在MySQL 5.6中以上过程是可能发生的，因为xa prepare并没有严格的持久化，当Session断开，数据库崩溃等情况下这些事务 会被回滚掉，而且的当一个主库配置了SemiSync的备库时xa prepare了的事务也不会被发送的备库，如果主库切换到备库这些 事务也会丢失。

MySQL 5.7解决了 xa prepare了的事务的严格持久化问题，也就是在session断开和实例崩溃重启情况下这些事务不丢，同时在 xa prepare ‘xid1’返回之前XA事务也会同步到备库。下面将通过在5.6和5.7上分别执行xa prepare并对binlog event进行分析 来演示这个改进。

在5.6和5.7上分别执行如下sql然后断开连接，再重新连接使用的xa recover验证 XA 事务是否回滚了。

  2. | formatID | gtrid_length | bqual_length | data |
  3. +----------+--------------+--------------+------+
  4. |        1 |            4 |            0 | xid1 |
  5. +----------+--------------+--------------+------+

说明断开连接后 5.7的prepare了的xa事务没有丢失。

XA 事务的 Binlog events 异同

在5.6和5.7上分别执行如下事务，然后用 show binlog events 查看两者binlog的不同：

5.6的结果：

  1. mysql-bin.000001 | 304 | Gtid           |      3706 |         352 | SET @@SESSION.GTID_NEXT= 'uuid:2'
  2. mysql-bin.000001 | 352 | Query          |      3706 |         424 | BEGIN
  3. mysql-bin.000001 | 424 | Table_map      |      3706 |         472 | table_id: 71 (test.test)
  4. mysql-bin.000001 | 472 | Write_rows     |      3706 |         516 | table_id: 71 flags: STMT_END_F

5.7的结果：

可以看到 MySQL 5.6 XA 事务和普通事务的binlog是一样的，并没有体现 xa prepare。而到了 MySQL 5.7 XA 事务的binlog和 普通的事务是完全不同的，XA Prepare有单独的Log event类型，有自己的Gtid，当开启semi-sync的情况下，MySQL 5.7 执行 XA prepare 时会等备库回复后才返回结果给客户端，这样XA prepare执行完就是安全的。