載均衡技術全解析：Pulsar 分散式系統的最佳實踐

crossoverJie發表於2024-07-16
分散式

背景

Pulsar 有提供一個查詢 Broker 負載的介面：

    /**
     * Get load for this broker.
     *
     * @return
     * @throws PulsarAdminException
     */
LoadManagerReport getLoadReport() throws PulsarAdminException;

public interface LoadManagerReport extends ServiceLookupData {  
  
    ResourceUsage getCpu();  
  
    ResourceUsage getMemory();  
  
    ResourceUsage getDirectMemory();  
  
    ResourceUsage getBandwidthIn();  
  
    ResourceUsage getBandwidthOut();
}

可以返回一些 broker 的負載資料，比如 CPU、記憶體、流量之類的資料。

我目前碰到的問題是目前會遇到部分節點的負債不平衡，導致資源佔用不均衡，所以想要手動查詢所有節點的負載資料，然後人工進行負載。

理論上這些資料是在執行時實時計算的資料，如果對於單機的倒還好說，每次請求這個介面直接實時計算一次就可以了。

但對於叢集的服務來說會有多個節點，目前 Pulsar 提供的這個介面只能查詢指定節點的負載資料，也就是說每次得傳入目標節點的 IP 和埠。

所以我的預期是可以提供一個查詢所有節點負載的介面，已經提了 issue，最近準備寫 Purpose 把這個需求解決了。

實現這個需求的方案有兩種：

  1. 拿到所有 broker 也就是服務節點資訊，依次遍歷呼叫介面，然後自己組裝資訊。
  2. 從 zookeeper 中獲取負載資訊。

理論上第二種更好，第一種實現雖然更簡單，但每次都發起一次 http 請求，多少有些浪費。

第二種方案直接從源頭獲取負載資訊，只需要請求一次就可以了。

而正好社群提供了一個命令列工具可以直接列印所有的 broker 負載資料：

pulsar-perf monitor-brokers --connect-string <zookeeper host:port>

分散式系統常用元件

提供的命令列工具其實就是直接從 zookeeper 中查詢的資料。

在分散式系統中需要一個集中的元件來管理各種資料，比如：

  1. 可以利用該元件來選舉 leader 節點
  2. 使用該元件來做分散式鎖
  3. 為分散式系統同步資料
  4. 統一的存放和讀取某些資料

可以提供該功能的元件其實也不少：

  • zookeeper
  • etcd
  • oxia

Zookeeper 是老牌的分散式協調元件，可以做 leader 選舉、配置中心、分散式鎖、服務註冊與發現等功能。

在許多中介軟體和系統中都有應用，比如：

  • Apache Pulsar 中作為協調中心
  • Kafka 中也有類似的作用。
  • 在 Dubbo 中作為服務註冊發現元件。

etcd 的功能與 zookeeper 類似，可以用作服務註冊發現，也可以作為 Key Value 鍵值對儲存系統；在 kubernetes 中扮演了巨大作用，經歷了各種考驗，穩定性已經非常可靠了。

Oxia 則是 StreamNative 開發的一個用於替換 Zookeeper 的中介軟體，功能也與 Zookeeper 類似；目前已經可以在 Pulsar 中替換 Zookeeper，只是還沒有大規模的使用。

Pulsar 中的應用

下面以 Pulsar 為例（使用 zookeeper），看看在這類大型分散式系統中是如何處理負載均衡的。

再開始之前先明確下負載均衡大體上會做哪些事情。

  1. 首先上報自己節點的負載資料
  2. Leader 節點需要定時收集所有節點的負載資料。
    1. 這些負載資料中包括：
      1. CPU、堆記憶體、堆外記憶體等通用資料的使用量
      2. 流出、流入流量
      3. 一些系統特有的資料，比如在 Pulsar 中就是：
        1. 每個 broker 中的 topic、consumer、producer、bundle 等資料。
  3. 再由 leader 節點讀取到這些資料後選擇負載較高的節點，將資料遷移到負載較低的節點。

以上就是一個完整的負載均衡的流程，下面我們依次看看在 Pulsar 中是如何實現這些邏輯的。

