11、ShardingSphere实战:分布式事务

导览

本小节主要介绍ShardingSphere分布式事务的实现原理

  • 两阶段XA事务
  • Saga柔性事务
  • Seata柔性事务

两阶段事务-XA

实现原理

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

[*]nbsp_nbsp

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

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

2.执行物理SQL

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

例如:

XAResource1.start             ## Enlist阶段执行
statement.execute("sql1");    ## 模拟执行一个分片SQL1
statement.execute("sql2");    ## 模拟执行一个分片SQL2
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日志进行重试,来保证提交阶段的操作原子性,和数据强一致性。

例如:

XAResource1.prepare           ## ack: yes
XAResource2.prepare           ## ack: yes
XAResource1.commit
XAResource2.commit
     
XAResource1.prepare           ## ack: yes
XAResource2.prepare           ## ack: no
XAResource1.rollback
XAResource2.rollback

SAGA柔性事务

实现原理

Saga柔性事务的实现类为SagaShardingTransactionMananger, ShardingSphere通过Hook的方式拦截逻辑SQL的解析和路由结果,这样,在分片物理SQL执行前,可以生成逆向SQL,在事务提交阶段再把SQL调用链交给Saga引擎处理。

[*]nbsp_nbsp 1

1.Init(Saga引擎初始化)

包含Saga柔性事务的应用启动时,saga-actuator引擎会根据saga.properties的配置进行初始化的流程。

2.Begin(开启Saga全局事务)

每次开启Saga全局事务时,将会生成本次全局事务的上下文(SagaTransactionContext),事务上下文记录了所有子事务的正向SQL和逆向SQL,作为生成事务调用链的元数据使用。

3.执行物理SQL

在物理SQL执行前,ShardingSphere根据SQL的类型生成逆向SQL,这里是通过Hook的方式拦截Parser的解析结果进行实现。

4.Commit/rollback(提交Saga事务)

提交阶段会生成Saga执行引擎所需的调用链路图,commit操作产生ForwardRecovery(正向SQL补偿)任务,rollback操作产生BackwardRecovery任务(逆向SQL补偿)。

SEATA柔性事务

实现原理

整合Seata AT事务时,需要把TM,RM,TC的模型融入到ShardingSphere 分布式事务的SPI的生态中。在数据库资源上,Seata通过对接DataSource接口,让JDBC操作可以同TC进行RPC通信。同样,ShardingSphere也是面向DataSource接口对用户配置的物理DataSource进行了聚合,因此把物理DataSource二次包装为Seata 的DataSource后,就可以把Seata AT事务融入到ShardingSphere的分片中。

[*]nbsp_nbsp 2

1.Init(Seata引擎初始化)

包含Seata柔性事务的应用启动时,用户配置的数据源会按seata.conf的配置,适配为Seata事务所需的DataSourceProxy,并且注册到RM中。

2.Begin(开启Seata全局事务)

TM控制全局事务的边界,TM通过向TC发送Begin指令,获取全局事务ID,所有分支事务通过此全局事务ID,参与到全局事务中;全局事务ID的上下文存放在当前线程变量中。

3.执行分片物理SQL

处于Seata全局事务中的分片SQL通过RM生成undo快照,并且发送participate指令到TC,加入到全局事务中。ShardingSphere的分片物理SQL是按多线程方式执行,因此整合Seata AT事务时,需要在主线程和子线程间进行全局事务ID的上下文传递,这同服务间的上下文传递思路完全相同。

4.Commit/rollback(提交Seata事务)

提交Seata事务时,TM会向TC发送全局事务的commit和rollback指令,TC根据全局事务ID协调所有分支事务进行commit和rollback。

版权声明:本文不是「本站」原创文章,版权归原作者所有 | 原文地址: