图解 RocketMQ 的系统架构

最新推荐文章于 2025-05-20 17:13:29 发布
最新推荐文章于 2025-05-20 17:13:29 发布
阅读量313 收藏
点赞数
CC 4.0 BY-SA版权
分类专栏： 程序员 JAVA 计算机 文章标签： java-rocketmq rocketmq 系统架构
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/JavaShark/article/details/125743050
本文详细介绍了RocketMQ的系统架构，包括Name Server集群、Broker主从集群、Producer和Consumer的角色，以及MessageQueue、消费模式、Broker高可用、消息存储机制和刷盘策略。RocketMQ通过Name Server和Broker集群实现高可用，消息存储在CommitLog和ConsumeQueue中，并使用Index文件加速检索，提供异步和同步刷盘策略以平衡性能和可靠性。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

今天给大家分享一篇我对学习 RocketMQ 系统架构核心知识点的梳理和总结,在讲解时力求精简、通俗易懂，通过图解来给正在学习 RocketMQ 的小伙伴带来帮助。

RocketMQ 是阿里巴巴的分布式消息中间件，在 2012 年开源，在 2017 年成为 Apache 顶级项目。

1 集群架构

RocketMQ 的集群架构如下图：

从上图可以看到，整个集群中有四个角色： Name Server集群、Broker主从集群、Producer、Consumer。

1.1 Name Server 集群

Name Server 集群部署，但是节点之间并不会同步数据，因为每个节点都会保存完整的数据。因此单个节点挂掉，并不会对集群产生影响。

1.2 Broker

Broker 采用主从集群，实现多副本存储和高可用。每个 Broker 节点都要跟所有的 Name Server 节点建立长连接，定义注册 Topic 路由信息和发送心跳。

跟所有 Name Server 建立连接，就不会因为单个 Name Server 挂了影响 Broker 使用。Broker 主从模式中， Slave 节点主动从 Master 节点拉取消息。

1.3 Producer

Producer 跟 Name Server 的任意一个节点建立长连接，定期从 Name Server 拉取 Topic 路由信息。Producer 是否采用集群，取决于它所在的业务系统。

1.4 Consumer

Consumer 跟 Name Server 的任意一个节点建立长连接，定期从 Name Server 拉取 Topic 路由信息。Consumer 是否采用集群，取决于它所在的业务系统。

Producer 和 Consume

最低0.47元/天 解锁文章

