2. OverloadShedder

接下来介绍OverloadShedder，在理解不同Shedder的时候，重点关注两个点：

• 什么样的broker判定为超载。

• 判定为超载后，挑选哪些bundle进行unload。

OverloadShedder跟ThresholdShedder在判定broker超载时不一样，但是计算出来需要卸载的流量吞吐大小后，挑选bundle的算法是相同的，都是从大到小开始挑选bundle。

下面详细介绍一下OverloadShedder是如何判定broker超载的。首先，同样会给每个broker进行打分。

org.apache.pulsar.policies.data.loadbalancer.LocalBrokerData#getMaxResourceUsage

public double getMaxResourceUsage() {
    // does not consider memory because it is noisy by gc.
    return max(cpu.percentUsage(), directMemory.percentUsage(), bandwidthIn.percentUsage(),
            bandwidthOut.percentUsage()) / 100;
}

但是注意：这里并没有使用loadBalancerCPUResourceWeight等配置进行加权计算，而是简单地使用了资源使用率，但是正如前面所描述的，直接内存跟真实负载并没有明显关系，因此这里很有可能会被直接内存使用率所干扰，导致误判broker的真实负载。因此，最好让loadBalancerCPUResourceWeight等配置也对OverloadShedder生效，提供一个手段来避免直接内存使用率的干扰。我提交了如下PR，并合并到主分支。

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

得到每个broker的负载打分后，跟loadBalancerBrokerOverloadedThresholdPercentage比较，如果超过该阈值则判定为超载，默认值为85%。

# Usage threshold to determine a broker as over-loaded
loadBalancerBrokerOverloadedThresholdPercentage=85

一个broker判定为超载后，就要计算需要卸载多少流量，算法如下：

double percentOfTrafficToOffload = currentUsage - overloadThreshold + ADDITIONAL_THRESHOLD_PERCENT_MARGIN;
double brokerCurrentThroughput = localData.getMsgThroughputIn() + localData.getMsgThroughputOut();

double minimumThroughputToOffload = brokerCurrentThroughput * percentOfTrafficToOffload;

private static final double ADDITIONAL_THRESHOLD_PERCENT_MARGIN = 0.05;

举个例子，假设一个broker的最大资源使用率为90%，threshold为默认值85，该broker的流量吞吐为10GB，则需要卸载(0.9-0.85+0.05)*10 GB = 1GB。

后面的bundle挑选算法跟ThresholdShedder是完全一致的，这里就不赘述了。

这个算法比较简单，但是有很多严重的corner case，使用率应该不高。这里介绍两个case：

• 当集群每个broker负载都达到阈值时，会一直执行bundle unload，但是只会从一个高载broker切换到另一个高载broker，这是毫无意义的，只会不断地干扰正常的用户流量。

• 如果集群没有broker负载达到阈值时，加入新的空载broker并不会将流量均衡到新broker上面。

这两点的影响都是比较严重的，所以不建议采用OverloadShedder。