消息队列高手课
李玥
美团高级技术专家
52199 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 42 讲
进阶篇 (21讲)
消息队列高手课
15
15
1.0x
00:00/00:00
登录|注册

23 | RocketMQ客户端如何在集群中找到正确的节点?

NamingService的设计思想
客户端寻找Broker
Broker注册的路由信息处理
RouteInfoManager
总体结构
配合Broker、生产者和消费者
集群模式
功能
通用的NamingService的设计思想
使用NamingService服务
NamingService的职责
NameServer的作用
不需要客户端配置每个Broker的地址
访问整个集群
配置一个接入地址
思考题
总结
NameServer的源代码分析
NameServer的工作
NameServer提供服务
分布式集群的架构设计
NameServer协调Broker和客户端
RocketMQ的生产者启动流程
RocketMQ客户端如何在集群中找到正确的节点?

该思维导图由 AI 生成,仅供参考

你好,我是李玥。
我们在《21 | RocketMQ Producer 源码分析:消息生产的实现过程》这节课中,讲解 RocketMQ 的生产者启动流程时提到过,生产者只要配置一个接入地址,就可以访问整个集群,并不需要客户端配置每个 Broker 的地址。RocketMQ 会自动根据要访问的主题名称和队列序号,找到对应的 Broker 地址。如果 Broker 发生宕机,客户端还会自动切换到新的 Broker 节点上,这些对于用户代码来说都是透明的。
这些功能都是由 NameServer 协调 Broker 和客户端共同实现的,其中 NameServer 的作用是最关键的。
展开来讲,不仅仅是 RocketMQ,任何一个弹性分布式集群,都需要一个类似于 NameServer 服务,来帮助访问集群的客户端寻找集群中的节点,这个服务一般称为 NamingService。比如,像 Dubbo 这种 RPC 框架,它的注册中心就承担了 NamingService 的职责。在 Flink 中,则是 JobManager 承担了 NamingService 的职责。
也就是说,这种使用 NamingService 服务来协调集群的设计,在分布式集群的架构设计中,是一种非常通用的方法。你在学习这节课之后,不仅要掌握 RocketMQ 的 NameServer 是如何实现的,还要能总结出通用的 NamingService 的设计思想,并能应用于其他分布式系统的设计中。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

RocketMQ NameServer是集群中的关键组件,通过协调作用帮助客户端找到正确的Broker节点。NameServer作为独立进程,为Broker、生产者和消费者提供寻址服务,并监控每个Broker的存活状态。在集群模式下,支持多个节点组成集群,避免单点故障。每个Broker需要与所有NameServer节点通信,定时上报路由信息,同时起到心跳作用。客户端只需选择任意一个NameServer节点查询路由信息,然后连接到对应的Broker节点进行生产或消费。NameServer还提供类似Redis的KV读写服务,主要的路由信息由topicQueueTable和brokerAddrTable保存。通过分析NameServer源代码展示了其协调集群中Broker和客户端的工作原理。客户端通过定时从NameServer上拉取主题的路由信息,缓存在本地内存中,以便在需要时使用。NameServer的核心功能在RouteInfoManager类中实现,使用Map在内存中保存集群中所有Broker的路由信息。文章建议读者仔细阅读registerBroker和pickupTopicRouteData方法的代码,体会RocketMQ NameServer的设计思想。最后,文章提出了思考题,让读者思考RocketMQ NameServer集群独特的架构优势和不足。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《消息队列高手课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(28)

  • 最新
  • 精选
  • 业余草
    线上环境突发消息延迟2个小时,该如何尽快解决?以及后期如何避免这类问题?说说你的思路和经验!

    作者回复: 这个我在之前的课程中讲到过,首先需要先看一下是消费慢还是生产慢,如果是生产慢,一般需要扩容Producer的节点数量,如果是消费慢,需要扩容队列数和Consumer数量。

    2019-09-17
    2
    14
  • 康师傅
    对于rocketmq和kafka而言,都有自己的“注册中心”,但对于rabbitmq而言,它的集群允许你连接到集群中的任何一台进行生产消费,即便队列master所在节点并不是你连接的这台,rabbitmq内部会帮你进行中转,但这会有一个很大的弊端,就是节点间会有较大的流量并且不可控,并且整体的性能会受影响 想请问下,这种时候,是否有较好的优化方式? 想到的一个办法是,自行做一个NameServer,按队列进行注册分流,生产者消费者先与NameServer交互得到真实的节点ip,然后直接连接到队列master所在节点进行生产消费

    作者回复: 理论上是可以的,但权衡工作量来说,最好还是换一个MQ吧。

    2019-09-19
    9
  • 我已经设置了昵称
    老师,我们生产环境。同一个group,多台机器消费同一个topic消息,遇到了某几个实例消费的分区延迟特别高,导致消息堆积的情况。但另外几个实例消费的分区并没有堆积。这通过扩容consumer也没法解决。而且很难排查,有什么好的方式吗

    作者回复: 一是查一下每个分区入队速度是不是均匀,另外在消费者加一个消费监控(记录每次消费的时延)看一下消费速度是不是有问题。

    2019-10-25
    8
  • 饭粒
    请问下老师,如果 nameserver 有节点重启了或是新加了一个节点,恢复内存中的路由数据过程是通过 broker 的心跳上报路由信息重新注册一遍吗?

    作者回复: 是的,RocketMQ的NameServer数据是以Broker上的为准,并且是从Broker上同步过来的。

    2019-11-17
    3
  • Better me
    NamingService集群有点像去中心化的结构设计,每个节点保存所有数据,很好的保证了节点的可用性,但每个节点之间不互相通信,很难确保节点间的数据一致性。想问下老师主题(和其中队列)在broker节点的分布情况是怎样的

    作者回复: 主题和队列是分散到所有Broker节点上的,每个Broker只保存自己负责的那部分主题和队列信息。并且实际上在集群中,元数据最终是以Broker上保存的信息为准的。

    2019-09-19
    2
    3
  • Stalary
    老师,我想问一下,如果起了很多个NameServer,都保持长连接的话是不是开销会较大呢,为什么没有采用订阅发布的模式去更新broker呢,是因为即时性吗

    作者回复: 这又是一个设计选择而已,NameServer只是负责存储一下元数据,数据量不大,处理请求的TPS也不高,所以没必要启动很多个NameServer,所以并不会存在你说的很多个NameServer的情况。

    2019-09-17
    2
  • Yippee
    想问下老师文中讲的代码是基于 RocketMQ 的哪个版本啊,我在 4.5.1 和 4.7.0 中找不到 RouteInfoManager 等类

    作者回复: 我们使用当前最新的 release 版本 release-4.5.1 进行分析,使用 Git 在 GitHub 上直接下载源码到本地: git clone git@github.com:apache/rocketmq.git cd rocketmq git checkout release-4.5.1

    2020-05-11
  • 丁小明
    老师你好,有个疑问就是如果客户端链接的那个nameserver不可用了怎么办呢,如果broker也恰好有变动,那这些客户端是不是也都不可用了。且无法自动恢复

    作者回复: 所以一般生产环境都使用多个NameServer节点来避免单点故障。

    2020-05-06
  • fomy
    假如其中一台NameServer挂了,客户端会自动切换到其他的吗?

    作者回复: 是的。

    2020-02-17
  • 我已经设置了昵称
    nameServer本身某几个实例挂了,会怎么处理呢

    作者回复: 挂了也不影响集群正常使用,尽快修复就好了

    2019-10-25
收起评论
显示
设置
留言
28
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部