RocketMQ 复习

Wed, 18 Feb 2026 00:00:00 +0000

概述

- 概述
- 定位
- 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（推进进度）

可靠性、语义、幂等、重试、死信

性能与扩展、顺序与分区、堆积治理

存储与高可用

- 存储与高可用
- 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 日志复制，从而提高一致性并提供自动选主
- 代价：写路径更重，延迟更高，但一致性更强、切换更自动化

消息队列 on 安橙的博客

RocketMQ 复习

概述

核心概念

可靠性、语义、幂等、重试、死信

性能与扩展、顺序与分区、堆积治理

存储与高可用