Nginx 高階用法

Nginx 反向代理與負載均衡

正向代理的概念：
正向代理是指客戶端與目標伺服器之間增加一個代理伺服器，客戶端直接訪問代理伺服器，在由代理伺服器訪問目標伺服器並返回客戶端並返回 。這個過程當中客戶端需要知道代理伺服器地址，並配置連線。

反向代理的概念：
反向代理是指 客戶端訪問目標伺服器，在目標服務內部有一個統一接入閘道器將請求轉發至後端真正處理的伺服器並返回結果。這個過程當中客戶端不需要知道代理伺服器地址，代理對客戶端而言是透明的。

反向代理與正向代理的區別

Nginx代理基本配置
Nginx 代理只需要配置 location 中配置proxy_pass 屬性即可。其指向代理的伺服器地址。

# 正向代理到baidu 服務
location = /baidu.html {
         proxy_passhttp://www.baidu.com;
}

# 反向代理至 本機的8010服務
location /luban/ {
     proxy_passhttp://127.0.0.1:8010;  
}

代理相關引數：
proxy_pass # 代理服務
proxy_redirect off; # 是否允許重定向
proxy_set_header Host $host; # 傳 header 引數至後端服務
proxy_set_header X-Forwarded-For $remote_addr; # 設定request header 即客戶端IP 地址
proxy_connect_timeout 90; # 連線代理服務超時時間
proxy_send_timeout 90; # 請求傳送最大時間
proxy_read_timeout 90; # 讀取最大時間
proxy_buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;

負載均衡配置與引數解析
通過proxy_pass 可以把請求代理至後端服務，但是為了實現更高的負載及效能， 我們的後端服務通常是多個， 這個是時候可以通過upstream 模組實現負載均衡。

演示upstream 的實現。

upstream backend {     
   server 127.0.0.1:8010 weight=1;
   server 127.0.0.1:8080 weight=2;
 
  server 127.0.0.1:8030 weight=1 backup;
}
location / {
    proxy_pass http://backend;
}

upstream 相關引數:
l server 反向服務地址 加埠
l weight 權重
l max_fails 失敗多少次 認為主機已掛掉則，踢出
l fail_timeout 踢出後重新探測時間
l backup 備用服務
l max_conns 允許最大連線數
l slow_start 當節點恢復，不立即加入,而是等待 slow_start 後加入服務對列。

upstream 負載均衡演算法介紹
l ll+weight： 輪詢加權重 (預設)
l ip_hash : 基於Hash 計算 ,用於保持session一至性
l url_hash: 靜態資源快取,節約儲存，加快速度（第三方）
l least_conn ：最少連結（第三方）
l least_time ：最小的響應時間,計算節點平均響應時間，然後取響應最快的那個，分配更高權重（第三方）

Nginx 實現快取記憶體

1. 在http元素下新增快取區宣告。
   proxy_cache_path 快取路徑
   levels 快取層級及目錄位數
   keys_zone 快取區記憶體大小
   inactive 有效期
   max_size 硬碟大小

proxy_cache_path /data/nginx/cache_zy levels=1:2 keys_zone=cache_zy:500m inactive=20d max_size=1g;

2. 為指定location 設定快取策略。

#指定快取區
proxy_cache cache_zy;
#以全路徑md5值做做為Key 
proxy_cache_key $host$uri$is_args$args;
#對不同的HTTP狀態碼設定不同的快取時間
proxy_cache_valid 200 304 12h;

3. 快取引數詳細說明
   

4. 快取的清除：
   該功能可以採用第三方模組 ngx_cache_purge 實現。
   為nginx 新增 ngx_cache_purge 模組

#下載ngx_cache_purge 模組包 ,這裡nginx 版本為1.6.2 purge 對應2.0版
wgethttp://labs.frickle.com/files/ngx_cache_purge-2.3.tar.gz
#檢視已安裝模組
./sbin/nginx -V
#進入nginx安裝包目錄 重新安裝 --add-module為模組解壓的全路徑
./configure --prefix=/root/svr/nginx --with-http_stub_status_module --with-http_ssl_module  --add-module=/root/svr/packages/ngx_cache_purge-2.3
#重新編譯
make
#拷貝 安裝目錄/objs/nginx 檔案用於替換原nginx 檔案
#檢測檢視安裝是否成功
nginx -t 

