RocketMQ 源码启动流程（简写版）

清河大善人

已于 2024-12-06 13:54:00 修改

阅读量227

点赞数

分类专栏： Java精进文章标签： java

于 2023-01-06 14:43:17 首次发布

本文链接：https://blog.csdn.net/weixin_45525272/article/details/128578169

版权

Java精进专栏收录该内容

33 篇文章

订阅专栏

文章目录

- RocketMQ 源码启动流程

RocketMQ 源码启动流程

1. NameServer

1.1 架构设计

NameServer 是 RocketMQ 集群中的一个关键组件，主要负责管理和维护 Broker 的路由信息。它是 RocketMQ 的 “服务注册与发现” 系统，确保消息的传递能够快速、可靠地找到合适的 Broker。其架构设计强调高可用、低延迟、易于扩展，主要包括以下几个模块：

路由管理：存储并维护 Broker 的路由信息，负责 Broker 的注册和发现。
心跳机制：通过定时发送和接收心跳包来监控 Broker 的健康状态。
负载均衡：确保多个 Broker 之间的负载均衡，从而实现高效的消息分发和系统的可靠性。

1.2 启动流程

1.2.1 步骤一：加载配置

NameServer 启动时会首先加载配置文件（例如 conf/namesrv.conf）。这些配置项包括：

网络配置（如端口号、绑定的IP等）
存储路径（如存储路由信息的内存或磁盘位置）
线程池配置（如接入的客户端数、消息处理线程数等）

1.2.2 步骤二：初始化服务

在初始化过程中，NameServer 主要做以下工作：

创建网络服务：初始化与 Broker 之间通信的网络服务，通常使用 Netty 作为底层通信框架。
启动监听服务：等待 Broker、Producer 和 Consumer 客户端的连接请求，确保客户端可以与 NameServer 建立通信。

1.2.3 步骤三：启动路由管理

在此阶段，NameServer 会初始化和管理路由信息，同时启动心跳管理模块，准备接收来自 Broker 和客户端的路由请求。它会将 Broker 注册信息加载到内存中，并保持路由信息的实时更新。

1.2.4 启动流程总结

加载配置：读取配置文件，完成相关配置项的初始化。
初始化服务：启动与 Broker 和客户端的通信服务。
启动路由管理与心跳机制：初始化路由信息，启动心跳监控，保持与 Broker 的连接。

1.3 路由管理

1.3.1 路由元信息

路由元信息指的是保存关于 Broker 的关键信息，它的组成包括：

Broker 信息：包括 Broker 的名称、地址、端口号、消息队列数量等。
队列信息：每个 Broker 上承载的各个消息队列的详细信息。
负载信息：每个 Broker 的负载情况，帮助生产者选择合适的 Broker 进行消息发送。

1.3.2 路由注册

1）发送心跳包

每个 Broker 会周期性地向 NameServer 发送心跳包，心跳包的内容通常包括：
- Broker 的健康状态。
- Broker 上的主题列表和消息队列信息。

2）处理心跳包

NameServer 在接收到 Broker 的心跳包后，会验证包内的信息，然后更新自己内部存储的路由信息。通过心跳包的机制，NameServer 可以了解 Broker 是否存活以及它的负载情况。

RocketMQ NameServer Broker 注册过程总结：

Broker 注册：Broker 启动时会向 NameServer 注册自己的信息，包括其所在的主机地址、端口号、队列数等。
心跳维护：通过周期性发送心跳包来保持与 NameServer 的连接，NameServer 会根据心跳包的内容更新路由信息。

1.3.3 路由删除

当一个 Broker 停止或退出时，NameServer 会及时删除该 Broker 的路由信息，确保系统不会尝试向一个已下线的 Broker 发送消息。Producer 和 Consumer 会自动从路由信息中去除该 Broker 的信息。

1.3.4 路由发现

Producer 和 Consumer 客户端通过访问 NameServer 获取最新的路由信息。基于最新的路由信息，客户端可以选择合适的 Broker 来发送或接收消息。

1.4 小结

