RocketMQ整体工作流程_详解

原创 于 2025-12-22 13:45:00 发布 · 758 阅读 · 12 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#rocketmq #java #RocketMQ整体流程

RocketMQ 整体工作流程（端到端）详解：从发消息到消费落库

这篇文档讲清楚 RocketMQ “一条消息从生到死”的全过程：
Producer 怎么找 Broker、Broker 怎么存、Consumer 怎么拉、Offset 怎么提交、失败怎么重试/进 DLQ。
你看完应该能把 RocketMQ 的工作流画出来，并且能解释线上常见现象：堆积、重复消费、顺序、事务、延时。

目录

1. 一句话总览：RocketMQ 在干嘛

RocketMQ 做的事可以浓缩成：

Producer 把消息写到 Broker 的 CommitLog（并按 Topic/Queue 建索引），Consumer 从 Broker 按 Offset 拉消息处理，成功就提交 Offset，失败就重试，重试多了进 DLQ。

2. 核心角色与它们的职责

  • NameServer：存路由（Topic → Broker/Queue），无状态，可多节点
  • Broker：接收/存储/投递消息，维护索引、复制、刷盘、重试队列等
  • Producer：发消息，负责重试与选择队列（可自定义路由）
  • Consumer：收消息，负责处理、幂等、Offset、重试/死信处理
  • (可选) Proxy（5.x 常见）：接入层，统一协议/鉴权/多语言等

3. 端到端流程总图

(1) Broker 启动 -> 向 NameServer 注册路由/心跳
        |
        v
(2) Producer/Consumer 启动 -> 从 NameServer 拉取路由缓存
        |
        v
(3) Producer send(msg) -> 选择 Topic 的某个 Queue -> 直连 Broker 写入
        |
        v
(4) Broker 存储：CommitLog 顺序写 -> 构建 ConsumeQueue/Index -> 刷盘/复制 -> ACK
        |
        v
(5) Consumer 拉取：根据 (Topic,Queue,Offset) Pull -> Broker 读 ConsumeQueue/CommitLog 返回消息
        |
        v
(6) Consumer 处理业务 -> 成功提交 Offset / 失败进入重试 -> 多次失败进 DLQ
        |
        v
(7) Rebalance：组内实例变化 -> 队列重新分配 -> 消费者接管新队列从 Offset 继续

4. Producer 发送流程（从路由到 ACK）

4.1 启动与路由发现

Producer 启动时做几件事：

  1. 连接/配置多个 NameServer 地址
  2. 拉取 Topic 路由（包含：Topic 有哪些队列、队列在哪些 Broker 上）
  3. 缓存路由，并定期更新

注意：Producer 不会每次发消息都问 NameServer，而是用缓存 + 定时刷新，减少中心依赖。

4.2 选择队列（负载均衡）

Topic 一般有多个队列（MessageQueue）。Producer 发送时会：

  • 默认轮询/随机选择一个队列做负载均衡
  • 也可以按业务键（orderId）自定义选择队列（用于顺序消息）

队列是并行度单位：队列越多，理论并行度越高，但运维成本也越高。

4.3 发送与重试

发送流程（简化）：

  1. Producer 把 Message 发给选中的 Broker
  2. 若失败/超时：按策略重试（可能换 Broker/换队列）
  3. 达到重试上限仍失败：返回失败，由业务决定补偿（落库重发等）

生产重点：

  • 发送失败不要“吞掉”，必须日志 + 告警 + 补偿方案
  • 核心链路建议“落库+异步重试”做最终保障

4.4 Broker 返回成功到底代表什么

这点必须搞清楚，不然你会误以为“绝对不丢”。

Broker 返回成功通常代表：

  • 消息已经写入 Broker（至少进入内存/PageCache），并满足你的刷盘/复制策略

不同策略的可靠性不同：

  • ASYNC_FLUSH：返回成功时可能还没落盘（极端断电可能丢最后一段）
  • SYNC_FLUSH：返回成功代表已刷盘更稳
  • ASYNC_MASTER：复制可能滞后
  • SYNC_MASTER：主从确认后才成功（更稳）

5. Broker 存储流程（CommitLog → ConsumeQueue → Index）

RocketMQ 高吞吐的核心：顺序写 CommitLog + 索引分层。

5.1 CommitLog（顺序写）

Broker 收到消息后：

  1. 进行校验（Topic、权限、大小等）
  2. 追加写入 CommitLog（append-only）

CommitLog 是“真相”，所有消息最终都在这里。

5.2 ConsumeQueue（逻辑队列索引）

为了让 Consumer 能按 Topic/Queue/Offset 消费，Broker 会维护 ConsumeQueue：

  • ConsumeQueue 以 (Topic, QueueId) 组织
  • 每条记录指向 CommitLog 的 offset/size 等信息
  • Consumer 拉取时，先通过 ConsumeQueue 快速定位消息位置，再读 CommitLog

