RocketMQ架构解析

架构图

Rocket核心组件详解

NameServer

什么是NameServer

Nameserver是一个关键的组件，它充当了消息路由和元数据管理的核心角色。Nameserver负责管理整个RocketMQ集群的元数据信息，包括Broker的地址、主题的路由信息以及消费者的订阅关系等。

设计目标

实现Broker动态注册与发现
解耦Producer/Consumer与Broker的强依赖
规避ZK等重型协调服务（减少运维复杂度与性能损耗）
💡 核心设计哲学：做最小化的可靠中间层​，不参与消息传输，不保证强一致性（采用最终一致性）

NameServer有什么作用

集群管理
Nameserver维护了整个RocketMQ集群中所有Broker的信息，这对于Producer和Consumer来说是至关重要的，它们需要知道消息应该从哪里发送和接收。

路由管理
Nameserver存储了主题的路由信息，指示消息在集群中的分布情况。这使得Producer能够有效地将消息发送到正确的Broker上。

动态发现
Nameserver能够动态地感知Broker的状态变化，包括Broker的上线、下线或状态变更。这有助于RocketMQ系统实现动态的路由调整，以保证消息的发送和接收的可靠性。

负载均衡
Nameserver可以根据Broker的负载情况和网络状况，为Producer和Consumer提供合适的Broker列表，实现负载均衡，提高整个系统的性能和稳定性。

NamseServer 工作方式

Broker注册
当Broker启动时，会向Nameserver注册自己的信息，包括地址、名称和角色等。Nameserver会记录这些信息，并在需要时向Producer和Consumer提供

路由查询
当Producer或Consumer需要发送或接收消息时，它们会向Nameserver查询目标Broker的路由信息。Nameserver会返回包含目标Broker地址的路由信息。

动态更新
当集群中的Broker发生变化时，如新增Broker或Broker宕机，Nameserver能够感知到并更新路由信息。这确保了Producer和Consumer能够及时发现并连接到可用的Broker。

解决关键问题

Broker

什么是Broker

Broker是一个关键的组件，它扮演着消息存储和消息转发的角色。Broker负责接收来自Producer的消息，并将其存储在合适的主题（Topic）中，同时负责接收来自Consumer的消息消费请求，并将消息传送给Consumer进行处理。

Broker的作用

消息存储

Broker负责将Producer发送的消息存储在合适的主题中，并确保消息的持久性，以便Consumer随时可以消费。

消息传递

当Consumer请求消费消息时，Broker负责将存储的消息传送给Consumer，确保消息能够被及时处理。

消息分发

Broker负责将发送到同一主题的消息分发给不同的Consumer，实现消息的广播或点对点传递。

消息管理

Broker管理消息的存储、清理和索引，确保消息数据的有效性和一致性。

定位与设计目标

核心使命​：

持久化存储​：承载万亿级消息堆积
流量调度​：实现亿级QPS削峰填谷
事务仲裁​：保障分布式事务最终一致

设计约束​：

写入性能：单节点50K TPS
99.99%故障恢复<30s
单Topic最大支持16K队列

Broker的工作方式

消息存储

当Producer发送消息时，Broker接收消息并将其存储在磁盘上，确保消息的持久性。Broker使用存储引擎（如文件存储或内存存储）来管理消息数据。

消息传递

当Consumer请求消费消息时，Broker根据消费者的订阅关系从存储中检索消息，并将消息传送给Consumer进行处理。传递过程可以通过推送或拉取的方式实现。

消息分发

Broker根据主题的订阅关系将消息分发给不同的Consumer。这可以基于订阅的模式（如广播模式或点对点模式）来实现。

消息管理

Broker负责管理消息的存储、清理和索引。它定期清理过期消息、维护消息索引，并确保消息数据的一致性和可靠性。

Producer

什么是Producer

Producer是消息的生产者，负责产生并发送消息到消息队列中。

Producer的作用

消息生产

