Loading [MathJax]/jax/output/CommonHTML/config.js
前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >分布式柔性事务之事务消息详解

分布式柔性事务之事务消息详解

作者头像
玄姐谈AGI
发布于 2020-06-28 10:06:20
发布于 2020-06-28 10:06:20
4620
举报
文章被收录于专栏:架构之美架构之美

- 消息详解 -

一、概述

在 《柔性事务之TCC详解》 和《柔性事务之Saga详解》两文中我们详细剖析了柔性事务的第一个分支补偿型事务。在《刚性事务总结和柔性事务概述》中我们介绍过的柔性事务包含补偿型事务和通知型事务。

通知型事务主要包含事务消息和最大努力通知型分布式事务两个组成。通知型事务的核心思想是通过MQ来通知其他事务参与者自己事务的执行状态。MQ组件的引入有效的将事务参与者解耦开,各个参与者都可以异步执行,所以通知型事务又称为异步事务。

事务消息的难度在于服务本地事务和投递消息的一致性保障。目前业界解决这个一致性的方案有两个分支:

  • 基于MQ自身的事务消息方案
  • 基于DB的本地消息表方案

- 基于MQ自身的事务消息方案 -

基于MQ的事务消息方案主要依靠MQ的半消息机制来实现投递消息和参与者自身本地事务的一致性保障。半消息机制实现原理其实借鉴的2PC的思路,是二阶段提交的广义拓展,流程图如下:

1、事务发起方首先发送prepare消息到MQ;

2、在发送prepare消息成功后执行本地事务;

3、根据本地事务执行结果返回commit或者是rollback;

4、如果消息是rollback, MQ将删除该prepare消息不进行下发,如果是commit消息,MQ将会消息发送给consumer端;

5、如果执行本地事务过程中,执行端挂掉,或者超时,MQ服务器端将不停的询问producer来获取事务状态;

6、Consumer端的消费成功机制有MQ保证

MQ事务消息方案因为使用了半消息机制,对业务页具有比较大侵入性,有以下注意点:

1、 业务方调用半消息,并提供对应的回查方法;

2、 MQ提要提供半消息机制,并定期扫描长期半消息,对消息生产者进行回查确认事务。

3、 消费方需要进行幂等消费。

- 基于BD的本地消息表方案 -

有时候我们目前的MQ组件并不支持事务消息,或者我们想尽量少的侵入业务方。这时我们需要另外一种方案“基于DB本地消息表“,流程图如下:

1、 业务方:直接利用本地事务,将业务数据和事务消息直接写入数据库。

2、 投递线程:使用专门的投递工作线程进行事务消息投递到MQ,根据投递ACK去删除事务消息表记录

本地事务消息表的优势在于方案的通用性,无需提供回查方法,进一步减少的业务的侵入。在某些场景下,还可以进一步利用注解等形式进行解耦,有可能实现无业务代码侵入式的实现。我们上面说了本地事务消息表的基本理论,那么如果要设计一个高可用的企业级本地事务消息表方案,就要考虑更多的事情,在性能上做更大的优化,降低更多的重复投递率。以下是一个企业级事务消息的设计流程图:

1、 事务消息服务:提供通用投递接口,用于保证事务消息的本地写入,并将事务消息写入事务内存队列。

2、 使用投递线程池,继续事务内存队列投递派发分配。投递工作线程只投递本实例拥有的事务消息,投递失败线程列入时间轮队列;重试机制使用失败挡位区分,默认提供6档:5s、10s、15s、20s、25s、30s。

3、 时间轮线程进行60秒转动,将到期的失败事务消息重入事务内存队列.

4、 因为我们的事务消息服务是无状态化的多实例存在,所以需要一个持锁线程进行主节点竞争强锁,处理一些额外的工作。

5、 因为我们的事务内存队列是内存级,不可避免面临重启等情况下的数据丢失。这时需要事务消息服务主节点进行定期扫表,将长期未投递的事务消息取出放入事务消息服务。

6、 事务消息服务主节点还有一个清理线程,专门用于将已处理成功的历史事务消息进行归档清理,降低DB的数据量。

- 总结 -

咱们上面介绍了MQ事务消息方案和DB本地消息表方案,这两个方案有什么区别呢?

1、 MQ事务消息方案

a) 需要MQ支持半消息机制或者类似特性,在重复投递上具有比较好的去重处理

b) 需要业务方进行改造,提供对应的本地操作成功回查功能。具有比较大的业务侵入性。

2、 DB本地事务消息表方案

a) 使用了数据库来存储事务消息,降低了对MQ的需求,但是增加了存储成本。

b) 事务消息使用了异步投递,增大了消息重复投递的可能性。

我们说了两种事务消息的特性和优劣性,我们在总结下事务消息的共性。

1、 事务消息都依赖MQ进行事务通知,所以都是异步的。

2、 事务消息在投递方都是存在重复投递的可能,需要有配套的机制去降低重复投递率,实现更友好的消息投递去重。

3、 事务消息的消费方,因为投递重复的无法避免,因此需要进行消费去重设计或者服务幂等设计。

- 作者介绍 -

孙玄

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

林淮川

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

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2020-06-22,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 架构之美 微信公众号,前往查看

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

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
分布式架构设计篇(十)-柔性事务之事务消息详解
​ 在 《柔性事务之TCC详解》 和《柔性事务之Saga详解》两文中我们详细剖析了柔性事务的第一个分支补偿型事务。在《刚性事务总结和柔性事务概述》中我们介绍过的柔性事务包含补偿型事务和通知型事务。
林淮川
2020/07/04
1.9K0
分布式事务常见解决方案
Innodb采用MVCC多版本并发控制实现读写并发执行,并且以此来支持读已提交和可重复读两个隔离级别,核心在于快照创建时间点不同,前者是每次select时创建快照版本,后者是在事务开始时创建快照版本。
大忽悠爱学习
2023/02/13
6120
分布式事务常见解决方案
分布式架构设计篇(七)-刚性事务总结和柔性事务概述
​ 在《分布式架构之设计篇-刚性事务之2PC详解》和《分布式架构之设计篇-刚性事务之3PC详解》二文中分析了分布式事务的本质、XA、2PC、3PC等等。但是没有说分布式事务的现象或者场景,我总结了分布式事务的触发场景大约有以下几种:
林淮川
2020/06/30
1.7K1
分布式架构设计篇(七)-刚性事务总结和柔性事务概述
干货来啦!分布式场景之刚性事务-2PC详解
分布式场景下,多个服务同时对服务一个流程,比如电商下单场景,需要支付服务进行支付、库存服务扣减库存、订单服务进行订单生成、物流服务更新物流信息等。如果某一个服务执行失败,或者网络不通引起的请求丢失,那么整个系统可能出现数据不一致的原因。
林淮川
2021/12/20
4870
干货来啦!分布式场景之刚性事务-2PC详解
分布式架构设计篇(五)-刚性事务之2PC详解
​ 分布式场景下,多个服务同时对服务一个流程,比如电商下单场景,需要支付服务进行支付、库存服务扣减库存、订单服务进行订单生成、物流服务更新物流信息等。如果某一个服务执行失败,或者网络不通引起的请求丢失,那么整个系统可能出现数据不一致的原因。
林淮川
2020/06/29
1.8K0
交易系统架构演进之路(四):分布式事务
上一篇文章我们将整个交易系统进行了微服务化,拆分为了多个相互独立的业务组件,每个业务组件不只是包含自己业务的微服务,还包括了独立管理的数据库。那么,我们来考虑下单的场景,用户下委托单的时候,主要有三步操作:一是冻结金额,二是新增订单,三是投递给到撮合引擎。这三步需要保证事务的一致性。在服务和数据库都不拆分的情况下,是很容易满足的。但拆分之后,这几个步骤的操作也分开到不同业务组件了,服务是分开的,数据库也是分开的。在这种分布式的环境下,又要如何保证事务的一致性,这就是分布式事务问题了。
Keegan小钢
2021/01/12
1.2K0
交易系统架构演进之路(四):分布式事务
分布式柔性事务之最大努力通知事务详解
咱们今天聊聊分布式事务系列中的最后一个方案:最大努力通知事务。最大努力通知事务的主流实现仍是基于MQ来进行事务控制。最大努力通知事务和事务消息都是通知型事务,主要适用于那些需要异步更新数据,并且对数据的实时性要求较低的场景。
玄姐谈AGI
2020/07/02
4010
分布式柔性事务之最大努力通知事务详解
分布式系统学习10:分布式事务
单体架构时,以本地事务为例,业务场景是下单场景,用户下单、创建订单、扣减库存这些操作都可以在一个数据库事务中完成。
卷福同学
2025/01/23
980
分布式架构设计篇(十二)-分布式事务总结篇
​ 咱们前面分别对分布式事务的几个分支:XA、2PC、3PC、TCC、Saga、事务消息、最大努力事务进行的详细介绍。本篇作为分布式事务设计的收尾篇,讲对前面的内容查缺补漏和总结,最后对市面的一些开源框架做一些介绍。
林淮川
2020/07/13
1.5K2
一文理解分布式事务的解决方案
单体数据库不涉及网络交互,所以在多表之间实现事务是比较简单的,这种事务称之为本地事务。
全菜工程师小辉
2021/07/23
7600
分布式事务专题
完成某件事情,可能有多个参与者需要执行多个步骤,最终多个步骤要么全部成功,要么全部失败。
botkenni
2023/03/01
5700
分布式事务专题
分布式事务的实现方法及替代方案
图的上半是两阶段提交成功的演示, 下半是两阶段提交失败的演示. 关于两阶段提交网上有很多经典的讲解, 这里就不细说了
java思维导图
2018/07/26
1K0
分布式事务的实现方法及替代方案
分布式柔性事务之Saga详解
Saga模型起源于1987年 Hector Garcia-Molina,Kenneth Salem 发表的论文《Sagas》,是分布式事务相关概念最早出现的。
玄姐谈AGI
2020/06/28
1.7K0
分布式事物的设计与实践
这就是分布式事物问题,当APP要买东西,这个操作会涉及到多个服务,意味着要操作多个数据库,这样本地事物就无法保证数据的一致性,所以就产生了分布式事物问题.
彼岸舞
2021/04/01
4830
分布式事物的设计与实践
分布式事务概述与项目实战
随着计算能力的提升、互联网的兴起、数据的分布和存储需求、容错性和可用性的要求、业务的分布和协同需求以及云计算和大数据技术的发展,分布式系统变得越来越重要,并在各个领域得到广泛应用。分布式系统由于机器宕机、网络异常、消息丢失、消息乱序、数据错误、不可靠的 TCP、存储数据丢失等原因面临一系列挑战,本文重点讲述分布式系统面临的挑战之一数据一致性问题。
腾讯技术工程官方号
2024/01/10
5940
分布式事务概述与项目实战
分布式事务有这一篇就够了!
事务可以看做是一次大的活动,它由不同的小活动组成,这些活动要么全部成功,要么全部失败。
烂猪皮
2020/11/02
1.7K0
分布式事务有这一篇就够了!
分布式事务几种方案
数据库支持的 2PC【2 phase commit 二阶提交】,又叫做 XA Transactions。
一个风轻云淡
2023/10/15
2150
分布式事务几种方案
我说分布式事务之消息最终一致性事务(二):RocketMQ的实现
上一篇《我说分布式事务之消息最终一致性事务(一):原理及实现》中,我们讲解了可靠消息最终一致性的实现原理及如何基于一款开源的消息中间件,实现一个可靠消息服务的思路。
程序猿DD
2019/05/10
2.8K0
我说分布式事务之消息最终一致性事务(二):RocketMQ的实现
分布式事务
两阶段提交协议 Two Phase Commitment Protocol 涉及到两种角色
Java_慈祥
2024/08/06
1840
分布式事务
从一笔金币充值去思考分布式事务
考虑支付重构的时候,自然想到原本属于一个本地事务中的处理,现在要跨应用了要怎么处理。拿充值订单举个栗子吧,假设:原本订单模块和账户模块是放在一起的,现在需要做服务拆分,拆分成订单服务,账户服务。原本收到充值回调后,可以将修改订单状态和增加金币放在一个mysql事务中完成的,但是呢,因为服务拆分了,就面临着需要协调2个服务才能完成这个事务
java思维导图
2018/12/13
6600
从一笔金币充值去思考分布式事务
推荐阅读
相关推荐
分布式架构设计篇(十)-柔性事务之事务消息详解
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档