ShardingSphere x Seata，一致性更强的分布式数据库中间件

做者：支付宝技术团队

原文连接： http://blog.itpub.net/6990479...

日前，分布式数据库中间件 ShardingSphere 将 Seata 分布式事务能力进行整合，旨在打造一致性更强的分布式数据库中间件。

背景

数据库领域，分布式事务的实现主要包含：两阶段的 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

ShardingSphere 已经实现了 base-seata-raw-jdbc-example，你们能够自行进行尝试：

https://github.com/apache/inc...

操做手册：

一、按照 seata-work-shop 中的步骤，下载并启动 seata server。

https://github.com/seata/seat...

参考 Step6 和 Step7 便可。

二、在每个分片数据库实例中执行 resources/sql/undo_log.sql 脚本，建立 undo_log 表

三、Run YamlConfigurationTransactionExample.java

关于 ShardingSphere

ShardingSphere 是一套开源的分布式数据库中间件解决方案组成的生态圈，它由 Sharding-JDBC、Sharding-Proxy 和 Sharding-Sidecar（计划中）这 3 款相互独立的产品组成，提供标准化的数据分片、分布式事务和数据库治理功能，可适用于如 Java 同构、异构语言、容器、云原生等各类多样化的应用场景。目前，已经拥有超过 8000 的 Star，57 位 Contributors。

关于 Seata

Seata 是阿里巴巴和蚂蚁金服共同开源的分布式事务中间件，融合了双方在分布式事务技术上的积累，并沉淀了新零售、云计算和新金融等场景下丰富的实践经验，以高效而且对业务 0 侵入的方式，解决微服务场景下面临的分布式事务问题。目前，已经拥有超过 9900 的 Star，83 位 Contributors。