5.3 IndexFile（按 Key 查消息）

IndexFile 用于“按 key 查消息”（排障很常用）：

  • 你给 Message 设置 keys（如 orderId）
  • Broker 构建 key → commitlogOffset 的索引
  • Console/Admin 可以用 key 查询消息

5.4 刷盘与复制

消息写入后，还要考虑两件事：

  • 刷盘（Flush）：写到磁盘
  • 复制（Replication）：写到从节点/多副本

这两项决定“成功 ACK”到底有多稳。

6. Consumer 消费流程（拉取、处理、提交 Offset）

6.1 Pull 与“看起来像 Push”】【长轮询】

RocketMQ 的 PushConsumer 看起来像“Broker 推”，但本质仍然是：

Consumer 端循环 Pull + Broker 端长轮询（Long Polling）

长轮询的意义：

  • Broker 没新消息时不立刻返回，而是挂起一段时间，有新消息马上返回
  • 减少空轮询，降低延迟

6.2 消费成功：Offset 提交

消费进度 Offset 的概念：

  • 对每个队列都有一个当前 offset：(topic, queueId) -> offset
  • Consumer 拉取一批消息，从 offset 开始
  • 业务处理成功后，提交新的 offset

Offset 存在哪里？

  • 取决于版本与模式，常见是 Broker/本地存储/集中存储的组合（你不用死记，关键是理解：offset 决定“从哪继续”）

6.3 消费失败：重试与死信

消费失败的常见流程：

  1. 返回失败/抛异常
  2. RocketMQ 把消息进入重试机制（Retry Topic / 延迟重投）
  3. 超过最大重试次数仍失败 → 进入死信队列（DLQ）

重点：

  • RocketMQ 默认语义偏 至少一次 → 你必须幂等
  • DLQ 不是垃圾桶，必须有人处理（人工后台/自动补偿）

7. Rebalance（队列重新分配）发生了什么

Rebalance 触发条件很常见：

  • Consumer 实例增加/减少
  • Topic 队列数变化
  • 路由变化

Rebalance 结果：

  • 同一消费组内，队列重新分配给不同实例
  • 新接管的实例会从该队列的 offset 继续消费

Rebalance 对你意味着：

  • 会有短暂抖动（尤其是实例频繁伸缩）
  • 顺序消费要更谨慎（队列迁移会影响延迟与稳定性）

8. 三个特殊流程

8.1 顺序消息流程（分区顺序）

核心：同业务键 -> 同队列；同队列 -> 串行消费。

流程差异点：

  • Producer：使用 MessageQueueSelector 或 hashKey，把同一个 orderId 的消息路由到固定队列
  • Consumer：使用有序消费（队列级串行），失败会“暂停队列”重试，后续消息会被卡住

8.2 延时消息流程

延时消息的直觉：

  • 先存起来，不立刻可见
  • 到时间后再投递到真实队列供消费

注意：

  • 延时不是精确定时（更像“延后投递”）
  • 延时级别/实现机制不同版本略有差异，但总体流程一致

8.3 事务消息流程（半消息与回查）

事务消息要解决：本地事务与消息发送一致性。

流程（简化）：

  1. Producer 发送 半消息（Half Message）：Broker 先存，但不让 Consumer 看见
  2. Producer 执行本地事务（DB 更新等）
  3. Producer 发送 commit/rollback 给 Broker
  4. 如果 Broker 长时间没收到结果，会发起 事务回查（询问 Producer：到底成功了吗）
  5. Producer 根据本地事务状态返回 commit/rollback

9. 常见现象的“流程解释”

9.1 为什么会重复消费？

  • Consumer 处理成功但 offset 提交失败/超时
  • Consumer 处理超时被认为失败，触发重试
  • 网络抖动导致 ACK/提交丢失

所以必须幂等。

9.2 为什么会出现堆积（lag）？

  • Producer 写入速度 > Consumer 处理速度
  • Consumer 失败重试导致吞吐下降
  • Rebalance 抖动、消费者实例不足、下游依赖慢

9.3 为什么顺序消息会“卡住”？

  • 顺序消费失败会暂停当前队列重试
  • 一条毒消息会阻塞该队列后续消息

9.4 为什么“发送成功了”还可能丢？

  • ASYNC_FLUSH：成功可能没刷盘
  • ASYNC_MASTER：成功可能没复制到从节点
  • 机器瞬间掉电/磁盘损坏可能导致最后一段丢失

