使用 NGINX 作 HTTP 負載均衡

Introduction

負載均衡通常被用來優化資源利用率、最大化吞吐量、下降延遲和容錯配置。

Nginx 能夠做爲一種十分有效的 HTTP 負載均衡工具來使用，經過 nginx 的負載均衡分發流量到不一樣的應用服務器，能夠提高 web 應用的性能、伸展性和可靠性。

Load balancing methods

Nginx 支持下面幾種負載均衡策略：

round-robin(輪詢) — 根據輪詢分發請求到不一樣的服務器
least-connected(最少鏈接) — 將最新請求分發到活動鏈接最少的服務器
ip-hash(ip 哈希) — 用一個哈希函數來決定最新請求應該被分發到哪個服務器(基於客戶端的 ip).

Default load balancing configuration

舉個栗子

最簡單的 nginx 負載均衡配置看起來像這樣：

http {
    upstream myapp1 {
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://myapp1;
        }
    }
}

在上面的例子中，有三個同樣的應用跑在 srv1-srv3 服務器上。當咱們沒有配置任何負載均衡策略的時候，nginx 會採用默認的負載均衡策略——輪詢。全部的請求都被代理到 myapp1 服務器羣，而後 nginx 根據 HTTP 負載均衡分發請求。

Nginx 反向代理包括對 HTTP, HTTPS, FastCGI, uwsgi, SCGI, and memcached 的負載均衡策略。

若是想要配置 HTTPS 的負載均衡，只須要使用 「https」 協議就能夠了。

當設置 FastCGI, uwsgi, SCGI, or memcached 的負載均衡策略時，只須要使用分別使用 fastcgi_pass , uwsgi_pass , scgi_pass , and memcached_pass 指令就能夠了。

Least connected load balancing

另外一種負載均衡策略是最少鏈接。當一些鏈接完成所需時間更長時，使用最少鏈接策略能夠更公平地控制均衡負載。

當使用最少鏈接負載均衡策略時，nginx 會把新請求分發給不太忙的服務器，從而避免分發過多的請求給忙碌的服務器形成過載。

只要把 least_conn 指令配置成服務器羣配置的一部分 nginx 就會採用最少鏈接負載均衡策略：

upstream myapp1 {
    least_conn;
    server srv1.example.com;
    server srv2.example.com;
    server srv3.example.com;
}

Session persistence

值得注意的是，輪詢和最少鏈接負載均衡可能會把來自同一個客戶端的請求分發到不一樣的服務器。它們不保證同一個客戶端的請求會分發到一樣的服務器上。

若是須要把同一個客戶端請求分發到一樣的服務器的，換句話說就是讓客戶端的會話「持續」而又「有粘性」地選擇鏈接到特定的服務器，那麼可使用 ip 哈希負載均衡策略。

ip 哈希負載均衡策略會使用客戶端的 ip 地址做爲哈希的 key 來決定選擇服務器羣中某臺服務器來處理客戶端的請求。這種方式確保來自同一臺客戶端的請求會分發到同一臺服務器上，除非這臺服務器處於不可用狀態。

只須要把 ip_hash 指令添加到服務器羣(upstream)配置中就可使用 ip 哈希負載均衡策略了：

upstream myapp1 {
    ip_hash;
    server srv1.example.com;
    server srv2.example.com;
    server srv3.example.com;
}

Weighted load balancing

除了上面三種負載均衡策略，咱們還能夠經過配置服務器權重來更深刻地影響 nginx 負載均衡算法。

在上面幾個例子中，並無配置服務器權重，那麼這意味着 nginx 在進行負載均衡計算的時候會同等地看待配置的服務器。

假若有足夠的請求，而且請求的處理模式一致並且完成的速度足夠快，那麼輪詢負載均衡策略意味着根據基本上一致的權重來分發請求到服務器上。

當一個服務器被配置了權重的時候，權重值就會被當作負載均衡算法決策因素的一部分。

upstream myapp1 {
    server srv1.example.com weight=3;
    server srv2.example.com;
    server srv3.example.com;
}

當採用上面的配置的時候，每5個請求將會以下方式分發到應用服務器上：
三個請求會分發到 srv1，一個會分發到 srv2，另外一個會分發到 srv3

權重式負載均衡策略能夠在最近版本的 nginx 運用到最少鏈接和 ip hash 負載均衡策略中。

Health checks

nginx 的反向代理實現包括了被動的 health checks 策略。當某個特定的服務器因爲錯誤而響應失敗時，nginx 會把這臺服務器標記爲 failed，而且會在一短期內不把後續的請求分發到這臺服務器上。

max_fails 指令能夠設置容許的在 fail_timeout 時間內嘗試與服務器交互的最大連續失敗次數。max_fails 默認爲 1。當 max_fails 設置成 0 的時候，這臺服務器的 health checks 功能將會被禁用。fail_timeout 參數同時也定義了服務器被標記爲 failed 的時長。服務器出錯而且通過 fail_timeout 的時間間隔以後， nginx 會開始優雅地用活躍的客戶端請求來探測出錯的服務器。若是這些探測成功了，那麼這臺服務器將會被標記爲正常。

強烈建議讀完 max_fails 跟 fail_timeout 的連接。

Further reading

另外，還有不少的命令以及參數能夠控制 nginx 的負載均衡，例如 proxy_next_upstream , backup , down , and keepalive 。同時，能夠經過閱讀 reference documentation 來獲取更多信息。

使用 NGINX 作 HTTP 負載均衡 - Agentd

Reference links

http://nginx.org/en/docs/http...
http://nginx.org/en/docs/http...
http://nginx.org/en/docs/http...
http://nginx.org/en/docs/http...
http://blog.csdn.net/xiajun07...
http://blog.csdn.net/xiajun07...