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。
————————————————
版权声明：本文为CSDN博主「OnlyQi」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/OnlyQi/article/details/50570439