nginx 的 HTTP 負載均衡

nginx 的 HTTP 負載均衡
========================

編譯自：
http://nginx.org/en/docs/http/load_balancing.html

目錄：
    負載均衡方法
    默認負載均衡配置
    基於最小鏈接數的負載均衡
    會話保持
    給負載均衡添加權重
    健康檢測
    進一步閱讀
    

簡介
-------

負載均衡是廣泛使用的技術，使用負載均衡架構有不少優勢：
    可提升資源利用率
    增長系統吞吐量的上限
    下降響應延遲
    可保證容錯的配置

nginx 可用做一個很是高效的 HTTP 負載均衡調度器，將訪問流量分發給多個應用服務器。
這樣能夠提高 web 應用的性能，以及可擴展性和可靠性。

負載均衡方法
---------------

nginx 支持三種均衡策略：
    1. 輪詢 
    2. 最小鏈接數 
    3. ip-hash - 源地址 hash 

默認負載均衡配置
----------------

最簡單的負載均衡配置以下：

    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。若是未指定均衡方法，默認採用「輪詢」策略。全部請求被轉發給一個服務器組 myapp1，nginx 使用 HTTP 負載均衡策略將訪問請求分發給組內的應用實例。

nginx 所實現的反向代理可爲以下的協議作負載均衡：
    HTTP, HTTPS, FastCGI, uwsgi, SCGI, and memcached.

若是要爲 HTTPS 訪問的配置負載均衡，使用 「https」 替換 「http」 做爲地址協議便可。

若是 FastCGI, uwsgi, SCGI, memcached 設置負載均衡，分別使用 

fastcgi_pass, uwsgi_pass, scgi_pass, memcached_pass 指令。

基於最小鏈接數的負載均衡
-------------------------

當一些訪問請求所須要時間較長，使用「最小鏈接數」策略可以使訪問更平均的分配到應用服務器，nginx 會嘗試把新的請求發給負擔較小的應用服務器。

在配置中，使用 least_conn 指令激活「最小鏈接數」策略，將該指令放入 server group:

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

會話保持
-------------

基於 「輪詢」 或 「最小鏈接數」策略，來自同一個 client 的訪問請求可能被分發給不一樣的服務器。不能保證來自同一個 client 的訪問定向至同一個應用服務器。

若是須要未來自同一個 client 的訪問定向至同一個應用服務器，可以使用 ip-hash 策略。

ip-hash 策略會把 client IP 地址做爲 hash key，用於決定未來自該 client 的訪問
請求定向至某個應用服務器。由於相同的 IP 地址老是計算出相同的 hash 值，因此 來自同一
個 client 的訪問老是被定向至同一個應用服務器，除非該服務器除了問題。

配置基於 ip-hash 的負載均衡，使用 ip_hash 指令：

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

 

給負載均衡添加權重
-----------------

對於基本的三種負載均衡策略，可爲其添加權重影響流量分配傾向。

若是應用服務器沒有配置權重，被認爲擁有相同的權重。

考慮以下的例子：

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

這個服務器組沒有顯式定義均衡策略，默認採用「輪詢」策略，srv1 具備值爲 3 的權重。
假設有 5 個訪問請求，3 個請求會分配給 srv1，1 個請求分配給 srv2，1 個請求分配給 srv3。

在最近的 nginx 版本中，一樣也能夠在基於「最小鏈接數」和 ip-hash 的負載均衡中使用權重。

健康檢測
----------

nginx 所實現的反向代理包含「被動的」服務器健康檢測功能。

若是 nginx 對於後端服務器的檢查，收到了包含錯誤的失敗響應，nginx 將其標記爲 failed，
而且在一段時間內再也不分發請求給該服務器。

max_fail 指令用於設置：在 fail_timeout 期間內，發生幾回連續失敗檢測，才認定該服務器爲失效。
max_fail 默認設置爲 1。當設置爲 0，意味不對該應用服務器進行健康檢查。

fail_timeout 也定義了，在多久沒有收到來自應用服務器的響應後，將其標記爲 failed。

當一個服務器被標記爲 failed，過了 fail_timeout 時間以後，nginx 開始嘗試分發用戶請求
給該服務器，以測試該服務器是否可正常服務，若是成功，該服務器被標記爲 live。

max_fail

fail_timeout

進一步閱讀
--------------

在 nginx 中，還有不少對於負載均衡進行控制的指令，好比：
proxy_next_upstream, 

backup, 

down, 

keepalive

更多信息請參考：http://nginx.org/en/docs/