一、RocketMQ总体架构|参与者如何通信的？

RocketMQ架构详解
最新推荐文章于 2025-03-17 08:00:00 发布
原创 最新推荐文章于 2025-03-17 08:00:00 发布 · 504 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文深入解析RocketMQ的架构设计，包括NameServer集群、Broker集群、生产者与消费者的工作原理及通信机制。阐述了RocketMQ如何确保消息的高可用性和可靠性，尤其是在broker宕机情况下的处理策略。

RocketMQ总体架构

1.各参与者是如何通信的？

  • 一、nameServer集群:
    • 本身的高可用可通过部署多台NameServer服务器来实现，但彼此间互不通信，单台nameserver挂掉，不影响其他nameserver；NameServer服务器之间在某一时刻的数据并不完全相同，但保证多台NameServer的最终一致性；NameServe集群可以理解为无状态的。
    • nameserver不会有频繁的读写，所以性能开销非常小，稳定性很高
  • 二、broker集群：
    • 1.@nameserv关系：
      • 连接：每一台borker会与所有的nameserver保持长连接, 因为每台broker需要向所有的nameserv汇报路由信息
      • 心跳：
        • 心跳间隔：每隔30秒（此时间无法更改）向所有nameserver发送心跳，心跳包含了自身的topic配置信息。
        • 心跳超时：nameserver每隔10秒钟（此时间无法更改），扫描所有还存活的broker连接，若某个连接2分钟内（当前时间与最后更新时间差值超过2分钟，此时间无法更改）没有发送心跳数据，则断开连接。
      • 断开：
        • 时机：broker挂掉；心跳超时导致nameserver主动关闭连接
        • 动作：一旦连接断开，nameserver会立即感知，更新topc与队列的对应关系，但不会通知生产者和消费者
    • 2.Broker集群组成：
      • 每个broker集群有统一的名字，即brokerClusterName，默认是DefaultCluster。一个集群下有多个master，每个master下有多个slave。master和slave算是一组，拥有相同的brokerName, master的brokerId是0，而slave则是大于0。master和slave之间可以进行同步复制或者是异步复制。
    • 3.可用性
      • 一旦某个broker宕机，则该broker上的消息读写都会受到影响。所以rocketmq提供了master/slave的结构，salve定时从master同步数据，如果master宕机，则slave提供消费服务，但是不能写入消息。
      • 一旦某个broker master宕机，生产者和消费者多久才能发现？
        • 受限于Rocketmq的网络连接机制，默认情况下最多需要30秒，因为消费者每隔30秒从nameserver获取所有topic的最新队列情况，这意味着某个broker如果宕机，客户端最多要30秒才能感知。在此期间，消费者会切换到salve上读取消息，若此时消费者消费消息时发生异常，又会怎样?详见https://cloud.tencent.com/developer/news/158048；生产者则通过高可用的的策略解决broker的宕机情况；
      • master恢复恢复后，消息能否恢复。
        • 消费者得到master宕机通知后，转向slave消费，但是slave不能保证master的消息100%都同步过来了，因此会有少量的消息丢失。但是消息最终不会丢的，一旦master恢复，未同步过去的消息会被消费掉。
    • 4.消息清理
      • 文件保留时长
        •  默认72小时，由broker配置参数fileReservedTime决定
      • 清理时机
        • 默认每天凌晨4点，由broker配置参数deleteWhen决定；或者磁盘空间达到阈值
    • 不同broker集群建立相同的topic而言是没问题的。但是如果是不同集群间的brokername有一致的则会有很大的问题。
  • 三、生产者：
    • 1.@nameserv关系
      • 连接：某一时刻只会连接一台namerServer，拉取主题的配置信息；
      • 轮询时间：默认情况下，生产者每隔30秒从nameserver获取所有topic的最新队列情况，这意味着某个broker如果宕机，生产者最多要30秒才能感知，在此期间，发往该broker的消息发送失败。该时间由DefaultMQProducer的pollNameServerInteval参数决定，可手动配置。
      • 心跳：与namerServ没有心跳
    • 2.@Broker关系
      • 连接：生产者与消费服务器(Broker)之间的（所有）Master保持长连接。因为生产者发送消息时，要轮询所有Master上的队列。
      • 心跳：
        • 超时：broker每隔10秒钟（此时间无法更改），扫描所有还存活的连接，若某个连接2分钟内（当前时间与最后更新时间差值超过2分钟，此时间无法更改）没有发送心跳数据，则关闭连接。
        • 间隔：默认情况下，生产者每隔30秒向所有broker发送心跳，该时间由DefaultMQProducer的heartbeatBrokerInterval参数决定，可手动配置。
      • 连接断开：移除broker上的生产者信息
    • 3.负载均衡：每个生产者向broker的所有队列轮询发送消息
  • 四、消费者：
    • 1.@namerserv关系
      • 连接：同一时间与NameServer集群中一台建立长连
      • 接轮询时间：默认情况下，消费者每隔30秒从nameserver获取所有topic的最新队列情况，这意味着某个broker如果宕机，客户端最多要30秒才能感知。该时间由DefaultMQPushConsumer的pollNameServerInteval参数决定，可手动配置
      • 心跳：与nameserver没有心跳
    • 2.@broker关系
      • 连接：单个消费者与所有Broker建立长连接，因为拉取消息可以从主服务器，也可以从服务上拉取。
      • 心跳：
        • 间隔：默认情况下，消费者每隔30秒向所有broker发送心跳，该时间由DefaultMQPushConsumer的heartbeatBrokerInterval参数决定，可手动配置
        • 超时：broker每隔10秒钟（此时间无法更改），扫描所有还存活的连接，若某个连接2分钟内（当前时间与最后更新时间差值超过2分钟，此时间无法更改）没有发送心跳数据，则关闭连接，并向该消费者分组的所有消费者发出通知，分组内消费者重新分配队列继续消费。
      • 断开：
        • 时机：消费者挂掉；心跳超时导致broker主动关闭连接
        • 动作：一旦连接断开，broker会立即感知到，并向该消费者分组的所有消费者发出通知，分组内消费者重新分配队列继续消费

