2019獨角獸企業重金招聘Python工程師標準>>>

ngnix的upstream模塊配置詳解

2017年04月04日 13:10:03?阿里-橙鷹-潘民蘭?閱讀數：15409?標簽：?nginxupstream集群 負載均衡?更多

個人分類：?nginx

ngx_http_upstream_module?模塊是用來定義被proxy_pass,fastcgi_pass,uwsgi_pass,scgi_pass, and?memcached_pass?指令引用的服務器組。

實例配置

?

?

upstream backend {

??? server backend1.example.com?????? weight=5;

??? server backend2.example.com:8080;

??? server unix:/tmp/backend3;

?

??? server backup1.example.com:8080?? backup;

??? server backup2.example.com:8080?? backup;

}

?

server {

??? location / {

??????? proxy_pass http://backend;

??? }

}

?

?

?

動態可配置組的定期健康檢查可以作為我們商業訂閱的一部分：

?

?

resolver 10.0.0.1;

?

upstream dynamic {

zone upstream_dynamic 64k;

?

server backend1.example.com weight=5;

server backend2.example.com:8080 fail_timeout=5s slow_start=30s;

server 192.0.2.1 max_fails=3;

server backend3.example.com resolve;

server backend4.example.com service=http resolve;

?

server backup1.example.com:8080 backup;

server backup2.example.com:8080 backup;

}

?

server {

location / {

proxy_pass http://dynamic;

health_check;

}

}

指令集

?

Syntax:

upstream name { ... }

Default:

—

Context:

http

定義一組服務。服務可以監聽在不同端口， 另外,?服務混合監聽在 TCP and UNIX-domain sockets。

例如：

?

upstream backend {

server backend1.example.com weight=5;

server 127.0.0.1:8080 max_fails=3 fail_timeout=30s;

server unix:/tmp/backend3;

?

server backup1.example.com backup;

}

通常,?請求被服務之間通過加權循環均衡負載方法分發。在上面的例子中， 每七次請求將被如下分發：5?次請求去?backend1.example.com然后第二和第三個服務分別獲得一次。當和一個服務通信失敗時, 請求將被傳遞給另一個服務,如果還是不行的話 會一直傳遞到所有的服務器，如果所有的服務都不不能成功處理該請求，客戶端將接受到最后一個服務器的響應。

?

?

Syntax:

server address [parameters];

Default:

—

Context: upstream

定義一個服務的地址和其他參數，?該地址可以被定義為一個?域名或者IP地址,作為一個可選的端口, 或者是一個被"unixt:"前綴修飾的UNIX_domain socket 路徑， 如果一個端口沒有定義, 則使用80端口. 一個域名如果對應多個Ip地址，則同時定義多個服務地址。.
可以定義一下參數

weight=number

設置定義的服務的權重，默認為1。

max_conns=number

限制連接到代理服務器的并發連接數，版本(1.11.5). 默認值是0,意思是沒有限制.?如果集群沒有使用 共享內存, 則該限制對應的是每個工作進程。.

如果idle keepalive?連接,多workers,?和?shared memory是能夠使用的 , 那么代理服務器的激活的和閑置的連接將超過max_conns的值。

版本1.5.9?到 1.11.5, max_conns是可用的作為我們商業訂閱的一部分。

max_fails=number

設置在被fail_timeout參數定義的時間內當和服務通信失敗嘗試的次數。默認的該值被設為1.如果為0表示不支持失敗重試，什么被當作是不成功的嘗試被這些指令定義：proxy_next_upstream,fastcgi_next_upstream,?uwsgi_next_upstream,?scgi_next_upstream,?和?memcached_next_upstream?.

fail_timeout=time

?

• 在該參數定義的時間范圍內和服務器的通信失敗嘗試重連時間范圍，如果超過則表示該服務器不可用。
• 在這個時間段服務被當作不可用

默認情況下, 該參數被設置成10秒.

backup

標記該服務是一個熱備服務. 當主服務不可用后才會把請求傳遞給它。

down

?

標記該服務永久不可用。

?

另外，下面參數是做為我們商業訂閱的一部分：

?

resolve

監控綁定到一個服務的域名的ip地址的變化，然后自動修改upstream配置不需要重啟nginx（1.5.12）.服務集群必須使用共享內存。

為了讓該參數生效，resolver指令必須定義在http 模塊，如：

?

?

http {

resolver 10.0.0.1;

?

upstream u {

zone ...;

...

server example.com resolve;

}

}

?

route=string

設置服務路由的名稱

service=name

啟用DNS SRV記錄解析和設置服務的名稱（1.9.13）.為了讓該參數生效，需要定義resolve參數和指定一個不需要端口的hostname.

