RocketMQ 架构

部署架构图

• Producer：生产者，负责发送消息到 Broker

• Consumer：消费者，负责消费 Broker 的消息

  支持推（Broker 主动把消息推送给消费者）、拉（消费者根据配置定期向 Broker 获取消息）两种消费模式

  支持集群（组下一个消费者消费消息）、广播（组下每个消费者都消费消息）两种方式

• NameServer：名称服务，可以集群部署，可以理解为 Broker 的注册中心，主要包含 Broker 管理 和 路由管理 两个功能

  Broker 管理：保存 Broker 集群的信息，并通过心跳检测机制检查各个 Broker 是否存活，NameServer 会根据心跳剔除不存活的 Broker

  路由管理：因为保存了 Broker 的信息（包括队列，每个队列逻辑属于某个 Topic），所以可以为客户端（生产者和消费者）提供查询队列的能力

  NameServer 集群部署，每个 NameServer 都保存所有 Broker 节点信息，当某个 NameServer 节点宕机时不需要选举，每一个都能独立工作

• Broker：代理服务器，主要负责消息投递、存储、查询的功能，因为是真正处理消息的组件，同时还必须提供高可用的能力

  Broker 在接收到消息后会存入队列、刷盘（写入 Commit Log 文件，并为每个消息构建索引，方便快速定位）、把消息推送给消费者

  每个 Broker 节点都会注册到所有 NameServer 节点（建立长连接），Broker 下有队列，会定期把队列的 Topic 信息注册到 NameServer

  Prodcuer 与 NameServer 中的某个节点建立长连接，定期获取 Topic 路由信息，并与相同 Topic 的队列的 Broker 的 Master 建立长连接，并定时向 Master 发送心跳，Topic 下的队列可能分布在不同的 Broker 中，所以客户端可能与多个 Broker 的 Master 建立长连接

  Consumer 与 Producer 基本一致，不同的是 Consumer 与 Master 和 Slave 都建立长连接，意味着发消息时只发给 Master，消费消息时既可以到 Master 获取消息，也可以到 Slave 获取消息

消息流程图

• Topic：消息的主题，是一个逻辑概念，每个 Topic 都有多个 MessageQueue

  RocketMQ 4.x 下，每个 Topic 默认 4 个队列；在 5.x 下，每个 Topic 默认 8 个队列

  生产者会指定 Topic，发消息时，会轮询发送到 Topic 下的各个队列中（Topic 是逻辑概念，真正是 Broker 下的队列）

  消费者也会指定 Topic（还会指定消费者组），当 Broker 收到消息时，会把队列中的消息推送给订阅了这个 Topic 的消费者组

• Topic 和 Broker 的关系：

  Topic 下有队列，Broker 中也有队列，Topic 下的队列分布在不同的 Broker 中

  生产者发消息时，消息会发到 Topic 下的队列中，根据队列能定位到 Broker，但并不是他俩就有直接的关系

• ConsumerGroup：消费者组，一个组下的所有消费者订阅的 Topic 必须相同（订阅一致性），一个消费者组可以订阅多个 Topic

  如果多个组订阅了相同的 Topic，这个 Topic 接收到消息后，每个组都会收到消息，处理方式也有两种：

  1，集群模式（默认），组下只有一个消费者会消费消息

  2，广播模式，组下所有消费者都要消费消息

• MessageTag：消息标签，也可以理解为消息的二级分类，Toppic 是一级分类

  发送一个带 Tag 的消息，不同的消费者可以根据 Tag 选择是否处理

• MessageQueue：消息队列，存储消息的最小单元，FIFO

  消息进入队列后，会有一个编号（下标、索引的意味，表示第几条消息）

  最小位点：当前队列上最小编号的消息（当消息条数超过队列上限时，删除前面的，保留最新的，所以最小位点可能不是0）

  最大位点（代理者位点）：当前队列上最大编号的消息（当前队列已经存放过的消息条数）

  消费者位点：当前正在消费的消息的编号

  差值：【最大位点】 - 【消费者位点】 的值，如果不是0，说明当前队列上还有未消费的消息（广播模式不遵循）

  队列不是无上限的，比如开始时，队列的最小位点是0，最大位点也是0，当投递5条消息后，最小位点是0，最大位点就是4
  如果队列上限是100，当投递第101条消息后，最大位点是100，最小位点就是1了