一览纵山小,原来RocketMQ是这样工作的!

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 本文介绍了阿里巴巴开源的高性能分布式消息队列系统RocketMQ的核心组件及其作用。RocketMQ拥有四个关键组件:NameServer、Broker、Producer和Consumer。NameServer作为注册中心维护路由信息;Broker负责消息的接收、存储和转发;Producer生成消息并通过Topic与Broker关联;Consumer则订阅并处理消息。文章详细解析了各组件的功能及交互逻辑,并展示了RocketMQ在异步通信、日志收集、流处理及事件驱动架构中的典型应用场景。通过整体框架的梳理,有助于读者更好地理解和掌握RocketMQ的工作机制。

你好,我是猿java。

提起分布式消息中间件,作为一名 Java程序员,很自然会想起阿里巴巴开源的RocketMQ,它是一款高性能、高吞吐量的消息队列系统,在大数据、微服务、事件驱动架构等领域大放异彩,因此,本文我们将从全貌上介绍 RocketMQ的核心组件及其各自的作用,帮助大家能从整理上掌握 RocketMQ的脉络。

RocketMQ 核心组件

首先,我们看一张 RocketMQ的内核原理鸟瞰图,它抽象了 RocketMQ的 4个核心组件 NameServer、Broker、Producer、Consumer以及组件间的交互逻辑,具体信息如下:

rocketmq-kernel.png

接下来,我们重点分析 4个核心组件以及它们之间是如何交互的。

NameServer

NameServer是 RocketMQ中的注册中心,负责维护 Broker集群的路由信息,为了高可用,NameServer可以集群部署,需要特别注意:NameServer相互之间不会通信,它们是一种Peer to Peer的对等关系,并且每个 NameServer都保存着所有 Broker的信息。

NameServer的核心功能包括路由注册、路由发现、路由更新等,具体描述如下:

当 Broker启动时会向所有的 NameServer注册自身的信息,比如 IP、端口、Topic、Queue等,NameServer会将这些信息存入本地数据表中。默认情况下,Broker每隔 30s会向 NameServer发送一次心跳包,NameServer接收到心跳包后更新 Broker状态,如果 NameServer在 120s内没有接收到心跳包,会认为 Broker异常,从而剔除该心跳异常的 Broker。

当存在 Producer和 Consumer时,它们默认会每隔 30s定时从 NameServer获取 Broker集群信息并更新本地缓存,然后对 Broker列表进行负载均衡,从而将消息发送给 Broker或者从 Broker获取消息。

Broker

Broker是 RocketMQ中的数据存储节点,负责接收、存储和转发消息。

Broker可以集群部署,每个集群下面可以有多个组(BrokerName一样),每个组还可以主从部署,BrokerId=0 代表主节点,BrokerId=1代表从节点。

Broker的主要职责包括消息接收、消息存储、消息转发、消息索引、负载均衡,具体描述如下:

当 Broker启动时会所有的 NameServer注册信息以及后期定时向 NameServer发送心跳包,当 Broker接收到 Producer发送的消息后,首先会将消息写入 CommitLog(Write ahead log,WAL),然后开启后台线程将 CommitLog上的数据索引写入 write queue,这样可以确保消息持久化到磁盘上。

另外,Broker 会根据消费者的消费模式(推模式或拉模式),主动推送消息或等待消费者拉取消息,为了提高消息的检索速度,Broker还会为消息创建索引,支持快速定位和检索消息。

Producer

Producer是 RocketMQ中的生产者,负责发送消息。

Producer 和 Broker 是通过 Topic这样一个虚拟的概念建立关系的,当创建 Topic后,其实已经建立了 Topic和 Broker的关系,而这个关系的桥梁就是 queue,在 Broker中,有 write queue 和 read queue两种类型。

Producer每隔 30s从 NameServer拉取所有的 Topic以及 Broker信息,当消息发送到 Topic之后,消息首先会被写入一个 CommitLog的日志文件中,然后有后台线程将消息在 CommitLog磁盘上的地址等索引信息写入 write queue。这样,一个 Topic的数据就可以存储在不同的 Broker上,真正达到了数据的分布式存储,即便有部分Broker异常,受影响的数据也局限在这些 Broker上。

