當前位置:首頁 » 硬碟大全 » nginx緩存用法
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

nginx緩存用法

發布時間: 2023-06-16 08:57:58

Ⅰ 基於Nginx設置瀏覽器協商緩存過程詳解

一、強緩存與協商緩存的區別

強緩存:瀏覽器不與服務端協商直接取瀏覽器緩存

協商緩存:瀏覽器會先向伺服器確認資源的有效性後才決定是從緩存中取資源還是重新獲取資源

二、協商緩存運作原理

現在有一個這樣的業務情景:後端的靜態資源會不定時地發生更新,而因為瀏覽器默認使用強緩存,會默認從瀏覽器緩存中取到過時的資源。

現在我們希望瀏覽器每次獲取資源的時候都向後端確認資源是否更新,就要設置瀏覽器使用協商緩存

那麼後端如何判斷資源是否更新了呢?這時就要用到Etag和Last-Modified兩項響應頭。

每次收到一個靜態資源的請求時,後端都將資源的最後修改時間(Last-Modified)、根據資源內容計算出來的Etag放在響應頭給前端

前端收到響應後將這兩項緩存起來,然後在下次請求同樣資源的時候,將這兩項的內容放到If-Modified-Since和If-None-Match這兩項請求頭中。

服務端收到這兩項後,會與資源當前生成的Etag和Last-Modified做比較,如果兩者都一致,說明資源沒有更新,服務端會返回304空響應;否則,說明資源有更新,服務端會將完整的資源內容返回

實現

那麼如何實現這樣一個復雜的過程呢?其實很簡單,只要使用nginx作為靜態資源的伺服器,再在響應頭加上Cache-Control:no-cache就可以了。

下面來分步驟實現一下

1. 使用nginx作為靜態資源的伺服器

在nginx的配置中,將對靜態資源的請求映射到資源的磁碟路徑上

http {

  server {

  listen 80;

  ...

  location /picture/ {

    alias D:/luozixi/tcp_test/picture/;

    # alias是重定義路徑

    # 比如訪問127.0.0.1/picture/1_new.gif,則會映射為訪問D:/luozixi/tcp_test/picture/1_new.gif

    # web應用根本不會收到請求,picture的請求都被nginx處理了

    # alias是替換,root是拼接

    autoindex on;

    }

  }

}

2. 重新載入nginx配置

3. 此時,請求靜態資源的時候nginx會自動在response頭中加上Etag和Last-Modified兩項

4. 但是這時發現,如果不配置Cache-Contrl: no-cache,瀏覽器在下次請求這個資源的時候不會將請求發向後端,而是直接從緩存中獲取資源

5. 在nginx中配置

location /picture/ {

  add_header Cache-Control no-cache;

  alias D:/luozixi/tcp_test/picture/;

}

6.清除瀏覽器緩存後第一次發起請求,會得到一個正常的200 Response,而且響應頭里已經有了Cache-Control: no-cache,表示使用協商緩存

7.再次發起請求後,會發現請求頭已經帶上了If-Modified-Since和If-None-Match兩項

8.服務端(nginx)收到這兩項後,會與資源當前生成的Etag和Last-Modified做比較,如果兩者都一致,說明資源沒有更新,服務端會返回304空響應;否則,說明資源有更新,服務端會將完整的資源內容返回

另外,伺服器驗證If-Modified-Since的方式只是簡單的字元串比較,即使資源的Last-Modified比If-Modified-Since要早,服務端仍認為資源有更新

9.瀏覽器在收到304響應後,會從瀏覽器緩存中取資源。因此速度非常塊

三、no-cache與no-store的區別

no-cache表示不緩存過期資源,緩存會向伺服器進行有效處理確認之後處理資源

而no-store才是真正的不進行緩存。

Ⅱ 【NGINX入門】3.Nginx的緩存伺服器proxy_cache配置

本文介紹NGINX緩存機制,配置和參數說明。

如圖所示,nginx緩存,可以在一定程度上,減少源伺服器的處理請求壓力。因為靜態文件(比如css,js, 圖片)中,很多都是不經常更新的。nginx使用proxy_cache將用戶的請求緩存到本地一個目錄。下一個相同請求可以直接調取緩存文件,就不用去請求伺服器了。畢竟,IO密集型服務的處理是nginx的強項。

