事件驱动的分布式事务架构设计

简介: 在这个架构中,已经没有中心化事务协调者 TC Server,用户只需关心自身应用的高可用,如应用多副本部署,hptx 和 dbpack 会通过 etcd 选主,只有选为 master 的副本才能 watch 自身产生的分支事务数据去做提交、回滚,避免了提交、回滚逻辑重复执行的问题。集成 hptx,只需要依赖相应的 sdk,而不需要部署额外的 TC Server。全新的、云原生的、事件驱动架构,更加简洁,性能更强。采用 hptx 的应用事务协调性能比 Seata-Golang 提升 1 倍,通过 dbpack 以 mesh 方式协调分布式事务性能比 seata-golang 提升了百分之 50。

一、什么是事件驱动架构

事件驱动架构是一种促进生产的软件架构范式。事件驱动架构在用微服务构建的现代应用中非常普遍,它用事件来触发、解耦服务之间的通信。事件可以是状态的变更,比如将商品放入购物车;也可以是某种标识,比如订单的发货通知。

eda.drawio.png

在传统的软件架构中,应用逻辑是通过请求、过程驱动的。一个请求执行一段逻辑同步返回一个响应,在业务逻辑中,将要执行的代码按照过程顺序进行编排。而事件驱动架构中,事件消费者会以异步的方式处理事件生产者产生的事件,原来过程当中的逻辑交给事件消费者去处理,解开服务之间的耦合,使应用的逻辑聚焦,应用的职责单一,代码更加简洁,也能提升系统的响应能力。

二、分布式事务的事件驱动架构

在 2020 年,本文作者开源了 Go 语言的分布式事务框架 Seata-Golang。Seata-Golang 实现 AT 模式和 TCC 模式,这两种模式都是过程驱动。到了 2022 年,随着对云原生技术的理解深入,从 Kubernetes Control-Loop 思想中获得灵感,全新设计了高性能、无侵入、事件驱动的 Go 语言分布式事务框架 hptx,以及支持跨语言分布式事务、读写分离、分库分表的 Mesh 方案 DBPack。这两款产品都能解决分布式事务问题,前者只支持 Go 语言,后者支持任意编程语言。他们采用了相同的事件驱动架构。下面进行详细的说明。

过程驱动

eda-Page-2.drawio.png

在 Seata 的设计中,事务发起者发起全局提交后,首先会判断该事务是否允许异步提交,如果允许,则直接返回提交成功,然后由 AsyncCommittingSessionManager 来异步地通知每个分支事务提交,AT 事务默认允许异步提交。如果不允许异步提交,事务协调者会依次通知全局事务参与者即每个分支事务提交,所有分支事务提交成功后,同步返回给事务发起者全局事务提交的结果,如上图。事务协调者通知事务参与者提交过程中发生了异常,会将该全局事务标记为 CommitRetrying 状态,将会有一个 RetryCommittingSessionManager 定时从持久存储中捞取标记的全局事务重试提交。

全局回滚的过程与上图类似,全局回滚时,AT 模式和 TCC 模式都是同步执行,依次通知每个分支事务回滚,然后再响应回滚结果给事务发起者。如果回滚失败,则将全局事务标记为 RollbackRetrying,由 RetryRollbackingSessionManager 定时捞取标记的全局事务数据重试回滚。

image-20220509114425335.png

Seata-Golang 的用户经常会问一个问题,事务协调者 TC Server 怎么做高可用?Seata 包括 Seata-Golang 默认推荐使用 Mysql 数据库作为 TC 状态数据的持久化存储。TC Server 本身则是无状态应用,可以部署多个副本,但这里就存在一个问题:多个对等副本里的 AsyncCommittingSessionManagerRetryCommittingSessionManagerRetryRollbackingSessionManager 都会从数据库去捞取对应的数据执行,会导致事务的提交、回滚重复执行,虽然 AT 模式天然做到幂等,TCC 模式由用户保证幂等,但总是存在一定的资源浪费,且不够优雅。

事件驱动

eda-Page-3.drawio.png

上图展示了 hptx 和 dbpack 的事务协调逻辑,事务发起者 AggregationSvc 发起全局事务提交、回滚,仅仅是修改 ETCD 中的数据状态,然后立即返回。订单服务和商品服务使用前缀 bs/${appid} Watch 存储在 ETCD 中的分支事务数据,当分支事务的数据发生过变更后,ETCD 马上推送一个变更事件给相应服务,订单服务和商品服务收到变更事件后,将数据加入 workqueue 去执行提交或回滚的逻辑。AggregationSvc 提交、回滚时不会调用 OrderSvc、ProductSvc 的接口,整个过程通过 ETCD 解耦后异步执行。

distributed-transaction.gif

事务分支提交或者回滚失败后,会重新进入到 workqueue 当中继续消费,直至提交、回滚成功,或回滚超时(AT 模式回滚操作涉及到全局锁的释放,需要设置超时时间,即 retry_dead_threshold)。

image-20220530171829086.png

在这个架构中,已经没有中心化事务协调者 TC Server,用户只需要关心自身应用的高可用,如果应用多副本部署,hptx 和 dbpack 会通过 etcd 选主,只有选为 master 的副本才能 watch 自身产生的分支事务数据去做提交、回滚,避免了提交、回滚逻辑重复执行的问题。集成 hptx,只需要依赖相应的 sdk,而不需要部署额外的 TC Server,但状态数据的存储由原来的 Mysql 换成了 ETCD。

三、新架构带来的好处

全新的、云原生的、事件驱动架构,更加简洁,性能更强。采用 hptx 的应用事务协调性能比 Seata-Golang 提升 1 倍,通过 dbpack 以 mesh 方式协调分布式事务性能比 seata-golang 提升了百分之 50。下面是一些测试数据:

环境 性能
seata-golang 2018 款 Mac book pro 每秒 18.54 笔事务
hptx 2018 款 Mac book pro 每秒 38.89 笔事务
dbpack 2018 款 Mac book pro 每秒 28.09 笔事务
hptx 阿里云 ecs ecs.sn1ne.xlarge (4 核 8G) 每秒 35.15 笔事务

hptx 是当前性能最强的云原生、无侵入分布式事务解决方案,选择其他内存型存储组件理论上可以得到更高的性能,但综合可靠性和性能,ETCD 是目前最好的选择。

四、结语

经过持续地在分布式事务领域的研究总结,使分布式事务框架不断进化,从最初的兼容 java seata 的 seata-golang v1 版本,到云原生的、无侵入的、基于 grpc 的 seata-golang v2 版本,到基于 ETCD watch 机制的、事件驱动的 hptx,再到跨语言的 dbpack,分布式事务一直在进化,能力也在进一步增强。

欢迎感兴趣的同学加入我们社区一起交流讨论分布式事务问题、DBMesh 问题,进群或参与社区建设请添加微信:scottlewis。

链接

Hptx 项目地址:https://github.com/cectc/hptx

Hptx samples:https://github.com/cectc/hptx-samples

DBPack 项目地址:https://github.com/cectc/dbpack

DBPack 文档:https://cectc.github.io/dbpack-doc/#/

DBPack-samples:https://github.com/cectc/dbpack-samples

目录
相关文章
|
9天前
|
存储 Prometheus Cloud Native
分布式系统架构6:链路追踪
本文深入探讨了分布式系统中的链路追踪理论,涵盖追踪与跨度的概念、追踪系统的模块划分及数据收集的三种方式。链路追踪旨在解决复杂分布式系统中请求流转路径不清晰的问题,帮助快速定位故障和性能瓶颈。文中介绍了基于日志、服务探针和边车代理的数据收集方法,并简述了OpenTracing、OpenCensus和OpenTelemetry等链路追踪协议的发展历程及其特点。通过理解这些概念,可以更好地掌握开源链路追踪框架的使用。
63 41
|
19天前
|
设计模式 存储 算法
分布式系统架构5:限流设计模式
本文是小卷关于分布式系统架构学习的第5篇,重点介绍限流器及4种常见的限流设计模式:流量计数器、滑动窗口、漏桶和令牌桶。限流旨在保护系统免受超额流量冲击,确保资源合理分配。流量计数器简单但存在边界问题;滑动窗口更精细地控制流量;漏桶平滑流量但配置复杂;令牌桶允许突发流量。此外,还简要介绍了分布式限流的概念及实现方式,强调了限流的代价与收益权衡。
60 11
|
21天前
|
设计模式 监控 Java
分布式系统架构4:容错设计模式
这是小卷对分布式系统架构学习的第4篇文章,重点介绍了三种常见的容错设计模式:断路器模式、舱壁隔离模式和重试模式。断路器模式防止服务故障蔓延,舱壁隔离模式通过资源隔离避免全局影响,重试模式提升短期故障下的调用成功率。文章还对比了这些模式的优缺点及适用场景,并解释了服务熔断与服务降级的区别。尽管技术文章阅读量不高,但小卷坚持每日更新以促进个人成长。
45 11
|
23天前
|
消息中间件 存储 安全
分布式系统架构3:服务容错
分布式系统因其复杂性,故障几乎是必然的。那么如何让系统在不可避免的故障中依然保持稳定?本文详细介绍了分布式架构中7种核心的服务容错策略,包括故障转移、快速失败、安全失败等,以及它们在实际业务场景中的应用。无论是支付场景的快速失败,还是日志采集的安全失败,每种策略都有自己的适用领域和优缺点。此外,文章还为技术面试提供了解题思路,助你在关键时刻脱颖而出。掌握这些策略,不仅能提升系统健壮性,还能让你的技术栈更上一层楼!快来深入学习,走向架构师之路吧!
57 11
|
25天前
|
自然语言处理 负载均衡 Kubernetes
分布式系统架构2:服务发现
服务发现是分布式系统中服务实例动态注册和发现机制,确保服务间通信。主要由注册中心和服务消费者组成,支持客户端和服务端两种发现模式。注册中心需具备高可用性,常用框架有Eureka、Zookeeper、Consul等。服务注册方式包括主动注册和被动注册,核心流程涵盖服务注册、心跳检测、服务发现、服务调用和注销。
67 12
|
1月前
|
消息中间件 架构师 数据库
本地消息表事务:10Wqps 高并发分布式事务的 终极方案,大厂架构师的 必备方案
45岁资深架构师尼恩分享了一篇关于分布式事务的文章,详细解析了如何在10Wqps高并发场景下实现分布式事务。文章从传统单体架构到微服务架构下分布式事务的需求背景出发,介绍了Seata这一开源分布式事务解决方案及其AT和TCC两种模式。随后,文章深入探讨了经典ebay本地消息表方案,以及如何使用RocketMQ消息队列替代数据库表来提高性能和可靠性。尼恩还分享了如何结合延迟消息进行事务数据的定时对账,确保最终一致性。最后,尼恩强调了高端面试中需要准备“高大上”的答案,并提供了多个技术领域的深度学习资料,帮助读者提升技术水平,顺利通过面试。
本地消息表事务:10Wqps 高并发分布式事务的 终极方案,大厂架构师的 必备方案
|
1月前
|
存储 算法 安全
分布式系统架构1:共识算法Paxos
本文介绍了分布式系统中实现数据一致性的重要算法——Paxos及其改进版Multi Paxos。Paxos算法由Leslie Lamport提出,旨在解决分布式环境下的共识问题,通过提案节点、决策节点和记录节点的协作,确保数据在多台机器间的一致性和可用性。Multi Paxos通过引入主节点选举机制,优化了基本Paxos的效率,减少了网络通信次数,提高了系统的性能和可靠性。文中还简要讨论了数据复制的安全性和一致性保障措施。
46 1
|
2月前
|
人工智能 运维 算法
引领企业未来数字基础架构浪潮,中国铁塔探索超大规模分布式算力
引领企业未来数字基础架构浪潮,中国铁塔探索超大规模分布式算力
|
2月前
|
NoSQL Java 数据处理
基于Redis海量数据场景分布式ID架构实践
【11月更文挑战第30天】在现代分布式系统中,生成全局唯一的ID是一个常见且重要的需求。在微服务架构中,各个服务可能需要生成唯一标识符,如用户ID、订单ID等。传统的自增ID已经无法满足在集群环境下保持唯一性的要求,而分布式ID解决方案能够确保即使在多个实例间也能生成全局唯一的标识符。本文将深入探讨如何利用Redis实现分布式ID生成,并通过Java语言展示多个示例,同时分析每个实践方案的优缺点。
76 8
|
3月前
|
运维 供应链 安全
SD-WAN分布式组网:构建高效、灵活的企业网络架构
本文介绍了SD-WAN(软件定义广域网)在企业分布式组网中的应用,强调其智能化流量管理、简化的网络部署、弹性扩展能力和增强的安全性等核心优势,以及在跨国企业、多云环境、零售连锁和制造业中的典型应用场景。通过合理设计网络架构、选择合适的网络连接类型、优化应用流量优先级和定期评估网络性能等最佳实践,SD-WAN助力企业实现高效、稳定的业务连接,加速数字化转型。
SD-WAN分布式组网:构建高效、灵活的企业网络架构