文档章节

RocketMQ事务消息实现分析

o
 osc_pn11u1x9
发布于 2018/08/07 09:49
字数 1808
阅读 11
收藏 0

精选30+云产品,助力企业轻松上云!>>>

这周RocketMQ发布了4.3.0版本,New Feature中最受关注的一点就是支持了事务消息:

今天花了点时间看了下具体的实现内容,下面是简单的总结。

RocketMQ事务消息概要

通过冯嘉发布的《RocketMQ 4.3正式发布,支持分布式事务》一文可以看到RocketMQ采用了2PC的方案来提交事务消息,同时增加一个补偿逻辑来处理二阶段超时或者失败的消息。

这张图说明了事务消息的大致方案,分为两个逻辑:正常事务消息的发送及提交、事务消息的补偿流程

事务消息发送及提交:

  1. 发送消息(half消息)
  2. 服务端响应消息写入结果
  3. 根据发送结果执行本地事务(如果写入失败,此时half消息对业务不可见,本地逻辑不执行)
  4. 根据本地事务状态执行Commit或者Rollback(Commit操作生成消息索引,消息对消费者可见)

补偿流程:

  1. 对没有Commit/Rollback的事务消息(pending状态的消息),从服务端发起一次“回查”
  2. Producer收到回查消息,检查回查消息对应的本地事务的状态
  3. 根据本地事务状态,重新Commit或者Rollback

补偿阶段用于解决消息Commit或者Rollback发生超时或者失败的情况。

以上RocketMQ事务消息的整体方案,对于了解Notify的同学应该是很熟悉的,下面是之前Notify相关的资料:

整体方案是完全相同的,只是两者的Storage不同。

RocketMQ事务消息设计

一阶段的消息如何对用户不可见

事务消息相对普通消息最大的特点就是一阶段发送的消息对用户是不可见的。

如何做到写入了消息但是对用户不可见?——写入消息数据,但是不创建对应的消息的索引信息。

熟悉RocketMQ的同学应该都清楚,消息在服务端的存储结构如上,每条消息都会有对应的索引信息,Consumer通过索引读取消息。

那么实现一阶段写入的消息不被用户消费(需要在Commit后才能消费),只需要写入Storage Queue,但是不构建Index Queue即可。

RocketMQ中具体实现策略是:写入的如果事务消息,对消息的Topic和Queue等属性进行替换,同时将原来的Topic和Queue信息存储到消息的属性中。

上图即RocketMQ替换事务消息属性的代码实现,替换属性后这条消息被写入到TransactionalMessageUtil.buildHalfTopic()的Queue 0中。

(RocketMQ将事务消息一阶段发送的消息称为Half消息让人费解,采用的2PC的方式,一阶段消息称为Prepare Message或者Pending Message更能体现它的含义)

在完成Storage Queue的写入后,在appendCallback中,普通消息会去构建消息索引,而如果发现是事务消息,则跳过了创建索引的逻辑。

如果让一阶段的消息对用户可见

在完成一阶段写入一条对用户不可见的消息后,二阶段如果是Commit操作,则需要让消息对用户可见;如果是Rollback则需要撤销一阶段的消息。

先说Rollback的情况。对于Rollback,本身一阶段的消息对用户是不可见的,其实不需要真正撤销消息(实际上RocketMQ也无法去真正的删除一条消息,因为是顺序写文件的)。

但是区别于这条消息没有确定状态(Pending状态,事务悬而未决),需要一个操作来标识这条消息的最终状态。

RocketMQ事务消息方案中引入了Op消息的概念,用Op消息标识事务消息是否状态已经确定(Commit或者Rollback)。如果一条事务消息没有对应的Op消息,说明这个事务的状态还无法确定(可能是二阶段失败了)。

引入Op消息后,事务消息无论是Commit或者Rollback都会记录一个Op操作。

Commit相对于Rollback只是在写入Op消息前创建Half消息的索引。

Op消息的存储

RocketMQ将Op消息写入到全局一个特定的Topic中:TransactionalMessageUtil.buildOpTopic()

这个Topic是一个内部的Topic(像Half消息的Topic一样),不会被用户消费。