Producer发送消息有 3种方式:同步发送、异步发送和单向发送 。

  • 同步发送:Producer 发送消息后需要等待 Broker的确认,这种方式保证消息可靠地发送到 Broker,适用于对消息可靠性要求较高的场景,比如金融领域。
  • 异步发送:Producer 发送消息后不等待 Broker的确认,而是通过回调函数处理发送结果,该方式可以提高系统的并发性和吞吐量,适用于日志收集,监控报警等场景。
  • 单向发送:Producer 仅发送消息,不关心发送结果,也不等待 Broker的确认。这种方式的性能最高,但无法保证消息一定被发送成功,适用于数据采集,实时统计等场景。

消息重试:在消息发送失败时,Producer 可以进行重试,确保消息最终被成功发送。

Consumer

Consumer是 RocketMQ中的消费者,负责消费和处理消息,通常是真实的业务系统,Consumer的整个工作流程描述如下:

当 Consumer启动后,会向 Broker订阅感兴趣的 Topic,当 Topic中的 read queue有消息时,Consumer会定时拉取,然后执行真实的业务逻辑。当 Consumer成功处理消息后,需要向 Broker发送确认信息,Broker收到确认信息标记该消息已消费,避免重复消费,另外,为了防止丢消息,Consumer一般不建议多线程处理。Consumer可以通过顺序消费和并行消费等方式去拉取信息,从而满足不同的业务需求。

因为一个 Topic可以对应不同 Broker上的 read queue,因此,一个 Consumer可以消费不同 Broker上的数据。

典型应用场景

RocketMQ的应用场景主要包含下面 4种:

异步通信

在分布式系统中,通过 RocketMQ实现异步通信可以显著提高系统的响应速度和并发能力。例如,电商系统中订单创建后,通过 RocketMQ将订单数据异步发送给库存系统进行处理,避免了同步调用带来的延迟。

日志收集

RocketMQ可以用于分布式系统的日志收集和分析。各个服务将日志数据发送到 RocketMQ,由专门的日志处理系统进行消费和分析,帮助运维人员监控系统状态和排查故障。

流处理

RocketMQ 结合流处理框架(如 Apache Flink、Apache Storm)可以实现实时数据流处理。例如,在金融领域,通过 RocketMQ收集实时交易数据,并进行实时风控分析。

事件驱动架构

在事件驱动架构中,RocketMQ 作为事件总线,可以实现不同服务之间的解耦。例如,用户注册后发送欢迎邮件、用户订单支付成功后更新用户积分等业务逻辑,都可以通过 RocketMQ进行事件通知和处理。

总结

RocketMQ作为一款高性能的分布式消息中间件,在分布式系统中有其重要的一席之地,本文通过 RocketMQ内核鸟瞰图,对其重要的 4个组件以及组件间的交互进行了分析,通过上述内核鸟瞰图,我们能很好的把控 RocketMQ的整理脉络。

其实,我们在学习很多框架时,都是需要先从整体上掌握其框架脉络,而不是一开始就扎进细节里,这样很容易陷入其中出不来,最后导致放弃。

学习交流

如果你觉得文章有帮助,请帮忙转发给更多的好友,或关注:猿java,持续输出硬核文章。

