到達POP的請求根據請求URI對不同的伺服器進行負載平衡。
當請求到達POP時，前端伺服器會處理請求，並根據請求的URI將請求映射到暫存伺服器。 一致的散列(或者，精確地說，使用CARP高速暫存陣列路由協議實現的Rendezvous散列)保證只要同一伺服器正常，相同的資源就會始終映射到同一高速暫存伺服器。 這種一致的映射對性能至關重要。 將請求定向到暫存中沒有所請求資源的伺服器將需要從另一臺伺服器獲取資源，從而增加響應延遲。 重要的是，一致的散列還可在Pop中的所有高速暫存伺服器之間實現相當一致的資源分配，從而有助於分配工作負載。
但是，不同的資源在受歡迎程度上有所不同，爲常用資源提供服務的伺服器最終可能會提供比流行資源中其他資源更多的流量。 因此，一個稱爲熱歸檔的機制會在資源迅速變得非常受歡迎時啓動，並開始使用伺服器網路或CPU資源的相當一部分。 熱歸檔可在一個或多個附加伺服器上快速複製此資源。 它會通知前端複本所在的伺服器，從而導致資源生成的負載的更廣泛分佈。
有待改進的地方
今天觸發熱歸檔的邏輯基於固定閾值，該閾值保證沒有一個資源負責伺服器所服務的請求或位元組的預定速率。 如果資源負載超過該閾值，它將進一步分佈。 但是，具有固定閾值的一個挑戰是，如果伺服器上相當一部分伺服器負載是由剛剛低於該閾值的資源生成的，那麼這些資源將不會被熱歸檔。 因此，它們各自的請求負載將不會被分配。
因此，我們觀察到，即使結合了基於資源的負載平衡和熱歸檔，伺服器之間的負載分佈也往往不均衡，某些伺服器的負載分配通常是中位數的2-3倍以上。
在任何給定時間，許多POPS中的網路負載分佈不均是常見的，某些伺服器提供的流量比中位數高出2倍。
這種不均衡並不總是一個問題，因爲只要伺服器沒有達到容量，它們就可以保持性能。 然而，在極端情況下，影響可能非常明顯。 下圖說明了這種效果的一個真實示例。
兩臺伺服器達到或超過其網路容量，而其餘的POP伺服器則提供較低的流量。 異常伺服器在執行狀況檢查(響應時間)時明顯出現膨脹。
在這張特定流行網路負載分佈快照中，雖然大多數伺服器發送的流量較低，但兩臺伺服器提供的負載超過中位數的兩倍，由於一個或幾個非常受歡迎的資源而達到其容量。 這對其執行狀況檢查指標(其最短響應時間的代理)有明顯的影響。 此度量的正常值通常低於1毫秒，且超過10毫秒時會發出警報。 在本例中，執行狀況檢查增加到100毫秒以上的值，並持續至少一小時，在此期間，過載的伺服器可能表現不佳。
我們還觀察到一些伺服器在幾天內的負載持續高於彈出窗口的其他伺服器。 在此期間，這些載入的伺服器通常比POP中的其他伺服器更難抵禦傳入流量峯值。 這在高峯期會加劇,因爲它們的負載可能達到或超過它們的容量,儘管其餘的Pop中有可用的容量。
自適應請求負載平衡系統
基於這些觀察,我們一直在研究熱歸檔動態閾值的想法。 這種方法考慮 在任何給定時間以及每臺伺服器位於該分佈中的位置跨伺服器的負載分佈 。 根據這些條件，伺服器特定的閾值計算爲伺服器在負載分配中的位置的函數： 負載高於中間值的伺服器被分配的閾值比負載較低的伺服器低，這有利於分佈末尾的伺服器更多地卸載。
伺服器閾值是根據每臺伺服器的當前負載分佈位置生成的。 負載高於中位數的伺服器被分配的閾值低於負載較低的伺服器。
更具體地說,我們定義了兩個控制熱歸檔水平的參數:
- BaseThresh 控制每個伺服器閾值的基線值。 特定於伺服器的閾值源自此值，並根據伺服器的當前負載進行調整。
- α ∈(0，2)控制算法爲需要卸載的伺服器調整權重的力度。
然後，對於POP中的每臺伺服器，我們使用以下公式生成權重W∈(0,2)，該權重 與伺服器當前負載成反比：
其中：α∈(0,1) BW(s) 是當前伺服器負載 BWmin是最低負載伺服器負載BWmin 是最高負載伺服器負載，然後，每個伺服器的閾值 T 計算如下：
在實施過程中，我們將BaseThresh配置爲適合工作負載的值。 我們讓算法動態地選擇 α 的值，這樣，如果離羣值(負載更多)的伺服器離負載中位數很遠，則會在這些伺服器上強制實施更積極的卸載。
使用CDN生產工作負載進行評估
我們使用生產工作負載快照來評估類比方法。 爲了測量在伺服器之間的負載分配過程中出現的(變化)偏差，我們定義了”偏差係數”：
換句話說，S測量負載最大的伺服器距離中位數有多遠。 例如，S=2表示負載最大的伺服器提供的負載是中值的2倍。 理想情況下，我們希望所有伺服器都接近中間值，因此S的較低值會更好(在理論上，S=1爲最佳值)。 下圖顯示了S如何根據動態閾值，每次迭代中生成的新熱文件數量以及每次迭代中選擇的 α 值在熱歸檔過程的多個迭代中進行更改。
在算法多次反覆迭代後載入分佈。 負載最大的伺服器上的負載從中值的2.73倍降低到中值的1.42倍，並且POP內部的流量分佈更加均勻。
藍線(“開始”)顯示起始狀態，表示彈出時負載分佈的真實快照。 我們注意到，S在每次迭代後都會減少，直到達到不再生成熱文件(HF)的點。 隨着每次迭代中的尾部被修剪，分佈變得更加均勻，更多的伺服器接近中間負載。
接下來，我們對6個不同的POPS重複相同的實驗10次：
6個POPS的偏斜係數(S)變化。 S在5次迭代中收斂，平均下降92%。
圖中的每一組條形表示不同的彈出窗口，而組中的每個條形表示後續迭代。 每個組中的第一個欄代表從生產工作負載快照中繪製的起始狀態。 每個列代表10次掃描的值。 我們觀察到,在所有情況下,S在第一次迭代中的下降比在隨後的任何迭代中S達到更多可接受值的迭代中顯著。 重要的是,分佈(以威士忌爲例)以及離羣值(鑽石)的傳播也同樣減少。 我們觀察到，負載平衡機制在少數迭代後收斂，只有在S因新的不平衡流量而變得高時才需要觸發。
後續步驟
將負載分佈到伺服器之間對於性能非常重要。 儘管由於快速流行的資源，預計會出現某種程度的不均勻，但伺服器持續過載，儘管其餘部分的可用容量仍會影響其性能和抵禦更多傳入流量峯值的恢復能力。 在這項工作中，我們探討了對現有負載平衡機制的增強，這有助於緩解這種負載不均衡現象。
仿真結果很有希望，因此我們正在將這一變化轉化爲現有機制，並在生產中監控結果。 測試這種生產方法將使我們獲得更真實的結果,並評估更難在類比中量化的其他因素。 這些因素包括對高度動態工作負載的恢復能力，時間影響，資源複製更改以及相關開銷。