Op消息的内容为对应的Half消息的存储的Offset,这样通过Op消息能索引到Half消息进行后续的回查操作。

Half消息的索引构建

在执行二阶段的Commit操作时,需要构建出Half消息的索引。

一阶段的Half消息由于是写到一个特殊的Topic,所以二阶段构建索引时需要读取出Half消息,并将Topic和Queue替换成真正的目标的Topic和Queue,之后通过一次普通消息的写入操作来生成一条对用户可见的消息。

所以RocketMQ事务消息二阶段其实是利用了一阶段存储的消息的内容,在二阶段时恢复出一条完整的普通消息,然后走一遍消息写入流程。

如何处理二阶段失败的消息

如果二阶段失败了,比如在Commit操作时出现网络问题导致Commit失败,那么需要通过一定的策略使这条消息最终被Commit。

RocketMQ采用了一种补偿机制,称为“回查”。

Broker端对未确定状态的消息发起回查,将消息发送到对应的Producer端(同一个Group的Producer),由Producer根据消息来检查本地事务的状态,进而执行Commit或者Rollback。

Broker端通过对比Half消息和Op消息进行事务消息的回查并且推进CheckPoint(记录那些事务消息的状态是确定的)。

值得注意的一点是具体实现中,在回查前,系统会执行putBackHalfMsgQueue操作,即将Half消息重新写一遍到Half消息的Queue中。这么做其实是为了能有效的推进上面的CheckPoint。

RocketMQ事务消息设计总结

以上是RocketMQ事务消息实现的示意图:

  • 通过写Half消息的方式来实现一阶段消息对用户不可见
  • 通过Op消息来标记事务消息的状态
  • 通过读取Half消息来生成一条新的Normal消息来完成二阶段Commit之后消息对Consumer可见
  • 通过Op消息来执行回查

优势:

  • Half Queue和Op Queue的数量可控,不会随着Topic的增加而增加
  • 没有外部依赖,实现自包含

缺陷:

  • 每条事务消息至少需要写一条Half消息(异常情况可能会有多条)和Normal,写放大了
  • 所有Half消息都是写到全局预设的一个内部的Topic,这块可能性能会有一些问题(所有Topic的事务消息会往一个Topic上写)
  • 全局Op消息写一个Topic,回查时间可能会有相互影响

o
粉丝 0
博文 500
码字总数 0
作品 0
私信 提问
加载中
请先登录后再评论。

暂无文章

渗透测试的概念和实战

目录 1. 前言 2. 常见web安全漏洞 3. 思路 3.1渗透测试思路 3.2黑客攻击思路 4. 暴力破解 4.1谷歌黑语法 4.1.1 黑语法inurl:搜索url包含指定字符串 4.1.2 黑语法intitle:搜索网页中的标题名...

六道木
28分钟前
19
0
Nginx搭建

Web服务器 放置网站文件,全世界浏览 可以放置数据文件,让全世界可以下载。 Nginx官方网站www.nginx.org #rz nginx-1.11.6.tar.gz #ls #rpm -q zlib-devel pcre-devel #yum –y install zli...

osc_fnto2dbd
39分钟前
14
0
如何在1分钟内CSDN收益1000万,走上人生巅峰?!

事情的起因源于前几日CSDN专栏作者群中有位同志自曝收益:426584.46元(不用数了42万+,未证实是否属实),瞬间刷屏。 那么作为一位普通的技术分享者,是否有机会利用开源项目短时间内赢取白...

osc_8db3mwb5
41分钟前
23
0
【java基础(五十)】为什么要使用泛型程序设计

从Java程序设计语言1.0版发布以来,变化最大的部分就是泛型。致使Java SE 5.0中增加泛型机制的主要原因是为了满足1999年制定的最早的Java规范需求之一(JSR 14)。专家组花费了5年左右的时间...

osc_qcm2mqmy
42分钟前
20
0
如何将Unix时间戳转换为DateTime,反之亦然? - How can I convert a Unix timestamp to DateTime and vice versa?

问题: There is this example code, but then it starts talking about millisecond / nanosecond problems. 有此示例代码,但随后开始谈论毫秒/纳秒问题。 The same question is on MSDN, ......

javail
43分钟前
9
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部