Talos網路卡負載最佳化：基於個性化一致性雜湊的負載均衡

本文將詳細介紹基於個性化一致性哈希的流量均衡方法。

  目錄   

1. 業務增長帶來的流量均衡需求

2. 基於一致性雜湊的排程策略

3. 個性化一致性雜湊的負載均衡

4. 流量均衡在Talos中的實現

前文《小米訊息佇列的實踐》介紹了小米自研訊息佇列Talos的業務背景和關鍵問題。

其中在網路卡資源最佳化方面，Talos主要做了兩方面工作：客戶端定址與基於流量的個性化一致性雜湊。前者是透過客戶端自定址避免Server轉發節省網路卡資源，後者是透過最佳化一致性雜湊的虛擬節點數配置，調整節點的流量分配情況。

本文將詳細介紹後者——基於個性化一致性雜湊的流量均衡方法。

  業務增長帶來的流量均衡需求     

Talos作為高吞吐型的訊息佇列服務，隨著業務增長，頻寬往往會成為瓶頸。如果網路卡流量不均衡，就會產生叢集網路卡資源的木桶效應—— 當叢集中使用網路卡最多的機器達到資源瓶頸就要觸發擴容，即便此時該叢集其他節點網路卡有大量富餘，機器成本因此浪費。且隨著業務量越來越多，叢集規模不斷變大，問題變得更加明顯。

以小米某線上叢集為例，該叢集150臺機器，將各節點的日流量均值繪製成散點圖以方便觀察其流量均衡程度。其中最高流量324M，最低134M，相差兩倍不止。

分析此問題，機器節點網路卡流量的大小，和該節點所serve的所有Partition流量之和呈正相關。要解決節點間網路卡負載不均衡的問題，需要調整Partition在各節點的分佈情況(即改變Partition的排程關係)。下面我們將簡單介紹下最佳化前Talos所使用的排程機制，再來分析如何做到這一點。

  基於一致性雜湊的排程策略     

Talos使用一致性雜湊來約定Partition排程關係。簡單來講，一致性雜湊可以理解為一個函式，Y = ConsistentHash (X)。任意的X取值都能對映為一個固定區間內的唯一數值Y.

舉例說明，我們將10節點叢集中各節點做對映，用下面的環狀圖表示。那麼區間被分成了10份。同樣將Partition對映也對映到環上，根據其位置區間，來決定由哪個節點所serve. 叢集所有節點都遵從這個約定從而排程資訊一致。

實際上，為了使圓環劃分的更加均勻和節點上下線更加穩定，每個機器節點將對應多個虛擬節點以力求平均。傳統的一致性雜湊，每個節點對映的虛擬節點個數是一致的。例如，Talos每個機器節點對應的虛擬節點個數都是2000個。

可以理解，使用一致性雜湊的排程方式，力求的是Partition個數分佈的儘量均衡，各Partition在排程中的權重是一樣的，並不關心Partition其他指標(例如QPS和流量)的差異，且一致性雜湊演算法的對映關係我們無法干預和調節。

  個性化一致性雜湊的流量均衡     

想要解決這個問題，我們需要引入流量資訊參與Partition排程決策。透過在排程策略中引入流量反饋機制，調節一致性雜湊虛擬節點個數，達到流量均衡。

具體思路是，獲得監控資料，對比節點的流量值與叢集各節點流量均值。如果該節點流量值較大，則透過減少該節點的虛擬節點個數減少所serve的Partition個數；如果該節點流量值較小，則透過增多該節點的虛擬節點個數增多所serve的Partition個數，不斷反饋。可以用下圖表示。

透過監控反饋和虛擬節點不斷的調整，該方式最終可以找到符合各節點流量均衡分佈的一致性雜湊虛擬節點分佈，下圖簡單解釋下最佳化排程效果。

最佳化前的排程：Partition個數大致均勻

最佳化後的排程：節點流量均勻

相比於引入一箇中心節點來實現統一的定製的排程機制，這種方式對Talos原有架構來說改動較小，且不會引入複雜的中心節點可用性問題。

  流量均衡在Talos中的實現     

依據上述思想落地到Talos業務，需要考慮穩定性問題，分析影響穩定性的因素：

• 對Talos來說，Partition在節點間的遷移大約在7s左右可恢復服務。由於流量均衡過程中會產生Partition的遷移，如果短時間內大規模的Partition遷移，由於資源的集中呼叫，不僅會造成恢復時間增長，大規模的遷移還可能帶來叢集可用性抖動。

• 類似HDFS Balance，我們可以設定流量均衡的目標值，例如，設定目標值為10%，則目標是調整叢集最大日均流量與最小日均流量在叢集日均流量的10%範圍內。有些情況下某些目標值我們是無法達到的，這時的調整最終就會變成來回震盪的狀況。舉個最簡單的例子，A機器100M流量，B機器50M流量，單個Partition的流量值是50M，按照10%的目標去調整，結果就是會在A 50M and B 100M和A 100M and B 50M的情況之間來回震盪。不僅達不到目標，還白白帶來遷移開銷。

• 還有一些情況，會出現“往壞的方向調節”。依然以一個簡單例子說明，A機器100M流量，B機器80M流量，調整目標10%，單個Partition的流量值是50M，一次調節後變成A 50M而B 130M，均衡度更差。2和3問題的出現，本質上都是由於我們調節的最小粒度是Partition。

為了避免這些問題，設定了以下機制：

• 透過監控資料模擬計算，模擬符合預期才觸發調整。取得各Partition的流量監控資料，帶入一致性雜湊函式，模擬調整虛擬節點個數並計算各節點流量值；
• 控制每次遷移的Partition個數，保證叢集整體穩定性；
• 計算方差決定是否調整，以防止無謂的震盪調整或往更壞的方向調整。方差能反應離散程度，只有當模擬調整後的方差變小才觸發調整；
• 設定最大調節次數，以設定調整目標無法達到時的無限模擬計算。

最終的實現架構如下：

其中BalanceServer會負責完成根據閾值和監控值模擬計算，控制遷移量，按規定時間間隔觸發等邏輯。叢集的可用性不依賴BalanceServer，BalanceServer掛掉只是停止了叢集的流量均衡調整，叢集會繼續按照當前的虛擬節點分佈進行排程執行，即便出現了叢集節點上下線也沒關係。

接下來展示下叢集均衡的效果，依然以文章開頭展示流量圖的Talos叢集為例，將調整後各節點的日流量均值製作成散點圖，可以發現最佳化後各節點流量值明顯聚合。經計算，此叢集150臺機器，可節省因網路卡達到瓶頸而需要擴容的機器35臺。

值得借鑑的是，透過改變BalanceServer引入的監控引數，此方法可以擴充套件到基於一致性雜湊的分散式系統的QPS均衡、甚至CPU資源和記憶體資源均衡，只要找到本系統監控指標和均衡指標間的函式關係即可。

後續Talos關鍵問題系列文章將持續更新，歡迎繼續關注。