今天想轉貼有香香動畫(?)的科普文： Load Balancing - Sam Rose

這篇文章用了簡單的動畫，讓讀者能直觀地了解當下 Request 的傳送狀況（看著球被丟給伺服器，意外地蠻療癒的）

Image

從最簡單的 1 個來源發送給 1 台伺服器（=只要一直把球丟過去給伺服器就好）開始

接著，伺服器開始吃不下了。我們想要增加伺服器數量，但就需要把 Request 分配給他們兩台伺服器，這時候最簡單粗暴的做法就是輪詢（=輪流發球給他們）

然後再加入一些會在實務上遇到的狀況：每顆球（Request）要處理的工可能不一樣大，伺服器也不一定都一樣強。

這樣一來，單純平均發球的輪詢作戰很快就會遇到胃口比較小的伺服器開始吃不下的尷尬狀況

為了減輕這個狀況，我們可以在每個伺服器前面加個小小的排隊區（Request Queues），雖然要排隊勢必會拉長時間，但至少掉球的狀況就減少了

再進一步的話，我們可以針對伺服器的消化能力來替他們加個權重，不過手動標權重很容易翻車，所以要想辦法讓他自動調整權重，也就是要能「動態加權輪詢」

例如根據最近三次的執行時間來計算伺服器的胃口(?)，再決定要發幾顆球給伺服器，比較餓吃比較快的就多發一點(??)

除了吃不下把球吐掉以外，如果吃太久吃到 Timeout 也是不行的。而針對延遲問題，這篇最後介紹了「峰值指數加權移動平均（PEWMA）」

做法其實也很直覺：抓一下最近這些伺服器的延遲如何、都處理了多久，然後再經過一些數學魔法(?) 來算出下一個 Request 給哪台伺服器比較好、看能不能讓延遲更少

ps. 附上數學魔法的段落給那些看得懂的朋友：

For each server, the algorithm keeps track of the latency from the last N requests. Instead of using this to calculate an average, it sums the values but with an exponentially decreasing scale factor. This results in a value where the older a latency is, the less it contributes to the sum. Recent requests influence the calculation more than old ones.
對於每個伺服器，該演算法會追蹤從最後 N 個請求開始的延遲時間。不同於使用此來計算平均值，它將這些值相加，但使用指數遞減的比例因子。這導致一個值，其中較舊的延遲對總和的貢獻較小。最近的請求比舊的請求更影響計算。

That value is then taken and multiplied by the number of open connections to the server and the result is the value we use to choose which server to send the next request to. Lower is better.
然後，將該值乘以與伺服器的開放連接數，結果就是我們用來選擇下一個請求要發送到哪個伺服器的值。數值越低越好。

但是相較前面著重在不要把球吐掉的「動態加權輪詢」，這套注重延遲問題的「峰值指數加權移動平均」就比較有可能發生更嚴重的吃不下問題

作者有進行一些測試並繪製圖表，有興趣的朋友可以參考看看。感覺還是要根據狀況、評估對延遲或掉包的容忍程度，再決定採用怎樣的負載平衡策略會比較好

那麼，今天的轉貼就到這邊，我們明天（大概）見～