RocketMQ 核心详讲（重点标粗，精简实用版）

原创 于 2026-05-28 11:36:46 发布 · 625 阅读 · 5 ·
本内容遵循CC 4.0 BY-SA版权协议
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
GEO检测
标签
#rocketmq #java中间件

一、整体定位 & 核心特点（必背重点）

RocketMQ 是阿里开源分布式消息中间件，主打高吞吐、高可用、低延迟、事务消息、顺序消息、重试队列，广泛用于异步解耦、流量削峰、消息推送、分布式事务。

核心优势（重点）

  1. 高吞吐：单机支持十万级 TPS，磁盘顺序写优化
  2. 高可用：主从架构、集群部署，支持故障自动切换
  3. 消息类型丰富：普通消息、顺序消息、延时消息、事务消息、重试 / 死信消息
  4. 可靠投递：消息持久化、ACK 确认、重试机制，保证不丢消息
  5. 轻量易运维：架构简单，部署、扩容、监控友好

二、整体架构（核心重中之重）

1. 四大核心组件（必记）

（1）NameServer 名称服务器
  • 作用：路由注册、路由发现，轻量级注册中心
  • 特点：无状态、可集群部署（多节点保证高可用）
  • 流程：Broker 主动上报路由信息 → 生产者 / 消费者先连 NameServer 获取 Broker 地址，再直连 Broker
（2）Broker 消息服务器（核心存储节点）

整个 RocketMQ 最核心角色，负责消息接收、存储、转发、推送。

  • 角色划分：
    • Master 主节点：读写都支持，负责接收生产消息
    • Slave 从节点：只读不写，同步 Master 数据，做负载 & 容灾
  • 部署模式：主从架构（1 主多从），支持异步 / 同步双写
  • 端口：
    • 对外通信端口：默认 10911
    • HA 主从同步端口：默认 10912
（3）Producer 消息生产者
  • 负责发送消息到 Broker
  • 集群模式：支持集群部署，负载均衡发消息
  • 发送模式（重点）：同步发送、异步发送、单向发送
（4）Consumer 消息消费者
  • 负责消费 Broker 推送的消息，也就是 MQ 监听端
  • 两种消费模式（高频考点 / 业务重点）
    1. 集群消费（默认）：同组消费者负载均衡，一条消息只被一个实例消费
    2. 广播消费：同组所有消费者全量接收同一条消息
  • 消费方式：主动拉取 (Pull) / 服务端推送 (Push)，日常多用 Push

2. 架构流转全景（精简）

生产者 → NameServer 获取 Broker 路由 → 直连 Broker 存消息消费者 → NameServer 获取 Broker 路由 → 直连 Broker 拉 / 推消息

重点：生产者、消费者不直接互相通信，全程只和 Broker 交互

三、消息模型 & 消息结构（业务使用核心）

1. 基础概念（重点）

（1）Topic 主题
  • 消息分类标识，同一业务消息归到一个 Topic
  • 逻辑概念，Broker 上物理分片存储
（2）Message Queue 消息队列（分区）
  • Topic 的物理分片，一个 Topic 拆分为多个 Queue
  • 作用：并发读写、实现顺序消息、负载均衡
  • 顺序消息依赖：单 Queue 内消息有序，多 Queue 无法全局有序
（3）ConsumerGroup 消费者组（日志里出现的重点）

plaintext

00000000000000000000000000000477_T_APPAY_PAYMENT_ACTIVITY_STATUS_DATA_PRO_sub-payment-group
  • 同一类消费者归为一个消费组
  • 规则：
    • 集群消费：组内实例均分 Queue，提高消费并发
    • 消费位点（Offset）：消费组独立维护位点，不同组互不影响
（4）Offset 偏移量
  • 消息消费位置标记，记录当前消费到队列的第几条
  • 持久化在 Broker，重启服务不会重复从头消费（正常情况）

2. 完整消息结构

  • 消息主体 Body + 消息唯一标识 MsgId + 自定义属性（Tags、Keys 等）
  • Tag 标签：Topic 内消息二次过滤，消费端按需筛选

四、消息投递 & 消费机制（可靠性核心）

