分散式数据库中介软件 ShardingSphere 将 Sea t a 分散式事务能力进行整合，旨在打造一致性更强的分散式 数据库中介软件 。
背景
数据库领域，分散式事务的实现主要包含：两阶段的 XA 和 BASE 柔性事务。
XA 事务底层，依赖于具体的数据库厂商对 XA 两阶段提交协议的支援。 通常，XA 协议通过在 Prepare 和 Commit 阶段进行 2PL（2 阶段锁），保证了分散式事务的 ACID，适用于短事务及非云化环境（云化环境下一次 IO 操作大概需要 20ms，两阶段锁会锁住资源长达 40ms， 因此热点行上的事务的 TPS 会降到 25/s 左右，非云化环境通常一次 IO 只需几毫秒，因此锁热 点资料的时间相对较低）。
但在 BASE 柔性事务方面，ShardingSphere 提供的接入分散式事务的 SPI，只适用于对效能要求较高，对一致性要求比较低的业务。
Seata 核心的 AT 模式 适用于构建于支援本地 ACID 事务的关系型数据库。通过整合 Seata ，其 AT 模 式 在一阶段提交+补偿的基础上，通过 TC 的全域性锁实现了 RC 隔离级别的支援，可提高 ShardingSphere 的分散式事务的一致性。
整合方案
整合 Seata AT 事务时，需要把 TM，RM，TC 的模型融入到 ShardingSphere 分散式事务的 SPI 的生态中。 在数据库资源上，Seata 通过对接 DataSource 界面，让 JDBC 操作可以同 TC 进行 RPC 通讯。 同样，ShardingSphere 也是面向 DataSource 界面对使用者配置的物理 DataSource 进行了聚合，因此把物理 DataSource 二次包装为 Seata 的 DataSource 后，就可以把 Seata AT 事务融入到 ShardingSphere 的分片中。
在 Seata 模型中，全域性事务的上下文存放线上程变数中，通过扩充套件服务间的 transport，可以完成执行绪变数的传递，分支事务通过执行绪变数判断是否加入到整个 Seata 全域性事务中。 而 ShardingSphere 的分片执行引擎通常是按多执行绪执行，因此整合 Seata AT 事务时，需要扩充套件主执行绪和子执行绪的事务上下文传递，这同服务间的上下文传递思路完全相同。
Quick Start
ShardingSpher e 已经实现了 base-seata-raw -jdbc-example，大家可以自行进行尝试：
https://github.com/apache/incubator-shardingsphere-example/tree/dev/sharding-jdbc-example/transaction-example/transaction-base-seata-example/transaction-base-seata-raw-jdbc-example
操作手册：
1、按照 seata-work-shop 中的步骤，下载并启动 seata server。
https://github.com/seata/seata-workshop
参考 Step6 和 Step7 即可。
2、在每一个分片数据库例项中执行 resources/sql/undo_log.sql 指令码，建立 undo_log 表
3、 Run YamlConfigurationTransactionExample.java
关于 ShardingSphere
ShardingSphere 是一套开源的分散式数据库中介软件解决方案组成的生态圈，它由 Sharding-JDBC、Sharding-Proxy 和 Sharding-Sidecar（计划中）这 3 款相互独立的产品组成， 提供标准化的资料分片、分散式事务和数据库治理功能，可适用于如 Java 同构、异构语言、容器、云原生等各种多样化的应用场景。 目前， 已经拥有超过 8000 的 Star，57 位 Contributors。
关于 Seata
Seata 是阿里巴巴和蚂蚁金服共同开源的分散式事务中介软件， 融合了 双方在分散式事务技术上的积累，并沉淀了新零售、云端计算和新金融等场景下丰富的实践经验，以高效并且对业务 0 侵入的方式，解决微服务场景下面临的分散式事务问题。目前， 已经拥有超过 9900 的 Star，83 位 Contributors。
end：如果你觉得本文对你有帮助的话，记得关注点赞转发，你的支援就是我更新动力。
