nginx負(fù)載均衡

當(dāng)我們的應(yīng)用單例不能支撐用戶請(qǐng)求時(shí)，此時(shí)就需要擴(kuò)容，從一臺(tái)服務(wù)器擴(kuò)容到兩臺(tái)、幾十臺(tái)、幾百臺(tái)，我們需要一個(gè)入口，將客戶端請(qǐng)求均衡分布在后臺(tái)的多個(gè)服務(wù)器上。
負(fù)載均衡在服務(wù)端開發(fā)中算是一個(gè)比較重要的特性， nginx 提供的負(fù)載均衡可以實(shí)現(xiàn)上游服務(wù)器的負(fù)載均衡、故障轉(zhuǎn)移、失敗重試、容錯(cuò)、健康檢查，當(dāng)某些上游服務(wù)器出現(xiàn)問題時(shí)，可以將請(qǐng)求轉(zhuǎn)到其它的上游服務(wù)器從而保障高可用。

image.png

第一步我們需要給 nginx 配置上游服務(wù)器，即負(fù)載均衡到真實(shí)的處理業(yè)務(wù)的服務(wù)器 通過在 http 指令下配置 upstream 即可。
指定一組上游服務(wù)器地址，其中，地址可以是域名、IP地址。可以在域名或者IP地址后加端口，如果不加端口，那么默認(rèn)使用80端口。

語法: upstream name { ... }
默認(rèn)值: —
上下文: http
例子：
upstream backend {
  server backend1.example.com weight=5;
  server backend2.example.com:8080;
}
server {
  location / {
    proxy_pass http://backend;
  }
}

upstream 指令當(dāng)中包含server指令

語法: server address [parameters];
默認(rèn)值: —
上下文: upstream
可以定義下面的參數(shù)：
weight=number 設(shè)定服務(wù)器的權(quán)重，默認(rèn)是1，權(quán)重越大被訪問機(jī)會(huì)越大，要根據(jù)機(jī)器的配置情況來配置
max_fails=number 設(shè)定Nginx與服務(wù)器通信的嘗試失敗的次數(shù)。在fail_timeout參數(shù)定義的時(shí)間段內(nèi)，如果失敗的次數(shù)達(dá)到此值，Nginx就認(rèn)為服務(wù)器不可用。在下一個(gè)fail_timeout時(shí)間段，服務(wù)器不會(huì)再被嘗試。 失敗的嘗試次數(shù)默認(rèn)是1。
可以通過指令proxy_next_upstream 和memcached_next_upstream來配置什么是失敗的嘗試。 默認(rèn)配置時(shí)，http_404狀態(tài)不被認(rèn)為是失敗的嘗試。
fail_timeout=time
統(tǒng)計(jì)失敗嘗試次數(shù)的時(shí)間段。在這段時(shí)間中，服務(wù)器失敗次數(shù)達(dá)到指定的嘗試次數(shù)，服務(wù)器就被認(rèn)為不可用。默認(rèn)情況下，該超時(shí)時(shí)間是10秒。
backup
標(biāo)記為備用服務(wù)器。當(dāng)主服務(wù)器不可用以后，請(qǐng)求會(huì)被傳給這些服務(wù)器，配置這個(gè)指令可以實(shí)現(xiàn)故障轉(zhuǎn)移。
down
標(biāo)記服務(wù)器永久不可用，可以跟ip_hash指令一起使用。
當(dāng)訪問Nginx時(shí)，會(huì)將請(qǐng)求反向代理到backend配置的upstream server。

負(fù)載均衡的方法

nginx支持以下負(fù)載均衡機(jī)制：

1、輪詢

默認(rèn)輪訓(xùn)方式
每一個(gè)來自網(wǎng)絡(luò)中的請(qǐng)求，輪流分配給內(nèi)部的服務(wù)器，從1到N然后重新開始。此種負(fù)載均衡算法適合服務(wù)器組內(nèi)部的服務(wù)器都具有相同的配置并且平均服務(wù)請(qǐng)求
相對(duì)均衡的情況。