在 Pulsar 中提供了多種負載均衡策略，以下是載入負載均衡器的邏輯：

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);  
}

預設使用的是 ModularLoadManagerImpl， 如果出現異常那就會使用 SimpleLoadManagerImpl 作為兜底。

他們兩個的區別是 ModularLoadManagerImpl 的功能更全，可以做更為細緻的負載策略。

接下來以預設的 ModularLoadManagerImpl 為例講解上述的流程。

上報負載資料

在負載均衡器啟動的時候就會收集節點資料然後進行上報：

      public void start() throws PulsarServerException {
        try {

            String brokerId = pulsar.getBrokerId();
            brokerZnodePath = LoadManager.LOADBALANCE_BROKERS_ROOT + "/" + brokerId;
            // 收集本地負載資料
            updateLocalBrokerData();

			// 上報 zookeeper
            brokerDataLock = brokersData.acquireLock(brokerZnodePath, localData).join();
        } catch (Exception e) {
            log.error("Unable to acquire lock for broker: [{}]", brokerZnodePath, e);
            throw new PulsarServerException(e);
        }
    }

首先獲取到當前 broker 的 Id 然後拼接一個 zookeeper 節點的路徑，將生成的 localData 上傳到 zookeeper 中。

// 存放 broker 的節點資訊
ls /loadbalance/brokers

[broker-1:8080, broker-2:8080]

// 根據節點資訊查詢負載資料
get /loadbalance/brokers/broker-1:8080

上報的資料：

{"webServiceUrl":"http://broker-1:8080","pulsarServiceUrl":"pulsar://broker-1:6650","persistentTopicsEnabled":true,"nonPersistentTopicsEnabled":true,"cpu":{"usage":7.311714728372232,"limit":800.0},"memory":{"usage":124.0,"limit":2096.0},"directMemory":{"usage":36.0,"limit":256.0},"bandwidthIn":{"usage":0.8324254085661579,"limit":1.0E7},"bandwidthOut":{"usage":0.7155446715644209,"limit":1.0E7},"msgThroughputIn":0.0,"msgThroughputOut":0.0,"msgRateIn":0.0,"msgRateOut":0.0,"lastUpdate":1690979816792,"lastStats":{"my-tenant/my-namespace/0x4ccccccb_0x66666664":{"msgRateIn":0.0,"msgThroughputIn":0.0,"msgRateOut":0.0,"msgThroughputOut":0.0,"consumerCount":2,"producerCount":0,"topics":1,"cacheSize":0}},"numTopics":1,"numBundles":1,"numConsumers":2,"numProducers":0,"bundles":["my-tenant/my-namespace/0x4ccccccb_0x66666664"],"lastBundleGains":[],"lastBundleLosses":[],"brokerVersionString":"3.1.0-SNAPSHOT","protocols":{},"advertisedListeners":{"internal":{"brokerServiceUrl":"pulsar://broker-1:6650"}},"loadManagerClassName":"org.apache.pulsar.broker.loadbalance.impl.ModularLoadManagerImpl","startTimestamp":1690940955211,"maxResourceUsage":0.140625,"loadReportType":"LocalBrokerData"}

採集資料

public static SystemResourceUsage getSystemResourceUsage(final BrokerHostUsage brokerHostUsage) {  
    SystemResourceUsage systemResourceUsage = brokerHostUsage.getBrokerHostUsage();  
  
    // Override System memory usage and limit with JVM heap usage and limit  
    double maxHeapMemoryInBytes = Runtime.getRuntime().maxMemory();  
    double memoryUsageInBytes = Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory();  
    double memoryUsage = memoryUsageInBytes / MIBI;  
    double memoryLimit = maxHeapMemoryInBytes / MIBI;  
    systemResourceUsage.setMemory(new ResourceUsage(memoryUsage, memoryLimit));  
  
    // Collect JVM direct memory  
    systemResourceUsage.setDirectMemory(new ResourceUsage((double) (getJvmDirectMemoryUsed() / MIBI),  
            (double) (DirectMemoryUtils.jvmMaxDirectMemory() / MIBI)));  
  
    return systemResourceUsage;  
}

