（自用）RocketMQ架构

RocketMQ是阿里巴巴开源的一个分布式消息中间件，后来捐赠给了Apache，成为顶级项目。它的设计目标是高吞吐量、高可用性、可伸缩性和低延迟，适合处理大规模的消息流。RocketMQ核心组件有四个：NameServer、Broker、Producer和Consumer。

核心组件

NameServer 是轻量级的服务发现与路由管理组件，负责维护集群中所有 Broker 的元数据信息（如 Topic 的路由配置、Broker 地址等）。其无状态设计使得多个 NameServer 节点可以独立运行，Broker 在启动时会向所有 NameServer 注册自身信息，并定期发送心跳以保持连接。Producer 和 Consumer 在发送或消费消息前，会从 NameServer 动态获取最新的路由表，确保能够正确找到目标 Broker。由于 NameServer 不存储持久化数据且节点间不通信，其高可用性通过部署多个节点实现，即使部分节点故障也不会影响整体服务。

Broker 是消息存储与转发的核心，采用主从架构（Master-Slave）保障高可用。Master 节点处理消息的写入和读取请求，支持同步或异步方式将数据复制到 Slave 节点：同步复制确保数据强一致（消息写入 Master 和 Slave 后返回成功），而异步复制则优先保证吞吐量（写入 Master 后立即返回，异步复制到 Slave）。当 Master 宕机时，Slave 可切换为新的 Master 继续提供服务。Broker 内部的消息存储机制基于高效的文件系统设计，所有消息按顺序追加写入 CommitLog 文件，避免随机磁盘 I/O 带来的性能损耗。同时，为加速消息检索，每个 Topic 的队列对应一个 ConsumeQueue 索引文件，记录消息在 CommitLog 中的物理位置，消费者通过 ConsumeQueue 快速定位消息。此外，IndexFile 提供基于消息 Key 或时间范围的查询能力，满足特定场景需求。

Producer 作为消息生产者，通过 NameServer 获取 Topic 对应的 Broker 地址，并选择特定队列发送消息。发送模式包括同步（等待 Broker 响应）、异步（回调通知结果）和单向（不关心结果）三种，用户可根据场景选择。Producer 还支持自定义消息分区策略，例如按 Key 哈希或轮询分配队列，以实现消息的负载均衡或顺序性保障。

Consumer 作为消息消费者，从 Broker 拉取或接收推送的消息。消费模式分为 集群消费 和 广播消费：前者允许多个消费者实例分摊同一 Topic 的消息（每个消息仅被消费一次），后者则让每个实例接收全量消息（适用于广播通知）。RocketMQ 默认通过长轮询机制模拟 Push 模式，Consumer 挂起请求直至 Broker 有消息到达或超时，兼顾实时性与资源效率。消费者需定期提交消费进度 Offset 至 Broker，确保故障恢复后能从正确位置继续消费。

我们可以想象它是一个超级快递公司，负责把“消息包裹”从寄件人（生产者）送到收件人（消费者）。以下是它的运作流程：

---

1. 快递公司的“总部地图”（NameServer）

• 作用：快递公司有一个总部的“智能地图”（NameServer），记录所有分拣中心（Broker）的位置。
• 工作步骤：
  ① 每个分拣中心开业时，都会打电话给总部说：“我在这里！可以处理某某区域的包裹！”（Broker 注册路由信息）
  ② 快递员（生产者/消费者）送件前，先去总部查地图：“最近的快递分拣中心在哪？”（客户端拉取路由表）

---

2. 寄包裹：从寄件人到分拣中心（Producer → Broker）

• 场景：小明想寄一个写着“明天秋游”的包裹（消息）给小红。
• 步骤：
  ① 小明找到快递员（生产者），说：“请把这个包裹送到‘班级通知’快递站（Topic）。”
  ② 快递员查地图，发现“班级通知”包裹由3号分拣中心（Broker）处理，于是开车送去。
  ③ 分拣中心收到包裹后，先把它扔进一个大仓库（CommitLog 存储），然后在小本子（ConsumeQueue）上记下：“小红包裹在仓库第5排架子”。

---

3. 送包裹：从分拣中心到收件人（Broker → Consumer）

• 场景：小红每天放学都会去快递站取包裹。
• 步骤：
  ① 小红（消费者）对快递站说：“我要取所有‘班级通知’的包裹！”（订阅 Topic）
  ② 快递站根据小本子的记录，从仓库里找到小红的包裹，按顺序交给她。
  ③ 小红拿到包裹后，在快递单上签个字（消费确认），快递站就把这个包裹标记为“已签收”。

---

4. 如果出了问题怎么办？

• 包裹丢了？
  → 快递公司发现小红没收到包裹，会自动再送一次，最多重试16次（消息重试机制）。
