nginx反向代理緩存服務(wù)器構(gòu)建

博主QQ：819594300

博客地址：http://zpf666.blog.51cto.com/

有什么疑問(wèn)的朋友可以聯(lián)系博主，博主會(huì)幫你們解答，謝謝支持！

代理服務(wù)可簡(jiǎn)單的分為正向代理和反向代理:

正向代理: 用于代理內(nèi)部網(wǎng)絡(luò)對(duì)Internet的連接請(qǐng)求(如×××/NAT),客戶端指定代理服務(wù)器,并將本來(lái)要直接發(fā)送給目標(biāo)Web服務(wù)器的HTTP請(qǐng)求先發(fā)送到代理服務(wù)器上, 然后由代理服務(wù)器去訪問(wèn)Web服務(wù)器,并將Web服務(wù)器的Response回傳給客戶端:

反向代理: 與正向代理相反,如果局域網(wǎng)向Internet提供資源,并讓Internet上的其他用戶可以訪問(wèn)局域網(wǎng)內(nèi)資源, 也可以設(shè)置一個(gè)代理服務(wù)器, 它提供的服務(wù)就是反向代理. 反向代理服務(wù)器接受來(lái)自Internet的連接,然后將請(qǐng)求轉(zhuǎn)發(fā)給內(nèi)部網(wǎng)絡(luò)上的服務(wù)器,并將Response回傳給Internet上請(qǐng)求連接的客戶端:

一、nginx反向代理：Web服務(wù)器的調(diào)度器

1、反向代理（ReverseProxy）方式是指以代理服務(wù)器來(lái)接受客戶端的連接請(qǐng)求，然后將請(qǐng)求轉(zhuǎn)發(fā)給網(wǎng)絡(luò)上的web服務(wù)器（可能是apache、nginx、tomcat、iis等），并將從web服務(wù)器上得到的結(jié)果返回給請(qǐng)求連接的客戶端，此時(shí)代理服務(wù)器對(duì)外就表現(xiàn)為一個(gè)服務(wù)器。

從上圖可以看出：反向代理服務(wù)器代理網(wǎng)站W(wǎng)eb服務(wù)器接收Http請(qǐng)求，對(duì)請(qǐng)求進(jìn)行轉(zhuǎn)發(fā)。而且nginx作為反向代理服務(wù)器可以根據(jù)用戶請(qǐng)求的內(nèi)容把請(qǐng)求轉(zhuǎn)發(fā)給后端不同的web服務(wù)器，例如靜動(dòng)分離，再例如在nginx上創(chuàng)建多個(gè)虛擬主機(jī)，這樣就成功的做到了在瀏覽器中輸入不同域名（url）的時(shí)候訪問(wèn)后端的不同web服務(wù)器或web群集。

2、反向代理的作用

①保護(hù)網(wǎng)站安全：任何來(lái)自Internet的請(qǐng)求都必須先經(jīng)過(guò)代理服務(wù)器；

②通過(guò)配置緩存功能加速Web請(qǐng)求：可以緩存真實(shí)Web服務(wù)器上的某些靜態(tài)資源，減輕真實(shí)Web服務(wù)器的負(fù)載壓力；

③實(shí)現(xiàn)負(fù)載均衡：充當(dāng)負(fù)載均衡服務(wù)器均衡地分發(fā)請(qǐng)求，平衡集群中各個(gè)服務(wù)器的負(fù)載壓力；

二、什么是nginx

1、nginx簡(jiǎn)介

Nginx是一款輕量級(jí)的網(wǎng)頁(yè)服務(wù)器、反向代理器以及電子郵件代理服務(wù)器。因它的穩(wěn)定性、豐富的功能集、示例配置文件和低系統(tǒng)資源的消耗而聞名。Nginx（發(fā)音同engine x），它是由俄羅斯程序員Igor Sysoev所開(kāi)發(fā)的。起初是供俄國(guó)大型的門戶網(wǎng)站及搜索引擎Rambler（俄語(yǔ)：Рамблер）使用。此軟件BSD-like協(xié)議下發(fā)行，可以在UNIX、GNU/Linux、BSD、Mac OS X、Solaris，以及MicrosoftWindows等操作系統(tǒng)中運(yùn)行。

Nginx的應(yīng)用現(xiàn)狀

Nginx已經(jīng)在俄羅斯最大的門戶網(wǎng)站── Rambler Media（www.rambler.ru）上運(yùn)行，同時(shí)俄羅斯超過(guò)20%的虛擬主機(jī)平臺(tái)采用Nginx作為反向代理服務(wù)器。

在國(guó)內(nèi)，已經(jīng)有淘寶、新浪博客、新浪播客、網(wǎng)易新聞、六間房、56.com、Discuz!、水木社區(qū)、豆瓣、YUPOO、海內(nèi)、迅雷在線 等多家網(wǎng)站使用 Nginx 作為Web服務(wù)器或反向代理服務(wù)器。

2、Nginx的核心特點(diǎn)

（1）跨平臺(tái)：Nginx 可以在大多數(shù)OS編譯運(yùn)行，而且也有Windows的版本；

（2）配置異常簡(jiǎn)單：非常容易上手。

（3）非阻塞、高并發(fā)連接：官方測(cè)試能夠支撐5萬(wàn)并發(fā)連接，在實(shí)際生產(chǎn)環(huán)境中跑到2～3萬(wàn)并發(fā)連接數(shù)。（這得益于Nginx使用了最新的epoll模型）；

注：

對(duì)于一個(gè)Web服務(wù)器來(lái)說(shuō)，首先看一個(gè)請(qǐng)求的基本過(guò)程：建立連接—接收數(shù)據(jù)—發(fā)送數(shù)據(jù)，在系統(tǒng)底層看來(lái) ：上述過(guò)程（建立連接—接收數(shù)據(jù)—發(fā)送數(shù)據(jù)）在系統(tǒng)底層就是讀寫事件。

如果采用阻塞調(diào)用的方式，當(dāng)讀寫事件沒(méi)有準(zhǔn)備好時(shí)，那么就只能等待，當(dāng)前線程被掛起，等事件準(zhǔn)備好了，才能進(jìn)行讀寫事件。