Nginx的緩存加速功能是由proxy_cache(用於反向代理和靜態緩存)和fastcgi_cache(PHP動態緩存)兩個功能模塊完成。

Nginx緩存特點:

先上個例子:

因為我是在一台伺服器上做試驗,所以用了兩個埠 80 和 90 進行模擬兩台伺服器之間的交互。

接下來講一下配置項:

這里我設置了 圖片 、 css 、 js 靜態資源進行緩存。
當用戶輸入 http://wangxiaokai.vip 域名時,解析得到 ip:port 的訪問地址。 port 默認為80。所以頁面請求會被當前server截取到,進行請求處理。
當解析到上述文件名結尾的靜態資源,會到緩存區獲取靜態資源。
如果獲取到對應資源,則直接返回數據。
如果獲取不到,則將請求轉發給 proxy_pass 指向的地址進行處理。

這里直接處理 90 埠接受到的請求,到伺服器本地目錄 /mnt/blog 下抓取資源進行響應。

細心的讀者應該發現,我在第二段例子里,留了個彩蛋 add_header wall "hey!guys!give me a star." 。
add_header 是用於在報頭設置自定義的信息。
所以,如果緩存有效的話,那麼靜態資源返回的報頭,一定會帶上這個信息。

(1)Nginx系列教程(3)nginx緩存伺服器上的靜態文件
https://yq.aliyun.com/articles/752967

(2)proxy_cache
nginx 反向代理之 proxy_cache https://www.cnblogs.com/yyxianren/p/10832172.html

(3)Nginx使用upstream負載均衡和proxy_cache緩存實現反向代理
https://blog.51cto.com/13770206/2163952

Ⅲ nginx配置緩存

在開發調試web的時候,經常會碰到因瀏覽器緩存(cache)而經常要去清空緩存或者強制刷新來測試的煩惱,提供下apache不緩存配置和nginx不緩存配置的設置。

apache:
首先確定配置文件httpd.conf中確已經載入mod_headers模塊。

LoadMole headers_mole moles/mod_headers.so

我們可以根據文件類型來讓瀏覽器每次都從伺服器讀取,這里測試用css、js、swf、php、html、htm這幾種文件。
<FilesMatch 「\.(css|js|swf|php|htm|html)$」>
Header set Cache-Control "private, no-cache, no-store, proxy-revalidate, no-transform"
Header set Pragma "no-cache"
</FilesMatch>

nginx:

location ~ .*\.(css|js|swf|php|htm|html )$ {
add_header Cache-Control no-store;
}

對於站點中不經常修改的靜態內容(如圖片,JS,CSS),可以在伺服器中設置expires過期時間,控制瀏覽器緩存,達到有效減小帶寬流量,降低伺服器壓力的目的。

以Nginx伺服器為例:
location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$ {
#過期時間為30天,
#圖片文件不怎麼更新,過期可以設大一點,
#如果頻繁更新,則可以設置得小一點。
expires 30d;
}

location ~ .*\.(js|css)$ {
expires 10d;
}

Ⅳ Nginx怎樣設置瀏覽器緩存

瀏覽器緩存(BrowserCaching)

為了加速瀏覽器,瀏覽器在用戶磁碟上,對最近請求過的文檔進行存儲

當訪問者再次請求這個頁面時,瀏覽器就可以從本地磁碟顯示文檔,這樣,就可以加速頁面的閱覽,緩存的方式節約了網路的資源,提高了網路的效率。


瀏覽器緩存可以通過expires指令輸出Header頭來實現,expires指令的語法如下

語法:expires[time| epoch | max |off]

默認值:expiresoff

作用域:http、server、location

用途:使用本指令可以控制http應答中的expires和Cache-Control的Header頭信息,起到控制頁面緩存的作用。


參數說明

Time,可以使用正數或負數,Expires頭標的值,將通過當前系統時間加上設定的time值來獲得。

epoch,指定expires的值為1January,1970,00:00:01 GMT。

Max,指定expires的值為31December 2037 23:59:59 GMT,Cache-Control的值為10年。

Off,表示不修改Expires和Cache-Control的值。