2、加權(quán)輪詢

通過 weight 參數(shù)控制權(quán)重
根據(jù)服務(wù)器的不同處理能力，給每個(gè)服務(wù)器分配不同的權(quán)值，使其能夠接受相應(yīng)權(quán)值數(shù)的服務(wù)請(qǐng)求。例如：服務(wù)器A的權(quán)值被設(shè)計(jì)成1，B的權(quán)值是3，C的權(quán)值是6，則服務(wù)器A、B、C將分別接受到10%、30％、60％的服務(wù)請(qǐng)求。此種均衡算法能確保高性能的服務(wù)器得到更多的使用率，避免低性能的服務(wù)器負(fù)載過重。

3、IP Hash

在 upstream 當(dāng)中配置 ip_hash ;
這種方式通過生成請(qǐng)求源IP的哈希值，并通過這個(gè)哈希值來找到正確的真實(shí)服務(wù)器。這意味著對(duì)于同一主機(jī)來說他對(duì)應(yīng)的服務(wù)器總是相同。使用這種方式，你不
需要保存任何源IP。 將客戶端會(huì)話"沾住"或者"持久化"，以便總是能選擇特定服務(wù)器，那么可以使用 ip-hash 負(fù)載均衡機(jī)制。
使用 ip-hash 時(shí)，客戶端IP地址作為 hash key 使用，用來決策選擇服務(wù)器集群中的哪個(gè)服務(wù)器來處理這個(gè)客戶端的請(qǐng)求。這個(gè)方法保證從同一個(gè)客戶端發(fā)起的
請(qǐng)求總是定向到同一臺(tái)服務(wù)器，除非服務(wù)器不可用。

4、最少連接數(shù)

在 upstream 當(dāng)中配置 least_conn 實(shí)現(xiàn)最少連接數(shù)
客戶端的每一次請(qǐng)求服務(wù)在服務(wù)器停留的時(shí)間可能會(huì)有較大的差異，隨著工作時(shí)間加長，如果采用簡單的輪循或隨機(jī)均衡算法，每一臺(tái)服務(wù)器上的連接進(jìn)程可能會(huì)產(chǎn)生極大的不同，并沒有達(dá)到真正的負(fù)載均衡。最少連接數(shù)均衡算法對(duì)內(nèi)部中需負(fù)載的每一臺(tái)服務(wù)器都有一個(gè)數(shù)據(jù)記錄，記錄當(dāng)前該服務(wù)器正在處理的連接數(shù)量，當(dāng)有新的服務(wù)連接請(qǐng)求時(shí)，將把當(dāng)前請(qǐng)求分配給連接數(shù)最少的服務(wù)器，使均衡更加符合實(shí)際情況，負(fù)載更加均衡。

失敗重試

通過配置上游服務(wù)器 max_fails 和 fail_timeout，指定每個(gè)上游服務(wù)器，當(dāng) fail_timeout 時(shí)間內(nèi)失敗了 max_fails 次請(qǐng)求，則認(rèn)為該上游服務(wù)器不可用/不存
活，然后這段時(shí)間將不會(huì)訪問這臺(tái)上游服務(wù)器， fail_timeout 時(shí)間后會(huì)再次進(jìn)行重試。
max_fails=2 fail_timeout=30s 這2個(gè)一起搭配使用，表示：當(dāng)失敗2次的時(shí)候，就停止使30秒

proxy_next_upstream 指令

在nginx的配置文件中， proxy_next_upstream 項(xiàng)定義了什么情況下進(jìn)行重試

語法: proxy_next_upstream error | timeout | invalid_header | http_500 | http_502 http_503 | http_504 |http_404 | off ...;
默認(rèn)值: proxy_next_upstream error timeout;
上下文: http, server, location

