Nginx配置引數
Nginux的配置檔案是ngiux.conf
全域性配置引數:
1、執行使用者
user nobody
2、啟動的程序數，與CPU數量設定相同
worker_processes 1;
3、錯誤日誌和PID檔案
#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;
#pid logs/nginx.pid;
4、輸出日誌格式
log_format access '$remote_addr -
time_local] “KaTeX parse error: Double superscript at position 15: request" ' '̲status
http_referer” ’ ‘“
http_x_forwarded_for”’;
Nginux內建引數含義
5、工作模式和連線數限制
events{
use epoll;
worker_connections 20000; //每個程序的連線數
}
Nginx支援如下處理連線的方法（I/O複用方法），這些方法可以通過use指令指定。
select – 標準方法。 如果當前平臺沒有更有效的方法，它是編譯時預設的方法。你可以使用配置引數 –with-select_module 和 –without-select_module 來啟用或禁用這個模組。
poll – 標準方法。 如果當前平臺沒有更有效的方法，它是編譯時預設的方法。你可以使用配置引數 –with-poll_module 和 –without-poll_module 來啟用或禁用這個模組。
kqueue – 高效的方法，使用於 FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 和 MacOS X. 使用雙處理器的MacOS X系統使用kqueue可能會造成核心崩潰。
epoll – 高效的方法，使用於Linux核心2.6版本及以後的系統。在某些發行版本中，如SuSE 8.2, 有讓2.4版本的核心支援epoll的補丁。
rtsig – 可執行的實時訊號，使用於Linux核心版本2.2.19以後的系統。預設情況下整個系統中不能出現大於1024個POSIX實時(排隊)訊號。這種情況 對於高負載的伺服器來說是低效的；所以有必要通過調節核心引數 /proc/sys/kernel/rtsig-max 來增加佇列的大小。可是從Linux核心版本2.6.6-mm2開始， 這個引數就不再使用了，並且對於每個程序有一個獨立的訊號佇列，這個佇列的大小可以用 RLIMIT_SIGPENDING 引數調節。當這個佇列過於擁塞，nginx就放棄它並且開始使用 poll 方法來處理連線直到恢復正常。
/dev/poll – 高效的方法，使用於 Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ 和 Tru64 UNIX 5.1A+.
eventport – 高效的方法，使用於 Solaris 10. 為了防止出現核心崩潰的問題， 有必要安裝 這個 安全補丁。
epoll的優點
支援一個程序開啟大數目的socket描述符(FD)
select 最不能忍受的是一個程序所開啟的FD是有一定限制的，由FD_SETSIZE設定，預設值是2048。對於那些需要支援的上萬連線數目的IM伺服器來說顯 然太少了。這時候你一是可以選擇修改這個巨集然後重新編譯核心，不過資料也同時指出這樣會帶來網路效率的下降，二是可以選擇多程序的解決方案(傳統的 Apache方案)，不過雖然linux上面建立程序的代價比較小，但仍舊是不可忽視的，加上程序間資料同步遠比不上執行緒間同步的高效，所以也不是一種完 美的方案。不過 epoll則沒有這個限制，它所支援的FD上限是最大可以開啟檔案的數目，這個數字一般遠大於2048,舉個例子,在1GB記憶體的機器上大約是10萬左 右，具體數目可以cat /proc/sys/fs/file-max察看,一般來說這個數目和系統記憶體關係很大。
IO效率不隨FD數目增加而線性下降
傳 統的select/poll另一個致命弱點就是當你擁有一個很大的socket集合，不過由於網路延時，任一時間只有部分的socket是”活躍”的，但 是select/poll每次呼叫都會線性掃描全部的集合，導致效率呈現線性下降。但是epoll不存在這個問題，它只會對”活躍”的socket進行操 作—這是因為在核心實現中epoll是根據每個fd上面的callback函式實現的。那麼，只有”活躍”的socket才會主動的去呼叫 callback函式，其他idle狀態socket則不會，在這點上，epoll實現了一個”偽”AIO，因為這時候推動力在os核心。在一些 benchmark中，如果所有的socket基本上都是活躍的—比如一個高速LAN環境，epoll並不比select/poll有什麼效率，相 反，如果過多使用epoll_ctl,效率相比還有稍微的下降。但是一旦使用idle connections模擬WAN環境,epoll的效率就遠在select/poll之上了。
使用mmap加速核心與使用者空間的訊息傳遞。
這 點實際上涉及到epoll的具體實現了。無論是select,poll還是epoll都需要核心把FD訊息通知給使用者空間，如何避免不必要的記憶體拷貝就很 重要，在這點上，epoll是通過核心於使用者空間mmap同一塊記憶體實現的。而如果你想我一樣從2.5核心就關注epoll的話，一定不會忘記手工 mmap這一步的。
核心微調
這一點其實不算epoll的優點了，而是整個linux平臺的優點。也許你可以懷疑linux平臺，但是你無法迴避linux平臺賦予你微調核心的能力。比如，核心TCP/IP協 議棧使用記憶體池管理sk_buff結構，那麼可以在執行時期動態調整這個記憶體pool(skb_head_pool)的大小— 通過echo XXXX>/proc/sys/net/core/hot_list_length完成。再比如listen函式的第2個引數(TCP完成3次握手 的資料包佇列長度)，也可以根據你平臺記憶體大小動態調整。更甚至在一個數據包面數目巨大但同時每個資料包本身大小卻很小的特殊系統上嘗試最新的NAPI網絡卡驅動架構。
6、設定Http伺服器，利用反向代理實現負載均衡
http{
#設定mime型別
include /etc/nginx/mime.types;
default_type application/octet-stream;
#設定日誌格式
access_log /usr/local/nginx/logs/access.log’
#sendfile: 設定為on表示啟動高效傳輸檔案的模式。sendfile可以讓Nginx在傳輸檔案時直接在磁#盤和tcp socket之間傳輸資料。如果這個引數不開啟，會先在使用者空間（Nginx程序空間）申請##一個buffer，用read函式把資料從磁碟讀到cache，再從cache讀取到使用者空間的buffer，再用#write函式把資料從使用者空間的buffer寫入到核心的buffer，最後到tcp socket。開啟這個引數後#可以讓資料不用經過使用者buffer
sendfile on;
#連線超時配置
keepalive_timeout 60;
#開啟gzip壓縮
gzip on;
#負載均衡列表
upstream test.com{
server 127.0.0.1:8080 weight=1;
server 127.0.0.1:9090 weight=2;
}
#虛擬機器設定
server {
listen 80;
server_name rabbitmq1; #匹配主機名
#charset koi8-r;
#access_log logs/host.access.log main;
#配置所有請求
location / {
proxy_pass http://127.0.0.1:8080/examples/;
proxy_redirect default;
}
#error_page 404 /404.html;
redirect server error pages to the static page /50x.html
error_page 500 502 503 504 /50x.html;
#配置50開頭的網頁
location = /50x.html {
root html;
}
}
#第二個虛擬機器
server {
listen 80;
server_name rabbitmq1.com rabbitmq1.net;#匹配主機名
#匹配所有請求
location / {
proxy_pass http://127.0.0.1:8080/;
proxy_redirect default;
}
}
}
Location匹配規則
1.=，精確匹配
location = /index.html {
#規則
}
# 則匹配到 `http://mytest.com/index.html` 這種請求。
2.~，大小寫敏感
location ~ /GuFang/ {
#規則
}
#請求示例
#http://mytest.com/GuFang/ [成功]
#http://mytest.com/gufang/ [失敗]
3.~*，大小寫忽略
location ~* /GuFang/ {
#規則
}
# 則會忽略 uri 部分的大小寫
#http://mytest.com/GuFang/ [成功]
#http://mytest.com/gufang/ [成功]
4.^~，只匹配以 uri 開頭
location ^~ /images/ {
#規則
}
#以 /images/ 開頭的請求，都會匹配上
#http://mytest.com/images/a.jpg [成功]
#http://mytest.com/images/b.mp4 [成功]
[email protected]，nginx內部跳轉
location /video/ {
error_page 404 @video_err;
}
location @video_err {
# 規則
}
#以 /video/ 開頭的請求，如果連結的狀態為 404。則會匹配到 @img_err 這條規則上。
Rewrite
rewrite的組要功能是實現RUL地址的重定向。Nginx的rewrite功能需要PCRE軟體的支援，即通過perl相容正則表示式語句進行規則匹配的。預設引數編譯nginx就會支援rewrite的模組，但是也必須要PCRE的支援
rewrite是實現URL重寫的關鍵指令，根據regex（正則表示式）部分內容，重定向到replacement，結尾是flag標記。
rewrite語法格式及引數語法說明如下:
關鍵字 正則 替代內容 flag標記
rewrite [flag];
關鍵字：其中關鍵字rewrite不能改變
正則：perl相容正則表示式語句進行規則匹配
替代內容：將正則匹配的內容替換成replacement
flag標記：rewrite支援的flag標記
flag標記說明：
last #本條規則匹配完成後，繼續向下匹配新的location URI規則
break #本條規則匹配完成即終止，不再匹配後面的任何規則
redirect #返回302臨時重定向，瀏覽器地址會顯示跳轉後的URL地址
permanent #返回301永久重定向，瀏覽器位址列會顯示跳轉後的URL地址
rewrite引數的標籤段位置：
server,location,if
regex 常用正則表示式說明
\
將後面接著的字元標記為一個特殊字元或一個原義字元或一個向後引用。如“\n”匹配一個換行符，而“\$”則匹配“$”
^
匹配輸入字串的起始位置
$
匹配輸入字串的結束位置
*
匹配前面的字元零次或多次。如“ol*”能匹配“o”及“ol”、“oll”
+
匹配前面的字元一次或多次。如“ol+”能匹配“ol”及“oll”、“oll”，但不能匹配“o”
?
匹配前面的字元零次或一次，例如“do(es)?”能匹配“do”或者“does”，"?"等效於"{0,1}"
.
匹配除“\n”之外的任何單個字元，若要匹配包括“\n”在內的任意字元，請使用諸如“[.\n]”之類的模式。
(pattern)
匹配括號內pattern並可以在後面獲取對應的匹配，常用$0...$9屬性獲取小括號中的匹配內容，要匹配圓括號字元需要\(Content\)
例程
server {
listen 80;
server_name mytest.com;
rewrite ^/(.*) http://myexample.com/$1 permanent;
location =/index.html {
root /usr/local/nginx/mydir;
}
location ~ /Example/{
root /usr/local/nginx/mydir;
index index.html;
}
location ~* /Example/{
root /usr/local/nginx/mydir;
index index.html;
}
location ^~ /image/ {
root /usr/local/nginx/html;
}
location /img/ {
error_page 404 @img404;
}
location @img404 {
root /usr/local/nginx/html;
index 50x.html;
}
}
server {
listen 80;
server_name myexample.com;
}
Nginx中的upstream輪詢機制
1、輪詢(weight=1)
預設選項，當weight不指定時，各伺服器weight相同， 每個請求按時間順序逐一分配到不同的後端伺服器，如果後端伺服器down掉，能自動剔除。
upstream bakend {
server 192.168.1.10;
server 192.168.1.11;
}
2、weight
指定輪詢機率，weight和訪問比率成正比，用於後端伺服器效能不均的情況。
如果後端伺服器down掉，能自動剔除。
比如下面配置，則1.11伺服器的訪問量為1.10伺服器的兩倍。
upstream bakend {
server 192.168.1.10 weight=1;
server 192.168.1.11 weight=2;
}
3、ip_hash
每個請求按訪問ip的hash結果分配，這樣每個訪客固定訪問一個後端伺服器，可以解決session不能跨伺服器的問題。
如果後端伺服器down掉，要手工down掉。
upstream resinserver{
ip_hash;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
}
4、fair（第三方外掛）
按後端伺服器的響應時間來分配請求，響應時間短的優先分配。
upstream resinserver{
server 192.168.1.10:8080;
server 192.168.1.11:8080;
fair;
}
5、url_hash（第三方外掛）
按訪問url的hash結果來分配請求，使每個url定向到同一個後端伺服器，後端伺服器為快取伺服器時比較有效。
在upstream中加入hash語句，hash_method是使用的hash演算法
upstream resinserver{
server 192.168.1.10:8080;
server 192.168.1.11:8080;
hash $request_uri;
hash_method crc32;
}