負載平衡演算法
💻 負載平衡演算法的進化邏輯筆記
這些演算法的進化，體現了從「簡單分配」到「感知伺服器即時負載」的過程。
🔄 階段一：簡單輪流分配 (Round Robin / Random)
核心假設： 假設所有伺服器和所有請求都是相等的。
| 演算法 | 運作方式 | 限制 / 盲點 | 解決方案的轉變方向 |
|---|---|---|---|
| Round Robin (RR) | 請求依序分配 (1 ➡️ A, 2 ➡️ B, 3 ➡️ C...) | 忽略伺服器實際的 性能差異 和 當前負載。慢速伺服器會成為瓶頸。 | 需要感知伺服器的「忙碌程度」。 |
| Random | 請求隨機分配 | 同樣忽略伺服器負載，分配結果不可控。 |
- Round Robin (RR): 雖然它平均分配請求數量，但它無法知道請求的複雜度。如果伺服器 A 拿到 10 個簡單請求，伺服器 B 拿到 10 個複雜的資料庫查詢，B 會先被耗盡資源而變得緩慢或崩潰。
- Random: 雖然機率上是平均的，但在短時間內或流量較低時，統計上有可能連續將較多請求分給同一台伺服器，產生一個「熱點 (Hotspot)」。
🧠 階段二：感知連線數 (Least Connections)
核心進化： 開始感知伺服器的狀態，將請求導向連線數最少的伺服器。
| 演算法 | 運作方式 | 限制 / 盲點 | 解決方案的轉變方向 |
|---|---|---|---|
| Least Connections | 導向活動連線數量最少的伺服器。 | 只計數連線的「數量」，不看連線的「品質或重量」。一個連線可能只是閒置，而另一個連線可能正在執行高 CPU 負載任務。 | 需要感知伺服器的「處理速度」。 |
但是 Least Connections 它只計算連線的數量 (Quantity)，卻無法衡量連線的複雜度或重量 (Quality)。
⚡ 階段三：感知性能 (Least Response Time)
核心進化： 直接衡量伺服器處理工作的即時速度，這是最真實的負載指標。
| 演算法 | 運作方式 | 優勢 / 目的 | 說明 |
|---|---|---|---|
| Least Response Time | 導向回應時間最短的伺服器。 | 將請求導向能最快完成工作的伺服器，優化使用者體驗。 | 即時測量伺服器的延遲。如果伺服器 CPU 滿載，回應時間就會變長，自動避免新請求。 |
🩺 Load Balancer 的主動監控機制
Least Response Time (LRT) 的核心仰賴於 Load Balancer 持續不斷地 主動發送微小的、合成的請求給所有後端伺服器。
- 發送探針 (Probe): Load Balancer 會週期性地（例如，每 5 秒一次）向每台伺服器的特定端口或 URL (例如
/health或/status) 發送一個小型請求。 - 測量時間 (Timing): Load Balancer 精確記錄 從發出請求到收到伺服器回應（例如 HTTP 200 OK）所需的總時間。
- 計算平均 (Averaging): Load Balancer 會將這些探測時間加權平均，作為該伺服器當前的 即時回應時間 (Live Response Time) 指標。
- 分配流量 (Dispatching): 當一個真實的使用者請求進來時，Load Balancer 會將其導向平均回應時間最短的伺服器。
這個健康檢查機制不僅用於 LRT 來判斷「誰最快」，它同時也是判斷伺服器是否「活著」的關鍵。如果伺服器完全當機，它就無法回應探針。
但是不管怎麼分配，都有可能有一個機器被分到較多的請求，進而造成這台機器無法負荷，當一個機器被拿掉的時候，其他的機器會被分到更多的請求，可能會有骨牌效應（級聯故障 Cascading Failure）讓系統開始崩潰。
當我們知道 Load Balancer 要怎麼處理請求的時候，接下來是要準備怎麼處理故障的機器。
🧩 橫向解決方案：IP Hash (會話持久性)
| 演算法 | 主要目的 | 運作方式 | 應用場景 |
|---|---|---|---|
| IP Hash | 確保會話持久性 (Session Persistence)。 | 根據使用者的 IP 位址 計算 Hash 值，將同一 IP 的所有請求導向同一台伺服器。 | 購物車、登入狀態、需要維持使用者狀態的應用程式。 |