一個HTML頁面,會引用一些JavaScript文件、圖片文件、而這些格式的文件很少會被修改,則可以通過expires設置瀏覽器緩存。

比如,對常見格式的圖片、Flash文件在瀏覽器本地緩存30天,對JS、CSS文件在瀏覽器本地緩存1小時,代碼如下

Ⅳ nginx緩存(proxy_cache模塊)

緩存的基本思想是利用客戶端訪問的時間局限性,將客戶端訪問過的內容做一個副本,在一定時間內存放到本地,當改數據下次被訪問時,不必連接到後端伺服器反復去查詢數據,而是由本地保存的副本響應數據。

保存在本地的這些副本具有一個過期時間,超過該時間將會更新。判斷一個副本數據是否為過期數據的辦法有很多,可以使用保留時間來判斷,也可以使用數據完整度來判斷。

許多Web伺服器還具有校驗功能,就是當某些副本數據過期以後,先向後端伺服器發送校驗請求,後端伺服器對這些數據進行校驗,如果發現原數據和副本沒有差別,則將過期副本重新置為可用副本。

以上nginx配置結合使用:

proxy_params文件的配置如下:

訪問一次頁面,並向 http://www.blogs-s.com:8080/api/ 發起一個介面數據請求,查看/cache/nginx目錄下的緩存結果:

ngx_cache_purge是nginx的第三方模塊,能夠幫助我清除nginx中的緩存。

在之前的nginx編譯安裝中我們是沒有把緩存的清除模塊ngx_cache_purge編譯進去的,如果啟動了緩存,沒有安裝這個模塊,在之後的調試中我們嘗試去清除緩存時,將會出現異常:

這個異常是在指示我們,找不到該指令的驅動,需要按照相關模塊。

ngx_cache_purge只是nginx的第三方模塊,並不是某個特殊的軟體,所以我們需要對nginx重新進行編譯,操作如下:

配置nginx:

再一次啟動nginx成功;

接下來進行緩存清除測試,訪問: http://blogs.com/clear_cache/api/index.php , 訪問這個連接將會清除介面: http://blogs.com/api/index.php 的緩存數據。

結果如下:

在項目開發中,不可能出現什麼都需要緩存的數據,緩存僅僅適合去緩存查詢頻繁,但是不需要實時更新的數據,這個是它適合的場景,而我們上面的配置,只要是訪問api介面目錄就會緩存介面的數據,這樣對於一些需要實時更新的介面數據來說是不合理的,需要控制好nginx的緩存去緩存什麼以及不緩存什麼

set 指令為變數設置,proxy_no_cache參數中的值可以設置多個,但是多個值中,只要有一個是不為0的,就會通過緩存響應數據。

該指令用於配置一塊公用的內存區域的名稱,該區域可以存放緩存的索引數據。這些數據在Nginx伺服器啟動時由緩存索引重建進程負責建立,在Nginx伺服器的整個運行過程中由緩存管理進程負責定時檢測過期數據,檢索等管理工作。

該指令用於配置Nginx伺服器向客戶端發送響應數據時,不從緩存中獲取的條件。這些條件支持使用Nginx 配置的常用變數。

看一個例子:

其中,Scookie_nocache、Sarg_nocache、Sarg_comment、Shttp_pragma 和Shttp_authorization 都是Nginx配置文件的變數,

該指令用於設置Nginx伺服器在內存中為緩存數據建立索引時使用的關鍵字

如果我們希望緩存數據包含伺服器主機名稱等關鍵字,則可以將該指令設置為:

該指令用於設置是否開啟緩存的鎖功能。在緩存中,某些數據項可以同時被多個請求返回的響應數據填充。開啟該功能後,Nginx伺服器同時只能有一個請求填充緩存中的某一數據項,這相當於給該數據項上鎖,不允許其他請求操作。其他的請求如果也想填充該項,必須等待該數據項的鎖被釋放。這個等待時間由 proxy_cache_lock_timeout 指令配置。

該指令用於設置緩存的鎖功能開啟以後鎖的超時時間。具體細節參見proxy_cache_lock 指令的相關內容

其中,time為設置的時間,默認為5s。

