nginx 做反向代理時，后端主機有多臺，可以使用 upstream 定義一個后端主機池，在反向代理時直接使用主機池的名字。在 upstream 中可以定義負載均衡調(diào)度算法，權(quán)重，健康狀態(tài)檢測等參數(shù)。

例如：

upstream backend {
  server 172.16.0.1:80 weight=1 max-fails=3 fail_timeout=10;
  server 172.16.0.2:80 weight=1max-fails=3 fail_timeout=10;;
}

默認請求下，使用 round-robin 調(diào)度算法，并有健康狀態(tài)檢查和恢復主機的能力。

ningx 還可以使用這些算法：

•     ip_hash：基于源地址哈希，主要目的是會話保持
•     least_conn：基于最少活動連接進行調(diào)度
•     sticky：基于 cookie 進行會話綁定，nginx 會在客戶端第一次訪問時插入路由信息到 cookie 中，或者選擇 cookie 中的某個字段的值作為鍵，以后每次請求將基于此信息進行調(diào)度

基于 cookie 的會話綁定共有 cookie，route 和 learn 三種。

例如，基于 cookie name 的調(diào)度：

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

  sticky cookie srv_id expires=1h domain=.example.com path=/;
}

使用此主機組進行反向代理：

location / {
  proxy_pass http://backend;
  proxy_set_header Host $host;
  proxy_set_haeder X-Forwared-For $proxy_add_x_forwarded_for;
}

proxy_pass URL 指定代理的后端主機，可以指定 "http" 或 "https" 協(xié)議，域名可以是 ip 地址，也可以是 upstream 池名字

•     如果代理指定的是一個 URI 地址，如 http://127.0.0.1/remote，那么將直接被代理至指定 URI，無論請求的 URI 是什么
•     如果代理指定的一個主機而沒有 URI，如 http://127.0.0.1，客戶端請求的URI將被傳遞至指定域名
•     如果 location 中使用模式匹配 url，那么 url 也會被傳遞至代理 URL 的末端
•     如果 location 中使用了 URI 重寫，那么 proxy_pass 會使用重寫后的結(jié)果進行處理

proxy_set_header HEADER VALUE 對轉(zhuǎn)發(fā)的報文首部進行修改一些

反向代理時的緩存相關(guān)設(shè)定

proxy_cache_path PATH [levels=levels] keys_zone=NAME:SIZE

定義磁盤緩存路徑，nignx 的緩存是以鍵值方式存放的，keys_zone 用于指定鍵存放的內(nèi)存空間名字和大小，對應的值則存放在 PATH 指定的路徑中。levels 可以指定緩存存放路徑的級數(shù)和名稱字符數(shù)。此設(shè)置只能在 http 段中定義。

如：

proxy_cache_path /var/cache/nginx/proxy levels=1:2 keys_zone=one:10m;

proxy_cache_valid [code ...] time 指定不同響應碼的內(nèi)容的緩存時間

如：

proxy_cache_valid 200 302 10m;
proxy_cache_valid 404   1m;
proxy_cache_valid any   1m;

proxy_cache_method METHOD 定義哪些方法的請求結(jié)果可以被緩存，如：

proxy_cache_method GET;
proxy_cache_method HEAD;

proxy_cache NAME 指定使用預先定義的緩存空間用于緩存

一些問題的解決方法

下面來看看采用Nginx負載均衡之后碰到的問題：

通常解決服務器負載問題，都會通過多服務器分載來解決。常見的解決方案有：

那我們看看Nginx是如何實現(xiàn)負載均衡的，Nginx的upstream目前支持以下幾種方式的分配
1、輪詢（默認）
每個請求按時間順序逐一分配到不同的后端服務器，如果后端服務器down掉，能自動剔除。
2、weight
指定輪詢幾率，weight和訪問比率成正比，用于后端服務器性能不均的情況。
2、ip_hash
每個請求按訪問ip的hash結(jié)果分配，這樣每個訪客固定訪問一個后端服務器，可以解決session的問題。
3、fair（第三方）
按后端服務器的響應時間來分配請求，響應時間短的優(yōu)先分配。
4、url_hash（第三方）
按訪問url的hash結(jié)果來分配請求，使每個url定向到同一個后端服務器，后端服務器為緩存時比較有效。

Upstream配置如何實現(xiàn)負載  