相关实践学习
快速体验阿里云云消息队列RocketMQ版
本实验将带您快速体验使用云消息队列RocketMQ版Serverless系列实例进行获取接入点、创建Topic、创建订阅组、收发消息、查看消息轨迹和仪表盘。
消息队列 MNS 入门课程
1、消息队列MNS简介 本节课介绍消息队列的MNS的基础概念 2、消息队列MNS特性 本节课介绍消息队列的MNS的主要特性 3、MNS的最佳实践及场景应用 本节课介绍消息队列的MNS的最佳实践及场景应用案例 4、手把手系列:消息队列MNS实操讲 本节课介绍消息队列的MNS的实际操作演示 5、动手实验:基于MNS,0基础轻松构建 Web Client 本节课带您一起基于MNS,0基础轻松构建 Web Client
目录
相关文章
|
缓存 Java API
【云原生】Spring Cloud Gateway的底层原理与实践方法探究
【云原生】Spring Cloud Gateway的底层原理与实践方法探究
|
2月前
|
消息中间件 缓存 监控
MQ消息积压 / Rocketmq 积压 最全的处理方案。 (秒懂+图解+史上最全)
MQ消息积压 / Rocketmq 积压 最全的处理方案。 (秒懂+图解+史上最全)
MQ消息积压 / Rocketmq 积压 最全的处理方案。 (秒懂+图解+史上最全)
|
10月前
|
消息中间件 存储 Kafka
RocketMQ 工作原理图解,看这篇就够了!
本文详细解析了 RocketMQ 的核心架构、消息领域模型、关键特性和应用场景,帮助深入理解消息中间件的工作原理。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
RocketMQ 工作原理图解,看这篇就够了!
|
11月前
|
消息中间件 存储 SQL
代码很少,却很优秀!RocketMQ的NameServer做到了!
本文深入剖析了RocketMQ的注册中心NameServer,基于RocketMQ release-5.2.0版本。NameServer作为Broker、Producer与Consumer之间的纽带,仅由少数几个类构成,却实现了高性能与轻量化。文章详细介绍了NameServer的AP设计思想、简洁的数据结构及心跳机制。AP设计避免了复杂的分布式协议,简化了网络开销;数据结构主要包括路由表、Broker信息等;心跳机制则通过定时扫描确保Broker的活跃状态。通过这些核心设计,NameServer实现了高效稳定的注册与发现功能。
504 5
|
3月前
|
消息中间件 存储 Kafka
一文带你从入门到实战全面掌握RocketMQ核心概念、架构部署、实践应用和高级特性
本文详细介绍了分布式消息中间件RocketMQ的核心概念、部署方式及使用方法。RocketMQ由阿里研发并开源,具有高性能、高可靠性和分布式特性,广泛应用于金融、互联网等领域。文章从环境搭建到消息类型的实战(普通消息、延迟消息、顺序消息和事务消息)进行了全面解析,并对比了三种消费者类型(PushConsumer、SimpleConsumer和PullConsumer)的特点与适用场景。最后总结了使用RocketMQ时的关键注意事项,如Topic和Tag的设计、监控告警的重要性以及性能与可靠性的平衡。通过学习本文,读者可掌握RocketMQ的使用精髓并灵活应用于实际项目中。
2295 9
 一文带你从入门到实战全面掌握RocketMQ核心概念、架构部署、实践应用和高级特性
|
5月前
|
消息中间件 存储 设计模式
RocketMQ原理—5.高可用+高并发+高性能架构
本文主要从高可用架构、高并发架构、高性能架构三个方面来介绍RocketMQ的原理。
1514 21
RocketMQ原理—5.高可用+高并发+高性能架构
|
11月前
|
消息中间件 监控 Java
RocketMQ 同步发送、异步发送和单向发送,如何选择?
本文详细分析了 RocketMQ 中同步发送、异步发送和单向发送三种消息发送方式的原理、优缺点及适用场景。同步发送可靠性高但延迟较大,适合订单系统等场景;异步发送非阻塞且延迟低,适用于实时数据处理等场景;单向发送高效但可靠性低,适用于日志收集等场景。文章还提供了示例代码和核心源码分析,帮助读者更好地理解每种发送方式的特点。
1686 4
|
6月前
|
负载均衡 Java 开发者
OpenFeign的工作原理
OpenFeign的工作原理
|
11月前
|
消息中间件 负载均衡 算法
聊聊 RocketMQ中 Topic,Queue,Consumer,Consumer Group的关系
本文详细解析了RocketMQ中Topic、Queue、Consumer及Consumer Group之间的关系。文中通过图表展示了Topic可包含多个Queue,Queue分布在不同Broker上;Consumer组内多个消费者共享消息;并深入探讨了集群消费与广播消费模式下Queue与Consumer的关系,以及Rebalancing机制在实例增减时如何确保负载均衡。理解这些关系有助于更好地掌握RocketMQ的工作原理,提升系统运维效率。
2530 2
|
11月前
|
Java Python
Python if-else嵌套!
本文详细介绍了Python中的条件语句,包括`if`、`if...else`、嵌套`if`及`if-elif`语句。`if`语句在条件为真时执行特定代码块,`if...else`则在条件为假时执行备选代码块。嵌套`if`语句允许在一层`if`语句内嵌套另一层`if`语句,实现更复杂的条件判断。`if-elif`语句简化了多条件判断的流程。文章通过多个示例演示了这些语句的使用方法,并讨论了常见问题,如在嵌套`if`中使用`elif`以及`if`语句的嵌套层次等。
463 3