如果采用非阻塞調(diào)用的方式：事件馬上返回，告訴你事件還沒(méi)準(zhǔn)備好呢，過(guò)會(huì)再來(lái)吧。過(guò)一會(huì)，再來(lái)檢查一下事件，直到事件準(zhǔn)備好了為止，在這期間，你就可以先去做其它事情，然后再來(lái)看看事件好了沒(méi)。雖然不阻塞了，但你得不時(shí)地過(guò)來(lái)檢查一下事件的狀態(tài)，你可以做更多的事情了，但帶來(lái)的開(kāi)銷也是不小的。非阻塞調(diào)用指在不能立刻得到結(jié)果之前，該調(diào)用不會(huì)阻塞當(dāng)前線程

（4）事件驅(qū)動(dòng)：通信機(jī)制采用epoll模型，支持更大的并發(fā)連接。

非阻塞通過(guò)不斷檢查事件的狀態(tài)來(lái)判斷是否進(jìn)行讀寫操作，這樣帶來(lái)的開(kāi)銷很大，因此就有了異步非阻塞的事件處理機(jī)制。這種機(jī)制讓你可以同時(shí)監(jiān)控多個(gè)事件，調(diào)用他們是非阻塞的，但可以設(shè)置超時(shí)時(shí)間，在超時(shí)時(shí)間之內(nèi)，如果有事件準(zhǔn)備好了，就返回。這種機(jī)制解決了上面阻塞調(diào)用與非阻塞調(diào)用的兩個(gè)問(wèn)題。

以epoll模型為例：當(dāng)事件沒(méi)有準(zhǔn)備好時(shí)，就放入epoll(隊(duì)列)里面。如果有事件準(zhǔn)備好了，那么就去處理；當(dāng)事件沒(méi)有準(zhǔn)備好時(shí)，才在 epoll里面等著。這樣，我們就可以并發(fā)處理大量的并發(fā)了，當(dāng)然，這里的并發(fā)請(qǐng)求，是指未處理完的請(qǐng)求。線程只有一個(gè)，所以同時(shí)能處理的請(qǐng)求當(dāng)然只有一個(gè)了，只是在請(qǐng)求之間進(jìn)行不斷地切換而已，切換也是因?yàn)楫惒绞录礈?zhǔn)備好，而主動(dòng)讓出的。這里的切換是沒(méi)有任何代價(jià)，你可以理解為循環(huán)處理多個(gè)準(zhǔn)備好的事件。

多線程方式相比，這種事件處理方式是有很大的優(yōu)勢(shì)的，不需要?jiǎng)?chuàng)建線程，每個(gè)請(qǐng)求占用的內(nèi)存也很少，沒(méi)有上下文切換，事件處理非常的輕量級(jí)，并發(fā)數(shù)再多也不會(huì)導(dǎo)致無(wú)謂的資源浪費(fèi)（上下文切換）。對(duì)于apache服務(wù)器，每個(gè)請(qǐng)求會(huì)獨(dú)占一個(gè)工作線程，當(dāng)并發(fā)數(shù)上到幾千時(shí)，就同時(shí)有幾千的線程在處理請(qǐng)求了。這對(duì)操作系統(tǒng)來(lái)說(shuō)，是個(gè)不小的挑戰(zhàn)：因?yàn)榫€程帶來(lái)的內(nèi)存占用非常大，線程的上下文切換帶來(lái)的cpu開(kāi)銷很大，自然性能就上不 去，從而導(dǎo)致在高并發(fā)場(chǎng)景下性能下降嚴(yán)重。

總結(jié)：通過(guò)異步非阻塞的事件處理機(jī)制，Nginx實(shí)現(xiàn)由進(jìn)程循環(huán)處理多個(gè)準(zhǔn)備好的事件，從而實(shí)現(xiàn)高并發(fā)和輕量級(jí)。

（5）Master/Worker結(jié)構(gòu)：一個(gè)master進(jìn)程，生成一個(gè)或多個(gè)worker進(jìn)程。

注：Master-Worker設(shè)計(jì)模式主要包含兩個(gè)主要組件Master和Worker，Master維護(hù)著Worker隊(duì)列，將請(qǐng)求下發(fā)到多個(gè)Worker并行執(zhí)行，Worker主要進(jìn)行實(shí)際邏輯計(jì)算，并將結(jié)果返回給Master。

nginx采用這種進(jìn)程模型有什么好處？采用獨(dú)立的進(jìn)程，可以讓互相之間不會(huì)影響，一個(gè)進(jìn)程退出后，其它進(jìn)程還在工作，服務(wù)不會(huì)中斷，Master 進(jìn)程則很快重新啟動(dòng)新的Worker進(jìn)程。當(dāng)然，Worker進(jìn)程的異常退出，肯定是程序有bug了，異常退出，會(huì)導(dǎo)致當(dāng)前Worker上的所有請(qǐng)求失敗，不過(guò)不會(huì)影響到所有請(qǐng)求，所以降低了風(fēng)險(xiǎn)。

（6）內(nèi)存消耗?。禾幚泶蟛l(fā)的請(qǐng)求內(nèi)存消耗非常小。在3萬(wàn)并發(fā)連接下，開(kāi)啟的10個(gè)Nginx 進(jìn)程才消耗150M內(nèi)存（15M*10=150M）。

（7）內(nèi)置的健康檢查功能：如果 Nginx 代理的后端的某臺(tái) Web 服務(wù)器宕機(jī)了，不會(huì)影響前端訪問(wèn)。

（8）節(jié)省帶寬：支持 GZIP 壓縮，可以添加瀏覽器本地緩存的 Header 頭。

（9）穩(wěn)定性高：用于反向代理，宕機(jī)的概率微乎其微。

三、Nginx+apache構(gòu)筑Web服務(wù)器集群的負(fù)載均衡

nginx配置反向代理

配置nginx作為反向代理和負(fù)載均衡，同時(shí)利用其緩存功能，將靜態(tài)頁(yè)面在nginx緩存，以達(dá)到降低后端服務(wù)器連接數(shù)的目的并檢查后端web服務(wù)器的健康狀況。

1、安裝nginx

環(huán)境：

OS:centos7.2

nginx：192.168.1.6

