百科狗-知识改变命运!
--

RocketMQ概念篇

泡在奶味里1年前 (2023-12-14)阅读数 9#综合百科
文章标签队列消息

白话系列文章讲述RocketMQ。因为是白话,尽量通过比较直白的方式来介绍RocketMQ,所以涉及到详细的技术细节可能表述的不是那么严谨。但是不用担心,后续会有专门的文章详细介绍技术细节。

这篇文章介绍的是RocketMQ基本概念,分为介绍和提问两部分,如果对概念很清楚了就不用了,闲暇无事可以看看提问。

类似介绍概念的文章网上比较多,希望这篇文章提问式的阅读会让大家对概念能有更清晰的认识。

Message Queue 消息队列 ,既然是队列,就要实现 数据结构中队列 的基本特征,比如先进先出,入队、出队操作等。

RocketMQ就是把内存中使用的那个队列,变成一个独立的、大家都可以用的队列系统。

一个业务事件,是整个MQ领域最核心的概念,无论是生产还是消费都是针对Topic进行操作。

如果MQ是个大的队列,只有一个队列可以用太浪费了吧,来分一分分一分,分解成很多个小的独立的队列。 RocketMQ变成一个管理队列的系统 ,而分解下来的若干个 小的队列通过什么来区分呢 ?

就是通过topic。

比如我的业务定义topic:tp_im_event。你的业务定义topic:tp_cargo_event,那就是两个小队列了,我的业务用我的队列,你的项目用你的队列。 Topic就是队列的名字 。

提问 :

如果不小心定义了相同的Topic名字,上线后会发生什么?

申请Topic好麻烦,所有业务都用一个Topic好了,这样会有什么问题?

Topic名字起的越酷炫越好?

既然Topic是队列的名字,那么queue就表示真实操作的队列了。一开始的时候一个Topic就对应一个queue,多好,一个是名字、一个是现实。可是用着用着就悲催了,为啥?消息操作太多了,全都怼在一个小队列上。为了提高效率,咋整RocketMQ是这样做的,一个Topic绑定的是一组queue,这样每个queue分摊部分压力,性能就上去了。

读队列 个数:可以用来读取数据的队列个数

写队列 个数:可以用来写入数据的队列个数

queue :真实存储数据用的队列。

提问 :

我申请了一个Topic,读队列设置2,写队列设置4有什么问题么?

我申请了一个Topic,读队列设置4,写队列设置2有什么问题么?

既然增加队列数可以提升性能,我申请8848个队列的Topic是不是可以达到性能的巅峰?

好了,说完了队列,我们再来说一说队列存储的内容是什么?

存储的是消息!Message!尽量小,别发个文件啊什么的大东西,后面真心扛不住(超过特定大小还会报错)

一个queue里都是消息,如何对这些消息进行归类呢?为了进一步细化消息,有了Tag的概念。可以通过Tag对相同消息进行归类,这样用户就可以只订阅一部分的消息了(只订阅部分Tag)

比如:有一个Topic叫做‘发货’,下游消费者希望可以根据货源进行不同的处理,可以通过‘tag=北京’以及‘tag=上海’来区分不同的发货源。下游消费者,可以单独订阅‘上海’的货物,或者‘tag=上海|江苏|浙江’来订阅这三个地区的货物,还可以‘tag=*’来订阅全国的货物。

发送了某个消息,但是希望在后台很方便的搜索到,就要通过key了。可以根据key搜索到所有相关的Message。可以认为RocketMQ内部维护了一个非常大的HashMap,key就是这个key,value就是Message,如果出现Hash冲突就用链表来报错对应关系。

RocketMQ概念篇

提问 :

每次申请Topic好烦啊,索性申请个叫tp_all的topic算了,然后内部用tag来区分岂不是美滋滋,这样很好吧?

我是生产者,我可以任意修改发送的消息体?

一个topic里面有什么tag我又不知道,索性消费所有消息,内部判断是不是我要的消息内容不就好?

生产者:针对某一个Topic制造数据,把数据塞到queue里。

简单点: 发消息的

管理消息的时候,我们肯定会遇见这个问题,某个消息谁发的?RocketMQ把发送者的身份抽象成了Producer Group,就是[ 发送组 ]。

简单点:这个东西命名成项目名就行, 相同Producer Group保持相同业务行为

提问 :

我的项目要发送10个Topic,定义相同的Producer Group可以么?

有一个Topic,可以多个Producer Group一起生产么?

2台机器有相同的Producer Group,机器1发送tp1、 机器2发送tp2这样有问题么?