清除配置：

ocation ~ /clear(/.*) {
  #允許訪問的IP
   allow           127.0.0.1;
   allow           192.168.0.193;
   #禁止訪問的IP
   deny            all;
   #配置清除指定快取區和路徑(與proxy_cache_key一至)
   proxy_cache_purge    cache_zy $host$1$is_args$args;
}                        

配置好以後 直接訪問 ：

#訪問生成快取檔案
http://www.luban.com/?a=1
#清除生成的快取,如果指定快取不存在 則會報404 錯誤。
http://www.luban.com/clear/?a=1

Nginx 效能引數調優

worker_processes number;
每個worker程式都是單執行緒的程式，它們會呼叫各個模組以實現多種多樣的功能。如果這些模組確認不會出現阻塞式的呼叫，那麼，有多少CPU核心就應該配置多少個程式；反之，如果有可能出現阻塞式呼叫，那麼需要配置稍多一些的worker程式。例如，如果業務方面會致使使用者請求大量讀取本地磁碟上的靜態資原始檔，而且伺服器上的記憶體較小，以至於大部分的請求訪問靜態資原始檔時都必須讀取磁碟（磁頭的定址是緩慢的），而不是記憶體中的磁碟快取，那麼磁碟I/O呼叫可能會阻塞住worker程式少量時間，進而導致服務整體效能下降。

每個worker 程式的最大連線數
語法：worker_connections number;
預設：worker_connections 1024

worker_cpu_affinity cpumask[cpumask……]
繫結Nginx worker程式到指定的CPU核心
為什麼要繫結worker程式到指定的CPU核心呢？假定每一個worker程式都是非常繁忙的，如果多個worker程式都在搶同一個CPU，那麼這就會出現同步問題。反之，如果每一個worker程式都獨享一個CPU，就在核心的排程策略上實現了完全的併發。
例如，如果有4顆CPU核心，就可以進行如下配置：
worker_processes 4;
worker_cpu_affinity 1000 0100 0010 0001;
注意worker_cpu_affinity配置僅對Linux作業系統有效。

Nginx worker程式優先順序設定
語法：worker_priority nice;
預設：worker_priority 0;
優先順序由靜態優先順序和核心根據程式執行情況所做的動態調整（目前只有±5的調整）共同決定。nice值是程式的靜態優先順序，它的取值範圍是–20～+19，–20是最高優先順序，+19是最低優先順序。因此，如果使用者希望Nginx佔有更多的系統資源，那麼可以把nice值配置得更小一些，但不建議比核心程式的nice值（通常為–5）還要小

Nginx worker程式可以開啟的最大控制程式碼描述符個數
語法：worker_rlimit_nofile limit;
預設：空
更改worker程式的最大開啟檔案數限制。如果沒設定的話，這個值為作業系統的限制。設定後你的作業系統和Nginx可以處理比“ulimit -a”更多的檔案，所以把這個值設高，這樣nginx就不會有“too many open files”問題了。

是否開啟accept鎖
語法：accept_mutex[on|off]
預設：accept_mutext on;
accept_mutex是Nginx的負載均衡鎖，當某一個worker程式建立的連線數量達到worker_connections配置的最大連線數的7/8時，會大大地減小該worker程式試圖建立新TCP連線的機會，accept鎖預設是開啟的，如果關閉它，那麼建立TCP連線的耗時會更短，但worker程式之間的負載會非常不均衡，因此不建議關閉它。

使用accept鎖後到真正建立連線之間的延遲時間
語法：accept_mutex_delay Nms;
預設：accept_mutex_delay 500ms;
在使用accept鎖後，同一時間只有一個worker程式能夠取到accept鎖。這個accept鎖不是堵塞鎖，如果取不到會立刻返回。如果只有一個worker程式試圖取鎖而沒有取到，他至少要等待accept_mutex_delay定義的時間才能再次試圖取鎖。