apache1:192.168.1.7

apache2:192.168.1.8

安裝zlib-devel、pcre-devel等依賴包

注：

結(jié)合proxy和upstream模塊實(shí)現(xiàn)后端web負(fù)載均衡

使用proxy模塊實(shí)現(xiàn)靜態(tài)文件緩存

結(jié)合nginx默認(rèn)自帶的 ngx_http_proxy_module模塊 和ngx_http_upstream_module模塊實(shí)現(xiàn)后端服務(wù)器的健康檢查，也可以使用第三方模塊nginx_upstream_check_module

使用nginx-sticky-module擴(kuò)展模塊實(shí)現(xiàn)Cookie會(huì)話黏貼（保持會(huì)話）

使用ngx_cache_purge實(shí)現(xiàn)更強(qiáng)大的緩存清除功能

上面提到的2個(gè)模塊都屬于第三方擴(kuò)展模塊，需要提前下好源碼，然后編譯時(shí)通過(guò)--add-moudle=src_path一起安裝。

安裝nginx

上圖中內(nèi)容如下：

./configure--prefix=/usr/local/nginx1.10 --user=www --group=www--with-http_stub_status_module --with-http_realip_module --with-http_ssl_module--with-http_gzip_static_module --http-client-body-temp-path=/var/tmp/nginx/client--http-proxy-temp-path=/var/tmp/nginx/proxy--http-fastcgi-temp-path=/var/tmp/nginx/fcgi --with-pcre--add-module=../ngx_cache_purge-2.3 --with-http_flv_module --add-module=../nginx-goodies-nginx-sticky-module-ng-08a395c66e42&& make && make install

注：nginx的所有模塊必須在編譯的時(shí)候添加，不能再運(yùn)行的時(shí)候動(dòng)態(tài)加載。

解釋：

--add-module：添加第三方模塊

--with-http_gzip_static_module：添加gzip模塊

--http-client-body-temp-path=/var/tmp/nginx/client：添加緩存目錄，該目錄需要手動(dòng)創(chuàng)建

優(yōu)化nginx程序的執(zhí)行路徑

2、編寫nginx服務(wù)腳本：

#!/bin/bash

#chkconfig: 2345 99 20

#description: Nginx Service Control Script

PROG="/usr/local/nginx1.10/sbin/nginx"

PIDF="/usr/local/nginx1.10/logs/nginx.pid"

case"$1" in

  start)

   netstat -anplt |grep ":80"&> /dev/null && pgrep "nginx" &> /dev/null

   if [ $? -eq 0 ]

   then

     echo "Nginx service alreadyrunning."

   else

     $PROG -t &> /dev/null

     if [ $? -eq 0 ] ; then

       $PROG

       echo "Nginx service start success."

     else

     $PROG -t

     fi

   fi

   ;;

  stop)

   netstat -anplt |grep ":80"&> /dev/null && pgrep "nginx" &> /dev/null

   if [ $? -eq 0 ]

   then

    kill -s QUIT $(cat $PIDF)

    echo "Nginx service stopsuccess."

   else

    echo "Nginx service already stop"

   fi

   ;;

  restart)

    $0 stop

    $0 start

    ;;

  status)

   netstat -anplt |grep ":80"&> /dev/null && pgrep "nginx" &> /dev/null

   if [ $? -eq 0 ]

   then

     echo "Nginx service is running."

   else

     echo "Nginx is stop."

   fi

  ;;

  reload)

   netstat -anplt |grep ":80"&> /dev/null && pgrep "nginx" &> /dev/null

   if [ $? -eq 0 ]

   then

    $PROG -t &> /dev/null

    if [ $? -eq 0 ] ; then

      kill -s HUP $(cat $PIDF)

      echo "reload Nginx configsuccess."

    else

      $PROG -t

    fi

   else

    echo "Nginx service is not run."

   fi

    ;;

  *)

   echo "Usage: $0{start|stop|restart|reload}"

   exit 1

esac

注：如果你想在已安裝好的nginx上添加第三方模塊，依然需要重新編譯，但為了不覆蓋你原有的配置，請(qǐng)不要makeinstall，而是直接拷貝可執(zhí)行文件，解決辦法如下：

nginx   -V   //可以查看你當(dāng)前nginx已經(jīng)安裝的模塊

[root@wwwnginx-1.10.2]#./configure  --add-module=……   #你的第三方模塊

[root@wwwnginx-1.10.2] #make后不要make install,改為手動(dòng)拷貝，先備份

[root@wwwnginx-1.10.2] #cp /usr/local/nginx1.10/sbin/nginx/usr/local/nginx1.10/sbin/nginx.bak

[root@wwwnginx-1.10.2] #cp objs/nginx/usr/local/nginx1.10/sbin/nginx

配置nginx反向代理：反向代理+負(fù)載均衡+健康探測(cè)

查看nginx加載的模塊：

再次申明：nginx的所有模塊必須在編譯的時(shí)候添加，不能再運(yùn)行的時(shí)候動(dòng)態(tài)加載。

3、nginx-sticky-module模塊：

這個(gè)模塊的作用是通過(guò)cookie黏貼的方式將來(lái)自同一個(gè)客戶端（瀏覽器）的請(qǐng)求發(fā)送到同一個(gè)后端服務(wù)器上處理，這樣一定程度上可以解決多個(gè)backend servers的session同步的問(wèn)題 —— 因?yàn)椴辉傩枰?，而RR輪詢模式必須要運(yùn)維人員自己考慮session同步的實(shí)現(xiàn)。

另外內(nèi)置的 ip_hash 也可以實(shí)現(xiàn)根據(jù)客戶端IP來(lái)分發(fā)請(qǐng)求，但它很容易造成負(fù)載不均衡的情況，而如果nginx前面有CDN網(wǎng)絡(luò)或者來(lái)自同一局域網(wǎng)的訪問(wèn)，它接收的客戶端IP是一樣的，容易造成負(fù)載不均衡現(xiàn)象。nginx-sticky-module的cookie過(guò)期時(shí)間，默認(rèn)瀏覽器關(guān)閉就過(guò)期。