NameServer 的功能：它的核心任务是管理和提供 Broker 的路由信息，确保消息能在各个 Broker 之间高效且正确地传递。
路由管理：通过心跳机制、路由注册、路由删除和路由发现来维护 Broker 的路由信息，确保生产者和消费者能够获取到最新且有效的路由数据。

NameServer 在 RocketMQ 中的角色非常关键，它是 Broker 的“目录服务”，让系统中的各个组件能够迅速找到其他组件并进行高效的通信。

2. Producer

2.1 Producer 类的结构关系

Producer 是消息生产者，负责将消息发送到 Broker。它封装了消息发送的核心逻辑，包括消息验证、路由查找、消息选择等。其主要结构包括：

Producer实例：每个 Producer 实例代表一个消息发送的客户端。可以通过配置文件或代码中的构造函数初始化。
发送消息的队列：Producer 将消息发送到特定的队列中，每个队列由一个或多个 Broker 承载。
路由信息管理：Producer 需要根据从 NameServer 获取的路由信息选择合适的 Broker 来发送消息。

2.2 启动流程

2.2.1 步骤一：初始化 Producer

Producer 在启动时，会通过构造函数或配置文件初始化所需的参数，包括消息的主题、消息发送方式、连接参数等。

2.2.2 步骤二：获取路由信息

Producer 启动后，会通过 NameServer 获取 Broker 的路由信息。此信息包含了各个 Broker 的地址、队列信息等。

2.2.3 步骤三：建立与 Broker 的连接

Producer 会与 Broker 建立 TCP 连接，通常通过 Netty 来进行高效的网络通信。通过与 Broker 的连接，Producer 能够将消息发送到选定的队列中。

2.2.4 步骤四：准备消息并发送

Producer 准备好要发送的消息后，根据路由信息选择合适的队列，并通过已建立的连接将消息发送到 Broker。

2.3 消息发送

验证消息：
- 在发送消息之前，Producer 会先验证消息的有效性。这包括检查消息体的大小、消息主题是否存在、消息格式是否正确等。如果验证失败，消息将不会被发送。
查找路由：
- Producer 通过访问 NameServer 获取当前所有 Broker 的路由信息。路由信息包含了 Broker 的地址、负载信息、队列信息等，Producer 根据这些信息选择合适的 Broker 来发送消息。
选择队列：
- 根据路由信息，Producer 会选择合适的队列进行消息的发送。如果有多个队列可供选择，Producer 会根据负载均衡策略选择队列，以确保消息的均匀分布，避免某些队列过载。
发送消息：
- 选定队列后，Producer 会将消息通过 TCP 连接发送到 Broker。消息发送成功后，Broker 会将消息存储，并等待消费者的拉取。

2.4 批量消息发送

Producer 支持批量消息发送，这样可以提高消息发送的效率，减少网络延迟。批量消息发送的流程与单条消息发送类似，只是在发送之前，将多个消息打包成一个批次。批量发送可以减少 TCP 连接的建立频率，同时提高吞吐量。

在批量发送过程中，Producer 会先将多条消息合并成一个批量消息包，然后将整个包发送给 Broker。
Broker 在接收到批量消息后，会对消息进行拆分，并将每个消息分别存储到对应的队列中。

这种方式适用于发送大量消息的场景，能够显著提升消息的发送效率。

2.5 总结：

Producer 在 RocketMQ 中是负责发送消息的核心角色，通过与 NameServer 和 Broker 的协作，确保消息能够高效、可靠地发送到指定的队列中。通过验证消息、查找路由、选择队列等步骤，Producer 可以保证消息的正确性和负载均衡。批量消息发送提供了更高的性能，适用于大规模消息发送的场景。

3. 消息存储（Broker核心）

3.1 消息存储核心类

RocketMQ 的消息存储模块是 Broker 核心的一部分，负责持久化存储和高效读取消息。其核心类包括：

