消息队列后端流处理【免费下载链接】pulsarApache Pulsar - distributed pub-sub messaging system项目地址https://gitcode.com/gh_mirrors/pulsar28/pulsar点击查看免费下载导读本文以 Apache Pulsar 2.2.1 官方管理文档为基础系统讲解 Pulsar 如何在逻辑集群的所有 Broker 之间均匀分布流量从 topic 动态分配、namespace bundle 分片机制、bundle 分裂与卸载操作到自动负载脱落load shedding的阈值计算与全套配置参数。读完本文你将掌握 Pulsar 负载均衡的底层架构能熟练使用pulsar-admin创建多 bundle 命名空间、手动卸载 topic/bundle、按业务场景调优conf/broker.conf中的负载均衡参数含 EC2 网卡速率覆盖技巧。一、Pulsar 负载分布的核心目标与设计前提Pulsar 是一个水平可扩展的消息系统因此一个核心要求是逻辑集群中的流量必须尽可能均匀地分布在所有可用 Broker 上。在大多数场景下这一目标开箱即用无需额外干预。但 Pulsar 提供了多个配置项和工具来控制流量分布理解它们需要先掌握流量在 Pulsar 中是如何被管理的。本文涉及的架构组件与配置参数均可在当前仓库的 conf/broker.confBroker 配置样例与 pulsar-broker-common 的 ServiceConfiguration.java参数定义与默认值中找到对应实现。二、Pulsar Load Manager 架构2.1 Topic 到 Broker 的动态分配Topic 会根据集群内所有 Broker 的负载状况被动态地分配给各个 Broker当客户端开始使用尚未分配给任何 Broker 的新 topic 时会触发一个分配流程根据当前的负载状况选出最适合的 Broker 来获得该 topic 的所有权。对于分区 topicpartitioned topic不同分区可能被分配给不同 Broker。本文语境下的topic统一指一个非分区 topic 或一个 topic 的某个分区。这种分配是动态的因为它可以非常迅速地变化。例如拥有某 topic 的 Broker 崩溃时该 topic 会立即被重新分配给另一个 Broker当某 Broker 过载时其上的 topic 也会被重新分配给负载更低的 Broker。动态分配之所以可行得益于Broker 的无状态特性stateless。这同时也保证了集群可以根据使用量快速扩容或缩容。相关实现可参见 pulsar-broker 的 loadbalance 目录其中LoadManager、PlacementStrategy、LoadSheddingStrategy等接口共同构成了负载管理框架。2.2 分配粒度Namespace Bundletopic/partition 的分配并非在单个 topic 粒度上进行原因是为了摊销需要跟踪的信息量例如哪些 topic 被分配给某个 Broker、Broker 上各 topic 的负载如何等等。作为替代每个 Broker 拥有某个 namespace 下 topics 的一个子集。这个子集被称为bundle本质上是一种分片sharding机制namespace 是管理单元许多配置旋钮和管理操作都在 namespace 级别执行为了分配一个 namespace 被切分为一组 bundle每个 bundle 覆盖该 namespace 整体哈希范围hash range的一部分Topic 通过对 topic 名称取哈希并判断该哈希值落在哪个 bundle 的范围内从而被分配到特定 bundle每个 bundle 相互独立因此可以被独立地分配给不同 Broker。namespace 的哈希空间 [0, 2^32) ├── bundle-0: [0x00000000, 0x0FFFFFFF) ├── bundle-1: [0x10000000, 0x1FFFFFFF) ├── bundle-2: [0x20000000, 0x2FFFFFFF) └── bundle-3: [0x30000000, 0x3FFFFFFF) 示例4 个 bundle 等分哈希范围topic 名哈希后落入对应区间在源码层面NamespaceBundle、NamespaceBundleFactory位于 pulsar-common而 bundle 到 broker 的分配、bundle 数据统计与分裂逻辑由 ModularLoadManagerImpl.java 承载bundle 统计数据以 JSON 形式存放在元数据存储的/loadbalance/bundle-data路径下。三、创建 Namespace 与 Bundle3.1 默认 Bundle 数量创建新 namespace 时默认使用系统默认的 bundle 数量该值在conf/broker.conf中设置# When a namespace is created without specifying the number of bundle, this # value will be used as the default defaultNumberOfNamespaceBundles4该默认值在源码 ServiceConfiguration.java 中定义private int defaultNumberOfNamespaceBundles 4;并同样出现在仓库 conf/standalone.conf 与 Terraform 部署模板 deployment/terraform-ansible/templates/broker.conf 中。3.2 创建时覆盖 Bundle 数量可以修改系统默认值也可以在创建新 namespace 时覆盖它$ bin/pulsar-admin namespaces create my-tenant/my-namespace --clusters us-west --bundles 16这条命令创建了一个初始含 16 个 bundle的 namespace因此该 namespace 的 topic 可以立即分散到最多 16 个 Broker 上。--bundles参数的取值范围与默认值可从 CmdNamespaces.java 的Create命令实现中看到默认numBundles 0不指定时走系统默认值有效范围是(0, 2^32]即 1 到 2^32 之间。该文件同时提供了pulsar-admin namespaces bundles命令用于查询一个 namespace 的 bundle 列表。3.3 规划建议一般来说如果预期流量和 topic 数量在前期已知最好一开始就设置一个合理的 bundle 数量而不是等待系统自动修正分布。同理通常建议 bundle 数量多于 Broker 数量这主要源于 topic 到 bundle 的哈希分布特性。例如一个 namespace 有 1000 个 topic使用类似64 个 bundle的配置即可在 16 个 Broker 上实现良好的流量分布。如果 bundle 数量过少哈希的随机性可能导致个别 bundle 聚集大量热门 topic反之bundle 越多单个 bundle 的粒度越细后续分裂、卸载和重新分配时也更加灵活。四、卸载 Topic 与 Bundle4.1 什么是 UnloadPulsar 中有一个管理操作叫做卸载unloading一个 topic。卸载意味着关闭 topic、释放所有权并根据当前负载将 topic 重新分配给新的 Broker。发生卸载时在 topic 被重新分配期间客户端会经历一次短暂的延迟抖动latency blip通常在几十毫秒量级。卸载是 Load Manager 执行负载脱落load shedding所用的机制但也可以手动触发例如在没有任何 Broker 过载的情况下提前纠正分配、重新分布流量。需要注意的是卸载一个 topic对 assignment分片归属没有影响它只是关闭并重新打开这个特定 topicpulsar-admin topics unload persistent://tenant/namespace/topic要卸载某个 namespace 下的所有 topic 并触发重新分配pulsar-admin namespaces unload tenant/namespace相关命令实现位于 CmdNamespaces.javanamespaces unload与unloadNamespaceBundle和 CmdTopics.javatopics unload。4.2 卸载场景小结场景命令影响单个 topic 卸载pulsar-admin topics unload persistent://tenant/ns/topic关闭并重开该 topic按当前负载重新分配整个 namespace 卸载pulsar-admin namespaces unload tenant/namespace触发该 namespace 下所有 bundle 的重新分配负载脱落自动Load Manager 按阈值自动选择 bundle 卸载由loadBalancerSheddingEnabled等参数控制五、Namespace Bundle 分裂Splitting5.1 分裂动机与过程由于 bundle 中 topic 的负载会随时间变化甚至难以提前预测bundle 可以由 Broker 分裂成 2 个分裂出的更小 bundle 随后可以被重新分配给不同 Broker。分裂基于一些可调阈值发生任何超过任一阈值的现有 bundle 都是分裂的候选者。默认情况下新分裂出的 bundle 也会立即被卸载offload到其他 Broker以促进流量分布。5.2 分裂相关配置以下是conf/broker.conf中与 bundle 分裂相关的完整配置块# enable/disable namespace bundle auto split loadBalancerAutoBundleSplitEnabledtrue # enable/disable automatic unloading of split bundles loadBalancerAutoUnloadSplitBundlesEnabledtrue # maximum topics in a bundle, otherwise bundle split will be triggered loadBalancerNamespaceBundleMaxTopics1000 # maximum sessions (producers consumers) in a bundle, otherwise bundle split will be triggered loadBalancerNamespaceBundleMaxSessions1000 # maximum msgRate (in out) in a bundle, otherwise bundle split will be triggered loadBalancerNamespaceBundleMaxMsgRate30000 # maximum bandwidth (in out) in a bundle, otherwise bundle split will be triggered loadBalancerNamespaceBundleMaxBandwidthMbytes100 # maximum number of bundles in a namespace (for auto-split) loadBalancerNamespaceMaximumBundles128各参数含义与默认值均可在 ServiceConfiguration.java 中核对配置项默认值作用loadBalancerAutoBundleSplitEnabledtrue是否启用 namespace bundle 自动分裂loadBalancerAutoUnloadSplitBundlesEnabledtrue分裂出的 bundle 是否自动卸载到其他 BrokerloadBalancerNamespaceBundleMaxTopics1000单个 bundle 最大 topic 数超过触发分裂loadBalancerNamespaceBundleMaxSessions1000单个 bundle 最大会话数生产者 消费者超过触发分裂loadBalancerNamespaceBundleMaxMsgRate30000单个 bundle 最大消息速率入 出超过触发分裂loadBalancerNamespaceBundleMaxBandwidthMbytes100单个 bundle 最大带宽入 出MB超过触发分裂loadBalancerNamespaceMaximumBundles128namespace 内最大 bundle 数自动分裂的上限5.3 手动分裂除自动分裂外pulsar-admin namespaces split-bundle支持手动分裂指定 bundle并可通过-u/--unload参数决定分裂后是否立即卸载新 bundle见 CmdNamespaces.java 的SplitBundle命令。底层分裂任务逻辑由 BundleSplitterTask.java 实现。六、自动负载脱落Load Shedding6.1 工作原理Pulsar 的 Load Manager 支持自动负载脱落每当系统识别出某个 Broker 过载时它会强制将部分流量重新分配给负载较低的 Broker。当一个 Broker 被判定为过载时它会强制卸载一部分 bundle——流量最高的那些 bundle卸载比例正好补足过载百分比。示例文档原例默认阈值是 85%如果某 Broker 的 CPU 使用率超配额达到 95%那么它将卸载百分比差值 5% 余量(95% - 85%) 5% 15%。由于 bundle 的选择基于流量作为 CPU、网络和内存的代理度量Broker 将卸载至少 15% 流量的 bundle。这一计算逻辑在源码 OverloadShedder.java 中有精确对应// 卸载比例 当前使用率 - 过载阈值 5% 边缘余量 double percentOfTrafficToOffload currentUsage - overloadThreshold ADDITIONAL_THRESHOLD_PERCENT_MARGIN; // 0.05 double minimumThroughputToOffload brokerCurrentThroughput * percentOfTrafficToOffload;同时OverloadShedder 的挑选逻辑包含两个重要约束至少 2 个 bundle 才执行卸载如果 Broker 上只有 1 个 bundle 且过载会打印HIGH USAGE WARNING日志并放弃卸载无法把唯一 bundle 全部搬走遵循宽限期近期loadBalancerSheddingGracePeriodMinutes内被卸载过的 bundle 不会被再次选中挑选时按 bundle 吞吐量入 出使用短期数据getShortTermData()降序排列优先卸载流量最大的 bundle。6.2 开启与关闭自动负载脱落默认启用可通过以下配置禁用# Enable/disable automatic bundle unloading for load-shedding loadBalancerSheddingEnabledtrue6.3 脱落调度参数另有若干作用于脱落的附加设置# Load shedding interval. Broker periodically checks whether some traffic should be offload from # some over-loaded broker to other under-loaded brokers loadBalancerSheddingIntervalMinutes1 # Prevent the same topics to be shed and moved to other brokers more that once within this timeframe loadBalancerSheddingGracePeriodMinutes30配置项默认值作用loadBalancerSheddingEnabledtrue是否启用自动负载脱落loadBalancerSheddingIntervalMinutes1负载脱落检查周期Broker 周期性检查是否需要从过载 Broker 卸载流量到低载 BrokerloadBalancerSheddingGracePeriodMinutes30宽限期防止同一 topic 在该时间窗口内被反复脱落和迁移6.4 Broker 过载阈值Overload ThresholdsBroker 是否过载基于CPU、网络和内存使用率的阈值判定。只要其中任一指标达到阈值就会触发脱落如果启用。默认过载阈值是 85%# Usage threshold to determine a broker as over-loaded loadBalancerBrokerOverloadedThresholdPercentage85使用率统计数据由 Pulsar 从系统指标中采集。在源码中CPU、内存等宿主使用率采集由 LinuxBrokerHostUsageImpl.java 与 GenericBrokerHostUsageImpl.java 完成Broker 的getMaxResourceUsage()返回所有资源使用率的最大值与过载阈值直接比较。七、网络使用率与 EC2 NIC 速率覆盖在网络利用率方面某些情况下 Linux 上报的网络接口速率并不正确需要手动覆盖。典型场景是AWS EC2 实例的 1Gbps NIC操作系统却上报为 10Gbps。由于最大速率不正确Pulsar Load Manager 可能认为 Broker 尚未达到 NIC 容量而实际上带宽已全部用尽、流量正在被降速。为此提供了一个修正最大 NIC 速率的配置项# Override the auto-detection of the network interfaces max speed. # This option is useful in some environments (eg: EC2 VMs) where the max speed # reported by Linux is not reflecting the real bandwidth available to the broker. # Since the network usage is employed by the load manager to decide when a broker # is overloaded, it is important to make sure the info is correct or override it # with the right value here. The configured value can be a double (eg: 0.8) and that # can be used to trigger load-shedding even before hitting on NIC limits. loadBalancerOverrideBrokerNicSpeedGbps当该值为空时Pulsar 使用操作系统上报的值。要点该值支持小数如0.8可用来在尚未触及 NIC 上限之前就触发负载脱落——即通过主动调低网卡速率上限让 Load Manager 提前认为网络资源接近饱和从而更早执行流量疏散。八、配置总览与调优建议8.1 全部负载均衡参数速查表下表汇总本文涉及的全部配置项及其默认值均可在 conf/broker.conf 中查看实际注释与取值类别配置项默认值namespace 默认分片defaultNumberOfNamespaceBundles4负载管理器总开关loadBalancerEnabledtrue放置策略loadBalancerPlacementStrategyleastLoadedServer自动分裂loadBalancerAutoBundleSplitEnabledtrue分裂后自动卸载loadBalancerAutoUnloadSplitBundlesEnabledtruebundle 最大 topic 数loadBalancerNamespaceBundleMaxTopics1000bundle 最大会话数loadBalancerNamespaceBundleMaxSessions1000bundle 最大消息速率loadBalancerNamespaceBundleMaxMsgRate30000bundle 最大带宽loadBalancerNamespaceBundleMaxBandwidthMbytes100namespace 最大 bundle 数loadBalancerNamespaceMaximumBundles128自动脱落开关loadBalancerSheddingEnabledtrue脱落检查周期loadBalancerSheddingIntervalMinutes1脱落宽限期loadBalancerSheddingGracePeriodMinutes30过载阈值loadBalancerBrokerOverloadedThresholdPercentage85网卡速率覆盖loadBalancerOverrideBrokerNicSpeedGbps空使用 OS 上报值注源码中还存在更多负载均衡相关参数如loadBalancerBrokerUnderloadedThresholdPercentage50、loadBalancerBrokerMaxTopics50000、资源权重loadBalancerCPUResourceWeight等它们服务于不同的 shedding 策略如 ThresholdShedder.java、UniformLoadShedder.java高版本 Pulsar 中可通过loadBalancerLoadSheddingStrategy切换。8.2 实操调优建议新 namespace 优先指定 bundle 数已知预期流量时用--bundles显式创建避免等待自动修正。经验法则bundle 数应大于 Broker 数且 topic 越多 bundle 应越多如 1000 个 topic 配 64 个 bundle 分布在 16 个 Broker。按负载特征收紧分裂阈值如果单个 bundle 的 topic 数、会话数或消息速率增长过快适当调低loadBalancerNamespaceBundleMaxTopics/MaxSessions/MaxMsgRate/MaxBandwidthMbytes让分裂更早发生。关注过载阈值与宽限期loadBalancerBrokerOverloadedThresholdPercentage85是脱落的触发线loadBalancerSheddingGracePeriodMinutes30防止 bundle 被反复搬迁。需要更激进的平衡可适当调低阈值。云环境务必核对网卡速率在 EC2 等虚拟化环境检查系统上报的 NIC 速率是否真实不准时用loadBalancerOverrideBrokerNicSpeedGbps覆盖甚至可设小数如0.8以提前触发脱落。手动纠正分配出现热点且不想等自动脱落时用pulsar-admin topics unload或pulsar-admin namespaces unload主动重新分配。九、小结Pulsar 的负载均衡体系可以概括为一条链路namespace 按哈希切分为 bundle → bundle 独立分配给 Broker → 热点 bundle 自动分裂 → 过载 Broker 触发自动负载脱落卸载高流量 bundle。理解 bundle 这一核心抽象是掌控 Pulsar 流量分布的关键动态分配依赖 Broker 的无状态性topic 可快速在 Broker 间迁移bundle 分片以 namespace 为管理单元摊薄了分配跟踪的开销分裂与卸载是负载均衡的两大执行手段既可自动触发也可手动操作过载判定基于 CPU/网络/内存的 85% 阈值默认脱落比例按超出部分 5% 余量计算云环境网络上报偏差可通过loadBalancerOverrideBrokerNicSpeedGbps修正。掌握以上机制后你可以在多 Broker 集群上主动规划 bundle 数量、灵活运用卸载命令并精准调优自动分裂与负载脱落参数让 Pulsar 集群的流量分布始终处于最佳状态。更多底层设计可进一步阅读 pulsar-broker 的 loadbalance 源码目录 以及仓库内对应版本的 reference-configuration 文档。赞分享消息队列后端流处理【免费下载链接】pulsarApache Pulsar - distributed pub-sub messaging system项目地址https://gitcode.com/gh_mirrors/pulsar28/pulsar点击查看免费下载相关推荐Apache Pulsar 负载分布机制详解Broker 间流量均衡、Bundle 拆分与自动负载均衡实践Apache Pulsar 负载分布机制详解Broker 间流量均衡、Bundle 拆分与自动负载均衡实践 本文基于 Apache Pulsar 官方文档v消息队列后端流处理Apache Pulsar 负载均衡架构与配置实战Bundle 分配、Unload 与自动负载均衡Apache Pulsar 负载均衡架构与配置实战Bundle 分配、Unload 与自动负载均衡 本文以 Apache Pulsar 的负载均衡机制为主题消息队列后端流处理5分钟掌握PyfaEVE Online舰船配置的终极免费工具5分钟掌握PyfaEVE Online舰船配置的终极免费工具 在浩瀚的EVE Online宇宙中每一次舰船配置都关乎生死存亡。无论你是刚踏入新伊甸的新手飞行消息队列后端流处理创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