這個(gè)模塊并不合適不支持 Cookie 或手動(dòng)禁用了cookie的瀏覽器，此時(shí)默認(rèn)sticky就會(huì)切換成RR。它不能與ip_hash同時(shí)使用。

說(shuō)明：配置起來(lái)超級(jí)簡(jiǎn)單，一般來(lái)說(shuō)一個(gè)sticky指令就夠了。

相關(guān)信息可以查看官方文檔https://bitbucket.org/nginx-goodies/nginx-sticky-module-ng

4、load-balance其它調(diào)度方案：

這里順帶介紹一下nginx的負(fù)載均衡模塊支持的其它調(diào)度算法：

輪詢（默認(rèn)） ： 每個(gè)請(qǐng)求按時(shí)間順序逐一分配到不同的后端服務(wù)器，如果后端某臺(tái)服務(wù)器宕機(jī)，故障系統(tǒng)被自動(dòng)剔除，使用戶訪問(wèn)不受影響。Weight 指定輪詢權(quán)值，Weight值越大，分配到的訪問(wèn)機(jī)率越高，主要用于后端每個(gè)服務(wù)器性能不均的情況下。

ip_hash： 每個(gè)請(qǐng)求按訪問(wèn)IP的hash結(jié)果分配，這樣來(lái)自同一個(gè)IP的訪客固定訪問(wèn)一個(gè)后端服務(wù)器，有效解決了動(dòng)態(tài)網(wǎng)頁(yè)存在的session共享問(wèn)題。當(dāng)然如果這個(gè)節(jié)點(diǎn)不可用了，會(huì)發(fā)到下個(gè)節(jié)點(diǎn)，而此時(shí)沒(méi)有session同步的話就注銷掉了。

least_conn：請(qǐng)求被發(fā)送到當(dāng)前活躍連接最少的realserver上。會(huì)考慮weight的值。

url_hash： 此方法按訪問(wèn)url的hash結(jié)果來(lái)分配請(qǐng)求，使每個(gè)url定向到同一個(gè)后端服務(wù)器，可以進(jìn)一步提高后端緩存服務(wù)器的效率。Nginx本身是不支持url_hash的，如果需要使用這種調(diào)度算法，必須安裝Nginx 的hash軟件包nginx_upstream_hash 。

fair：這是比上面兩個(gè)更加智能的負(fù)載均衡算法。此種算法可以依據(jù)頁(yè)面大小和加載時(shí)間長(zhǎng)短智能地進(jìn)行負(fù)載均衡，也就是根據(jù)后端服務(wù)器的響應(yīng)時(shí)間來(lái)分配請(qǐng)求，響應(yīng)時(shí)間短的優(yōu)先分配。Nginx本身是不支持fair的，如果需要使用這種調(diào)度算法，必須下載Nginx的 upstream_fair 模塊。

5、負(fù)載均衡與健康檢查：

嚴(yán)格來(lái)說(shuō)，nginx自帶是沒(méi)有針對(duì)負(fù)載均衡后端節(jié)點(diǎn)的健康檢查的，但是可以通過(guò)默認(rèn)自帶的ngx_http_proxy_module 模塊和 ngx_http_upstream_module 模塊中的相關(guān)指令來(lái)完成當(dāng)后端節(jié)點(diǎn)出現(xiàn)故障時(shí)，自動(dòng)切換到下一個(gè)節(jié)點(diǎn)來(lái)提供訪問(wèn)。

weight ： 輪詢權(quán)值也是可以用在ip_hash的，默認(rèn)值為1

max_fails ： 允許請(qǐng)求失敗的次數(shù)，默認(rèn)為1。當(dāng)超過(guò)最大次數(shù)時(shí)，返回proxy_next_upstream 模塊定義的錯(cuò)誤。

fail_timeout ： 有兩層含義，一是在10s 時(shí)間內(nèi)最多容許2 次失??；二是在經(jīng)歷了 2 次失敗以后，10s時(shí)間內(nèi)不分配請(qǐng)求到這臺(tái)服務(wù)器。

6、nginx的proxy緩存使用：

緩存也就是將js、css、p_w_picpath等靜態(tài)文件從后端服務(wù)器緩存到nginx指定的緩存目錄下，既可以減輕后端服務(wù)器負(fù)擔(dān)，也可以加快訪問(wèn)速度，但這樣緩存及時(shí)清理成為了一個(gè)問(wèn)題，所以需要 ngx_cache_purge 這個(gè)模塊來(lái)在過(guò)期時(shí)間未到之前，手動(dòng)清理緩存。

proxy模塊中常用的指令時(shí)proxy_pass和proxy_cache.

nginx的web緩存功能的主要是由proxy_cache、fastcgi_cache指令集和相關(guān)指令集完成，proxy_cache指令負(fù)責(zé)反向代理緩存后端服務(wù)器的靜態(tài)內(nèi)容，fastcgi_cache主要用來(lái)處理FastCGI動(dòng)態(tài)進(jìn)程緩存。

相關(guān)選項(xiàng)說(shuō)明：

proxy_buffering on; 代理的時(shí)候，開(kāi)啟或關(guān)閉緩沖后端服務(wù)器的響應(yīng)。

當(dāng)開(kāi)啟緩沖時(shí)，nginx盡可能快地從被代理的服務(wù)器接收響應(yīng)，再將它存入緩沖區(qū)中。

proxy_temp_path ： 緩存臨時(shí)目錄。后端的響應(yīng)并不直接返回客戶端，而是先寫到一個(gè)臨時(shí)文件中，然后被rename一下當(dāng)做緩存放在 proxy_cache_path 。0.8.9版本以后允許temp和cache兩個(gè)目錄在不同文件系統(tǒng)上（分區(qū)），然而為了減少性能損失還是建議把它們?cè)O(shè)成一個(gè)文件系統(tǒng)上。

proxy_cache_path： 設(shè)置緩存目錄，目錄里的文件名是 cache_key 的MD5值。

levels=1:2keys_zone=my-cache:100m表示采用2級(jí)目錄結(jié)構(gòu)，第一層目錄只有一個(gè)字符，是由levels=1:2設(shè)置，總共二層目錄，子目錄名字由二個(gè)字符組成。Web緩存區(qū)名稱為my-cache，內(nèi)存緩存空間大小為100MB，這個(gè)緩沖zone可以被多次使用。文件系統(tǒng)上看到的緩存文件名類似于

