如何选择最适合你的分布式事务方案

简介: 当我们采用服务/微服务架构,对业务进行分拆解耦后,原先在一个单体内,使用本地数据库保证ACID的数据修改,因为跨了多个服务,就不再适用了,就需要引入分布式事务来保证新的原子性。

当我们采用服务/微服务架构,对业务进行分拆解耦后,原先在一个单体内,使用本地数据库保证ACID的数据修改,因为跨了多个服务,就不再适用了,就需要引入分布式事务来保证新的原子性。

由于分布式事务方案,无法做到ACID的保证,没有一种完美的方案,能够解决掉所有业务问题。因此在实际应用中,会根据业务的不同特性,选择最适合的分布式事务方案。

业务分类
下面是常见的几种业务分类,以及适合的解决方案介绍

多个微服务组合成原子操作
有一类业务场景是需要把多个微服务组合成原子操作:假设您有一个活动业务,用户点击领取按钮后,会领取一张优惠券,和一个月的会员。优惠券和会员分别属于不同的服务,需要都被调用,不希望出现一个服务调用成功,另一个因为网络或者其他故障导致没有成功。

这个场景适合可靠消息方案,可以使用rocketmq、rabbitmq等,发送给消息队列的消息,一定要等收到队列接收确认,再返回应用程序。

本地事务+多个微服务组合为原子操作
有一类业务与前一种业务情况类似,但有一些差别:假设您有一个新用户注册成功后,领取一张优惠券和一个月会员。如果注册不成功,不希望调用领取;只有注册成功才领取。

这种情况,适合本地消息方案,或者事务消息方案。这两种方案都能保证本地事务和消息的原子性。

订单类对一致性要求较高的业务
订单交易类业务,涉及资金、库存、优惠券等多个服务,完成一个订单,需要相关的各个服务组合成一个整体可回滚的事务。如果订单进行过程中金额先扣减,后续因为库存不够只能退款,把金额补偿加回来。在这个过程中用户看到了金额减少,又金额变回来,体验很差。一般这类业务都会先冻结资金,如果订单能成功,再扣减资金;不能成功,则解冻资金,这样能够让资金信息对用户更友好。

这种场景适合TCC方案,可以在TCC的Try中冻结资金,Confirm中扣减资金,Cancel中解冻资金

一致性要求不高的可回滚业务
如果业务对事务中的一致性要求不高,允许用户看到中间状态,例如用户的积分数据等。

这种模式适用SAGA模式,SAGA对比与TCC,只有正向操作和逆向补偿操作,会更加简单

耗时较久的全局事务
耗时较旧的全局事务适合可靠消息和SAGA,不适合TCC和XA,因为大多数的XA和TCC实现,为了方便用户灵活的定义事务,通常把事务的进度保存在应用程序,一旦事务进行中应用程序崩溃,无法往前进行下一步,只能回滚。

SAGA和可靠消息,把事务进度保存在数据库或消息系统中,任何一个组件临时的失败,如果重试成功,能够让事务继续。

其中如果整个事务是需要回滚的,那么适合SAGA,不需要回滚的,适合可靠消息

并发度较低的业务
如果业务并发度不高,事务又需要支持回滚,那么适合XA方案。XA方案,除了并发不高,也还需要本地数据库能支持XA接口。这个方案的优点是,使用上较简单,比较接近本地事务

实践
上面介绍完各种业务类型,以及适合的事务方案,通常情况下,您需要选择合适的开源项目来实施技术方案。在分布式事务领域,应用比较广泛的有DTM、SEATA、RocketMq

其中seata用Java开发,支持Java语言的接入,支持TCC、SAGA、XA、AT(类似XA,性能更高,但有脏回滚)

RocketMq用Java开发,支持各类语言的接入,仅支持可靠消息、事务消息模式

这里重点介绍DTM,它用GO开发,基于HTTP协议,支持多种语言接入,支持TCC、SAGA、XA、可靠消息、事务消息模式。

