高效能Web伺服器Nginx的配置與部署研究（15）Upstream負載平衡模組

標籤：style   blog   http   color   io   os   ar   使用   sp   

Nginx 的 HttpUpstreamModule 提供對後端（backend）伺服器的簡單負載平衡。一個最簡單的 upstream 寫法如下：

    server backend1.example.com;

    server backend2.example.com;

    server.backend3.example.com;

    location / {

        proxy_pass http://backend;

    }

1、後端伺服器

通過 upstream 可以設定後端伺服器，指定的方式可以是IP 位址與連接埠、網域名稱、UNIX 通訊端（socket）。其中如果網域名稱可以被解析為多個地址，則這些地址都作為 backend。下面舉例說明：

    server blog.csdn.net/poechant;

    server 145.223.156.89:8090;

    server unix:/tmp/backend3;

第一個 backend 是用網域名稱指定的。第二個 backend 是用 IP 和連接埠號碼指定的。第三個 backend 是用 UNIX 通訊端指定的。

2、負載平衡策略

Nginx 提供輪詢（round robin）、使用者 IP 雜湊（client IP）和指定權重 3 種方式。

預設情況下，Nginx 會為你提供輪詢作為負載平衡策略。但是這並不一定能夠讓你滿意。比如，某一時段內的一連串訪問都是由同一個使用者 Michael 發起的，那麼第一次 Michael 的請求可能是 backend2，而下一次是 backend3，然後是 backend1、backend2、backend3…… 在大多數應用情境中，這樣並不高效。當然，也正因如此，Nginx 為你提供了一個按照 Michael、Jason、David 等等這些亂七八糟的使用者的 IP 來 hash 的方式，這樣每個 client 的訪問請求都會被甩給同一個後端伺服器。（另外，由於最近發現很多網站以不留原文連結的方式盜取本博博文，所以我就在這插一下本博的地址“http://blog.csdn.net/poechant”）具體的使用方式如下：

    ip_hash;

    server backend1.example.com;

    server backend2.example.com;

    server.backend3.example.com;

這種策略中，用於進行hash 運算的 key，是 client 的 C 類別 IP 位址（C 類別 IP 位址就是範圍在 192.0.0.0 到 223.255.255.255 之間，前三段號碼錶示子網，第四段號碼為本地主機的 IP 位址類別）。這樣的方式保證一個 client 每次請求都將到達同一個 backend。當然，如果所 hash 到的 backend 當前不可用，則請求會被轉移到其他 backend。

再介紹一個和 ip_hash 配合使用的關鍵字：down。當某個一個 server 暫時性的宕機（down）時，你可以使用“down”來標示出來，並且這樣被標示的 server 就不會接受請求去處理。具體如下：

    server blog.csdn.net/poechant down;

    server 145.223.156.89:8090;

    server unix:/tmp/backend3;

還可以使用指定權重（weight）的方式，如下：

    server backend1.example.com;

weight=4;

預設情況下 weight 為 1，對於上面的例子，第一個 server 的權重取預設值 1，第二個是 4，所以相當於第一個 server 接收 20% 的請求，第二接收 80% 的。要注意的是weight 與 ip_hash 是不能同時使用的，原因很簡單，他們是不同且彼此衝突的策略。

3、重試策略

可以為每個 backend 指定最大的重試次數，和重試時間間隔。所使用的關鍵字是 max_fails 和 fail_timeout。如下所示：

    server backend1.example.com weight=5;

max_fails=3fail_timeout=30s;

在上例中，最大失敗次數為 3，也就是最多進行 3 次嘗試，且逾時時間為 30秒。max_fails 的預設值為 1，fail_timeout 的預設值是 10s。傳輸失敗的情形，由 proxy_next_upstream 或 fastcgi_next_upstream 指定。而且可以使用 proxy_connect_timeout 和 proxy_read_timeout 控制 upstream 回應時間。

有一種情況需要注意，就是 upstream 中只有一個 server 時，max_fails 和 fail_timeout 參數可能不會起作用。導致的問題就是 nginx 只會嘗試一次 upstream 請求，如果失敗這個請求就被拋棄了 : (……解決的方法，比較取巧，就是在 upstream 中將你這個可憐的唯一 server 多寫幾次，如下：

    server backend.example.com max_fails fail_timeout=30s;

    server backend.example.com max_fails fail_timeout=30s;

    server backend.example.com max_fails fail_timeout=30s;

4、備機策略

從 Nginx 的 0.6.7 版本開始，可以使用“backup”關鍵字。當所有的非備機（non-backup）都宕機（down）或者繁忙（busy）的時候，就只使用由 backup 標註的備機。必須要注意的是，backup 不能和 ip_hash 關鍵字一起使用。舉例如下：

    server backend1.example.com;

backup;

    server backend3.example.com;

}

高效能Web伺服器Nginx的配置與部署研究（15）Upstream負載平衡模組