RocketMQ 各部分介绍

一般来讲，RocketMQ 的架构为：

RocketMQ 一共由四个部分组成：NameServer、Broker、Producer、Consumer，它们分别对应着发现、存、发、收四个功能。这四部分的功能很像邮政系统，Producer 相当于负责发送信件的发件人，Consumer 相当于负责接收信件的收件人，Broker 相当于负责暂存信件传输的邮局，NameServer 相当于负责协调各个地方邮局的管理机构。一般情况下，为了保证高可用，每一部分都是以集群形式部署的。

NameServer：NameServer 是一个非常简单的 Topic 路由注册中心，是一个无状态的服务器，角色类似于 Kafka 使用的 Zookeeper，但比 Zookeeper 更轻量。支持 Broker 的动态注册与发现。主要功能有：

（1）Broker 管理：NameServer 接收 Broker 集群的注册信息并且保存下来作为路由信息的基本数据。然后提供心跳检测机制，检查 Broker 是否还存活；

（2）路由信息管理：每个 NameServer 将保存关于 Broker 集群的整个路由信息和用于客户端查询的队列信息。然后 Producer 和 Conumser 通过 NameServer 就可以知道整个 Broker 集群的路由信息，从而进行消息的投递和消费。

NameServer 通常也是集群的方式部署，每个 NameServer 结点之间是相互独立，彼此没有任何信息交互。Broker 是向每一台 NameServer 注册自己的路由信息，所以每一个 NameServer 实例上面都保存着一份完整的路由信息。当某个 NameServer 实例下线了，Broker 仍然可以向其他 NameServer 同步其路由信息。Producer 和 Consumer 仍然可以动态感知 Broker 的路由信息。

Broker：又称 BrokerServer，主要负责消息的存储、投递和查询以及服务高可用保证。为了实现这些功能，Broker 包含了一下几个重要的子模块：

（1）Remoting Moudle：整个 Broker 的实体，负责处理来自 Client 端的请求；

（2）Client Manager：负责管理客户端（Producer 和 Consumer）和维护 Consumer 的 Topic 订阅信息；

（3）Store Service：提供方便简单的 API 接口，处理消息存储到物理硬盘和查询功能；

（4）HA Service：高可用服务，提供 Master Broker 和 Slave Broker 之间的数据同步功能；

（5）Index Service：根据特定的 Message Key 对投递到 Broker 的消息进行索引服务，以提供消息的快速查询。

Broker 内部维护着 Consumer Queue，用来存储消息的索引，真正存储消息的地方是 CommitLog。

每个单独的 Broker 与所有的 NameServer 保持着长连接和心跳检测，并定时将 Topic 信息同步到 NameServer。和 NameServer 的通信底层是通过 Netty 实现的。

Producer：消息生产者。支持分布式集群部署，Producer 通过多种负载均衡模式将消息投递到 Broker 集群，投递的过程支持快速失败并且低延迟。

RocketMQ 提供了三种方式发送消息：同步发送、异步发送和单向发送。

（1）同步发送：同步发送指消息发送方 Producer 发出数据后会在接收到接收方 Consumer 发回响应之后才发下一个数据包。一般用于重要通知消息，例如重要通知邮件、营销短信。

（2）异步发送：异步发送指发送方发出数据后，不需要等待接收方 Consumer 发回响应，直接发送下个数据包，一般用于可能链路耗时较长而且对响应时间敏感的业务场景，例如用户视频上传后通知启动转码服务。

（3）单向发送：单向发送是指只负责发送消息而不等待服务器回应且没有回调函数触发，适用于某些耗时非常短但对可靠性要求并不高的场景，例如日志收集。

Consumer：消息消费者，负责消费消息，一般是后台系统负责异步消费。支持分布式集群部署。支持集群消费和广播消费，同时其提供的实时的消息订阅机制可以满足大多数用户的需求。除此之外，还支持以 push 推，pull 拉两种模式对消息进行消费。

（1）Pull：拉取型消费者（Pull Consumer）：主动从消息服务器拉取信息，只要批量拉取到消息，用户应用就会启动消费过程，所以 Pull 称为主动消费型。

（2）Push：推送型消费者（Push Consumer）：封装了消息的拉取、消费进度和其他的内部维护工作，将消息到达时执行的回调接口留给用户应用程序来实现。所以 Push 称为被动消费类型，但其实从实现上看还是从消息服务器中拉取消息，不同于 Pull 的是 Push 首先要注册消费监听器，当监听器被触发后才开始消费消息。

RocketMQ 网络部署架构为：

其特点为：

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

（2）Broker 部署相对复杂，Broker 分为 Master 与 Slave，一个 Master 可以对应多个 Slave，但是一个 Slave 只能对应一个 Master，Master 与 Slave 的对应关系通过指定相同的 BrokerName 不同的 BrokerId 来定义，BrokerId 为 0 表示 Master，非 0 表示 Slave。Master 也可以部署多个。每个 Broker 与 NameServer 集群中的所有节点建立长连接，定时注册 Topic 信息到所有 NameServer。 注意：当前 RocketMQ 版本在部署架构上支持一 Master 多 Slave，但只有 BrokerId=1 的从服务器才会参与消息的读负载。

（3）Producer 与 NameServer 集群中的其中一个节点（随机选择）建立长连接，定期从 NameServer 获取 Topic 路由信息，并向提供 Topic 服务的 Master 建立长连接，且定时向 Master 发送心跳。Producer 完全无状态，可集群部署。

（4）Consumer 与 NameServer 集群中的其中一个节点（随机选择）建立长连接，定期从 NameServer 获取Topic路由信息，并向提供 Topic 服务的 Master、Slave 建立长连接，且定时向 Master、Slave 发送心跳。Consumer 既可以从 Master 订阅消息，也可以从 Slave 订阅消息，消费者在向 Master 拉取消息时，Master 服务器会根据拉取偏移量与最大偏移量的距离（判断是否读老消息，产生读I/O），以及从服务器是否可读等因素建议下一次是从 Master 还是 Slave 拉取。

结合部署架构图，描述集群工作流程：

（1）启动 NameServer，NameServer 起来后监听端口，等待 Broker、Producer、Consumer 连上来，相当于一个路由控制中心。

（2）Broker 启动，跟所有的 NameServer 保持长连接，定时发送心跳包。心跳包中包含当前 Broker 信息(IP+端口等)以及存储所有 Topic 信息。注册成功后，NameServer 集群中就有 Topic 跟 Broker 的映射关系。

（3）收发消息前，先创建 Topic，创建 Topic 时需要指定该 Topic 要存储在哪些 Broker 上，也可以在发送消息时自动创建 Topic。

（4）Producer 发送消息，启动时先跟 NameServer 集群中的其中一台建立长连接，并从 NameServer 中获取当前发送的 Topic 存在哪些 Broker 上，轮询从队列列表中选择一个队列，然后与队列所在的 Broker 建立长连接，从而向 Broker 发消息。

（5）Consumer 跟 Producer 类似，跟其中一台 NameServer 建立长连接，获取当前订阅 Topic 存在哪些 Broker 上，然后直接跟 Broker 建立连接通道，开始消费消息。

本文参考自：两万字、三十图、二十三问，搞定RocketMQ! - 掘金