http {  
  
  upstream www.test1.com {
     ip_hash;
     server  172.16.125.76:8066 weight=10;
     server  172.16.125.76:8077 down;
     server  172.16.0.18:8066 max_fails=3 fail_timeout=30s;
     server  172.16.0.18:8077 backup;
   }
   
   upstream www.test2.com {
     server  172.16.0.21:8066;
     server  192.168.76.98:8066;     
   }


   server {
    listen    80;
    server_name www.test1.com;    
    
    location /{
      proxy_pass    http://www.test1.com;
      proxy_set_header  Host       $host;
      proxy_set_header  X-Real-IP    $remote_addr;
      proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
    }   
   } 
   
   server {
    listen    80;
    server_name www.test2.com;    
    
    location /{
      proxy_pass    http://www.test2.com;
      proxy_set_header  Host       $host;
      proxy_set_header  X-Real-IP    $remote_addr;
      proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
   }
}

當有請求到www.test1.com/www.test2.com 時請求會被分發(fā)到對應的upstream設(shè)置的服務器列表上。test2的每一次請求分發(fā)的服務器都是隨機的，就是第一種情況列舉的。而test1剛是根據(jù)來訪問ip的hashid來分發(fā)到指定的服務器，也就是說該IP的請求都是轉(zhuǎn)到這個指定的服務器上。

根據(jù)服務器的本身的性能差別及職能，可以設(shè)置不同的參數(shù)控制。

down 表示負載過重或者不參與負載

weight 權(quán)重過大代表承擔的負載就越大

backup 其它服務器時或down時才會請求backup服務器

max_fails 失敗超過指定次數(shù)會暫?；蛘埱筠D(zhuǎn)往其它服務器

fail_timeout 失敗超過指定次數(shù)后暫停時間

以上就Nginx的負載均衡的簡單配置。那繼續(xù)我們的本節(jié)討論內(nèi)容：

一、Session問題

當我們確定一系列負載的服務器后，那我們的WEB站點會分布到這些服務器上。這個時候如果采用Test2 每一次請求隨機訪問任何一臺服務器上，這樣導致你訪問A服務器后，下一次請求又突然轉(zhuǎn)到B服務器上。這個時候與A服務器建立的Session，傳到B站點服務器肯定是無法正常響應的。我們看一下常用的解決方案：

• Session或憑據(jù)緩存到獨立的服務器
• Session或憑據(jù)保存數(shù)據(jù)庫中
• nginx ip_hash 保持同一IP的請求都是指定到固定的一臺服務器

第一種緩存的方式比較理想，緩存的效率也比較高。但是每一臺請求服務器都去訪問Session會話服務器，那不是加載重了這臺Session服務器的負擔嗎？

第二種保存到數(shù)據(jù)庫中，除了要控制Session的有效期，同時加重了數(shù)據(jù)庫的負擔，所以最終的轉(zhuǎn)變?yōu)镾QL Server 負載均衡，涉及讀，寫，過期，同步。

第三種通過nginx ip_hash負載保持對同一服務器的會話，這種看起來最方便，最輕量。

正常情況下架構(gòu)簡單的話， ip_hash可以解決Session問題，但是我們來看看下面這種情況

這個時候ip_hash 收到的請求都是來自固定IP代理的請求，如果代理IP的負載過高就會導致ip_hash對應的服務器負載壓力過大，這樣ip_hash就失去了負載均衡的作用了。

如果緩存可以實現(xiàn)同步共享的話，我們可以通過多session服務器來解決單一負載過重的問題。那Memcached是否可以做Session緩存服務器呢？MemcachedProvider提供了Session的功能，即將Session保存到數(shù)據(jù)庫中。那為什么不直接保存到數(shù)據(jù)庫中，而要通過Memcached保存到數(shù)據(jù)庫中呢？很簡單，如果直接保存到數(shù)據(jù)庫中，每一次請求Session有效性都要回數(shù)據(jù)庫驗證一下。其次，即使我們?yōu)閿?shù)據(jù)庫建立一層緩存，那這個緩存也無法實現(xiàn)分布式共享，還是針對同一臺緩存服務器負載過重。網(wǎng)上也看到有用Memcached實現(xiàn)Session緩存的成功案例，當然數(shù)據(jù)庫方式實現(xiàn)的還是比較常用的，比如開源Disuz.net論壇。緩存實現(xiàn)的小范圍分布式也是比較常用的，比如單點登錄也是一種特殊情況。

二、文件上傳下載

如果實現(xiàn)了負載均衡，除了Session問題，我們還會碰到文件的上傳下載問題。文件不可能上傳不同的服務器上，這樣會導致下載不到對應文件的問題。我們看一下下面的方案

1. 獨立文件服務器 
2. 文件壓縮數(shù)據(jù)庫

兩種方案都是常用的，我們來說一下文件壓縮數(shù)據(jù)庫，以前的方式都是將文件二進制壓縮至關(guān)系型數(shù)據(jù)庫，而現(xiàn)在NOSQL的流行，加上MongoDB處理文件又比較方便，所以文件壓庫又多了一種選擇。畢竟文件服務器的效率和管理以及安全都不及數(shù)據(jù)庫。

隨便聊聊這點事，其實也就是一些應用的趨勢和多一種解決方案的實現(xiàn)。