10. 生产建议：把流程跑稳

  1. 至少 2~3 台 NameServer
  2. Broker 选型要明确：吞吐优先还是不丢优先（刷盘/复制策略）
  3. Producer：失败重试 + 失败补偿（落库重发）
  4. Consumer：幂等 + 限制重试 + DLQ 处理闭环
  5. 监控必备：发送失败率、消费失败率、堆积、DLQ 增长、Broker 磁盘、复制滞后
  6. 定期演练：挂 Broker、断网络、磁盘写满、消费者全停

一句话复盘

RocketMQ 的整体工作流程可以记成这条链：

路由发现（NameServer） → 写入存储（Broker CommitLog） → 建索引（ConsumeQueue/Index） → 拉取消费（Consumer Pull/长轮询） → 成功提交 Offset / 失败重试进 DLQ → Rebalance 动态分配队列

RocketMQ消费流程深度解析：从原理到实践
sc35262的博客
09-21 893
启动阶段完成路由发现和队列分配，拉取阶段通过长轮询机制高效获取消息，处理阶段利用线程池并发消费，位点管理确保消息不丢失。其中ProcessQueue作为本地缓存，起到了承上启下的关键作用。配置优化要根据业务特点调整线程池、批量拉取等参数。性能调优需要平衡吞吐量和延迟，合理设置缓存阈值防止内存溢出。问题排查要关注消息堆积、重复消费、消费延迟等典型问题，建立完善的监控和告警体系。
RocketMQ的架构及其工作流程详解
weixin_45974176的博客
08-16 891
一文搞懂rocketmq的架构及其工作流程
RocketMQ 内容详解【一、RocketMQ 基础篇（入门与整体认知）】
NeoLshu的博客
09-18 1006
RocketMQ是一个起源于阿里巴巴MetaQ的高性能分布式消息中间件，现为Apache顶级项目。它解决了分布式系统中的耦合度高、流量削峰、异步处理和分布式事务等问题，广泛应用于电商、金融等领域。核心组件包括Producer、Consumer、Broker和NameServer，支持多种消息模型如发布订阅、点对点、顺序消息和广播消息。RocketMQ具有高吞吐、低延迟、高可靠等特点，通过Remoting模块实现高效网络通信，其架构设计适合大规模高可靠场景。
RocketMQ两万字详解
qq_26751319的博客
10-28 1822
目录简介1.RocketMQ搭建(基于linux)1.1 安装NameServer1.2 安装Broker1.3 控制台安装2 .集成Spring Boot测试2.1添加依赖2.2 添加yml配置2.3 添加生产者消费者代码3.了解RocketMQ的组件3.1 Broker3.2 Topic3.2.1 Tags3.3 NameServer3.4 Producer3.5 Consumer3.5.1 pull3.5.2 push3.6 Message Queue4.RocketMQ原理4.1 生产者4.1.1
RocketMQ-broker启动流程详解
龚厂长的博客
12-06 3039
本文基于RocketMQ 4.7.1版本 本文将从整体上分析broker如何启动。 文章目录一、broker启动1、createBrokerController()2、start() 一、broker启动 broker的启动类是BrokerStartup，其main方法如下： public static void main(String[] args) { start(createBrokerController(args)); } createBrokerControlle.
RocketMQ详解
刘皇叔说Java的博客
03-06 1615
阿里系下开源的一款分布式、队列模型的消息中间件，原名Metaq，3.0版本名称改为RocketMQ，是阿里参照kafka设计思想使用java实现的一套mq。同时将阿里系内部多款mq产品（Notify、metaq）进行整合，只维护核心功能，去除了所有其他运行时依赖，保证核心功能最简化，在此基础上配合阿里上述其他开源产品实现不同场景下mq的架构，目前主要多用于订单交易系统。RocketMQ 是一款分布式、队列模型的消息中间件，Apache Alibaba RocketMQ 是一个消息中间件。
rocketmq 消息指定_详解RocketMQ不同类型的消费者
weixin_39593277的博客
12-20 1514
原标题：详解RocketMQ不同类型的消费者云栖君导读：本文节选自云栖社区系列丛书《RocketMQ原理与实战解析》，作者：阿里巴巴数据专家杨开元。本节将重点讲解RocketMQ不同类型的消费者。根据使用者对读取操作的控制情况，分为两种类型。一个是DefaultMQPushConsumer，由系统控制读取操作，收到消息后自动调用传入的处理方法来处理；另一个是DefaultMQPullConsume...
RocketMQ事务消息流程与原理解析
流楚丶格念的博客
10-26 1290
RocketMQ的事务消息（Transactional Message）是一种确保应用程序本地事务与消息发送操作可以统一在一个全局事务中执行的机制。该机制确保要么本地事务与消息发送同时成功，要么同时失败。这种消息确保了分布式系统中消息和业务操作的一致性，适用于类似电商下单等场景。以电商系统为例，用户下单是一个核心操作，但同时还会涉及到多个下游子系统，如仓储、积分、购物车状态等。通常，在下单成功后，系统需要向这些子系统发送消息，以通知它们更新各自的状态。然而，如何确保下单成功的同时，消息也一定发送成功呢？这就
RocketMQ架构详解
刘皇叔说Java的博客
03-06 3454
文章目录概述RocketMQ架构Broker 高可用集群刷盘策略 概述 RocketMQ一个纯java、分布式、队列模型的开源消息中间件，前身是MetaQ，是阿里研发的一个队列模型的消息中间件，后开源给apache基金会成为了apache的顶级开源项目，具有高性能、高可靠、高实时、分布式特点。 RocketMQ是阿里开源的分布式消息中间件，跟其它中间件相比，RocketMQ的特点是纯JAVA实现；集群和HA实现相对简单；在发生宕机和其它故障时消息丢失率更低。 RocketMQ架构 ● Producer：
RocketMQ工作原理详解及开发实例
深圳市多克创新科技有限公司
10-16 1782
RocketMQ详解及开发用例
RocketMq学习视频
08-11
009-009_RocketMQ_整体架构概述详解 010-010_RocketMQ_Producer_API详解 011-011_RocketMQ_Producer_顺序消费机制详解 012-012_RocketMQ_Producer_事务消息机制详解 013-013_RocketMQ_Consumer_Push和Pull模式及使用...
JAVA-ACE-架构师系列视频教程在线观看地址- RocketMQ（订单实战上下全集）
09-01
9009_RocketMQ_整体架构概述详解 10010_RocketMQ_Producer_API详解 11011_RocketMQ_Producer_顺序消费机制详解 12012_RocketMQ_Producer_事务消息机制详解 13013_RocketMQ_Consumer_Push和Pull模式及使用详解 14014_...
rocketmq教程两套
05-29
009-009_RocketMQ_整体架构概述详解 010-010_RocketMQ_Producer_API详解 011-011_RocketMQ_Producer_顺序消费机制详解 012-012_RocketMQ_Producer_事务消息机制详解 013-013_RocketMQ_Consumer_Push和Pull模式及使用...
SpringBoot优雅的封装不同研发环境下（环境隔离）RocketMq自动ack和手动ack
qq_37557563的博客
08-12 2356
SpringBoot优雅的封装不同研发环境下（环境隔离）RocketMq自动ack和手动ack,并提供具体示例，亲测有效
车载系统应用开发集成系统API
yangyulong0622的博客
12-16 672
车载开发中，为了快速迭代常将系统应用剥离为普通应用开发，但调用系统API时反射效率低。解决方法是通过集成framework.jar，但会遇到编译报错问题。通用方案是在gradle中配置bootstrapClasspath引入jar包。当使用高版本JDK时，必须强制指定模块使用JDK8并关闭lint检查才能生效。关键步骤：先加载jar包到工程，再设置模块JDK版本为1.8。
Windows安装Maven
heqilai1的博客
12-17 234
Maven是一个基于POM模型的项目管理和构建自动化工具，其核心是通过一份配置文件，实现依赖管理和标准化的构建流程。对于Java开发者而言，Maven不是一个可选项，而是一个基础设施。它极大地降低了项目管理的复杂度，让开发者可以更专注于编写代码，而不是浪费时间在“搭建环境”和“寻找Jar包”上，Maven因其稳定、成熟和广泛的应用，至今仍是Java生态系统中最主流的构建工具。二、下载Maven https://maven.apache.org/download.cgi。至此Maven安装配置完成 😊😊。
MyBatis-Plus 单元测试中 Lambda Mock 的坑与解决
qq_43657722的博客
12-17 1220
本文总结了 MyBatis-Plus 在单元测试中使用 LambdaWrapper 时常见的 Lambda 缓存异常问题，分析其根源在于 Mock 环境缺失真实上下文。通过精简示例说明为何 any(LambdaWrapper.class) 易出错，并给出使用 any() 的稳定解决方案，强调单元测试应聚焦业务逻辑、避免过度关注 SQL 与 Lambda 细节。
JAVA设计模式之观察者模式
pingguocu3的博客
12-17 384
在我们开发的过程中，经常会遇到一些当什么什么事情发生的时候，然后做什么什么事。比如某种商品的物价上涨时会导致部分商家高兴，而消费者伤心。平台声明：文章内容（如有图片或视频亦包括在内）由作者上传并发布，文章内容仅代表作者本人观点，简书系信息发布平台，仅提供信息存储服务。著作权归作者所有,转载或内容合作请联系作者。
使用idea启动一个springboot项目
最新发布
qq_51389137的博客
12-19 1515
5.装配置maven配置到idea下载项目依赖。4.装navicat。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值