球友好，欢迎来到本章，我们一起来揭开 Rocketmq 的神秘面纱。

本章知识点会很多，可以说是超级干货了，大家端起小板凳，学起来。

初识 MQ

在微服务架构下，一个业务将会被拆成多个微服务，各个服务间相互通信形成完整功能，那么大家清楚系统间都是如何通信协作的吗？

不卖关子啦，系统间的通信协作通常有 2 种：

• HTTP/RPC 通信
• 消息通信

HTTP/RPC 通信是微服务系统的标配，不是今天的主角，今天的主角是消息通信，而主角中的主角是消息通信中叱咤风云的 RocketMQ。

什么是消息队列

为了大家更好理解消息队列以及 RocketMQ，我将会通过好朋友鸡毛开餐馆的故事来展开。

“老板，我的酸菜鱼好了没，都等 20 分钟了！”坐在角落那桌的长腿女生极为不满的吼道。

“就快了，稍等！”鸡毛一边用挂在脖子上的毛巾擦汗，一边看着满桌子的订单，活了大半辈子也没见像今天生意这么好的样子。

鸡毛是个大厂退役的 Java 开发，拿着被裁的几个月赔偿费和多年来做牛马的一点积蓄，回老家开了个破烂的餐馆。餐馆是个收垃圾的铺子改造而来，一开始顾客总觉得餐馆有股难闻的气味，所以来的人基本保持在个位数左右。

这几天鸡毛搞了个促销，有些好转，但也不愠不火，今天像发了神经私的，不知道哪儿来的这么多人。

顾客点单，写在纸条上，然后直接丢给鸡毛，鸡毛放在一个桌子上，就开始炒菜。这个流程在人少的时候当然没问题，鸡毛甚至还有时间刷一会美女视频，但人一多，就手足无措了。

鸡毛看着桌子上堆积的订单，想起这不正是消息队列的场景吗？订单是消息，顾客是生产消息的生产者，而鸡毛是订单的消费者。

整个消息队列组件其实就三部分：

• 生产者：生产消息的一方，比如顾客就是生产者
• 消息队列：就是消息的「篮子」，用来存放消息，比如鸡毛餐馆的桌子
• 消费者：专门负责消息的一方，比如鸡毛

在分布式微服务系统中，消息队列在系统中扮演者很重要的角色，如果说整个系统是皇帝，消息队列至少是三品以上的大臣了。主要有解耦、异步处理、削峰等作用。

微信搜索《苍何》或者微信扫下⾯的⼆维码，关注后回复《mq》即可获取最新的 PDF 版本（我会不定期更新）。

常用的消息队列有哪些？

下面一个表格整理了常用的消息队列以及性能对比：

我们不难得出结论：

• 如果是大数据领域的实时计算、日志采集等场景，就用 kafka
• 对时效性有要求，且不关心底层情况，用 RabbitMQ 就可以
• 国内的大部分项目，特别是微服务项目，就用阿里的 RocketMQ 就好了，有丰富的教程且是阿里出品，经历过双十一这种大促，肯定是没问题的。

RocketMQ 是什么？

终于到我们的主角出场啦🎉， RocketMQ 是阿里开源的消息中间件，具有**高性能、高可靠、高实时、分布式 **的特点，底层是用 Java 语言开发的分布式组件。2016 年成为 Apache 的顶级项目，在阿里内部经历了多年的双十一的拷打，主打一个能抗能打。

• 官网地址：https://rocketmq.apache.org/
• 开源地址：https://github.com/apache/rocketmq

不得不说，官网做的还是很炫酷的！下面是一张底层架构图：

图中不难看出， RocketMQ 主要有以下 4 个部分：

生产者 Producer

这哥们是个发布消息的角色。Producer 通过 MQ 的负载均衡模块选择相应的 Broker 集群队列进行消息投递，投递的过程支持快速失败和重试。

消费者 Consumer

这哥们是消息消费的角色：

• 支持推（push）和拉（pull）两种模式对消息进行消费。
• 支持集群方式和广播方式的消费。
• 提供实时消息订阅机制，可以满足大多数用户的需求。

名字服务器 NameServer

NameServer 是 RocketMQ 中的注册中心，支持 Topic、Broker 的动态注册与发现。

主要包括两个功能：

• Broker管理： NameServer接受Broker集群的注册信息并且保存下来作为路由信息的基本数据，并提供心跳检测机制，检查Broker是否存活。
• 路由信息管理： 每个NameServer将保存关于 Broker 集群的整个路由信息和用于客户端查询的队列信息。Producer和Consumer通过NameServer可以知道整个Broker集群的路由信息，从而进行消息的投递和消费。

