追求极致性能，RocketMQ 消息通信详解

最新推荐文章于 2025-04-16 14:31:32 发布

原创

最新推荐文章于 2025-04-16 14:31:32 发布 · 1.1k 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#java-rocketmq #rocketmq #java

本文详细介绍了 RocketMQ 的网络通信过程，从 RocketMQ 的架构到网络通信模块的设计，包括 NameServer、Broker、Producer 和 Consumer 的角色及交互。重点解析了 rocketmq-remoting 模块的结构，自定义通信协议，以及基于 Netty 的 Reactor 多线程模型。此外，还探讨了同步、异步和单向通信模式及其流程。通过对 RocketMQ 消息通信的深入理解，有助于提升系统的性能和稳定性。

1 介绍

RocketMQ 消息队列架构主要包括 NameServe、Broker(Master/Slave)、Producer、Consumer 4 个核心部件，基本执行流程如下：

点击查看大图

NameServer 优先启动。NameServer 是整个 RocketMQ 的“中央大脑” ，作为 RocketMQ 的服务注册中心，所以 RocketMQ 需要先启动 NameServer 再启动 Rocket 中的 Broker。
Broker 启动后，需要将自己注册至 NameServer 中，并保持长连接，每 30s 发送一次发送心跳包，来确保 Broker 是否存活。并将 Broker 信息 ( IP+、端口等信息）以及 Broker 中存储的 Topic 信息上报。注册成功后，NameServer 集群中就有 Topic 跟 Broker 的映射关系。
NameServer 如果检测到 Broker 宕机（因为使用心跳机制，如果检测超 120s（两分钟）无响应），则从路由注册表中将其移除。
生产者在发送某个主题的消息之前先从 NamerServer 获取 Broker 服务器地址列表（Broker 可能是 Cluster 模式），然后根据负载均衡算法从列表中选择 1 台 Broker ，建立连接通道，进行消息发送。
消费者在订阅某个 topic 的消息之前从 NamerServer 获取 Broker 服务器地址列表（Broker 可能是 Cluster 模式），包括关联的全部 Topic 队列信息。进而获取当前订阅 Topic 存在哪些 Broker 上，然后直接跟 Broker 建立连接通道，开始消费数据。
生产者和