/usr/local/nginx1.10/proxy_cache/c/29/b7f54b2df7773722d382f4809d65029c。

inactive=600 max_size=2g表示600分鐘沒(méi)有被訪問(wèn)的內(nèi)容自動(dòng)清除，硬盤最大緩存空間為2GB，超過(guò)這個(gè)大小將清除最近最少使用的數(shù)據(jù)。

需要在默認(rèn)情況，nginx不緩存從后端響應(yīng)的http頭中帶有Set-Cookie的對(duì)象。如果客戶端發(fā)送的請(qǐng)求帶有Cookie header，varnish將忽略緩存，直接將請(qǐng)求傳遞到后端。nginx中通過(guò)proxy_ignore_headers設(shè)置忽略它們，設(shè)置方法如下：

解決辦法： 

proxy_ignore_headersSet-Cookie;

proxy_hide_headerSet-Cookie;

proxy_cache ： 引用前面定義的緩存區(qū) my-cache

proxy_cache_key：定義如何生成緩存的鍵，設(shè)置web緩存的key值，nginx根據(jù)key值md5哈希存儲(chǔ)緩存

proxy_cache_valid ： 為不同的響應(yīng)狀態(tài)碼設(shè)置不同的緩存時(shí)間，比如200、302等正常結(jié)果可以緩存的時(shí)間長(zhǎng)點(diǎn)，而404、500等緩存時(shí)間設(shè)置短一些，這個(gè)時(shí)間到了文件就會(huì)過(guò)期，而不論是否剛被訪問(wèn)過(guò)。

add_header指令來(lái)設(shè)置responseheader, 語(yǔ)法: add_header name value;

$upstream_cache_status這個(gè)變量來(lái)顯示緩存的狀態(tài)，我們可以在配置中添加一個(gè)http頭來(lái)顯示這一狀態(tài)，

$upstream_cache_status包含以下幾種狀態(tài)：

·MISS 未命中，請(qǐng)求被傳送到后端

·HIT 緩存命中

·EXPIRED 緩存已經(jīng)過(guò)期請(qǐng)求被傳送到后端

·UPDATING 正在更新緩存，將使用舊的應(yīng)答

·STALE 后端將得到過(guò)期的應(yīng)答

expires ： 在響應(yīng)頭里設(shè)置Expires:或Cache-Control:max-age，返回給客戶端的瀏覽器緩存失效時(shí)間。

下面是nginx.conf實(shí)現(xiàn)nginx在前端做反向代理服務(wù)器的完整配置文件的例子，處理js、png等靜態(tài)文件，jsp/php等動(dòng)態(tài)請(qǐng)求轉(zhuǎn)發(fā)到其它服務(wù)器tomcat/apache。

user  www www;

worker_processes  4;

worker_cpu_affinity0001 0010 0100 1000;

error_log  logs/error.log;

#error_log  logs/error.log  notice;

#error_log  logs/error.log  info;

worker_rlimit_nofile10240;

pid        logs/nginx.pid;

events{

    use epoll;

    worker_connections  4096;

}

http{

    include       mime.types;

    default_type  application/octet-stream;

   log_format  main  '$remote_addr - $remote_user [$time_local]"$request" '

                      '$status $body_bytes_sent"$http_referer" '

                     '"$http_user_agent" "$http_x_forwarded_for"'

                     '"$upstream_cache_status"';

access_log  logs/access.log  main;

server_tokensoff;

    sendfile        on;

    #tcp_nopush     on;

    #keepalive_timeout  0;

    keepalive_timeout  65;

    #Compression Settings

    gzip on;

    gzip_comp_level 6;

    gzip_http_version 1.1;

    gzip_proxied any;

    gzip_min_length 1k;

    gzip_buffers 16 8k;

    gzip_types text/plain text/csstext/javascript application/json application/javascriptapplication/x-javascript application/xml;

    gzip_vary on;

    #end gzip

    # http_proxy Settings

    client_max_body_size   10m;

    client_body_buffer_size   128k;

    proxy_connect_timeout   75;

    proxy_send_timeout   75;

    proxy_read_timeout   75;

    proxy_buffer_size   4k;

    proxy_buffers   4 32k;

    proxy_busy_buffers_size   64k;

    proxy_temp_file_write_size  64k;

    proxy_buffering on;

    proxy_temp_path/usr/local/nginx1.10/proxy_temp;

    proxy_cache_path/usr/local/nginx1.10/proxy_cache levels=1:2 keys_zone=my-cache:100mmax_size=1000m inactive=600m max_size=2g;

    #load balance Settings

    upstream backend {

        sticky;

        server 192.168.1.7:80 weight=1max_fails=2 fail_timeout=10s;

        server 192.168.1.8:80 weight=1max_fails=2 fail_timeout=10s;

    }

    #virtual host Settings

    server {

        listen      80;

        server_name  localhost;

        charset utf-8;

        location  ~/purge(/.*) {

           allow 127.0.0.1;

           allow 192.168.1.0/24;

           deny all;

           proxy_cache_purge my-cache$host$1$is_args$args;

        }

        location / {

            index  index.php index.html index.htm;

            proxy_pass        http://backend;

            proxy_redirect off;

            proxy_set_header  Host $host;

            proxy_set_header  X-Real-IP $remote_addr;

            proxy_set_header  X-Forwarded-For  $proxy_add_x_forwarded_for;

            proxy_ignore_headers Set-Cookie;

           proxy_hide_header Set-Cookie;

            proxy_next_upstream error timeoutinvalid_header http_500 http_502 http_503 http_504;

        }

        location ~.*\.(gif|jpg|png|html|htm|css|js|ico|swf|pdf)(.*) {

           proxy_pass  http://backend;

           proxy_redirect off;

           proxy_set_header Host $host;

           proxy_set_header X-Real-IP$remote_addr;

           proxy_set_header X-Forwarded-For$proxy_add_x_forwarded_for;

           proxy_next_upstream error timeoutinvalid_header http_500 http_502 http_503 http_504;

           proxy_cache my-cache;

           add_header Nginx-Cache$upstream_cache_status;

           proxy_cache_valid 200 304 301 302 8h;

           proxy_cache_valid 404 1m;

           proxy_cache_valid any 1d;

           proxy_cache_key$host$uri$is_args$args;

           expires 30d;

        }

        location /nginx_status {

            stub_status on;

            access_log off;

            allow 192.168.1.0/24;

            deny all;

        }

    }

}