Producer负责生成各种类型的消息，如文本、对象等，并将它们发送到指定的主题（Topic）中。

消息可靠性

Producer确保消息的可靠性，通过发送消息后等待Broker的确认，以确保消息已经成功保存到消息队列中。

消息分发

Producer负责将消息发送到特定的主题，以便Consumer可以根据订阅关系消费消息。

生产者发送消息方式

同步发送

当生产者发送一条消息时，会阻塞当前线程，直到Broker返回响应确认消息已成功存储。这种方式确保了消息发送的可靠性，因为生产者只有在收到确认后才会认为消息发送成功。但如果Broker处理较慢或网络延迟，同步发送可能会增加生产者的响应时间。

异步发送

生产者发送消息后不会阻塞，而是继续执行后续操作。Broker收到消息并处理后，会通过回调函数通知生产者发送结果（成功或失败）。异步发送提高了生产者的吞吐量，因为它不需要等待服务器响应就可以继续发送下一条消息，但可能需要额外处理失败重试的逻辑

单向发送

生产者发送消息后，不等待任何响应就直接认为消息发送成功，Broker不会返回任何确认。这种方式牺牲了消息的可靠性以换取极高的发送速度，适用于对消息丢失不敏感的场景，比如日志收集，因为一旦消息发送失败，生产者无从知晓，也无法重试。

Consumer

什么是Consumer

Consumer是消息的消费者，负责从消息队列中订阅并消费消息。

Consumer的作用

消息订阅

Consumer订阅特定主题下的消息，以便从Broker接收相应的消息

消息处理

Consumer处理接收到的消息，根据业务逻辑进行相应的处理，如数据分析、业务计算等。

消息可靠性

Consumer确保消费消息的可靠性，通过消息确认机制，保证每条消息被正确处理。

消费模型

集群模式

消息只会被集群中的一个消费者消费一次

广播模式

每条消息都会被推送给所有订阅了特定主题或标签的消费者。
在这种模式下，一个生产者发出的消息会被集群内所有订阅该Topic的消费者都接收到。

RocketMQ基础组件概念

Topic

每个主题下有多个消息，但是每个消息只能属于一个主题 
一个topic 可以通过MessageQueue分布式存储在多个broker中

NameServer

用于管理多个Broker
Broker 启动的时候会往NameServer注册

Broker

Broker 负责接收生产者发送的消息，并存储在commitlog中 同时也负责消费者的拉取请求

Producer

负责生产消息  将应用的消息发送给Broker

Consumer

负责消费消息 进行业务逻辑的处理

Tag

标签 为消息设置的一个标志 用于区分同一Topic下不同类型的消息

Message Queue

相当于Topic的分区  一个Topic下有多个MessageQueue
当消息生产的时候会将消息路由到 Broker下的MessageQueue中

ConsumerQueue

对于每个Topic下的每一个Message Queue，RocketMQ都会创建一个对应的ConsumeQueue
这个文件存储了指向CommitLog中对应消息的偏移量、消息大小和其他一些元信息，起到了索引的作用。
当消费者订阅并消费某个Message Queue的消息时，通过查询对应的ConsumeQueue，能够快速定位到CommitLog中的具体消息位置，从而高效地进行消息拉取和消费。

CmmitLog

负责消息的存储  持久化所有发送到Broker的消息 

Message

什么是Message

数据传输的基本单元

消息模型

点对点（Queue模型）

类似于传统的消息队列，生产者将消息发送到特定的队列，然后由一个或多个消费者竞争消费这些消息。RocketMQ虽然原生支持发布/订阅模型，但通过配置可以模拟点对点模型，即每个消息队列只分配给一个消费者组中的一个消费者。

发布/订阅（Topic模型）

RocketMQ主要支持的消息模型，生产者发布消息到一个主题（Topic），可以有多个消费者订阅这个主题，并且每个消费者都能收到发布的消息副本。RocketMQ允许在主题下进一步划分Tag，实现更细粒度的消息路由。