
Narayana-XA事务恢复(5)
说事务恢复流程之前,我们来讨论下,会啥会出现事务恢复?XA二阶段提交协议不是强一致性的吗?要解答这个问题,我们就要来看看XA二阶段协议有什么问题?
问题一 :单点故障
由于协调者的重要性,一旦协调者TM发生故障。参与者RM会一直阻塞下去。尤其在第二阶段,协调者发生故障,那么所有的参与者还都处于锁定事务资源的状态中,而无法继续完成事务操作。(如果是协调者挂掉,可以重新选举一个协调者,但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题)
问题二 :数据不一致
数据不一致。在二阶段提交的阶段二中,当协调者向参与者发送commit请求之后,发生了局部网络异常或者在发送commit请求过程中协调者发生了故障,这会导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据不一致性的现象。
如何解决?
解决的方案简单,就是我们在事务的操作的每一步,我们都需要对事务状态的日志进行人为的记录,我们可以把日志记录存储在我们想存储的地方,可以是本地存储,也可以中心化的存储。Narayana的开源版本,提供了file
,db
2种方式存储,file只能支持单机环境,而db是可以支持集群环境。
Narayana 事务恢复流程。
Narayana使用了单线程轮询RM,执行XA recovery语句,来判断是否有需要恢复的语句。
具体的代码 com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run()
方法。以下是代码:
- 别被吓到了,我们重点来关注
doWorkInternal();
我们来看看这个方法。
- 首先会获取框架所有的
RecoveryModule
类,然后一个一个执行,我们先来看看这个类:
RecoveryModule的实现类有 XARecoveryModule ,AtomicActionRecoveryModule,SubordinateAtomicActionRecoveryModule,CommitMarkableResourceRecordRecoveryModule。等4个实现类。
恢复执行第一个阶段
- XARecoveryModule :
它的作用就是执行XA recovery 命令从RM,获取 Xid数组。然后缓存起来。核心代码为:
- AtomicActionRecoveryModule:
从事务日志里面获取需要恢复的UID,具体代码为:
恢复执行第二个阶段
首先执行的代码为 :
- AtomicActionRecoveryModule: 进入
processTransactionsStatus()
,最终会调用到com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2()
。我们来看看这个方法。
- 判断事务状态,如果是需要commit阶段的状态,进行commit,否则进行rollback
- XARecoveryModule : 尝试在进行恢复。核心代码为
文章到此,已经写的很长很多了,我们分析了ShardingSphere对于XA方案,提供了一套SPI解决方案,对Atomikos进行了整合,也分析了Atomikos初始化流程,开始事务流程,获取连接流程,提交事务流程,回滚事务流程,事务恢复流程。
希望对大家理解XA的原理有所帮助。
关于我们
Apache ShardingSphere是一套开源的分布式数据库中间件解决方案组成的生态圈,它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar(规划中)这3款相互独立的产品组成。他们均提供标准化的数据分片、分布式事务、数据迁移、数据库治理和管控界面功能,可适用于如Java同构、异构语言、容器、云原生等各种多样化的应用场景。
Apache ShardingSphere不断践行Apache Way,致力于打造充满活力、规范、互助的社区!开源路上,我们欢迎你的加入。
项目地址:
https://github.com/apache/shardingsphere
更多信息请浏览官网:
https://shardingsphere.apache.org/
作者介绍:肖宇,Apache ShardingSphere Committer,开源hmily分布式事务框架作者,开源soul网关作者,热爱开源,追求写优雅代码。目前就职于京东数科,参与ShardingSphere的开源建设,以及分布式数据库的研发工作。
