Nginx的繼續深入（日志輪詢切割，重寫，負載均衡等）

Nginx的訪問日志輪詢切割

通常什么情況Nginx會把所有的訪問日志生成到一個制定的訪問日志文件access.log里面，但時間一長，日志個頭很大不利於日志的分析和處理。

有必要對Nginx日志進行按天或按小時進行切割，分成不同的文件保存。

[root@www logs]#cat /server/script/cut_nginx_log.sh
#!/bin/sh
Dataformat = `date +%Y%m%d`
Basedir = "/usr/local/nginx"
Nginxlogdir = "$Basedir/logs"
Logname = "access_www"
[ -d $Nginxlogdir ] && cd $Nginxlogdir || exit 1
[ -f ${Logname}.log] || exit 1
/bin/mv ${Logname}.log ${Dateformat}_${Logname}.log
$Basedir/sbin/nginx -s reload

注意：腳本實現切割Nginx日志的思想為講正在寫入的Nginx日志改名為（20161111_access_www.log）,然后平滑重啟生成新的nginx日志（access_www.log）

通過定時任務實現每天的00點整定時執行/server/script/cut_nginx_log.sh

00 00 * * * /bin/sh /server/script/cut_nginx_log.sh >/dev/null 2>&1

 

Nginx 的location語法

location的使用基本語法：

location [= | ~ | ~* | ^~] uri {
....
}

location   指令
[=|~|~*|@] 匹配標識
uri    匹配的網站網址
{。。。。}  匹配URI后要執行的配置段

~ 區分大小寫（大小寫敏感）

　~* 不區分大小寫匹配

 ！取反

 ^~ 的作用是用來進行常規的字符串匹配檢查之后不做正則表達式的檢查

 

匹配實例

location = / {
    [ configuration A]
}

location / {
    [ configuration B]
}

location /documents/ {
    [ configuration C]
}

location ^~ /images/ {
    [ configuration D]
}

location ~* \.(gif|jpg|jpeg)$ {
    [ configuration E]
}

 

用戶請求的URL

http://www.abc.com/    匹配A    /
http://www.abc.com/    匹配B    /index.html
http://www.abc.com/documents/document.html    匹配C    /documents/document.html
http://www.abc.com/images/1.gif    匹配D    /images/1.gif
http://www.abc.com/documents/1.gif    匹配E  /documents/1.gif

 

Nginxd rewrite

\  進行轉義
^ 匹配輸入字符串的起始位置
$ 匹配輸入字符串的結束位置
* 匹配0次或多次
+ 匹配1次到多次
？ 匹配0次到1次
.   匹配除\n以外的任意字符
(pattern) 匹配括號內的字符

 

rewrite 指令最后一項參數flag標記說明

last　　本條規則匹配完成后，繼續向下匹配新的location URI規則
break　　本條規則匹配完成即終止，不在匹配后面的任何規則
redirect 返回302 臨時重定向， 瀏覽器地址欄會顯示跳轉后的URI地址
permanent  返回301 永久重定向， 瀏覽器地址欄會顯示跳轉后的URI地址

 

實例：

rewrite ^/(.*) http://www.abc.com/$1 permanent;

 

Nginx負載均衡

負載均衡模塊的組件

ngx_http_proxy_module  proxy代理模塊
ngx_http_upstream_module  負載均衡模塊

upstream www_server_pools {   #upstream 關鍵字 www_server_pools 集群組的名字，可以自己起名字
　　server 10.1.1.1:80 weight=5;     #server關鍵字    ip/域名：端口， 默認80  weight權重

　　server 10.1.1.1:80 weight=5;　　　　#如果用域名解析，需要在hosts里面有域名解析；或者內網有DNS

　　server www.abc.com:80 weight=5 backup;
　　server unix:/temp/backend3;   #指定socket文件/可以不寫

}

通過proxy_pass 功能把用戶的請求交由上面反向代理upstream定義的tornadoes服務器池處理

 

 

weight = 1 代表服務器權重，默認值是1， 權重數字表示接受的請求比例越大；

max_fails = 1 nginx嘗試連接主機失敗的次數，這個值是配合proxy_next_upstream、fastcgi_next_upstram 和 memcached_mext_upstream三個參數來使用的。

backup  熱備配置（RS節點的高可用），當當前激活的RS都失敗后會自動啟動熱備RS。這標志這個服務器作為備份服務器，如果主宕機，就會向他轉發請求。注意：

當負載調度算法為ip_hash時，后端服務器不能是weight和backup

fail_timeout = 10s  在max_fails定義失敗次數后，距離下次檢查的間隔時間，默認是10s；如果是5，就檢測5次，如果5次都是502，那么就等待10s在去檢查

down  標志這服務器永遠不可用，這個參數可以配合ip_hash使用

 

upstream 模塊調度算法

1.rr輪詢（默認調度算法，靜態調度算法）
相當於lvs的rr算法，如果后端節點服務器宕機（默認檢測80），自動會從節點地址池剔除

 

2.wrr（權重輪詢，靜態調度算法）


例子：
upstream pools{
　　server 192.168.1.1 weight=1;
　　server 192.168.1.2 weight=2;

}

 

3.ip_hash(靜態調度算法)
每個請求按客戶端的IP的hash進行分配；缺點可能道士分配不均無法保證1：1的負載均衡。比如客戶端的nat上網方式

例子：
upstream pools{
ip_hash;
server backend1.example.com;   #可以用ip
server backend2.example.com down;

}
注意：ip_hash時，不能有weight和backup

4.fair(動態調度算法)

此算法會根據后端節點服務器的響應時間來分配請求，響應時間短的優先分配
nginx 本身不支持fair調度算法，需要下載nginx的相關模塊upstram_fair

例子：
upstream pool{
server 192.168.1.1;

server 192.168.1.2;
fair;
}

5.least_conn
此算法會根據后端節點的連接數來決定分配情況，那個機器連接數少就分發。

6.url_hash算法
和ip_hash 類似，這個是根據訪問 URL的hash分配的。同樣也不能寫入weight等
必須安裝nginx的哈市模塊軟件包
例子：
upstream pools{
server queid1:1233;
server squid2:1233;
hash $request_uri;
hash_method crc32;
}

7.一致性hash算法

 

Nginx反向代理

 http_proxy_module 模塊

此模塊可以將請求轉發到另一台服務器，在實際的反向代理工作中，或通過location功能指定URL，然后在接受到的符合匹配的URI的請求通過proxy_pass 拋給定義好的upstream節點池

案例：

1.將匹配URI為name的請求拋給http://127.0.0.1/remote/

location /name/ {
proxy_pass http://127.0.0.1/remote/;
}

2.將匹配URI為name的請求應用指定的rewrite規則，然后拋給http://127.0.0.0.1.

location /name/ {
　　rewrite /name/([^/]+) /users?name=$1 break;
　　proxy_pass http://127.0.0.1;


}