注：nginx代理服務(wù)器這里server_name  localhost;而后臺(tái)web服務(wù)器上每個(gè)服務(wù)器上都必須是ServerName www.benet.com。

常用指令說(shuō)明:

main全局配置:

woker_processes 4

在配置文件的頂級(jí)main部分，worker角色的工作進(jìn)程的個(gè)數(shù)，master進(jìn)程是接收并分配請(qǐng)求給worker處理。這個(gè)數(shù)值簡(jiǎn)單一點(diǎn)可以設(shè)置為cpu的核數(shù)grep ^processor /proc/cpuinfo | wc -l，也是 auto 值，如果開(kāi)啟了ssl和gzip更應(yīng)該設(shè)置成與邏輯CPU數(shù)量一樣甚至為2倍，可以減少I/O操作。如果nginx服務(wù)器還有其它服務(wù)，可以考慮適當(dāng)減少。

worker_cpu_affinity

也是寫在main部分。在高并發(fā)情況下，通過(guò)設(shè)置cpu粘性來(lái)降低由于多CPU核切換造成的寄存器等現(xiàn)場(chǎng)重建帶來(lái)的性能損耗。如worker_cpu_affinity0001 0010 0100 1000; （四核）。

附：

CPU工作狀況：（輸入 top 后，按1 查看）

上面的配置表示：4核CPU，開(kāi)啟4個(gè)進(jìn)程。0001表示開(kāi)啟第一個(gè)cpu內(nèi)核， 0010表示開(kāi)啟第二個(gè)cpu內(nèi)核，依次類推；有多少個(gè)核，就有幾位數(shù)，1表示該內(nèi)核開(kāi)啟，0表示該內(nèi)核關(guān)閉。

例如：

1、2核CPU，開(kāi)啟2個(gè)進(jìn)程

worker_processes  2;

worker_cpu_affinity01 10;

2、2核CPU，開(kāi)啟4進(jìn)程

worker_processes4;

worker_cpu_affinity01 10 01 10;

3、2核CPU，開(kāi)啟8進(jìn)程

worker_processes  8;

worker_cpu_affinity01 10 01 10 01 10 01 10;

4、8核CPU，開(kāi)啟2進(jìn)程

worker_processes  2;

worker_cpu_affinity10101010  01010101;

說(shuō)明：10101010表示開(kāi)啟了第2,4,6,8內(nèi)核，01010101表示開(kāi)始了1,3,5,7內(nèi)核http

通過(guò) apache 的ab測(cè)試查看nginx對(duì)CPU的使用狀況：

如果多個(gè)CPU內(nèi)核的利用率都相差不多，證明nginx己經(jīng)成功的利用了多核CPU。

測(cè)試結(jié)束后，CPU內(nèi)核的負(fù)載應(yīng)該都同時(shí)降低。

worker_connections 4096

寫在events部分。每一個(gè)worker進(jìn)程能并發(fā)處理（發(fā)起）的最大連接數(shù)（包含與客戶端或后端被代理服務(wù)器間等所有連接數(shù)）。

worker_rlimit_nofile 10240

寫在main部分。worker進(jìn)程的最大打開(kāi)文件數(shù)限制。默認(rèn)是沒(méi)有設(shè)置，如果沒(méi)設(shè)置的話，這個(gè)值為操作系統(tǒng)的限制(ulimit -n)。可以限制為操作系統(tǒng)最大的限制65535。把這個(gè)值設(shè)高，這樣nginx就不會(huì)有“too many open files”問(wèn)題了。

use epoll

寫在events部分。在Linux操作系統(tǒng)下，nginx默認(rèn)使用epoll事件模型，得益于此，nginx在Linux操作系統(tǒng)下效率相當(dāng)高。同時(shí)Nginx在OpenBSD或FreeBSD操作系統(tǒng)上采用類似于epoll的高效事件模型kqueue。

http服務(wù)器:

與提供http服務(wù)相關(guān)的一些配置參數(shù)。例如：是否使用keepalive啊，是否使用gzip進(jìn)行壓縮等。

sendfile on

開(kāi)啟高效文件傳輸模式。

keepalive_timeout 65 :長(zhǎng)連接超時(shí)時(shí)間，單位是秒，長(zhǎng)連接請(qǐng)求大量小文件的時(shí)候，可以減少重建連接的開(kāi)銷，如果設(shè)置時(shí)間過(guò)長(zhǎng)，用戶又多，長(zhǎng)時(shí)間保持連接會(huì)占用大量資源。

client_max_body_size 10m

允許客戶端請(qǐng)求的最大單文件字節(jié)數(shù)。如果有上傳較大文件，請(qǐng)?jiān)O(shè)置它的限制值

client_body_buffer_size 128k

緩沖區(qū)代理緩沖用戶端請(qǐng)求的最大字節(jié)數(shù)

server_tokens off;

隱藏nginx的版本號(hào)

模塊http_proxy：

這個(gè)模塊實(shí)現(xiàn)的是nginx作為反向代理服務(wù)器的功能，包括緩存功能

proxy_connect_timeout

nginx跟后端服務(wù)器連接超時(shí)時(shí)間(代理連接超時(shí))

proxy_read_timeout

定義從后端服務(wù)器讀取響應(yīng)的超時(shí)。此超時(shí)是指相鄰兩次讀操作之間的最長(zhǎng)時(shí)間間隔，而不是整個(gè)響應(yīng)傳輸完成的最長(zhǎng)時(shí)間。如果后端服務(wù)器在超時(shí)時(shí)間段內(nèi)沒(méi)有傳輸任何數(shù)據(jù)，連接將被關(guān)閉。

proxy_send_timeout

