分布式事务——实现原理-京东云开发者社区

# 导览

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

* 基于 XA 协议的两阶段事务
* 基于 Seata 的柔性事务

## XA两阶段事务

`XAShardingTransactionManager` 为Apache ShardingSphere 的分布式事务的XA实现类。
它主要负责对多数据源进行管理和适配，并且将相应事务的开启、提交和回滚操作委托给具体的 XA 事务管理器。

![](//img1.jcloudcs.com/developer.jdcloud.com/444cbbe3-db6b-4f1e-a17b-c0b1b98fa8e520210117152014.png)

### 开启全局事务

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

### 执行真实分片SQL

`XAShardingTransactionManager`将数据库连接所对应的 XAResource 注册到当前 XA 事务中之后，事务管理器会在此阶段发送 `XAResource.start` 命令至数据库。
数据库在收到 `XAResource.end` 命令之前的所有 SQL 操作，会被标记为 XA 事务。

例如:

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

示例中的 `sql1` 和 `sql2` 将会被标记为 XA 事务。

## 提交或回滚事务

`XAShardingTransactionManager` 在接收到接入端的提交命令后，会委托实际的 XA 事务管理进行提交动作，
事务管理器将收集到的当前线程中所有注册的 XAResource，并发送 `XAResource.end` 指令，用以标记此 XA 事务边界。
接着会依次发送 `prepare` 指令，收集所有参与 XAResource 投票。
若所有 XAResource 的反馈结果均为正确，则调用 `commit` 指令进行最终提交；
若有任意 XAResource 的反馈结果不正确，则调用 `rollback` 指令进行回滚。
在事务管理器发出提交指令后，任何 XAResource 产生的异常都会通过恢复日志进行重试，以保证提交阶段的操作原子性，和数据强一致性。

例如:

```
XAResource1.prepare           ## ack: yes
XAResource2.prepare           ## ack: yes
XAResource1.commit
XAResource2.commit

XAResource1.prepare           ## ack: yes
XAResource2.prepare           ## ack: no
XAResource1.rollback
XAResource2.rollback
```
## Seata 柔性事务

整合 Seata AT 事务时，需要将 TM，RM 和 TC 的模型融入 Apache ShardingSphere 的分布式事务生态中。
在数据库资源上，Seata 通过对接 `DataSource` 接口，让 JDBC 操作可以同 TC 进行远程通信。
同样，Apache ShardingSphere 也是面向 `DataSource` 接口，对用户配置的数据源进行聚合。
因此，将 `DataSource` 封装为 基于Seata 的 `DataSource` 后，就可以将 Seata AT 事务融入到 Apache ShardingSphere的分片生态中。

![](//img1.jcloudcs.com/developer.jdcloud.com/6ebc6d97-05b8-4bdd-911c-00ff3dec23c820210117152128.png)

### 引擎初始化

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

### 开启全局事务

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

### 执行真实分片SQL

处于 Seata 全局事务中的分片 SQL 通过 RM 生成 undo 快照，并且发送 `participate` 指令至 TC，加入到全局事务中。
由于 Apache ShardingSphere 的分片物理 SQL 采取多线程方式执行，因此整合 Seata AT 事务时，需要在主线程和子线程间进行全局事务 ID 的上下文传递。

### 提交或回滚事务

提交 Seata 事务时，TM 会向 TC 发送全局事务的提交或回滚指令，TC 根据全局事务 ID 协调所有分支事务进行提交或回滚。