具體可見 wiki.nginx.org
傳統上基於進程或線程模型架構的web服務通過每進程或每線程處理併發連接請求，這勢必會在網絡和I/O操作時產生阻塞，其另一個必然結果則是對內存或CPU的利用率低下。生成一個新的進程/線程需要事先備好其運行時環境，這包括爲其分配堆內存和棧內存，以及爲其創建新的執行上下文等。這些操作都需要佔用CPU，而且過多的進程/線程還會帶來線程抖動或頻繁的上下文切換，系統性能也會由此進一步下降。
在設計的最初階段，nginx的主要着眼點就是其高性能以及對物理計算資源的高密度利用，因此其採用了不同的架構模型。受啓發於多種操作系統設計中基於“事件”的高級處理機制，nginx採用了模塊化、事件驅動、異步、單線程及非阻塞的架構，並大量採用了多路複用及事件通知機制。在nginx中，連接請求由爲數不多的幾個僅包含一個線程的進程worker以高效的迴環(run-loop)機制進行處理，而每個worker可以並行處理數千個的併發連接及請求。
如果負載以CPU密集型應用爲主，如SSL或壓縮應用，則worker數應與CPU數相同；如果負載以IO密集型爲主，如響應大量內容給客戶端，則worker數應該爲CPU個數的1.5或2倍。
Nginx會按需同時運行多個進程：一個主進程(master)和幾個工作進程(worker)，配置了緩存時還會有緩存加載器進程(cache loader)和緩存管理器進程(cache manager)等。所有進程均是僅含有一個線程，並主要通過“共享內存”的機制實現進程間通信。主進程以root用戶身份運行，而worker、cache loader和cache manager均應以非特權用戶身份運行。
主進程主要完成如下工作：
1. 讀取並驗正配置信息；
2. 創建、綁定及關閉套接字；
3. 啓動、終止及維護worker進程的個數；
4. 無須中止服務而重新配置工作特性；
5. 控制非中斷式程序升級，啓用新的二進制程序並在需要時回滾至老版本；
6. 重新打開日誌文件，實現日誌滾動；
7. 編譯嵌入式perl腳本；
worker進程主要完成的任務包括：
1. 接收、傳入並處理來自客戶端的連接；
2. 提供反向代理及過濾功能；
3. nginx任何能完成的其它任務；
cache loader進程主要完成的任務包括：
1. 檢查緩存存儲中的緩存對象；
2. 使用緩存元數據建立內存數據庫；
cache manager進程的主要任務：
1. 緩存的失效及過期檢驗；
Nginx的配置有着幾個不同的上下文：main、http、server、upstream和location(還有實現郵件服務反向代理的mail)。配置語法的格式和定義方式遵循所謂的C風格，因此支持嵌套，還有着邏輯清晰並易於創建、閱讀和維護等優勢。
Nginx的代碼是由一個核心和一系列的模塊組成, 核心主要用於提供Web Server的基本功能，以及Web和Mail反向代理的功能；還用於啓用網絡協議，創建必要的運行時環境以及確保不同的模塊之間平滑地進行交互。不過，大多跟協議相關的功能和某應用特有的功能都是由nginx的模塊實現的。這些功能模塊大致可以分爲事件模塊、階段性處理器、輸出過濾器、變量處理器、協議、upstream和負載均衡幾個類別，這些共同組成了nginx的http功能。事件模塊主要用於提供OS獨立的(不同操作系統的事件機制有所不同)事件通知機制如kqueue或epoll等。協議模塊則負責實現nginx通過http、tls/ssl、smtp、pop3以及imap與對應的客戶端建立會話。
在nginx內部，進程間的通信是通過模塊的pipeline或chain實現的；換句話說，每一個功能或操作都由一個模塊來實現。例如，壓縮、通過FastCGI或uwsgi協議與upstream服務器通信，以及與memcached建立會話等。
nginx配置信息
main worker_process error_log etc.
http {} 關於http的配置信息
server {} 定義虛擬主機
location {} 關於location的另一篇博文http://reliable.blog.51cto.com/blog/10292844/1757210
2.1 配置main模塊
下面說明main模塊中的幾個關鍵參數。
2.1.1 error_log
用於配置錯誤日誌，可用於main、http、server及location上下文中；語法格式爲：
error_log file | stderr [ debug | info | notice | warn | error | crit | alert | emerg ]
如果在編譯nginx時使用了--with-debug選項，還可以使用如下格式打開調試功能。
error_log LOGFILE [debug_core | debug_alloc | debug_mutex | debug_event | debug_http | debug_imap];
要禁用錯誤日誌，不能使用“error_log off;”，而要使用類似如下選項：
error_log /dev/null crit;
2.1.2 timer_resolution
用於降低gettimeofday()系統調用的次數。默認情況下，每次從kevent()、epoll、/dev/poll、select()或poll()返回時都會執行此係統調用。語法格式爲：
timer_resolution interval
例如：
timer_resolution 100ms;
2.1.3 worker_cpu_affinity
通過sched_setaffinity()將worker綁定至CPU上，只能用於main上下文。語法格式爲：
worker_cpu_affinity cpumask ...
例如：
worker_processes 4;
worker_cpu_affinity 0001 0010 0100 1000;
2.1.4 worker_priority
爲worker進程設定優先級(指定nice值)，此參數只能用於main上下文中，默認爲0；語法格式爲：
worker_priority number
2.1.5 worker_processes
worker進程是單線程進程。如果Nginx用於CPU密集型的場景中，如SSL或gzip，且主機上的CPU個數至少有2個，那麼應該將此參數值設定爲與CPU核心數相同；如果Nginx用於大量靜態文件訪問的場景中，且所有文件的總大小大於可用內存時，應該將此參數的值設定得足夠大以充分利用磁盤帶寬。
此參數與Events上下文中的work_connections變量一起決定了maxclient的值：
maxclients = work_processes * work_connections
2.1.6 worker_rlimit_nofile
設定worker進程所能夠打開的文件描述符個數的最大值。語法格式：
worker_rlimit_nofile number
2.2 配置Events模塊
2.2.1 worker_connections
設定每個worker所處理的最大連接數，它與來自main上下文的worker_processes一起決定了maxclients的值。
max clients = worker_processes * worker_connections
而在反向代理場景中，其計算方法與上述公式不同，因爲默認情況下瀏覽器將打開2個連接，而nginx會爲每一個連接打開2個文件描述符，因此，其maxclients的計算方法爲：
max clients = worker_processes * worker_connections/4
2.2.2 use
在有着多於一個的事件模型IO的應用場景中，可以使用此指令設定nginx所使用的IO機制，默認爲./configure腳本選定的各機制中最適用當前OS的版本。語法格式：
use [ kqueue | rtsig | epoll | /dev/poll | select | poll | eventport ]
2.3 一個配置示例
user nginx;
# the load is CPU-bound and we have 16 cores
worker_processes 16;
error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;
events {
use epoll;
worker_connections 2048;
}
2.4 HTTP服務的相關配置
http上下文專用於配置用於http的各模塊，此類指令非常的多，每個模塊都有其專用指定，具體請參數nginx官方wiki關於模塊部分的說明。大體上來講，這些模塊所提供的配置指令還可以分爲如下幾個類別。
客戶端類指令：如client_body_buffer_size、client_header_buffer_size、client_header_timeout和keepalive_timeout等；
文件IO類指令：如aio、directio、open_file_cache、open_file_cache_min_uses、open_file_cache_valid和sendfile等；
hash類指令：用於定義Nginx爲某特定的變量分配多大的內存空間，如types_hash_bucket_size、server_names_hash_bucket_size和variables_hash_bucket_size等；
套接字類指令：用於定義Nginx如何處理tcp套接字相關的功能，如tcp_nodelay(用於keepalive功能啓用時)和tcp_nopush(用於sendfile啓用時)等；
2.5 虛擬服務器相關配置
server {
<directive> <parameters>;
}
用於定義虛擬服務器相關的屬性，常見的指令有backlog、rcvbuf、bind及sndbuf等。
2.6 location相關的配置
location [modifier] uri {...} 或 location @name {…}
通常用於server上下文中，用於設定某URI的訪問屬性。location可以嵌套。
The prefix "@" specifies a named location. Such locations are not used during normal processing of requests, they are intended only to process internally redirected requests (see error_page, try_files). 如下面關於memcached的相關配置。
server {
location / {
set $memcached_key $uri;
memcached_pass name:11211;
default_type text/html;
error_page 404 @fallback;
}
location @fallback {
proxy_pass http://backend;
}
}
三、Nginx反向代理
Nginx通過proxy模塊實現反向代理功能。在作爲web反向代理服務器時，nginx負責接收客戶請求，並能夠根據URI、客戶端參數或其它的處理邏輯將用戶請求調度至上游服務器上(upstream server)。nginx在實現反向代理功能時的最重要指令爲proxy_pass，它能夠將location定義的某URI代理至指定的上游服務器(組)上。如下面的示例中，location的/uri將被替換爲上游服務器上的/newuri。
location /uri {
proxy_pass http://www.magedu.com:8080/newuri;
}
不過，這種處理機制中有兩個例外。一個是如果location的URI是通過模式匹配定義的，其URI將直接被傳遞至上游服務器，而不能爲其指定轉換的另一個URI。例如下面示例中的/forum將被代理爲http://www.magedu.com/forum。
location ~ ^/bbs {
proxy_pass http://www.magedu.com;
}
第二個例外是，如果在loation中使用的URL重定向，那麼nginx將使用重定向後的URI處理請求，而不再考慮上游服務器上定義的URI。如下面所示的例子中，傳送給上游服務器的URI爲/index.php?page=<match>，而不是/index。
location / {
rewrite /(.*)$ /index.php?page=$1 break;
proxy_pass http://localhost:8080/index;
}
3.1 proxy模塊的指令
proxy模塊的可用配置指令非常多，它們分別用於定義proxy模塊工作時的諸多屬性，如連接超時時長、代理時使用http協議版本等。下面對常用的指令做一個簡單說明。
proxy_connect_timeout：nginx將一個請求發送至upstream server之前等待的最大時長；
proxy_cookie_domain：將upstream server通過Set-Cookie首部設定的domain屬性修改爲指定的值，其值可以爲一個字符串、正則表達式的模式或一個引用的變量；
proxy_cookie_path: 將upstream server通過Set-Cookie首部設定的path屬性修改爲指定的值，其值可以爲一個字符串、正則表達式的模式或一個引用的變量；
proxy_hide_header：設定發送給客戶端的報文中需要隱藏的首部；
proxy_pass：指定將請求代理至upstream server的URL路徑；
proxy_set_header：將發送至upsream server的報文的某首部進行重寫；
proxy_redirect：重寫location並刷新從upstream server收到的報文的首部；
proxy_send_timeout：在連接斷開之前兩次發送至upstream server的寫操作的最大間隔時長；
proxy_read_timeout：在連接斷開之前兩次從接收upstream server接收讀操作的最大間隔時長；
如下面的一個示例：
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr; 注意Realserver中LogFormat中記錄的access_log要在前面添加
%{X-Real-IP}i
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size 10m;
client_body_buffer_size 128k;
proxy_connect_timeout 30;
proxy_send_timeout 15;
proxy_read_timeout 15;
3.2 upstream模塊
與proxy模塊結合使用的模塊中，最常用的當屬upstream模塊。upstream模塊可定義一個新的上下文，它包含了一組包括upstream服務器，這些服務器可能被賦予了不同的權重、不同的類型甚至可以基於維護等原因被標記爲down。
upstream模塊常用的指令有：
ip_hash：基於客戶端IP地址完成請求的分發，它可以保證來自於同一個客戶端的請求始終被轉發至同一個upstream服務器；
keepalive：每個worker進程爲發送到upstream服務器的連接所緩存的個數；
least_conn：最少連接調度算法；
server：定義一個upstream服務器的地址，還可包括一系列可選參數，如：
weight：權重；
max_fails：最大失敗連接次數，失敗連接的超時時長由fail_timeout指定；
fail_timeout：等待請求的目標服務器發送響應的時長；
backup：用於fallback的目的，所有服務均故障時才啓動此服務器；
down：手動標記其不再處理任何請求；
例如：
upstream backend {
server www.magedu.com weight=5;前面一定不能加http://
server www2.magedu.com:8080 max_fails=3 fail_timeout=30s;
}
upstream模塊的負載均衡算法主要有三種，輪調(round-robin)、ip哈希(ip_hash)和最少連接(least_conn)三種。
此外，upstream模塊也能爲非http類的應用實現負載均衡，如下面的示例定義了nginx爲memcached服務實現負載均衡之目的。
upstream memcachesrvs {
server 172.16.100.6:11211;
server 172.16.100.7:11211;
}
server {
location / {
set $memcached_key "$uri?$args";
memcached_pass memcachesrvs;
error_page 404 = @fallback;
}
location @fallback {
proxy_pass http://127.0.0.1:8080;
}
}
3.3 if判斷語句
在location中使用if語句可以實現條件判斷，其通常有一個return語句，且一般與有着last或break標記的rewrite規則一同使用。但其也可以按需要使用在多種場景下，需要注意的是，不當的使用可能會導致不可預料的後果。
location / {
if ($request_method == “PUT”) {
proxy_pass http://upload.magedu.com:8080;
}
if ($request_uri ~ "\.(jpg|gif|jpeg|png)$") {
proxy_pass http://p_w_picpathservers;
break;
}
}
upstream p_w_picpathservers {
server 172.16.100.8:80 weight 2;
server 172.16.100.9:80 weight 3;
}
3.3.1 if語句中的判斷條件
正則表達式匹配：
~：與指定正則表達式模式匹配時返回“真”，判斷匹配與否時區分字符大小寫；
~*：與指定正則表達式模式匹配時返回“真”，判斷匹配與否時不區分字符大小寫；
!~：與指定正則表達式模式不匹配時返回“真”，判斷匹配與否時區分字符大小寫；
!~*：與指定正則表達式模式不匹配時返回“真”，判斷匹配與否時不區分字符大小寫；
文件及目錄匹配判斷：
-f, !-f：判斷指定的路徑是否爲存在且爲文件；
-d, !-d：判斷指定的路徑是否爲存在且爲目錄；
-e, !-e：判斷指定的路徑是否存在，文件或目錄均可；
-x, !-x：判斷指定路徑的文件是否存在且可執行；
3.3.2 nginx常用的全局變量
下面是nginx常用的全局變量中的一部分，它們經常用於if語句中實現條件判斷。
$args
$content_length
$content_type
$document_root
$document_uri
$host
$http_user_agent
$http_cookie
$limit_rate
$request_body_file
$request_method
$remote_addr
$remote_port
$remote_user
$request_filename
$request_uri
$query_string
$scheme
$server_protocol
$server_addr
$server_name
$server_port
$uri
四、反向代理性能優化
在反向代理場景中，nginx有一系列指令可用於定義其工作特性，如緩衝區大小等，給這些指令設定一個合理的值，可以有效提升其性能。
4.1 緩衝區設定
nginx在默認情況下在將其響應給客戶端之前會儘可能地接收來upstream服務器的響應報文，它會將這些響應報文存暫存於本地並儘量一次性地響應給客戶端。然而，在來自於客戶端的請求或來自upsteam服務器的響應過多時，nginx會試圖將之存儲於本地磁盤中，這將大大降低nginx的性能。因此，在有着更多可用內存的場景中，應該將用於暫存這些報文的緩衝區調大至一個合理的值。
proxy_buffer_size size：設定用於暫存來自於upsteam服務器的第一個響應報文的緩衝區大小；
proxy_buffering on|off：啓用緩衝upstream服務器的響應報文，否則，如果proxy_max_temp_file_size指令的值爲0，來自upstream服務器的響應報文在接收到的那一刻將同步發送至客戶端；一般情況下，啓用proxy_buffering並將proxy_max_temp_file_size設定爲0能夠啓用緩存響應報文的功能，並能夠避免將其緩存至磁盤中；
proxy_buffers 8 4k|8k：用於緩衝來自upstream服務器的響應報文的緩衝區大小；
4.2 緩存
nginx做爲反向代理時，能夠將來自upstream的響應緩存至本地，並在後續的客戶端請求同樣內容時直接從本地構造響應報文。
proxy_cache zone|off：定義一個用於緩存的共享內存區域，其可被多個地方調用；緩存將遵從upstream服務器的響應報文首部中關於緩存的設定，如 "Expires"、"Cache-Control: no-cache"、 "Cache-Control: max-age=XXX"、"private"和"no-store" 等，但nginx在緩存時不會考慮響應報文的"Vary"首部。爲了確保私有信息不被緩存，所有關於用戶的私有信息可以upstream上通過"no-cache" or "max-age=0"來實現，也可在nginx設定proxy_cache_key必須包含用戶特有數據如$cookie_xxx的方式實現，但最後這種方式在公共緩存上使用可能會有風險。因此，在響應報文中含有以下首部或指定標誌的報文將不會被緩存。
Set-Cookie
Cache-Control containing "no-cache", "no-store", "private", or a "max-age" with a non-numeric or 0 value
Expires with a time in the past
X-Accel-Expires: 0
proxy_cache_key：設定在存儲及檢索緩存時用於“鍵”的字符串，可以使用變量爲其值，但使用不當時有可能會爲同一個內容緩存多次；另外，將用戶私有信息用於鍵可以避免將用戶的私有信息返回給其它用戶；
proxy_cache_lock：啓用此項，可在緩存未命令中阻止多個相同的請求同時發往upstream，其生效範圍爲worker級別；
proxy_cache_lock_timeout：proxy_cache_lock功能的鎖定時長；
proxy_cache_min_uses：某響應報文被緩存之前至少應該被請求的次數；
proxy_cache_path：定義一個用記保存緩存響應報文的目錄，及一個保存緩存對象的鍵及響應元數據的共享內存區域(keys_zone=name:size)，其可選參數有：
levels：每級子目錄名稱的長度，有效值爲1或2，每級之間使用冒號分隔，最多爲3級；
inactive：非活動緩存項從緩存中剔除之前的最大緩存時長；
max_size：緩存空間大小的上限，當需要緩存的對象超出此空間限定時，緩存管理器將基於LRU算法對其進行清理；
loader_files：緩存加載器(cache_loader)的每次工作過程最多爲多少個文件加載元數據；
loader_sleep：緩存加載器的每次迭代工作之後的睡眠時長；
loader_threashold：緩存加載器的最大睡眠時長；
例如： proxy_cache_path /data/nginx/cache/one levels=1 keys_zone=one:10m;
proxy_cache_path /data/nginx/cache/two levels=2:2 keys_zone=two:100m;
proxy_cache_path /data/nginx/cache/three levels=1:1:2 keys_zone=three:1000m;
proxy_cache_use_stale：在無法聯繫到upstream服務器時的哪種情形下(如error、timeout或http_500等)讓nginx使用本地緩存的過期的緩存對象直接響應客戶端請求；其格式爲：
proxy_cache_use_stale error | timeout | invalid_header | updating | http_500 | http_502 | http_503 | http_504 | http_404 | off
proxy_cache_valid [ code ...] time：用於爲不同的響應設定不同時長的有效緩存時長，例如：proxy_cache_valid 200 302 10m;
proxy_cache_methods [GET HEAD POST]：爲哪些請求方法啓用緩存功能；
proxy_cache_bypass string：設定在哪種情形下，nginx將不從緩存中取數據；例如：
proxy_cache_bypass $cookie_nocache $arg_nocache $arg_comment;
proxy_cache_bypass $http_pragma $http_authorization;
4.2.1 使用示例
http {
proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=STATIC:10m
inactive=24h max_size=1g;
server {
location / {
proxy_pass http://www.magedu.com;
proxy_set_header Host $host;
proxy_cache STATIC;
proxy_cache_valid 200 1d;
proxy_cache_valid 301 302 10m;
proxy_cache_vaild any 1m;
proxy_cache_use_stale error timeout invalid_header updating
http_500 http_502 http_503 http_504;
}
}
}
4.3 壓縮
nginx將響應報文發送至客戶端之前可以啓用壓縮功能，這能夠有效地節約帶寬，並提高響應至客戶端的速度。通常編譯nginx默認會附帶gzip壓縮的功能，因此，可以直接啓用之。
http {
gzip on;
gzip_http_version 1.0;
gzip_comp_level 2;
gzip_types text/plain text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript application/json;
gzip_disable msie6;
}
gzip_proxied指令可以定義對客戶端請求哪類對象啓用壓縮功能，如“expired”表示對由於使用了expire首部定義而無法緩存的對象啓用壓縮功能，其它可接受的值還有“no-cache”、“no-store”、“private”、“no_last_modified”、“no_etag”和“auth”等，而“off”則表示關閉壓縮功能。
五、配置示例
5.1 反向代理
server {
listen 80;
server_name www.magedu.com;
add_header X-Via $server_addr;
location / {
root html;
index index.html index.htm;
if ($request_method ~* "PUT") {
proxy_pass http://172.16.100.12;
break;
}
}
location /bbs {
proxy_pass http://172.16.100.11/;
}
}
此例中，對http://www.magedu.com/bbs/的請求將被轉發至http://172.16.100.11/這個URL，切記最後的/不應該省去；而/匹配的URL中請求方法爲“PUT”時，將被轉發至http://172.16.100.12/這個URL。
另外，add_header用於讓nginx在響應給用戶的報文中構造自定義首部，其使用格式爲“add_header NAME VALUE”。
可以使用curl命令對配置好的服務進行請求，以驗正其效果。如：
# curl -I http://www.magedu.com/bbs/
HTTP/1.1 200 OK
Server: nginx/1.4.1
Date: Tue, 14 May 2013 10:19:10 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 15
Connection: keep-alive
Last-Modified: Tue, 30 Apr 2013 09:34:09 GMT
ETag: "186e9f-f-b4076640"
X-Via: 172.16.100.107
Accept-Ranges: bytes
在後端服務器172.16.100.12上裝載dav模塊，並開放其dav功能，而後驗正文件上傳效果。開放dav功能的方法如下：
首先啓用如下兩個模塊：
LoadModule dav_module modules/mod_dav.so
LoadModule dav_fs_module modules/mod_dav_fs.so
而後配置相應主機的目錄如下所示，關鍵是其中的dav一行。
<Directory "/var/www/html">
dav on
Options Indexes FollowSymLinks
Order allow,deny
Allow from all
</Directory>
接着嘗試訪問代理服務器：
# curl -I -T /etc/inittab http://www.magedu.com/
HTTP/1.1 100 Continue
HTTP/1.1 201 Created
Server: nginx/1.4.1
Date: Tue, 14 May 2013 10:20:15 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 261
Location: http://172.16.100.107/inittab
Connection: keep-alive
X-Via: 172.16.100.107
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>201 Created</title>
</head><body>
<h1>Created</h1>
<p>Resource /inittab has been created.</p>
<hr />
<address>Apache/2.2.3 (Red Hat) Server at 172.16.100.12 Port 80</address>
</body></html>
5.2 啓用緩存
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
proxy_cache_path /nginx/cache/first levels=1:2 keys_zone=first:10m max_size=512m;
server {
listen 80;
server_name www.magedu.com;
location / {
root html;
index index.html index.htm;
if ($request_method ~* "PUT") {
proxy_pass http://172.16.100.12;
break;
}
}
location /bbs {
proxy_pass http://172.16.100.11/;
proxy_cache first;
proxy_cache_valid 200 1d;
proxy_cache_valid 301 302 10m;
proxy_cache_valid any 1m;
}
}
}
5.3 使用upstream
5.3.1 不啓用緩存
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
upstream websrv {
server 172.16.100.11 weight=1;
server 172.16.100.12 weight=1;
server 127.0.0.1:8080 backup;
}
server {
listen 80;
server_name www.magedu.com;
add_header X-Via $server_addr;
location / {
proxy_pass http://websrv;
index index.html index.htm;
if ($request_method ~* "PUT") {
proxy_pass http://172.16.100.12;
break;
}
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
server {
listen 8080;
server_name localhost;
root /nginx/htdocs;
index index.html;
}
}
測試效果：默認情況下，nginx對定義了權重的upstream服務器使用加權輪調的方法調度訪問，因此，其多次訪問應該由不同的服務器進行響應。如下所示。
# curl http://172.16.100.107/
RS2.magedu.com
# curl http://172.16.100.107/
RS1.magedu.com
根據上面的配置，如果172.16.100.11和172.16.100.12兩個upstream服務器均宕機時，將由本地監聽在8080端口的虛擬主機進行響應。
# curl http://172.16.100.107/
Sorry...
5.3.2 爲upstream啓用緩存
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
proxy_cache_path /nginx/cache/first levels=1:2 keys_zone=first:10m max_size=512m;
upstream websrv {
server 172.16.100.11 weight=1;
server 172.16.100.12 weight=1;
server 127.0.0.1:8080 backup;
}
server {
listen 80;
server_name www.magedu.com;
add_header X-Via $server_addr;
add_header X-Cache-Status $upstream_cache_status;
location / {
proxy_pass http://websrv;
proxy_cache first;
proxy_cache_valid 200 1d;
proxy_cache_valid 301 302 10m;
proxy_cache_valid any 1m;
index index.html index.htm;
if ($request_method ~* "PUT") {
proxy_pass http://172.16.100.12;
break;
}
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
server {
listen 8080;
server_name localhost;
root /nginx/htdocs;
index index.html;
}
}
第一次訪問某可緩存資源時，在本地緩存中尚未有其對應的緩存對象，因此，其一定爲未命中狀態。而第二次請求時，則可以直接從本地緩存構建響應報文。
# curl -I http://www.magedu.com/
HTTP/1.1 200 OK
Server: nginx/1.4.1
Date: Tue, 14 May 2013 10:53:07 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 15
Connection: keep-alive
Last-Modified: Tue, 30 Apr 2013 09:34:09 GMT
ETag: "186e9f-f-b4076640"
Accept-Ranges: bytes
X-Via: 172.16.100.107
X-Cache-Status: MISS
# curl -I http://www.magedu.com/
HTTP/1.1 200 OK
Server: nginx/1.4.1
Date: Tue, 14 May 2013 10:53:09 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 15
Connection: keep-alive
Last-Modified: Tue, 30 Apr 2013 09:34:09 GMT
ETag: "186e9f-f-b4076640"
X-Via: 172.16.100.107
X-Cache-Status: HIT
Accept-Ranges: bytes