RocketMQ 02

 今天是2025/04/06 22:04 day 19

总路线请移步主页Java大纲相关文章

今天进行RocketMQ 3,4,5 个模块的归纳

首先是RocketMQ 的相关内容概括的思维导图

​

3. 存储机制

3.1 Commit Log

• 核心设计

  • 顺序写盘：所有消息（无论属于哪个 Topic/Queue）按到达顺序追加到 Commit Log 文件，最大化磁盘写入性能。

  • 物理存储：消息原始内容存储在此，文件名按偏移量命名（如 00000000000000000000）。

• 优势与限制

  • 优势：避免随机写磁盘，吞吐量可达百万级 TPS。

  • 限制：需依赖索引文件（Consume Queue）快速定位消息。

3.2 消息索引

• Consume Queue

  • 逻辑队列索引：每个 Topic/Queue 对应一个 Consume Queue 文件，存储消息在 Commit Log 中的物理偏移量、消息大小和 Tag 哈希值。

  • 快速消费：Consumer 通过读取 Consume Queue 的索引快速定位 Commit Log 中的消息。

  • 分片存储：单个 Consume Queue 文件大小固定（默认 600 万条索引），滚动生成新文件。

• Index File

  • 关键词检索：支持通过消息 Key 或时间范围快速检索消息（类似数据库索引）。

  • 存储结构：哈希索引 + 时间范围索引，牺牲空间换查询效率。

3.3 存储优化策略

• 页缓存（Page Cache）

  • Broker 优先将数据写入 OS 页缓存，由操作系统异步刷盘，减少磁盘 I/O 压力。

• 内存映射（MappedFile）

  • 使用 MappedByteBuffer 将文件映射到内存，实现零拷贝（Zero-Copy）读取。

• 过期清理

  • 默认保留 3 天消息，通过后台线程删除过期 Commit Log 和索引文件。

---

4. 高可用机制

4.1 主从同步

• 同步模式

  模式	特点	适用场景
  异步复制	Master 写入成功后立即响应，异步复制到 Slave，存在数据丢失风险。	高吞吐场景（如日志收集）
  同步双写	Master 需等待 Slave 写入成功后才响应，强一致性，但延迟较高。	金融交易、订单核心业务

• 故障切换

  • 自动切换：Slave 检测 Master 宕机后，自动升级为 Master（需配合 NameServer 路由更新）。

  • 数据恢复：Slave 切换后从旧 Master 的未同步数据中恢复（需配置数据同步策略）。

4.2 Dledger（分布式一致性协议）

• 核心原理

  • 基于 Raft 协议，实现多副本数据强一致性和自动选主。

  • 所有写请求需经 Leader 节点确认，同步复制到多数节点（Quorum）后才返回成功。

• 关键能力

  • 自动选主：Leader 宕机时，剩余节点通过选举产生新 Leader。

  • 数据强一致：避免主从异步复制的数据丢失风险。

  • 部署模式：需至少 3 节点组成 Dledger 集群（推荐奇数节点）。

4.3 容灾设计

• 消息重试

  • 消费失败重试：若 Consumer 消费失败，消息会被放入重试队列（%RETRY%），按延迟等级（1s/5s/10s…）重新投递。

  • 最大重试次数：默认 16 次，超过后消息进入死信队列（%DLQ%）。

• 死信队列（DLQ）

  • 存储多次重试失败的消息，需人工干预处理（如排查异常原因后重新投递）。

  • 死信 Topic 命名规则：%DLQ% + ConsumerGroup。

---

5. 运维管理

5.1 管理工具

• mqadmin 命令行工具

  • 常用命令：

    • 创建/删除 Topic：mqadmin updateTopic

    • 查看 Broker 状态：mqadmin brokerStatus

    • 查看消费进度：mqadmin consumerProgress

  • 动态配置：支持运行时修改 Broker 参数（如刷盘策略、主从同步模式）。

• Dashboard 可视化控制台

  • 核心功能：

    • 集群状态监控（Broker、Topic、Consumer Group）

    • 消息轨迹追踪（查询消息发送/消费路径）

    • 配置管理和告警设置

5.2 监控与告警

• 监控指标

  指标类型	监控项	告警阈值建议
  Broker	CPU/内存/磁盘使用率、写入TPS、堆积消息量	磁盘使用率 >80% 或堆积量 >1万
  Consumer	消费TPS、消费延迟时间、失败重试次数	消费延迟 >1分钟 或失败率 >5%
  网络	连接数、网络吞吐量	连接数突增或突降 50% 以上

• 告警集成

  • 支持对接 Prometheus + Grafana 或企业微信/钉钉告警机器人。

5.3 运维最佳实践

• 容量规划

  • 根据业务峰值流量预留 2 倍以上 Broker 资源（防止突发流量）。

  • 单个 Topic 的队列数（Queue）建议为消费者数量的 2~3 倍。

• 日常维护

  • 定期清理过期 Commit Log 文件（避免磁盘占满）。

  • 监控 Consumer 堆积情况，及时扩容或优化消费逻辑。