會在執行時獲取一些 JVM 和 堆外記憶體的資料。

收集所有節點資料

作為 leader 節點還需要收集所有節點的負載資料，然後根據一些規則選擇將負載較高的節點移動到負債較低的節點中。

    private void updateAllBrokerData() {
	    // 從 zookeeper 中獲取所有節點
        final Set<String> activeBrokers = getAvailableBrokers();
        final Map<String, BrokerData> brokerDataMap = loadData.getBrokerData();
        for (String broker : activeBrokers) {
            try {
                String key = String.format("%s/%s", LoadManager.LOADBALANCE_BROKERS_ROOT, broker);
                // 依次讀取各個節點的負載資料
                Optional<LocalBrokerData> localData = brokersData.readLock(key).get();
                if (!localData.isPresent()) {
                    brokerDataMap.remove(broker);
                    log.info("[{}] Broker load report is not present", broker);
                    continue;
                }

                if (brokerDataMap.containsKey(broker)) {
                    // Replace previous local broker data.
                    brokerDataMap.get(broker).setLocalData(localData.get());
                } else {
                    // Initialize BrokerData object for previously unseen
                    // brokers.
                    // 將資料寫入到本地快取
                    brokerDataMap.put(broker, new BrokerData(localData.get()));
                }
            } catch (Exception e) {
                log.warn("Error reading broker data from cache for broker - [{}], [{}]", broker, e.getMessage());
            }
        }
        // Remove obsolete brokers.
        for (final String broker : brokerDataMap.keySet()) {
            if (!activeBrokers.contains(broker)) {
                brokerDataMap.remove(broker);
            }
        }
    }

會從 zookeeper 的節點中獲取到所有的 broker 列表（broker 會在啟動時將自身的資訊註冊到 zookeeper 中。）

然後依次讀取各自節點的負載資料，也就是在負載均衡器啟動的時候上報的資料。

篩選出所有 broker 中需要 unload 的 bundle

在 Pulsar 中 topic 是最核心的概念，而為了方便管理大量 topic，提出了一個 Bundle 的概念； Bundle 是一批 topic 的集合，管理 Bundle 自然會比 topic 更佳容易。

所以在 Pulsar 中做負載均衡最主要的就是將負載較高節點中的 bundle 轉移到低負載的 broker 中。

    private void updateAllBrokerData() {
        final Set<String> activeBrokers = getAvailableBrokers();
        final Map<String, BrokerData> brokerDataMap = loadData.getBrokerData();
        for (String broker : activeBrokers) {
            try {
                String key = String.format("%s/%s", LoadManager.LOADBALANCE_BROKERS_ROOT, broker);
                Optional<LocalBrokerData> localData = brokersData.readLock(key).get();
                if (!localData.isPresent()) {
                    brokerDataMap.remove(broker);
                    log.info("[{}] Broker load report is not present", broker);
                    continue;
                }

                if (brokerDataMap.containsKey(broker)) {
                    // Replace previous local broker data.
                    brokerDataMap.get(broker).setLocalData(localData.get());
                } else {
                    // Initialize BrokerData object for previously unseen
                    // brokers.
                    brokerDataMap.put(broker, new BrokerData(localData.get()));
                }
            } catch (Exception e) {
                log.warn("Error reading broker data from cache for broker - [{}], [{}]", broker, e.getMessage());
            }
        }
        // Remove obsolete brokers.
        for (final String broker : brokerDataMap.keySet()) {
            if (!activeBrokers.contains(broker)) {
                brokerDataMap.remove(broker);
            }
        }
    }

負載均衡器在啟動的時候就會查詢所有節點的資料，然後寫入到 brokerDataMap 中。


同時也會註冊相關的 zookeeper 事件，當註冊的節點發生變化時（一般是新增或者刪減了 broker 節點）就會更新記憶體中快取的負載資料。

之後 leader 節點會定期呼叫 org.apache.pulsar.broker.loadbalance.impl.ModularLoadManagerImpl#doLoadShedding 函式查詢哪些資料需要解除安裝，然後進行重新負載。

final Multimap<String, String> bundlesToUnload = loadSheddingStrategy.findBundlesForUnloading(loadData, conf);

