Nginx的反向代理模塊Upstream，可以實現集羣的負載均衡功能，假設後端有三個服務節點，用於提供Web服務，通過Nginx的調度實現三個節點的負載均衡。
一、Nginx配置
http
{
upstream tshare365{
server 192.168.12.181:80 weight=1 max_fails=3 fail_timeout=20s;
server 192.168.12.182:80 weight=1 max_fails=3 fail_timeout=20s;
server 192.168.12.183:80 weight=1 max_fails=3 fail_timeout=20s;
}
server
{
listen 80;
server_name www.tshare365.com;
index index.htm index.html;
root /web/www;
location / {
proxy_pass http://tshare365; #如果後端的服務器返回500、502、503、執行超時等錯誤，自動將請求轉發到upstream負載均衡池中的另一臺服務器，實現故障轉移。 proxy_next_upstream http_500 http_502 http_503 error timeout invalid_header;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;
proxy_buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
}
}
}二、配置文件參數解釋
Nginx的代理功能是通過http proxy模塊來實現的。默認在安裝Nginx時已經安裝了http proxy模塊因此可直接使用http proxy模塊。
proxy_set_header：設置由後端的服務器獲取用戶的主機名或者真實IP地址，以及代理者的真實IP地址。
client_body_buffer_size：用於指定客戶端請求主體緩衝區大小，可以理解爲先保存到本地再傳給用戶。
proxy_connect_timeout：表示與後端服務器連接的超時時間，即發起握手等候響應的超時時間。
proxy_send_timeout：表示後端服務器的數據回傳時間，即在規定時間之內後端服務器必須傳完所有的數據，否則，Nginx將斷開這個連接。
proxy_read_timeout：設置Nginx從代理的後端服務器獲取信息的時間，表示連接建立成功後，Nginx等待後端服務器的響應時間，其實是Nginx已經進入後端的排隊之中等候處理的時間。
proxy_buffer_size：設置緩衝區大小， 默認,該緩衝區大小等於指令proxy_buffers設置的大小。
proxy_buffers：設置緩衝區的數量和大小。nginx從代理的後端服務器獲取的響應信息，會放置到緩衝區。
proxy_busy_buffers_size：用於設置系統很忙時可以使用的proxy_buffers大小，官方推薦的大小爲proxy_buffers*2。
proxy_temp_file_write_size：指定proxy緩存臨時文件的大小。
三、Nginx常用調度算法
提供輪詢（round robin）、用戶 IP 哈希（client IP）和指定權重 3 種方式
默認情況下，Nginx 會爲你提供輪詢作爲負載均衡策略。例如，某一時段內的一連串訪問都是由同一個用戶 Michael 發起的，那麼第一次 Michael 的請求可能是 backend2，而下一次是 backend3，然後是 backend1、backend2、backend3…… 在大多數應用場景中，這樣並不高效。當然，也正因如此，Nginx 爲你提供了一個按照 Michael、Jason、David 等等這些亂七八糟的用戶的 IP 來 hash 的方式，這樣每個 client 的訪問請求都會被甩給同一個後端服務器。這樣可以解決session共享的問題。具體的使用方式如下：
upstream backend {
ip_hash;
server backend1.example.com;
server backend2.example.com;
server.backend3.example.com;
}這種策略中，用於進行 hash 運算的 key。這樣的方式保證一個 client 每次請求都將到達同一個 backend。當然，如果所 hash 到的 backend 當前不可用，則請求會被轉移到其他 backend。
再介紹一個和 ip_hash 配合使用的關鍵字：down。當某個一個 server 暫時性的宕機（down）時，你可以使用“down”來標示出來，並且這樣被標示的 server 就不會接受請求去處理。具體如下：
upstream backend {
ip_hash;
server backend1.example.com down;
server backend2.example.com;
server.backend3.example.com;
}還可以使用指定權重（weight）的方式，如下：
upstream tshare365{
server 192.168.12.181:80 weight=1
server 192.168.12.182:80 weight=4
}默認情況下 weight 爲 1，對於上面的例子，第一個 server 的權重取默認值 1，第二個是 4，所以相當於第一個 server 接收 20% 的請求，第二接收 80% 的。要注意的是 weight 與 ip_hash 是不能同時使用的，原因很簡單，他們是不同且彼此衝突的策略。
可以爲每個 backend 指定最大的重試次數，和重試時間間隔。所使用的關鍵字是 max_fails 和 fail_timeout,這裏注意了，這個健康狀態監測並不能保證nginx後端代理服務的可用性，因爲它只是監測後端服務的端口號，如果服務僵死了，那麼還是會把請求轉發過去，這樣我們客戶端訪問就會出現錯誤，正對這個問題，我們可以使用Nginx的第三方模塊 nginx_upstream_check_module 來解決這個問題，這個模塊的安裝與使用放到我們後面的文章中講解 也就是我們上面的例子。
最大失敗次數爲 3，也就是最多進行 3 次嘗試，且超時時間爲 20秒
從 Nginx 的 0.6.7 版本開始，可以使用“backup”關鍵字。當所有的非備機（non-backup）都宕機（down）或者繁忙（busy）的時候，就只使用由 backup 標註的備機。必須要注意的是，backup 不能和 ip_hash 關鍵字一起使用。舉例如下：
upstream tshare365{
server 192.168.12.181:80 weight=1 max_fails=3 fail_timeout=20s;
server 192.168.12.182:80 weight=1 max_fails=3 fail_timeout=20s;
server 192.168.12.183:80 backup;
}