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

简介: 分布式数据库中间件 ShardingSphere 将 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 事务时,需要扩展主线程和子线程的事务上下文传递,这同服务间的上下文传递思路完全相同。

image.png

Quick Start

ShardingSphere 已经实现了 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。

image.png

目录
相关文章
|
11月前
|
消息中间件 存储 Kafka
分布式消息中间件设计与实现
本文深入探讨了消息中间件的核心功能实现与高并发、高可用设计。在生产者设计中,涵盖消息构造、序列化、路由策略及可靠性保障(如ACK机制)。消费者部分分析了拉取/推送模式、分区分配与消息确认机制。同时,Broker作为核心组件,负责消息路由、存储和投递,并通过索引技术实现快速检索。 高并发设计方面,重点讨论了文件存储(顺序写入、分段存储)、日志结构存储及负载均衡策略(如哈希分区、轮询分区)。为确保高可用性,文章详细解析了主从复制、故障转移机制以及同城/异地多活容灾方案。
417 13
|
canal 缓存 NoSQL
Redis缓存与数据库如何保证一致性?同步删除+延时双删+异步监听+多重保障方案
根据对一致性的要求程度,提出多种解决方案:同步删除、同步删除+可靠消息、延时双删、异步监听+可靠消息、多重保障方案
Redis缓存与数据库如何保证一致性?同步删除+延时双删+异步监听+多重保障方案
|
消息中间件 缓存 监控
如何保证缓存和数据库的一致性?
保证缓存和数据库的一致性的做法
|
11月前
|
消息中间件 存储 中间件
分布式消息中间件基础
消息中间件是一种基于异步消息传递的分布式系统通信工具,核心功能包括消息传输、存储、路由与投递,能够实现系统解耦、异步处理和流量削峰。其主要组件包括生产者、消费者、Broker、主题/队列等,支持点对点和发布-订阅两种消息模型。主流中间件如Kafka(高吞吐)、RabbitMQ(灵活路由)、RocketMQ(事务支持)各有特色,适用于不同场景。此外,中间件还涉及多种协议(AMQP、MQTT等)、可靠性传输机制(持久化、确认机制)、顺序性与重复性问题解决以及事务支持(两阶段提交、本地消息表等)。选择中间件需根据业务需求权衡性能、功能和运维成本。
526 6
|
存储 缓存 监控
分布式链路监控系统问题之kywalking在后期维护过程中可能会遇到中间件版本升级的问题如何解决
分布式链路监控系统问题之kywalking在后期维护过程中可能会遇到中间件版本升级的问题如何解决
258 1
|
消息中间件 缓存 NoSQL
缓存与数据库的一致性方案,Redis与Mysql一致性方案,大厂P8的终极方案(图解+秒懂+史上最全)
缓存与数据库的一致性方案,Redis与Mysql一致性方案,大厂P8的终极方案(图解+秒懂+史上最全)
|
存储 SQL 关系型数据库
一篇文章搞懂MySQL的分库分表,从拆分场景、目标评估、拆分方案、不停机迁移、一致性补偿等方面详细阐述MySQL数据库的分库分表方案
MySQL如何进行分库分表、数据迁移?从相关概念、使用场景、拆分方式、分表字段选择、数据一致性校验等角度阐述MySQL数据库的分库分表方案。
2287 15
一篇文章搞懂MySQL的分库分表,从拆分场景、目标评估、拆分方案、不停机迁移、一致性补偿等方面详细阐述MySQL数据库的分库分表方案
|
运维 安全 Cloud Native
核心系统转型问题之分布式数据库和数据访问中间件协作如何解决
核心系统转型问题之分布式数据库和数据访问中间件协作如何解决
|
关系型数据库 Serverless 分布式数据库
揭秘PolarDB Serverless:大促洪峰秒级应对,无感伸缩见证科技魔法!一探云数据库管理的颠覆性革新,强一致性的守护神来了!
【8月更文挑战第13天】在云计算背景下,阿里巴巴的云原生数据库PolarDB Serverless针对弹性伸缩与高性能一致性提供了出色解决方案。本文通过一个电商平台大促活动的真实案例全面测评PolarDB Serverless的表现。面对激增流量,PolarDB Serverless能秒级自动扩展资源,如通过调用`pd_add_reader`快速增加读节点分摊压力;其无感伸缩确保服务平滑运行,不因扩展中断;强一致性模型则保障了数据准确性,即便在高并发写操作下也确保库存等数据的同步一致性。PolarDB Serverless简化了数据库管理,提升了系统效能,是追求高效云数据库管理企业的理想选择。
296 7
|
缓存 NoSQL 数据库
Redis问题之在高并发场景下,保证Redis缓存和数据库的一致性如何解决
Redis问题之在高并发场景下,保证Redis缓存和数据库的一致性如何解决
458 3