該指令用於設置客戶端請求發送的次數,當客戶端向被代理伺服器發送相同請求達到該指令設定的次數後,Nginx伺服器才對該請求的響應數據做緩存。合理設置該值可以有效地降低硬碟上緩存數據的數量,並提高緩存的命中率。

其中,number為設置的次數。默認設置為1。

該指令用於設置Nginx伺服器存儲緩存數據的路徑以及和緩存索引相關的內容

該指令設置比較復雜,一般需要設置前面三個指令的情形比較多,後面的幾個變數與Nginx伺服器緩存索引重建進程及管理進程的性能相關,一般情況下保持默認設置就可以了。我們來看幾個簡單的配置實例:

如果Nginx在訪問被代理伺服器過程中出現被代理的伺服器無法訪問或者訪問錯誤等現象時,Nginx伺服器可以使用歷史緩存響應客戶端的請求,這些數據不一定和被代理伺服器上最新的數據相一致,但對於更新頻率不高的後端伺服器來說,Nginx伺服器的該功能在一定程度上能夠為客戶端提供不間斷訪問。該指令用來設置一些狀態,當後端被代理的伺服器處於這些狀態時,Nginx伺服器啟用該功能。

該指令可以支持的狀態如語法結構中所示。

該指令可以針對不同的HTTP響應狀態設置不同的緩存時間,

該指令同於配置在什麼情況下不使用cache功能

該指令配置是否在本地磁碟緩存來自被代理伺服器的響應數據。這是Nginx伺服器提供的另一種緩存數據的方法,但是該功能相對 Proxy Cache簡單一些,它不提供緩存過期更新、內存索引建立等功能,不佔用內存空間,對靜態數據的效果比較好。

Proxy Store方法多使用在被代理伺服器端發生錯誤的情況下,用來緩存被代理伺服器的響應數據。

該指令用於設置用戶或用戶組對Proxy Store緩存的數據的訪問許可權,

有關Proxy Store方法的使用,我們通過官方給出的實例加深理解,在該實例中筆者通過注釋對配置做了說明:

Ⅵ Nginx文件描述符緩存--open_file_cache

標簽(空格分隔): nginx

NGINX雖然已經對靜態內容做過優化。但在高流量網站的情況下,仍然可以使用open_file_cache進一步提高性能。 NGINX緩存將最近使用的文件描述符和相關元數據(如修改時間,大小等)存儲在緩存中。緩存不會存儲所請求文件的內容。

啟用此指令將存儲以下信息的緩存:

如下例子:

在上述配置中,為1,000個元素定義了一個緩存。 inactive參數配置到期時間為20秒。 沒有必要為該指令設置非活動時間段,默認情況下,非活動時間段為60秒。
NGINX還定義了一些相關的指令,可用於在錯誤和有效性檢查期間配置open_file_cache的行為。

NGINX的open_file_cache保存信息的快照。 由於信息在源處更改,快照可能在一段時間後無效。 open_file_ cache_valid指令定義時間段(以秒為單位),之後將重新驗證open_file_cache中的元素。默認情況下,60秒後重新檢查元素。 如下例子:

NGINX將在非活動時間段之後從高速緩存中清除元素。 此指令可用於配置最小訪問次數以將元素標記為活動使用。 默認情況下,最小訪問次數設置為1次或更多次。如下例子

如前所述,NGINX可以緩存在文件訪問期間發生的錯誤。但是這需要通過設置open_file_cache_errors指令來啟用。 如果啟用錯誤緩存,則在訪問資源(不查找資源)時,NGINX會報告相同的錯誤。默認情況下,錯誤緩存設置為關閉。

Ⅶ nginx 緩存機制

Nginx緩存的基本思路
基本思想是利用客戶訪問的時間局部性原理,對客戶已經訪問過的內容在Nginx伺服器本地建立副本,這樣在一段時間內再次訪問該數據,就不需要通過Nginx伺服器再次向後端伺服器發出請求,所以能夠減少Nginx伺服器與後端伺服器之間的網路流量,減輕網路擁塞,同時還能減小數據傳輸延遲,提高用戶訪問速度。同時,當後端伺服器宕機時,Nginx伺服器上的副本資源還能夠回應相關的用戶請求,這樣能夠提高後端伺服器的魯棒性。

