今天是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 堆积情况，及时扩容或优化消费逻辑。
-