其中：
error 表示和后端服務(wù)器建立連接時(shí)，或者向后端服務(wù)器發(fā)送請(qǐng)求時(shí)，或者從后端服務(wù)器接收響應(yīng)頭時(shí)，出現(xiàn)錯(cuò)誤。
timeout 表示和后端服務(wù)器建立連接時(shí)，或者向后端服務(wù)器發(fā)送請(qǐng)求時(shí)，或者從后端服務(wù)器接收響應(yīng)頭時(shí)，出現(xiàn)超時(shí)。
invalid_header 表示后端服務(wù)器返回空響應(yīng)或者非法響應(yīng)頭
http_500 表示后端服務(wù)器返回的響應(yīng)狀態(tài)碼為500
.............
off 表示停止將請(qǐng)求發(fā)送給下一臺(tái)后端服務(wù)器

重試不能無限制進(jìn)行，因此，需要如下兩個(gè)指令控制重試次數(shù)和重試超時(shí)時(shí)間。
proxy_next_upstream_tries number：設(shè)置重試次數(shù)，默認(rèn)0表示不限制，注意此重試次數(shù)指的是所有請(qǐng)求次數(shù)（包括第一次和之后的重試次數(shù)之和）。
proxy_next_upstream_timeout time： 設(shè)置重試最大超時(shí)時(shí)間，默認(rèn)0表示不限制。
即在 proxy_next_upstream_timeout 時(shí)間內(nèi)允許 proxy_next_upstream_tries 次重試。如果超過了其中一個(gè)設(shè)置，則 Nginx 也會(huì)結(jié)束重試并返回客戶端響應(yīng)（可能是錯(cuò)誤碼）。

proxy_send_timeout 后端服務(wù)器數(shù)據(jù)回傳時(shí)間(代理發(fā)送超時(shí)時(shí)間)
proxy_read_timeout 連接成功后，后端服務(wù)器響應(yīng)時(shí)間(代理接收超時(shí)時(shí)間)
proxy_connect_timeout nginx連接后端的超時(shí)時(shí)間，一般不超過75s

backup(故障轉(zhuǎn)移)
標(biāo)記為備用服務(wù)器。當(dāng)主服務(wù)器不可用以后，請(qǐng)求會(huì)被傳給這些服務(wù)器。
down
標(biāo)記服務(wù)器永久不可用，可以跟ip_hash指令一起使用。

動(dòng)態(tài)負(fù)載均衡

nginx-upsync-module 提供了動(dòng)態(tài)的負(fù)載均衡，動(dòng)態(tài)更新上游的服務(wù)器不需要 reload nginx ，它的功能是拉取 consul 的后端 server 的列表，并更新Nginx 的路由信息。此模塊不依賴于任何第三方模塊。 consul 作為 Nginx 的 db，利用 consul 的 KV 服務(wù)，每個(gè) Nginx work 進(jìn)程獨(dú)立的去拉取各個(gè)upstream 的配置，并更新各自的路由.
掛了第三方模塊無法結(jié)束進(jìn)程或者是當(dāng)前進(jìn)程尚未結(jié)束。
nginx -s reload 是平滑重啟，不會(huì)強(qiáng)制結(jié)束正在工作的連接，需要等所有連接都結(jié)束才會(huì)重啟。想象一個(gè)場景上線繁忙，想要多添加幾臺(tái)服務(wù)器處理更多的流量.
改配置文件并重新啟動(dòng) Nginx 可能并不總是很方便。 例如，當(dāng)遇到大流量和高負(fù)載，重啟 Nginx 并在此時(shí)重新加載配置會(huì)進(jìn)一步增加系統(tǒng)負(fù)載，并可能暫時(shí)降低性能.

