XA 分布式事务研究

亲爱的编程学习爱好者，如果你点开了这篇文章，说明你对《XA 分布式事务研究》很感兴趣。本篇文章就来给大家详细解析一下，主要介绍一下MySQL、spring、MariaDB、分布式事务，希望所有认真读完的童鞋们，都有实质性的提高。

在开始讲解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

---

https://segmentfault.com/a/1190000005718940
原创文章，版权所有，转载请注明出处

本篇关于《XA 分布式事务研究》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于数据库的相关知识，请关注golang学习网公众号！