本文主要是介绍MySQL数据库分布式事务XA优缺点与改进方案，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
1 MySQL 外部XA分析
1.1 作用分析
MySQL数据库外部XA可以用在分布式数据库代理层，实现对MySQL数据库的分布式事务支持，例如开源的代理工具：ameoba[4]，网易的DDB，淘宝的TDDL，B2B的Cobar等等。
通过MySQL数据库外部XA，这些工具可以提供跨库的分布式事务。当然，这些工具也就成了外部XA事务的协调者角色。在crash recover时控制悬挂事务是全局commit，或者rollback。
在crash recover之后，外部应用程序可能会遇到以下几种情况：
- 情况一：分布式事务对应的MySQL数据库实例，部分完成prepare，部分未完成prepare。此时直接回滚完成prepare的实例即可。n_prepared < Total Nodes (处于prepare状态的节点数量要小于参与分布式事务的所有节点总数)。
- 情况二：分布式事务对应的MySQL实例，全部完成prepare，未开始进行commit。此时即可提交此事务，也可回滚此事务(根据分布式事务原理，所有节点都完成prepare，应该提交)。n_prepared = Total Nodes。
- 情况三：分布式事务对应的MySQL实例，全部完成prepare，并且部分节点已经完成commit。此时应该提交该事务处于prepare状态的节点。n_prepared < Total Nodes。对比情况三与情况一，仅仅通过prepare节点的数量无法区分，因此应用程序需要在prepare完成之后记录日志(此时，应用程序起着事务协调者(Transcaction Coordinator)的角色，而根据MariaDB WorkLog#132[5]的说法，TC角色是可以进行”middle engine”优化的，不需要prepare过程，所有MySQL节点xa prepare返回之后，应用程序直接写commit标识即可，然后再对每个MySQL节点进行xa commit操作。)，从而用于区分情况一与情况三。
- 情况四：分布式事务对应的MySQL实例，全部完成commit。此时事务已经提交成功，xid不会出现在执行xa recover的任一个节点。不需要特殊处理。
- 情况五：未记录任何prepare日志。那么所有的事务，在各个存储引擎的crash recover时，都会被回滚，不需要外部特殊处理。
1.2 MySQL外部XA不足
通过前面的分析，可知应用程序配合MySQL的XA事务功能，能够较好的支持分布式环境下的事务。但是，这个支持并不完美，根据我的分析，有可能会出现以下几个问题：
l 问题一：主备数据库的数据不一致。
MySQL数据库的主备数据库的同步，通过Binlog的复制完成。而Binlog是MySQL数据库内部XA事务的协调者，并且MySQL数据库为binlog做了优化——binlog不写prepare日志，只写commit日志。
考虑前面提到的情况二，所有的参与节点prepare完成，在进行xa commit前crash。crash recover如果选择commit此事务。由于binlog在prepare阶段未写，因此主库中看来，此分布式事务最终提交了，但是此事务的操作并未写到binlog中，因此也就未能成功复制到备库，从而导致主备库数据不一致的情况出现。
在MySQL 5.5.16版本中做过测试，这个问题实际存在。crash recover之后，对xa recover返回的事务运行xa commit，对应事务提交，但是操作并未写入binlog，因此无法复制到备库。
那么是否回滚所有prepare的事务，就可以避免此问题呢？结论是仍旧不行，不仅不能解决问题一，甚至可能引起问题二。
l 问题二：同一事务，在各参与节点，最终状态不一致(部分提交，部分回滚)。
若回滚所有prepare状态的分布式事务，会产生问题二。考虑情况三(所有节点完成prepare，部分节点完成commit)，该分布式事务对应的节点，部分已经提交，无法回滚，而部分节点回滚。最终导致同一分布式事务，在各参与节点，最终状态不一致。
l 问题三：源码级别问题。MySQL 5.1.49源码对于外部XA事务处理存在bug，在MySQL 5.5.16版本中，此bug已经被fix。经过验证发现，在我已下载的MySQL 5.1.61与之后的所有版本，此bug均已经被fix。
在MySQL 5.1.49中，所有xa recover返回的外部xid，都不能被提交。原因如下：
当运行xa commit ‘xid_name’命令时，MySQL会判断当前xid_name的错误信息，若存在错误信息，那么就在内部将xa commit命令强制转换为xa rollback。xid_name的状态存于xid_cache中，在crash recover阶段，由函数Handler.cc::xarecover_handlerton调用xid_cache_insert(&xid_cache, x)函数完成插入。MySQL 5.1.49在实现xid_cache_insert函数有bug。
…
xs->xa_state=xa_state;
xs->xid.set(xid);
xs->in_thd=0;
xs->rm_error=0;
res=my_hash_insert(&xid_cache, (uchar*)xs);
…
MySQL 5.1.49中，缺少了xs->rm_error =0这一行，未初始化rm_error，导致xa commit时判断出错，无法commit。MySQL 5.5.16已经fix此bug，加上了黑色这一行的初始化，应用程序可以xa commit。
1.3 不足的解决方案
从MySQL数据库外部分布式事务XA不足的分析可以看出，除了实现bug之外，产生其余两个问题的最大原因，还是在于MySQL针对binlog做的 ”middle engine” 优化，binlog的prepare不写日志。在MySQL内部XA事务中，这个优化是可行的，因为Binlog本身的角色就是事务协调者(Transaction Coordinator)，事务协调者可以不进行prepare [5]。
但是对于MySQL外部XA事务，Binlog已经不是事务协调者的角色，其也是一个参与者，或者说是Resource Manager。因此Binlog的prepare日志是不可省略的。
为了解决MySQL数据库外部XA分布式事务crash recover过程中出现的问题，我觉得只能修改binlog模块。使binlog模块在正常运行过程中也区分内部XA事务与外部XA事务。内部XA事务可以仍旧沿用现在的方案；而外部XA分布式事务，需要增加写prepare日志的功能，已经crash recover时处理prepare日志的功能。
2 参考资料
[1] Sergei Golubchik. Distributed Transaction Processing with MySQL XA
[2] http://dev.mysql.com/doc/refman/5.1/en/xa.html
[3] X/Open. Distributed TP: The XA Specification
[4] 陈思儒. Amoeba
[5] MariaDB WorkLog: Transaction coordinator plugin
该文章出自http://jishu.zol.com.cn/4306.html
这篇关于MySQL数据库分布式事务XA优缺点与改进方案的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