最核心的就是呼叫這個 findBundlesForUnloading 函式，會返回需要解除安裝 bundle 集合，最終會遍歷這個集合呼叫 admin API 進行解除安裝和重平衡。

而這個函式會有多種實現，本質上就是根據傳入的各個節點的負載資料，然後根據自定義的規則返回一批需要解除安裝的資料。

以預設的 org.apache.pulsar.broker.loadbalance.impl.ThresholdShedder 規則為例：


它是根據頻寬、記憶體、流量等各個指標的權重算出每個節點的負載值，之後為整個叢集計算出一個平均負載值。

以上圖為例：超過 ShedBundles 的資料就需要被解除安裝掉，然後轉移到低負載的節點中。

所以最左邊節點和超出的 bundle 部分就需要被返回。

具體的計算邏輯如下：

    private void filterAndSelectBundle(LoadData loadData, Map<String, Long> recentlyUnloadedBundles, String broker,
                                       LocalBrokerData localData, double minimumThroughputToOffload) {
        MutableDouble trafficMarkedToOffload = new MutableDouble(0);
        MutableBoolean atLeastOneBundleSelected = new MutableBoolean(false);
        loadData.getBundleDataForLoadShedding().entrySet().stream()
                .map((e) -> {
                    String bundle = e.getKey();
                    BundleData bundleData = e.getValue();
                    TimeAverageMessageData shortTermData = bundleData.getShortTermData();
                    double throughput = shortTermData.getMsgThroughputIn() + shortTermData.getMsgThroughputOut();
                    return Pair.of(bundle, throughput);
                }).filter(e ->
                        !recentlyUnloadedBundles.containsKey(e.getLeft())
                ).filter(e ->
                        localData.getBundles().contains(e.getLeft())
                ).sorted((e1, e2) ->
                        Double.compare(e2.getRight(), e1.getRight())
                ).forEach(e -> {
                    if (trafficMarkedToOffload.doubleValue() < minimumThroughputToOffload
                            || atLeastOneBundleSelected.isFalse()) {
                        selectedBundlesCache.put(broker, e.getLeft());
                        trafficMarkedToOffload.add(e.getRight());
                        atLeastOneBundleSelected.setTrue();
                    }
                });
    }

從程式碼裡看的出來就是在一個備選集合中根據各種閾值和判斷條件篩選出需要解除安裝的 bundle。

而 SimpleLoadManagerImpl 的實現如下：

synchronized (currentLoadReports) {
	for (Map.Entry<ResourceUnit, LoadReport> entry : currentLoadReports.entrySet()) {
		ResourceUnit overloadedRU = entry.getKey();
		LoadReport lr = entry.getValue();
		// 所有資料做一個簡單的篩選，超過閾值的資料需要被 unload
		if (isAboveLoadLevel(lr.getSystemResourceUsage(), overloadThreshold)) {
			ResourceType bottleneckResourceType = lr.getBottleneckResourceType();
			Map<String, NamespaceBundleStats> bundleStats = lr.getSortedBundleStats(bottleneckResourceType);
			if (bundleStats == null) {
				log.warn("Null bundle stats for bundle {}", lr.getName());
				continue;

			}

就是很簡單的透過將判斷節點的負載是否超過了閾值 isAboveLoadLevel，然後做一個簡單的排序就返回了。

從這裡也看得出來 SimpleLoadManagerImpl 和 ModularLoadManager 的區別，SimpleLoadManagerImpl 更簡單，並沒有提供多個 doLoadShedding 的篩選實現。

總結

總的來說對於無狀態的服務來說，理論上我們只需要做好負載演算法即可（輪訓、一致性雜湊、低負載優先等）就可以很好的平衡各個節點之間的負載。

而對於有狀態的服務來說，負載均衡就是將負載較高節點中的資料轉移到負載低的節點中。

其中的關鍵就是需要儲存各個節點的負載資料（業界常用的是儲存到 zookeeper 中），然後再由一個 leader 節點從這些節點中根據某種負載演算法選擇出負載較高的節點以及負載較低的節點，最終把資料遷移過去即可。

相關文章