wget https://github.com/weibocom/nginx-upsync-module/archive/v2.1.0.tar.gz
--add-module=/root/nginx-upsync-module-2.1.0
示例：
upstream swoole_test {
  upsync 127.0.0.1:8700/v1/kv/upstreams/swoole_test upsync_timeout=6m         
  upsync_interval=500ms upsync_type=consul
  strong_dependency=off;
  upsync_dump_path /usr/local/nginx/conf/servers_test.conf;
  include /usr/local/nginx/conf/servers_test.conf;
}
upsync模塊會(huì)去consul拉取最新的upstream信息并存到本地的文件中
upsync_timeout 配置從consul拉取上游服務(wù)器的超時(shí)時(shí)間
upsync_interval 配置從consul拉取上游服務(wù)器的間隔時(shí)間
upsync_type 指定使用配置服務(wù)器的類型，當(dāng)前是consul
strong_dependency 啟動(dòng)時(shí)是否強(qiáng)制依賴配置服務(wù)器，如果配置為on,則拉取失敗，nginx同樣會(huì)啟用失敗
upsync_dump_path 指定從consul拉取的上游服務(wù)器后持久化到的位置，這樣即使
Consul服務(wù)器出問題了，本地同樣會(huì)有備份

添加的時(shí)候要注意名稱模塊的匹配：

安裝consul

對(duì)于consul的介紹可以移步到另外的文檔，暫時(shí)先了解就行，我們可以先通過docker的方式pull一個(gè)consul
curl -X PUT -d '{"weight":1, "max_fails":2, "fail_timeout":10}' http://$consul_ip:$port/v1/kv/$dir1/$upstream_name/$backend_ip:$backend_port

curl -X PUT -d '{"weight":1,"max_fails":2,"fail_timeout":10}' http://127.0.0.1:8700/v1/kv/upstreams/swoole_test/127.0.0.1:9501
docker run -itd --name -p consul consul
查看所有已經(jīng)存儲(chǔ)的k/v
curl http://127.0.0.1:8700/v1/kv/?recurse
刪除 curl -X DELETE http://127.0.0.1:8700/

半自動(dòng)平滑升級(jí)

所謂半自動(dòng)，其實(shí)就是在最后遷移的時(shí)候使用源碼自帶的升級(jí)命令：make upgrade 來自動(dòng)完成

• 1、需要下載對(duì)應(yīng)的需要加載的第三方的擴(kuò)展，或者是需要附加設(shè)置的參數(shù) （注意：之前的配置參數(shù)要保留）
  --add_module=PATH 添加第三方擴(kuò)展
• 2、執(zhí)行make不要執(zhí)行make install
• 3、重命名 nginx 舊版本二進(jìn)制文件，即 sbin 目錄下的 nginx（期間 nginx 并不會(huì)停止服務(wù)）
• 4、然后拷貝一份新編譯的二進(jìn)制文件到安裝目錄

• 5、在源碼目錄執(zhí)行 make upgrade 開始升級(jí)：

  
  
  image.png

nginx緩存機(jī)制（瀏覽器緩存及nginx緩存）

什么是緩存？

Web緩存是可以自動(dòng)保存常見文檔副本的HTTP 設(shè)備。當(dāng)Web請(qǐng)求抵達(dá)緩存時(shí)，如果本地有“已緩存的”副本，就可以從本地設(shè)備而不是服務(wù)器中提取這個(gè)文檔。

為什么使用緩存？

緩存減少了冗余的數(shù)據(jù)傳輸，節(jié)約了網(wǎng)絡(luò)費(fèi)用
緩存緩解了網(wǎng)絡(luò)瓶頸的問題，對(duì)于帶寬的要求
緩存降低了對(duì)原始服務(wù)器的要求，降低服務(wù)器壓力
緩存加速了頁面的展示

緩存的分類：

緩存分為服務(wù)端側(cè)（比如 Nginx,redis,memcached）和客戶端側(cè)（比如 web browser）。
服務(wù)端緩存又分為 代理服務(wù)器緩存 和 反向代理服務(wù)器緩存（也叫網(wǎng)關(guān)緩存，比如 Nginx反向代理就可以設(shè)置緩存）
客戶端側(cè)緩存一般指的是瀏覽器緩存、app緩存等等，目的就是加速各種靜態(tài)資源的訪問，降低服務(wù)器壓力。
簡單看看瀏覽器的緩存規(guī)則，同時(shí)使用瀏覽器緩存跟nginx緩存：

