博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
XA 分布式事务研究
阅读量:5742 次
发布时间:2019-06-18

本文共 3323 字,大约阅读时间需要 11 分钟。

  hot3.png

在开始讲解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环境中客户端应用之间的关系:

bVy1PT

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)

二阶段提交是分布式事务的重要的一个关键点,二阶段提交协议包含了两个阶段:第一阶段(也称准备阶段)和第二阶段(也称提交阶段)。

bVx9Gx引用《Java事务设计策略》一图

1. 准备阶段:准备阶段,每个资源管理器都会被轮训一遍,事务管理器给每个资源管理器发送Prepare消息,每个资源管理器要么直接返回失败(如权限验证失败)或异常,要么在本地执行事务等等,但不Commoit,处于Ready状态。

2. 提交阶段:如果事务管理器收到了资源管理器的失败信息(如异常、超时等),直接给每个资源管理器发送回滚(Rollback)消息;否则,发送提交(Commit)消息;资源管理器根据事务管理器的指令执行Commit或者Rollback操作,释放所有事务处理过程中使用的锁资源。(注意:必须在最后阶段释放锁资源)

可以看出,二阶段提交这么做的就是让前面都完成了准备工作,才能提交整个事务,若中间由某一环节出现问题,则整个事务回滚。

从两阶段提交的工作方式来看,很显然,在提交事务的过程中需要在多个节点之间进行协调,而各节点对锁资源的释放必须等到事务最终提交时,这样,比起一阶段提交,两阶段提交在执行同样的事务时会消耗更多时间。事务执行时间的延长意味着锁资源发生冲突的概率增加,当事务的并发量达到一定数量的时候,就会出现大量事务积压甚至出现死锁,系统性能就会严重下滑。

二阶段提交看起来确实能够提供原子性的操作,但是不幸的事,二阶段提交还是有几个缺点的:

1、同步阻塞问题。执行过程中,所有参与节点都是事务阻塞型的。当参与者占有公共资源时,其他第三方节点访问公共资源不得不处于阻塞状态。

2、单点故障。由于协调者的重要性,一旦协调者发生故障。参与者会一直阻塞下去。尤其在第二阶段,协调者发生故障,那么所有的参与者还都处于锁定事务资源的状态中,而无法继续完成事务操作。(如果是协调者挂掉,可以重新选举一个协调者,但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题)

3、数据不一致。在二阶段提交的阶段二中,当协调者向参与者发送commit请求之后,发生了局部网络异常或者在发送commit请求过程中协调者发生了故障,这回导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据部一致性的现象。

4、二阶段无法解决的问题:协调者再发出commit消息之后宕机,而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者,这条事务的状态也是不确定的,没人知道事务是否被已经提交。

转载于:https://my.oschina.net/cccyb/blog/844644

你可能感兴趣的文章
C++与MySQL的冲突
查看>>
siki学习之观察者模式笔记
查看>>
单元测试
查看>>
spring.net 继承
查看>>
ES6:模块简单解释
查看>>
JavaScript indexOf() 方法
查看>>
用Bootstrap写一份简历
查看>>
ZJU PAT 1023
查看>>
WMI远程访问问题解决方法
查看>>
从零开始学习IOS,(UILabel控件)详细使用和特殊效果
查看>>
Android开发历程_15(AppWidget的使用)
查看>>
阿花宝宝 Java 笔记 之 初识java
查看>>
7、设计模式-创建型模式-建造者模式
查看>>
Cesium官方教程11--建模人员必读
查看>>
我国古代的勾股定理
查看>>
Linux下的C编程实战
查看>>
[32期] html中部分代码与英语单词关系
查看>>
PHP安装环境,服务器不支持curl_exec的解决办法
查看>>
jQuery|元素遍历
查看>>
RedHat 6 安装配置Apache 2.2
查看>>