摘要：下图说明了事务管理器资源管理器，以及典型环境中客户端应用之间的关系分布式事务是由一个或者多个，一个事务管理器以及一个应用程序组成。
在开始讲解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接口详解在非XA环境中，消息队列的插入过程独立于数据库更新操作，ACID准则中的原子性和独立性不能得到保证，从而整体上数据完整性受到损害。我们需要的是，有一种方式能够让消息队列和数据库处于单一事务的控制之下，以至于两个资源能被协调形成单一工作单元。使用X/Open的XA接口，我们便能够做到协调多个资源，保证维持ACID准则。
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
原创文章，版权所有，转载请注明出处
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/48645.html
摘要：如上图所示，的实际上是已中间件的形式放在应用层，不用依赖数据库对协议的支持，完全剥离了分布式事务方案对数据库在协议支持上的要求。 微信公众号「后端进阶」，专注后端技术分享：Java、Golang、WEB框架、分布式中间件、服务治理等等。 在微服务架构体系下，我们可以按照业务模块分层设计，单独部署，减轻了服务部署压力，也解耦了业务的耦合，避免了应用逐渐变成一个庞然怪物，从而可以轻松扩展，...
摘要：使用事务管理器是支持的一个流行的开源事务管理器实现，你可以使用启动器向项目添加适当的依赖项，与和一样，将自动配置并对进行后处理，以确保启动和关闭顺序是正确的。 37. 用JTA分布式事务 通过使用Atomikos或Bitronix嵌入式事务管理器，Spring Boot支持跨多个XA资源的分布式JTA事务，在部署到合适的Java EE应用服务器时也支持JTA事务。 当检测到JTA环境时...
摘要：中大致分为两部分事务管理器和本地资源管理器。具体实现分布式事务框架的核心功能是对本地事务的协调控制，框架本身并不创建事务，只是对本地事务做协调控制。 Spring Cloud 分布式事务管理 在微服务如火如荼的情况下，越来越多的项目开始尝试改造成微服务架构，微服务即带来了项目开发的方便性，又提高了运维难度以及网络不可靠的概率. @[toc]在说微服务的优缺点时，有对比才会更加明显，首先...
摘要：阿里云分布式关系型数据库服务，于月号发布了版本，这是一个年度大更新。无需额外付费或者开通，不依赖第三方组件，即可执行分布式事务。确保分布式执行代价的最小化。柔性事务提供的最终一致方式执行的分布式事务称为柔性事务。 摘要： DRDS （阿里云分布式关系型数据库服务，https://www.aliyun.com/produc...）于 4 月 30 号发布了 5.3 版本，年度更新，具备众...
阅读 1065·2021-10-11 10:57
阅读 1752·2021-09-02 15:15
阅读 1393·2019-08-30 15:56
阅读 992·2019-08-30 15:55
阅读 1031·2019-08-30 15:44
阅读 871·2019-08-29 12:20
阅读 1166·2019-08-29 11:12
阅读 954·2019-08-28 18:29
