在开始讲解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消息之后宕机,而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者,这条事务的状态也是不确定的,没人知道事务是否被已经提交。