XA 分布式事务研究
在开始讲解XA事务前，先引出一个例子来讲解这样比较容易理解XA事务。比如有一笔交易，在交易完成后，接受到到交易成功信息和扣款成功信息，代码如下：
public void savePayOrder(PayOrder payOrder) throws Exception { try { ...//交易前预备逻辑 PayOrderResult payOrderResult= payOrderService.save(payOrder); noticeService.excuteNotice(payOrderResult); } catch (PayOrderExecutionException e) { logger.error(e); sessionCtx.setRollbackOnly(); throw e; } } 在开头首先查询了一下订单相关的业务参数，然后先保存交易信息，然后再更新相关信息，而这个过程需要操作多个表，最后达成交易。注意这里有可能在保存一笔交易的时候，就抛出异常，导致后面无法更新交易的相关信息。
如果顺利的话，这段代码可以保证遵循ACID准则。
这时候如果我们加入一个新需求，比如需要交易成功后发送一条信息通知用户交易成功，并且send()方法里实现所有消息逻辑，则例子改成如下：
public void savePayOrder(PayOrder payOrder) throws Exception { try { ...//交易前预备逻辑 PayOrderResult payOrderResult= payOrderService.save(payOrder); smsService.send(payOrderResult);//发送短信 noticeService.excuteNotice(payOrderResult); } catch (PayOrderExecutionException e) { logger.error(e); sessionCtx.setRollbackOnly(); throw e; } } 这段代码却不会保证ACID准则。如果excuteNotice()方法抛出了PayOrderExecutionException，数据库更改将会回滚，但交易后发出的消息将会通过send()方法被发送到JMS进行相关的订阅或发送。
在非XA环境中，消息队列的插入过程独立于数据库更新操作，ACID准则中的原子性和独立性不能得到保证，从而整体上数据完整性受到损害。我们需要的是，有一种方式能够让消息队列和数据库处于单一事务的控制之下，以至于两个资源能被协调形成单一工作单元。使用X/Open的XA接口，我们便能够做到协调多个资源，保证维持ACID准则。
XA接口详解
XA接口是双向的系统接口，分布式事务是由一个一个应用程序(Application Program)、一个事务管理器（Transaction Manager）以及一个或多个资源管理器（Resource Manager）之间形成通信桥梁。事务管理器控制着JTA事务，管理事务生命周期，并协调资源。
在JTA中，事务管理器抽象为javax.transaction.TransactionManager接口，并通过底层事务服务（即JTS）实现。资源管理器负责控制和管理实际资源(如数据库或JMS队列)。下图说明了事务管理器、资源管理器，以及典型JTA环境中客户端应用之间的关系：
XA分布式事务是由一个或者多个Resource Managerd，一个事务管理器Transaction Manager以及一个应用程序 Application Program组成。
资源管理器：提供访问事务资源的方法，通常一个数据库就是一个资源管理器。
事务管理器：协调参与全局事务中的各个事务。需要和参与全局事务中的资源管理器进行通信。
应用程序：定义事务的边界，指定全局事务中的操作。
XA使用场景
许多事务管理器采用这种单阶段提交的模式，可以避免单一事务资源下的过度开销，以及性能的下降，如果在不适合的场景中引入XA数据库驱动，特别是资源比较局限的情况下使用本地事务模型(Local Transaction Model)。
那究竟什么情况下使用XA事务呢？
一般来说，当你的上下逻辑结构涉及的表或者需要协调的资源(如数据库，以及消息主题或队列等)比较多的时候，建议使用XA。
或者对于该系统在未来对整个结构模块趋于稳定，要求负载、代码扩展等方面稳定性大于性能，则可选择XA。
如果这些资源并不在同一个事务中使用，就没有必要去用XA。
而对于性能要求很高的系统，建议使用 一阶段提交(Best Efforts 1PC)或事务补偿机制。
二阶段提交（The two-phase commit protocol，2PC）
二阶段提交是分布式事务的重要的一个关键点，二阶段提交协议包含了两个阶段：第一阶段（也称准备阶段）和第二阶段（也称提交阶段）。
引用《Java事务设计策略》一图
1. 准备阶段：准备阶段，每个资源管理器都会被轮训一遍，事务管理器给每个资源管理器发送Prepare消息，每个资源管理器要么直接返回失败(如权限验证失败)或异常，要么在本地执行事务等等，但不Commoit，处于Ready状态。
2. 提交阶段：如果事务管理器收到了资源管理器的失败信息(如异常、超时等)，直接给每个资源管理器发送回滚(Rollback)消息；否则，发送提交(Commit)消息；资源管理器根据事务管理器的指令执行Commit或者Rollback操作，释放所有事务处理过程中使用的锁资源。(注意:必须在最后阶段释放锁资源)
可以看出，二阶段提交这么做的就是让前面都完成了准备工作，才能提交整个事务，若中间由某一环节出现问题，则整个事务回滚。
从两阶段提交的工作方式来看，很显然，在提交事务的过程中需要在多个节点之间进行协调，而各节点对锁资源的释放必须等到事务最终提交时，这样，比起一阶段提交，两阶段提交在执行同样的事务时会消耗更多时间。事务执行时间的延长意味着锁资源发生冲突的概率增加，当事务的并发量达到一定数量的时候，就会出现大量事务积压甚至出现死锁，系统性能就会严重下滑。
二阶段提交看起来确实能够提供原子性的操作，但是不幸的事，二阶段提交还是有几个缺点的：
1、同步阻塞问题。执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。
2、单点故障。由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）
3、数据不一致。在二阶段提交的阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据部一致性的现象。
4、二阶段无法解决的问题：协调者再发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。
参考资料
http://www.infoq.com/cn/articles/xa-transactions-handle
http://blog.csdn.net/bluishglc/article/details/7612811
http://www.open-open.com/lib/view/open1429863503010.html
http://hedengcheng.com/?p=136
http://www.hollischuang.com/archives/681
关键字：mysql, mariadb, 分布式事务, spring
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
