RocketMQ基本概念

Charge8

已于 2022-05-30 23:32:13 修改

阅读量907

点赞数

分类专栏： # RocketMQ 文章标签： RocketMQ基本概念

于 2022-05-30 23:28:07 首次发布

本文链接：https://blog.csdn.net/qq_42402854/article/details/125055989

版权

RocketMQ 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

RocketMQ是阿里巴巴开源的一个消息中间件，2016年开源后捐赠给Apache，现在是Apache的一个顶级项目。
目前 RocketMQ在阿里云上也有一个付费的商业版本，商业版本集成了阿里内部一些更深层次的功能及运维定制。

参考文章：这篇参考文章对 RocketMQ 简介很详细，本文内容转载与它。

RocketMQ 简介：https://www.jianshu.com/p/db11a702d49f

1、RocketMQ物理部署架构

在这里插入图片描述

执行流程：

启动 NameServer，NameServer 启动后监听端口，等待 Broker、Producer、Consumer 连上来，相当于一个路由控制中心。
Broker 启动，跟所有的 NameServer 保持长连接，定时发送心跳包。心跳包中包含当前 Broker 信息(IP+端口等)以及存储所有Topic信息。注册成功后，NameServer 集群中就有 Topic 跟 Broke r的映射关系。
收发消息前，先创建 Topic，创建 Topic 时需要指定该 Topic 要存储在哪些 Broker 上，也可以在发送消息时自动创建 Topic。
Producer 发送消息，启动时先跟 NameServer 集群中的其中一台建立长连接，并从 NameServer 中获取当前发送的 Topic 存在哪些 Broker 上，轮询从队列列表中选择一个队列，然后与队列所在的 Broker 建立长连接从而向 Broker 发消息。
Consumer 跟 Producer 类似，跟其中一台 NameServer 建立长连接，获取当前订阅 Topic 存在哪些 Broker 上，然后直接跟 Broker 建立连接通道，开始消费消息。

RocketMQ 需要先启动NameServer，再启动 RocketMQ 中的 Broker。

2、基本概念

关于RocketMQ的基本概念，可以查看 Apache RocketMQ中文文档：https://github.com/apache/rocketmq/blob/master/docs/cn/concept.md

下面整理一部分：

消息模型（Message Mode）

RocketMQ 主要由 Producer、Broker、Consumer 三部分组成，其中 Producer 负责生产消息，Consumer 负责消费消息，Broker 负责存储消息。Broker 在实际部署过程中对应一台服务器，每个 Broker 可以存储多个Topic的消息，每个 Topic 的消息也可以分片存储于不同的 Broker。
MessageQueue 用于存储消息的物理地址，每个 Topic 中的消息地址存储于多个 Message Queue 中。ConsumerGroup 由多个 Consumer 实例构成。

NameServer

NameServer：管理Broker；提供轻量级的 Broker路由服务。

NameServer 是一个无状态节点，可集群部署，节点之间无任何信息同步。

NameServer可以理解为是整个 RocketMQ 的“大脑”，它是 RocketMQ 的服务注册中心。

Broker 在启动时向所有 NameServer 注册（主要是服务器地址等），生产者在发送消息之前先从 NameServer 获取 Broker 服务器地址列表（消费者一样），然后根据负载均衡算法从列表中选择一台服务器进行消息发送。

NameServer与每台 Broker 服务保持长连接，并间隔 30S 检查 Broker 是否存活，如果检测到 Broker 宕机，则从路由注册表中将其移除。这样就可以实现 RocketMQ 的高可用。

主机(Broker)

主机(Broker)：暂存和传输消息；实际处理消息存储、转发等服务的核心组件。

Broker 部署相对复杂，Broker 分为 Master 和 Slave，一个 Master 可以对应多个 Slave，但是一个Slave 只能对应一个 Master，Master 与 Slave 的对应关系通过指定相同的 BrokerName，不同的BrokerId 来定义，BrokerId 为 0 表示为 Master ，非 0 表示 Slave 。Master 也可以部署多个。

每个 Broker 与 NameServer 集群中的所有节点建立长连接，定时注册 Topic 信息到所有 NameServer。

消息(Message)

消息(Message)：生产或消费的数据，对于 RocketMQ 来说，消息就是字节数组。

生产者(Producer)

生产者(Producer)：消息的发送者；也称为消息发布者，负责生产并发送消息至 RocketMQ。通常是业务系统中的一个功能模块。

消费者(Consumer)

消费者(Consumer)：也称为消息订阅者，负责从 RocketMQ 接收并消费消息。通常也是业务系统中的一个功能模块。

分组(Group)：

