本篇内容主要讲解“TopicLookup请求处理方法是什么”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“TopicLookup请求处理方法是什么”吧!简单逻辑说明通过topi 香港云主机c名字确定namespace查找这个namespace的bundle分配信息根据bundle分配信息来确认这个topic属于哪个bundle根据bundle信息来确认哪个broker负责这个bundle，返回broker的地址。CommandLookup 主要用来查找Topic在被哪个broker负责。
一般客户端可以通过http协议或者二进制协议来查询。这里直接看服务端的代码ServerCnxorg.apache.pulsar.broker.lookup.TopicLookupBase#lookupTopicAsync
这个是一个静态方法
主要validation 校验集群，topic名字等（这里面有跨集群检查的逻辑，先略过）lookup逻辑这里校验的逻辑先略过了，实际核心的逻辑在下面这2行上。这里面的主要逻辑在NamespaceService里面，PulsarService 可以认为是一个全局对象，pulsar需要的任何核心逻辑对象
（比如说NamspaceService,BrokerService,ConfigurationCacheService等）你都可以从这个对象里面拿到。这里面的主要逻辑是
根据传递过来的topic名字定位namespace
之后确认这个topic属于哪个NamespaceBundle。
之后根据这个NamespaceBundle 来找到这个bundle 的owner broker的地址。这里面的bundleFactory实际上是一个异步加载的cache。我们看一下定义这里简单说一下NamespaceBundles 这个类，这个类会保存这个Namespace的所有NamespaceBundle，提供一个聚合的视图。这个类表示一个hash环，这个环按照配置的分片个数，会被分成几个片段，
每个broker会按照一定算法来确定这个环上的哪一部分属于他自己。
topic也会按照一定的算法分配到这个hash环上。
这样broker就能确定自己负责哪些topic。
就可以返回lookup请求了，这个流程也会触发topic的加载流程。这个函数就是确定这个topic属于哪个NamespaceBundle到这一步我们就能确定这个namespace的信息了，namespce被分为多少个bundle。
而且可以确定这个topic属于哪个namespacebundle。
下一步是根据namespaceBundle查找负责的broker。到这里是根据namespacebundle 确定broker这样如果cache中存在这个topic的owner信息，就可以直接返回。到此，相信大家对“TopicLookup请求处理方法是什么”有了更深的了解，不妨来实际操作一番吧！这里是开发云网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
相关推荐: ORACLE物化视图怎么解决CMS数据同步与来不及的DATA PIPLELINE
这篇文章给大家介绍ORACLE物化视图怎么解决CMS数据同步与来不及的DATA PIPLELINE，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。为啥要牵扯仅DataPiple Line, 因为如果有DataPipe Line,我下面的故事…
免责声明：本站发布的图片视频文字，以转载和分享为主，文章观点不代表本站立场，本站不承担相关法律责任；如果涉及侵权请联系邮箱：360163164@qq.com举报，并提供相关证据，经查实将立刻删除涉嫌侵权内容。
微信扫一扫 
