MySQL分布式事务（XA事务）

XA由协调者(coordinator，一般为transaction manager)和参与者(participants,一般在各个资源上有各自的resource manager)共同完成。在MySQL中，XA事务有两种。

内部XA事务
mysql本身的插件式架构导致在其内部需要使用XA事务，此时MySQL即是协调者，也是参与者。例如，不同的存储引擎之间是完全独立的，因此当一个事务涉及两个不同的存储引擎时，就必须使用内部XA事务。需要特别注意的是，如果将二进制日志看做一个独立的“存储引擎”,就不难理解为什么即使是一个存储引擎参与的事务也需要使用XA事务了。在向存储引擎提交数据时，同时需要将提交的信息写入二进制日志，这就是一个分布式事务。

下面的SQL就实现了一个简单的MySQL XA事务：

mysql> XA START 'xatest';
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO mytable (i) VALUES(10);
Query OK, 1 row affected (0.04 sec)

mysql> XA END 'xatest';
Query OK, 0 rows affected (0.00 sec)

mysql> XA PREPARE 'xatest';
Query OK, 0 rows affected (0.00 sec)

mysql> XA COMMIT 'xatest';
Query OK, 0 rows affected (0.00 sec)

外部XA事务
MySQL也可以仅作为一个外部XA的参与者。例如在Java程序中实现一个操作多个异构数据库数据的分布式事务，则分工为：

Transaction Manager
javax.transaction.xa.XAResource, or Java::BitronixTm(aka “Transaction Coordinator”) 也就是程序本身

Resource Managers
MySQL, PostgreSQL, Oracle, Redis, MQueue, MongoDB, etc.(aka “cohorts”) 即各个数据库。也就是说只要是提供了相应接口的数据库产品就可以作为XA的参与者

Two-phase commit
XA一般由两阶段完成，称为two-phase commit(2PC)。
阶段一为准备阶段，即所有的参与者准备执行事务并锁住需要的资源。参与者ready时，向transaction manager汇报自己已经准备好。
阶段二为提交阶段。当transaction manager确认所有参与者都ready后，向所有参与者发送commit命令。
如下图所示：
MySQL分布式事务（XA事务）

XA的性能问题
XA的性能很低。一个数据库的事务和多个数据库间的XA事务性能对比可发现，性能差10倍左右。因此要尽量避免XA事务，例如可以将数据写入本地，用高性能的消息系统分发数据。或使用数据库复制等技术。
只有在这些都无法实现，且性能不是瓶颈时才应该使用XA。

最后是MySQL的XA官方文档：
http://dev.mysql.com/doc/refman/5.7/en/xa.html

在开发中，为了降低单点压力，通常会根据业务情况进行分表分库，将表分布在不同的库中（库可能分布在不同的机器上）。在这种场景下，事务的提交会变得相对复杂，因为多个节点（库）的存在，可能存在部分节点提交失败的情况，即事务的ACID特性需要在各个不同的数据库实例中保证。比如更新db1库的A表时，必须同步更新db2库的B表，两个更新形成一个事务，要么都成功，要么都失败。
那么我们如何利用mysql实现分布式数据库的事务呢？

Mysql 为我们提供了分布式事务解决方案（https://dev.mysql.com/doc/refman/5.7/en/xa.html 这是mysql5.7的文档）
这里先声明两个概念：

资源管理器（resource manager）：用来管理系统资源，是通向事务资源的途径。数据库就是一种资源管理器。资源管理还应该具有管理事务提交或回滚的能力。
事务管理器（transaction manager）：事务管理器是分布式事务的核心管理者。事务管理器与每个资源管理器（resource
manager）进行通信，协调并完成事务的处理。事务的各个分支由唯一命名进行标识。

mysql在执行分布式事务（外部XA）的时候，mysql服务器相当于xa事务资源管理器，与mysql链接的客户端相当于事务管理器。

分布式事务原理：分段式提交

分布式事务通常采用2PC协议，全称Two Phase Commitment Protocol。该协议主要为了解决在分布式数据库场景下，所有节点间数据一致性的问题。分布式事务通过2PC协议将提交分成两个阶段：

prepare；
commit/rollback

阶段一为准备（prepare）阶段。即所有的参与者准备执行事务并锁住需要的资源。参与者ready时，向transaction manager报告已准备就绪。
阶段二为提交阶段（commit）。当transaction manager确认所有参与者都ready后，向所有参与者发送commit命令。
如下图所示：
MySQL分布式事务（XA事务）