2.问题

1.当某一个broker发生宕机,namerServer的剔除是120s，有延迟，那么作为客户端的生产者or消费者，是如何保证消息发送or消费的可靠性的？详见生产者 以及 消费者@NamserServer

2.消费者根据队列分配算法，得到本消费者对应的队列。当该主题的多个消费者动态增加或减少时，消费者的队列负载是没30s一次，不能达到实时性，那消费者是如何实时重新分配队列的呢？见消费者的负载均衡；见RocketMQ消息消费总览-问题

3. 断掉broker时，nameServer就感知到了，是不是与nameServer和broker的长连接断掉有关？tcp中断时，会被handler的监听到NettyConnectManageHandler#close，然后调用链：NettyRemotingAbstract#putNettyEvent->NettyEventExecutor#putNettyEvent->NettyEventExecutor#run->BrokerHousekeepingService#onChannelClose->RouteInfoManager#onChannelDestroy

4.生产者分组以及消费者分组，作用？类似jmq的appname。

5. nameserv无法像zk那样实时感知到生产者、消费者、broker的宕机，设计上由客户端来解决

消息中间件学习总结（5）——RocketMQ之Apache RocketMQ背后的设计思路与最佳实践
科技D人生
10-16 1728
摘要：为了更好地让开发者们更加深入了解阿里开源，阿里云云栖社区在3月1号了举办“阿里开源项目最佳实践”在线技术峰会，直播讲述了当前阿里新兴和经典开源项目实战经验以及背后的开发思路。在本次在线技术峰会上，阿里巴巴中间件架构师冯嘉深入浅出的为大家讲述Apache RocketMQ背后的设计思路、典型场景、最佳实践以及社区运营与商业化之路。 演讲嘉宾介绍： 冯嘉（花名鼬神），阿里巴巴中间件架构师，具...
RocketMQ消息短暂而又精彩的一生
mxt51220的博客
01-10 507
为了更好地理解本文，这里再来总结一下RokcetMQ消息一生的各个环节。消息发送生产者产生消息生产者在发送消息之前会拉取topic的路由信息根据队列选择算法，从topic众多的队列中选择一个队列跟队列所在的Broker机器建立网络连接，将消息发送到Broker上消息存储Broker接收到生产者的消息将消息存到CommitLog中在CosumeQueue中存储这条消息在CommitLog中的位置。
RocketMQ NameServer网络通信架构（基于Netty）
墨玉浮白的博客
07-05 314
初始化 Netty是负责监听、处理Broker和客户端发送的网络请求的，NameServer通过9876这个端口接收来自Broker、客户端的网络请求，如Broker注册自己、客户端拉取Broker路由数据等。 在构建好NamesrvController后，会通过start方法来启动这一核心组件。首先要初始化NamesrvController //初始化NamesrvController boolean initResult = controller.initialize(); 在这个方法内，会构建Net
《RocketMQ源码分析》NameServer如何处理Broker的连接
qq_41956309的博客
08-15 872
rocketmq源码解析
rocketMq原理_客户端与namesrv及broker的交互
wb_snail的博客
04-12 3990
对于rocketMq客户端来说，无非就两个任务，消息生产与消息消费 对于生产者来说，需要知道消息可以往哪个或者哪些目的地发送 对于消费者来说，需要知道可以从哪个或者哪些目的地拉取到消息 本文会从客户端与namesrv、broker的交互的角度讲述消息生产与消息消费大致原理，当然，重点还是围绕上文中提出的queue进行讲述： 客户端包括生产者与消费者，它们有共同的...
RocketMQ的通信
tian31233的专栏
01-29 383
6.rocketmq源代码学习----客户端怎么与服务端通信
Fighting!
12-26 817
通过消息发送的源代码，我们知道rocketmq是使用了netty，来完成客户端于服务端的通信 而且rocketmq对netty的调用全部都封装到remoting包中 其中最主要的几个类如图： NettyRemotingClient：对客户端通信做封装 NettyRemotingServer：对服务端通信做封装 RemotingCommand：请求、响应对象封装 接下来我们就从NettyRemot...
RocketMQ-Streams架构设计浅析
阿里巴巴中间件
04-06 1047
*作者：倪泽，RocketMQ 资深贡献者， RocketMQ-Streams 维护者之一，阿里云技术专家。 * RocketMQ-Streams 是一款轻量级流处理引擎，应用以SDK 的形式嵌入并启动，即可进行流处理计算，不依赖于其他组件，最低1核1G可部署，在资源敏感场景具有很大优势。同时它支持 UTF/UTAF/UTDF 多种计算类型。目前已经广泛运用于安全，风控，边缘计算等场景。 本期将带领大家从源码的角度，解析RocketMQ-Streams的构建，数据流转过程。也会讨论RocketMQ-Stre
RocketMQ
m0_46702681的博客
03-17 1994
bin：启动脚本，包括shell脚本和CMD脚本conf：实例配置文件 ，包括broker配置文件、logback配置文件等lib：依赖jar包，包括Netty、commons-lang、FastJSON等Producer：消息的发送者；举例：发信者Consumer：消息接收者；举例：收信者Broker：暂存和传输消息；举例：邮局NameServer：管理Broker；举例：各个邮局的管理机构Topic：区分消息的种类；一个发送者可以发送消息给一个或者多个Topic；
深入解析RocketMQ 4.7.1源码包的核心组件与架构
- 理解RocketMQ的总体架构和各个组件之间的交互关系是阅读源码前需要做的准备。 - 在源码阅读过程中，重点关注消息的存储、消息的投递和消费流程，以及如何保证消息的一致性和顺序性。 - 要注意区分同步和异步...
RocketMQ架构设计
zxyhj的博客
10-30 1354
无序消息即普通、定时、延时、事务消息，当consumer消费消息失败时，可以通过设置返回状态实现消息重试注意：无序消息的重试只针对集群消费方式（非广播方式）生效广播方式不提供失败重试特性，即消费失败后，失败的消息不再重试，而是继续消费新消息延时消息：Producer 将消息发送到消息队列 RocketMQ 服务端，但并不期望这条消息立马投递，而是延迟一定时间后才投递到 Consumer 进行消费， 该消息即延时消息。死信队列用于处理无法被正常消费的消息。当一条消息初次消费失败，消息队列MQ。
RocketMQ的NameServer和Broker之间是如何通信的？
qq_33240556的博客
09-24 1235
Broker 与 NameServer 通信：通过心跳机制保持连接，Broker 定期向 NameServer 发送心跳包以更新路由信息。客户端与 NameServer 通信：客户端启动时向 NameServer 请求路由信息，并在必要时更新缓存。Broker 之间的通信：主要用于主备同步，确保数据的一致性和高可用性。这种设计使得 RocketMQ 能够高效地管理和分发路由信息，同时也保证了系统的高可用性和扩展性。
RocketMQ-初体验RocketMQ(06)-使用API操作RocketMQ ,理解RocketMQ的存储结构
热门推荐
小工匠
11-09 2万+
文章目录RocketMQ集群基本信息目标知识预习发送方式发送结果环境搭建使用Java API操作RocketMQ—Simple Message RocketMQ集群基本信息 右侧的部署模式 ，双机互为主备 如何搭建的，请移步： RocketMQ-初体验RocketMQ(03)_RocketMQ多机集群部署 目标 1. 使用RocketMQ 发送3种类型的消息： reliable synch...
rocketMq原理_nameserver与broker的交互
wb_snail的博客
04-11 7812
本文从namesrv与broker的交互角度，讲述namesrv的具体作用，以及与broker的关系： broker启动时，需要指定namesrv地址(一个或多个)，在建立好与所有namesrv的连接后，broker的一个重要任务就是向这些namesrv注册路由信息： namesrv在内存中维护了下面几个数据结构，用于保存broker注册的有关数据，这些数据统称为路由信息，路...
通信模块——RocketMQ（一）
2301_77162163的博客
05-19 220
Broker是RocketMQ的消息存储和转发节点，每个Broker负责管理若干个Topic的消息存储和转发。生产者在发送消息时会先向NameServer查询要发送的Topic所在的Broker地址，消费者在订阅消息时也会先向NameServer查询要订阅的Topic所在的Broker地址。消息确认机制：消息确认机制指的是生产者和消费者之间的消息传递确认机制，可以是自动确认或手动确认。消息持久化：消息持久化指的是将消息保存在存储介质中，以便在重启系统后恢复未被消费的消息。
RocketMQ基础介绍
DaftCat的博客
11-15 516
1.RocketMQ功能介绍 消息队列是一种“先进先出”的数据结构，分布式消息队列的作用：①应用解耦。②消息分发。③流量削峰。 2.RocketMQ各部分角色介绍 4个角色：producer，consumer, broker, nameserver 一个Topic可以设置一个或者多个Message Queue, Message Queue类似于分区或partition...
RocketMQ之Broker
hfwangyl的博客
03-08 845
作为消费者的系统在获取消息的时候会先发送请求到Master Broker上去，请求获取一批消息，此时Master Broker是会返回一批消息给消费者系统，然后Master Broker在返回消息给消费者系统的时候，会根据当时Master Broker的负载情况和Slave Broker的同步情况，向消费者系统建议下一次拉取消息的时候是从Master Broker拉取还是从Slave Broker拉取。消费者消费消息：有可能从Master Broker获取消息，也有可能从Slave Broker获取消息。
深入学习Kafka：集群中Controller和Broker之间通讯机制分析 - ControllerChannelManager
12-11 838
所有博文均在个人独立博客http://blog.mozhu.org首发，欢迎访问！ Kafka集群中，首先会选举出一个broker作为controller，然后该controller负责跟其他broker进行协调topic创建，partition主副本选举，topic删除等事务。 下面我们...
双主双从异步复制的Broker集群—RocketMQ
如果有什么好的建议，希望前辈们不吝赐教。
02-24 400
RoCket双主双从异步复制
RocketMq一条消息最大字符数？
最新发布
12-04
RocketMQ 单条消息的最大字符数（或字节数）取决于其消息体大小的限制，具体规则如下： ### 核心限制参数 1. **默认配置**： - **单条消息最大大小**：4MB（`maxMessageSize=4×1024×1024`字节） - 适用于 RocketMQ 4.x 及 5.x 版本（生产环境推荐值） 2. **关键配置项**： ```properties # broker.conf 配置文件中的参数 maxMessageSize=4194304 # 单位：字节（4MB） ``` - 修改后需重启 Broker 生效 ### 字符数换算规则 1. **UTF-8 编码下**： - 英文字符：1 字节/字符 - 中文字符：3 字节/字符 - **计算示例**： ```text 4MB = 4×1024×1024 = 4,194,304 字节 纯中文消息：最多约 1,398,101 个字符（4,194,304 ÷ 3） 混合内容：实际字符数需根据编码具体计算 ``` 2. **特殊场景**： - 若消息包含**大附件**（如图片、PDF），建议通过以下方式处理： - 使用 RocketMQ 的**消息轨迹**功能追踪大文件 - 将文件存储至 OSS/NAS，消息体仅传递文件 URL ### 版本差异说明 | RocketMQ 版本 | 默认 maxMessageSize | 备注 | |----------------|----------------------|------| | 4.x | 4MB | 稳定版默认值 | | 5.x | 4MB（可配置至 256MB）| 需修改 `broker.conf` 中的 `maxMessageSize` | | 阿里云版 | 64KB~6MB（根据套餐） | 云服务有额外限制 | ### 性能影响建议 1. **大消息优化**： - 超过 1MB 的消息建议拆分为多条 - 使用**事务消息**保证拆分后的原子性 2. **监控指标**： - 通过 `RocketMQ-Console` 监控 `MessageSize` 指标 - 超过 2MB 的消息会触发 Broker 日志警告 ### 代码示例（发送大消息） ```java // 生产者配置（需确保 Broker 的 maxMessageSize ≥ 消息大小） DefaultMQProducer producer = new DefaultMQProducer("producer_group"); producer.setNamesrvAddr("localhost:9876"); producer.start(); // 构造大消息（需注意实际大小限制） Message msg = new Message( "TopicTest", "TagA", "Key1", ("超大消息内容..." + "a".repeat(4_000_000)).getBytes(StandardCharsets.UTF_8) ); // 发送前检查大小（推荐） if (msg.getBody().length > 4_194_304) { throw new IllegalArgumentException("消息超过4MB限制"); } producer.send(msg); ``` ### 常见问题解决方案 1. **消息过大报错**： - 错误日志：`MESSAGE_SIZE_EXCEEDED` - 解决方案： - 拆分消息为多条 - 修改 Broker 配置（需评估网络带宽影响） 2. **生产环境建议**： - 保持默认 4MB 限制（避免影响 Broker 吞吐量） - 大文件通过 FTP/OSS 传输，消息体仅传递文件标识
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值