image.png

第一次訪問某個(gè)網(wǎng)站

image.png

第二次訪問某個(gè)網(wǎng)站

image.png

我們發(fā)現(xiàn)多了一些字段關(guān)于這些字段的詳細(xì)介紹下面會(huì)講
HTTP 緩存控制頭介紹
HTTP 中最基本的緩存機(jī)制，涉及到的 HTTP 頭字段，包括 Cache-Control, Last-Modified, If-Modified-Since, Etag, If-None-Match 等
Last-Modified/If-Modified-Since
Last-Modified ：標(biāo)示這個(gè)響應(yīng)資源的最后修改時(shí)間。web服務(wù)器在響應(yīng)請(qǐng)求時(shí)，告訴瀏覽器資源的最后修改時(shí)間。
If-Modified-Since ：當(dāng)資源過期時(shí)（使用Cache-Control標(biāo)識(shí)的max-age），發(fā)現(xiàn)資源具有 Last-Modified 聲明，則再次向web服務(wù)器請(qǐng)求時(shí)帶上頭
If-Modified-Since ，表示請(qǐng)求時(shí)間。web服務(wù)器收到請(qǐng)求后發(fā)現(xiàn)有頭 If-Modified-Since 則與被請(qǐng)求資源的最后修改時(shí)間進(jìn)行比對(duì)。若最后修改時(shí)間較新，
說明資源有被改動(dòng)過，則響應(yīng)整片資源內(nèi)容（寫在響應(yīng)消息包體內(nèi)），HTTP 200；若最后修改時(shí)間較舊，說明資源無新修改，則響應(yīng) HTTP 304 (無需包體，節(jié)省
瀏覽)，告知瀏覽器繼續(xù)使用所保存的 cache 。

當(dāng)我們按下f5刷新的時(shí)候，我們看看瀏覽器發(fā)送的請(qǐng)求頭：

image.png

此處發(fā)送時(shí)有一個(gè) If-Modified-Since 請(qǐng)求頭，其值就是上次請(qǐng)求響應(yīng)的 Last-Modified
響應(yīng)狀態(tài)碼為304

image.png

Ctrl+f5強(qiáng)制刷新
如果你想強(qiáng)制從服務(wù)器獲取最新的內(nèi)容，不去對(duì)比，那么就可以強(qiáng)制刷新

image.png

Pragma行是為了兼容 HTTP1.0 ，作用與 Cache-Control: no-cache 是一樣的
Etag/If-None-Match
Etag ：web服務(wù)器響應(yīng)請(qǐng)求時(shí)，告訴瀏覽器當(dāng)前資源在服務(wù)器的唯一標(biāo)識(shí)（生成規(guī)則由服務(wù)器決定),如果給定URL中的資源修改，則一定要生成新的Etag值。
If-None-Match ：當(dāng)資源過期時(shí)（使用Cache-Control標(biāo)識(shí)的max-age），發(fā)現(xiàn)資源具有Etage聲明，則再次向web服務(wù)器請(qǐng)求時(shí)帶上頭 If-None-Match （Etag的值）。web服務(wù)器收到請(qǐng)求后發(fā)現(xiàn)有頭 If-None-Match 則與被請(qǐng)求資源的相應(yīng)校驗(yàn)串進(jìn)行比對(duì)，決定返回200或304。
Last-Modified 標(biāo)注的最后修改只能精確到秒級(jí)，如果某些文件在1秒鐘以內(nèi)，被修改多次的話，它將不能準(zhǔn)確標(biāo)注文件的修改時(shí)間
如果某些文件會(huì)被定期生成，當(dāng)有時(shí)內(nèi)容并沒有任何變化，但 Last-Modified 卻改變了，導(dǎo)致文件沒法使用緩存
有可能存在服務(wù)器沒有準(zhǔn)確獲取文件修改時(shí)間，或者與代理服務(wù)器時(shí)間不一致等情形 Etag是服務(wù)器自動(dòng)生成或者由開發(fā)者生成的對(duì)應(yīng)資源在服務(wù)器端的唯一標(biāo)識(shí)
符，能夠更加準(zhǔn)確的控制緩存。 Last-Modified 與 ETag 是可以一起使用的，服務(wù)器會(huì)優(yōu)先驗(yàn)證 ETag ，一致的情況下，才會(huì)繼續(xù)比對(duì) Last-Modified ，最后才
決定是否返回304。

