消息队列高手课
李玥
京东零售技术架构部资深架构师
立即订阅
8426 人已学习
课程目录
已完结 41 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (2讲)
开篇词 | 优秀的程序员,你的技术栈中不能只有“增删改查”
免费
预习 | 怎样更好地学习这门课?
基础篇 (8讲)
01 | 为什么需要消息队列?
02 | 该如何选择消息队列?
03 | 消息模型:主题和队列有什么区别?
04 | 如何利用事务消息实现分布式事务?
05 | 如何确保消息不会丢失?
06 | 如何处理消费过程中的重复消息?
07 | 消息积压了该如何处理?
08 | 答疑解惑(一) : 网关如何接收服务端的秒杀结果?
进阶篇 (21讲)
09 | 学习开源代码该如何入手?
10 | 如何使用异步设计提升系统性能?
11 | 如何实现高性能的异步网络传输?
12 | 序列化与反序列化:如何通过网络传输结构化的数据?
13 | 传输协议:应用程序之间对话的语言
14 | 内存管理:如何避免内存溢出和频繁的垃圾回收?
加餐 | JMQ的Broker是如何异步处理消息的?
15 | Kafka如何实现高性能IO?
16 | 缓存策略:如何使用缓存来减少磁盘IO?
17 | 如何正确使用锁保护共享数据,协调异步线程?
18 | 如何用硬件同步原语(CAS)替代锁?
19 | 数据压缩:时间换空间的游戏
20 | RocketMQ Producer源码分析:消息生产的实现过程
21 | Kafka Consumer源码分析:消息消费的实现过程
22 | Kafka和RocketMQ的消息复制实现的差异点在哪?
23 | RocketMQ客户端如何在集群中找到正确的节点?
24 | Kafka的协调服务ZooKeeper:实现分布式系统的“瑞士军刀”
25 | RocketMQ与Kafka中如何实现事务?
26 | MQTT协议:如何支持海量的在线IoT设备?
27 | Pulsar的存储计算分离设计:全新的消息队列设计思路
28 | 答疑解惑(二):我的100元哪儿去了?
案例篇 (7讲)
29 | 流计算与消息(一):通过Flink理解流计算的原理
30 | 流计算与消息(二):在流计算中使用Kafka链接计算任务
31 | 动手实现一个简单的RPC框架(一):原理和程序的结构
32 | 动手实现一个简单的RPC框架(二):通信与序列化
33 | 动手实现一个简单的RPC框架(三):客户端
34 | 动手实现一个简单的RPC框架(四):服务端
35 | 答疑解惑(三):主流消息队列都是如何存储消息的?
测试篇 (2讲)
期中测试丨10个消息队列热点问题自测
免费
期末测试 | 消息队列100分试卷等你来挑战!
结束语 (1讲)
结束语 | 程序员如何构建知识体系?
消息队列高手课
登录|注册

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

