系列文章目录

前言

本文主要是 RocketMQ 核心概念中的 RocketMQ 整体架构的一些介绍，有不足之处希望读者们指出。

<hr style=" border:solid; width:100px; height:1px;" color=#000000 size=1"><font color=#999AAA >提示：以下是本篇文章正文内容，下面案例可供参考

一、RocketMQ 整体架构

RocketMQ 主要由三大主件(NameServer、Broker、Client)组成，如上图所示。

1.1、NameServer（注册与发现服务器）

NameServer，翻译过来就是名称服务器，Topic（是一个 Message 的目录）的路由注册中心，为 Client 提供关于 Topic 的路由信息，从而引导 Client 向 Broker 发送消息，需要注意的是，NameServer 是一个几乎无状态节点，多个 NameServer 实例组成集群，但相互独立，没有信息交换。NameServer 存储数据一致性方案用的是最终一致性方案。

主要作用是：为 Client 提供在内存中存储的关于 Topic 的路由信息（路由管理），监控更新 Broker 的实时状态（Broker 管理）。

1.2、Broker（代理服务器）

Broker,翻译过来就是中间人，是一个消息存储和转发服务器，并且也是持久化 Topic 路由信息的地方。Broker 是以 Group 为单位提供服务，一个 Group 主要是由 Master 和 Slave 组成。在 RocketMQ 中，Master 服务承担读写操作，Slave 服务器作为一个备份（Slave 从 Master 同步数据（同步双写或异步复制看配置）），当 Master 服务器存在压力时，Slave 服务器可以承担读服务（消息消费）。

每个 Broker 与 NameServer 集群中的所有节点建立长连接，每隔 30s 会向 NameServer 发送心跳包（包含存在在 Broker 上所有的 Topic 的路由信息），更新 Broker 信息、Topic 路由信息等。

注：

一个 Master 可以对应多个 Slave，一个 Slave 只能对应一个 Master。Master 与 Slave 的对应关系通过指定相同的 BrokerName、不同的 BrokerId 来定义，BrokerId 为 0 表示 Master，非 0 表示 Slave。Master 也可以部署多个。Broker 不一定是物理机或虚拟机。在 RocketMQ4.5.0 版本后引入了多副本机制，内部使用 Raft 协议保证 Broker 节点数据的强一致性。

1.3、Client（客户端）

1.3.1、Producer（消息生产者）

Producer 与 NameServer 集群中的其中一个节点（随机选择）建立长连接，只有在连接异常的时候才会去连接集群中的另一 NameServer 节点。Producer 每隔 30 秒从 NameServer 获取 Topic 路由信息，并向提供 Topic 服务的 Broker Master 建立长连接，且定时向 Broker Master 发送心跳。Producer 完全无状态，可集群部署。

Producer 负责生产消息，一般由业务系统负责生产消息。一个消息生产者会把业务应用系统里产生的消息发送到 Broker 服务器。RocketMQ 提供多种发送方式，同步发送、异步发送、单向发送。同步和异步方式均需要 Broker 返回确认信息，单向发送不需要。

注：

如果初始 Producer 在事务后出错崩溃，Broker 会联系同一 Producer Group 中的不同 Producer 实例，继续提交或回滚事务。

1.3.2、Consumer（消息消费者）

Consumer 与 NameServer 集群中的其中一个节点（随机选择）建立长连接，只有在连接异常的时候才会连接集群中的另一 NameServer 节点。Consumer 每隔 30 秒从 NameServer 获取 Topic 路由信息，并向提供 Topic 服务的 Broker Master、Broker Slave 建立长连接，且定时向 Broker Master、Broker Slave 发送心跳。Consumer 既可以从 Broker Master 订阅消息，也可以从 Broker Slave 订阅消息，订阅规则由 Broker 配置决定。

Consumer 负责消费消息，一般是后台系统负责异步消费。一个消息消费者会从 Broker 服务器拉取消息、并将其提供给应用程序。从用户应用的角度而言提供了两种消费形式：

• 拉取式消费：拉式消费者从 Broker 拉取消息，一旦一批消息被拉取，用户应用系统将发起消费过程。

• 推取式消费：推取式消费，从另一方面讲，囊括了消息的拉取、消费过程，并保持了内部的其他工作，留下了一个回调接口给终端用户去实现，实现在消息到达时要执行的内容。

注：

一个 Consumer Group 中的消费者实例必须有确定的相同的订阅 Topic，相同 Consumer Group 的每个 Consumer 实例平均分摊消息。一个条消息仅能被一个 Consumer Group 消费一次，实现了负载均衡和容错的功能。

<hr style=" border:solid; width:100px; height:1px;" color=#000000 size=1">

总结

RocketMQ 核心概念中的 RocketMQ 整体架构就先介绍到这里了，还有不少不全的地方，后续系列文章再补充，笔者欢迎各位大佬指出错误。

著作权归 NoLongerConfused 所有。商业转载请联系 NoLongerConfused 获得授权，非商业转载请注明出处。