1. 消息发送流程

  1. 生产者组装消息 → 路由寻址到 Broker
  2. Broker 接收消息 → 磁盘持久化（CommitLog）
  3. 返回投递结果给生产者

2. 消息存储机制（重点）

三大存储文件：

  1. CommitLog：所有消息统一物理存储文件（核心），顺序写，性能极高
  2. ConsumeQueue：逻辑队列索引，记录消息在 CommitLog 的位置
  3. IndexFile：消息索引文件，支持按 Key / 时间检索

核心特性：磁盘顺序写 + 内存页缓存，是 RocketMQ 高吞吐的根本

3. 消费可靠性（保证消息不丢、不重复）

（1）消费 ACK 机制（关键）
  • 消费者成功执行业务后，手动 / 自动提交 Offset
  • 未提交 ACK：Broker 判定消费失败，重试投递
（2）消息重试队列
  • 消费失败的消息，不会直接丢弃，进入重试队列
  • 有重试次数上限，超过次数转入死信队列 (DLQ)
  • 死信消息：人工排查处理，不再自动重试
（3）重复消费问题
  • 网络抖动、ACK 丢失会导致消息重复
  • 业务解决方案：接口幂等性（唯一主键去重）

五、五大消息类型（业务开发必用重点）

1. 普通消息

最基础，无顺序、无延时，通用异步场景。

2. 顺序消息（高频重点）

  • 分类：全局顺序、分区顺序（常用）
  • 实现原理：同一类有序消息发送到同一个 MessageQueue
  • 限制：单 Queue 串行消费，并发下降

3. 延时消息

消息投递后，延迟指定时间再被消费（定时场景）

  • 不支持任意时间，内置延时等级（1s~2h 档位）

4. 批量消息

多条消息打包发送，提升吞吐，注意单批大小限制。

5. 事务消息（RocketMQ 特色重点）

实现分布式事务最终一致性，半消息 + 回查机制，解决跨服务事务问题。流程：半消息发送 → 执行本地事务 → 提交 / 回滚消息 → 定时回查补状态。

六、高可用设计（运维 & 架构重点）

  1. NameServer 集群：多节点部署，单点故障不影响路由
  2. Broker 主从集群
    • Master 宕机：Slave 接管读请求，保证消费不中断
    • 同步双写：主从同时落盘，防止消息丢失
  3. 消息持久化：断电 / 重启消息不丢失
  4. 故障重试：生产、消费失败均有重试机制

七、结合日志的对应解读（落地对照）

  1. RocketmqRemoting：RocketMQ 原生 Netty 通信层，负责客户端与 Broker（10.62.212.65:10911）长连接
  2. NettyClientWorkerThread：RocketMQ 客户端网络线程
  3. closeChannel：应用优雅停机 → 消费者 Bean 执行 close () → 主动断开与 Broker 的长连接
  4. 消费组：日志中超长串即为 ConsumerGroup，用来区分消费实例、维护消费位点

关键总结：看到的 “监听关闭”= 应用进程退出，RocketMQ 客户端主动断开长连接，并非 MQ 服务端故障。

八、高频核心考点 / 总结（极简背诵版）

  1. 四大组件：NameServer、Broker、Producer、Consumer
  2. 核心存储：CommitLog（主存储）+ ConsumeQueue（索引）
  3. 分组概念：Topic（大类）、Tag（小过滤）、ConsumerGroup（消费组）
  4. 消费模式：集群消费、广播消费
  5. 可靠性保障：持久化、ACK、重试队列、死信队列、主从架构
  6. 特色能力：顺序消息、延时消息、事务消息
  7. 本质：消费者是客户端长连接，不监听本地端口，主动连接 Broker 服务端口。