可靠消息例子
我们拿第一个最简单的业务场景“多个微服务组合成原子操作”来看DTM是如何解决问题的

假设领取优惠券和会员的处理函数分别是:ObtainCoupon和ObtainVip,那么处理领取逻辑的处理函数(用Go做示例)只用这么写:

        Add(Busi+"/ObtainCoupon", req).
        Add(Busi+"/ObtainVip", req)
    err := msg.Submit()

dtm收到客户端提交的消息后,会保证ObtainCoupon和ObtainVip被调用,如果任何一个出现失败,会不断重试,直到成功。

假如您采用的是rocketmq方案,那么您需要做以下几个步骤:

发送"领取"的消息给队列
消费"领取”的消息,然后调用ObtainCoupon和ObtainVip,然后确认消息已成功消费
对比dtm和rocketmq的方案,dtm仅需要简单的几行代码即可(dtm也提供http的接口,可以用任何语言直接发http请求),清晰简单。而rocketmq方案,涉及较多队列的知识,要做的工作较多

SAGA例子
假设我们有一个积分兑换课程的业务,一方面积分不属于非常核心的资产,中间状态允许用户看到,另一方面兑换课程可能出现课程已拥有权限,则需要回滚,因此该业务属于“一致性要求不高的可回滚业务“。

我们采用SAGA方案来解决这个问题,来看看DTM的解决方式,代码大致如下:

        Add(Busi+"/AdjustIntegral", Busi+"/AdjustIntegralRevert", req).
        Add(Busi+"/AuthCourse", Busi+"/AuthCourseRevert", req)
    saga.WaitResult = true
    err := saga.Submit()

dtm收到客户端提交的saga事务之后,会按顺序调用AdjustIntegral,AuthCourse,如果函数返回错误要求回滚,dtm则会调用AuthCourseRevert,AdjustIntegralRevert进行回滚。

如果您没有采用dtm方案,那么您可以采用SEATA的SAGA,涉及比较多的背景知识,接入较复杂。

如果你想开发小程序或者APP的话,可以通过第三方专业开发平台,来帮助你实现开发需求:厦门在乎科技-专注厦门小程序开发公司、app开发、网站开发