李玥 2019-09-17
你好,我是李玥。
我们在《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/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《消息队列高手课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(18)

  • 益军
    优点: nameserver本身设计为无状态,实现简单,
    缺点: broker客户端通信成本复杂,适合在客户端环境完全可控的情况下设计。namesrv 一致性无法保证,需要定时幂等性心跳保持最终一致性。
    2019-09-20
    1
    2
  • 业余草
    线上环境突发消息延迟2个小时,该如何尽快解决?以及后期如何避免这类问题?说说你的思路和经验!

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

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

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

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

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

    2019-09-19
    1
  • 饭粒
    优点:实现简单,集群节点平等,比较容易的水平扩展节点数量提供高可用性。路由数据读写都是内存,QPS比较高。
    缺点:每个 broker 需要与所有 nameserver 节点心跳通信,通信成本较大,无法保证强一致性。
    2019-11-17
  • 饭粒
    请问下老师,如果 nameserver 有节点重启了或是新加了一个节点,恢复内存中的路由数据过程是通过 broker 的心跳上报路由信息重新注册一遍吗?

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

    2019-11-17
  • PeterLu
    优点是性能高,Broker只需关心单个节点,而不需要关注集群状态,客户端只需要和一个NameServer打交道,不用关心集群状态。
    缺点是不能保证一致性
    2019-11-01
  • 微笑
    nameserver服务感觉跟注册中心有点像
    2019-10-25
  • 我已经设置了昵称
    nameServer本身某几个实例挂了,会怎么处理呢

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

    2019-10-25
  • 柳俊波
    优点:
    1:Nameserver高可用,节点之间无状态,减少节点同步逻辑,非常轻量级。
    缺点:
    1:牺牲了一致性。两个nameserver数据不一致,导致消息数据倾斜
    2019-10-24
  • WL
    请问一下老师,如果namingServer集群的各节点在多机房部署,如果一个机房与所有broker的通信中断了,那这个节点的namingServer上的信息就与其他namingServer不一致了,出现这种情况怎么办?

    作者回复: 实际上,RocketMQ的路由数据是以Broker为准的,所以不会存在数据不一致的情况。由于NameServer与Broker有心跳机制,在这种发生网络隔离情况下,每个NameServer上就只有它可以连通的那些Broker的路由数据了。这也符合实际情况。

    2019-10-12
    1
  • 囊子
    还有个缺点是NameService不支持写扩展,增加服务节点无法水平扩展,让我想起了zookeeper。不知道理解是否正确。
    2019-09-29
  • 康师傅
    对于rocketmq和kafka而言,都有自己的“注册中心”,但对于rabbitmq而言,它的集群允许你连接到集群中的任何一台进行生产消费,即便队列master所在节点并不是你连接的这台,rabbitmq内部会帮你进行中转,但这会有一个很大的弊端,就是节点间会有较大的流量并且不可控,并且整体的性能会受影响

    想请问下,这种时候,是否有较好的优化方式?
    想到的一个办法是,自行做一个NameServer,按队列进行注册分流,生产者消费者先与NameServer交互得到真实的节点ip,然后直接连接到队列master所在节点进行生产消费

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

    2019-09-19
  • leslie
    老师最近的课都是在啃代码且非常整体性:学习上是越来越辛苦了,总要翻阅和梳理知识才能明白题目可能的问题。
        节点之间不互相通信其实减少了网络开销以及相互的等待确认的过程从而节约了时间,不会互相影响互相继承:换个角度来思考这个问题其实就像是我们用虚拟化一样,RocketMQ的这种NameServer就像是docker/Kubernetes,各自出了问题不会影响其它的docker/K8。
       优势就是减少了节点之间的通信以及等待的代价,不足就是出了问题如何发现以及通知系统/服务端。等待老师对于这个问题的答案的公布:等待明天老师继续的分享,谢谢。
    2019-09-18
  • DFighting
    多个NameServer独立对外提供服务是一种用冗余的路由注册来换维持集群式的NameServer间数据一致性和高可用性的方式,集群部署不可避免需要在数据一致性和高可用性间平衡,这会给程序设计、编码和后溪维护带来很大的代价,因为路由信息本就不会太多,所以选择了前者。
    不过我更偏向于后者,单节点独立提供服务肯定会出现某个节点请求当前的NameServer找不到对应的正常Broker的情况,因为NameServer不能保证保存了完整的Broker集群拓扑。路由发现算法虽然会导致一些时间的服务不可用,但在Broker集群体量很大的时候,肯定比独立NameServer好点。当然目前也可以考虑部署RocketMQ集群,让每个独立的NameServer服务部分区域的Broker的设计思路吧
    2019-09-17
  • 有铭
    这整个就是一个微服务架构
    2019-09-17
  • 糖醋🏀
    nnameserver各个节点独立不通信,是ap的思路。
    各个节点总是可用,但是节点之间不通信,有可能由于网络原因,某个节点的路由信息可能会不一致。
    客户端拉去所有节点的路由信息,可以弥补某个节点路由信息不一致的情况。
    2019-09-17
  • Stalary
    老师,我想问一下,如果起了很多个NameServer,都保持长连接的话是不是开销会较大呢,为什么没有采用订阅发布的模式去更新broker呢,是因为即时性吗

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

    2019-09-17
收起评论
18
返回
顶部