一个Topic有Producer Group:‘test_group’ 两个项目都用了,但是A项目发送的tag叫A,B项目发送的消息Tag是B,请问有问题么

消费者:把queue里面的消息拿出来用

消费行为:如何处理通过 Topic+Tag定位的 消息

重点!重点!重点! 来了,直接翻译是‘消费组’

一个RocketMQ集群是如何区分 消费者是谁 的呢?就是通过消费组, 相同消费组的机器,MQ认为消费行为是一致的 。业务上一定要保证相同消费组有相同的消费行为。对于不同的消费组名字,RocketMQ就认为是个不同消费者了。如果修改了消费组的名字,那就是新的消费者,就会按照新的消费组的消费进度处理消费。

消息那么多,项目都重启无数次了,RocketMQ是如何记录消息消费到什么地方了呢?

也是通过消费组,RocketMQ内部会维护一个关系,记录Consumer Group和消费进度之间的联系。所以,如果把Consumer Group的名字改掉是可能重新消费之前的所有数据的(视初始消费位置而定)

提问 :

两个服务,服务A和服务B,消费相同集群的 相同Topic ,既然服务不一样,那么就算是定义了 相同的consumer group 也无所谓吧?

常见问题: 消费组名字命名的不合理,上线后悄悄改回来行不行?

不小心用了别人的消费组名,悄悄改回来重新上线也没什么问题吧?

常见问题: 一个服务有消费组A消费3个Topic,有一次上线,希望消费4个Topic。对于新消费的消息希望可以灰度验证一段时间。请问有问题么?

消息队列主要的功能是模块结偶,同步转异步和削峰,必然会出现生产非常快但是消费慢这种事情,比如生产的速度是100000/s但是消费速度是1/s,这个时候就叫做消息积压或者消费延迟(Delay)。理论上RockeMQ对于这种场景有比较好的适应能力,原理大致这样:正常的生产消费都是操作内存数据,所以比较快。但是如果积压非常多,内存明显扛不住了,则降级为生产消费的是磁盘数据,直接操作磁盘。磁盘肯定比内存的速度慢很多啦。

这个时候整个集群的处理能力就拉低了。所以最好生产和消费能力不要相差太多,即便相差很多,积压也应该在有限的时间内处理完毕。

目前比较容易出现消息积压的情况有:

1.新消费组上线(消费历史消息)

2.消费能力弱

3.生产洪峰(比如for循环发消息,job发消息)

由于RocketMQ开源版本没有多租户隔离,所以公共集群使用的过程中会有相互影响发生,鉴于此大家在上线前还是要合理评估自己的系统能力。

提问 :

消费延迟太多了,业务上接受丢弃一部分消息,如何操作呢?

消息的处理线程太少了,想加大处理线程怎么办?

自己搞个线程池处理消息是不是很赞?

这个概念比较尴尬。上面说的Producer Group和Consumer Group都是逻辑概念。如果需要连接 多集群 ,就需要物理上进行区分(Instance Name)。

一个Instance Name对应一个连接,默认的值是本机ip@进程号。连接多集群的时候务必修改这个值。

提问 :

要向两个RocketMQ集群生产数据,只需要设置不同的Producer Group即可?

要从两个RocketMQ集群消费数据,只需要设置不同的Consumer Group即可?

鹏仔微信 15129739599 鹏仔QQ344225443 鹏仔前端 pjxi.com 共享博客 sharedbk.com

免责声明:我们致力于保护作者版权,注重分享,当前被刊用文章因无法核实真实出处,未能及时与作者取得联系,或有版权异议的,请联系管理员,我们会立即处理! 部分文章是来自自研大数据AI进行生成,内容摘自(百度百科,百度知道,头条百科,中国民法典,刑法,牛津词典,新华词典,汉语词典,国家院校,科普平台)等数据,内容仅供学习参考,不准确地方联系删除处理!邮箱:344225443@qq.com)

图片声明:本站部分配图来自网络。本站只作为美观性配图使用,无任何非法侵犯第三方意图,一切解释权归图片著作权方,本站不承担任何责任。如有恶意碰瓷者,必当奉陪到底严惩不贷!

内容声明:本文中引用的各种信息及资料(包括但不限于文字、数据、图表及超链接等)均来源于该信息及资料的相关主体(包括但不限于公司、媒体、协会等机构)的官方网站或公开发表的信息。部分内容参考包括:(百度百科,百度知道,头条百科,中国民法典,刑法,牛津词典,新华词典,汉语词典,国家院校,科普平台)等数据,内容仅供参考使用,不准确地方联系删除处理!本站为非盈利性质站点,本着为中国教育事业出一份力,发布内容不收取任何费用也不接任何广告!)