nginx的upstream配置和作用是什么

配置例子

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; ??} }

指令

定義一組服務器。 這些服務器可以監聽不同的端口。 而且，監聽在tcp和unix域套接字的服務器可以混用。

例子：

upstream?backend?{ ??server?backend1.example.com?weight=5; ??server?127.0.0.1:8080????max_fails=3?fail_timeout=30s; ??server?unix:/tmp/backend3; }

默認情況下，nginx按加權輪轉的方式將請求分發到各服務器。 在上面的例子中，每7個請求會通過以下方式分發： 5個請求分到backend1.example.com， 一個請求分到第二個服務器，一個請求分到第三個服務器。 與服務器通信的時候，如果出現錯誤，請求會被傳給下一個服務器，直到所有可用的服務器都被嘗試過。 如果所有服務器都返回失敗，客戶端將會得到最后通信的那個服務器的（失敗）響應結果。

定義服務器的地址address和其他參數parameters。 地址可以是域名或者ip地址，端口是可選的，或者是指定“unix:”前綴的unix域套接字的路徑。如果沒有指定端口，就使用80端口。 如果一個域名解析到多個ip，本質上是定義了多個server。

你可以定義下面的參數：weight=number設定服務器的權重，默認是1。max_fails=number設定nginx與服務器通信的嘗試失敗的次數。在fail_timeout參數定義的時間段內，如果失敗的次數達到此值，nginx就認為服務器不可用。在下一個fail_timeout時間段，服務器不會再被嘗試。 失敗的嘗試次數默認是1。設為0就會停止統計嘗試次數，認為服務器是一直可用的。 你可以通過指令proxy_next_upstream、 fastcgi_next_upstream和memcached_next_upstream來配置什么是失敗的嘗試。 默認配置時，http_404狀態不被認為是失敗的嘗試。fail_timeout=time設定

• 統計失敗嘗試次數的時間段。在這段時間中，服務器失敗次數達到指定的嘗試次數，服務器就被認為不可用。

• 服務器被認為不可用的時間段。

默認情況下，該超時時間是10秒。backup標記為備用服務器。當主服務器不可用以后，請求會被傳給這些服務器。down標記服務器永久不可用，可以跟ip_hash指令一起使用。

example:

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:8080?backup; }

指定服務器組的負載均衡方法，請求基于客戶端的ip地址在服務器間進行分發。 ipv4地址的前三個字節或者ipv6的整個地址，會被用來作為一個散列key。 這種方法可以確保從同一個客戶端過來的請求，會被傳給同一臺服務器。除了當服務器被認為不可用的時候，這些客戶端的請求會被傳給其他服務器，而且很有可能也是同一臺服務器。

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

如果其中一個服務器想暫時移除，應該加上down參數。這樣可以保留當前客戶端ip地址散列分布。

例子：

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

從1.3.1和1.2.2版本開始，ip_hash的負載均衡方法才支持設置服務器權重值。

這個指令出現在版本 1.1.4.

激活對上游服務器的連接進行緩存。

connections參數設置每個worker進程與后端服務器保持連接的最大數量。這些保持的連接會被放入緩存。 如果連接數大于這個值時，最久未使用的連接會被關閉。

需要注意的是，keepalive指令不會限制nginx進程與上游服務器的連接總數。 新的連接總會按需被創建。 connections參數應該稍微設低一點，以便上游服務器也能處理額外新進來的連接。

配置memcached上游服務器連接keepalive的例子：

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”頭的值也應被清空。

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?""; ????... ??} }

另外一種選擇是，http/1.0協議的持久連接也可以通過發送“connection: keep-alive”頭來實現。不過不建議這樣用。

對于fastcgi的服務器，需要設置 fastcgi_keep_conn 指令來讓連接keepalive工作：

upstream?fastcgi_backend?{ ??server?127.0.0.1:9000;  ??keepalive?8; }  server?{ ??...  ??location?/fastcgi/?{ ????fastcgi_pass?fastcgi_backend; ????fastcgi_keep_conn?on; ????... ??} }

當使用的負載均衡方法不是默認的輪轉法時，必須在keepalive 指令之前配置。

針對scgi和uwsgi協議，還沒有實現其keepalive連接的打算。

這個指令出現在版本 1.3.1 和 1.2.2.

指定服務器組的負載均衡方法，根據其權重值，將請求發送到活躍連接數最少的那臺服務器。 如果這樣的服務器有多臺，那就采取有權重的輪轉法進行嘗試。

嵌入的變量

ngx_http_upstream_module模塊支持以下嵌入變量：

$upstream_addr保存服務器的ip地址和端口或者是unix域套接字的路徑。 在請求處理過程中，如果有多臺服務器被嘗試了，它們的地址會被拼接起來，以逗號隔開，比如： “192.168.1.1:80, 192.168.1.2:80, unix:/tmp/sock”。 如果在服務器之間通過“x-accel-redirect”頭或者error_page有內部跳轉，那么這些服務器組之間會以冒號隔開，比如：“192.168.1.1:80, 192.168.1.2:80, unix:/tmp/sock : 192.168.10.1:80, 192.168.10.2:80”。$upstream_response_time以毫秒的精度保留服務器的響應時間，（輸出）單位是秒。 出現多個響應時，也是以逗號和冒號隔開。$upstream_status保存服務器的響應代碼。 出現多個響應時，也是以逗號和冒號隔開。$upstream_http_…保存服務器的響應頭的值。比如“server”響應頭的值可以通過$upstream_http_server變量來獲取。 需要注意的是只有最后一個響應的頭會被保留下來。