如下所示：

image.png

瀏覽器第一次請(qǐng)求，無緩存狀態(tài)

image.png

瀏覽器第二次請(qǐng)求

image.png

Nginx web緩存設(shè)置

nginx 提供了 expires、etag、if-modified-since 指令來進(jìn)行瀏覽器緩存控制。

expires指令

語法: expires [modified] time;
默認(rèn)值: expires off;
上下文: http, server, location, if in location

假設(shè)我們使用 nginx 作為靜態(tài)資源服務(wù)器，此時(shí)可以使用 expires 進(jìn)行緩存控制。
location /img { alias /export/img/; expires 10s; }

expires 30s;#30秒
expires 30m;#30分鐘
expires 2h;#2個(gè)小時(shí)
expires 30d;#30天

image.png

nginx代理緩存模塊（ngx_http_proxy_module）

Proxy 模塊，用于把請(qǐng)求后拋給服務(wù)器節(jié)點(diǎn)或 upstream 服務(wù)器池
常用配置，具體看手冊(cè)
請(qǐng)求頭傳遞

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;
client_max_body_size 50m;
client_body_buffer_size 256k;
proxy_connect_timeout 30;
proxy_send_timeout 30;
proxy_read_timeout 60;
proxy_buffer_size 256k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;
proxy_temp_file_write_size 256k;
proxy_max_temp_file_size 128m;
proxy_pass http://nginx.23673.com;

proxy_cache_path指令

語法:proxy_cache_path[levels=number] keys_zone=zone_name:zone_size[inactve=time] [max_size=size];
默認(rèn)值:None
上下文:http
proxy_cache_path 設(shè)置緩存目錄，目錄里的文件名是cache_key的MD5值。
levels=1:2 默認(rèn)所有緩存文件都放在同一個(gè)/path/to/cache下，但是會(huì)影響緩存的性能，因此通常會(huì)在/path/to/cache下面建立子目錄用來分別存放不
同的文件。假設(shè)levels=1:2。
key_zone 在共享內(nèi)存中設(shè)置一塊存儲(chǔ)區(qū)域來存放緩存的key和metadata（類似使用次數(shù)），這樣nginx可以快速判斷一個(gè)request是否命中或者未命中緩
存，1m可以存儲(chǔ)8000個(gè)key，10m可以存儲(chǔ)80000個(gè)key。
max_size 最大cache空間，如果不指定，會(huì)使用掉所有disk space，當(dāng)達(dá)到配額后，會(huì)刪除最少使用的cache文件。
inactive 未被訪問文件在緩存中保留時(shí)間，本配置中如果60分鐘未被訪問則不論狀態(tài)是否為expired，緩存控制程序會(huì)刪掉文件。inactive默認(rèn)是10分
鐘。需要注意的是，inactive和expired配置項(xiàng)的含義是不同的，expired只是緩存過期，但不會(huì)被刪除，inactive是刪除指定時(shí)間內(nèi)未被訪問的緩存文
件。
use_temp_path 如果為off，則nginx會(huì)將緩存文件直接寫入指定的cache文件中，而不是使用temp_path存儲(chǔ)，official建議為off，避免文件在不同文件
系統(tǒng)中不必要的拷貝。
proxy_cache 啟用proxy cache，并指定key_zone。另外，如果proxy_cache off表示關(guān)閉掉緩存。
proxy_cache_key 定義cache_key,nginx對(duì)緩存的資源會(huì)設(shè)置一個(gè)key，NGINX生成的鍵的默認(rèn)格式是類似于下面的NGINX變量的MD5哈希
值:$scheme$proxy_host$request_uri，實(shí)際的算法有些復(fù)雜。 為了改變變量（或其他項(xiàng)）作為基礎(chǔ)鍵，可以使用proxy_cache_key命令。
proxy_cache_valid 為不同的HTTP返回狀態(tài)碼的資源設(shè)置不同的緩存時(shí)長。

