V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
dongfuye1
V2EX  ›  推广

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

  •  1
     
  •   dongfuye1 · 281 天前 · 3301 次点击
    这是一个创建于 281 天前的主题,其中的信息可能已经有所发展或是发生改变。

    之前我有一篇文章,介绍了分布式事务最经典的七种解决方案,这里我们从业务需求的角度,根据不同的业务场景,给出最适合的解决方案。

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

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

    业务分类

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

    多个微服务组合成原子操作

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

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

    本地事务+多个微服务组合为原子操作

    有一类业务与前一种业务情况类似,但有一些差别:假设您有一个新用户注册成功后,领取一张优惠券和一个月会员。如果注册不成功,不希望调用领取;只有注册成功才领取。

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

    订单类对一致性要求较高的业务

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

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

    一致性要求不高的可回滚业务

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

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

    耗时较久的全局事务

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

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

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

    并发度较低的业务

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

    实践

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

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

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

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

    可靠消息例子

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

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

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

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

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

    1. 发送"领取"的消息给队列
    2. 消费"领取”的消息,然后调用 ObtainCoupon 和 ObtainVip,然后确认消息已成功消费

    对比 dtm 和 rocketmq 的方案,dtm 仅需要简单的几行代码即可( dtm 也提供 http 的接口,可以用任何语言直接发 http 请求),清晰简单。而 rocketmq 方案,涉及较多队列的知识,要做的工作较多

    SAGA 例子

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

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

    	saga := dtmcli.NewSaga(DtmServer, gid).
    		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,涉及比较多的背景知识,接入较复杂。

    更多的例子

    您可以访问https://github.com/yedf/dtm ,里面有很多的分布式事务例子

    多种模式并存

    如果您的实际项目,涉及分布式事务的场景较多,一种事务模式,可能并不满足需求,可能需要使用 SEATA+Rocketmq,接入以及维护成本较高。而 DTM 提供了一站式的解决方案,对常见的各种业务场景都提供了便捷的支持。

    小结

    dtm 作为一个新兴起的分布式事务框架,提供了强大的功能,以及简单易用的接口,极大的简化了微服务架构下,分布式事务的使用。

    下面是 dtm 与 seata 的主要特性对比:

    特性 DTM SEATA 备注
    支持语言 Golang 、python 、php 、c# 及其他 Java dtm 可轻松接入一门新语言
    异常处理 子事务屏障自动处理 手动处理 dtm 解决了幂等、悬挂、空补偿
    TCC 事务
    XA 事务
    AT 事务 AT 与 XA 类似,性能更好,但有脏回滚
    SAGA 事务 简单模式 状态机复杂模式 dtm 的状态机模式在规划中
    事务消息 dtm 提供类似 rocketmq 的事务消息
    通信协议 HTTP 、GRPC dubbo 等协议,无 HTTP dtm 对云原生友好

    dtm 的项目地址为https://github.com/yedf/dtm ,欢迎大家访问、试用、点亮 star

    9 条回复    2021-08-23 15:30:28 +08:00
    masterclock
        1
    masterclock  
       281 天前
    dtm 看着非常不错
    我们目前基于 temporal https://docs.temporal.io/ 实现简单的部分 saga,用于几个服务间的事务协作,“几”小于 10
    这种情况下
    有没有必要引入 dtm
    有没有可能引入 dtm
    如果,有,呃,能来个例子吗?🤪
    dongfuye1
        2
    dongfuye1  
    OP
       281 天前
    @masterclock 我大概看了一下 temporal 的例子,他很像一个把状态机写在客户端的 saga 事务管理器,或者叫 workflow 。
    我初步的感觉是,dtm 的简单 saga 能够满足绝大部分需求,并且比 temporal 更加简单易用。
    例子在文中,自取哈
    S2Line
        3
    S2Line  
       280 天前
    有性能测试数据吗?和不做分布式事务以及其他主流分布式事务解决方案(seata 、servicecomb 之类的)的对比。
    dongfuye1
        4
    dongfuye1  
    OP
       280 天前
    @S2Line 没收到 seata 、servicecomb-pack 的测试报告,没办法比较。从架构原理上,dtm 对每个事务分支,会有 1~3 次数据库读写,其他都是网络开销,额外性能消耗不大。
    S2Line
        5
    S2Line  
       280 天前
    @dongfuye1 想请问下你们为什么考虑使用 mysql 作为存放呢?有频繁的数据库读写,且字段内容比较单一,为什么不考虑使用 KV 库?还有请问数据库清理策略是怎样的呢? mysql 的可用性怎么保证的?
    dongfuye1
        6
    dongfuye1  
    OP
       280 天前
    @S2Line 您的问题比较深入。dtm 主要目标是解决分布式事务问题,大多数接入 dtm 的公司,微服务的数据访问用的是 mysql,因此 dtm 很自然采用 mysql 存储,对各家公司的运维成本最低,只要公司的 mysql 是高可用的,那么 dtm 就是高可用的。
    如果采用其他 KV 库,那么部署运维,高可用等,都有不少的学习维护成本。

    dtm 目前没做数据库清理,但是相关的查询索引都是 OK 的。如果贵公司的数据量很大,由 DBA 弄个简单的定时脚本进行清理即可。
    akira
        7
    akira  
       276 天前
    看到最后 果然是广告啊。。。欣慰
    wangxin13g
        8
    wangxin13g  
       275 天前
    最好的分布式事务框架果然就是不用框架
    fkdog
        9
    fkdog  
       275 天前
    谢谢,即使目前没有用到 dtm 的需求, 也学到不少分布式事务相关的知识.
    这样帖子即使是推广也是诚意满满.
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   3981 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 49ms · UTC 01:47 · PVG 09:47 · LAX 18:47 · JFK 21:47
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.