RocketMQ底层通信基于自定义Remoting私有协议与Netty主从Reactor模型，通过二进制帧结构、零拷贝、堆外内存池化及Header/Body分离解析等机制实现高吞吐、低延迟与强可靠性。
RocketMQ 底层通信基于自定义私有协议 + Netty 网络框架实现，核心目标是兼顾高吞吐、低延迟与强可靠性。它不依赖 HTTP 等通用协议，而是通过精简二进制格式、零拷贝传输和主从 Reactor 模型，在大规模消息场景下保持稳定高性能。
私有 Remoting 协议设计要点
RocketMQ 所有组件（Producer/Broker/Consumer/NameServer）均使用统一的 Remoting 协议通信，该协议是轻量、紧凑的二进制私有协议，结构固定：
- 帧头固定结构：含 4 字节魔数（用于协议识别）、4 字节总长度、1 字节序列化类型、3 字节 header 长度，再后接 header 和 body；
- 头部可扩展：header 中包含 requestCode（如 SEND_MESSAGE=10、PULL_MESSAGE=11）、opaque（请求唯一 ID）、flag（是否需要响应）、extFields（键值对，支持版本兼容与功能扩展）；
-
无粘包/半包问题：采用
LengthFieldBasedFrameDecoder解码器，依据帧头中声明的总长度精准切分，避免遍历或定长浪费； - 序列化轻量高效：默认使用 RocketMQ 自研二进制编码（非 JSON/XML），支持快速序列化/反序列化，减少 CPU 和内存开销。
Netty 主从多线程 Reactor 模型
Broker 和 NameServer 的服务端网络层完全基于 Netty 构建，采用经典的主从 Reactor 模式：
- Boss EventLoopGroup：单线程，仅负责 accept 新连接，建立 Channel 后立即将其注册到 Worker Group；
-
Worker EventLoopGroup：默认线程数为
CPU 核心数 × 2，每个线程绑定一个 Selector，轮询处理已连接 Channel 的 read/write 事件； -
业务线程池隔离：IO 事件解析出
RemotingCommand后，交由独立线程池（serverCallbackExecutorThreads）执行具体逻辑（如消息写入 CommitLog），避免阻塞 IO 线程； - 连接复用与长连接：Producer/Consumer/Broker 均与 NameServer 或目标 Broker 维持长连接，心跳保活（Broker 每 30s 上报路由，Producer 每 30s 发送心跳），降低建连开销。
高性能通信关键机制
协议与网络模型之外，RocketMQ 还融合多项底层优化技术：
-
零拷贝传输：接收时复用 Netty 的
PooledDirectByteBuf，跳过堆内复制；发送大文件（如拉取消息体）时使用DefaultFileRegion调用transferTo()，借助 DMA 直达网卡； -
堆外内存池化：通过
PooledByteBufAllocator.DEFAULT复用 DirectBuffer，显著降低 GC 压力； - Header/Body 分离解析：解码时仅解析 header 字段（如 requestCode、opaque），body 可延迟反序列化或直接透传，提升吞吐；
-
参数精细调优：如
serverSocketRcvBufSize和writeBufferHighWaterMark设置为 256KB~1MB，避免缓冲区频繁扩容或写堆积。
与 Kafka 网络模型对比参考
不同于 Kafka 的单 Selector + 多 Processor 模型，RocketMQ 的 Netty 主从模式更强调线程职责分离：
- Kafka 共享 Selector 监听所有连接，IO 和部分解析耦合在同一个线程；
- RocketMQ 每个 Channel 绑定专属 EventLoop，IO 处理更均匀，连接数增长时扩展性更好；
- 内存方面，Kafka 使用临时 ByteBuffer 易触发 GC，RocketMQ 则全程池化堆外内存；
- 实测在 10 万连接场景下，RocketMQ CPU 利用率更平稳，Kafka 容易出现 Selector.select() 阻塞现象。
