导览
本大节次要介绍ShardingSphere分布式事务的实现原理
- 两阶段XA事务
- Seata柔性事务
两阶段事务-XA
- 实现原理
实现原理
ShardingSphere里定义了分布式事务的SPI接口ShardingTransactionManager，Sharding-JDBC和Sharding-Proxy为分布式事务的两个接入端。XAShardingTransactionManager为分布式事务的XA实现类，通过引入sharding-transaction-xa-core依赖，即可退出ShardingSphere 的分布式事务生态中。XAShardingTransactionManager次要负责对actual datasource进行治理和适配，并且将接入端事务的begin/commit/rollback操作委托给具体的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事务。
例如:
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引擎解决。
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的分片中。
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。