nginx分發算法

NIGNX http 分發算法介紹


跨多個應用程序實例的負載平衡是優化資源利用率、最大化吞吐量、減小延遲和確保容錯配置的經常使用技術。

可使用 nginx 做爲很是高效的 HTTP 負載均衡器將流量分發到多個應用程序服務器，並提升使用 nginx 的 Web 應用程序的性能、可擴展性和可靠性。

負載平衡方法
nginx 中支持如下負載平衡機制（或方法） ：

循環 - 對應用程序服務器的請求以循環方式分發，
鏈接最少的 = 下一個請求分配給活動鏈接最少的服務器，
ip 哈希 - 哈希函數用於肯定應爲下一個請求（基於客戶端的 IP 地址）選擇哪一個服務器。
默認負載平衡配置
使用 nginx 進行負載平衡的最簡單配置可能以下所示：

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

    server {
        listen 80;

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

在上面的示例中，有 3 個相同應用程序的實例在 srv1-srv3 上運行。當負載平衡方法未專門配置時，它默認爲循環。全部請求都代理到服務器組 myapp1，nginx 應用 HTTP 負載平衡來分發請求。

nginx 中的反向代理實現包括 HTTP、HTTPS、FastCGI、uwsgi、SCGI、memcached 和 gRPC 的負載平衡。

若要爲 HTTPS 而不是 HTTP 配置負載平衡，只需使用"https"做爲協議。

當爲 FastCGI、uwsgi、SCGI、memcached 或 gRPC 設置負載平衡時，分別使用 fastcgi_pass、uwsgi_pass、scgi_pass、memcached_pass和grpc_pass指令。

最少鏈接的負載平衡
另外一個負載平衡約束鏈接最少。在某些請求須要更長的時間才能完成的狀況下，鏈接最少容許更公平地控制應用程序實例上的負載。

使用鏈接最少的負載平衡，nginx 將盡可能不要使繁忙的應用程序服務器過載，請求過多，而是將新請求分發到不太繁忙的服務器。

當將系統指令用做服務器組配置的一least_conn時，將激活 nginx 中鏈接最少的負載平衡：

    upstream myapp1 {
        least_conn;
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }
會話持久性
請注意，經過循環或最少鏈接的負載平衡，每一個後續客戶端的請求均可能分發到不一樣的服務器。不能保證同一客戶端將始終定向到同一服務器。

若是須要將客戶端與特定應用程序服務器（換句話說，使客戶端的會話始終嘗試選擇特定服務器爲"粘性"或"持久"）使用 ip 哈希負載平衡機制。

使用 ip 哈希，客戶端的 IP 地址用做哈希鍵，以肯定應爲客戶端的請求選擇服務器組中的哪一個服務器。此方法可確保來自同一客戶端的請求始終定向到同一服務器，除非此服務器不可用。

要配置 ip 哈希負載平衡，只需將ip_hash添加到服務器（上游）組配置：

upstream myapp1 {
    ip_hash;
    server srv1.example.com;
    server srv2.example.com;
    server srv3.example.com;
}
加權負載平衡
也能夠經過使用服務器權重進一步影響 nginx 負載平衡算法。

在上面的示例中，未配置服務器權重，這意味着全部指定的服務器都被視爲對特定負載平衡方法的同等限定。

特別是循環，這也意味着請求在服務器之間或多或少的平等分佈 ——只要有足夠的請求，而且請求以統一的方式處理而且完成得足夠快。

當爲服務器指定權重參數時，權重將計入負載平衡決策的一部分。

    upstream myapp1 {
        server srv1.example.com weight=3;
        server srv2.example.com;
        server srv3.example.com;
    }
經過此配置，每 5 個新請求將分佈在應用程序實例中，以下所示：3 個請求將定向到 srv1，一個請求將定向到 srv2，另外一個請求將轉到 srv3。

一樣，在 nginx 的最新版本中，使用鏈接最少的和 ip 哈希負載平衡的權重。

運行情況檢查
nginx 中的反向代理實現包括帶內（或被動）服務器運行情況檢查。若是來自特定服務器的響應失敗並出現錯誤，nginx 將標記此服務器爲失敗，並將嘗試在一段時間內避免選擇此服務器進行後續入站請求。

max_fails指令設置在一個會話期間應發生的連續未成功嘗試fail_timeout。默認狀況下，max_fails設置爲 1。當設置爲 0 時，將禁用此服務器的運行情況檢查。"fail_timeout參數還定義了服務器將被標記爲失敗的時間。服務器fail_timeout後，nginx 將開始使用實時客戶端的請求正常地探測服務器。若是探測器成功，則服務器將標記爲實時探測器。



upstream backend {
    hash $remote_addr consistent;

    server backend1.example.com:12345  weight=5;
    server backend2.example.com:12345;
    server unix:/tmp/backend3;
    server backup1.example.com:12345   backup;
    server backup2.example.com:12345   backup;
}

server {
    listen 12346;
    proxy_pass backend;
}



upstream backend {
    server backend1.example.com:12345 weight=5;
    server 127.0.0.1:12345            max_fails=3 fail_timeout=30s;
    server unix:/tmp/backend2;
    server backup1.example.com:12345  backup;
}