两阶段事务-XA

实现原理

ShardingSphere里定义了分布式事务的SPI接口ShardingTransactionManager,Sharding-JDBC和Sharding-Proxy为分布式事务的两个接入端。XAShardingTransactionManager为分布式事务的XA实现类,通过引入sharding-transaction-xa-core依赖,即可加入ShardingSphere 的分布式事务生态中。XAShardingTransactionManager主要负责对actual datasource进行管理和适配,并且将接入端事务的begin/commit/rollback操作委托给具体的XA事务管理器。

XA事务实现原理

1.Begin(开启XA全局事务)

通常收到接入端的set autoCommit=0时,XAShardingTransactionManager会调用具体的XA事务管理器开启XA的全局事务,通常以XID的形式进行标记。

2.执行物理SQL

ShardingSphere进行解析/优化/路由后,会生成逻辑SQL的分片SQLUnit,执行引擎为每个物理SQL创建连接的同时,物理连接所对应的XAResource也会被注册到当前XA事务中,事务管理器会在此阶段发送XAResource.start命令给数据库,数据库在收到XAResource.end命令之前的所有SQL操作,会被标记为XA事务。

例如:

  1. XAResource1.start ## Enlist阶段执行
  2. statement.execute("sql1"); ## 模拟执行一个分片SQL1
  3. statement.execute("sql2"); ## 模拟执行一个分片SQL2
  4. XAResource1.end ## 提交阶段执行

这里sql1和sql2将会被标记为XA事务。

3.Commit/rollback(提交XA事务)

XAShardingTransactionManager收到接入端的提交命令后,会委托实际的XA事务管理进行提交动作,这时事务管理器会收集当前线程里所有注册的XAResource,首先发送XAResource.end指令,用以标记此XA事务的边界。 接着会依次发送prepare指令,收集所有参与XAResource投票,如果所有XAResource的反馈结果都是OK,则会再次调用commit指令进行最终提交,如果有一个XAResource的反馈结果为No,则会调用rollback指令进行回滚。 在事务管理器发出提交指令后,任何XAResource产生的异常都会通过recovery日志进行重试,来保证提交阶段的操作原子性,和数据强一致性。

例如:

  1. XAResource1.prepare ## ack: yes
  2. XAResource2.prepare ## ack: yes
  3. XAResource1.commit
  4. XAResource2.commit
  5. XAResource1.prepare ## ack: yes
  6. XAResource2.prepare ## ack: no
  7. XAResource1.rollback
  8. XAResource2.rollback