緩存細(xì)節(jié)

NGINX僅僅默認(rèn)緩存GET和HEAD客戶端請(qǐng)求，在響應(yīng)頭部中 Cache-Control 被配置為 Private，No-Cache，No-Store 或者 Set-Cookie ， NGINX 不會(huì)進(jìn)行緩
存。
如果你不想源服務(wù)器控制是否緩存，也可以在 nginx 當(dāng)中配置忽略利用 proxy_ignore_headers Cache-Control 指令實(shí)現(xiàn)
下面的指令允許多種請(qǐng)求類型緩存
proxy_cache_methods GET HEAD POST ;

緩存設(shè)置優(yōu)化

proxy_cache_min_uses 設(shè)置響應(yīng)被緩存的最小請(qǐng)求次數(shù)。
當(dāng)緩存不斷被填滿時(shí)，這項(xiàng)設(shè)置便十分有用，因?yàn)檫@確保了只有那些被經(jīng)常訪問的內(nèi)容才會(huì)被添加到緩存中。該項(xiàng)默認(rèn)值為1。
proxy_cache_lock 開啟此功能時(shí)，對(duì)于相同的請(qǐng)求，同時(shí)只允許一個(gè)請(qǐng)求發(fā)往后端。
只有這些請(qǐng)求中的第一個(gè)被允許發(fā)送至服務(wù)器。其他請(qǐng)求在第一個(gè)請(qǐng)求得到滿意結(jié)果之后在緩存中得到文件。如果不啟用 proxy_cache_lock ，則所有在緩存中找不到文件的請(qǐng)求都會(huì)直接與源服務(wù)器通信。

不緩存的條件

有時(shí)候，我們也不想所有的請(qǐng)求都被緩存，我們可以指定某些請(qǐng)求不被緩存，比如帶有后臺(tái)后綴的，可以通過一些條件判斷決定是否緩存。

語法: proxy_cache_bypass string ...;
默認(rèn)值: —
上下文: http, server, location
定義nginx不從緩存取響應(yīng)的條件。如果至少一個(gè)字符串條件非空而且非“0”，nginx就不會(huì)從緩存中去取響應(yīng),而是請(qǐng)求源服務(wù)器

比如后臺(tái)模塊是不允許緩存的，就可以設(shè)置不緩存

清除緩存

某些時(shí)候我們?nèi)绻幌氲却彺娴倪^期，想要主動(dòng)清除緩存，可以采用第三方的緩存清除模塊清除緩存 nginx_ngx_cache_purge

第三方地址 https://www.nginx.com/resources/wiki/modules/
Purge 模塊下載地址 http://labs.frickle.com/nginx_ngx_cache_purge/
可以利用平滑升級(jí)的方式安裝
proxy_cache_purge
syntax: proxy_cache_purge zone_name key
default: none
context: location

注意：要在proxy_cache 指令 下方

proxy_cache_purge tmp-test $uri;
tmp-test：指定的key_zone
$uri：指定的生成key的參數(shù)

比如：匹配url當(dāng)中包含了purge關(guān)鍵字的就清除
緩存 xxx.com/cache/shop/?a=1
清除 xxxx.com/purge/shop/?a=1