• 分拣中心停电？
  → 总部地图会告诉快递员：“换备用分拣中心送！”（主从切换高可用）
• 包裹顺序乱了？
  → 如果小明连续寄了3个包裹，快递公司会保证小红按“1→2→3”的顺序拿到（顺序消息）。

---

5. 总结：快递公司的秘密武器

快递公司术语	RocketMQ 对应	作用
总部地图	NameServer	告诉快递员往哪送包裹
分拣中心	Broker	存包裹并安排配送路线
仓库和小本子	CommitLog + 队列	记录包裹位置，方便快速查找
备用分拣中心	Slave Broker	防止主中心故障，包裹不丢失

一句话理解：
RocketMQ 就像一家永远不会丢包裹、还能智能调度快递员的公司，确保每个人都能准确收到自己的“消息包裹”，哪怕遇到问题也能自动解决！

RocketMQ集群

1. NameServer 集群（轻量级路由中心）
   • 无状态设计：多个 NameServer 节点独立运行，不互相通信，仅存储 Broker 的路由信息（类似电话簿）。
   • 动态感知：Broker 定时向所有 NameServer 发送心跳包，NameServer 感知 Broker 存活状态并更新路由表。
   • 客户端交互：生产者和消费者从任意 NameServer 拉取最新路由，本地缓存以降低依赖。
2. Broker 集群（消息存储与转发核心）
   • 主从架构：每个 Broker 组（Broker Cluster）包含 1个Master + N个Slave，Master 负责读写，Slave 仅同步数据。
   • 数据同步模式：
     • 同步复制（SYNC_MASTER）：Master 收到消息后需等待 Slave 写入完成才返回响应，确保数据零丢失。
     • 异步复制（ASYNC_MASTER）：Master 写入后立即响应，Slave 异步同步，性能更高但存在短暂数据不一致风险。
3. 生产者与消费者集群（客户端负载均衡）
   • 生产者：通过轮询、哈希等策略选择 Topic 对应的 Broker 队列发送消息。
   • 消费者：以消费者组（Consumer Group）形式订阅消息，组内多个实例分摊队列负载（如4个队列由2个消费者各消费2个）。

---

        数据分布与高可用机制

1. Topic 分片与队列分配
   • 队列分片：每个 Topic 划分为多个队列（MessageQueue），均匀分布在多个 Broker 上，实现水平扩展。
   • 读写分离：Producer 向 Master 写入消息，Consumer 可从 Master 或 Slave 读取（Slave 仅在 Master 故障时接管）。
2. 故障自动切换
   • Broker 宕机：NameServer 检测到 Master 离线后，通知消费者切换至 Slave 继续消费。
   • 消息重试：若消费失败，消息自动进入重试队列（%RETRY%），最多重试16次后转入死信队列（%DLQ%）。

---

三、扩展性与运维管理

1. 动态扩缩容
   • 增加 Broker：在线扩容时，新 Broker 向 NameServer 注册，Topic 队列自动分配到新节点。
   • 队列扩容：支持修改 Topic 队列数量，新队列立即生效，旧队列数据保留至消费完成。

 

心跳检测机制：实时感知与故障恢复

1. Broker → NameServer 心跳
   • 注册与保活：
     • Broker 启动时向所有 NameServer 节点注册自身信息（IP、端口、Topic 配置）。
     • 每隔 30秒 发送一次心跳包，维持长连接。
   • 心跳内容：
     • Broker ID、角色（Master/Slave）、Topic 路由表、队列分布。
     • 当前负载状态（CPU、内存、磁盘使用率）。
2. NameServer 故障检测
   • 超时剔除：若 NameServer 在 120秒 内未收到 Broker 心跳，判定该 Broker 宕机，更新路由表并通知客户端。
   • 主动探测：NameServer 可主动向 Broker 发送健康检查请求（兜底机制）。
3. 客户端 ↔ Broker 心跳
   • 生产者/消费者保活：
     • 客户端与 Broker 建立 TCP 长连接后，每隔 20秒 发送心跳包维持连接。
     • 心跳内容：客户端 ID、订阅关系、消费进度（Consumer Offset）。
   • 异常处理：
     • 若 Broker 未响应心跳超过 90秒，客户端自动切换至其他 Broker。
     • 消费者心跳失败时，触发重平衡（Rebalance），重新分配队列。
4. 主从心跳同步
   • Slave → Master 心跳：
     • Slave 定期向 Master 上报同步进度（CommitLog 最大偏移量）。
     • Master 根据 Slave 状态调整同步策略（如限流或告警）。

RocketMQ的broker保留信息方式有两种：

（1）、重复消费的信息（这种信息有时长限制）

（2）、事务（消费者消费一次后消失）