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。

目录
相关文章
|
消息中间件 存储 Kafka
分布式消息中间件设计与实现
本文深入探讨了消息中间件的核心功能实现与高并发、高可用设计。在生产者设计中,涵盖消息构造、序列化、路由策略及可靠性保障(如ACK机制)。消费者部分分析了拉取/推送模式、分区分配与消息确认机制。同时,Broker作为核心组件,负责消息路由、存储和投递,并通过索引技术实现快速检索。 高并发设计方面,重点讨论了文件存储(顺序写入、分段存储)、日志结构存储及负载均衡策略(如哈希分区、轮询分区)。为确保高可用性,文章详细解析了主从复制、故障转移机制以及同城/异地多活容灾方案。
501 13
|
9月前
|
数据采集 监控 NoSQL
优化分布式采集的数据同步:一致性、去重与冲突解决的那些坑与招
本文讲述了作者在房地产数据采集项目中遇到的分布式数据同步问题,通过实施一致性、去重和冲突解决的“三板斧”策略,成功解决了数据重复和同步延迟问题,提高了系统稳定性。核心在于时间戳哈希保证一致性,URL归一化和布隆过滤器确保去重,分布式锁解决写入冲突。
485 2
 优化分布式采集的数据同步:一致性、去重与冲突解决的那些坑与招
|
9月前
|
消息中间件 运维 监控
《聊聊分布式》BASE理论 分布式系统可用性与一致性的工程平衡艺术
BASE理论是对CAP定理中可用性与分区容错性的实践延伸,通过“基本可用、软状态、最终一致性”三大核心,解决分布式系统中ACID模型的性能瓶颈。它以业务为导向,在保证系统高可用的同时,合理放宽强一致性要求,并借助补偿机制、消息队列等技术实现数据最终一致,广泛应用于电商、社交、外卖等大规模互联网场景。
|
监控 算法 关系型数据库
分布式事务难题终结:Seata+DRDS全局事务一致性架构设计
在分布式系统中,CAP定理限制了可用性、一致性与分区容错的三者兼得,尤其在网络分区时需做出取舍。为应对这一挑战,最终一致性方案成为常见选择。以电商订单系统为例,微服务化后,原本的本地事务演变为跨数据库的分布式事务,暴露出全局锁失效、事务边界模糊及协议差异等问题。本文深入探讨了基于 Seata 与 DRDS 的分布式事务解决方案,涵盖 AT 模式实践、分片策略优化、典型问题处理、性能调优及高级特性实现,结合实际业务场景提供可落地的技术路径与架构设计原则。通过压测验证,该方案在事务延迟、TPS 及失败率等方面均取得显著优化效果。
633 61
|
canal 缓存 NoSQL
Redis缓存与数据库如何保证一致性?同步删除+延时双删+异步监听+多重保障方案
根据对一致性的要求程度,提出多种解决方案:同步删除、同步删除+可靠消息、延时双删、异步监听+可靠消息、多重保障方案
Redis缓存与数据库如何保证一致性?同步删除+延时双删+异步监听+多重保障方案
|
消息中间件 缓存 监控
如何保证缓存和数据库的一致性?
保证缓存和数据库的一致性的做法
|
消息中间件 存储 中间件
分布式消息中间件基础
消息中间件是一种基于异步消息传递的分布式系统通信工具,核心功能包括消息传输、存储、路由与投递,能够实现系统解耦、异步处理和流量削峰。其主要组件包括生产者、消费者、Broker、主题/队列等,支持点对点和发布-订阅两种消息模型。主流中间件如Kafka(高吞吐)、RabbitMQ(灵活路由)、RocketMQ(事务支持)各有特色,适用于不同场景。此外,中间件还涉及多种协议(AMQP、MQTT等)、可靠性传输机制(持久化、确认机制)、顺序性与重复性问题解决以及事务支持(两阶段提交、本地消息表等)。选择中间件需根据业务需求权衡性能、功能和运维成本。
656 6
|
中间件 关系型数据库 数据库
docker快速部署OS web中间件 数据库 编程应用
通过Docker,可以轻松地部署操作系统、Web中间件、数据库和编程应用。本文详细介绍了使用Docker部署这些组件的基本步骤和命令,展示了如何通过Docker Compose编排多容器应用。希望本文能帮助开发者更高效地使用Docker进行应用部署和管理。
467 19
|
消息中间件 缓存 NoSQL
缓存与数据库的一致性方案,Redis与Mysql一致性方案,大厂P8的终极方案(图解+秒懂+史上最全)
缓存与数据库的一致性方案,Redis与Mysql一致性方案,大厂P8的终极方案(图解+秒懂+史上最全)
|
存储 SQL 关系型数据库
一篇文章搞懂MySQL的分库分表,从拆分场景、目标评估、拆分方案、不停机迁移、一致性补偿等方面详细阐述MySQL数据库的分库分表方案
MySQL如何进行分库分表、数据迁移?从相关概念、使用场景、拆分方式、分表字段选择、数据一致性校验等角度阐述MySQL数据库的分库分表方案。
2464 15
一篇文章搞懂MySQL的分库分表,从拆分场景、目标评估、拆分方案、不停机迁移、一致性补偿等方面详细阐述MySQL数据库的分库分表方案