nginx（一） nginx詳解
nginx是一個被廣泛使用的集羣架構組件，我們有必要對它有足夠的瞭解。下面將先認識nginx：包括應用場景、nginx基本架構、功能特性、併發模型以及配置說明，最後我們再總結下，爲什麼選擇nginx的原因。
1、nginx應用
nginx （engine x）是一個可以作爲HTTP WEB服務器、反向代理服務器、郵件代理服務器和一個通用的TCP / UDP代理服務器（1.9.0版本後）的多功能架構組件，同時也可以提供一定的緩存服務功能。
nginx應用比較多的場景是WEB服務器和反向代理服務器，這兩個場景的相關配置後面的文章我們會分別操作配置，這裏先來認識下：
1、WEB服務器：這是應用比較多的場景，配置虛擬主機提供HTTP WEB服務。可以先通過動態/靜態內容分離，而後爲靜態內容（html/css/js/圖片等）提供HTTP訪問功能；而動態內容可以整合代理模塊，代理給上游服務器，來支持對外部程序的直接調用或者解析，如FastCGI支持PHP。
2、反向代理服務器：這是應用非常多的場景，爲後端服務器代理。接收客戶端請求，根據負載均衡策略轉發給後端多個上游服務器處理；然後再等待後端服務器返回請求響應，接收到後再返回給請求的客戶端。
2、nginx基本架構
1、一個master進程生成多個worker子進程（每個進程只有一個線程），一個worker響應多個用戶請求；
2、非阻塞、IO複用、事件驅動：select，poll， epoll， kqueue，/dev/poll；
3、支持sendfile，sendfile64；
4、支持文件AIO（異步I/O）；
5、支持mmap；
6、靈活的文件配置；
7、佔用內存小：10,000個非活動HTTP保持連接佔用大約2.5M內存。
3、nginx功能特性
3-1、基本功能
實現與服務靜態文件（靜態資源的web服務器），能緩存打開的文件描述符；
反向代理服務器，緩存、負載均衡、健康狀態檢測；
支持FastCGI；
模塊化機制，非DSO機制，支持多種過濾器gzip，SSI和圖像的模塊完成圖形大小調整等；
支持SSL；
3-2、擴展功能
基於名稱和IP做虛擬主機；
支持keeplive；
支持平滑配置更新或程序版本升級；
定製訪問日誌，支持使用日誌緩存以提高性能；
支持URL rewrite；
支持路徑別名；
支持基於IP及用戶的認證；
支持速率限制，併發數限制等；
4、nginx併發模型
如前圖，一個master進程生成多個worker子進程（每個進程只有一個線程），一個worker響應多個用戶請求。如果單進程啓動：僅有一個進程，既充當master進程的角色，也充當worker進程的角色。
4-1、master進程
充當整個進程組與用戶的交互接口（接收來自外界的信號，向各worker進程發送信號），同時監控worker進程的運行狀態。
它不需要處理網絡事件，不負責業務的執行，只會通過管理worker進程來實現重啓服務、平滑升級、更換日誌文件、配置文件實時生效等功能。
4-2、worker進程
主要任務是處理基本的網絡事件，完成具體的任務邏輯。多個worker進程之間是對等的，互相獨立的。
worker進程主要關注點是與客戶端或後端服務器（此時nginx作爲中間代理）之間的數據可讀/可寫等I/O交互事件，所以工作進程的阻塞點是在像select()、epoll_wait()等這樣的I/O多路複用函數調用處，以等待發生數據可讀/寫事件。當然也可能被新收到的進程信號中斷。
worker進程個數：
如果負載以CPU密集型應用爲主，一般會設置與機器cpu核數一致或少一個（用來處理用戶等其他任務）；
如果負載以IO密集型爲主，如響應大量內容給客戶端，則worker數應該爲CPU個數的1.5或2倍。
因爲更多的worker數，只會導致進程來競爭cpu資源了，從而帶來不必要的上下文切換。而且，nginx爲了更好的利用多核特性，具有cpu綁定選項，我們可以將某一個進程綁定在某一個核上，這樣就不會因爲進程的切換帶來cache的失效。
更具體的可以根據公式：Nthread = Ncpu*Ucpu*(1+W/C)，Ncpu是cpu的個數，Ucpu是cpu的使用率，W爲等待時間，C爲計算時間。這時需要通過監控工具來獲取相應數據來計算。
最後，再以監控工具數據爲準進行微調。
4-3、併發處理
A、在master進程裏面，先創建socket，並bind、listen在80端口（所以master進程需要root權限）；
B、然後再fork出多個worker進程，這樣每個worker進程都可以去accept這個socket（會產生驚羣問題）， 或者使用鎖機制，讓搶到鎖的一個worker進程去accept這個socket，注意這裏一般使用select/poll/epoll機制來解決accept阻塞問題；
C、當一個新連接進來後，而只有搶到鎖的一個進程可以accept這個連接進行處理（也是放入epoll中）；
D、搶到鎖的worker進程accept到新連接後，會立即釋放鎖；然後所有worker進程再次參與搶鎖，這樣就回到了第二步，進行循環處理併發連接；
4-4、驚羣問題
A、生產原因：像上面第二步，多個worker進程等待同一個socket的連接事件，當這個事件發生時，這些進程被同時喚醒，就是驚羣。
注意，在linux2.6內核上，accept系統調用已經不存在驚羣，但用epoll機制來解決accept阻塞問題，epoll_wait會有驚羣問題（新增 EPOLLEXCLUSIVE 選項解決了）。
B、導致後果：許多worker進程被內核重新調度喚醒，只有一個進程可以accept這個連接進行處理，其他餘者皆失敗，導致性能浪費。
C、nginx解決方案：使用鎖機制，讓搶到鎖的一個worker進程去accept（epoll_wait）這個socket；如果操作系統支持原子整型，纔會使用共享內存實現原子上鎖，否則使用文件上鎖。
5、Nginx配置說明
5-1、配置文件區域說明
nginx主要配置文件nginx.conf，裏面主要包括以下幾個配置區域，如下表：
|
配置區域 |
說明 |
|
main塊 |
配置影響nginx全局的指令。一般有運行nginx服務器的用戶組，nginx進程pid存放路徑，日誌存放路徑，配置文件引入，允許生成worker process數等。 |
|
events塊 |
配置影響nginx服務器或與用戶的網絡連接。有每個進程的最大連接數，選取哪種事件驅動模型處理連接請求，是否允許同時接受多個網路連接，開啓多個網絡連接序列化等。 |
|
http塊 |
可以嵌套多個server，配置代理，緩存，日誌定義等絕大多數功能和第三方模塊的配置。如文件引入，mime-type定義，日誌自定義，是否使用sendfile傳輸文件，連接超時時間，單連接請求數等。 |
|
upstream塊 |
配置HTTP負載均衡器分配流量到幾個應用程序服務器。 |
|
server塊 |
配置虛擬主機的相關參數，一個http中可以有多個server。 |
|
location塊 |
配置請求的路由，以及允許根據用戶請求的URI來匹配指定的各location以進行訪問配置；匹配到時，將被location塊中的配置所處理。 |
nginx文件結構如下：
- … #main全局塊
- events { #events塊
- …
- }
- http #http塊
- {
- … #http全局塊
- upstream … # upstream負載均衡塊
- {
- …
- }
- server #server塊
- {
- … #server全局塊
- location [PATTERN] #location塊
- {
- …
- }
- location [PATTERN]
- {
- …
- }
- }
- server
- {
- …
- }
- … #http全局塊
- }
5-2、Nginx核心功能配置
nginx核心功能配置主要是main和events的頂層全局配置，都是配置nginx核心模塊（ngx_core_module），管理服務器級別的行爲。下表包含是大部分常用的配置選項，更多配置請參考官方文檔：http://nginx.org/en/docs/ngx_core_module.html
|
配置類別 |
配置選項 |
上下文 |
語法 |
默認值 |
功能描述 |
|
基本配置 |
user |
main |
user username [groupname] |
nobody |
以那個用戶身份運行,以在configure指定的用戶爲準 |
|
pid |
main |
pid /path/to/pid_filename |
nginx.pid |
指定nginx的pid文件 |
|
|
worker_rlimit_nofile |
main |
受linux內核文件描述符數量限制 |
指定一個worker進程所能夠打開的句柄數。因爲Linux對每個進程所能打開的文件描述數量是有限制的，默認一般是1024個，可通過ulimit -n FILECNT或/etc/securit/limits.conf配置修改linux默認能打開的文件句柄數限制。建議值爲：系統最大數量/進程數。但進程間工作量並不是平均分配的，所以可以設置在大一些。推薦值爲：655350。 |
||
|
優化性能相關配置 |
worker_procrsses |
main |
worker_processes number | auto; |
1 |
work進程的個數.如果負載以CPU密集型應用爲主，一般會設置與機器cpu核數一致或少一個（用來處理用戶等其他任務），如果負載以IO密集型爲主，如響應大量內容給客戶端，則worker數應該爲CPU個數的1.5或2倍。因爲更多的worker數，只會導致進程來競爭cpu資源了，從而帶來不必要的上下文切換。而且，nginx爲了更好的利用多核特性，具有cpu綁定選項，我們可以將某一個進程綁定在某一個核上，這樣就不會因爲進程的切換帶來cache的失效。 |
|
worker_cpu_affinity |
main |
worker_cpu_affinity cpumask …; |
無，不綁定 |
將工作進程綁定到特定的CPU上，減少CPU在進程之間切換的開銷。用二進制bit位表示進程綁定在哪個CPU內核。如4工作進程4內核：worker_processes 4; worker_cpu_affinity 0001 0010 0100 1000; 2工作進程4內核： worker_processes 2; worker_cpu_affinity 0101 1010; |
|
|
worker_priority |
main |
worker_priority number; |
0 |
工作進程調度優先級，-20到19之間的值，值越小越優先調用。如果系統同時運行多個任務，你可能需要提高nginx的工作進程的優先級 |
|
|
timer_resolution |
main |
timer_resolution interval; |
無 |
每次內核事件調用返回時，都會使用gettimeday（）來更新nginx緩存時鐘；timer_resolution用於定義每隔多久纔會由gettimeday（）更新一次緩存時鐘；x86-64系統上，gettimeday()代價已經很小，可以忽略此配置 |
|
|
ssl_engine |
main |
ssl_engine device; |
無 |
在存在ssl硬件加速器的服務器上，指定所使用的ssl硬件加速設備。由於https鏈接所消耗的資源比http大得多，可能要多消耗5、6倍，最好有專門處理ssl的硬件設備 |
|
|
事件相關配置 |
worker_commections |
events |
worker_connections number; |
512 |
每個worker能夠併發響應的最大請求數。系統每處理一個請求就要消耗一個套接字文件，如果爲代理服務器的話，worker_rlimit_nofile=worker_commections*2 |
|
use |
events |
use method; |
無，自動選擇 |
指定使用哪種模型（select/poll/epoll）,建議讓nginx自動選擇,linux內核2.6以上一般能使用epoll，提高性能。 |
|
|
accept_mutex |
events |
accept_mutex on | off; |
Off(1.11.3版本前默認on) |
是否打開nginx的accept鎖；此鎖能夠讓多個worker進行輪流地、序列化地與新的客戶端建立連接；而通常當一個worker進程的負載達到其上限的7/8，master就儘可能不將請求調度至worker. 1.11.3版本epoll支持EPOLLEXCLUSIVE 標記，不再有驚羣問題 。 |
|
|
accept_mutex_delay |
events |
accept_mutex_delay time; |
500ms |
使用accept鎖以後，只有一個worker能取得鎖，一個worker進程爲取得accept鎖的等待時長，即用戶建立等待的時間，如果某worker進程在某次試圖取得鎖時失敗了，至少要等待#ms才能在一次請求鎖 |
|
|
multi_accept |
events |
multi_accept on | off; |
off |
是否允許一次性地響應多個用戶請求 |
|
|
調試、定位問題配置 |
daemon |
main |
daemon on | off; |
on |
nginx是否以守護進程運行，是否讓nignx運行於後臺；調試時應該爲off，使得所有信息直接輸出在控制檯 |
|
master_process |
main |
master_process on | off; |
on |
是否以master/worker模式運行nginx，默認爲on，調試時可以設置爲off以方便追蹤 |
|
|
error_log |
main, http, mail, stream, server, location |
error_log file [level]; |
error_log logs/error.log error; |
配置錯誤日誌文件的路徑和日誌級別。日誌級別有debug, info, notice, warn, error, crit, alert和emerg幾種。調試時可以使用debug級別，但要求在編譯時必須使用–with-debug啓用debug功能，默認通常爲error級別. |
5-3、Nginx HTTP核心配置
http功能核心配置主要是http塊、server塊和location塊的配置，包括HTTP核心模塊（ngx_http_core_module）和一些擴展模塊（如ngx_stream_ssl_module），提供管理WEB服務器級別的行爲。
必須使用虛擬機來配置站點，每個虛擬主機使用一個server{}段來配置，非虛擬主機的配置和公共選項，需要定義在server之外，http之內。
下表包含是大部分常用的配置選項，更多配置請參考官方文檔：http://nginx.org/en/docs/
|
配置類別 |
配置選項/模塊 |
上下文 |
語法 |
默認值 |
功能描述 |
|
基本配置 |
http |
main |
http { … } |
無 |
提供HTTP服務器配置上下文 |
|
server |
http |
server { … } |
無 |
HTTP服務器的核心配置，定義一個虛擬主機：nginx支持使用基於主機名或IP的虛擬主機 |
|
|
listen |
server |
listen address[:port] listen prot listen unix:socket |
listen *:80 | *:8000 |
配置虛擬主機監聽的IP地址和端口，默認監聽本機IP地址和80或8000端口。如果只設置了IP沒設端口，默認使用80端口。如果只設置了端口，沒設置IP默認使用本機IP。 後面可以指定一些參數： default_server:定義此server爲http中默認的server；如果所有的server中任何一個listen使用此參數，那麼第一個server即爲默認server； rcvbuf=SIZE：接收緩存大小； sndbuf=SIZE: 發送緩存大小； ssl：https server：必須以ssl連接； |
|
|
server_name |
server |
server_name name …; |
“” |
配置虛擬主機的域名，可以指定多個，用空格分隔。默認爲空。 名稱可以使用通配符和正則表達式（通常以~開頭）：當nginx收到一個請求時，會取出其首部的server的值，而後跟衆server_name進行比較：比較方式 (1) 先做精確匹配，如www.tjiyu.com (2) 左側通配符匹配，如*tjiyu.com (3) 右側通配符匹配，如www.* (4) 正則表達式匹配 |
|
|
server_name_hash_bucket_size |
server |
server_names_hash_bucket_size size; |
32|64|128 |
爲了實現快速主機查找，nginx使用hash表來保存主機名。 默認值取決於處理器緩存線的大小。 |
|
|
location |
server, location |
location [ = | ~ | ~* | ^~ ] uri { … } location @name { … } |
無 |
允許根據用戶請求的URI來匹配指定的各location以進行訪問配置；匹配到時，將被location塊中的配置所處理。 =：精確匹配； ~：正則表達式模式匹配，匹配時區分字符大小寫； ~*：正則表達式模式匹配，匹配時忽略字符大小寫； ^~:只需要前半部分與uri匹配即可，不檢查正則表達式； 匹配優先級： 字符字面量最精確匹配、正則表達式檢索（由多個時，由第一個匹配到的所處理），按字符字面量。 |
|
|
資源路徑定義配置 |
root |
http, server, location, if in location |
root path; |
root html; |
設置web資源路徑，用於指定請求的根文檔目錄，從根開始匹配。 如root /html/image/，請求”/tjiyu.gif”對應的文件爲”/html/image/tjiyu.gif” |
|
alias |
location |
alias path; |
無 |
指定路徑別名，只能用於location中，從最後一個/開始匹配。 如location /i/ { alias /data/w3/images/; } 請求”/i/top.gif”, 實際文件”/data/w3/images/top.gif” |
|
|
Index |
http, server, location |
index file …; |
index index.html; |
ngx_http_index_module. 定義默認頁面，可以跟多個值。自左向右匹配。 |
|
|
error_page |
http, server, location, if in location |
error_page code … [=[response]] uri; |
無 |
ngx_http_core_module 當對於某個請求發回錯誤時，如果匹配上了error_page指令中設定的code，則從定向至新的URI中，錯誤重定向. 如 error_page 500 502 503 504 /50x.html; 也可以改變返回碼。 如error_page 404 =200 /404.html; |
|
|
try_files |
server, location |
try_files file … uri; try_files file … =code; |
無 |
自左向右嘗試讀取有path所指定路徑，在第一找到即停止並返回，如果所有path均不存在，則返回最後一個uri或者code. 如try_files uri/index.html $uri.html =404; |
|
|
網絡連接相關設置 |
keepalive_timeout |
http, server, location |
keepalive_timeout timeout [header_timeout]; |
75s |
保持連接的超時時長，默認爲75s。 降低每個連接的alive時間可在一定程度上提高可響應連接數量，所以一般可適當降低此值 |
|
keepalive_requests |
http, server, location |
keepalive_requests number; |
100 |
在一次長連接上允許承載的最大請求數。 |
|
|
keepalive_disable |
http, server, location |
keepalive_disable none | browser …; |
msie6（ie6無法長連接） |
對指定的瀏覽器禁止使用長連接。 |
|
|
tcp_nodelay |
http, server, location |
tcp_nodelay on | off; |
on |
這裏指ngx_http_core_module模塊的選項。 對keepalive連接是否使用tcp_nodelay選項 啓動配置，會在數據包達到一定大小後再發送數據。這樣會減少網絡通信次數，降低阻塞概率，但也會影響響應及時性。比較適合於文件下載這類的大數據通信場景。 |
|
|
client_header_timeout |
http, server |
client_header_timeout time; |
60s |
讀取http請求首部的超時時長。 如果客戶端在此時間內未傳輸整個頭，則會向客戶端返回408（請求超時）錯誤。 |
|
|
client_body_timeout |
http, server, location |
client_body_timeout time; |
60s |
讀取http請求包體的超時時間。 |
|
|
send_timeout |
http, server, location |
send_timeout time; |
60s |
發送響應的超時時長。 超時後連接將關閉。 |
|
|
對客戶端請求的限制配置 |
limit_except |
location |
limit_except method … { … } |
on |
指定範圍之外的其他方法的訪問控制。 方法有：GET, HEAD, POST, PUT, DELETE, MKCOL, COPY, MOVE, OPTIONS, PROPFIND, PROPPATCH, LOCK, UNLOCK, or PATCH. 如只允許GET訪問： limit_except GET { allow 192.168.1.0/32; deny all; } |
|
client_max_body_size |
http, server, location |
client_max_body_size size; |
1m |
http請求包體的最大值，常用於限定客戶端所能夠請求的最大包體，根據請求首部中的Content-Length來檢查，以避免無用的傳輸。 |
|
|
limit_rate |
http, server, location, if in location |
limit_rate rate; |
0 |
限制客戶端每秒傳輸的字節數，默認爲0，表示沒有限制。 |
|
|
limit_rate_after |
http, server, location, if in location |
limit_rate_after size; |
0 |
nginx向客戶端發送響應報文時，如果時長超過了此處指定的時長，則後續的發送過程開始限速（下載站點常用）。 配置上面的limit_rate使用。 |
|
|
對客戶端請求的特殊處理 |
ignore_invalid_headers |
http, server |
ignore_invalid_headers on | off; |
on |
是否忽略不合法的http首部，默認爲on，off意味着請求首部中出現不合規的首部將拒絕響應。 |
|
log_not_found |
http, server, location |
log_not_found on | off; |
on |
用戶訪問的文件不存在時，是否將其記錄到錯誤日誌中。 |
|
|
resolver |
http, server, location |
resolver address … [valid=time] [ipv6=on|off]; |
無 |
這裏指ngx_http_core_module模塊選項、 指定nginx使用的dns服務器地址。 valid = 30s，整緩存時間設置。在1.1.9版之前，不可能調整緩存時間，而nginx總是緩存答案5分鐘的時間。 |
|
|
resolver_timeout |
http, server, location |
resolver_timeout time; |
30s |
指定DNS解析超時時長。 |
|
|
server_tokens |
http, server, location |
server_tokens on | off | string; |
on |
是否在錯誤頁面中顯示和”響應頭字段中發出nginx的版本號。 從版本1.9.13開始，可以使用帶有變量的字符串顯式設置。 空字符串禁用。 |
|
|
文件操作的優化 |
sendfile |
http, server, location, if in location |
sendfile on | off; |
off |
是否啓用sendfile內核複製模式功能。 作爲靜態服務器可以提高最大的IO訪問速度。傳統的文件讀寫採用read和write方式，流程爲：硬盤 >> kernel buffer >> user buffer>> kernel socket buffer >>協議棧，採用sendfile文件讀寫的流程爲：硬盤 >> kernel buffer (快速拷貝到kernelsocket buffer) >>協議棧，很明顯sendfile這個系統調用減少了內核到用戶模式之間的切換和數據拷貝次數，直接從內核緩存的數據拷貝到協議棧，提高了很大的效率。 |
|
aio |
http, server, location |
aio on | off | threads[=pool]; |
off |
是否啓用異步文件IO功能。 Linux從內核版本2.6.22開始支持，有必要啓用directio，否則讀取將阻塞。 directio只能用於讀取在512字節邊界（或XFS爲4K）上對齊的塊。文件結束未對齊將在阻塞模式下讀取。 當在Linux上同時啓用AIO和sendfile功能時，AIO用於大於或等於directio指令中指定大小的文件，而小於或禁用directio時則用sendfile。 location /video/ { sendfile on; aio on; directio 8m; } |
|
|
open_file_cache |
http, server, location |
open_file_cache off; open_file_cache max=N [inactive=time]; |
off |
是否打開文件緩存功能。 max：用於緩存條目的最大值，允許打開的緩存條目最大數，當滿兩類以後將根據LRU（最小最少連接數）算法進行置換 inactive：某緩存條目在指定時長內沒有被訪問過時，將自動被刪除，即緩存有效期，通常默認爲60s。 緩存的信息包括： 文件句柄、文件大小和上次修改時間； 已經打開的目錄結構； 沒有找到或沒有訪問權限的信息等。 建議值：max=655350（和worker_rlimit_nofile參數一致） inactive=20s; |
|
|
open_file_cache_errors |
http, server, location |
open_file_cache_errors on | off; |
off |
是否緩存文件找不到或沒有權限訪問等相關信息。 |
|
|
open_file_cache_valid |
http, server, location |
open_file_cache_valid time; |
60s |
多長時間檢查一次緩存中的條目是否超出非活動時長。 建議值：小於等於open_file_cache inactive |
|
|
open_file_cache_min_use |
http, server, location |
open_file_cache_min_uses number; |
1 |
在open_file_cache inactive指定的時長內被訪問超過此處指定的次數時，纔不會被刪除（刪除低命中率的緩存）。 |
|
|
Gzip壓縮相關配置 |
gzip |
http, server, location, if in location |
gzip on | off; |
off |
開啓內容壓縮，可以有效降低客戶端的訪問流量和網絡帶寬 |
|
gzip_min_length |
http, server, location |
gzip_min_length length; |
20k |
內容超過最少長度後纔開啓壓縮，因爲太短的內容壓縮效果不佳，且壓縮過程還會浪費系統資源。這個壓縮長度會作爲http響應頭Content-Length字段返回給客戶端。 建議值：64 |
|
|
gzip_comp_level |
http, server, location |
gzip_comp_level 1~9; |
1 |
壓縮級別，默認值爲1。範圍爲1～9級，壓縮級別越高壓縮率越高，但對系統性能要求越高。 建議值：4 |
|
|
gzip_types |
http, server, location |
gzip_types mime-type …; |
text/html |
壓縮內容類型，默認爲text/html;。只壓縮html文本，一般我們都會壓縮js、css、json之類的，可以把這些常見的文本數據都配上。如：text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript; |
5-4、配置變量
Nginx配置文件支持使用變量，可以使用內置變量或自定義變量。用戶自定義變量語法：set var_name value；http核心模塊的內置變量（http://nginx.org/en/docs/varindex.html），主要有如下：
- $uri:當前請求的uri，不帶參數
- $request_uri：請求的uri，帶完整參數
- $host：http請求報文中host首部；如果請求中沒有host首部，則以處理此請求的主機的主機名代替
- $hostname：nginx服務運行所在主機的主機名
- $remote_addr：客戶端IP
- $remote_port: 客戶端port
- $remote_user：使用用戶認證時客戶端用戶輸入的用戶名
- $request_filename：用戶請求中的URI經過本地root或alias轉換後映射的本地的文件路徑
- $request_method：請求方法
- $server_addr：服務器地址
- $server_name: 服務器名稱
- $server_port：服務器端口
- $server_protocol：服務器向客戶端發送響應時的協議，如http/1.1，http/1.0
- $scheme:在請求中使用的scheme 映射協議本身的協議
- http_host匹配請求報文中的host首部
- http_content_type匹配相應報文中的content-type首部
- $document_root：當前請求映射到的root配置
5-5、if判斷語句
if是URL地址重寫ngx_http_rewrite_module模塊中的選項。
在location中使用if語句可以實現條件判斷，其通常有一個return語句，且一般與有着last或break標記的rewrite規則一同使用。但其也可以按需要使用在多種場景下，需要注意的是，不當的使用可能會導致不可預料的後果。if語句中的判斷條件匹配用法如下：
- 正則表達式匹配：
- ==: 等值比較；
- ~：與指定正則表達式模式匹配時返回”真”，判斷匹配與否時區分字符大小寫；
- ~*：與指定正則表達式模式匹配時返回”真”，判斷匹配與否時不區分字符大小寫；
- !~：與指定正則表達式模式不匹配時返回”真”，判斷匹配與否時區分字符大小寫；
- !~*：與指定正則表達式模式不匹配時返回”真”，判斷匹配與否時不區分字符大小寫；
- 文件及目錄匹配判斷：
- -f, !-f：判斷指定的路徑是否爲存在且爲文件；
- -d, !-d：判斷指定的路徑是否爲存在且爲目錄；
- -e, !-e：判斷指定的路徑是否存在，文件或目錄均可；
- -x, !-x：判斷指定路徑的文件是否存在且可執行；
比如：
if ($request_method == “PUT”) { #判斷請求方法
}
if ( ”){#判斷URL是否是以這些結尾的圖片
}
6、nginx命令行參數
nginx 僅有數個命令行參數，完全通過配置文件來配置。通過”nginx –h”可以查看，如下：
常用選項：
- -c </path/to/config> 爲 Nginx 指定一個配置文件，來代替缺省的。
- -t 不運行，而僅僅測試配置文件。nginx 將檢查配置文件的語法的正確性，並嘗試打開配置文件中所引用到的文件。
- -v 顯示 nginx 的版本。
- -V 顯示 nginx 的版本，編譯器版本和配置參數。
注意，下面安裝後我們爲nginx提供了一個SysV init服務腳本，就是基於這些命令實現的。
7、爲什麼選擇使用nginx
前面講了那麼多，我們最後來總結下，選擇nginx的理由：
7-1、高併發性能的併發模型：性能好、佔用內存少、穩定
前面說過，nginx的併發模型中最好設置worker進程與CPU核心數量差不多，而一個worker進程可以處理多個請求，比apache一個進程/一個線程響應響應一個請求的併發模型，可以大大減少進程/線程數量，減少重複的數據，所以內存使用效率較高，佔用內存資源少，同時減少CPU調度和上下文切換次數，所以nginx要比apache更“輕量”，且性能更好；
一個worker進程綁定一個CPU核心，更是可以讓nginx充分發揮CPU的計算能力來處理請求。
使用IO複用機制避免阻塞，可以處理更多的任務；
多個worker進程互不影響，不像多線程模型，一個線程出問題可能使整個進程內其他線程都崩潰，所以nginx穩定，健壯性好。
7-2、高擴展性
Nginx的模塊化設計極具擴展性，它完全是由多個不同功能、不同層次、不同類型且耦合度極低的模塊組成。因此，當對某一個模塊修復Bug或進行升級時，可以專注於模塊自身，無須在意其他。
這種低耦合度的優秀設計，造就了Nginx龐大的第三方模塊，當然，公開的第三方模塊也如官方發佈的模塊一樣容易使用。
7-3、功能強大，應用前景廣闊
Nginx提供大量的功能模塊，支持諸多特性，應用場景多，且現今（2016）在WEB服務器應用中佔有27.80%份額。
作爲 Web 服務器：相比 Apache，Nginx 使用更少的資源，支持更多的併發連接，體現更高的效率，能夠支持高達50000個併發連接數的響應。
作爲負載均衡服務器：Nginx既可以在內部直接支持 Rails 和 PHP，也可以支持作爲 HTTP代理服務器 對外進行服務。Nginx用C編寫, 不論是系統資源開銷還是 CPU 使用效率都比Perlbal要好的多。
還可作爲郵件代理服務器、緩存服務器。
7-4、配置/操作簡便
Nginx安裝非常的簡單，配置文件非常簡潔（還能夠支持perl語法），Bugs非常少的服務器: Nginx 啓動特別容易，並且幾乎可以做到7*24不間斷運行，即使運行數個月也不需要重新啓動。你還能夠在不間斷服務的情況下進行軟件版本的升級。
到這裏，我們對nginx有了一個基本的認識，後面將分別進行nginx的WEB服務和代理服務相關的應用配置……
【參考資料】
1、nginx官網文檔：http://nginx.org/en/docs/
2、nginx源碼
3、Web服務器之Nginx詳解：http://freeloda.blog.51cto.com/2033581/1285332
4、Nginx 多進程連接請求/事件分發流程分析：http://www.cnblogs.com/NerdWill/p/4992345.html
5、Nginx配置詳解：http://www.cnblogs.com/knowledgesea/p/5175711.html
================
對比
對於數據流量過大的網絡中，往往單一設備無法承擔，需要多臺設備進行數據分流，而負載均衡器就是用來將數據分流到多臺設備的一個轉發器。
目前有許多不同的負載均衡技術用以滿足不同的應用需求，如軟/硬件負載均衡、本地/全局負載均衡、更高網絡層負載均衡，以及鏈路聚合技術。
我們使用的是軟負載均衡器Nginx,而農行用的是F5硬負載均衡器，這裏就簡單介紹下這兩種技術：
a.軟件負載均衡解決方案
在一臺服務器的操作系統上，安裝一個附加軟件來實現負載均衡，如Nginx負載均衡（我們管理系統平臺使用的也是這款均衡器）。它的優點是基於特定環境、配置簡單、使用靈活、成本低廉，可以滿足大部分的負載均衡需求。
一、什麼是Nginx
Nginx (“engine x”) 是一個高性能的 HTTP 和 反向代理 服務器，也是一個 IMAP/POP3/SMTP 代理服務器。 可以說Nginx 是目前使用最爲廣泛的HTTP軟負載均衡器，其將源代碼以類BSD許可證的形式發佈（商業友好），同時因高效的性能、穩定性、豐富的功能集、示例配置文件和低系統資源的消耗而聞名於業界。像騰訊、淘寶、新浪等大型門戶及商業網站都採用Nginx進行HTTP網站的數據分流。
二、Nginx的功能特點
1、工作在網絡的7層之上，可以針對http應用做一些分流的策略，比如針對域名、目錄結構；
2、Nginx對網絡的依賴比較小；
3、Nginx安裝和配置比較簡單，測試起來比較方便；
4、也可以承擔高的負載壓力且穩定，一般能支撐超過1萬次的併發；
5、Nginx可以通過端口檢測到服務器內部的故障，比如根據服務器處理網頁返回的狀態碼、超時等等，www.linuxidc.com 並且會把返回錯誤的請求重新提交到另一個節點，不過其中缺點就是不支持url來檢測；
6、Nginx對請求的異步處理可以幫助節點服務器減輕負載；
7、Nginx能支持http和Email，這樣就在適用範圍上面小很多；
8、不支持Session的保持、對Big request header的支持不是很好，另外默認的只有Round-robin和IP-hash兩種負載均衡算法。
三、Nginx的原理
Nginx採用的是反向代理技術，代理服務器來接受internet上的連接請求，然後將請求轉發給內部網絡上的服務器，並將從服務器上得到的結果返回給internet上請求連接的客戶端，此時代理服務器對外就表現爲一個服務器。反向代理負載均衡技術是把將來自internet上的連接請求以反向代理的方式動態地轉發給內部網絡上的多臺服務器進行處理，從而達到負載均衡的目的。
b.硬件負載均衡解決方案
直接在服務器和外部網絡間安裝負載均衡設備，這種設備我們通常稱之爲負載均衡器。由於專門的設備完成專門的任務，獨立於操作系統，整體性能得到大量提高，加上多樣化的負載均衡策略，智能化的流量管理，可達到最佳的負載均衡需求。 一般而言，硬件負載均衡在功能、性能上優於軟件方式，不過成本昂貴，比如最常見的就是F5負載均衡器。
什麼是F5 BIG-IP
F5負載均衡器是應用交付網絡的全球領導者F5 Networks公司提供的一個負載均衡器專用設備，F5 BIG-IP LTM 的官方名稱叫做本地流量管理器，可以做4-7層負載均衡，具有負載均衡、應用交換、會話交換、狀態監控、智能網絡地址轉換、通用持續性、響應錯誤處理、IPv6網關、高級路由、智能端口鏡像、SSL加速、智能HTTP壓縮、TCP優化、第7層速率整形、內容緩衝、內容轉換、連接加速、高速緩存、Cookie加密、選擇性內容加密、應用攻擊過濾、拒絕服務(DoS)攻擊和SYN Flood保護、防火牆—包過濾、包消毒等功能。
以下是F5 BIG-IP用作HTTP負載均衡器的主要功能：
①、F5 BIG-IP提供12種靈活的算法將所有流量均衡的分配到各個服務器，而面對用戶，只是一臺虛擬服務器。
②、F5 BIG-IP可以確認應用程序能否對請求返回對應的數據。假如F5 BIG-IP後面的某一臺服務器發生服務停止、死機等故障，F5會檢查出來並將該服務器標識爲宕機，從而不將用戶的訪問請求傳送到該臺發生故障的服務器上。這樣，只要其它的服務器正常，用戶的訪問就不會受到影響。宕機一旦修復，F5 BIG-IP就會自動查證應用已能對客戶請求作出正確響應並恢復向該服務器傳送。
③、F5 BIG-IP具有動態Session的會話保持功能。
④、F5 BIG-IP的iRules功能可以做HTTP內容過濾，根據不同的域名、URL，將訪問請求傳送到不同的服務器。
方案優缺點對比
基於硬件的方式(F5)
優點：能夠直接通過智能交換機實現,處理能力更強，而且與系統無關，負載性能強更適用於一大堆設備、大訪問量、簡單應用
缺點：成本高，除設備價格高昂，而且配置冗餘．很難想象後面服務器做一個集羣，但最關鍵的負載均衡設備卻是單點配置；無法有效掌握服務器及應用狀態.
硬件負載均衡，一般都不管實際系統與應用的狀態，而只是從網絡層來判斷，所以有時候系統處理能力已經不行了，但網絡可能還來 得及反應（這種情況非常典型，比如應用服務器後面內存已經佔用很多，但還沒有徹底不行，如果網絡傳輸量不大就未必在網絡層能反映出來）
基於軟件的方式(Nginx)
優點：基於系統與應用的負載均衡，能夠更好地根據系統與應用的狀況來分配負載。這對於複雜應用是很重要的，性價比高，實際上如果幾臺服務器，用F5之類的硬件產品顯得有些浪費，而用軟件就要合算得多，因爲服務器同時還可以跑應用做集羣等。
缺點：負載能力受服務器本身性能的影響，性能越好，負載能力越大。
綜述：對我們管理系統應用環境來說，由於負載均衡器本身不需要對數據進行處理，性能瓶頸更多的是在於後臺服務器，通常採用軟負載均衡器已非常夠用且其商業友好的軟件源碼授權使得我們可以非常靈活的設計，無逢的和我們管理系統平臺相結合。
</div>
</div>