定義向后端服務(wù)器傳輸請(qǐng)求的超時(shí)。此超時(shí)是指相鄰兩次寫操作之間的最長(zhǎng)時(shí)間間隔，而不是整個(gè)請(qǐng)求傳輸完成的最長(zhǎng)時(shí)間。如果后端服務(wù)器在超時(shí)時(shí)間段內(nèi)沒(méi)有接收到任何數(shù)據(jù)，連接將被關(guān)閉。

proxy_buffer_size 4k

設(shè)置緩沖區(qū)的大小為size。nginx從被代理的服務(wù)器讀取響應(yīng)時(shí)，使用該緩沖區(qū)保存響應(yīng)的開(kāi)始部分。這部分通常包含著一個(gè)小小的響應(yīng)頭。該緩沖區(qū)大小默認(rèn)等于proxy_buffers指令設(shè)置的一塊緩沖區(qū)的大小，但它也可以被設(shè)置得更小。

proxy_buffers 8 4k

語(yǔ)法: proxy_buffers the_number is_size;

為每個(gè)連接設(shè)置緩沖區(qū)的數(shù)量為number，每塊緩沖區(qū)的大小為size。這些緩沖區(qū)用于保存從被代理的服務(wù)器讀取的響應(yīng)。每塊緩沖區(qū)默認(rèn)等于一個(gè)內(nèi)存頁(yè)的大小。這個(gè)值是4K還是8K，取決于平臺(tái)。

附：查看Linux內(nèi)存頁(yè)大小

[root@www~]# getconf PAGESIZE

4096

或

[root@www~]# getconf PAGE_SIZE

4096

proxy_busy_buffers_size 64k

高負(fù)荷下緩沖大?。J(rèn)大小是proxy_buffers指令設(shè)置單塊緩沖大小的2倍）

proxy_max_temp_file_size

當(dāng) proxy_buffers 放不下后端服務(wù)器的響應(yīng)內(nèi)容時(shí)，會(huì)將一部分保存到硬盤的臨時(shí)文件中，這個(gè)值用來(lái)設(shè)置最大臨時(shí)文件大小，默認(rèn)1024M。

proxy_temp_file_write_size 64k

當(dāng)緩存被代理的服務(wù)器響應(yīng)到臨時(shí)文件時(shí)，這個(gè)選項(xiàng)限制每次寫臨時(shí)文件的大小。

模塊http_gzip：

gzip on : 開(kāi)啟gzip壓縮輸出，減少網(wǎng)絡(luò)傳輸。

gzip_min_length 1k ： 設(shè)置允許壓縮的頁(yè)面最小字節(jié)數(shù)，頁(yè)面字節(jié)數(shù)從header頭得content-length中進(jìn)行獲取。建議設(shè)置成大于1k的字節(jié)數(shù)，小于1k可能會(huì)越壓越大。

gzip_buffers 4 16k： 設(shè)置系統(tǒng)獲取幾個(gè)單位的緩存用于存儲(chǔ)gzip的壓縮結(jié)果數(shù)據(jù)流。4 16k代表以16k為單位，按照原始數(shù)據(jù)大小以16k為單位的4倍申請(qǐng)內(nèi)存。如果沒(méi)有設(shè)置，默認(rèn)值是申請(qǐng)跟原始數(shù)據(jù)相同大小的內(nèi)存空間去存儲(chǔ)gzip壓縮結(jié)果

gzip_http_version 1.1 ： 用于識(shí)別 http 協(xié)議的版本，早期的瀏覽器不支持 Gzip 壓縮，用戶就會(huì)看到亂碼，所以為了支持前期版本加上了這個(gè)選項(xiàng)，如果你用了Nginx 的反向代理并期望也啟用 Gzip 壓縮的話，由于末端通信是 http/1.1，故請(qǐng)?jiān)O(shè)置為 1.1。

gzip_comp_level 6 ： gzip壓縮比，1壓縮比最小處理速度最快，9壓縮比最大但處理速度最慢(傳輸快但比較消耗cpu)

gzip_types ：匹配mime類型進(jìn)行壓縮，無(wú)論是否指定”text/html”類型總是會(huì)被壓縮的。

默認(rèn)值: gzip_types text/html (默認(rèn)不對(duì)js/css文件進(jìn)行壓縮)

#壓縮類型，匹配MIME類型進(jìn)行壓縮

#不能用通配符 text/*

#(無(wú)論是否指定)text/html默認(rèn)已經(jīng)壓縮

#設(shè)置哪壓縮種文本文件可參考 conf/mime.types

gzip_proxied any： Nginx作為反向代理的時(shí)候啟用，根據(jù)某些請(qǐng)求和應(yīng)答來(lái)決定是否在對(duì)代理請(qǐng)求的應(yīng)答啟用gzip壓縮，是否壓縮取決于請(qǐng)求頭中的“Via”字段，指令中可以同時(shí)指定多個(gè)不同的參數(shù)，意義如下：

off– 關(guān)閉所有的代理結(jié)果數(shù)據(jù)的壓縮

expired– 啟用壓縮，如果header頭中包含 “Expires” 頭信息

no-cache– 啟用壓縮，如果header頭中包含 “Cache-Control:no-cache” 頭信息

no-store– 啟用壓縮，如果header頭中包含 “Cache-Control:no-store” 頭信息

private– 啟用壓縮，如果header頭中包含 “Cache-Control:private” 頭信息

no_last_modified– 啟用壓縮,如果header頭中不包含“Last-Modified” 頭信息

no_etag– 啟用壓縮 ,如果header頭中不包含“ETag” 頭信息

auth– 啟用壓縮 , 如果header頭中包含“Authorization” 頭信息

any– 無(wú)條件啟用壓縮

gzip_vary on ：和http頭有關(guān)系，加個(gè)vary頭，給代理服務(wù)器用的，有的瀏覽器支持壓縮，有的不支持，所以避免浪費(fèi)不支持的也壓縮，所以根據(jù)客戶端的HTTP頭來(lái)判斷，是否需要壓縮。

模塊http_stream：

這個(gè)模塊通過(guò)一個(gè)簡(jiǎn)單的調(diào)度算法來(lái)實(shí)現(xiàn)客戶端IP到后端服務(wù)器的負(fù)載均衡，upstream后接負(fù)載均衡器的名字，后端realserver以 host:portoptions;方式組織在 {} 中。如果后端被代理的只有一臺(tái)，也可以直接寫在 proxy_pass 。

