[shardingSphere 使用与场景3] shardingSphere分布式事务-XA事务

概念

XA分布式的基本概念

AP：应用程序
TM：事务管理器，XA事务管理器
RM：资源管理器，指的是数据库链接资源

主要解决的问题是多数据源的操作原子性和数据一致性问题

事务提交：

执行分片的SQL语句：

RM是由收到TM（XA事务管理器）的指令来触发，该事务还未提交到数据库。

• 开启事务（XAResource.start）
• 执行所有的SQL语句（XAResource.excute）
• 提交事务 （XAResource.commit）

# 第一個分片
xaResource1.start
xaResource1.excute
xaResource1.end
# 第二個分片
xaResource2.start
xaResource2.excute
xaResource2.end
# ...

两阶段式 prepare 和 commit / rollback：

该阶段是有RM与数据库资源通信，当所有数据源链接都是正常状态的时候，把所有事务提交到不同数据源。

# 正常提交情況：
xaResource1.prepare #ack yes
xaResource2.prepare #ack yes
xaResource1.commit #ack commit
xaResource2.commit #ack commit

# 回滾情況：
xaResource1.prepare #ack yes
xaResource2.prepare #ack no
xaResource1.rollback #ack rollback 
xaResource2.rollback #ack rollback 

在第二段提交的时候，任何XAResource的异常会以恢复日志的形式进行数据库补偿，保证数据库操作原子性和数据一致性。

Resuorce Manager的功能

Resuorce Manager 相当于数据库事物的协调者，参与者是各个数据源。

• 协调所有参与者是否准备好事务提交 prepare
• 协调所有参与者提交事务 commit
• 协调所有参与者回滚事务 rollback

shardingSphere 配置XA事务处理器

使用的是mysql，

@Configuration
@Slf4j
public class XADatabaseConfig {
    @Bean
    public XATransactionManager txManager() {
        XADataSource xaDataSource = new MysqlXADataSource();
        AtomikosTransactionManager atomikosTransactionManager = new AtomikosTransactionManager();
        atomikosTransactionManager.registerRecoveryResource("xaDataSource",xaDataSource);
        return atomikosTransactionManager;
    }
}

XA分布式事务的缺陷

• 性能问题：第二阶段提交时，提交属于同步阻塞状态，且会锁定所有参与者资源（表），参与者多会有性能瓶颈。
• 可靠性问题：Resoure Manager的单点故障，第二阶段commit的时候，出现单点故障，参与者的资源会一直被锁定，占用资源。
• 数据一致性问题：第二阶段提交事务的时候，部分参与者故障（网络或者宕机），会导致数据一致性问题

XA两阶段计较的优化方案 - 三阶段提交

• canCommit 向所有参与者申请资源，准备执行事务操作
• preCommit 执行事务操作，将 undo 和 redo 信息记入事务日志中，不提交事务
• doCommit / abort 提交事务 或者 回滚事务

三阶段提交正常流程：

第1阶段提交：向数据申请资源

第2阶段提交：执行事务操作，undo（回滚日志） 和 redo（重做日志） 信息记入日志中，事务在这阶段并未提交
ps：mysql中还有一个binlog（归档日志）的概念

第3阶段提交：事务提交

异常：终止事务
当在任一阶段有异常情况或接收到ack信息超时，会向数据库发送abort，会滚事务

优点：
优化了阻塞范围，提交事务之后，若出现单点故障，参与者还是会提交事务。
缺点：
doCommit阶段提交abort，若协调者与参与者通信阻断，还是会有数据不一致情况。

总结：XA保证的是强一致性，XA对于大集群分库来说并不是最优策略