NameServer通常会有多个实例部署，各实例间相互不进行信息通讯。Broker向每一台NameServer注册自己的路由信息，每个NameServer实例上都保存一份完整的路由信息。当某个NameServer因某种原因下线了，客户端仍然可以向其它NameServer获取路由信息。

代理服务器 Broker

Broker 主要负责消息的存储、投递和查询以及服务高可用保证。

• NameServer几乎无状态节点，因此可集群部署，节点之间无任何信息同步。
• Broker部署相对复杂。在 Master-Slave 架构中，Broker 分为 Master 与 Slave。一个Master可以对应多个Slave，但是一个Slave只能对应一个Master。Master 与 Slave 的对应关系通过指定相同的BrokerName，不同的BrokerId 来定义，BrokerId为0表示Master，非0表示Slave。Master也可以部署多个。

做个总结吧：

• 每个 Broker 与 NameServer 集群中的所有节点建立长连接，定时注册 Topic 信息到所有 NameServer。
• Producer 与 NameServer 集群中的其中一个节点建立长连接，定期从 NameServer 获取 Topic 路由信息，并向提供 Topic 服务的 Master 建立长连接，且定时向 Master 发送心跳。Producer 完全无状态。
• Consumer 与 NameServer 集群中的其中一个节点建立长连接，定期从 NameServer 获取 Topic 路由信息，并向提供 Topic 服务的 Master、Slave 建立长连接，且定时向 Master、Slave发送心跳。Consumer 既可以从 Master 订阅消息，也可以从Slave订阅消息。

主题Topic详解

上一节已经介绍了消息队列的基础概念、常用的消息队列框架以及 RocketMQ 的整体设计架构。

还没看过或者已经忘记的小伙伴可以看看上一篇哈。

我们只有先建立整体的框架和初步的概念，才能更加深入的学习他的技术细节。（学任何技术或知识都是如此，ps：这可不是苍何说的，书本上都这么说。）

上一篇中讲了 RocketMQ 的四大核心概念，也即生产者、消费者、broker、nameserver。作为消息队列的宠儿，可不止这 4 个概念，还有其他比较重要的概念和模型，只有充分理解了这些核心的理念，才能更好的理解和使用 RocketMQ。

好，你现在先闭上眼，看能想到哪些概念或者名词呢？

我想你第一个想到的应该就是 topic 了（反正我是最先想到了他），OK，那我们这一篇的主题也就是主题 topic，当然此主题非彼主题，不过概念上相差不大，这就是中文的强大之处了。

微信搜索《苍何》或者微信扫下⾯的⼆维码，关注后回复《mq》即可获取最新的 PDF 版本（我会不定期更新）。

Topic 概念定义

我们先来看看官方定义：

主题是 RocketMQ 中消息传输和存储的顶层容器，用于标识同一类业务逻辑的消息。

我的理解主题就是消息的分类，比如上一篇说到的鸡毛的餐厅中订单消息是一类主题消息，顾客下单的消息都往订单消息这个主题里面发，那么同样鸡鸡毛的朋友狗毛约他去打球，就属于打球主题消息，依此类推，不难发现，主题消息的分类其实是受业务所决定的，你要发什么业务消息最好单独是一个 Topic 主题，大家相互之间互不干扰。

现如今垃圾都要做好干湿分类，消息可不能一个 topic 干到底哦。

Topic 主要有 2 大核心作用：

• 定义数据的分类隔离：将不同业务类型的数据拆分到不同的主题中管理，通过主题实现存储的隔离性和订阅隔离性。
• 定义数据的身份和权限：RocketMQ 的消息本身是匿名无身份的，同一分类的消息使用相同的主题来做身份识别和权限管理。

模型关系

在 RocketMQ 中主题 Topic 所处的流程和位置如下：

其实 Topic 是一个逻辑的概念，并不是一个实际的消息容器，每个 Topic 包含多个消息队列（Queue），队列是消息的实际存储单元，每个队列独立存储消息，队列数量在创建 Topic 时可以配置，后续也可以动态调整。

生产者发送消息时，消息会根据一定策略分配到不同的队列中，常见的分配策略包括轮询（Round Robin）和哈希（Hashing）。消费者消费消息时，同样是从这些队列中拉取消息。

Topic 属性和配置

Topic 主要有以下内部属性，并且可以用来配置。

主题名称

主题名称是在创建主题的时候，我们自己定义的，主要是用于标识主题，名称需要满足集群内唯一。虽然理论上可以按照自己所想随便定义，但官方还是苦口婆心的给了做了我们一些限制，看看也无妨：

Topic 命名应该尽量使用简短、常用的字符，避免使用特殊字符。特殊字符会导致系统解析出现异常，字符过长可能会导致消息收发被拒绝。