Enter your search text in the box above

Select a result to preview

負載平衡器 (Load Balancer)

#infrastructure #load-balancer #system-design
一句話定位

Load Balancer 在多個伺服器/服務實例之間分配流量。對客戶端而言只看到一個入口，實際流量被分散到多台後端。
本質不是「平均」，而是讓整體吞吐量最大化，同時避免局部過載。

這篇 vs 網路層視角

01-Networking/06-Load-Balancing 從網路層講客戶端 LB、L4/L7、CDN、區域分片。這篇從基礎設施元件角度補強：流量分配的細節、健康檢查、高可用、SSL 終止、Session 持久化、演算法盲點與產品選型。兩篇互補，不重複。

核心功能

1. 流量分配（Traffic Distribution）

小規模可能只是單純 Round Robin。但流量變大、請求變複雜時，分流策略就是穩定性關鍵：

分配策略太天真 → 表面平均、實際不平均。成熟 LB 會結合即時負載資訊（連線數、延遲、錯誤率）動態調整。

2. 健康檢查（Health Check）— 自動容錯的核心

定期對後端發送探測（HTTP /health、TCP port、或自訂應用層檢測）。連續多次失敗 → 該節點暫時移出流量池；恢復後重新加入。

設計取捨 影響
檢查頻率太低 故障切換慢
檢查頻率太高 造成額外負擔
檢查邏輯太簡單 誤判（服務活著但依賴的 DB 已掛）

健康檢查讓「壞節點」在無人介入下被自動隔離。

3. 高可用性（High Availability）

LB 本身是關鍵基礎設施 —— 它掛了整個系統就 SPOF。實務做法：

高可用的本質不是「有備份」，而是故障時流量能否在可接受時間內自動轉移。

4. SSL 終止（SSL Termination）

在 LB 層完成 TLS 握手與解密，後端只處理純 HTTP。

高流量系統幾乎是標配。

5. Session 持久化（Sticky Session）

使用者狀態存在應用伺服器記憶體（購物車、臨時 session）時，LB 用 cookie 或 IP hash 讓同一用戶固定打同一台。

風險 說明
流量分佈不均 黏在熱門節點上
節點掛掉 → session 消失 狀態存記憶體就一起沒了
Sticky Session 是過渡方案

可擴展架構的理想做法是把 session 外移到 Redis / DB，讓應用層保持 stateless，減少對 Sticky Session 的依賴。

6. 多區域分流（Global Load Balancing）

跨資料中心 / 地理區域部署時，依使用者地理位置、DNS latency、即時回應時間、區域健康狀況分流。常見做法：DNS-based routing 或 Anycast IP。目標：① 降低用戶延遲 ② 區域故障時自動切換（與災難復原策略緊密相關）。

常見演算法

演算法 規則 適用 / 盲點
Round Robin 依序輪流，不看負載 預設；請求成本相近時有效。長短差異大 → 實際不均
Least Connections 送給活躍連線數最少的 長連線（WebSocket、DB proxy）佳；連線少 ≠ CPU 低
IP Hash 對客戶端 IP 雜湊固定後端 實現黏性會話；NAT 出口集中 → 不均；節點變動大搬遷
Weighted Round Robin 依伺服器性能給權重 混合規格部署有用；靜態權重無法反映即時壓力
多 LB 無共享狀態怎麼路由？

Round Robin 與 IP Hash 都不需共享狀態就能各自決策 —— 這也是它們在多 LB 部署裡常見的原因（對比 Least Connections 需要即時負載資訊）。

常見產品

類型 產品
硬體型 F5、Citrix NetScaler
軟體型 NGINX、HAProxy、Envoy
雲端服務 AWS ELB（ALB L7 / NLB L4）、GCP / Azure LB

面試怎麼談 Load Balancer

不要在每個服務前面都畫一個 LB

會顯得多餘、讓設計圖混亂。較好的做法：

  1. 乾脆省略，只說「這些服務是水平擴展的」
  2. 只在系統入口畫一個 LB 作為抽象層，表示流量會分散到多台實例

L4 還是 L7？速答法則

類型 層級 路由依據 場景
L4 傳輸層 TCP/UDP IP / Port WebSocket / 長連線（不頻繁斷重建）
L7 應用層 HTTP URL / Header / Method 一般 Web 流量（更靈活路由、減少下游連線負擔） 
有 WebSocket / 持久連線 → L4 LB
一般 HTTP 流量          → L7 LB（路由更靈活）

特定情境需要的功能：Sticky Sessions（購物車）、Persistent Connections（WebSocket，連線固定在同一後端）。

自我測驗重點

問題 重點
流量分配本質 最大化吞吐 + 避免局部過載（非單純平均）
健康檢查取捨 頻率高低、邏輯太簡單會誤判
LB 高可用 ≥2 台 + failover + VIP / Anycast
Sticky Session 定位 過渡方案，理想是 session 外移 Redis
Least Connections 盲點 連線少 ≠ CPU 低
L4 vs L7 WebSocket/長連線→L4；一般 HTTP→L7