MySQL分布式XA事务

XA–eXtended Architecture 在事务中意为分布式事务 
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命令。 
如下图所示： 

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

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