Nginx反向代理+緩存開啓+url重寫+負載均衡(帶健康探測)的部署記錄
在平常運維工做中，運維人員會時常使用到nginx的反向代理，負載均衡以及緩存等功能來優化web服務性能。
廢話很少說，下面對測試環境下的nginx反向代理+緩存開啓+url重寫+負載均衡(帶健康探測)搭建過程作一記錄： php
1、後端的Real Server的準備html
兩臺RS服務器(192.168.1.104/192.168.1.105)要事先配置好nginx。
而且nginx訪問均是用ip訪問便可，方便實驗效果！前端
2、nginx代理服務器192.168.1.103（假設外網ip是111.112.114.23）的配置node
1.nginx反向代理和緩存linux
0）安裝依賴軟件（若是是ubuntu系統，則sudo apt-get update && sudo apt-get upgrade && sudo apt-get install libpcre3 libpcre3-dev zlib1g-dev libssl-dev build-essential openssl libssl0.9.8 libssl-dev）
[root@node1 ~]# yum install -y pcre pcre-devel openssl openssl-devel gcc nginx
1）首先添加用戶nginx，實現以之運行nginx服務進程：
[root@node1 ~]# groupadd -r nginx
[root@node1 ~]# useradd -r -g nginx -s /bin/false -M nginx #-M參數表示建立用戶時不建立用戶家目錄web
2）接着開始編譯和安裝：
[root@node1 ~]# cd /usr/loca/src
[root@node1 src]# wget http://nginx.org/download/nginx-1.8.0.tar.gz
[root@node1 src]# tar -zxvf nginx-1.8.0.tar.gz
[root@node1 src]# cd nginx-1.8.0
[root@node1 nginx-1.8.0]# ./configure --prefix=/usr/local/nginx --user=nginx --group=nginx --with-http_ssl_module --with-http_flv_module --with-http_stub_status_module --with-http_gzip_static_module --with-pcre
[root@node1 src]# make && make install 正則表達式
#以上編譯安裝nginx後，--http-client-body-temp-path、--http-proxy-temp-path、--http-fastcgi-temp-path、--http-uwsgi-temp-path、--http-scgi-temp-path默認的路徑就在/usr/local/nginx下，分別是client_body_temp、proxy_temp、fastcgi_temp、scgi_temp、uwsgi_tempubuntu
[root@node1 src]# cd /usr/local/nginx/
[root@node1 nginx]# ls
conf html logs sbin
[root@node1 nginx]# /usr/local/nginx/sbin/nginx //nginx啓動後，就會出現下面的目錄
[root@node1 nginx]# ls /usr/local/nginx/
client_body_temp conf fastcgi_temp html logs proxy_temp sbin scgi_temp uwsgi_tempvim
3）反代的實現，和緩存的開啓（可參考：nginx緩存配置的操做記錄梳理）
[root@node1 src]# vim /usr/local/nginx/conf/nginx.conf
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
#要想開啓nginx的緩存功能，須要添加此處的兩行內容！
#這一行分別表示：定義緩存存儲目錄,手動建立；緩存級別,表示緩存目錄的第一級目錄是1個字符，第二級目錄是2個字符；內核中創建用於緩存緩存數據源數據的空間，查找緩存的時候，先從這個內核空間中找到，緩存數據的源數據，而後再到對應目錄中查找緩存；這一行分別表示：緩存空間最大值；緩存的數據，60分鐘內沒有被訪問過就刪除
proxy_cache_path /var/www/cache levels=1:2 keys_zone=mycache:20m max_size=2048m inactive=60m;
#這一行分別表示：建立緩存的時候可能生成一些臨時文件存放的位置，自動建立
proxy_temp_path /var/www/cache/tmp;
server {
listen 80;
server_name localhost;
location / {
#root html;
#index index.html index.htm;
proxy_pass http://192.168.1.104/; #代理哪一個web服務器
proxy_cache mycache; #內存緩存源數據空間名字，對應咱們前面的設定
proxy_cache_valid 200 302 60m; #頁面返回碼爲200 302 的緩存60分
proxy_cache_valid 404 1m; #頁面錯誤響應嗎404緩存時間1分
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
[root@node1 src]# mkdir /var/www/cache
[root@node1 src]# /usr/local/nginx/sbin/nginx
4）驗證結果
訪問http://111.112.114.23，則顯示的是http://192.168.1.104的訪問結果（如上配置，RS2的反向代理相似）
---------------------------------------------------------------------------------------------------------
再看以下的一個實例配置（nginx.conf文件中已開啓緩存功能）(max_fails默認值爲1，fail_timeout默認值爲10s，鏈接失敗的情形由proxy_next_upstream 指定)
upstream LB-WWW {
ip_hash;
server 192.168.1.101:80 max_fails=3 fail_timeout=30s weight=100; #max_fails = 3 爲容許失敗的次數，默認值爲1
server 192.168.1.102:80 max_fails=3 fail_timeout=30s weight=100; #fail_timeout = 30s（也能夠是fail_timeout = 30，即後面的秒單位不帶） 當max_fails次失敗後，暫停將請求分發到該後端服務器的時間
server 192.168.1.118:80 max_fails=3 fail_timeout=30s weight=50; #因爲這三臺機器中，前兩臺配置高，後一臺118機器配置低點，三臺機器開啓的nginx線上數是同樣的，因此118機器設置的weight權重低。
} #weight權限設置低，命中率就會低，這樣機器壓力就會減輕（如果權重不設置低點，也能夠經過減小nginx線程數來減小機器壓力）；
server {
listen 80;
server_name www.wangshibo.com;
access_log /usr/local/nginx/logs/www-access.log main;
error_log /usr/local/nginx/logs/www-error.log;
location / {
proxy_pass http://LB-WWW;
proxy_redirect off ;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header REMOTE-HOST $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_connect_timeout 300; #跟後端服務器鏈接超時時間，發起握手等候響應時間
proxy_send_timeout 300; #後端服務器回傳時間，就是在規定時間內後端服務器必須傳完全部數據
proxy_read_timeout 600; #鏈接成功後等待後端服務器的響應時間，已經進入後端的排隊之中等候處理
proxy_buffer_size 256k; #代理請求緩衝區,會保存用戶的頭信息以供nginx進行處理
proxy_buffers 4 256k; #同上，告訴nginx保存單個用幾個buffer最大用多少空間
proxy_busy_buffers_size 256k; #若是系統很忙時候能夠申請最大的proxy_buffers
proxy_temp_file_write_size 256k; #proxy緩存臨時文件的大小
proxy_next_upstream error timeout invalid_header http_500 http_503 http_404;
proxy_max_temp_file_size 128m;
proxy_cache mycache; #內存緩存源數據空間名字，對應咱們前面的設定
proxy_cache_valid 200 302 60m;
proxy_cache_valid 404 1m;
}
}
proxy_set_header參數解釋
1）proxy_redirect off
語法：proxy_redirect [ default|off|redirect replacement ]
默認值：proxy_redirect default
使用字段：http, server, location
proxy_redirect功能比較強大,其做用是對發送給客戶端的URL進行修改。
若是須要修改從被代理服務器傳來的應答頭中的"Location"和"Refresh"字段，能夠用這個指令設置。
設置爲off，表示禁止全部的proxy_redirect指令.
假設被代理服務器返回Location字段爲：http://localhost:8000/two/some/uri/
這個指令：
proxy_redirect http://localhost:8000/two/ http://frontend/one/;
將Location字段重寫爲http://frontend/one/some/uri/。
在代替的字段中能夠不寫服務器名：
proxy_redirect http://localhost:8000/two/ /;
這樣就使用服務器的基本名稱和端口，即便它來自非80端口。
若是使用「default」參數，將根據location和proxy_pass參數的設置來決定。
例以下列兩個配置等效：
location /one/ {
proxy_pass http://upstream:port/two/;
proxy_redirect default;
}
location /one/ {
proxy_pass http://upstream:port/two/;
proxy_redirect http://upstream:port/two/ /one/;
}
在指令中可使用一些變量：
proxy_redirect http://localhost:8000/ http://$host:$server_port/;
這個指令有時能夠重複：
proxy_redirect default;
proxy_redirect http://localhost:8000/ /;
proxy_redirect ;
/;
參數off將在這個字段中禁止全部的proxy_redirect指令：
proxy_redirect off;
proxy_redirect default;
proxy_redirect http://localhost:8000/ /;
proxy_redirect ;
/;
利用這個指令能夠爲被代理服務器發出的相對重定向增長主機名：
---------------------------------------------------------------------------------------------------
實例說明：
好比在作nginx反向代理時出了一點點問題，原來後端節點用的端口是8080，經過反向代理後，使用wireshark抓包發現location頭域數值爲http://192.168.1.154:8080/huihui/，
若是把這個返回給客戶端確定是不能夠的，看起來彆扭並且還暴露了後端節點的具體信息。因此在這裏用到了nginx的proxy_redirect指定修改被代理服務器返回的響應頭中的location頭域跟refresh頭域數值。
前期配置（暴露了後端節點信息）
[root@localhost nginx]# cat test.conf
server {
listen 80;
server_name www.wangshibo.com;
location / {
proxy_pass http://192.168.1.154:8080;
proxy_redirect off;
}
}
此時咱們經過curl查看結果得出
[root@localhost nginx]# curl -I http://www.wangshibo.com/huihui
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Thu, 24 Dec 2015 12:02:00 GMT
Content-Type: text/html; charset=iso-8859-1
Connection: keep-alive
Location: http://192.168.1.154:8080/huihui/
這裏location爲帶有後端服務器實際地址跟端口的響應頭信息，這樣在實際線上是不容許的。
因此這裏須要經過proxy_redirect將被代理服務器的響應頭中的location字段進行修改後返回給客戶端
修改後的配置：
[root@localhost nginx]# cat test.conf
server {
listen 80;
server_name www.wangshibo.com;
location / {
proxy_pass http://192.168.1.154:8080;
proxy_redirect http://192.168.1.154:8080/huihui/ http://www.wangshibo.com/huihui/;
}
server {
listen 80;
server_name www.wangshibo.com;
location / {
proxy_pass http://192.168.1.154:8080;
proxy_redirect ~^http://192.168.1.154:8080(.*) http://www.wangshibo.com$1;
}
則curl查看返回結果
[root@localhost nginx]# curl -I http://www.wangshibo.com/huihui
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Thu, 24 Dec 2015 12:08:34 GMT
Content-Type: text/html; charset=iso-8859-1
Connection: keep-alive
Location: http://www.wangshibo.com/huihui/
此時查看location已經變成了咱們想要的結果了。 此時經過replacement 301重定向到了咱們新的頁面
---------------------------------------------------------------------------------------------------
2）proxy_set_header Host $host;
容許從新定義或添加字段傳遞給代理服務器的請求頭。該值能夠包含文本、變量和它們的組合。在沒有定義proxy_set_header時會繼承以前定義的值。
默認狀況下，只有兩個字段被重定義：
proxy_set_header Host $proxy_host;
proxy_set_header Connection close;
實例說明：
nginx對於upstream默認使用的是基於IP的轉發，以下配置：
[root@localhost nginx]# cat test.conf
upstream backend {
server 127.0.0.1:8080;
}
upstream china {
server china.wangshibo.com;
}
server {
listen 80;
server_name www.wangshibo.com;
proxy_set_header Host $http_host;
proxy_set_header x-forwarded-for $remote_addr;
proxy_buffer_size 64k;
proxy_buffers 32 64k;
charset utf-8;
access_log logs/host.access.log main;
location = /50x.html {
root html;
}
location / {
proxy_pass backend ;
}
location = /customer/straightcustomer/download {
proxy_pass http://china;
proxy_set_header Host $proxy_host;
}
}
當匹配到/customer/straightcustomer/download時，使用china處理，到upstream就匹配到china.wangshibo.com，這裏直接轉換成IP進行轉發了。
假如china.wangshibo.com是在另外一臺nginx下配置的，ip爲10.22.10.116，則$proxy_host則對應爲10.22.10.116。
此時至關於設置了Host爲10.22.10.116。若是想讓Host是china.wangshibo.com，則進行以下設置：
proxy_set_header Host china.wangshibo.com;
若是不想改變請求頭「Host」的值，能夠這樣來設置：
proxy_set_header Host $http_host;
可是，若是客戶端請求頭中沒有攜帶這個頭部，那麼傳遞到後端服務器的請求也不含這個頭部。 這種狀況下，更好的方式是使用$host變量——它的值在請求包含「Host」請求頭時爲「Host」字段的值，在請求未攜帶「Host」請求頭時爲虛擬主機的主域名：
proxy_set_header Host $host;
此外，服務器名能夠和後端服務器的端口一塊兒傳送：
proxy_set_header Host $host:$proxy_port;
若是某個請求頭的值爲空，那麼這個請求頭將不會傳送給後端服務器：
proxy_set_header Accept-Encoding "";
3）有了下面三行配置，就能夠在web的後端節點服務器端得到客戶端用戶的真實ip。
proxy_set_header X-Real-IP $remote_addr; //後端節點機器獲取客戶端真實ip的第一種方案
proxy_set_header REMOTE-HOST $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; //後端節點機器獲取客戶端真實ip的第二中方案。固然這兩種方案也能夠一塊兒配置！
其中這個X-real-ip是一個自定義的變量名，名字能夠隨意取，這樣作完以後，用戶的真實ip就被放在X-real-ip這個變量裏了，而後，在web端能夠這樣獲取：
request.getAttribute("X-real-ip")
remote_addr 表明客戶端的ip，但它的值不是由客戶端提供的，而是服務器端根據客戶端的ip指定的，當你的瀏覽器訪問某個網站時，假設中間沒有任何代理，那麼網站的web服務器（好比nginx）就會把remote_addr設置爲
你的機器ip；若是你使用了代理，那麼你的瀏覽器會先訪問這個代理，而後再由這個代理轉發到網站，這樣web服務器就會把remote_addr設爲這臺代理機器的ip。
x_forwarded_for 正如上面所述，當你使用了代理時，web服務器就不知道你的真實ip了。爲了不這個狀況，代理服務器一般會增長一個叫作x_forwarded_for的頭消息，把鏈接它的客戶端ip（即你的上網機器的ip）
加到這個頭消息裏，這樣就能保證網站的web服務器能得到真實ip。
使用haproxy作反向代理
一般網站爲了支撐更大的訪問，會增長不少web服務器，並在這些服務器前面增長一個反向代理（如haproxy）它能夠把負載均衡的分佈到這些服務器上。你的瀏覽器訪問的首先是這臺反向代理服務器，它再把
你的請求轉發到後面的web服務器上，這就使得web服務器會把remote_addr設爲這臺反向代理服務器的ip，爲了能讓你的程序得到真實的客戶端ip，就須要給haproxy增長下面的配置：
option forwardfor
它的做用就像上面說的，增長一個x_forwarded_for的頭信息，把你上網機器的ip添加進去。
-----------------------------------------------------------
實際上要得到用戶的真實ip，不是隻有這一個方法，下面咱們繼續看
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
這裏有個X-Forwarded-For變量，這是一個squid開發的，用於識別經過HTTP代理或負載平衡器原始IP一個鏈接到Web服務器的客戶機地址的非rfc標準，若是有作X-Forwarded-For設置的話,
每次通過proxy轉發都會有記錄,格式就是client1, proxy1, proxy2,以逗號隔開各個地址，因爲他是非rfc標準，因此默認是沒有的，須要強制添加，在默認狀況下通過proxy轉發的請求，
在後端看來遠程地址都是proxy端的ip 。也就是說在默認狀況下咱們使用request.getAttribute("X-Forwarded-For")獲取不到用戶的ip，若是咱們想要經過這個變量得到用戶的ip，
這樣配置的意思是：
增長一個$proxy_add_x_forwarded_for到X-Forwarded-For裏去，注意是增長，而不是覆蓋，固然因爲默認的X-Forwarded-For值是空的，因此咱們總感受X-Forwarded-For的值就等於$proxy_add_x_forwarded_for的值，
實際上當你搭建兩臺nginx在不一樣的ip上，而且都使用了這段配置，那你會發如今web服務器端經過request.getAttribute("X-Forwarded-For")得到的將會是客戶端ip和第一臺nginx的ip。
那麼$proxy_add_x_forwarded_for又是什麼？
$proxy_add_x_forwarded_for變量包含客戶端請求頭中的"X-Forwarded-For"，與$remote_addr兩部分，他們之間用逗號分開。
舉個例子，有一個web應用，在它以前經過了兩個nginx轉發，www.linuxidc.com 即用戶訪問該web經過兩臺nginx。
在第一臺nginx中,使用
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
如今的$proxy_add_x_forwarded_for變量的"X-Forwarded-For"部分是空的，因此只有$remote_addr，而$remote_addr的值是用戶的ip，因而賦值之後，X-Forwarded-For變量的值就是用戶的真實的ip地址了。
到了第二臺nginx，使用
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
如今的$proxy_add_x_forwarded_for變量，X-Forwarded-For部分包含的是用戶的真實ip，$remote_addr部分的值是上一臺nginx的ip地址，因而經過這個賦值之後如今的X-Forwarded-For的值就變成了「用戶的真實ip，
第一臺nginx的ip」，這樣就清楚了吧。最後咱們看到還有一個$http_x_forwarded_for變量，這個變量就是X-Forwarded-For，因爲以前咱們說了，默認的這個X-Forwarded-For是爲空的，
因此當咱們直接使用proxy_set_header X-Forwarded-For $http_x_forwarded_for時會發現，web服務器端使用request.getAttribute("X-Forwarded-For")得到的值是null。若是想要經過request.getAttribute("X-Forwarded-For")得到用戶ip，就必須先使用proxy_set_header
X-Forwarded-For $proxy_add_x_forwarded_for;這樣就能夠得到用戶真實ip。
---------------------------------------------------------------------------------------------------------
2.url的重寫
-----------------------------------------------------------------------------
介紹下url重寫的格式，寫在配置文件中
rewrite regex replacement [flag]
Regex：被代替的原URL路徑，能夠是莫須有的，不存在的，支持正則表達式
Replacement：用來實現代替的URL路徑，必須真實存在的
Flag：標誌位，定義URL重寫後進行的操做，有4種，分別是：
a)
last:匹配重寫後的URL，再一次對URL重寫規則進行匹配，當使用last的須要注意的是以下：
rewrite /images/.*\.jpg /images/a.jpg last;
這樣寫的話，將會形成死循環。
b）
break：匹配重寫URL後，終止匹配，直接使用
c）
redirect：臨時重定向，返回代碼302
d）
permanent：永久重定向，返回代碼301
-----------------------------------------------------------------------------
下面是nginx配置文件中的配置，簡單實現url的重寫配置(能夠在vhosts虛擬主機配置裏設置)
[root@node1 src]# vim /usr/local/nginx/conf/nginx.conf
...............
server {
listen 80;
server_name localhost;
root /var/www/html;
index index.html index.htm;
location / {
rewrite /abc http://www.huanqiu.com break; #本機站點目錄下並不須要建立abc這個目錄，對其的訪問都重寫到http://www.huanqiu.com
}
location /text {
rewrite / http://china.huanqiu.com break; #本機站點目錄下不須要建立text目錄，對其的訪問都重寫到http://china.huanqiu.com
}
}
[root@node1 src]# mkdir /var/www/html/text
注意：
nginx的rewrite重寫規則後的url必需要是能在外網訪問的真實url！
這一點要和nginx的反向代理區別開，proxy_pass代理後的url能夠是內網訪問，在內網之間代理！
3.nginx實現帶健康狀態檢測的負載均衡
nginx要可以檢測後端nginx的健康狀態，須要新的模塊，從新編譯nginx
模塊的使用：healthcheck_nginx_upstreams-master.zip
下載模塊，下載到本機的/usr/loca/src目錄下
下載地址：http://pan.baidu.com/s/1o8IrpbG
提取密碼：vp4y
[root@node1 ~]# cd /usr/local/src
[root@node1 src]# unzip healthcheck_nginx_upstreams-master.zip
[root@node1 src]# ll healthcheck_nginx_upstreams-master
接下來切換到nginx解壓目錄，打補丁~
[root@node1 src]# cd nginx-1.8.0
[root@node1 nginx-1.8.0]# patch -p1 < ../healthcheck_nginx_upstreams-master
而後從新編譯nginx，加上healthcheck_nginx_upstreams-master模塊
[root@node1 nginx-1.8.0]# ./configure --prefix=/usr/loca/nginx --user=nginx --group=nginx --with-http_ssl_module --with-http_flv_module --with-http_stub_status_module --with-http_gzip_static_module --with-pcre --add-module=/usr/local/src/healthcheck_nginx_upstreams-master
[root@node1 src]# make && make install
接下來配置實現nginx帶健康狀態的負載均衡：
[root@node1 src]# vim /usr/local/nginx/conf/nginx.conf
..................
..................
upstream cluster {
server 192.168.1.104 weight=1;
server 192.168.1.105 weight=1;
healthcheck_enabled;
healthcheck_delay 1000;
healthcheck_timeout 1000;
healthcheck_failcount 3;
healthcheck_send "GET /.health HTTP/1.0";
#healthcheck_expected 'I_AM_ALIVE'; ＃從RS上收到的http body部分的響應內容，若是未設置，則表示從後端服務器收到200狀態碼便可，這裏咱們不啓用
# Optional supervisord module support
#supervisord none;
#supervisord_inherit_backend_status;
}
server {
listen 80;
server_name localhost;
location / {
root html;
index index.php index.html index.htm;
proxy_pass http://cluster;
}
location /stat {
healthcheck_status;
}
}
----------------------------------------------------------------------------------------
上面參數解釋：
upstream cluster //定義後方的服務器羣組
Server 192.168.1.104 weight=1 //指明後方的一臺服務器地址，權重設置爲1；也能夠IP:PORT指定端口實現端口映射
Server 192.168.1.105 weight=1 //指明後方的另外一臺服務器地址，權重設置爲1
healthcheck_enable //開啓健康探測功能
healthcheck_delay 1000 //設置健康檢測的時延；即對同一臺RS兩次檢測之間的時間間隔，單位毫秒，默認爲1000
healthcheck_timeout 1000 //設置一次健康檢測的超時時間
healthcheck_failcount 1 //後方某臺服務器有一次檢測不到即視爲宕掉；即對同一臺RS檢測成功或失敗多少次，才決定其成功或失敗，並實現啓用和禁用此服務
healthcheck_send "GET /.health HTTP/1.0" //使用GET方法訪問後方服務器站點下的.health來進行探測；即從RS上得到用於檢測健康狀態的文件，默認只支持http 1.0協議
proxy_pass http://cluster //與upstream cluster相對應，在訪問http://111.112.114.23時將流量轉發到cluster組內機器上
location /stats //定義一個站點，用來查看後方服務器的健康情況
----------------------------------------------------------------------------------------
最後，重啓nginx
[root@node1 src]# /usr/local/nginx/sbin/nginx -s reload
測試：
假如：
RS1機器上訪問的結果是「welcome to 192.168.1.104」
RS2機器上訪問的結果是「welcome to 192.168.1.105」
訪問http://111.112.114.23，第一次出現的若是是RS1的訪問結果，那麼再刷一下，就會出現RS2的訪問結果，這樣就看出了負載均衡的效果。
能夠查看後端兩臺Real Server服務器的健康狀態:
訪問http://111.112.114.23/stat便可！
關閉RS1的nginx服務，再次訪問http://111.112.114.23/stat查看後端機器狀態，就會發現RS1的健康狀態已提示Bad，即顯示後端的192.168.1.101的RS1不能正常鏈接。
這樣就實現了負載均衡和健康探測，但依然不能知足高併發量，再次用ab進行測試：
可是，這樣經過nginx代理能夠知足的最大鏈接請求依然沒有直接訪問RS的大！
這個經過下面結果可知：
[root@node1 src]# ab -c 100 -n 10000 http://192.168.1.104/test.jpg
[root@node1 src]# ab -c 100 -n 10000 http://111.112.114.23/test.jpg
繼續作優化！以下：
[root@node1 src]# vim /usr/local/nginx/conf/nginx.conf
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
proxy_cache_path /var/www/cache levels=1:2 keys_zone=mycache:20m max_size=2048m inactive=24h;
proxy_temp_path /var/www/cache/tmp;
upstream cluster {
server 192.168.1.104 weight=1;
server 192.168.1.105 weight=1;
healthcheck_enabled;
healthcheck_delay 1000;
healthcheck_timeout 1000;
healthcheck_failcount 3;
healthcheck_send "GET /.health HTTP/1.0";
}
server {
listen 80;
server_name localhost;
location / {
root html;
index index.php index.html index.htm;
proxy_set_header HOST $host;
proxy_cache STATIC;
proxy_cache_valid 200 1d;
proxy_cache_use_stale error_timeout invalid_header updating http_500 http_502 http_503 http_504;
proxy_pass http://cluster;
}
location /stat {
healthcheck_status;
}
}
--------------------------------------------------------------
參數解釋：
proxy_cache_path //設置緩存的路徑和其餘參數。緩存數據是保存在文件中的，緩存的鍵和文件名都是在代理URL上執行MD5的結果。 levels參數定義了緩存的層次結構。
proxy_set_header //容許從新定義或者添加發日後端服務器的請求頭。
proxy_cache //指定用於頁面緩存的共享內存。
proxy_cache_valid //爲不一樣的響應狀態碼設置不一樣的緩存時間。
proxy_cache_use_stale //指定後端服務器出現情況時，nginx可使用的過時緩存
---------------------------------------------------------------
接着重啓nginx服務
[root@node1 src]# /usr/local/nginx/sbin/nginx -s reload
[root@node1 src]# mkdir /var/www/cache #這個前面作緩存時，已經建立了。
再次進行壓力測試，能夠看到經過nginx代理能夠知足的最大鏈接請求已經達到了5000多，超過了直接訪問RS的最大鏈接請求了！
這樣負載均衡+健康探測+緩存已經完成！
[root@node1 src]# ab -c 100 -n 10000 http://111.112.114.23/test.jpg
接下來一個問題就是在啓用緩存以後的訪問問題，試着從新訪問一下該站點http://111.112.114.23：
即第一次訪問http://111.112.114.23時訪問到了192.168.1.104（即RS1），顯示結果是：「welcome to 192.168.1.104」，前端nginx將本次的訪問結果放入本地緩存，在緩存未失效以前，訪問http://111.112.114.23時其實是nginx的本地緩存提供的訪問結果，依然顯示「welcome to 192.168.1.104」的頁面。
能夠試着多刷新幾回，能夠發現再怎麼刷新頁面內容依然是「welcome to 192.168.1.104」！
這就證實如今訪問到的是nginx緩存在本地的結果！
看看緩存目錄中有沒有內容[root@node1 src]# ll /var/www/cache #發現緩存目錄下已經有了緩存結果；能夠將這個緩存結果清除，再次刷次頁面，就會是新頁面了。total 4drwx------ 3 nginx nginx 4096 Sep 18 16:44 e[root@node1 src]#
- 1. nginx反向代理+緩存開啓+url重寫+負載均衡(帶健康探測)的部署記錄
- 2. nginx反向代理並開啓緩存+url重寫+帶健康檢測的負載均衡
- 3. nginx_3_反向代理負載均衡緩存URL重寫
- 4. nginx配置詳解-url重寫、反向代理、負載均衡
- 5. Nginx 反向代理-負載均衡-URL重寫
- 6. Nginx反向代理負載均衡的容器化部署
- 7. nginx反向代理和負載均衡的簡單部署
- 8. nginx配置、反向代理緩存、負載均衡
- 9. nginx 反向代理 負載均衡 頁面緩存
- 10. nginx下帶健康檢測的負載均衡
- 更多相關文章...
- • Hibernate的二級緩存 - Hibernate教程
- • Hibernate的一級緩存 - Hibernate教程
- • 使用阿里雲OSS+CDN部署前端頁面與加速靜態資源
- • PHP開發工具
-
每一个你不满意的现在，都有一个你没有努力的曾经。