nginx負載均衡

原創 TRUEtpc 2018-08-28 23:12

nginx負載均衡的5種策略（轉載）

nginx可以根據客戶端IP進行負載均衡，在upstream裏設置ip_hash，就可以針對同一個C類地址段中的客戶端選擇同一個後端服務器，除非那個後端服務器宕了纔會換一個。

nginx的upstream目前支持的5種方式的分配


1、輪詢（默認）
每個請求按時間順序逐一分配到不同的後端服務器，如果後端服務器down掉，能自動剔除。 
upstream backserver { 
server 192.168.0.14; 
server 192.168.0.15; 
} 

2、指定權重
指定輪詢機率，weight和訪問比率成正比，用於後端服務器性能不均的情況。 
upstream backserver { 
server 192.168.0.14 weight=10; 
server 192.168.0.15 weight=10; 
} 

3、IP綁定 ip_hash
每個請求按訪問ip的hash結果分配，這樣每個訪客固定訪問一個後端服務器，可以解決session的問題。 
upstream backserver { 
ip_hash; 
server 192.168.0.14:88; 
server 192.168.0.15:80; 
} 

4、fair（第三方）
按後端服務器的響應時間來分配請求，響應時間短的優先分配。 
upstream backserver { 
server server1; 
server server2; 
fair; 
} 

5、url_hash（第三方）
按訪問url的hash結果來分配請求，使每個url定向到同一個後端服務器，後端服務器爲緩存時比較有效。 
upstream backserver { 
server squid1:3128; 
server squid2:3128; 
hash $request_uri; 
hash_method crc32; 
} 

在需要使用負載均衡的server中增加 

proxy_pass http://backserver/; 
upstream backserver{ 
ip_hash; 
server 127.0.0.1:9090 down; (down 表示單前的server暫時不參與負載) 
server 127.0.0.1:8080 weight=2; (weight 默認爲1.weight越大，負載的權重就越大) 
server 127.0.0.1:6060; 
server 127.0.0.1:7070 backup; (其它所有的非backup機器down或者忙的時候，請求backup機器) 
} 

max_fails ：允許請求失敗的次數默認爲1.當超過最大次數時，返回proxy_next_upstream 模塊定義的錯誤 

fail_timeout:max_fails次失敗後，暫停的時間

nginx可以根據客戶端IP進行負載均衡，在upstream裏設置ip_hash，就可以針對同一個C類地址段中的客戶端選擇同一個後端服務器，除非那個後端服務器宕了纔會換一個。

nginx的upstream目前支持的5種方式的分配


1、輪詢（默認）
每個請求按時間順序逐一分配到不同的後端服務器，如果後端服務器down掉，能自動剔除。 
upstream backserver { 
server 192.168.0.14; 
server 192.168.0.15; 
} 

2、指定權重
指定輪詢機率，weight和訪問比率成正比，用於後端服務器性能不均的情況。 
upstream backserver { 
server 192.168.0.14 weight=10; 
server 192.168.0.15 weight=10; 
} 

3、IP綁定 ip_hash
每個請求按訪問ip的hash結果分配，這樣每個訪客固定訪問一個後端服務器，可以解決session的問題。 
upstream backserver { 
ip_hash; 
server 192.168.0.14:88; 
server 192.168.0.15:80; 
} 

4、fair（第三方）
按後端服務器的響應時間來分配請求，響應時間短的優先分配。 
upstream backserver { 
server server1; 
server server2; 
fair; 
} 

5、url_hash（第三方）
按訪問url的hash結果來分配請求，使每個url定向到同一個後端服務器，後端服務器爲緩存時比較有效。 
upstream backserver { 
server squid1:3128; 
server squid2:3128; 
hash $request_uri; 
hash_method crc32; 
} 

在需要使用負載均衡的server中增加 

proxy_pass http://backserver/; 
upstream backserver{ 
ip_hash; 
server 127.0.0.1:9090 down; (down 表示單前的server暫時不參與負載) 
server 127.0.0.1:8080 weight=2; (weight 默認爲1.weight越大，負載的權重就越大) 
server 127.0.0.1:6060; 
server 127.0.0.1:7070 backup; (其它所有的非backup機器down或者忙的時候，請求backup機器) 
} 