MappedFileQueue：用于管理消息存储队列。一个 MappedFileQueue 由多个 MappedFile 组成，它管理存储文件的创建、删除和回收。
MappedFile：实际的存储文件。它使用内存映射文件（MappedByteBuffer）进行存储，提高了文件读写的效率。
TransientStorePool：消息存储池，负责管理内存映射文件的缓存池，减少频繁的内存分配和释放。

3.2 消息存储流程

消息存储的基本流程如下：

Producer发送消息后：消息会通过网络传输到 Broker。
Broker将消息存储到磁盘：Broker 将收到的消息存入存储文件。
内存映射文件：消息通过 MappedByteBuffer 写入到内存映射文件中，确保高效的存储。
管理和索引：消息会通过消息消费队列和索引文件进行管理，以便后续消费和检索。

3.3 存储文件

存储文件是 RocketMQ 消息持久化的基础。RocketMQ 使用内存映射文件（MappedFile）来存储消息，这样可以减少磁盘 I/O 操作，提高存取效率。存储文件按需进行分配，并且会在文件达到一定大小后自动切换到新的文件。存储文件根据配置自动进行回收，以确保磁盘空间的有效利用。

3.4 存储文件内存映射

RocketMQ 通过内存映射文件来提高存储的效率，具体实现如下：

MappedFileQueue：管理多个 MappedFile 文件，类似一个文件的队列。它负责创建、删除、切换文件等。
MappedFile：每个 MappedFile 对应一个存储文件。RocketMQ 使用 MappedByteBuffer 进行内存映射，直接将磁盘文件映射到内存，从而加速读取和写入操作。
TransientStorePool：这是一个缓存池，用于缓存消息的内存映射对象，减少重复的内存分配，提升效率。

3.5 实时更新消息消费队列与索引文件

转发到 ConsumerQueue：
- 消息存储完成后，Broker 会将消息信息更新到消费队列中，确保消费者能够读取到正确的消息。
转发到 Index：
- 为了提高消息的检索效率，Broker 会将消息的元数据（如消息ID、消息偏移量等）存储到索引文件中，方便后续查询。

3.6 消息队列和索引文件恢复

存储文件加载：
- 恢复过程包括将存储文件重新加载到内存中。恢复时，Broker 会从磁盘加载已经持久化的消息，以便继续服务消费者的消息消费。
异常恢复：
- 在消息存储过程中，如果出现异常，Broker 会根据消息的标记进行回滚或重试，确保消息的一致性。

3.7 刷盘机制

RocketMQ 提供两种刷盘机制，确保消息的持久性：

同步刷盘：每次写入消息后，都会进行同步刷盘操作，确保数据持久化到磁盘。这种方式保证了数据的可靠性，但会牺牲一定的性能。
异步刷盘：消息写入后，后台线程会异步进行刷盘操作，提高了性能，但在极端情况下可能会丢失少量数据。

3.8 过期文件删除机制

RocketMQ 会定期清理过期的存储文件，以释放磁盘空间。文件的过期时间由配置决定，通常基于时间戳或文件大小进行判断。过期文件会被删除，以确保系统不会因为磁盘空间不足而导致服务中断。

3.9 小结

RocketMQ 的消息存储模块通过高效的存储类（如 MappedFile、MappedFileQueue）和刷盘机制，确保了消息的持久性和高效读取。通过内存映射文件、实时更新消费队列和索引文件等机制，Broker 能够保证消息的可靠存储并提供高性能的消息访问。消息存储的可靠性和高效性是 RocketMQ 的核心优势之一。

4. Consumer

4.1 消息消费概述

Consumer 是消息的消费者，负责从 Broker 拉取消息并进行处理。消息消费的主要流程包括：拉取消息、处理消息、确认消息等。RocketMQ 通过灵活的消费策略，提供高效的消息消费机制。

4.2 消息消费初探

消息消费的基本过程如下：

拉取消息：Consumer 从 Broker 拉取待消费的消息。
处理消息：消费者根据业务逻辑处理消息。
确认消息：处理完消息后，消费者向 Broker 发送确认消息（或者根据业务逻辑决定是否重试）。

4.3 消费者启动流程

4.3.1 步骤一：初始化消费者配置

