当前位置：首页 > wzjs >正文

做水果的网站百度浏览器官网

wzjs 2025/8/12 18:11:42

做水果的网站,百度浏览器官网,网站设计制作从哪里学起,css wordpress今天是2025/04/06 22:04 day 19 总路线请移步主页Java大纲相关文章今天进行RocketMQ 3,4,5 个模块的归纳首先是RocketMQ 的相关内容概括的思维导图 3. 存储机制 3.1 Commit Log 核心设计顺序写盘：所有消息（无论属于哪个 Topic/Queue&#xff0…

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