导读

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

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

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

---

MQ

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

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

---

Topic

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

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

就是通过topic。

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

提问：

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

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

Topic名字起的越酷炫越好？

---

Queue

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

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

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

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

提问：

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

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

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

---

Message

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

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

---

Tag

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

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

---

Key

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

提问：

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

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

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

---

Producer

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

简单点：发消息的

Producer Group

管理消息的时候，我们肯定会遇见这个问题，某个消息谁发的？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，请问有问题么？？

---

Consumer

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

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

Consumer Group

重点！重点！重点！来了，直接翻译是‘消费组’

一个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开源版本没有多租户隔离，所以公共集群使用的过程中会有相互影响发生，鉴于此大家在上线前还是要合理评估自己的系统能力。

提问：

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

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

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

---

InstanceName

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

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

提问：

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

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