對於緩存,我們大概會有以下問題:
(1)緩存文件放在哪兒?
(2)緩存的空間大小是否可以限定?
(3)如何指定哪些請求被緩存?
(4)緩存的有效期是多久?
(5)對於某些請求,是否可以不走緩存?

解決這些問題後,nginx的緩存也就基本配置完成了,下面看詳細配置過程
開啟緩存

要使用緩存,首先要使用 proxy_cache_path 這個指令(必須放在 http 上下文的頂層位置),然後在目標上下文中使用 proxy_cache 指令

配置示例

proxy_cache_path 有兩個必填參數,第一個參數為 緩存目錄,第二個參數keys_zone指定緩存名稱和佔用內存空間的大小(註:示例中的10m是對內存中緩存內容元數據信息大小的限制,如果想限制緩存總量大小,需要用 max_size 參數)

proxy_cache 的參數為之前指定的緩存名稱

緩存管理的相關進程
在緩存工作中有兩個附加進程:
(1)緩存管理器
定期檢查緩存狀態,看緩存總量是否超出限制,如果超出,就移除其中最少使用的部分
(2)緩存載入器
載入器只在nginx啟動後運行一次,把緩存內容的元數據信息載入到內存空間,如果一次性載入全部緩存信息,會大量消耗資源,使nginx在啟動後的幾分鍾里變慢,為避免此問題,有3種載入策略:
loader_threshold – 指定每次載入執行的時間
loader_files – 每次最多載入的數量
loader_sleeps – 每次載入的延時
例如:
proxy_cache_path /data/nginx/cache keys_zone=one:10m loader_threshold=300 loader_files=200;
指定緩存哪些請求
nginx默認會緩存所有 get 和 head 方法的請求結果,緩存的key默認使用請求字元串
(1)自定義key
例如 proxy_cache_key " request_uri cookie_nocache arg_comment;
如果任何一個參數值不為空,或者不等於0,nginx就不會查找緩存,直接進行代理轉發
綜合示例

nginx 緩存機制
三分鍾看懂Nginx伺服器的緩存原理和機制

Ⅷ Nginx作為緩存服務

  上一篇文章講了Nginx作為代理服務的使用方式,這篇文章我們講一講Nginx作為緩存服務是怎麼工作的,以及實戰的使用。
  先看一張圖:

  面對第一次客戶端的應用Nginx需要從後端的服務獲取數據,對於後續的請求,Nginx若進行了緩存就不再從後端服務獲取數據。

語法:proxy_cache_path path [levels=levels].只能用在http中。

  proxy_cache zone | off。默認是關閉的,可以用在http,server,location中。

訪問zzm這個路徑的時候,會返回配置文件中的spring.s項,具體值可以參考我們的啟動設置:

三個後台金正分別對應6000埠,6001埠,6002埠

所以我們訪問ip:port/zzm的時候會自動去訪問後台

我們首先注釋掉proxy_cache zzm_cache;進行訪問,也就是沒有緩存的情況下,訪問3次:

我們可以看到沒有緩存的情況下,會進行輪詢訪問,每次訪問的結果不一樣,而且我們的緩存路徑什麼都沒有,讓我想起了一首歌空空如也:

好奇的看了下目錄下的文件內容:

add_header Nging-Cache "$upstream_cache_status";

當我們沒有緩存的時候,我們可以看到應答會是MISS:

現在nginx.conf中加入新的配置項:

此時我們怒刷前端頁面,會發現後端日誌如下:

Nginx的緩存服務就講到這里,歡迎大家指正

Ⅸ 如何利用Nginx的緩沖,緩存優化提升性能

