作者 | 狂野
编辑 | Irene
导读：本文介绍了 Pulsar 负载均衡相关的概念，以及 Pulsar 负载的分配管理原理。
更多干货请关注微信公众号“StreamNative” 。
image
Pulsar 定位为云级别可伸缩的消息系统解决方案，其核心设计在于逻辑集群能够尽可能的把负载（traffic）均匀分布在各个可用的 Broker 上。
在大多数情况下，Pulsar 是开箱即用的，不必过多关注配置。 然而，即使这样，Pulsar 有多种参数设置和管理工具可以控制负载分配，下面我们一起来了解 Pulsar 中负载是怎么分配管理的。
动态分配 Topic 到 Broker 上
基于 Broker 集群负载状况，Topic 将动态分配到 Broker 上。当客户端创建新的还没有分配到任何 Broker 的 Topic 时，会触发一个动作：在给定负载条件的情况下，它将选择最适合的 Broker 来作为新 Topic 的所有者。
当然，对于 Partition Topic，不同的 Partition 可能被分配到不同的 Broker 上。注意，这里谈论的 **Topic **是无分区的 Topic 或者 Partition Topic 中的一个 Partition。
分配是“动态的”，因为变更非常快速。例如：如果拥有该 Topic 的 Broker 宕机了，或者拥有该 Topic 的 Broker 负载过大，则该 Topic 将立即重新分配给另一个 Broker 。 在这种情况下，该 Topic 也将重新分配给负载较低的 Broker 。Broker 的无状态特性使得动态分配成为可能， 这也确保根据实际使用情况可以快速扩容或缩容（可伸缩）。
分配粒度
对于要分配到 Broker 上的 Topic/Partition 来说，它不是在自身（Topic/Partition）的级别上进行分配的，而是在更高一层的级别 Bundle 上进行分配，这样做是为了减少元数据的信息。通过对系统 CPU、内存、网络负载等指标数据采集，然后根据指标数据把 Topic 动态分配到特定的 Broker 上（负载均衡）。
每个 Broker 都拥有 Namespace（命名空间）下 Topic 的子集，而不是单独的 Topic/Partition 分区分配。 这个子集称为“ Bundle ”（下文详解），实际上它是一个分片机制。Namespace 是“管理”单元：许多配置开关或操作在命名空间级别完成。
对于分配，Namespace 被分片为 Bundles 列表，每个 Bundle 包含 Namespace 的整个哈希范围的一部分。通过计算 Topic 的哈希码来确定把 Topic 分配给特定的 Bundle 。每个 Bundle 都是互相独立的，被分配到不同的 Broker 上。
创建 Namespace 和 Bundle
当创建新的 Namespace 时，需要在 conf/broker.conf 文件中设置 **Bundle ** 的数量。
创建命名空间时若没有设置 bundle 数量，这个值为 bundle 的默认数量
defaultNumberOfNamespaceBundles=4
当然，也能改变系统默认值，创建新 Namespace 时，可以用如下命令覆盖：
bin/pulsar-admin namespaces create my-tenant/my-namespace --clusters us-west --bundles 16
用这命令，可以创建有16个 Bundle 的 Namespace 。因此，此 Namespace 的 Topic 最多可以立即分布在16个 bundle 中。一般的，如果预先知道系统将要承载的负载和 Topic 数量，最佳实践是设置一个合理数量的 Bundle 而不是将来等待系统自动变更分片。
同样，系统投入使用时，Bundle 数量比 Broker 数量多通常是有益的。主要因为 Topic 分配到 Bundle 中的哈希散列特性。 例如，对于具有1000个 Topic 的 Namespace，使用64个 Bundle 在16个 Broker 中就能实现良好的负载分配。
卸载 Topic 和 Bundle 的关系
Pulsar 中有一个 卸载 Topic 的管理命令，卸载意味着关闭 Topic，释放所有者，然后基于当前负载，重新把 Topic 分配到新的 Broker 上。
发生卸载时，客户端将经历有极小的延迟抖动，通常耗时10ms左右，与此同时，Topic 将被重新分配到新的 Broker 上。卸载是负载管理器用于执行减载的机制，也可以手动触发，例如，即使在任何 Broker 超载之前，也要变更分配并重新分配负载。
卸载 Topic 对于分配来讲没有影响，仅仅是关闭和重新打开此 Topic：
pulsar-admin topics unload persistent://tenant/namespace/topic
卸载 Namespace 下所有的 Topic 触发重分配：
pulsar-admin namespaces unload tenant/namespace
Namespace Bundles 拆分
由于 Bundle 中 Topic 的负载可能随着时间的推移发生变化，也很难预先预测到，因此 Bundle 可以由 Broker 分成 2 个。 然后将新的较小的 Bundle 重新分配给不同的 Broker 。
拆分发生在可调节的阈值上。 超过阈值的 Bundle 会成为候选 Bundle 被拆分。 默认情况下，新拆分的 Bundle 也会立即卸载（分配到）到其他负载较低的 Broker，以促进负载均衡。
启用/禁用自动拆分 Namespace Bundle
loadBalancerAutoBundleSplitEnabled=true
启用/禁用自动卸载拆分 Bundle
loadBalancerAutoUnloadSplitBundlesEnabled=true
Bundle 中 topic 最多为1000，超过会触发拆分 bundle
loadBalancerNamespaceBundleMaxTopics=1000
Bundle 中会话数最多（包括生产者和消费者）为1000，超过会触发拆分 Bundle
loadBalancerNamespaceBundleMaxSessions=1000
Bundle 中消息数最多为 30000（包括输入和输出），超过会触发拆分 Bundle
loadBalancerNamespaceBundleMaxMsgRate=30000
Bundle 中宽带最大为 100M(包括扇入和扇出)，超过会触发拆分 Bundle
loadBalancerNamespaceBundleMaxBandwidthMbytes=100
Namespace 中 Bundle 数量最大为128，超过则自动拆分
loadBalancerNamespaceMaximumBundles=128
（负载高）自动减少负载
Broker 超载时，Pulsar 负载均衡管理器支持自动降低负载。也就是说，当系统认为 broker 过载时，它将强制一部分负载分流到其他负载较低的 broker 上。
当负载管理器判断 broker 超载时，broker 会被强制卸载到具有较高负载的 bundle 子集，以降低其负载。
例如，默认阈值为85%，如果 broker 超过 CPU 使用率95%配额，将卸载这中间的差额并加上5%的余量：(95% - 85%) + 5% = 15%。
考虑到选择要卸载的 bundle 基于流量（作为 CPU，网络，内存计算代理），broker 将卸载 bundle 至少15%的负载。默认情况下，启用自动减少负载；如果要禁用，可以采用如下方式：
启用/禁用自动 bundle 卸载
loadBalancerSheddingEnabled=true
还有2个 shedding 参数如下：
负载 shedding 间隔。broker 会周期性的检查是否把负载从超载的 broker 分配到负载低的 broker 上去。
loadBalancerSheddingIntervalMinutes=1
在此时间范围内，防止相同的 topic 被移除并转移到其他 broker 上。
loadBalancerSheddingGracePeriodMinutes=30
broker 超载阈值
决定 broker 何时负载超载是基于 CPU 、网络和内存指标阈值。无论什么时候这指标达到阈值时，将触发一个减负动作（如果启用）
决定 broker 是否负载超载是基于 CPU 、网络和内存指标阈值。无论这些指标中任意一个达到阈值时，都会触发减负动作（如果启用）。
负载阈值默认为 85%：
loadBalancerBrokerOverloadedThresholdPercentage=85
Pulsar 从系统指标收集使用情况统计信息。在某些情况下，Linux 报告的网络接口速度不正确，需要人工设置网络带宽值。 在具有1Gbps NIC 速度的 AWS EC2 实例中就是这种情况，OS 报告10 Gbps 的速度。
由于最大速度不正确，Pulsar 负载管理器可能认为代理尚未达到 NIC 容量，而实际上它已经在使用所有带宽并且流量正在减慢。
可以通过以下设置修正最大 NIC 速度：
loadBalancerOverrideBrokerNicSpeedGbps=
当这个值为空时，Pulsar 将用 OS 报告的值。
网友评论