带你认识pulsar负载均衡利器Bundle

本文涉及的产品
应用型负载均衡 ALB,每月750个小时 15LCU
网络型负载均衡 NLB,每月750个小时 15LCU
传统型负载均衡 CLB,每月750个小时 15LCU
简介: 带你认识pulsar负载均衡利器Bundle

Pulsar是一款非常优秀的消息流平台,这篇文章主要讲Pulsar中Topic通过Bundle这个负载均衡利器在Broker中的分配。

1 Topic层级概念

首先看一下Pulsar的架构图,如下图:

微信图片_20221212210544.jpgPulsar的Broker可以管理一个或者多个Topic。Pulsar是一个多租户平台,多租户的特性体现在Topic是一个层级概念,Topic的URL如下图:

微信图片_20221212210622.png

一个Topic可以使用persistent属性指定是否持久化,而Topic的上层使用租户来进行权限隔离,使用Namespace来进行策略管理。

Topic的层级概念也可以用下图来表示:

微信图片_20221212210649.jpg

在一个公司内部的Pulsar集群中,可以根据业务部门建租户,根据业务部门内部的不同项目组来划分Namespace,根据每个项目组的不同业务单元来划分Topic。

2 Namespace Bundles

Pulsar把Namespace拆成了Bundle,Bundle是namespace的子集。如下图一个Namespace下面有6个Topic:

微信图片_20221212210709.png

我们把这个Namespace划分成四个hash区域,从0x00000000~0xffffffff,之后把6个Topic按照名字(上面URL图中的最后一部分)做Hash运算,分配到这四个区域内,如下图:

微信图片_20221212210731.png

上图中,Topic0做Hash运算后值落在了0xc0000000~0xffffffff这个区域,其他几个Topic也分别落到了自己的Hash区域。

为什么要为Namespace划分Bundle子集呢?因为Pulsar有自动负载均衡机制,会把繁忙的Broker里面的一些Topic迁移到比较空闲的Broker中,实现Broker直接的流量均衡。这个搬移如果直接搬移Namespace,会太重,比如上面的图需要一下子搬移6个Topic。如果以Topic为单位,每次搬移数据就会太小,而且搬移过程中需要保存大量Topic和Broker之间的元数据。有了Bundle后,以Bundle为单位进行迁移,迁移Topic会容易很多,比如上图中,一次迁移一个Bundle,有的包含一个Topic,有的包含两个Topic。

3 Broker分配Bundle

Broker集群启动过程中会在Zookeeper竞争创建临时节点,创建成功的成为Leader节点,叫Load Manager,这个节点会定期搜集其他Broker的服务状态,比如CPU、内存、网卡带宽利用率,这些指标都是临时数据,所以Leader节点并不会保存太多数据。

Leader节点会根据搜集到的负载情况为其他Broker节点分配Bundle。如下图:

微信图片_20221212210754.png


上图中Broker1竞争成为Leader,它负责为其他几个Broker分配Bundle。初始化时,每个Broker都没有Boundle,Leader把topic0分配给了Broker3,这就代表topic0所在的Bundle分配给了Broker3,之后Hash值跟topic0相同的都会落到这个Bundle。然后把topic1分配给了Broker2,这就代表topic1所在的Bundle分配给了Broker2。类似把其他2个Bundle分别分配给了Broker0和Broker1。

4 高可用

还是以上面的图为例,如果Broker0宕机了,Load Manager和ZK都能检测到broker0宕机,这时Load Manager会重新把Bundle(0x00000000~0x400000000)分配给其他三个broker,最后选择哪个broker取决于Load Manager收集到的每个broker的负载情况,会找一个负载最小的broker分配。如下图:

微信图片_20221212210816.png

如果Broker1宕机了,也就是Leader节点宕机了,那Broker0、Broker2和Broker3三个节点会去Zookeeper抢占注册临时节点,注册成功的成为新的Leader,新的Leader节点会把Broker1的Bundle分配给剩下的3个Broker。

5 客户端

Topic通过Bundle绑定了Broker之后,客户端就可以跟自己要访问的Broker建立长链接,如下图:

微信图片_20221212210837.png

这里需要注意:图中的第1、2两步既可以用HTTP的方式,也可以用TCP的方式,但是第3步也就是Broker跟client建立连接只能用TCP。

Pulsar为客户端提供了代理,客户端可以直接跟代理通信,如下图:

微信图片_20221212210859.png

6 总结

使用了Bundle,Pulsar可以方便地通过Load Manager节点做负载均衡,不用考虑一次搬移的Topic太多,也不用担心一次搬移一个Topic而需要保存太多元数据。

相关实践学习
SLB负载均衡实践
本场景通过使用阿里云负载均衡 SLB 以及对负载均衡 SLB 后端服务器 ECS 的权重进行修改,快速解决服务器响应速度慢的问题
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
目录
打赏
0
0
0
0
114
分享
相关文章
kafka的使用与负载均衡(Windows环境)
kafka的介绍 Kafka是一个分布式的、可分区的、可复制的消息系统。它提供了普通消息系统的功能,但具有自己独特的设计。它可以像消息系统一样读写数据流,并且可以在实时业务的场景中写可靠的流处理应用,并且能安全地存储数据流到分布式、多副本、容错的集群中。
2833 0
【Apache ShenYu源码】如何实现负载均衡模块设计
整个模块为ShenYu提供了什么功能。我们可以看下上文我们提到的工厂对象。/***/核心方法很清晰,我们传入Upsteam列表,通过这个模块的负载均衡算法,负载均衡地返回其中一个对象。这也就是这个模块提供的功能。
108 1
mod_sflow 轻量、实时的流量分析 Apache 模块
sFlow 是一种网络流量分析的协议。通过流量分析,可以实现更有效地监控网络的状况。例如,最近爆出的OpenSSL心脏出血漏洞,由于是通过 OpenSSL 漏洞直接读取内存信息,而不是直接入侵系统,因此服务器日志上不会有相关的记录,使用常规手段难以难以追查。但是,由于来回通信包的长度等特征非常明显,因此利用sFlow之类的技术分析流量特征,就可以追溯攻击流量和攻击历史。特别是,这次的 OpenSSL 漏洞可以无限制反复利用,这既方便了攻击者,不用依靠精妙的技巧来操控读取地址,反复读取即可获得大量内存片段,另一方面也使攻击行为更容易被侦测到。
586 0
mod_sflow 轻量、实时的流量分析 Apache 模块
Gearman——分布式任务分发框架
工作中我们有时候会遇到比如需要同时发布数据到多个个服务器上,或者同时处理多个任务。可以使用PHP的curl_multi的方式并发处理请求,但是由于网络和数据以及各个服务器等等的一些情况导致这种并发处理的响应时间很慢,因为在并发请求的过程中还包括记录日志,处理数据等逻辑,等待处理结果并返回,所以也不能友好的满足后台操作的体验。
1257 0
《高性能Linux服务器构建实战》——2.7节Varnish的常见应用实例
本节书摘来自华章社区《高性能Linux服务器构建实战》一书中的第2章,第2.7节Varnish的常见应用实例,作者:高俊峰,更多章节内容可以访问云栖社区“华章社区”公众号查看
1285 0
Java微服务开发指南 -- 集群管理、失败转移和负载均衡的实践
# 集群管理、失败转移和负载均衡的实践     在前一章节中,我们快速的介绍了集群管理、Linux容器,接下来让我们使用这些技术来解决微服务的伸缩性问题。作为参考,我们使用的微服务工程来自于第二、第三和第四章节(Spring Boot、Dropwizard和WildFly Swarm)中的内容,接下来的步骤都适合上述三款框架。
6487 0
Nacos多级服务存储模型, NacosRule负载均衡规则入门
下面来简单认识一下今天的主角Nacos吧.Nacos给我们提供了一个这样的服务分级存储模型:1级是服务, 2级是集群, 3级是实例. Nacos提供了权重配置来控制访问频率, 权重越大访问频率越高;Nacos同一集群的默认权重是1:1的;Nacos控制台可以设置实例的权重值0~1之间
581 0

热门文章

最新文章

AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等