max_fails ：允許請求失敗的次數默認爲1.當超過最大次數時，返回proxy_next_upstream 模塊定義的錯誤 

fail_timeout:max_fails次失敗後，暫停的時間



Nginx 的 HttpUpstreamModule 提供對後端（backend）服務器的簡單負載均衡。一個最簡單的 upstream 寫法如下：

upstream backend {
    server backend1.example.com;
    server backend2.example.com;
    server.backend3.example.com;
}

server {
    location / {
        proxy_pass http://backend;
    }
}

1、後端服務器

通過 upstream 可以設定後端服務器，指定的方式可以是 IP 地址與端口、域名、UNIX 套接字（socket）。其中如果域名可以被解析爲多個地址，則這些地址都作爲 backend。下面舉例說明：

upstream backend {
    server blog.csdn.net/poechant;
    server 145.223.156.89:8090;
    server unix:/tmp/backend3;
}

第一個 backend 是用域名指定的。第二個 backend 是用 IP 和端口號指定的。第三個 backend 是用 UNIX 套接字指定的。

2、負載均衡策略

Nginx 提供輪詢（round robin）、用戶 IP 哈希（client IP）和指定權重 3 種方式。

默認情況下，Nginx 會爲你提供輪詢作爲負載均衡策略。但是這並不一定能夠讓你滿意。比如，某一時段內的一連串訪問都是由同一個用戶 Michael 發起的，那麼第一次 Michael 的請求可能是 backend2，而下一次是 backend3，然後是 backend1、backend2、backend3…… 在大多數應用場景中，這樣並不高效。當然，也正因如此，Nginx 爲你提供了一個按照 Michael、Jason、David 等等這些亂七八糟的用戶的 IP 來 hash 的方式，這樣每個 client 的訪問請求都會被甩給同一個後端服務器。具體的使用方式如下：

upstream backend {
    ip_hash;
    server backend1.example.com;
    server backend2.example.com;
    server.backend3.example.com;
}

這種策略中，用於進行 hash 運算的 key，是 client 的 C 類 IP 地址（C 類 IP 地址就是範圍在 192.0.0.0 到 223.255.255.255 之間，前三段號碼錶示子網，第四段號碼爲本地主機的 IP 地址類別）。這樣的方式保證一個 client 每次請求都將到達同一個 backend。當然，如果所 hash 到的 backend 當前不可用，則請求會被轉移到其他 backend。

再介紹一個和 ip_hash 配合使用的關鍵字：down。當某個一個 server 暫時性的宕機（down）時，你可以使用“down”來標示出來，並且這樣被標示的 server 就不會接受請求去處理。具體如下：

upstream backend {
    server blog.csdn.net/poechant down;
    server 145.223.156.89:8090;
    server unix:/tmp/backend3;
}

還可以使用指定權重（weight）的方式，如下：

upstream backend {
    server backend1.example.com;
    server 123.321.123.321:456 weight=4;
}

默認情況下 weight 爲 1，對於上面的例子，第一個 server 的權重取默認值 1，第二個是 4，所以相當於第一個 server 接收 20% 的請求，第二接收 80% 的。要注意的是 weight 與 ip_hash 是不能同時使用的，原因很簡單，他們是不同且彼此衝突的策略。

3、重試策略

可以爲每個 backend 指定最大的重試次數，和重試時間間隔。所使用的關鍵字是 max_fails 和 fail_timeout。如下所示：

upstream backend {
    server backend1.example.com weight=5;
    server 54.244.56.3:8081 max_fails=3 fail_timeout=30s;
}

在上例中，最大失敗次數爲 3，也就是最多進行 3 次嘗試，且超時時間爲 30秒。max_fails 的默認值爲 1，fail_timeout 的默認值是 10s。傳輸失敗的情形，由 proxy_next_upstream 或 fastcgi_next_upstream 指定。而且可以使用 proxy_connect_timeout 和 proxy_read_timeout 控制 upstream 響應時間。

