前言

利用 proxy_ pass可以將請求代理到后端服務器，前一篇博客中的的配置示例都指向同一臺服務器，如果需要指向多臺服務器就要用到 ngx_ http_ upstream_ module。它為反向代理提供了負載均衡及故障轉移等重要功能。

代理多臺服務器

先來看一個簡單的版本：

指令： upstream
語法： upstream name {...}
環(huán)境： http含義：定義一組 HTTP服務器，這些服務器可以監(jiān)聽不同的端口，以及 TCP和 UNIX套接字。在同一個 upstream中可以混合使用不同的端口、 TCP和 UNIX套接字。

指令： server
語法： server address [parameters];
環(huán)境： upstream
含義：配置后端服務器，參數可以是不同的 IP地址、端口號，甚至域名。 

server指令擁有豐富的參數，其參數說明見下表：

故障轉移

如果在前面的配置示例中出現了超過請求失敗次數的服務器，下面這些參數可以用來對這些服務器進行配置： proxy_ next_ upstream、 fastcgi_ next_ upstream、 uwsgi_ next_ upstream、 scgi_ next_ upstream、 memcached_ next_ upstream和 grpc_ next_ upstream。

下面用最常見的 proxy_ next_ upstream為例進行說明。

指令： proxy_ next_ upstream
語法： proxy_ next_ upstream error | timeout | invalid_ header | http_ 500 | http_ 502 | http_ 503 | http_ 504 | http_ 403 | http_ 404 | http_ 429 | non_ idempotent | off ...;
默認值： proxy_ next_ upstream error timeout;
環(huán)境： http、 server、 location
含義：定義轉發(fā)條件，當請求返回 Nginx時，如果 HTTP狀態(tài)滿足 proxy_ next_ upstream設置的條件，就會觸發(fā) Nginx將請求重新轉發(fā)到下一臺后端服務器，并累加出現此狀態(tài)的服務器的失敗次數（當超過 max_ fails和 fail_ timeout的值時就會設置此服務器為不可用）。如果設置為 off，則表示關閉此功能。

指令： proxy_ next_ upstream_ tries
語法： proxy_ next_ upstream_ tries number;
默認值： proxy_ next_ upstream_ tries 0;
環(huán)境： http、 server、 location
含義：定義嘗試請求的次數，達到次數上限后就停止轉發(fā)，并將請求內容返回客戶端。

指令： proxy_ next_ upstream_ timeout
語法： proxy_ next_ upstream_ timeout time;
默認值： proxy_ next_ upstream_ timeout 0;
環(huán)境： http、 server、 location
含義：限制嘗試請求的超時時間，如果第一次請求失敗，下一次請求就會被此參數值控制。若設置為 0，則表示無超時時間，但嘗試的請求仍會受到 proxy_ read_ timeout、 proxy_ send_ timeout、 proxy_ connect_ timeout的影響。

注意：通過這些配置，可以在后端服務器的某些節(jié)點出現請求異常時，快速做出故障切換的操作，從而屏蔽這些異常的請求。但是這存在一種隱患，即如果 proxy_ next_ upstream_ tries設置的值比較大，且 proxy_ next_ upstream也設置了很多狀態(tài)，當發(fā)生大面積異常時，重試不斷累加，可能會導致請求反復向多個服務器發(fā)送，這樣會給后端服務器帶來更大的壓力。

負載均衡

Nginx不僅支持代理多臺后端服務器，也支持各種負載均衡模式，負載均衡在 upstream的配置環(huán)境內設置（默認根據權重輪詢）。

負載均衡指令見下表：

通過 hash分片提升緩存命中率

緩存系統是減少后端服務壓力的重要組件，常見的 HTTP緩存系統有 Nginx的 proxy_ cache、 varnish、 squid。如果通過反向代理去獲取緩存數據，一般需要使用 hash分片，以避免 URL的請求隨機進入緩存系統的某個分片，導致緩存命中率低、后端服務器壓力上升。

基于 URL緩存的服務配置一般如下所示，相同的 URL（包含參數）會進入相同的后端緩存系統。

注意：

增減節(jié)點會導致 hash重新計算，因此增減節(jié)點最好選擇在服務的低峰期進行。在緩存系統上使用 max_ fails不一定是最好的選擇，但一旦使用請確保 proxy_ next_ upstream的合理性，盡量不要配置各種 HTTP狀態(tài)碼，因為緩存系統代理的是后端服務，當后端服務異常時會將錯誤的狀態(tài)碼返回給 Nginx，這樣會讓 Nginx以為緩存系統出了問題，從而將緩存節(jié)點當作失敗的節(jié)點，停止分流。

緩存系統的故障轉移應該只以存活檢查方式（一般指檢查緩存系統的端口是否存活，以及固定檢查一個接口是否能返回正常的響應）為主?？梢越Y合健康檢測功能，或者動態(tài)剔除異常緩存節(jié)點的功能來使用，詳細介紹請看后續(xù)。

利用長連接提升性能

在 Nginx中，使用 upstream進行后端訪問默認用的是短連接，但這會增加網絡資源的消耗?？梢酝ㄟ^配置長連接，來減少因建立連接產生的開銷、提升性能。和長連接有關的配置示例如下：

長連接配置指令說明見下表：

注意：如果沒有添加長連接，在壓力測試（以下簡稱壓測）環(huán)境中，可能會出現這樣的情景：當壓測達到一定的 QPS（ Query Per Second，每秒查詢率）后， Nginx服務器突然“卡死”， QPS直接降到幾乎為 0，但是壓測并沒有停；幾分鐘后又會自動恢復，然后再壓測一段時間后， QPS又會突然降到接近于 0。這種情況就要考慮是不是 timewait的狀態(tài)過多了。

利用 resolver加速對內部域名的訪問

proxy_ pass可以直接將域名代理到后端服務器上，請求前會先解析出 IP地址，例如：

反復的 DNS（ Domain Name System，域名系統）解析會影響請求的速度，并且如果出現連接 DNS服務器超時的情況，可能會導致請求無法發(fā)送，這里需要用 DNS緩存來解決這個問題，示例代碼如下：

resolver指令說明見下表。

注意：解析 DNS后，通過 set $ upstream_ host test2. zhe800. com的方式，將獲取的 IP地址再賦值給 proxy_ pass，這是為了讓 Nginx重新去解析 DNS中的 IP地址。利用 valid的配置，可以減少 DNS的解析次數，從而提高請求的效率。當然對 DNS緩存時間的控制也要有度，避免出現 DNS切換 IP地址后， Nginx無法快速切換到新 IP地址的情況。如果需要在 upstream內部對域名的配置進行解析，使用 Nginx的開源版會受到一些限制，因為此功能被放到了商業(yè)版中，需要和 zone的功能配合使用。

到此這篇關于Nginx upstream使用指南的文章就介紹到這了,更多相關Nginx upstream使用內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論