生产者：
标识发送同一类消息的 Producer，通常发送逻辑一致。发送普通消息的时候，仅标识使用，并无特别用处。
主要作用用于事务消息：
（事务消息中如果某条发送某条消息的producer-A宕机，使得事务消息一直处于PREPARED状态并超时，则broker会回查同一个group的其它producer，确认这条消息应该 commit 还是 rollback）
消费者：
标识一类 Consumer 的集合名称，这类 Consumer 通常消费一类消息，且消费逻辑一致。
同一个 Consumer Group 下的各个实例将共同消费 topic的消息，起到负载均衡的作用。
消费进度以 Consumer Group 为粒度管理，不同 Consumer Group 之间消费进度彼此不受影响，即消息 A 被 Consumer Group1 消费过，也会再给 ConsumerGroup2 消费。

主题(Topic)

主题(Topic)：区分消息的种类，标识一类消息的逻辑名字，消息的逻辑管理单位。无论消息生产还是消费，都需要指定 Topic。

主题区分消息的种类：

一个发送者可以发送消息给一个或者多个 Topic；
一个消息的接收者可以订阅一个或者多个 Topic 消息。

标签(Tag)

RocketMQ 支持在发送时给 topic 的消息设置 tag，用于同一主题下区分不同类型的消息。

来自同一业务单元的消息，可以根据不同业务目的在同一主题下设置不同标签。

标签能够有效地保持代码的清晰度和连贯性，并优化 RocketMQ 提供的查询系统。消费者可以根据Tag实现对不同子主题的不同消费逻辑，实现更好的扩展性。

消息队列(Message Queue)

消息队列(Message Queue)：简称 Queue 或 Q，消息物理管理单位。用于并行发送和接收消息，相当于是Topic的分区。

一个 Topic 将有若干个 Q。若一个 Topic 创建在不同的 Broker，则不同的 broker 上都有若干 Q，消息将物理地存储落在不同 Broker 结点上，具有水平扩展的能力。

无论生产者还是消费者，实际的生产和消费都是针对 Q 级别。

例如：

Producer 发送消息的时候，会预先选择（默认轮询）好该 Topic 下面的某一条 Q发送；
Consumer 消费的时候也会负载均衡地分配若干个 Q，只拉取对应 Q 的消息。

注意：
在 RocketMQ 中，所有消息队列都是持久化的，长度无限的数据结构，所谓长度无限是指队列中的每个存储单元都是定长，访问其中的存储单元使用Offset来访问，offset 为 java long 类型，64 位，理论上在 100 年内不会溢出，所以认为为是长度无限，另外队列中只保存最近几天的数据，之前的数据会按照过期时间来删除。也可以认为Message Queue是一个长度无限的数组，offset 就是下标。

偏移量(Offset)

RocketMQ 中，有很多 offset 的概念。

一般我们只关心暴露到客户端的 offset。不指定的话，就是指 Message Queue 下面的 offset。

Message queue 是无限长的数组。一条消息进来下标就会涨 1，而这个数组的下标就是 offset。

Message queue 中的 max offset 表示消息的最大 offset.，Consumer offset 可以理解为标记 Consumer Group 在一条逻辑 Message Queue 上，消息消费到哪里即消费进度。

在这里插入图片描述

3、RocketMQ 消费模式

RocketMQ 消息订阅有两种模式：Push模式和 Pull模式。

3.1 Push 模式

Push模式（MQPushConsumer）：即MQServer主动向消费端推送；

优点：就是实时性高。

缺点：在于消费端的处理能力有限，当瞬间推送很多消息给消费端时，容易造成消费端的消息积压，严重时会压垮客户端。

3.2 Pull 模式

Pull模式（MQPullConsumer）：即消费端在需要时，主动到MQ Server拉取。但在具体实现时，Push和Pull模式本质都是采用消费端主动拉取的方式，即 Consumer 轮询从 Broker 拉取消息。

优点：主动权掌握在消费端自己手中，根据自己的处理能力量力而行。

缺点：如何控制 Pull 的频率，定时间隔太久影响时效性，间隔太短担心做太多“无用功”浪费资源。比较折中的办法就是长轮询。

3.3 Push 与 Pull 区别：

Push 方式里，Consumer 把长轮询的动作封装了，并注册 MessageListener监听器，取到消息后，唤醒MessageListener的consumeMessage()来消费，对用户而言，感觉消息是被推送过来的。

Pull 方式里，取消息的过程需要用户自己主动调用，首先通过打算消费的 Topic 拿到 MessageQueue 的集合，遍历MessageQueue集合，然后针对每个MessageQueue批量取消息，一次取完后，记录该队列下一次要取的开始offset，直到取完了，再换另一个MessageQueue。
RocketMQ 使用长轮询机制来模拟 Push 效果，算是兼顾了二者的优点。