RocketMQ 为何性能高

本文主要从性能角度考虑 RocketMQ 的实现。

整体架构

这是网络上流行的 RocketMQ 的集群部署图。

RocketMQ 主要由 Broker、NameServer、Producer 和 Consumer 组成的一个集群。

**NameServer：整个集群的注册中心和配置中心，管理集群的元数据。包括 Topic 信息和路由信息、Producer 和 Consumer 的客户端注册信息、Broker 的注册信息。**Broker：负责接收消息的生产和消费请求，并进行消息的持久化和消息的读取。**Producer：负责生产消息。**Consumer：负责消费消息。在实际生产和消费消息的过程中，NameServer 为生产者和消费者提供 Meta 数据，以确定消息该发往哪个 Broker 或者该从哪个 Broker 拉取消息。有了 Meta 数据后，生产者和消费者就可以直接和 Broker 交互了。这种点对点的交互方式最大限度降低了消息传递的中间环节，缩短了链路耗时。

网络模型

RocketMQ 使用 Netty 框架实现高性能的网络传输。

基于 Netty 实现网络通信模块

Netty 主要特点

**具有统一的 API，用户无需关心 NIO 的编程模型和概念。通过 Netty 的 ChannelHandler 可以对通信框架进行灵活的定制和扩展。**Netty 封装了网络编程涉及的基本功能：拆包解包、异常检测、零拷贝传输。**Netty 解决了 NIO 的 Epoll Bug，避免空轮询导致 CPU 的 100% 利用率。**支持多种 Reactor 线程模型。**使用范围广泛，有较好的的开源社区支持。Hadoop、Spark、Dubbo 等项目都集成 Netty。**Netty 的高性能传输的体现

非阻塞 IORactor 线程模型**零拷贝。使用 FileChannel.transfer 避免在用户态和内核态之间的拷贝操作；通过 CompositeByteBuf 组合多个 ByteBuffer；通过 slice 获取 ByteBuffer 的切片；通过 wrapper 把普通 ByteBuffer 封装成 netty.ByteBuffer。**RocketMQ 网络模型

RocketMQ 的 Broker 端基于 Netty 实现了主从 Reactor 模型。架构如下：

具体流程：

eventLoopGroupBoss 作为 acceptor 负责接收客户端的连接请求eventLoopGroupSelector 负责 NIO 的读写操作NettyServerHandler 读取 IO 数据，并对消息头进行解析disatch 过程根据注册的消息 code 和 processsor 把不同的事件分发给不同的线程。由 processTable 维护（类型为 HashMap）业务线程池隔离

RocketMQ 对 Broker 的线程池进行了精细的隔离。使得消息的生产、消费、客户端心跳、客户端注册等请求不会互相干扰。如下是各个业务执行线程池和 Broker 处理的报文类型的对应关系，从下图中我们也可以看出 Broker 的核心功能点。

消息的生产

RocketMQ 支持三种消息发送方式：同步发送、异步发送和 One-Way 发送。One-Way 发送时客户端无法确定服务端消息是否投递成功，因此是不可靠的发送方式。

客户端发送时序图