200万优质内容无限畅学
RocketMQ 消息负载均衡策略解析——图解、源码级解析
如切如磋，如琢如磨
07-01 3880
Producer发送消息时，会首先获取Topic路由信息（通过本地 + 注册中心拉取），RocketMQ的架构里有多个Broker服务器，而消息队列也会存在于多个Broker服务器里，所以就需要负载均衡策略来将流量尽可能均匀的打到所有服务器上。本章节就介绍一下RocketMQ中常用的四种负载均衡策略。找到Producer发送消息时选择消息队列的逻辑，在类中定义了方法： 进入到方法里： 上述代码的类中定义了方法： 根据源码可以很清楚地看到，默认策略就是依次选择消息队列进行发送，具体的执行细节如下：如何选一个
RocketMQ Push消息给消费者 解析——图解、源码级解析
如切如磋，如琢如磨
09-09 2068
文章目录概述Push消息消费流程开启消息消费接收消息 概述 RocketMQ中消费者有两种方式获得消息来消费：Push模式和Pull模式 Push模式：服务端将消息推送到客户端 Pull模式：客户端不断请求服务端，或许消息 实际上这两种模式的底层实现都是采用的Consumer主动拉取消息的方式 在Push方式里，把Consumer轮询过程封装起来了，并注册了MessageListener监听器，当拉取到消息后唤醒监听器来消费，所以感觉消息就像是被服务端推过来的一样 在Pull模式中，Consumer
一张图进阶 RocketMQ - 整体架构
三此君的博客
06-15 1513
三此君看了好几本书，看了很多遍源码整理的 一张图进阶 RocketMQ 图片，关于 RocketMQ 你只需要记住这张图！ 本文是《一张图进阶 RocketMQ》系列的第 1 篇，今天的内容主要分为两个部分： 整体架构：会从大家熟悉的“生产者-消费者模式”逐步推出 RocketMQ 完整架构，只需要记住一张完整的架构图即可。 消息收发示例：通过 Docker 部署 RocketMQ，并用简单的示例串起 RocketMQ 消息收发流程。 ......
7张图带你轻松入门RocketMQ
zjj2006的专栏
11-30 3763
非常好的学习RocketMQ的文章
RocketMQ原理—高可用+高并发+高性能架构
kfashfasf的博客
05-20 1177
惰性读写分离其实就是上面说的读写分离主从漂移。这种漂移指的是：主从机器对外提供一个完整的服务，客户端有时候访问主、有时候访问从。惰性读写分离不属于彻底的读写分离，从节点的数据更多时候是用于备用。在以下两种情况下，Consumer才会选择到从节点去读取消费数据。情况一：如果主节点过于繁忙，积压没有消费的消息太多，已经超过本地内存40%。此时主节点可能出现大量读写线程并发运行，机器运行效率可能已经降低，来不及处理这么多的请求，那么主节点就会让消费请求漂移到从节点去读取消费数据。
rocketmq架构
weixin_39313241的博客
04-06 1951
架构设计 1 技术架构 RocketMQ架构上主要分为四部分，如上图所示: Producer：消息发布的角色，支持分布式集群方式部署。Producer通过MQ的负载均衡模块选择相应的Broker集群队列进行消息投递，投递的过程支持快速失败并且低延迟。 Consumer：消息消费的角色，支持分布式集群方式部署。支持以push推，pull拉两种模式对消息进行消费。同时也支持集群方式和广播方式的消费，它提供实时消息订阅机制，可以满足大多数用户的需求。 NameServer：NameServer是一
图解 RocketMQ 架构
面向生活编程
07-07 2653
图解 RocketMQ 架构
深度好文 图解 RocketMQ 的系统架构
wui66655的博客
02-23 6902
今天给大家分享一篇学习 RocketMQ 系统架构核心知识点的梳理和总结,在讲解时力求精简、通俗易懂，通过图解来给正在学习 RocketMQ 的小伙伴带来帮助。 RocketMQ 是阿里巴巴的分布式消息中间件，在 2012 年开源，在 2017 年成为 Apache 顶级项目。 1 集群架构 RocketMQ 的集群架构如下图： 从上图可以看到，整个集群中有四个角色：Name Server集群、Broker主从集群、Producer、Consumer。 1.1 Name Server 集群 .
万字长文，图文详解。带你轻松拿捏RocketMQ。
2301_76607156的博客
04-11 346
类比一下我们生活的邮政系统——邮政系统要正常运行，离不开下面这四个角色， 一是发信者，二 是收信者， 三是负责暂存传输的邮局， 四是负责协调各个地方邮局的管理机构。对应到 RocketMQ 中，这四个角色就是 Producer、 Consumer、 Broker 、NameServer。NameServerNameServer 是一个无状态的服务器，角色类似于 Kafka使用的 Zookeeper，但比 Zookeeper 更轻量。
RocketMQ-架构与设计
wlphlj的专栏
02-21 1698
RocketMQ是阿里巴巴开发的纯Java的分布式、队列模型的开源消息中间件，其架构简单、业务场景丰富，支持分布式事务、是一款金融级别可靠业务消息中间件。
RocketMQ(二)——架构设计(转)
学会改变自己——才能突破
03-17 902
最近看了看RocketMQ的官方文档，感觉不错，一直在用，每看一次，深刻一次。接下几篇主要是整理转载一下！ 官方地址：http://rocketmq.apache.org/docs/motivation/ github地址：https://github.com/apache/rocketmq 架构设计 技术架构 RocketMQ架构上主要分为四部分，如上图所示: Producer：消息发布...
RocketMQ 架构简析
JAVA高级架构
05-30 498
Apache RocketMQ 是阿里开源的一款高性能、高吞吐量的分布式消息中间件。- 整体架构 -RocketMQ主要由 Producer、Broker、Consumer ...
RocketMQ的核心概念以及架构图
【原】编程界的小学生
07-07 6268
编程界的小学生一、架构图以及角色1、架构图2、角色2.1、Broker2.2、Nameserver2.3、Producer2.4、Consumer3、核心流程二、核心概念1、Message2、topic3、queue4、Tag5、Message Model6、Message Order7、Producer Group8、Consumer Group三、ACK四、消费模式1、集群模式（Clustering）1.1、图解1.2、特点2、广播模式（Broadcasting）2.1、图解2.2、特点 一、架构图以及
RocketMq架构
zhaozhenzuo的专栏
03-19 3997
一.概述 rocketMq是消息中间件，通常用于业务上的解藕，消峰。 二.竞品对比 特性 ActiveMQ RabbitMQ RocketMQ Kafka 单机吞吐量 万级，比 RocketMQ、Kafka 低一个数量级 同 ActiveMQ 10 万级，支撑高吞吐 10 万级，高吞吐，一般配合大数据类的系统来进行实时数据计算、日志采集等场景 topic 数量对吞吐量的影响 topic 可以达到几百/几千的级别，吞吐量会
RocketMQ从基础到架构原理
Java就是我的道！
01-09 1413
rocketmq、mq、消息
RocketMQ 架构
qq_45801780的博客
03-19 1034
集群的「中枢神经」，负责 Topic 元数据管理（如 Topic 分区分布、Broker 节点状态监控）。消息存储与流转的核心节点，负责消息的持久化、读写请求处理。消息生产者，负责将消息投递到指定的 Topic。消息消费者，从 Broker 拉取消息并处理。
RocketMQ架构详解
刘皇叔说Java的博客
03-06 3326
文章目录概述RocketMQ架构Broker 高可用集群刷盘策略 概述 RocketMQ一个纯java、分布式、队列模型的开源消息中间件，前身是MetaQ，是阿里研发的一个队列模型的消息中间件，后开源给apache基金会成为了apache的顶级开源项目，具有高性能、高可靠、高实时、分布式特点。 RocketMQ是阿里开源的分布式消息中间件，跟其它中间件相比，RocketMQ的特点是纯JAVA实现；集群和HA实现相对简单；在发生宕机和其它故障时消息丢失率更低。 RocketMQ架构 ● Producer：
RocketMQ架构
weixin_34292287的博客
11-05 190
概述 RocketMQ是一个分布式消息和流处理平台，具有低延迟、高性能和高可靠、万亿级容量和灵活的可扩展性。它由四部分组成：name servers，brokers，生产者和消费者。它们中的每一个都可以水平扩展，而没有单一的故障节点。 NameServer 集群 Name Servers提供了轻量级的服务发现和路由。每个Name Server记录全部的...
文件系统索引结构图
最新发布
06-13
<think>嗯，用户这次在查找文件系统索引结构的相关图解或架构图，看来ta正在深入学习文件系统实现原理。从用户引用的资料看，ta应该已经掌握了dentry、inode等基础概念，但需要更直观的结构图示来建立整体认知。用户可能是个Linux内核爱好者，或是正在研究文件系统设计的开发者。注意到用户特别强调了"图解或架构图"，说明文字描述可能不够直观，需要提供视觉化方案。ta引用的资料里有个关键词值得关注：VFS的树状层次结构、inode指向数据块、hash槽的数组结构——这些正是索引结构的核心要素。不过用户提供的引用[3][4][5]来自不同技术领域（RocketMQ索引），需要谨慎区分通用文件系统和特定存储引擎的设计差异。用户可能遇到了三个理解难点：1)从磁盘物理结构到内存抽象层（dentry/inode）的映射关系2)文件名如何通过多层索引找到数据块3)不同文件系统（如ext4的区段树）的特殊实现。ta上次问的是索引结构图解，这次要求更具体的视觉呈现，说明学习进入了实操阶段。在构思回复时，应该把握三个层次：第一层用文字描述核心组件关系，第二层提供ASCII架构图建立空间感，第三层用真实文件系统（ext4）案例强化认知。引用[3]的inode链表机制可以延伸为多级索引示意图，引用[5]的hash槽概念虽然属于消息队列，但可以反衬说明文件系统索引不使用哈希的原因——因为需要保证连续存储特性。考虑设计一个互动环节，提供两个可选方向：其一是从文件名到物理磁盘的完整流程（适合文件系统初学者），其二是现代文件系统的索引效率优化方案（适合有经验者）。这样既能覆盖用户当前需求，又能预判ta可能的进阶问题。</think> 以下是针对文件系统索引结构的图解与分层解析，结合您提供的引用信息整理而成： --- ### **文件系统索引结构核心图解** ```ascii ┌─────────────┐ ┌───────────┐ ┌────────────┐ │ 文件名 │ │ 目录项 │ │ 索引节点 │ │ (文件1.txt) ├─────►│ (dentry) ├─────►│ (inode) │ └─────────────┘ └─────┬─────┘ └─────┬──────┘ │ │ │ ▼ │ ┌───────────────┐ │ │ 元数据 │ │ │ (权限/大小/时间)│ │ └───────┬───────┘ ▼ │ ┌───────────────┐ │ │ 数据块指针 │◄─────────┘ │ (直接/间接指针)│ └───────┬───────┘ ▼ ┌────────────────────┐ │ 磁盘数据块 │ │ (实际文件内容存储) │ └────────────────────┘ ``` --- ### **关键组件解析** 1. **目录项 (dentry)** - **作用**：文件名与 inode 的映射桥梁（引用[1][3]） - **内存结构**：构成树状层次（VFS 抽象），包含文件名、父目录指针等 - **示例**：路径 `/home/user/file.txt` 生成 3 个 dentry 实例 2. **索引节点 (inode)** - **核心功能**（引用[3]）： - 存储文件元数据（权限、大小、时间戳） - 包含 **数据块指针**（直接指针/间接指针/多级索引） - **可视化索引方式**： ```ascii inode ┬─► 直接块1 → 磁盘块#100 ├─► 直接块2 → 磁盘块#101 └─► 间接块 ─┬─► 磁盘块#200 → 块#102 ├─► 磁盘块#201 → 块#103 └─► ... ``` 3. **扩展结构（如 ext4 文件系统）** - **区段树 (Extent Tree)**： ```ascii inode ───► 区段头 ┬─► [逻辑块0-99] → 物理块1000-1099 └─► [逻辑块100-200] → 物理块5000-5100 ``` - 优势：连续块聚合存储，减少指针开销 --- ### **典型文件系统索引差异** | 文件系统 | 索引结构 | 特点 | |----------|-------------------|--------------------------| | **ext2** | 多级间接指针 | 经典但碎片化风险高 | | **ext4** | 区段树 + HTree目录 | 大文件高效处理，目录检索快 | | **XFS** | B+树索引 | 超大规模文件支持 | --- ### **架构图参考来源** 1. **Linux VFS 分层架构**（引用[1][2]）： ``` 应用层 → 系统调用 → VFS抽象层 → 具体文件系统 → 块设备驱动 ``` - **dentry** 缓存加速路径查找 - **inode** 统一不同文件系统的元数据表示 2. **磁盘布局示意图**（基于引用[3][4]概念）： ``` 超级块 | inode表区 | 数据块位图 | inode位图 | 数据块区域 ``` --- ### 相关问题 1. **不同文件系统（如EXT4/XFS）的索引结构性能对比有何区别？** 2. **硬链接与软链接在索引层是如何实现的？**（提示：inode引用计数 vs. 独立dentry） 3. **SSD优化文件系统（如F2FS）如何改造传统索引结构？** > 引用来源说明： > - inode数据块寻址机制基于UNIX文件系统设计[^3] > - VFS dentry抽象层实现参考Linux内核文档[^1][^2] > - 区段树结构为ext4核心优化[^4]的扩展说明 如需更详细的机制图解或特定文件系统深度解析，请随时告知方向。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值