使用緩沖釋放後端伺服器
反向代理的一個問題是代理大量用戶時會增加伺服器進程的性能沖擊影響。在大多數情況下,可以很大程度上能通過利用Nginx的緩沖和緩存功能減輕。
當代理到另一台伺服器,兩個不同的連接速度會影響客戶的體驗:
從客戶機到Nginx代理的連接。
從Nginx代理到後端伺服器的連接。
Nginx具有優化這些連接調整其行為的能力。
如果沒有緩沖,數據從代理的伺服器發送並立即開始被發送到客戶。如果假定客戶端很快,緩沖可以關閉而盡快使數據到客戶端,有了緩沖,Nginx 代理將暫時存儲後端的響應,然後按需供給數據給客戶端。如果客戶端是緩慢的,允許Nginx伺服器關閉到後端的連接。然後,它可以處理數據分配到客戶端, 以任何可能的速度。
Nginx默認有緩沖設計,因為客戶端往往有很大的不同的連接速度。我們可以用以下指令調節緩沖行為。可以在HTTP,server或 location位置來設置。重要的是要記住,大小size指令是針對每個請求配置的,所以增加超出你需求會影響你的性能,如果這時有許多客戶端請求:
proxy_buffering:該指令控制緩沖是否啟用。默認情況下,它的值是「on」。
proxy_buffers:該指令控制代理響應緩沖區的數量(第一個參數)和大小(第二個參數)。默認配置是8個緩沖區大小等於一個內存頁(4K或者8K)。增加緩沖區的數目可以讓你緩沖更多信息。
proxy_buffer_size:從後端伺服器的響應頭緩沖區大小,它包含headers,和其他部分響應是分開的。該指令設置響應部分的緩沖區大小。默認情況下,它和proxy_buffers是相同的尺寸,但因為這是用於頭信息,這通常可以設置為一個較低的值。
proxy_busy_buffers_size:此指令設置標注「client-ready」緩沖區的最大尺寸。而客戶端可以一次讀取來自一個緩沖區的數據,緩沖被放置在隊列中,批量發送到客戶端。此指令控制允許是在這種狀態下的緩沖空間的大小。
proxy_max_temp_file_size:這是每個請求能用磁碟上臨時文件最大大小。這些當上游響應太大不能裝配到緩沖區時被創建。
proxy_temp_file_write_size:這是當被代理伺服器的響應過大時Nginx一次性寫入臨時文件的數據量。
proxy_temp_path:當上游伺服器的響應過大不能存儲到配置的緩沖區域時,Nginx存儲臨時文件硬碟路徑。
正如你所看到的,Nginx提供了相當多的不同的指令來調整緩沖行為。大多數時候,你不必擔心太多,但它對於調整一些值可能是有用的。可能最有用的調整是proxy_buffers和proxy_buffer_size指令。
一個例子:、
proxy_busy_buffers_size 8k;
proxy_max_temp_file_size 2048m;
proxy_temp_file_write_size 32k;
proxy_pass http://example.com;
配置代理服務緩存來減少響應時間
盡管緩沖可以幫助釋放後端伺服器以處理更多的請求,Nginx還提供了一種方法來緩存從後端伺服器的內容,對於許多請求無需連接到上游。
配置代理緩存
要設置緩存用於代理內容,我們可以使用proxy_cache_path指令。這將創建區域保存來自被代理伺服器返回的數據。該proxy_cache_path指令必須在HTTP上下文部分進行設置。
在下面的例子中,我們將配置一些相關的指令來建立我們的緩存系統。
# http context
proxy_cache_path /var/lib/nginx/cache levels=1:2 keys_zone=backcache:8m max_size=50m;
proxy_cache_key "$scheme$request_method$host$request_uri$is_args$args";
proxy_cache_valid 200 302 10m;
proxy_cache_valid 404 1m;
用proxy_cache_path指令,我們首先應該已經定義在文件系統中希望存儲緩存的目錄。在這個例子中,我們選擇在/var/lib/nginx/cache目錄。如果該目錄不存在,你可以用正確的許可權和所有權創建它:
sudo mkdir -p /var/lib/nginx/cache
sudo chown www-data /var/lib/nginx/cache
sudo chmod 700 /var/lib/nginx/cache
levels=參數指定緩存將如何組織。 Nginx將通過散列鍵(下方配置)的值來創建一個緩存鍵。我們選擇了上述的levels決定了單個字元目錄(這是散列值的最後一個字元)配有兩個字元的 子目錄(下兩個字元取自散列值的末尾)將被創建。你通常不必對這個細節關注,但它可以幫助Nginx快速找到相關的值。
keys_zone=參數定義緩存區域的名字,我們稱之為backcache。這也是我們定義多少元數據存儲的地方。在這個例子里,我們是存儲8 MB的key。對於每兆位元組,Nginx可存儲8000左右的條目。MAX_SIZE參數設置實際緩存數據的最大尺寸。
我們使用上面的另一個指令是proxy_cache_key。這個設置將設置用於存儲緩存值的鍵。此鍵用於檢查是否一個請求可以從高速緩存提供服務。我們將它設置成方案(http或https),HTTP請求方法,以及被請求的主機和URI的組合。
proxy_cache_valid指令可以被指定多次。它依賴於狀態代碼值使我們能夠配置多長時間存儲。在我們的例子中,我們對於後端返回200和302存儲10分鍾,404響應的一分鍾過期。
現在,我們已經配置了緩存區,但我們仍然需要告訴Nginx什麼時候使用緩存。
在我們代理到後端的location位置,我們可以配置使用這個緩存:
# server context
location /proxy-me {
proxy_cache backcache;
proxy_cache_bypass $http_cache_control;
add_header X-Proxy-Cache $upstream_cache_status;
proxy_pass http://backend;
}
使用proxy_cache指令,就可以指定該backcache緩存區被用於這個位置。 Nginx會在這里檢查傳遞給後端有效的條目。
上述proxy_cache_bypass指令被設置為$ http_cache_control變數。這將包含一個指示器,用以指示該客戶端是否被明確地請求一個最新的,非緩存版本。設置此指令允許Nginx正確處理這些類型的客戶端請求。無需進行進一步的配置。
我們還增加了被稱為X-Proxy-Cache的額外頭。我們設置這個頭部為$ upstream_cache_status變數的值。這個設置頭,使我們能夠看到,如果請求導致高速緩存命中,高速緩存未命中,或者高速緩存被明確旁 路。這是對於調試特別有價值,也對客戶端是有用的信息。
關於緩存結果的注意事項
高速緩存能夠極大地提高代理伺服器的性能。不過,也需要明確的考慮配置緩存時候,要記住。
首先,任何用戶相關的數據不應被高速緩存。這可能導致一個用戶的數據被呈現給其他用戶。如果你的網站是完全靜態的,這可能不是一個問題。
如果你的網站有一些動態元素,你將不得不考慮到這一點。你如何處理要看是什麼應用程序或伺服器處理的後端處理。對於私人的內容,你應該設置Cache-Control頭為「no-cache」,「no-sotre」,或者「private」依賴於數據的性質:
no-cache:
請求: 告知緩存者,必須原原本本的轉發原始請求,並告知任何緩存者,需要去轉發請求,並驗證緩存(如果有的話).對應名詞:端對端重載.
響應: 允許緩存者緩存副本.那麼其實際價值是,總是強制緩存者,校驗緩存的新鮮度.一旦確認新鮮,則可以使用緩存副本作為響應. no-cache,還可以指定某個包含欄位,比如一個典型應用,no-cache=Set-Cookie. 這樣做的結果,就是告知緩存者,對於Set-Cookie欄位,你不要使用緩存內容.而是使用新滴.其他內容則可以使用緩存
no-store:表示在任何時候收到的數據不被緩存。這對於私人數據是最安全,因為它意味著,該數據必須從伺服器每次進行檢索。
private:這表明共享的緩存空間不能緩存此數據。這可以用於指示用戶的瀏覽器高速緩存數據,但代理伺服器不應當考慮隨後的請求數據有效。
public:這表明該響應是可在連接的任何點被高速緩存的公共數據。
一個相關的可以控制此行為報頭是max-age頭,其指示,任何資源應該緩存的秒數。
根據內容的敏感性,正確設置這些頭,會幫助你利用緩存優勢,同時保持你的私人數據安全,並使您的動態數據最新。
如果你的後端也使用Nginx,你可以設置使用過期指令,設置max-age來實現Cache-Control:
location / {
expires 60m;
}
location /check-me {
expires -1;
}
在上面的例子中,第一個塊允許緩存一個小時的內容。第二塊設置Cache-Control頭為「無緩存」。要設置其他值,可以使用add_header指令,就像這樣:
location /private {
expires -1;
add_header Cache-Control "no-store";
}