XA分布式事务全面理解

XA协议：

是两阶段的实时分布式事务解决方案：

• 第一阶段：prepare，每个RM都要prepare返回给TM表示准备就绪。
• 第二阶段：TM通过判断决定全部commit或者全部rollback。

第二阶段判断依据是，第一阶段prepare返回的状态，如果都成功，则全部commit；有失败，则全部rollback。

架构图：

协议具体过程：

	1. xa start <xid>     //表示xa协议开始
	2. 进行一些事务操作DML
	3. xa end <xid>     //xid是当前的分布式事务的唯一编号。当前DML操作解释
	4. xa prepare <xid>   //xa 第一阶段，此阶段有返回值，表示该RM的prepare阶段成功与否
	5. TM 接收所有prepare结果，判断全部成功，全部commit；否则，全部失败。

解决什么问题？

是分布式环境下的事务一致性解决方案之一。也是实时分布式事务的解决，但其效率不高。
还有其他的分布式事务解决方案，例如：TCC补偿型事务、最终一致性MQ分布式事务。

XA协议实现：

XA只是一个协议，具体的实现可以有很多

XA协议在mysql中的使用：

在mysql中，涉及两种XA协议的使用：

• mysql内部：因为mysql的插件式架构，
  1. mysql本身作为协调者，多个的存储引擎共同的数据一致性；
  2. mysql本身作为协调者，二进制日志和存储引擎的事务日志的数据一致性
• mysql外部：
  mysql作为RM参与者，而第三方组件作为TM对多个mysql的数据一致性进行分布式事务管理。

XA协议的缺陷？

1、网络通信的复杂性和延迟
2、参与者本身的失败，导致client、TM、RM整个服务的等待。
3、打破了批量提交。XA导致了二进制日志和事务日志的多次fsync() 磁盘化的调用。

基于以上三点的缺陷，它的整体性能是比较低的。故，在实际应用中，多在内网而非广域网中使用。

4、同时，XA的两阶段认为，只要第一阶段prepare全部成功，第二阶段commit就不会失败。但实际场景中，如果分布式事务包含多个库，是有比较少的可能造成只有部分库成功的，这个问题直到mysql 5.7才得到解决。且解决方案还只是mysql端的一个解决方案，一些TM组件并未支持。

mysql如何解决第二阶段失败的？

在mysql 5.7以后将prepare的xa操作加入到了binlog二进制日志中。可以进行mysql检测出处于prepare阶段的xa事务，继而继续存储引擎层面的提交。