专栏首页分布式架构分布式架构设计篇(十一)-柔性事务之最大努力通知事务详解
原创

分布式架构设计篇(十一)-柔性事务之最大努力通知事务详解

- 概述 -

咱们在上一篇文章探讨了事务消息,事务消息是基于MQ实现的一种异步事务。接下来咱们开始聊聊咱们分布式事务系列中的最后一个方案:最大努力通知事务。最大努力通知事务的主流实现仍是基于MQ来进行事务控制。最大努力通知事务和事务消息都是通知型事务,主要适用于那些需要异步更新数据,并且对数据的实时性要求较低的场景。

最大努力通知事务主要用于外部系统,因为外部的网络环境更加复杂和不可信,所以只能尽最大努力去通知实现数据最终一致性,比如充值平台与运营商、支付对接、商户通知等等跨平台、跨企业的系统间业务交互场景;而事务消息主要适用于内部系统的数据最终一致性保障,因为内部相对比较可控,比如订单和购物车、收货与清算、支付与结算等等场景。

普通消息是无法解决本地事务执行和消息发送的一致性问题的。因为消息发送是一个网络通信的过程,发送消息的过程就有可能出现发送失败、或者超时的情况。超时有可能发送成功了,有可能发送失败了,消息的发送方是无法确定的,所以此时消息发送方无论是提交事务还是回滚事务,都有可能不一致性出现。所以通知型事务的难度在于投递消息和参与者自身本地事务的一致性保障。

因为核心要点一致,都是为了保证消息的一致性投递,所以最大努力通知事务在投递流程上跟事务消息是一样的,因此也有两个分支:

  • 基于MQ自身的事务消息方案
  • 基于DB的本地事务消息表方案
- 最大努力通知事务流程 -

我们先看看事务消息的两个分支:

​图1-基于MQ的事务消息
​图2-基于DB消息表的事务消息

最大努力通知事务在投递之前跟上面流程都差不多,关键在于投递后的处理,因为事务消息在于内部的事务处理,所以MQ和系统是直连并且无需严格的权限、安全等方面的思设计。

​图3-基于事务消息的最大努力通知事务
​图4-基于DB消息表的最大努力通知事务

最大努力通知事务在投递之前跟上面流程都差不多,关键在于投递后的处理,因为事务消息在于内部的事务处理,所以MQ和系统是直连并且无需严格的权限、安全等方面的思设计。最大努力通知事务在于第三方系统的对接,所以最大努力通知事务有几个特性

  • 业务主动方在完成业务处理后,向业务被动方(第三方系统)发送通知消息,允许存在消息丢失。
  • 业务主动方提供递增多挡位时间间隔(5min、10min、30min、1h、24h),用于失败重试调用业务被动方的接口;在通知N次之后就不再通知,报警+记日志+人工介入。
  • 业务被动方提供幂等的服务接口,防止通知重复消费。
  • 业务主动方需要有定期校验机制,对业务数据进行兜底;防止业务被动方无法履行责任时进行业务回滚,确保数据最终一致性。

在很多其他资料都会说“业务被动方根据定时策略,向业务活动的主动方进行轮询,进而恢复丢失的业务消息”;但在真实场景中被动方很多时候可能是业务强势方,不会反向调用业务主动方的接口;所以我们需要一定的熔断探活机制来保证我们的通知有效性。还有很多资料也说“被动方的处理结果不影响主动方的处理结果”,在我的认知中,这句话其实是有缺陷的:在大多数下确实业务被动方的处理结果不影响业务主动方,但在业务被动方确定无法履行业务责任时,业务主动方可能仍需要回滚业务数据。

- 最大努力通知事务VS 事务消息 -

​ 最大努力通知事务在我认知中,其实式基于事务消息发展而来适用于外部对接的一种业务实现。他们主要有的是业务差别,如下:

  • 从参与者来说:最大努力通知事务适用于跨平台、跨企业的系统间业务交互;事务消息更适用于同网络体系的内部服务交付。
  • 从消息层面说:最大努力通知事务需要主动推送并提供多档次时间的重试机制来保证数据的通知;而事务消息只需要消息消费者主动去消费。
  • 从数据层面说:最大努力通知事务还需额外的定期校验机制对数据进行兜底,保证数据的最终一致性;而事务消息秩序保证消息的可靠投递即可,自身无需对数据进行兜底处理。
- 总结 -

​ 最大努力通知事务本质是通过引入定期校验机制来对最终一致性做兜底,对业务侵入性较低;适合于对最终一致性敏感度比较低、业务链路较短的场景。

- 作者介绍 -

孙玄

毕业于浙江大学,奈学教育创始人兼CEO,前转转公司技术委员会主席,前58集团技术委员会主席,前百度资深研发工程师,腾讯云TVP,阿里云MVP,在线直播大课《百万架构师》品牌创始人。

林淮川

毕业于西安交通大学;奈学教育《百万架构师训练营》讲师及企业级源码内源负责人,前大树金融高级架构师;前大树金融技术委员会开创者;前大树金融供应链金融技术总监;前天阳宏业交易事业部技术主管;多年互联网金融行业(ToB)经验。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 分布式架构设计篇(五)-刚性事务之2PC详解

    ​ 分布式场景下,多个服务同时对服务一个流程,比如电商下单场景,需要支付服务进行支付、库存服务扣减库存、订单服务进行订单生成、物流服务更新物流信息等...

    林淮川
  • 分布式架构设计篇(六)-刚性事务之3PC详解

    咱们上文介绍了分布式事务的常见方案、类型划分、2PC的起源和流程。但是不幸的是2PC还是存在几个问题:

    林淮川
  • 分布式架构设计篇(七)-刚性事务总结和柔性事务概述

    ​ 在《分布式架构之设计篇-刚性事务之2PC详解》和《分布式架构之设计篇-刚性事务之3PC详解》二文中分析了分布式事务的本质、XA、2PC、3PC等...

    林淮川
  • 分布式柔性事务之最大努力通知事务详解

    咱们今天聊聊分布式事务系列中的最后一个方案:最大努力通知事务。最大努力通知事务的主流实现仍是基于MQ来进行事务控制。最大努力通知事务和事务消息都是通知型事务,主...

    孙玄@奈学教育
  • 分布式柔性事务之最大努力通知事务详解

    咱们今天聊聊分布式事务系列中的最后一个方案:最大努力通知事务。最大努力通知事务的主流实现仍是基于MQ来进行事务控制。最大努力通知事务和事务消息都是通知型事务,主...

    江帅帅
  • Spring事务的传播特性和隔离级别

    什么是事务 事务(Transaction)是并发控制单位,是用户定义的一个操作序列,这些操作要么都做,要么都不做,是一个不可分割的工作单位。 事务通常以BE...

    葆宁
  • [spring事务]一篇浅文让你摆脱事务困扰

    原子性(Atomicity):事物是一个不可分割的工作单位,事物中的操作要么都发生,要么都不发生

    星尘的一个朋友
  • Java项目实践,数据访问层事务控制方法总结,保障数据安全

    事务是为解决数据安全操作提出的,事务控制实际上就是控制数据的安全访问,比如,银行转帐业务,账户A要将自己账户上的1000元转到B账户下面,A账户余额首先要减去1...

    用户1289394
  • 关系型数据库的ACID(原子性、一致性、隔离性与持久性)

    Coxhuang
  • spring事物

    用户1637228

扫码关注云+社区

领取腾讯云代金券