如果該服務名稱不包含(".")號，那么RFC-compliant名稱將被構造以及TCP協議被添加到服務的前綴。例如，去查找_http._tcp.backend.example.com?SRV記錄，是有必要定義該指令：

?

server backend.example.com service=http resolve;

如果該服務名稱包含一個或者多個點號, 那么該服務名稱將通過結合服務前綴和服務名稱構造。例如。

?

?

server backend.example.com service=_http._tcp resolve;

server example.com service=server1.backend resolve;

最高優先級SRV記錄（同樣最低數字的優先級值）將被當作主服務解析，剩下的SRV記錄被當作備份服務。如果backup參數在有定義在該服務商，高優先級SRV 記錄將被當作備份服務，剩下的SRV記錄被忽略。

?

slow_start=time

設置服務從權重0到正常值的一個時間期限，當不健康的服務變成健康的，或者當服務從不可用到可用，默認值是0，意思slow start不可用。

該參數不能和hash 以及ip_hash 負載均衡方法一起使用。

如果在集群中只有一個服務?max_fails,?fail_timeout?and?slow_start?參數將被忽略，然后這樣的服務將被永久當作可用。

?

Syntax:

zone name [size];

Default:

—

Context:

upstream

This directive appeared in version 1.9.0.

定義集群的配置和工作進程共享運行時狀態的共享內存區域的name 和size ，幾個集群會共享同樣的區域，所以可以定義zone的大小一次就可。

另外，作為我們商業訂閱的一部分，集群運行改變集群成員和修改一些服務的配置不需要重啟nginx。那配置是可以見的在指定的位置被upstream_conf管理。

?

Syntax:

state file;

Default:

—

Context:

upstream

This directive appeared in version 1.9.7.

制定一個文件保存動態可配置集群的狀態。

例如：

?

?

state /var/lib/nginx/state/servers.conf; # path for Linux

state /var/db/nginx/state/servers.conf; # path for FreeBSD

集群的狀態目前被限制在一系列的服務里。當解析配置或者更新配置時該文件將被讀取。直接改變該文件的內容應該要避免，該指令不能和server指令一起使用。
在configuration_reload或者binary_upgrade期間對該文件的修改將可能丟失修改。

這個指令是我們商業訂閱的一部分。

?

Syntax:Default:Context:

hash?key?[consistent];

—

upstream

This directive appeared in version 1.7.2.

指定集群負載均衡的方法基于hash key的值。key可以保護文本，變量，和它們的組合。注意，從集群添加或者刪除服務都會導致請求映射到其他服務商。這個方法可以和Cache::Memcached Perl 庫兼容。

如果consistent參數被定義，一致性哈希算法將被使用，該方法保證一小部分的請求被重新映射到其他服務當集群的服務添加或者刪除時，這幫助緩存服務器提高緩存命中率。IThe method is compatible with the?Cache::Memcached::Fast?Perl library with the?ketama_points?parameter set to 160.

Syntax: ip_hash; ?

Default:

—

Context:

upstream

指定集群服務應該根據客戶端ip來進行負載均衡。IPV4地址的前三個字節，或者整個IPV6的地址，將被當作哈希值。這個方法保證來自哦同一個客戶端的請求映射到同一個服務器上除掉該服務部可用。

IPV6地址將從1.3.2和1.2.2版本開始支持。

如果集群中的一個服務被暫時的移除，該服務應用用 down參數定義，以防當前客戶的ip地址哈希映射過去。

例如：

?

Example:

upstream backend {

ip_hash;

?

server backend1.example.com;

server backend2.example.com;

server backend3.example.com down;

server backend4.example.com;

}

直到版本.32和1.2.2，都不能夠用過ip_hash進行負載均衡時指定權重。

?

?

Syntax:

keepalive connections;

Default:

—

Context:

upstream

This directive appeared in version 1.1.4.

激活連接到上游服務器的緩存。

connections參數設置連接到上游服務的最大空閑連接數--被保存在每個工作進程的緩存里。當連接數超過該connections時最近最少使用的連接將被關閉。

使用keepalive connections的上游服務的緩存配置實例：

?

upstream memcached_backend {

server 127.0.0.1:11211;

server 10.0.0.2:11211;

?

keepalive 32;

}

?

server {

...

?

location /memcached/ {

set $memcached_key $uri;

memcached_pass memcached_backend;

}

?

}

對于HTTP，proxy_http_version應該設置為'1.1'然后"Connection"header 字段應該被清空：

?

?

upstream http_backend {

server 127.0.0.1:8080;

?

keepalive 16;

}

?

server {

...

?

location /http/ {

proxy_pass http://http_backend;

proxy_http_version 1.1;

proxy_set_header Connection "";

...

}

}

轉載于:https://my.oschina.net/u/3367404/blog/2252452

超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生

總結

以上是生活随笔為你收集整理的ngnix的upstream模块配置详解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。