事务协调者transaction manager

因为XA 事务是基于两阶段提交协议的，所以需要有一个事务协调者（transaction manager）来保证所有的事务参与者都完成了准备工作(第一阶段)。如果事务协调者（transaction manager）收到所有参与者都准备好的消息，就会通知所有的事务都可以提交了（第二阶段）。MySQL 在这个XA事务中扮演的是参与者的角色，而不是事务协调者（transaction manager）。

Mysql的XA事务分为外部XA和内部XA

外部XA用于跨多MySQL实例的分布式事务，需要应用层作为协调者，通俗的说就是比如我们在PHP中写代码，那么PHP书写的逻辑就是协调者。应用层负责决定提交还是回滚，崩溃时的悬挂事务。MySQL数据库外部XA可以用在分布式数据库代理层，实现对MySQL数据库的分布式事务支持，例如开源的代理工具：网易的DDB，淘宝的TDDL等等。
内部XA事务用于同一实例下跨多引擎事务，由Binlog作为协调者，比如在一个存储引擎提交时，需要将提交信息写入二进制日志，这就是一个分布式内部XA事务，只不过二进制日志的参与者是MySQL本身。Binlog作为内部XA的协调者，在binlog中出现的内部xid，在crash recover时，由binlog负责提交。(这是因为，binlog不进行prepare，只进行commit，因此在binlog中出现的内部xid，一定能够保证其在底层各存储引擎中已经完成prepare)。

MySQL XA事务基本语法

XA {START|BEGIN} xid [JOIN|RESUME] 启动xid事务 (xid 必须是一个唯一值; 不支持[JOIN|RESUME]子句)
XA END xid [SUSPEND [FOR MIGRATE]] 结束xid事务 ( 不支持[SUSPEND [FOR MIGRATE]] 子句)
XA PREPARE xid 准备、预提交xid事务
XA COMMIT xid [ONE PHASE] 提交xid事务
XA ROLLBACK xid 回滚xid事务
XA RECOVER 查看处于PREPARE 阶段的所有事务

PHP调用MYSQL XA事务示例

1、首先要确保mysql开启XA事务支持

SHOW VARIABLES LIKE '%xa%'

如果innodb_support_xa的值是ON就说明mysql已经开启对XA事务的支持了。
如果不是就执行：

SET innodb_support_xa = ON

开启

2、代码如下：

<!--?PHP $dbtest1 = new mysqli("172.20.101.17","public","public","dbtest1")or die("dbtest1 连接失败"); $dbtest2 = new mysqli("172.20.101.18","public","public","dbtest2")or die("dbtest2 连接失败"); //为XA事务指定一个id，xid 必须是一个唯一值。 $xid = uniqid(""); //两个库指定同一个事务id，表明这两个库的操作处于同一事务中 $dbtest1->query("XA START '$xid'");//准备事务1 $dbtest2->query("XA START '$xid'");//准备事务2 try { //$dbtest1 $return = $dbtest1->query("UPDATE member SET name='唐大麦' WHERE id=1") ; if($return == false) {
       throw new Exception("库[email protected]执行update member操作失败！");
    } //$dbtest2 $return = $dbtest2->query("UPDATE memberpoints SET point=point+10 WHERE memberid=1") ; if($return == false) {
       throw new Exception("库[email protected]执行update memberpoints操作失败！");
    } //阶段1：$dbtest1提交准备就绪 $dbtest1->query("XA END '$xid'"); $dbtest1->query("XA PREPARE '$xid'"); //阶段1：$dbtest2提交准备就绪 $dbtest2->query("XA END '$xid'"); $dbtest2->query("XA PREPARE '$xid'"); //阶段2：提交两个库 $dbtest1->query("XA COMMIT '$xid'"); $dbtest2->query("XA COMMIT '$xid'");
} 
catch (Exception $e) { //阶段2：回滚 $dbtest1->query("XA ROLLBACK '$xid'"); $dbtest2->query("XA ROLLBACK '$xid'");
    die($e->getMessage());
} $dbtest1->close(); $dbtest2->close(); ?>

XA的性能问题

XA的性能很低。一个数据库的事务和多个数据库间的XA事务性能对比可发现，性能差10倍左右。因此要尽量避免XA事务，例如可以将数据写入本地，用高性能的消息系统分发数据。或使用数据库复制等技术。只有在这些都无法实现，且性能不是瓶颈时才应该使用XA。