Nginx的生產環境常規使用

一、反向代理基本配置

1、概念

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

 

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

 

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

	正向代理	反向代理
代理服務器位置	客戶端與服務都能連接的們位置	目標服務器內部
主要作用	屏蔽客戶端IP、集中式緩存、解決客戶端不能直連服務端的問題。	屏蔽服務端內部實現、負載均衡、緩存。
應用場景	爬蟲、FQ、maven 的nexus 服務	Nginx 、Apache負載均衡應用

2、Nginx的代理基本配置

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

正向代理：

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

反向代理 ：

# 反向代理至 本機的8010服務 location /yufeng { proxy_pass http://127.0.0.1:8080/; 
}

正向代理和反向代理在技術的實現上沒有什么區別，需要看具體的應用場景是什么；

代理相關參數：

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; # nginx將請求發送給目標服務器的最大時間 proxy_read_timeout 90; # 從目標服務器讀取最大時間 proxy_buffer_size 4k; proxy_buffers 4 32k; proxy_busy_buffers_size 64k; proxy_temp_file_write_size 64k;

3、負載均衡配置與參數解析

（1）通過proxy_pass 可以把請求代理至后端服務，但是為了實現更高的負載及性能， 我們的后端服務通常是多個， 這個是時候可以通過 upstream 模塊實現負載均衡。

示例：

http { 
 upstream backend { server 127.0.0.1:8080 weigth=2; server 127.0.0.1:8010 weigth=1 max_fails=3 fail_timeout=3;
 server www.baidu.com backup;
 }  server { listen 80 default; server_name www.yufeng.com; root /usr1/nginx/yufeng/; # 代理服務器集群 location / { proxy_pass http://backend/;
 } } }

 （2）upstream 相關參數:

• service 反向服務地址 加端口；
• weight 權重；
• max_fails 失敗多少次 認為主機已掛掉，則踢出；
• fail_timeout 踢出后重新探測時間；
• slow_start 當節點恢復，不立即加入，而是等待 slow_start 后加入服務對列。 
• backup 備用服務； 當配置的集群所有服務掛掉了，啟用當前的配置項；
• max_conns 允許最大連接數；

（3）upstream 負載均衡算法介紹

• ll + weight：輪詢+權重（默認） 
• ip_hash：基於 hash 算法，可用於保持 session 一致性；弊端：有可能一個小區都用的一個公網的IP，IP計算哈希后再去取模，那請求都發送到同一個服務了，那壓力太大了；若有一個服務掛掉了，IP計算哈希后取模，那就會亂掉，部分session就丟失了；
• url_hash：用於靜態資源緩存，節約存儲，加快速度（第三方）； url計算hash之后將靜態資源存儲在不同的服務器上，但是其中一個服務器掛掉后就沒有資源了；
• least_conn： 最少鏈接（第三方）；
• least_time：最小的響應時間，計算節點平均響應時間，然后取響應最快的那個，分配更高權重（第三方）；

 

4、Nginx 靜態緩存基本配置

步驟一：在 http 元素下添加緩存區聲明

#proxy_cache_path 緩存路徑 #levels 緩存層級及目錄位數 #keys_zone 緩存區內存占用的大小 #inactive 有效期 #max_size 硬盤大小 proxy_cache_path /usr1/nginx/yufeng/cache levels=1:2 keys_zone=cache_yufeng:500m inactive=20d max_size=1g;

說明： levels=1:2，  若緩存的文件名(MD5)為：2a8e811742add9762ec4369e32afa6c3， 則文件的存儲目錄為：3/6c

 步驟二：為指定 location 設定緩存策略

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

注意： nginx配置文件要配置： user root

父元素	名稱	描述
http	proxy_cache_path	指定緩沖區的跟路徑
	levels	緩存目錄層級(最高3層)，每層1~2個字符表示。如 1:1:2 表示3層
	keys_zone	緩存塊名稱及內存塊大小。如 cache_item:500m。表示聲明一個名為 cache_item 大小為 500M 的緩存區。超出大小后最早的數據會被清除
	inactive	最長閑置時間； 如 10d 如果一個數據被閑置10天將會被清除
	max_size	緩存區硬盤最大值。超出閑置數據將被清除
