ShardingSphere x Seata,一致性更强的分散式资料库中间件
日前,分散式资料库中间件 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 事务时,需要扩展主线程和子线程的事务上下文传递,这同服务间的上下文传递思路完全相同。