負載均衡演算法

引言：「單點故障」問題

想像一家餐廳有 100 個客人，但只有 1 名服務員。服務員會被累死，而客人會等得發瘋。如果你雇了 5 名服務員，你就需要一種方法來決定哪位服務員服務哪張桌子。

負載均衡 (Load Balancing) 是將進入的網路流量分發到一組後端伺服器（伺服器池）的過程。她確保沒有一台伺服器承受過大的壓力，從而提高響應速度和可用性。

演算法要解決什麼問題？

• 輸入： 湧入的請求流。
• 輸出： 處理該請求的最佳後端伺服器。
• 承諾： 可擴展性（透過增加伺服器來處理更多流量）和可靠性（如果一台伺服器掛了，其他伺服器能接管流量）。

常見演算法

1. 輪詢 (Round Robin)

• 邏輯： 簡單地按順序分配：伺服器 1，然後是 2，然後是 3，再回到 1。
• 適用場景： 所有伺服器硬體配置相同，且每個請求的處理成本大致相等。

2. 加權輪詢 (Weighted Round Robin)

• 邏輯： 根據伺服器的處理能力分配「權重」。權重為 10 的伺服器收到的請求是權重為 5 的伺服器的兩倍。
• 適用場景： 伺服器集群配置不均（例如，有些機器是 64GB 記憶體，有些只有 16GB）。

3. 最小連接數 (Least Connections)

• 邏輯： 將下一個請求發送到當前活躍連接數最少的伺服器。
• 適用場景： 處理耗時差異很大的請求（如影片流或持久的 WebSocket 連接）。

4. IP 雜湊 (IP Hash)

• 邏輯： 根據用戶端的 IP 地址決定去哪台伺服器（例如 hash(用戶端IP) % N）。
• 適用場景： 「粘性會話 (Sticky Sessions)」。確保同一個使用者始終訪問同一台伺服器，以利用本地快取或 Session 數據。

典型業務場景

• ✅ Web 伺服器： Nginx 或 HAProxy 將 HTTP 請求分發到 Node.js/Python 後端。

• ✅ 資料庫讀副本： 將 「SELECT」 查詢分散到 5 個唯讀資料庫節點上。

• ✅ API 閘道： 根據路由路徑將流量引導到不同的微服務。

• ❌ 有狀態應用： 如果你使用輪詢，就不能在伺服器記憶體裡存使用者 Session。你必須使用共享的 Redis 儲存，或者使用 IP 雜湊。

性能與複雜度總結

• 效率： 極高。大多數演算法的複雜度為 $O(1)$ 或 $O(\log N)$。
• 開銷： 與水平擴展帶來的收益相比，演算法本身的開銷幾乎可以忽略不計。

小結：一句話記住它

「負載均衡是網際網路的『交通警察』。她確保你的系統可以透過增加『人手』來擴容，並讓你在單台伺服器宕機時依然屹立不倒。」