关键词：
参考技术A 白话系列文章讲述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冲突就用链表来报错对应关系。
提问 ：
每次申请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即可？
rocketmq—高可用集群篇
一、集群的模式首先要明确两个概念:Master:主节点，可以进行读和写操作。Slave:从节点，只可以读，不进行写操作。也就是Producer只能和Master角色的Broker连接写入消息；Consumer可以连接Master角色的Broker，也可以... 查看详情
rocketmq概念整理
MapedFile和文件一对一关系MapedFileQueue管理mapedFile，新建、获取、删除mapedFile将消息写入文件 查看详情
rocketmq---核心概念特性使用等
对于RocketMQ而言，感觉官方提供的东西还是可以的：https://github.com/apache/rocketmq/tree/master/docs/cn 查看详情
rocketmq源码解析-store篇(代码片段)
这一篇我们主要来梳理下`RocketMQ`消息的存储，这一块的逻辑主要是在`rocketmq-store`模块我们对于这个模块的逻辑梳理主要是借助这些测试类来debug分析主要是MappedFileQueue、MappedFile、CommitLog、MessageStore、ConsumeQueue... 查看详情
（转）rocketmq源码学习--消息存储篇
...tp://www.tuicool.com/articles/umQfMzA1.序言今天来和大家探讨一下RocketMQ在消息存储方面所作出的努力，在介绍RocketMQ的存储模型之前，可以先探讨一下MQ的存储模型选择。2.MQ的存储模型选择个人看来，从MQ的类型来看，存储模型分两种：... 查看详情
rocketmq源码解析-nameserver篇(代码片段)
...NameServer是怎样保存topic、broker、cluster这些信息的。一、rocketmq-namesrv模块基本介绍可以看到在它的源码中，namesrv其只有这些类(当然也有使用rocketMQ源码的其他的模块)。NamesrvController完成netty连接的初始化，然后DefaultReque... 查看详情
rocketmq源码学习--消息存储篇
1.序言今天来和大家探讨一下RocketMQ在消息存储方面所作出的努力，在介绍RocketMQ的存储模型之前，可以先探讨一下MQ的存储模型选择。2.MQ的存储模型选择个人看来，从MQ的类型来看，存储模型分两种：需要持久化（ActiveMQ,RabbitMQ,K... 查看详情
rocketmq事务消息篇之事务消息的使用(代码片段)
前言在RocketMQ事务消息篇（一）之事务消息的介绍里对RocketMQ的事务消息作了相关说明，本文提供一些基本的开发示例。java示例依赖<dependencies><dependency><groupId>org.apache.rocketmq</groupId><artifactId>ro 查看详情
rocketmq的消息架构模型以及核心概念
详细介绍了RocketMQ的基本概念，以及消息模型。文章目录1基本概念2消息模型3消费位移RocketMQ是一个纯Java开发的分布式的开源消息中间件，具有高性能、高可靠、高实时、分布式等特点。RocketMQ在阿里内部经历了多次双十... 查看详情
rocketmq事务消息篇之事务消息源码分析(代码片段)
前言RocketMQ事务消息篇（一）之事务消息的介绍RocketMQ事务消息篇（二）之事务消息的使用本文继前两篇对事务消息源码进行分析。事务消息处理基本流程在介绍事务消息的时候，画了一个简单的流程图说明事... 查看详情
消息队列学习--rocketmq概念了解
今天来学习一款国产的消息中间件：RocketMQ。RocketMQ最初是由阿里团队研发，具有高性能、低延迟和高可靠等特性。一、概述 先来对RocketMQ有一个宏观的了解灵活的可扩展性。天然支持集群，四大核心组件（NameSe... 查看详情
消息队列学习--rocketmq概念了解
今天来学习一款国产的消息中间件：RocketMQ。RocketMQ最初是由阿里团队研发，具有高性能、低延迟和高可靠等特性。一、概述 先来对RocketMQ有一个宏观的了解灵活的可扩展性。天然支持集群，四大核心组件（NameSe... 查看详情
rocketmq源码篇-生产者获取topic路由信息
参考技术ADefaultMQProducerImpl#tryToFindTopicPublishInfoMQClientInstance#updateTopicRouteInfoFromNameServerMQClientAPIImpl#getTopicRouteInfoFromNameServerNettyRemotingClient#invokeSyncDefaultRequestProcessor#processRequestDefaultRequestProcessor#getRouteInfoByTopic 查看详情
rocketmq架构原理及名词概念
这节主要讲述RocketMQ的整体架构，和常用术语解释。当我们接触一个新东西的时候，一定要知道他的原理，只有知道原理之后，才会产生问题。只有带着问题去读源码才会事半功倍。首先盗用官方的一张图片：（官方地址：http://... 查看详情
rocketmq中的基本概念
文章目录基本概念1消息模型（MessageModel）2消息生产者（Producer）3消息消费者（Consumer）4主题（Topic）5代理服务器（BrokerServer）6名字服务（NameServer）7拉取式消费 查看详情
rocketmq源码解析-store篇(代码片段)
这一篇我们主要来梳理下`RocketMQ`消息的存储，这一块的逻辑主要是在`rocketmq-store`模块我们对于这个模块的逻辑梳理主要是借助这些测试类来debug分析主要是MappedFileQueue、MappedFile、CommitLog、MessageStore、ConsumeQueue... 查看详情
一次rocketmq进程自动退出排查经验分享（实战篇）(代码片段)
1、背景公司一个RocketMQ集群由4主4从组成，突然其中3台服务器“竟然”在同一时间下线，其监控显示如下：依次查看三台机器的监控图形，时间戳几乎完美“吻合”，不可思议吧。2、故障分析出现问题，先二话不说，马上重启... 查看详情
rocketmq源码解析-nameserver篇(代码片段)
...NameServer是怎样保存topic、broker、cluster这些信息的。一、rocketmq-namesrv模块基本介绍可以看到在它的源码中，namesrv其只有这些类(当然也有使用rocketMQ源码的其他的模块)。NamesrvController完成netty连接的初始化，然后DefaultReque... 查看详情