Pulsar负载均衡原理及优化

时间:2023-02-07 09:08:41

Pulsar负载均衡原理及优化

前段时间我们在升级 Pulsar 版本的时候发现升级后最后一个节点始终没有流量。
Pulsar负载均衡原理及优化

虽然对业务使用没有任何影响,但负载不均会导致资源的浪费。

和同事沟通后得知之前的升级也会出现这样的情况,最终还是人工调用 Pulsar 的 admin API 完成的负载均衡。

这个问题我尝试在 Google 和 Pulsar 社区都没有找到类似的,不知道是大家都没碰到还是很少升级集群。

我之前所在的公司就是一个版本走到黑????

Pulsar 负载均衡原理

当一个集群可以水平扩展后负载均衡就显得非常重要,根本目的是为了让每个提供服务的节点都能均匀的处理请求,不然扩容就没有意义了。

在分析这个问题的原因之前我们先看看 Pulsar 负载均衡的实现方案。

# Enable load balancer
loadBalancerEnabled=true

我们可以通过这个 broker 的这个配置来控制负载均衡器的开关,默认是打开。

但具体使用哪个实现类来作为负载均衡器也可以在配置文件中指定:

# Name of load manager to use
loadManagerClassName=org.apache.pulsar.broker.loadbalance.impl.ModularLoadManagerImpl

默认使用的是 ModularLoadManagerImpl

    static LoadManager create(final PulsarService pulsar) {
        try {
            final ServiceConfiguration conf = pulsar.getConfiguration();
            // Assume there is a constructor with one argument of PulsarService.
            final Object loadManagerInstance = Reflections.createInstance(conf.getLoadManagerClassName(),
                    Thread.currentThread().getContextClassLoader());
            if (loadManagerInstance instanceof LoadManager) {
                final LoadManager casted = (LoadManager) loadManagerInstance;
                casted.initialize(pulsar);
                return casted;
            } else if (loadManagerInstance instanceof ModularLoadManager) {
                final LoadManager casted = new ModularLoadManagerWrapper((ModularLoadManager) loadManagerInstance);
                casted.initialize(pulsar);
                return casted;
            }
        } catch (Exception e) {
            LOG.warn("Error when trying to create load manager: ", e);
        }
        // If we failed to create a load manager, default to SimpleLoadManagerImpl.
        return new SimpleLoadManagerImpl(pulsar);
    }

broker 启动时会从配置文件中读取配置进行加载,如果加载失败会使用 SimpleLoadManagerImpl 作为兜底策略。

当 broker 是一个集群时,只有 leader 节点的 broker 才会执行负载均衡器的逻辑。

Leader 选举是通过 Zookeeper 实现的。

默然情况下成为 Leader 节点的 broker 会每分钟读取各个 broker 的数据来判断是否有节点负载过高需要做重平衡。

而是否重平衡的判断依据是由 org.apache.pulsar.broker.loadbalance.LoadSheddingStrategy 接口提供的,它其实只有一个函数:

public interface LoadSheddingStrategy {

    /**
     * Recommend that all of the returned bundles be unloaded.
     * @return A map from all selected bundles to the brokers on which they reside.
     */
    Multimap<String, String> findBundlesForUnloading(LoadData loadData, ServiceConfiguration conf);
}

根据所有 broker 的负载信息计算出一个需要被 unload 的 broker 以及 bundle。

这里解释下 unload 和 bundle 的概念:

  • bundle 是一批 topic 的抽象,将 bundlebroker 进行关联后客户端才能知道应当连接哪个 broker;而不是直接将 topic 与 broker 绑定,这样才能实现海量 topic 的管理。
  • unload 则是将已经与 broker 绑定的 bundle 手动解绑,从而触发负载均衡器选择一台合适的 broker 重新进行绑定;通常是整个集群负载不均的时候触发。

ThresholdShedder 原理

LoadSheddingStrategy 接口目前有三个实现,这里以官方默认的 ThresholdShedder 为例:
Pulsar负载均衡原理及优化

它的实现算法是根据带宽、内存、流量等各个指标的权重算出每个节点的负载值,之后为整个集群计算出一个平均负载值。

# 阈值
loadBalancerBrokerThresholdShedderPercentage=10

当集群中有某个节点的负载值超过平均负载值达到一定程度(可配置的阈值)时,就会触发 unload,以上图为例就会将最左边节点中红色部分的 bundle 卸载掉,然后再重新计算一个合适的 broker 进行绑定。

阈值存在的目的是为了避免频繁的 unload,从而影响客户端的连接。

问题原因

当某些 topic 的流量突然爆增的时候这种负载策略确实可以处理的很好,但在我们集群升级的情况就不一定了。

假设我这里有三个节点:

  • broker0
  • broker1
  • broker2

Pulsar负载均衡原理及优化
集群升级时会从 broker2->0 进行镜像替换重启,假设在升级前每个 broker 的负载值都是 10。

  • 重启 broker2 时,它所绑定的 bundle 被 broker0/1 接管。
  • 升级 broker1 时,它所绑定的 bundle 又被 broker0/2 接管。
  • 最后升级 broker0, 它所绑定的 bundle 会被broker1/2 接管。

只要在这之后没有发生流量激增到触发负载的阈值,那么当前的负载情况就会一直保留下去,也就是 broker0 会一直没有流量。

经过我反复测试,现象也确实如此。

./pulsar-perf monitor-brokers --connect-string pulsar-test-zookeeper:2181

Pulsar负载均衡原理及优化
通过这个工具也可以查看各个节点的负载情况

优化方案

这种场景是当前 ThresholdShedder 所没有考虑到的,于是我在我们所使用的版本 2.10.3 的基础上做了简单的优化:
Pulsar负载均衡原理及优化

  • 当原有逻辑走完之后也没有获取需要需要卸载的 bundle,同时也存在一个负载极低的 broker 时(emptyBundle),再触发一次 bundle 查询。
  • 按照 broker 所绑定的数量排序,选择一个数量最多的 broker 的 第一个 bundle 进行卸载。

修改后打包发布,再走一遍升级流程后整个集群负载就是均衡的了。
Pulsar负载均衡原理及优化

但其实这个方案并不严谨,第二步选择的重点是筛选出负载最高的集群中负载最高的 bundle;这里只是简单的根据数量来判断,并不够准确。

正当我准备持续优化时,鬼使神差的我想看看 master 上有人修复这个问题没,结果一看还真有人修复了;只是还没正式发版。

https://github.com/apache/pulsar/pull/17456

Pulsar负载均衡原理及优化

整体思路是类似的,只是筛选负载需要卸载 bundle 时是根据 bundle 自身的流量来的,这样会更加精准。

总结

不过看社区的进度等这个优化最终能用还不知道得多久,于是我们就自己参考这个思路在管理台做了类似的功能,当升级后出现负载不均衡时人工触发一个逻辑:

  • 系统根据各个节点的负载情况计算出一个负载最高的节点和 bundle 在页面上展示。
  • 人工二次确认是否要卸载,确认无误后进行卸载。

本质上只是将上述优化的自动负载流程改为人工处理了,经过测试效果是一样的。

Pulsar 整个项目其实非常庞大,有着几十上百个模块,哪怕每次我只改动一行代码准备发布测试时都得经过漫长的编译+ Docker镜像打包+上传私服这些流程,通常需要1~2个小时;但总的来说收获还是很大的,最近也在提一些 issue 和 PR,希望后面能更深入的参与进社区。