RocketMQ 的架构设计

技术架构

• 包含以上四个部分
• Producer：消息生产者
• Consumer：消息消息者
• NameServer：管理调度中心
• BrokerServer：负责消息的存储、发送、接收
  • Remoting Module：整个 Broker 的实体，负责处理来自 clients 端的请求
  • Client Manager：负责管理客户端（Producer/Consumer）和维护 Consumer 的 Topic 订阅信息
  • Store Service：提供方便简单的 API 接口处理消息存储到物理硬盘和查询功能
  • HA Service：高可用服务，提供 Master Broker 和 Slave Broker 之间的数据同步功能
  • Index Service：根据特定的 Message Key 对投递到 Broker 的消息进行索引服务，以提供消息的快速查询

部署架构

网络部署特点

• Name Server 为无状态节点，可集群部署，节点之间无信息同步
• Broker 部署相对复杂，分为 Master 与 Slave，
  • 一个 Master 对应多个 Slave，但一个 Slave 只能对应一个 Master
  • Master 和 Slave 的对应关系通过指定相同的 BrokerName，不同的 BrokerId 来定义，BrokerId 为 0 表示 Master，非 0 表示 Slave
  • Master 可部署多个，每个 Broker 与 NameServer 集群中的所有节点建立长连接，定时注册 Topic 信息到所有 NameServer
  • 目前版本的 RocketMQ 在部署架构上支持一 Maste r多 Slave，但只有 BrokerId = 1 的从服务器才会参与消息的读负载
• Producer 与 NameServer 集群中的一个节点（随机选择）建立长连接，定期从 NameServer 获取 Topic 路由信息，并向提供 Topic 服务的 Master 建立长连接，且定时向 Master 发送心跳，Producer 完全无状态，可集群部署
• Consumer 与 NameServer 集群中的一个节点（随机选择）建立长连接，定期从 NameServer 获取 Topic 路由信息，并向提供 Topic 服务的 Master、Slave 建立长连接，且定时向 Master、Slave 发送心跳。Consumer 既可从 Master 订阅消息，也可从 Slave 订阅消息，消费者在向 Master 拉取消息时，Master 服务器会根据拉取偏移量与最大偏移量的距离（判断是否读老消息，产生读 IO），以及从服务器是否可读等因素建议下一次是从 Master or Slave 拉取。

简述工作流程

• 启动 NameServer 并监听端口，等待 Broker、Producer、Consumer 连上来，相当于一个路由控制中心
• 启动 Broker，跟所有的 NameServer 保持长连接，定时发送心跳包。心跳包中包含当前 Broker 信息（IP、端口等）以及存储所有 Topic 信息，注册成功后，NameServer 集群中就有 Topic 跟 Broker 的映射关系
• 收发消息前，先创建 Topic，创建 Topic 时需要指定该 Topic 要存储在哪些 Broker 上，也可以在发送消息时自动创建 Topic
• Producer 发送消息，启动时先跟 NameServer 集群中的其中一台建立长连接，并从 NameServer 中获取当前发送送给你的 Topic 存在哪些 Broker 上，轮询从队列列表中选择一个队列，然后与队列所在的 Broker 建立长连接从而向 Broker 发消息
• Consumer 跟 Producer 类似，跟其中一台 NameServer 建立长连接，获取当前订阅 Topic 存在哪些 Broker 上，然后直接跟 Broker 建立连接通道，消费消息