相关实践学习
消息队列RocketMQ版:基础消息收发功能体验
本实验场景介绍消息队列RocketMQ版的基础消息收发功能,涵盖实例创建、Topic、Group资源创建以及消息收发体验等基础功能模块。
消息队列 MNS 入门课程
1、消息队列MNS简介 本节课介绍消息队列的MNS的基础概念 2、消息队列MNS特性 本节课介绍消息队列的MNS的主要特性 3、MNS的最佳实践及场景应用 本节课介绍消息队列的MNS的最佳实践及场景应用案例 4、手把手系列:消息队列MNS实操讲 本节课介绍消息队列的MNS的实际操作演示 5、动手实验:基于MNS,0基础轻松构建 Web Client 本节课带您一起基于MNS,0基础轻松构建 Web Client
相关文章
|
7月前
|
存储 NoSQL Java
分布式锁中的王者方案 - Redission
分布式锁中的王者方案 - Redission
91 1
|
12天前
|
消息中间件 SQL 中间件
大厂都在用的分布式事务方案,Seata+RocketMQ带你打破10万QPS瓶颈
分布式事务涉及跨多个数据库或服务的操作,确保数据一致性。本地事务通过数据库直接支持ACID特性,而分布式事务则需解决跨服务协调难、高并发压力及性能与一致性权衡等问题。常见的解决方案包括两阶段提交(2PC)、Seata提供的AT和TCC模式、以及基于消息队列的最终一致性方案。这些方法各有优劣,适用于不同业务场景,选择合适的方案需综合考虑业务需求、系统规模和技术团队能力。
98 7
|
17天前
|
缓存 NoSQL Java
Spring Boot中的分布式缓存方案
Spring Boot提供了简便的方式来集成和使用分布式缓存。通过Redis和Memcached等缓存方案,可以显著提升应用的性能和扩展性。合理配置和优化缓存策略,可以有效避免常见的缓存问题,保证系统的稳定性和高效运行。
35 3
|
16天前
|
消息中间件 架构师 数据库
本地消息表事务:10Wqps 高并发分布式事务的 终极方案,大厂架构师的 必备方案
45岁资深架构师尼恩分享了一篇关于分布式事务的文章,详细解析了如何在10Wqps高并发场景下实现分布式事务。文章从传统单体架构到微服务架构下分布式事务的需求背景出发,介绍了Seata这一开源分布式事务解决方案及其AT和TCC两种模式。随后,文章深入探讨了经典ebay本地消息表方案,以及如何使用RocketMQ消息队列替代数据库表来提高性能和可靠性。尼恩还分享了如何结合延迟消息进行事务数据的定时对账,确保最终一致性。最后,尼恩强调了高端面试中需要准备“高大上”的答案,并提供了多个技术领域的深度学习资料,帮助读者提升技术水平,顺利通过面试。
本地消息表事务:10Wqps 高并发分布式事务的 终极方案,大厂架构师的 必备方案
|
22天前
|
NoSQL 安全 PHP
hyperf-wise-locksmith,一个高效的PHP分布式锁方案
`hyperf-wise-locksmith` 是 Hyperf 框架下的互斥锁库,支持文件锁、分布式锁、红锁及协程锁,有效防止分布式环境下的竞争条件。本文介绍了其安装、特性和应用场景,如在线支付系统的余额扣减,确保操作的原子性。
24 4
|
1月前
|
NoSQL 算法 关系型数据库
分布式 ID 详解 ( 5大分布式 ID 生成方案 )
本文详解分布式全局唯一ID及其5种实现方案,关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
分布式 ID 详解 ( 5大分布式 ID 生成方案 )
|
6月前
|
消息中间件 数据挖掘 程序员
【建议收藏】高并发下的分布式事务:如何选择最优方案?
本文介绍了分布式事务的三种常见解决方案。在分布式系统中,事务处理变得复杂,需确保ACID特性。TCC(Try-Confirm-Cancel)方案适用于严格资金要求的场景,如银行转账,通过预留、确认和取消步骤确保一致性。可靠消息最终一致性方案适合一致性要求较低的场景,如电商积分处理,通过消息中间件实现最终一致性。最大努力通知方案则用于允许不一致的场景,如数据分析,通过重复通知尽可能达成一致性。选择合适的方案取决于具体应用场景。
180 5
|
2月前
|
存储 缓存 NoSQL
分布式架构下 Session 共享的方案
【10月更文挑战第15天】在实际应用中,需要根据具体的业务需求、系统架构和性能要求等因素,选择合适的 Session 共享方案。同时,还需要不断地进行优化和调整,以确保系统的稳定性和可靠性。
|
2月前
|
SQL NoSQL 安全
分布式环境的分布式锁 - Redlock方案
【10月更文挑战第2天】Redlock方案是一种分布式锁实现,通过在多个独立的Redis实例上加锁来提高容错性和可靠性。客户端需从大多数节点成功加锁且总耗时小于锁的过期时间,才能视为加锁成功。然而,该方案受到分布式专家Martin的质疑,指出其在特定异常情况下(如网络延迟、进程暂停、时钟偏移)可能导致锁失效,影响系统的正确性。Martin建议采用fencing token方案,以确保分布式锁的正确性和安全性。
52 0
|
4月前
|
存储 NoSQL Java
一天五道Java面试题----第十一天(分布式架构下,Session共享有什么方案--------->分布式事务解决方案)
这篇文章是关于Java面试中的分布式架构问题的笔记,包括分布式架构下的Session共享方案、RPC和RMI的理解、分布式ID生成方案、分布式锁解决方案以及分布式事务解决方案。
一天五道Java面试题----第十一天(分布式架构下,Session共享有什么方案--------->分布式事务解决方案)