Consumer 初始化时，首先加载配置项，指定要订阅的主题和消息类型等配置。这些配置项一般来自于配置文件或程序中指定的参数。

4.3.2 步骤二：连接 Broker

Consumer 启动时，会通过网络建立与 Broker 的连接。通常通过 TCP 连接来实现。

4.3.3 步骤三：开始消费消息

消费者启动消费线程，进入等待状态，等待并消费消息。消息消费过程通常是异步的，Consumer 会不断地拉取消息并进行处理。

4.4 消息拉取

PullMessageService 实现机制
- PullMessageService 是负责拉取消息的核心服务。它处理来自 Consumer 的拉取请求，并与 Broker 进行交互，获取消息内容。
ProcessQueue 实现机制
- ProcessQueue 是消息的缓存容器。它用于缓存已经拉取到本地但尚未处理的消息。消息会在这里暂存，直到 Consumer 进行处理。
消息拉取基本流程
- 拉取请求：客户端 Consumer 发起拉取请求，向 Broker 查询是否有可用消息。
- Broker 组装消息：Broker 会根据 Consumer 的请求，筛选并返回相关的消息。
- 处理消息：消费者收到消息后会进行业务处理，完成后会根据处理结果决定是否确认消息或重试。
消息拉取总结
- RocketMQ 提供高效的消息拉取机制，确保消费者能够及时获取到需要消费的消息。通过长轮询、批量拉取等技术手段，优化了拉取效率，减少了网络负载。
消息拉取长轮询机制分析
- 长轮询机制：RocketMQ 采用了长轮询机制，在没有新消息时，Consumer 不会频繁地请求 Broker，而是等待 Broker 返回消息或超时。这样可以显著减少拉取请求的频率，提高系统的整体效率。

4.5 消息队列负载与重新分布机制

Broker 通过负载均衡机制重新分配消息队列，确保各个 Consumer 实例的负载相对均衡。这有助于防止某些 Consumer 被过多消息压垮，而其他 Consumer 却处于空闲状态。负载均衡的过程通常包括：

消息队列的分配：将消息队列平均分配到各个 Consumer 上。
消费者扩展：当有新的消费者加入时，Broker 会重新分配消息队列，确保消息消费的均衡。

4.6 消息消费过程

消息消费过程包括以下几个步骤：

接收消息：Consumer 向 Broker 发送拉取请求，获取待消费的消息。
处理消息：Consumer 对拉取到的消息进行业务处理，可以是同步或异步的。
确认消息：处理完成后，Consumer 向 Broker 发送确认消息，表明该消息已经成功消费。

在消费者没有确认消息之前，Broker 会将消息保留在队列中。确认机制（ACK）能够确保消息的可靠消费。

4.7 定时消息机制

RocketMQ 支持定时消息的发送和消费。消费者可以设置定时消息的消费时间，只有在消息达到指定的时间后，才会被处理。这种机制常用于实现延时任务或定时任务。

定时消息：消息发送时可以设置延迟时间，Broker 会在消息达到设定的时间后，才会将消息投递给消费者。
消费定时消息：消费者根据设定的时间来消费定时消息，确保消息的消费不会超时或重复消费。

4.8 顺序消息

顺序消息确保消息在消费时按照发送顺序进行处理。RocketMQ 为顺序消息提供了专门的支持，确保同一个消息队列中的消息按顺序消费。

顺序消费：消费者消费同一队列的消息时，确保按照发送顺序进行处理，避免消息顺序错乱。
负载均衡与顺序消费：为了保证顺序消费的准确性，RocketMQ 会将顺序消息限定在特定的队列中，避免多个消费者同时消费同一消息。

4.9 小结

RocketMQ 的消费者模块通过高效的拉取机制、负载均衡机制和消费策略，确保消息的高效消费。长轮询机制、消息拉取和消费过程的优化，使得 RocketMQ 在高并发场景下能够提供稳定且高效的消息消费服务。同时，定时消息和顺序消息机制的支持，使得 RocketMQ 适应了更多场景的需求，增强了其灵活性和可扩展性。