支援的負載平衡器

當篩選器需要取得上游叢集中主機的連線時，叢集管理員會使用負載平衡策略來決定選擇哪個主機。負載平衡策略是可插拔的，並在每個上游叢集的設定中指定。請注意，如果沒有為叢集設定任何作用中的健康檢查策略，則除非透過health_status另行指定，否則所有上游叢集成員都會被視為健康。

加權循環配置

這是一個簡單的策略，其中每個可用的上游主機都按循環順序選取。如果權重被指派給區域中的端點，則會使用加權循環配置排程，其中權重較高的端點會在輪換中更頻繁地出現，以實現有效的加權。

加權最少請求

最少請求負載平衡器會根據主機是否具有相同或不同的權重而使用不同的演算法。

所有權重相等：一個 O(1) 演算法，它會選取設定中指定 (預設為 2) 的 N 個隨機可用主機，並選取具有最少活躍請求的主機 (Mitzenmacher et al. 已證明這種方法幾乎與 O(N) 完全掃描一樣好)。這也稱為 P2C (二選一的力量)。P2C 負載平衡器具有以下特性：主機權重會隨著這些主機上活躍請求數量的增加而減少。由於 P2C 選擇對群體行為具有抵抗力，因此特別適用於負載平衡器實作。
所有權重不相等：如果叢集中有兩個或更多主機具有不同的負載平衡權重，則負載平衡器會轉換為使用加權循環配置排程的模式，其中權重會根據主機在選取時的請求負載動態調整。

在這種情況下，權重是在選取主機時使用以下公式計算的

權重 = load_balancing_weight / (active_requests + 1)^active_request_bias.

active_request_bias 可以透過執行階段設定，預設為 1.0。它必須大於或等於 0.0。

活躍請求偏差越大，活躍請求降低有效權重的程度就越積極。

如果 active_request_bias 設定為 0.0，則最少請求負載平衡器的行為會像循環配置負載平衡器，並在選取時忽略活躍請求計數。

例如，如果 active_request_bias 為 1.0，則權重為 2 且活躍請求計數為 4 的主機的有效權重將為 2 / (4 + 1)^1 = 0.4。此演算法在穩定狀態下提供良好的平衡，但可能無法快速適應負載不平衡。此外，與 P2C 不同，主機永遠不會真正耗盡，但隨著時間的推移，它會收到較少的請求。

環狀雜湊

環狀/模數雜湊負載平衡器會對上游主機實作一致性雜湊。每個主機都會透過雜湊其位址來對應到一個圓圈 (「環」)；然後，每個請求都會透過雜湊請求的某些屬性，並找到環中順時針方向最接近的對應主機來路由到主機。這種技術也通常稱為「Ketama」雜湊，並且像所有基於雜湊的負載平衡器一樣，它僅在指定要雜湊的值時，才使用通訊協定路由有效。如果您希望使用主機位址以外的內容作為雜湊索引鍵 (例如 Kubernetes StatefulSet 中主機的語義名稱)，則可以在 "envoy.lb" LbEndpoint.Metadata 中指定，例如

  filter_metadata:
    envoy.lb:
      hash_key: "YOUR HASH KEY"

這將覆寫 use_hostname_for_hashing。

每個主機會被雜湊並放置在環上，其次數與其權重成正比。例如，如果主機 A 的權重為 1，而主機 B 的權重為 2，則環上可能有三個項目：主機 A 一個項目，主機 B 兩個項目。但是，這實際上並未提供所需的 2:1 圓形分割，因為計算出的雜湊可能會非常接近；因此，有必要將每個主機的雜湊次數乘以，例如在環上插入 100 個主機 A 的項目和 200 個主機 B 的項目，以更好地近似所需的分布。最佳做法是明確設定minimum_ring_size 和 maximum_ring_size，並監控min_hashes_per_host 和 max_hashes_per_host 量表，以確保良好的分布。如果環分割適當，則從 N 個主機集中新增或移除一個主機只會影響 1/N 個請求。

當使用基於優先順序的負載平衡時，優先順序級別也會由雜湊選取，因此當後端集合穩定時，選取的端點仍將保持一致。

Maglev

Maglev 負載平衡器會對上游主機實作一致性雜湊。它使用這篇論文第 3.4 節中描述的演算法，固定表大小為 65537 (請參閱同一論文的第 5.3 節)。在任何需要一致性雜湊的地方，Maglev 都可以作為環狀雜湊負載平衡器的替代品。與環狀雜湊負載平衡器一樣，一致性雜湊負載平衡器僅在指定要雜湊的值時，才使用通訊協定路由有效。如果您希望使用主機位址以外的內容作為雜湊索引鍵 (例如 Kubernetes StatefulSet 中主機的語義名稱)，則可以在 "envoy.lb" LbEndpoint.Metadata 中指定，例如

  filter_metadata:
    envoy.lb:
      hash_key: "YOUR HASH KEY"

這將覆寫 use_hostname_for_hashing。

表建構演算法會將每個主機按其權重成比例的次數放置在表中，直到表完全填滿。例如，如果主機 A 的權重為 1，而主機 B 的權重為 2，則主機 A 將有 21,846 個項目，而主機 B 將有 43,691 個項目 (總計 65,537 個項目)。該演算法會嘗試至少將每個主機放置在表中一次，無論設定的主機和區域權重如何，因此在某些極端情況下，實際比例可能與設定的權重不同。例如，如果主機總數大於固定表大小，則某些主機將各自獲得 1 個項目，而其餘主機將獲得 0 個項目，無論權重如何。最佳做法是監控min_entries_per_host 和 max_entries_per_host 量表，以確保沒有主機被低估或遺失。

一般而言，與環狀雜湊 (「ketama」) 演算法相比，Maglev 的表查找建構時間和主機選取時間都明顯更快 (當使用 256K 項目的大環狀大小時，分別大約快 10 倍和 5 倍)。雖然 Maglev 的目標是最大限度地減少干擾，但在上游主機變更時，它的穩定性不如環狀雜湊。當主機被移除時，會有更多索引鍵移動位置 (模擬顯示大約有兩倍的索引鍵會移動)。可以透過增加table_size來最大限度地減少干擾量。話雖如此，對於包括 Redis 在內的許多應用程式，Maglev 很可能是一個優於環狀雜湊的替代品。進階讀者可以使用此基準來比較具有不同參數的環狀雜湊與 Maglev。

隨機

隨機負載平衡器會選取隨機可用的主機。如果未設定健康檢查策略，隨機負載平衡器通常會比循環配置執行得更好。隨機選取避免對集合中失敗主機之後的主機產生偏差。