location	proxy_cache	指定緩存區，對應 keys_zone 中設置的值
	proxy_cache_key	通過參數拼裝緩存key，如： $host$uri$is_args$args 則會以全路徑MD5值作為key
	proxy_cache_valid	為不同的緩存碼設置緩存有效期

 5、緩存的清除

 該功能可以采用第三方模塊 ngx_cache_purge 實現。

（1）為nginx 添加 ngx_cache_purge 模塊

#下載 ngx_cache_purge 模塊包 ,這里nginx 版本為1.6.2 purge 對應2.0版 wget http://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/nginx/models/ngx_cache_purge-2.0 #重新編譯 make #拷貝 安裝目錄/objs/nginx 文件用於替換原nginx 文件 #檢測查看安裝是否成功 nginx -t

（2）清除配置

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

配置好以后 直接訪問 ：

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

 

二、Nginx 性能參數調優

1、worker 進程數

語法：worker_processes number;

每個worker進程都是單線程的進程，它們會調用各個模塊以實現多種多樣的功能。如果這些模塊確認不會出現阻塞式的調用，那么，有多少CPU內核就應該配置多少個進程；反之，如果有可能出現阻塞式調用，那么需要配置稍多一些的worker進程。例如，如果業務方面會致使用戶請求大量讀取本地磁盤上的靜態資源文件，而且服務器上的內存較小，以至於大部分的請求訪問靜態資源文件時都必須讀取磁盤（磁頭的尋址是緩慢的），而不是內存中的磁盤緩存，那么磁盤I/O調用可能會阻塞住worker進程少量時間，進而導致服務整體性能下降。

2、每個worker 進程的最大連接數

語法：worker_connections number;

默認：worker_connections 1024;

3、綁定Nginx worker進程到指定的CPU內核

語法：worker_cpu_affinity cpumask[cpumask……]

　　為什么要綁定worker進程到指定的CPU內核呢？假定每一個worker進程都是非常繁忙的，如果多個worker進程都在搶同一個CPU，那么這就會出現同步問題。反之，如果每一個worker進程都獨享一個CPU，就在內核的調度策略上實現了完全的並發。

例如，如果有4顆CPU內核，就可以進行如下配置：

worker_processes 4;

worker_cpu_affinity 1000 0100 0010 0001;

注意： worker_cpu_affinity配置僅對 Linux 操作系統有效；

 

4、Nginx 進程優先級設置

語法：worker_priority nice;

默認：worker_priority 0;

　　優先級由靜態優先級和內核根據進程執行情況所做的動態調整（目前只有±5的調整）共同決定。nice值是進程的靜態優先級，它的取值范圍是–20～+19，–20是最高優先級，+19是最低優先級。因此，如果用戶希望Nginx占有更多的系統資源，那么可以把nice值配置得更小一些，但不建議比內核進程的nice值（通常為–5）還要小。

 

5、Nginx worker進程可以打開的最大句柄描述符個數

語法： worker_rlimit_nofile limit;

默認：空

　　更改worker進程的最大打開文件數限制。如果沒設置的話，這個值為操作系統的限制。設置后你的操作系統和Nginx可以處理比“ulimit -a”更多的文件，所以把這個值設高，這樣nginx就不會有“too many open files”問題了。

 

6、是否打開accept鎖

語法：accept_mutex[on|off]

默認：accept_mutext on;

　　accept_mutex是Nginx的負載均衡鎖，當某一個worker進程建立的連接數量達到worker_connections配置的最大連接數的7/8時，會大大地減小該worker進程試圖建立新TCP連接的機會，accept鎖默認是打開的，如果關閉它，那么建立TCP連接的耗時會更短，但worker進程之間的負載會非常不均衡，因此不建議關閉它。

 

7、使用accept鎖后到真正建立連接之間的延遲時間

語法：accept_mutex_delay Nms; 

默認：accept_mutex_delay 500ms; 

　　在使用accept鎖后，同一時間只有一個worker進程能夠取到accept鎖。這個accept鎖不是堵塞鎖，如果取不到會立刻返回。如果只有一個worker進程試圖取鎖而沒有取到，他至少要等待accept_mutex_delay定義的時間才能再次試圖取鎖。