Location:

root /var/www/html

定義服務(wù)器的默認(rèn)網(wǎng)站根目錄位置。如果locationURL匹配的是子目錄或文件，root沒(méi)什么作用，一般放在server指令里面或/下。

index index.jsp index.html index.htm

定義路徑下默認(rèn)訪問(wèn)的文件名，一般跟著root放

proxy_pass http:/backend

請(qǐng)求轉(zhuǎn)向backend定義的服務(wù)器列表，即反向代理，對(duì)應(yīng)upstream負(fù)載均衡器。也可以proxy_pass http://ip:port。

proxy_redirect off;

指定是否修改被代理服務(wù)器返回的響應(yīng)頭中的location頭域跟refresh頭域數(shù)值

例如：

設(shè)置后端服務(wù)器“Location”響應(yīng)頭和“Refresh”響應(yīng)頭的替換文本。 假設(shè)后端服務(wù)器返回的響應(yīng)頭是 “Location: http://localhost:8000/two/some/uri/”，那么指令

proxy_redirecthttp://localhost:8000/two/ http://frontend/one/;

將把字符串改寫為

“Location:http://frontend/one/some/uri/”。

proxy_set_header Host $host;

允許重新定義或者添加發(fā)往后端服務(wù)器的請(qǐng)求頭。

Host的含義是表明請(qǐng)求的主機(jī)名，nginx反向代理服務(wù)器會(huì)向后端真實(shí)服務(wù)器發(fā)送請(qǐng)求，并且請(qǐng)求頭中的host字段重寫為proxy_pass指令設(shè)置的服務(wù)器。因?yàn)閚ginx作為反向代理使用，而如果后端真實(shí)的服務(wù)器設(shè)置有類似防盜鏈或者根據(jù)http請(qǐng)求頭中的host字段來(lái)進(jìn)行路由或判斷功能的話，如果反向代理層的nginx不重寫請(qǐng)求頭中的host字段，將會(huì)導(dǎo)致請(qǐng)求失敗。

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

后端的Web服務(wù)器可以通過(guò)X-Forwarded-For獲取用戶真實(shí)IP

X_Forward_For字段表示該條http請(qǐng)求是有誰(shuí)發(fā)起的？如果反向代理服務(wù)器不重寫該請(qǐng)求頭的話，那么后端真實(shí)服務(wù)器在處理時(shí)會(huì)認(rèn)為所有的請(qǐng)求都來(lái)自反向代理服務(wù)器，如果后端有防***策略的話，那么機(jī)器就被封掉了。因此，在配置用作反向代理的nginx中一般會(huì)增加兩條配置，修改http的請(qǐng)求頭：

proxy_set_headerHost $host;

proxy_set_headerX-Forward-For $remote_addr;

proxy_next_upstreamerror timeout invalid_header http_500 http_502 http_503 http_504;

增加故障轉(zhuǎn)移，如果后端的服務(wù)器返回502、504、執(zhí)行超時(shí)等錯(cuò)誤，自動(dòng)將請(qǐng)求轉(zhuǎn)發(fā)到upstream負(fù)載均衡池中的另一臺(tái)服務(wù)器，實(shí)現(xiàn)故障轉(zhuǎn)移。

proxy_set_header X-Real-IP $remote_addr;

web服務(wù)器端獲得用戶的真實(shí)ip但是，實(shí)際上要獲得用戶的真實(shí)ip，也可以通過(guò)X-Forward-For

7、驗(yàn)證：nginx反向代理的緩存功能、負(fù)載均衡及健康檢查

說(shuō)明：

1）下面我們來(lái)測(cè)試一下緩存功能

如果在緩存時(shí)間之內(nèi)需要更新被緩存的靜態(tài)文件怎么辦呢，這時(shí)候就需要手動(dòng)來(lái)清除緩存了。

ngx_cache_pure清除緩存模塊使用說(shuō)明

用谷歌瀏覽器測(cè)試的時(shí)候，可以按F12調(diào)用開(kāi)發(fā)工具，選擇Network選項(xiàng)，我們可以看到，Response Headers，在這里我們可以看到，我們請(qǐng)求的是否是緩存。

說(shuō)明：第一次訪問(wèn)是MISS，刷新一下這個(gè)頁(yè)面就是HIT命中了。

從圖中我們可以看到，我們?cè)L問(wèn)的服務(wù)器是192.168.1.6，緩存命中。

也可以查看緩存目錄或nginx的訪問(wèn)日志。

清除緩存:

上述配置的proxy_cache_purge指令用于方便的清除緩存，但必須按照第三方的ngx_cache_purge 模塊才能使用

使用 ngx_cache_purge 模塊清除緩存（直接刪除緩存目錄下的文件也算一種辦法）：

GET方式請(qǐng)求URL

即使用配置文件中的location ~ /purge(/.*)

瀏覽器訪問(wèn)http://192.168.1.6/purge/your/may/path來(lái)清除緩存。

緩存清除成功。

備注：

      （1）purge是ngx_cache_pure 模塊指令

      （2）your/may/path是要清除的緩存文件URL路徑

2）若只有一臺(tái)客戶端要驗(yàn)證負(fù)載均衡和健康檢查可以先關(guān)掉緩存功能和保持session會(huì)話。

測(cè)試：

驗(yàn)證健康檢查：

首先關(guān)閉一臺(tái)后端的web服務(wù)器的web服務(wù)：

開(kāi)始驗(yàn)證：

中間不卡頓，一直訪問(wèn)的是apache2的網(wǎng)頁(yè)。

重新啟動(dòng)宕機(jī)的apache1的web服務(wù):

再次驗(yàn)證：

又可以來(lái)回切換的正常訪問(wèn)了。

在后端服務(wù)器上查看訪問(wèn)日志：

可以看見(jiàn)，訪問(wèn)日志記錄的訪問(wèn)者是nginx反向代理服務(wù)器的IP，那怎么讓它記錄的是客戶機(jī)的真是IP，而不是nginx代理服務(wù)器的呢？

解決辦法如下：

再次查看：

注：192.168.1.4是我客戶機(jī)的IP。