Nginx Upstream 模組四大負載均衡調度方式深度解析

前言

Nginx 作為高效能的 Web 伺服器與反向代理，其核心模組 ngx_http_upstream_module 提供了強大的負載均衡能力。透過 upstream 指令區塊定義後端伺服器群組，Nginx 能依據不同演算法將客戶端請求分發至上游伺服器。本文系統整理官方支援的四種調度策略，並補充實務常用的伺服器狀態參數與多組負載均衡配置技巧。

一、輪詢 —— 預設的基礎調度

輪詢是 Upstream 預設的調度方式，無需額外配置即可生效。其運作邏極為直觀：依請求到達的時間順序，循序將每個請求分配給不同的後端伺服器。若某台伺服器異常下線，Nginx 會自動將其從輪詢清單中剔除，確保服務可用性。

適用場景： 後端伺服器硬體規格、效能相近，且無 Session 持久化需求的靜態資源或無狀態服務。

二、加權輪詢 —— 依效能比例分配流量

透過 weight 參數賦予每台伺服器不同權重，權重值與分得請求的機率成正比。此機制完美解決異構叢集中效能差異導致的資源浪費或過載問題。

upstream backend {
    server 192.168.0.14 weight=10;
    server 192.168.0.15 weight=10;
}

上例中兩台伺服器權重相同，實際分流比例為 1:1。若調整為 weight=3 與 weight=1，前者將承擔 75% 流量。

適用場景： 叢集包含新舊機型混合部署，或需依 CPU/記憶體配比精細分配負載時。

三、IP Hash —— 解決 Session 一致性

ip_hash 指令啟用基於客戶端 IP 的雜湊演算法，確保同一 IP 的請求恆定導向同一台後端伺服器。此特性可原生解決分散式 Session 共享難題，無須引入 Redis 等外部儲存。

upstream backend {
    ip_hash;
    server 192.168.0.14:88;
    server 192.168.0.15:80;
}

注意事項： 若後端伺服器需下線維護，務必標記 down 而非直接移除，否則雜湊環變更會導致大量用戶 Session 失效。

適用場景： 傳統單體應用遷移至叢集、未實現 Session 共享的舊系統、需維持長連線的 WebSocket 服務。

四、Fair（第三方模組） —— 依回應時間動態調度

Fair 為第三方模組 nginx-upstream-fair 提供，核心邏輯為「誰回應快，分給誰」。它持續監測各上游伺服器的回應延遲，優先將新請求派發至當前延遲最低的節點，實現真正的負載均衡而非單純的請求均衡。

upstream backend {
    server server1;
    server server2;
    fair;
}

適用場景： 後端處理時間差異極大的動態應用（如報表生成、圖片處理），或混合部署快慢機型的環境。

五、URL Hash（第三方模組） —— 針對快取優化

同屬第三方模組，hash 指令依請求 URI 的雜湊值固定路由，使相同 URL 恆定命中同一台後端伺服器。此特性極大提升後端快取（如 Squid、Varnish）的命中率，減少重複運算與資料傳輸。

upstream backend {
    server squid1:3128;
    server squid2:3128;
    hash $request_uri;
    hash_method crc32;
}

關鍵限制： 啟用 hash 後，server 指令不可再使用 weight、max_fails 等參數。

適用場景： 靜態資源快取層、CDN 邊緣節點、大量重複請求的 API 閘道。

六、實務進階：伺服器狀態參數與多組負載均衡

在 upstream 區塊中，每台 server 可疊加以下狀態參數：

• down：暫時移出輪詢，適合維護窗口期
• weight：權重值，預設 1
• max_fails：允許失敗次數，預設 1；超過則標記為不可用
• fail_timeout：經 max_fails 失敗後的熔斷冷卻時間
• backup：備援節點，僅在所有非備援節點不可用時啟用

upstream backend {
    ip_hash;
    server 127.0.0.1:9090 down;
    server 127.0.0.1:8080 weight=2;
    server 127.0.0.1:6060;
    server 127.0.0.1:7070 backup;
}

在 server 區塊中透過 proxy_pass https://backend/; 即可引用上游群組。Nginx 支援定義多組 upstream，分別服務不同 server 或 location，實現業務級流量隔離。

七、輔助除錯指令

• client_body_in_file_only on：將 POST 請求體寫入檔案，便於離線分析
• client_body_temp_path：指定暫存檔目錄，支援最多三層子目錄分散 I/O 壓力

搭配 location 的正則匹配與 rewrite，可實現精細的 URL 級路由、重導向與代理策略。

總結

選型建議：無狀態服務首選輪詢/加權輪詢；需 Session 親和性用 IP Hash；後端處理時間波動大引入 Fair；快取層部署 URL Hash。實際生產常混合使用，如靜態資源走 URL Hash，動態 API 用加權輪詢 + IP Hash 兜底。善用 backup、down、max_fails 等參數構建高可用架構，並配合監控系統觀測 $upstream_response_time 等變數，持續優化調度策略。