有一種情況需要注意，就是 upstream 中只有一個 server 時，max_fails 和 fail_timeout 參數可能不會起作用。導致的問題就是 nginx 只會嘗試一次 upstream 請求，如果失敗這個請求就被拋棄了 : ( ……解決的方法，比較取巧，就是在 upstream 中將你這個可憐的唯一 server 多寫幾次，如下：

upstream backend {
    server backend.example.com max_fails fail_timeout=30s;
    server backend.example.com max_fails fail_timeout=30s;
    server backend.example.com max_fails fail_timeout=30s;
}

4、備機策略

從 Nginx 的 0.6.7 版本開始，可以使用“backup”關鍵字。當所有的非備機（non-backup）都宕機（down）或者繁忙（busy）的時候，就只使用由 backup 標註的備機。必須要注意的是，backup 不能和 ip_hash 關鍵字一起使用。舉例如下：

upstream backend {
    server backend1.example.com;
    server backend2.example.com backup;
    server backend3.example.com;
}



Nginx 的 HttpUpstreamModule 提供對後端（backend）服務器的簡單負載均衡。一個最簡單的 upstream 寫法如下：

upstream backend {
    server backend1.example.com;
    server backend2.example.com;
    server.backend3.example.com;
}

server {
    location / {
        proxy_pass http://backend;
    }
}

1、後端服務器

通過 upstream 可以設定後端服務器，指定的方式可以是 IP 地址與端口、域名、UNIX 套接字（socket）。其中如果域名可以被解析爲多個地址，則這些地址都作爲 backend。下面舉例說明：

upstream backend {
    server blog.csdn.net/poechant;
    server 145.223.156.89:8090;
    server unix:/tmp/backend3;
}

第一個 backend 是用域名指定的。第二個 backend 是用 IP 和端口號指定的。第三個 backend 是用 UNIX 套接字指定的。

2、負載均衡策略

Nginx 提供輪詢（round robin）、用戶 IP 哈希（client IP）和指定權重 3 種方式。

默認情況下，Nginx 會爲你提供輪詢作爲負載均衡策略。但是這並不一定能夠讓你滿意。比如，某一時段內的一連串訪問都是由同一個用戶 Michael 發起的，那麼第一次 Michael 的請求可能是 backend2，而下一次是 backend3，然後是 backend1、backend2、backend3…… 在大多數應用場景中，這樣並不高效。當然，也正因如此，Nginx 爲你提供了一個按照 Michael、Jason、David 等等這些亂七八糟的用戶的 IP 來 hash 的方式，這樣每個 client 的訪問請求都會被甩給同一個後端服務器。具體的使用方式如下：

upstream backend {
    ip_hash;
    server backend1.example.com;
    server backend2.example.com;
    server.backend3.example.com;
}

這種策略中，用於進行 hash 運算的 key，是 client 的 C 類 IP 地址（C 類 IP 地址就是範圍在 192.0.0.0 到 223.255.255.255 之間，前三段號碼錶示子網，第四段號碼爲本地主機的 IP 地址類別）。這樣的方式保證一個 client 每次請求都將到達同一個 backend。當然，如果所 hash 到的 backend 當前不可用，則請求會被轉移到其他 backend。

再介紹一個和 ip_hash 配合使用的關鍵字：down。當某個一個 server 暫時性的宕機（down）時，你可以使用“down”來標示出來，並且這樣被標示的 server 就不會接受請求去處理。具體如下：

upstream backend {
    server blog.csdn.net/poechant down;
    server 145.223.156.89:8090;
    server unix:/tmp/backend3;
}

還可以使用指定權重（weight）的方式，如下：

upstream backend {
    server backend1.example.com;
    server 123.321.123.321:456 weight=4;
}

默認情況下 weight 爲 1，對於上面的例子，第一個 server 的權重取默認值 1，第二個是 4，所以相當於第一個 server 接收 20% 的請求，第二接收 80% 的。要注意的是 weight 與 ip_hash 是不能同時使用的，原因很簡單，他們是不同且彼此衝突的策略。

3、重試策略

可以爲每個 backend 指定最大的重試次數，和重試時間間隔。所使用的關鍵字是 max_fails 和 fail_timeout。如下所示：

upstream backend {
    server backend1.example.com weight=5;
    server 54.244.56.3:8081 max_fails=3 fail_timeout=30s;
}

在上例中，最大失敗次數爲 3，也就是最多進行 3 次嘗試，且超時時間爲 30秒。max_fails 的默認值爲 1，fail_timeout 的默認值是 10s。傳輸失敗的情形，由 proxy_next_upstream 或 fastcgi_next_upstream 指定。而且可以使用 proxy_connect_timeout 和 proxy_read_timeout 控制 upstream 響應時間。

有一種情況需要注意，就是 upstream 中只有一個 server 時，max_fails 和 fail_timeout 參數可能不會起作用。導致的問題就是 nginx 只會嘗試一次 upstream 請求，如果失敗這個請求就被拋棄了 : ( ……解決的方法，比較取巧，就是在 upstream 中將你這個可憐的唯一 server 多寫幾次，如下：

upstream backend {
    server backend.example.com max_fails fail_timeout=30s;
    server backend.example.com max_fails fail_timeout=30s;
    server backend.example.com max_fails fail_timeout=30s;
}

4、備機策略

從 Nginx 的 0.6.7 版本開始，可以使用“backup”關鍵字。當所有的非備機（non-backup）都宕機（down）或者繁忙（busy）的時候，就只使用由 backup 標註的備機。必須要注意的是，backup 不能和 ip_hash 關鍵字一起使用。舉例如下：

upstream backend {
    server backend1.example.com;
    server backend2.example.com backup;
    server backend3.example.com;
}




Nginx 的 HttpUpstreamModule 提供對後端（backend）服務器的簡單負載均衡。一個最簡單的 upstream 寫法如下：

upstream backend {
    server backend1.example.com;
    server backend2.example.com;
    server.backend3.example.com;
}

server {
    location / {
        proxy_pass http://backend;
    }
}

1、後端服務器

通過 upstream 可以設定後端服務器，指定的方式可以是 IP 地址與端口、域名、UNIX 套接字（socket）。其中如果域名可以被解析爲多個地址，則這些地址都作爲 backend。下面舉例說明：

upstream backend {
    server blog.csdn.net/poechant;
    server 145.223.156.89:8090;
    server unix:/tmp/backend3;
}

第一個 backend 是用域名指定的。第二個 backend 是用 IP 和端口號指定的。第三個 backend 是用 UNIX 套接字指定的。

2、負載均衡策略

Nginx 提供輪詢（round robin）、用戶 IP 哈希（client IP）和指定權重 3 種方式。

默認情況下，Nginx 會爲你提供輪詢作爲負載均衡策略。但是這並不一定能夠讓你滿意。比如，某一時段內的一連串訪問都是由同一個用戶 Michael 發起的，那麼第一次 Michael 的請求可能是 backend2，而下一次是 backend3，然後是 backend1、backend2、backend3…… 在大多數應用場景中，這樣並不高效。當然，也正因如此，Nginx 爲你提供了一個按照 Michael、Jason、David 等等這些亂七八糟的用戶的 IP 來 hash 的方式，這樣每個 client 的訪問請求都會被甩給同一個後端服務器。具體的使用方式如下：

upstream backend {
    ip_hash;
    server backend1.example.com;
    server backend2.example.com;
    server.backend3.example.com;
}

這種策略中，用於進行 hash 運算的 key，是 client 的 C 類 IP 地址（C 類 IP 地址就是範圍在 192.0.0.0 到 223.255.255.255 之間，前三段號碼錶示子網，第四段號碼爲本地主機的 IP 地址類別）。這樣的方式保證一個 client 每次請求都將到達同一個 backend。當然，如果所 hash 到的 backend 當前不可用，則請求會被轉移到其他 backend。

再介紹一個和 ip_hash 配合使用的關鍵字：down。當某個一個 server 暫時性的宕機（down）時，你可以使用“down”來標示出來，並且這樣被標示的 server 就不會接受請求去處理。具體如下：

upstream backend {
    server blog.csdn.net/poechant down;
    server 145.223.156.89:8090;
    server unix:/tmp/backend3;
}

還可以使用指定權重（weight）的方式，如下：

upstream backend {
    server backend1.example.com;
    server 123.321.123.321:456 weight=4;
}

默認情況下 weight 爲 1，對於上面的例子，第一個 server 的權重取默認值 1，第二個是 4，所以相當於第一個 server 接收 20% 的請求，第二接收 80% 的。要注意的是 weight 與 ip_hash 是不能同時使用的，原因很簡單，他們是不同且彼此衝突的策略。

3、重試策略

可以爲每個 backend 指定最大的重試次數，和重試時間間隔。所使用的關鍵字是 max_fails 和 fail_timeout。如下所示：

upstream backend {
    server backend1.example.com weight=5;
    server 54.244.56.3:8081 max_fails=3 fail_timeout=30s;
}

在上例中，最大失敗次數爲 3，也就是最多進行 3 次嘗試，且超時時間爲 30秒。max_fails 的默認值爲 1，fail_timeout 的默認值是 10s。傳輸失敗的情形，由 proxy_next_upstream 或 fastcgi_next_upstream 指定。而且可以使用 proxy_connect_timeout 和 proxy_read_timeout 控制 upstream 響應時間。

有一種情況需要注意，就是 upstream 中只有一個 server 時，max_fails 和 fail_timeout 參數可能不會起作用。導致的問題就是 nginx 只會嘗試一次 upstream 請求，如果失敗這個請求就被拋棄了 : ( ……解決的方法，比較取巧，就是在 upstream 中將你這個可憐的唯一 server 多寫幾次，如下：

upstream backend {
    server backend.example.com max_fails fail_timeout=30s;
    server backend.example.com max_fails fail_timeout=30s;
    server backend.example.com max_fails fail_timeout=30s;
}

4、備機策略

從 Nginx 的 0.6.7 版本開始，可以使用“backup”關鍵字。當所有的非備機（non-backup）都宕機（down）或者繁忙（busy）的時候，就只使用由 backup 標註的備機。必須要注意的是，backup 不能和 ip_hash 關鍵字一起使用。舉例如下：

upstream backend {
    server backend1.example.com;
    server backend2.example.com backup;
    server backend3.example.com;
}

Nginx 的 HttpUpstreamModule 提供對後端（backend）服務器的簡單負載均衡。一個最簡單的 upstream 寫法如下：

upstream backend {
    server backend1.example.com;
    server backend2.example.com;
    server.backend3.example.com;
}

server {
    location / {
        proxy_pass http://backend;
    }
}

1、後端服務器

通過 upstream 可以設定後端服務器，指定的方式可以是 IP 地址與端口、域名、UNIX 套接字（socket）。其中如果域名可以被解析爲多個地址，則這些地址都作爲 backend。下面舉例說明：

upstream backend {
    server blog.csdn.net/poechant;
    server 145.223.156.89:8090;
    server unix:/tmp/backend3;
}

第一個 backend 是用域名指定的。第二個 backend 是用 IP 和端口號指定的。第三個 backend 是用 UNIX 套接字指定的。

2、負載均衡策略

Nginx 提供輪詢（round robin）、用戶 IP 哈希（client IP）和指定權重 3 種方式。

默認情況下，Nginx 會爲你提供輪詢作爲負載均衡策略。但是這並不一定能夠讓你滿意。比如，某一時段內的一連串訪問都是由同一個用戶 Michael 發起的，那麼第一次 Michael 的請求可能是 backend2，而下一次是 backend3，然後是 backend1、backend2、backend3…… 在大多數應用場景中，這樣並不高效。當然，也正因如此，Nginx 爲你提供了一個按照 Michael、Jason、David 等等這些亂七八糟的用戶的 IP 來 hash 的方式，這樣每個 client 的訪問請求都會被甩給同一個後端服務器。具體的使用方式如下：

upstream backend {
    ip_hash;
    server backend1.example.com;
    server backend2.example.com;
    server.backend3.example.com;
}

這種策略中，用於進行 hash 運算的 key，是 client 的 C 類 IP 地址（C 類 IP 地址就是範圍在 192.0.0.0 到 223.255.255.255 之間，前三段號碼錶示子網，第四段號碼爲本地主機的 IP 地址類別）。這樣的方式保證一個 client 每次請求都將到達同一個 backend。當然，如果所 hash 到的 backend 當前不可用，則請求會被轉移到其他 backend。

再介紹一個和 ip_hash 配合使用的關鍵字：down。當某個一個 server 暫時性的宕機（down）時，你可以使用“down”來標示出來，並且這樣被標示的 server 就不會接受請求去處理。具體如下：

upstream backend {
    server blog.csdn.net/poechant down;
    server 145.223.156.89:8090;
    server unix:/tmp/backend3;
}

還可以使用指定權重（weight）的方式，如下：

upstream backend {
    server backend1.example.com;
    server 123.321.123.321:456 weight=4;
}

默認情況下 weight 爲 1，對於上面的例子，第一個 server 的權重取默認值 1，第二個是 4，所以相當於第一個 server 接收 20% 的請求，第二接收 80% 的。要注意的是 weight 與 ip_hash 是不能同時使用的，原因很簡單，他們是不同且彼此衝突的策略。

3、重試策略

可以爲每個 backend 指定最大的重試次數，和重試時間間隔。所使用的關鍵字是 max_fails 和 fail_timeout。如下所示：

upstream backend {
    server backend1.example.com weight=5;
    server 54.244.56.3:8081 max_fails=3 fail_timeout=30s;
}

在上例中，最大失敗次數爲 3，也就是最多進行 3 次嘗試，且超時時間爲 30秒。max_fails 的默認值爲 1，fail_timeout 的默認值是 10s。傳輸失敗的情形，由 proxy_next_upstream 或 fastcgi_next_upstream 指定。而且可以使用 proxy_connect_timeout 和 proxy_read_timeout 控制 upstream 響應時間。

有一種情況需要注意，就是 upstream 中只有一個 server 時，max_fails 和 fail_timeout 參數可能不會起作用。導致的問題就是 nginx 只會嘗試一次 upstream 請求，如果失敗這個請求就被拋棄了 : ( ……解決的方法，比較取巧，就是在 upstream 中將你這個可憐的唯一 server 多寫幾次，如下：

upstream backend {
    server backend.example.com max_fails fail_timeout=30s;
    server backend.example.com max_fails fail_timeout=30s;
    server backend.example.com max_fails fail_timeout=30s;
}

4、備機策略

從 Nginx 的 0.6.7 版本開始，可以使用“backup”關鍵字。當所有的非備機（non-backup）都宕機（down）或者繁忙（busy）的時候，就只使用由 backup 標註的備機。必須要注意的是，backup 不能和 ip_hash 關鍵字一起使用。舉例如下：

upstream backend {
    server backend1.example.com;
    server backend2.example.com backup;
    server backend3.example.com;
}

Nginx 的 HttpUpstreamModule 提供對後端（backend）服務器的簡單負載均衡。一個最簡單的 upstream 寫法如下：

upstream backend {
    server backend1.example.com;
    server backend2.example.com;
    server.backend3.example.com;
}

server {
    location / {
        proxy_pass http://backend;
    }
}

1、後端服務器

通過 upstream 可以設定後端服務器，指定的方式可以是 IP 地址與端口、域名、UNIX 套接字（socket）。其中如果域名可以被解析爲多個地址，則這些地址都作爲 backend。下面舉例說明：

upstream backend {
    server blog.csdn.net/poechant;
    server 145.223.156.89:8090;
    server unix:/tmp/backend3;
}

第一個 backend 是用域名指定的。第二個 backend 是用 IP 和端口號指定的。第三個 backend 是用 UNIX 套接字指定的。

2、負載均衡策略

Nginx 提供輪詢（round robin）、用戶 IP 哈希（client IP）和指定權重 3 種方式。

默認情況下，Nginx 會爲你提供輪詢作爲負載均衡策略。但是這並不一定能夠讓你滿意。比如，某一時段內的一連串訪問都是由同一個用戶 Michael 發起的，那麼第一次 Michael 的請求可能是 backend2，而下一次是 backend3，然後是 backend1、backend2、backend3…… 在大多數應用場景中，這樣並不高效。當然，也正因如此，Nginx 爲你提供了一個按照 Michael、Jason、David 等等這些亂七八糟的用戶的 IP 來 hash 的方式，這樣每個 client 的訪問請求都會被甩給同一個後端服務器。具體的使用方式如下：

upstream backend {
    ip_hash;
    server backend1.example.com;
    server backend2.example.com;
    server.backend3.example.com;
}

這種策略中，用於進行 hash 運算的 key，是 client 的 C 類 IP 地址（C 類 IP 地址就是範圍在 192.0.0.0 到 223.255.255.255 之間，前三段號碼錶示子網，第四段號碼爲本地主機的 IP 地址類別）。這樣的方式保證一個 client 每次請求都將到達同一個 backend。當然，如果所 hash 到的 backend 當前不可用，則請求會被轉移到其他 backend。

再介紹一個和 ip_hash 配合使用的關鍵字：down。當某個一個 server 暫時性的宕機（down）時，你可以使用“down”來標示出來，並且這樣被標示的 server 就不會接受請求去處理。具體如下：

upstream backend {
    server blog.csdn.net/poechant down;
    server 145.223.156.89:8090;
    server unix:/tmp/backend3;
}

還可以使用指定權重（weight）的方式，如下：

upstream backend {
    server backend1.example.com;
    server 123.321.123.321:456 weight=4;
}

默認情況下 weight 爲 1，對於上面的例子，第一個 server 的權重取默認值 1，第二個是 4，所以相當於第一個 server 接收 20% 的請求，第二接收 80% 的。要注意的是 weight 與 ip_hash 是不能同時使用的，原因很簡單，他們是不同且彼此衝突的策略。

3、重試策略

可以爲每個 backend 指定最大的重試次數，和重試時間間隔。所使用的關鍵字是 max_fails 和 fail_timeout。如下所示：

upstream backend {
    server backend1.example.com weight=5;
    server 54.244.56.3:8081 max_fails=3 fail_timeout=30s;
}

在上例中，最大失敗次數爲 3，也就是最多進行 3 次嘗試，且超時時間爲 30秒。max_fails 的默認值爲 1，fail_timeout 的默認值是 10s。傳輸失敗的情形，由 proxy_next_upstream 或 fastcgi_next_upstream 指定。而且可以使用 proxy_connect_timeout 和 proxy_read_timeout 控制 upstream 響應時間。

有一種情況需要注意，就是 upstream 中只有一個 server 時，max_fails 和 fail_timeout 參數可能不會起作用。導致的問題就是 nginx 只會嘗試一次 upstream 請求，如果失敗這個請求就被拋棄了 : ( ……解決的方法，比較取巧，就是在 upstream 中將你這個可憐的唯一 server 多寫幾次，如下：

upstream backend {
    server backend.example.com max_fails fail_timeout=30s;
    server backend.example.com max_fails fail_timeout=30s;
    server backend.example.com max_fails fail_timeout=30s;
}

4、備機策略

從 Nginx 的 0.6.7 版本開始，可以使用“backup”關鍵字。當所有的非備機（non-backup）都宕機（down）或者繁忙（busy）的時候，就只使用由 backup 標註的備機。必須要注意的是，backup 不能和 ip_hash 關鍵字一起使用。舉例如下：

upstream backend {
    server backend1.example.com;
    server backend2.example.com backup;
    server backend3.example.com;
}
發表評論
所有評論
還沒有人評論，想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章

Dokcer部署Kafka集羣

docker網絡規劃 docker network create kafka-net --subnet 172.20.0.0/16 docker network ls zookeeper1（172.20.0.11 2184:2181

zer0black 2024-05-16 14:31:24

「Pygors跨平臺GUI」2：安裝MinGW-w64、MSYS2還是WSL2

「Pygors系列」一句話導讀： MinGW-w64只有編譯器，MSYS2帶着更新環境，WSL2實用性比較高   歷史與淵源     Windows平臺 Linux平臺 二進制兼容 WSL2：運行Linux程序 Wine：運行Wi

windfic 2024-05-16 14:29:14

「Pygors跨平臺GUI」1：Pygors跨平臺GUI應用研究

「Pygors系列」一句話導讀： Python、Go、Rust、C程序跨平臺GUI框架研究。   一、問題 Pygors是什麼？ Pygors是我自己創造的一個詞，就是Python、Go、Rust、C四種語言的合體。目的是爲了跨平臺GUI應

windfic 2024-05-16 14:29:14

【Linux命令學習】lsof查看打開的文件

lsof： list open files 作用1：可查端口號被哪個進程佔用 比如我們跑自動化，經常會遇到端口號被佔用，無法啓動driver lsof -i :8081 lsof 輸出的結果含義： fd：文件描述符的數字，通常是一個

金大鑫要堅持 2024-05-16 14:27:04

MacOS添加，查看，刪除用戶

1. 添加用戶 在macOS中，可以通過命令行使用dscl（Directory Service command line utility）工具來添加用戶。以下是使用dscl添加用戶的步驟： 打開終端：可以通過在Spotlight搜索中輸

金大鑫要堅持 2024-05-16 14:27:04

Flink執行圖

Flink的代碼編寫流程爲env->source->transform->sink，基本所有的代碼都是大致按照圖1的流程進行代碼編寫，當然中間也會有一些封裝之類的。   Flink代碼寫好後，它的任務調度執行圖按照生成順序分爲:邏輯流圖(

人不瘋狂枉一生 2024-05-16 14:23:03

Garnet：微軟官方基於.NET開源的高性能分佈式緩存存儲數據庫

前言 前不久Redis宣佈從 Redis 7.4 開始，將原先比較寬鬆的 BSD 源碼使用協議修改爲 RSALv2 和 SSPLv1 協議，該協議變化意味着Redis不再開源。今天給大家分享一款完全開源（MIT協議）、免費的Redis替代性

追逐時光 2024-05-16 14:22:03

nodejs學習07——API

接口 一、簡介 1.1 接口是什麼 接口是 前後端通信的橋樑 簡單理解：一個接口就是 服務中的一個路由規則 ，根據請求響應結果 接口的英文單詞是 API (Application Program Interface)，所以有時也稱之爲 AP

htj10 2024-05-16 14:21:53

nodejs學習06——小案例

記賬本  

htj10 2024-05-16 14:21:53

🔥 Java Solon v2.7.6 發佈

Java Solon 是什麼框架？ Java “新的”應用開發框架。開放原子開源基金會，孵化項目。從零開始構建（非 java-ee 架構），有靈活的接口規範與開放生態。 追求： 更快、更小、更簡單 提倡： 剋制、簡潔、高效、開放、生態

劉之西東 2024-05-16 14:21:13

Puppeteer！

什麼是Puppeteer Puppeteer 是一個由 Google 開發的 Node.js 庫，它提供了一組用於控制 Headless Chrome 的 API。 Headless Chrome 是 Chrome 瀏覽器的無界面版本，可以

CharyGao 2024-05-16 14:17:02

openstack虛擬機用keep alive添加的VIP，其它機器無法訪問

  neutron port-list |grep ipneutron port-update a7fbxxf6cc2 --allowed_address_pairs type=dict list=true ip_address=vipne

馬昌偉 2024-05-16 14:13:52

apisix~authz-keycloak插件介紹

參考：https://apisix.apache.org/docs/apisix/plugins/authz-keycloak/ kc插件源碼梳理及原理說明 如果只是進行keycloak頒發的token進行校驗（簽名校驗和有效期校驗），

張佔嶺 2024-05-16 14:12:42

Dynamic-Datasource動態數據源

1、添加請求對應的數據源標籤 DynamicDataSourceContextHolder.push(ds); 2、添加數據源    3、動態添加數據源 private DynamicRoutingDataSource dataSo

擾擾 2024-05-16 14:12:02

NETCore中實現一個輕量無負擔的極簡任務調度ScheduleTask

至於任務調度這個基礎功能,重要性不言而喻,大多數業務系統都會用到,世面上有很多成熟的三方庫比如Quartz,Hangfire,Coravel 這裏我們不討論三方的庫如何使用 而是從0開始自己製作一個簡易的任務調度,如果只是到分鐘級別的粒度基

萬雅虎 2024-05-16 14:04:41