免费签名设计软件迅速上排名网站优化
今天是2025/04/06 21:31 day 18
总路线请移步主页Java大纲相关文章
今天进行RocketMQ 1,2 个模块的归纳
首先是RocketMQ 的相关内容概括的思维导图
1. 核心组件
1.1 NameServer
-
核心功能
-
服务发现：作为轻量级注册中心，管理所有 Broker 的地址和路由信息，Producer/Consumer 通过 NameServer 动态获取 Broker 地址。
-
无状态设计：多个 NameServer 之间无数据同步，通过 Broker 周期性注册心跳维持路由表。
-
高可用保障：集群部署，单节点宕机不影响整体服务。
-
-
关键特性
-
低延迟：仅维护基础元数据（Topic-Broker 映射），不参与消息传输。
-
最终一致性：Broker 下线后，NameServer 通过心跳超时（默认30秒）剔除失效节点。
-
1.2 Broker
-
核心职责
-
消息存储：基于 Commit Log 顺序写盘，保证高吞吐量。
-
消息转发：根据 Consumer 拉取请求从 Commit Log 读取数据并分发。
-
高可用架构：主从模式（Master-Slave），支持 同步双写（强一致）和 异步复制（高性能）。
-
-
存储机制
-
刷盘策略：
-
同步刷盘（可靠但低吞吐）：消息写入内存后同步刷入磁盘，确保数据不丢失（适用于金融场景）。
-
异步刷盘（高吞吐）：消息写入内存后立即返回成功，异步批量刷盘（适用于日志类场景）。
-
-
主从同步：
-
异步复制：Master 异步复制消息到 Slave，存在短暂数据不一致风险。
-
同步双写：Master 同步等待 Slave 写入成功，保障强一致性（性能较低）。
-
-
-
扩展能力
-
分片存储：Topic 可划分为多个队列（Queue），分布在多个 Broker 上，实现水平扩展。
-
1.3 Producer
-
核心功能
-
消息发送：将消息发送到指定 Topic 的某个队列（Queue）。
-
负载均衡策略：
-
轮询（Round Robin）
-
哈希（Hash，保证相同 Key 的消息进入同一队列）
-
随机（Random）
-
-
-
发送模式
-
同步发送：等待 Broker 返回确认（ACK），保证消息可靠但延迟较高。
-
异步发送：通过回调函数处理结果，兼顾性能和可靠性。
-
单向发送（Oneway）：只管发送，不关注结果（适用于日志采集等低重要性场景）。
-
1.4 Consumer
-
消费模式
-
Push 模式（推荐）：Broker 主动推送消息给 Consumer，需设置合理的流控策略。
-
Pull 模式：Consumer 主动拉取消息，灵活性高但需自行控制频率。
-
-
消费方式
-
集群消费（Clustering）：同组 Consumer 分摊消费同一 Topic 的消息（每条消息仅被消费一次）。
-
广播消费（Broadcasting）：同组 Consumer 各自消费全量消息（适用于通知类场景）。
-
-
消息确认（ACK）
-
Consumer 消费成功后需返回 ACK，否则消息会重新投递（重试队列机制）。
-
2. 消息模型
2.1 主题（Topic）与标签（Tag）
-
Topic
-
消息的逻辑分类，生产者按 Topic 发送消息，消费者按 Topic 订阅消息。
-
支持多队列（Queue）分片，提升并发处理能力。
-
-
Tag
-
二级消息过滤标签，同一 Topic 下可通过 Tag 实现消息分类（如：订单Topic下分为支付Tag、发货Tag）。
-
消费者可订阅
Topic + Tag组合（支持 SQL表达式过滤），避免全量消息处理。
-
2.2 消息类型
| 消息类型 | 特性与场景 | 实现机制 |
|---|---|---|
| 顺序消息 | 保证同一队列内消息的严格顺序（如：订单状态变更） | 通过哈希策略将相同业务 Key 的消息路由到同一队列，消费者单线程顺序消费。 |
| 事务消息 | 实现分布式事务（如：支付成功后扣减库存） | 两阶段提交： 1. 发送 Half 消息（预提交） 2. 本地事务执行成功后提交消息。 |
| 定时/延时消息 | 消息在指定时间后投递（如：订单超时取消） | Broker 内置定时器，按延迟级别（1s/5s/10s…）存储到特定队列，到期后转发到目标Topic。 |
| 批量消息 | 一次发送多条消息，减少网络开销（如：日志批量上传） | Producer 将多条消息合并为一次请求发送，单批次消息大小需 ≤ 4MB。 |