RocketMQ核心概念
聊聊学习到的技术和工作中遇到的问题
01-16 979
RocketMQ的核心概念的介绍，主要从架构（Nameserver, broker），生产者(事务消息，定时消息)和消费者（消息订阅模式，消费模式，消息队列负载均衡，重平衡，消费模型，消息过滤）的角度来说明
RocketMQ核心概念详解
IAtlantiscsdn的博客
09-15 956
MQ：MessageQueue，消息队列。是在互联网中使用非常广泛的一系列服务中间件。这个词可以分两个部分来看，一是Message：消息。消息是在不同进程之间传递的数据。这些进程可以部署在同一台机器上，也可以分布在不同机器上。二是Queue：队列。队列原意是指一种具有FIFO(先进先出)特性的数据结构，是用来缓存数据的。对于消息中间件产品来说，能不能保证FIFO特性，尚值得考量。但是，所有消息队列都是需要具备存储消息，让消息排队的能力。
第01讲：RocketMQ入门
分享日常工作技术
05-16 809
​ 消息队列中间件是分布式系统中重要的组件，主要解决应用耦合，异步消息，流量削锋等问题。实现高性能，高可用，可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件。目前在生产环境，使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ等。
RocketMQ
qq_41893505的博客
10-07 2903
漏消费问题：通过消费进度管理、重试机制和消息持久化，RocketMQ 能有效防止漏消费。重复消费问题：虽然 RocketMQ 保证至少一次投递，但消费者需要通过幂等性设计来避免重复消费对业务造成的影响。事务消息机制：RocketMQ 提供的事务消息机制可以帮助在分布式事务场景中，确保消息消费的准确性和一致性。通过以上机制，RocketMQ 在高可靠性消息系统中提供了强大的保障，防止消息漏消费和重复消费问题。管理 事务消息。
RocketMQ-RocketMQ⾼性能核心原理与源码剖析（上）
weixin_43874650的博客
12-06 991
实际上，在应用中，可以通过producer.setSendMessageWithVIPChannel(true)，让少量比较重要的producer走VIP的通道。这个Cotroller对象就跟MVC中的Controller是很类似的，都是响应客户端的请求。我们现在不需要了解这些核心组件的具体功能，只要有个大概，Broker中有一大堆的功能组件负责具体的业务。​ 从NameServer启动和关闭这两个关键步骤，我们可以总结出NameServer的组件其实并不是很多，整个NameServer的结构是这样的；
RocketMQ-核心篇(2)-核心概念
TianXinCoord的博客
05-15 1万+
文章目录一、消息模型（Message Model）二、消息生产者（Producer）三、消息消费者（Consumer）四、主题（Topic）五、代理服务器（Broker Server）六、名字服务（Name Server）七、拉取式消费（Pull Consumer）八、推动式消费（Push Consumer）九、生产者组（Producer Group）十、消费者组（Consumer Group）十一、集群消费（Clustering）十二、广播消费（Broadcasting）十三、普通顺序消息（Normal
消息中间件第八讲：消息队列 RocketMQ 版实战、集群及原理
Jet_qi的博客
11-12 1434
是用于监控 RocketMQ broker 端和客户端所有相关指标的系统，通过mqAdmin从 broker 端获取指标值后封装成 87 个 cache。获取监控指标的流程如下图所示，Expoter 通过 MQAdminExt 向 MQ 集群请求数据，请求到的数据通过 MetricService 规范化成 Prometheus 需要的格式，然后通过 /metics 接口暴露给 Promethus。
RocketMQ核心技术精讲-----初识RocketMQ与快速上手
双吉堡工程专业的一名27届Javaer。
10-24 1166
RocketMQ核心技术精讲-----初识RocketMQ与快速上手
RocketMQ源码构建和重点解读
沮丧的南瓜
08-29 603
文章目录一、源码环境搭建1 源码拉取2 源码调试2.1 启动NameServer2.2 启动Broker2.3 发送消息2.4 消费消息2.5 如何看源码 一、源码环境搭建 1 源码拉取 RocketMQ的官方Git仓库地址：https://github.com/apache/rocketmq 可以用git把项目clone下来或者直接下载代码包。 也可以到RocketMQ的官方网站上下载指定版本的源码： http://rocketmq.apache.org/dowloading/releases/ 下载
19、RocketMQ核心源码解读
srrsheng的博客
06-27 1200
⼀。
终于有人把RocketMQ讲明白了。
Java大将军的博客
11-11 493
消息队列（RocketMQ）作为高并发系统的核心组件之一，能够帮助业务系统解构提升开发效率和系统稳定性。 RocketMQ 是一款分布式、队列模型的消息中间件，具有以下特点： 能够保证严格的消息顺序 提供丰富的消息拉取模式 高效的订阅者水平扩展能力 实时的消息订阅机制 亿级消息堆积能力 选择 RocketMQ 的理由： 强调集群模式无单点，可扩展，任意一点高可用，水平扩展 海量数据的堆积能力，消息堆积后，写入延迟低 支持上万个队.
RocketMQ第一讲
m0_58478012的博客
06-24 228
RocketMQ第一讲 消息中间件 应用场景 异步通信   有些业务不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。 解耦   降低工程间的强依赖程度，针对异构系统进行适配。在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。通过消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口，当应用发生变化时，可以独立的扩展或修改两边的处理过程，只要确保它们遵守
RocketMQ 面试核心知识点总结
2403_85207115的博客
01-23 885
环节方案代价生产者同步发送 + 重试降低吞吐Broker同步刷盘 + DLedger 集群IO / 网络负担增加消费者同步处理 + 确认无法异步提升效率集群故障降级缓存增加存储成本多次处理同一消息，业务结果一致（不重复创建订单、不重复扣款）
RocketMQ核心知识点
先度过菜鸟阶段
11-11 932
优先级问题核心要点⭐⭐⭐⭐⭐RocketMQ架构4个组件、职责、通信方式⭐⭐⭐⭐⭐消息可靠性3个维度、刷盘、主从复制、重试⭐⭐⭐⭐⭐消息存储CommitLog、ConsumeQueue、顺序写⭐⭐⭐⭐⭐消息堆积原因、应急方案、预防措施⭐⭐⭐⭐⭐事务消息Half消息、本地事务、回查机制⭐⭐⭐⭐消息顺序分区顺序、MessageQueueSelector⭐⭐⭐⭐消费模式集群消费、广播消费⭐⭐⭐⭐高可用Dledger、主从切换⭐⭐⭐延迟消息。
深入解析RocketMQ的源码，从NameServer说起！
热门推荐
小威的博客
02-17 1万+
前面的文章中介绍了RocketMQ一些用法和特性（优点，集群等），接下来的文章咱们一起了解下RocketMQ的源码。NameServer 是RocketMQ的核心组件之一，咱们先拿NameServer“开刀吧”。这篇文章主要围绕和！！在前面的文章中，我们已经介绍过NameServer的作用了，为了让大家了解的更全面，在这里再给NameServer一个特写！！！Broker 启动时会向 NameServer 注册（重点），NameServer 会维护 Broker 的数据信息。
RocketMQ源码(1)—RocketMQ源码调试环境准备
终生学习践行者
04-29 3410
详细介绍了RocketMQ 4.9.3 分支的源码调试环境搭建等一系列准备工作。
rocketmq 的核心概念讲解
qq_33803292的博客
11-05 976
Spring Cloud Stream 是更高层次的抽象，通过“绑定器（Binder）”适配不同消息中间件，屏蔽底层差异，适合微服务架构中统一消息编程模型。基于 Spring Boot 封装，通过注解简化配置，自动管理生产者/消费者生命周期，适合 Spring Boot 项目快速集成。原生客户端直接调用 RocketMQ 底层 API，需手动管理生产者/消费者生命周期，适合对底层细节有强控制需求的场景。这些可选概念用于增强消息的灵活性和可维护性，但不影响消息的基本传输流程。
【MQ】你知道RocketMQ与Kafka的核心差异有哪些吗?提供面试速记版
最新发布
小冷coding的博客
02-28 830
本文对比了RocketMQ与Kafka的核心特性，并针对消息中间件的常见异常提供了解决方案。RocketMQ侧重金融级可靠性和低延迟，支持事务消息；Kafka则更适合大数据场景的高吞吐需求。文章详细分析了消息丢失、重复消费、消息堆积等问题的成因，给出了具体的技术应对措施，包括同步刷盘、幂等处理、水平扩展等。同时结合供应链金融等实际项目场景，展示了如何应用这些解决方案保障系统可靠性。最后总结了不同场景下的技术选型建议，强调根据业务需求选择适合的消息中间件。
RocketMQ核心知识
不积硅步，无以至千里
04-18 1746
RocketMQ核心知识点
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值