RocketMQ 复习二月 18, 2026概述# - 概述 - 定位 - RocketMQ 是一个分布式消息中间件，用于在分布式系统中以异步方式传递时间/数据 - 典型问题 - 异步解耦 - 场景：下单后做扣库存、发优惠券、发短信、写审计日志 - 没用 MQ：下单接口串行调用 N 个下游 -> 延迟高、耦合重、下游挂了全挂 - 用 MQ：下单服务只负责写订单 + 发消息，下游异步消费，链路变短、隔离故障、便于扩展 - 削峰填谷 - 场景：大促瞬时 QPS 飙升，下游撑不住 - 用 MQ：把瞬时峰值写入 MQ，消费者按能力稳定拉取 -> 系统不被打爆 - 广播/集群消费 - 广播：配置刷新、缓存预热、全量通知 - 集群：订单履约、发货、对账（同组只要处理一次） - 顺序/延迟/事务 - 顺序：同一订单状态流转必须按照顺序处理 - 延迟：30 分钟未支付自动关单 - 事务：下单写库 + 发消息要一致性 - 领域模型 - Topic/MessageQueue（并发与顺序的载体） - Topic：逻辑分类 - MessageQueue（队列/分区）：Topic 下的物理分片 - 并发的本质：多个队列=>多个消费者实例并行消费 - 顺序的边界：只保证同一队列内有序，跨队列无需 - 原因：MessageQueue 带来了水平扩展吞吐（分片并行）+提供队列内顺序语义 - Producer 生产者 - 生产者发送消息时，核心要决定：这条消息进入哪个队列 - 普通消息：轮询/负载均衡选择队列（提升吞吐） - 顺序消息：按业务 key 做一致性路由到同一队列，保证顺序 - ConsumerGroup 消费组 - 消费组：一组消费者实例共享同一套消费进度 - 集群消费：同组内分摊队列 - 广播消费：每个实例都处理全量消息 - 同一个 Topic，两个不同的 ConsumerGroup 相当于两套独立的订阅者，各自消费一份完整消息流 - 卖点 - 高吞吐 - 顺序写：消息落到 CommitLog -> 磁盘友好 - 零拷贝/高效网络传输：减少内核态/用户态拷贝开销 - 批量与异步：批量写入、批量拉取、异步刷盘/复制 - 读写分离：写走 CommitLog，读通过索引定位 - 可扩展 - Topic 多队列 -> 消费端扩容实例可提升并发 - Broker 集群扩容 -> 分摊存储与 I/O 压力 - NameServer 做路由发现 -> Producer/Consumer 动态感知集群变化 - 靠队列分片 + Broker 横向扩展 + 消费组负载均衡 - 语义能力 - 至少一次投递与重复消费 - RocketMQ 工程实践通常是至少一次：可能重复，但不丢 - 业务必须幂等 - 重试与死信 - 消费失败 -> 重试 - 达到最大次数仍然失败 -> 进入死信队列 - 生产实践：DLQ 监控高进 + 人工/自动补偿 + 重新投递 - 事务消息（最终一致性） - 目标：本地事务与消息发送一致 - 核心机制：半消息（先存 broker 不投递）-> 本地事务 -> commit 才投递；不确定则回查 - 它解决的是最终一致性，不是强一致 ACID 核心概念# - 核心概念 - Topic - 定义：消息的逻辑分类，Producer 发送到 Topic，Consumer 订阅 Topic。 - 关键点：Topic 本身不决定并发，并发来自 Topic 下的 MessageQueue 数量 - 一个 Topic 通常会在多个 Broker 上分布存储，每个 Broker 上持有一些队列分片 - MessageQueue - 定义：Topic 的物理分片，是投递与顺序的基本单元。 - 并发能力=队列数上限：同哦个 ConsumerGroup 里，一个队列同一个时刻只会被一个消费者实例消费 - 顺序边界：RocketMQ 的顺序语义通常是队列内有序，跨队列不保证 - 路由载体：Producer 发送时必须选择一个队列（轮询/哈希/自定义） - Producer 生产者 - 职责：构造消息、选择 Topic 队列、发送、处理失败重试 - Producer 会先拿到 Topic 的路由信息（队列分布在哪些 Broker） - 发送失败通常会重试/换 Broker（取决于客户端策略与路由状态） - 发送模式 - 同步：拿到 sendResult 才返回（最常用） - 异步：回调（高吞吐/低延迟） - 单向：不关心结果（日志/打点） - Consumer（消费者） - 职责：拉取消息（Pull 体系，Push 是封装）、本地处理、成功后提交 offset，失败触发重试 - RocketMQ PushConsumer 本质是客户端内部循环 Pull + 回调你业务代码 - 消费并发：由消费线程数 + 队列分配决定 - ConsumerGroup（消费组） - 定义：一组消费者实例，共享同一套消费进度（offset），一起消费 Topic。 - CLUSTERING（集群消费）：同组分摊消费（每条只处理一次） - BROADCASTING（广播消费）：每个实例都处理全量（各自进度） - NameServer - 定位：路由注册与发现（轻量注册中心，不像 Kafka 把协调状态放在上面） - Broker 启动后像 NameServer 注册：Topic -> Broker -> 队列信息 - Producer/Consumer 定期从 NameServer 拉取最新路由 - NameServer 挂了是否可以发消息 - 短期通常能发（客户端还有路由缓存），但路由无法更新；长期不行，且新 Topic/新 Broker 不可见。 - Broker - 职责：接收消息，持久化存储，为消费者提供拉取、维护消费进度相关能力、做复制。 - 消息一般先写 CommitLog （顺序写），再构建队列索引。 - 吞吐高的原因：顺序写+批量+高效 IO 路径 - Offset （消费进度） - 定义：ConsumerGroup 在每个 MessageQueue 上的消费位置 - 成功消费 -> 提交 offset - 失败 -> 不提交 -> 后续重试/再次提交 - 数据流 - 生产链路 - 拿路由 - Producer 启动后从 NameServer 拉取 Topic 路由：有哪些 Broker、每个 Broker 上有哪些队列 - 选队列 - Produer 根据策略选择一个 MessageQueue - 普通消息：轮询/负载均衡 - 顺序消息：按业务 key 哈希到固定队列 - 发送到 Broker - Producer 把消息发送到队列所在 Broker - 持久化与应答 - Broker 持久化成功后返回 sendResult，Producer 认为发送成功 - 消费链路 - 订阅与分配 - Consumer 加入 ConumserGroup，订阅 Topic - 在集群模式下，同组实例会进行队列分配：每个 MessageQueue 分配给某个实例 - 拉取 - 被分配到队列的 Consumer 维护该队列的 offset，向 Broker 发起拉取请求 - 拉取这个队列从 offset=N 开始的下一批消息 - 本地处理 - Consumer 收到消息后调用你的业务处理逻辑（线程池并发执行） - 提交 Offset - 业务成功 -> 提交 offset（推进进度） 可靠性、语义、幂等、重试、死信# - 可靠性/语义/幂等/重试/死信 - 消息语义 - 三种语义 - At-most-once（至多一次）：不重复，但可能丢 - At-least-once（至少一次）：尽量不丢，但可能重复（RocketMQ 采用） - Exactly-once（恰好一次）：不丢不重 - 为什么会重复 - 本质：分布式不确定性，无法在网络超时常见里判断对方是否已经成功 - 生产端导致重复：超时不等于失败 - Producer 发出了 send 请求 - Broker 实际写成功了，但 ack 在路上丢了/Producer 超时 - Producer 认为失败 -> 重试发送 - Broker 上存在两条业务等价消息 - 消费端导致重复：处理成功但提交 offset 失败/延迟 - Consumer 拉到消息并执行成功 - 在提交 offset 前发生进程重启/网络抖动/提交失败 - 下次启动从旧 offset 拉 -> 同一消息再次被处理 - 重试与死信：失败后到底怎么流转 - 消费失败 -> 重试：两类消费方式的区别 - 并发消费：消息可并行处理；失败后会触发稍后重投 - 顺序消费：同队列内严格顺序；失败会卡住队列，知道成功或打到策略 - 重试次数与延迟 - 消费失败后，消息会进入“重试主题/重试队列“ - 每次重试都会有一定的延迟 - 达到最大重试次数后仍然失败 -> 进入死信队列 - DLQ 常见命名 %DLQ%<ConsumerGroup> - DLQ 工程治理 - 监控报警 - DLQ 堆积量、进入 DLQ 的速率、重试次数分布、消费失败率 - 分类原因 - 可重试：下游超时、偶发网络、锁冲突 - 不可重试：参数非法、业务校验失败、数据缺失 - Offset 管理 - Offset 是什么 - Offset 是 ConsumerGroup 在每个 MessageQueue 上的消费位置 - 不是全局一个值，而是 (group,topic,queueId) -> offset - 正确提交时机 - 处理成功后再提交 性能与扩展、顺序与分区、堆积治理# - 性能与扩展、顺序与分区、堆积治理 - 吞吐与并发怎么调 - 吞吐链路拆解，多个环节的 min - Producer 发送能力 - Broker 写入能力 - Consumer 拉取与处理能力 - 队列分片与分配：队列数决定 - 并发的硬上限：Queue 数决定可扩展性 - 集群消费模式下，同一个 ConsumerGroup 内，一个 MessageQueue 同一时刻只会分配给一个消费者实例 - 有效消费实例并行度 <= 队列数 Q - 有 C 个实例：有效利用 = min(Q,C) - 线程数只能提高单实例处理并行，队列数太少时，扩容实例不涨吞吐 - 调整的三类杠杆 - 队列数 - 现象：加消费者实例吞吐不涨/涨很少 - 原因：Q 太小，很多实例分不到队列 - 操作：提高 Topic 队列数 - 消费者实例数 - 前提：Q 足够 - 收益：线性提升 - 消费者线程数/批量参数 - 适用 Q 足够但实例受限或业务处理轻的场景 - 堆积定位 - 堆积的数学本质 - 堆积增长 = 生产速率 > 消费速率，差值积累在 broker - 堆积原因分类 - 消费变慢 - 失败重试太多 - 生产突增 - Broker 压力抖动 - 堆积排查步骤 - 确定堆积是全局还是局部 - 如果是局部队列对接，大概率是热点 key/顺序路由/某实例异常 - 消费失败率与重试量 - 失败率高 -> 先止血，否则越修越崩 - 识别同一类异常栈是否集中 - 看单消息处理耗时分布 - 平均不重要，重点看 p95/p99 - p99 高往往来自：慢 SQL、远程调用尾延迟、锁竞争 - 看下游容量 - 看队列数与分配 - 看 Broker 层资源 - 堆积治理手段 - 止血 - 限流生产端：控制入口 - 失败隔离：把异常消息旁路到补偿 Topic/DLQ，避免拖垮主消费 - 降级业务逻辑：先做核心动作，其他异步/延后 - 恢复吞吐 - 扩容消费者实例 - 提高批量拉取/批量处理 - 优化热点：把热点 key 拆散 - 若某些队列极端堆积：考虑迁移/重新分配队列所在 broker - 根治 - 优化热点：慢 SQL、缓存、异步化、批处理 - 调整队列数与 key 策略 - 建立 DLQ/补偿闭环与告警 - 压测与容量规划：明确峰值可承受的 TPS 与延迟 存储与高可用# - 存储与高可用 - Broker 存储核心 - 三类文件 - CommitLog：消息本体的唯一真相源 - 所有 Topic 的消息都会追加吸入 CommitLog（不是每个队列一个日志，而是统一日志） - 写入模型是 append-only（追加写），是 RocketMQ 的高吞吐基础之一 - ConsumeQueue：面向消费的队列索引 - 消费者按照 MessageQueue 语义来消费，CommitLog 是全局混合写入的，需要一个队列视角的索引结构把队列映射回 CommitLog - ConsumeQueue 的本质是：每个 (topic, queueId) 一套逻辑队列索引，记录这条队列消息在 CommitLog 的物理位置等信息 - ConsumeQueue 是可重建的-Broker 异常后基于 CommitLog 恢复并重建缺失的 ConsumeQueue 索引，因此 ConsumeQueue 对绝对不丢要求没那么高 - IndexFile：按 key 查询的哈希索引 - 用于按 message key 做快速查询 - 写入流程 - 流程 - Producer 把消息发送到 Broker - Broker 顺序追加写 CommitLog - 再异步/批量地更新 ConsumeQueue/IndexFile - 原因 - 顺序写 CommitLog 最快 - 索引可以延迟/批量构建，并且 ConsumeQueue 丢了也能重建 - 读取链路 - 消费者按队列 (topic, queueId) 消费 - Consumer 拉取时携带 offset - Broker 通过 ConsumeQueue 把队列 offset 映射到 CommitLog 的物理位置 - 再从 CommitLog 把消息读出来返回给 Consumer - 吞吐高：顺序写+mmap+零拷贝+批量 - 顺序写：CommitLog append-only 模式写磁盘 - mmap 内存映射与 MappedFile 抽象 - Broker 用 mmap 把文件映射为虚拟内存，写入像写内存一样，减少传统 read/write 的系统调用与拷贝成本 - 零拷贝方向 - 批量 - 批量写入、批量拉取能显著摊薄网络往返与系统调用开销 - HA：复制、切换、延迟与一致性取舍 - 传统 Master/Slave：复制延迟与一致性 - Master 负责写入，Slave 复制数据做冗余 - 关键变量：复制是同步还是异步，直接决定 - RPO（数据丢失窗口）：异步复制可能丢失最近一段 - RTO（恢复时间）：切换/重连需要时间 - 自动主从切换：Controller - Controller：把谁是主、怎么选主、怎么切这个协调逻辑集中管理，从而支持自动故障转移 - 切换时关注 - 选主/仲裁机制 - 路由更新 - 复制进度 - 业务容忍度 - RocketMQ-on-DLedger(Raft)：更强一致的 HA 思路 - DLedge 把 CommitLog 的复制变成 Raft 日志复制，从而提高一致性并提供自动选主 - 代价：写路径更重，延迟更高，但一致性更强、切换更自动化