Nginx
php
一個web緩存坐落於客戶端和「原始服務器(origin server)」中間,它保留了全部可見內容的拷貝。若是一個客戶端請求的內容在緩存中存儲,則能夠直接在緩存中得到該內容而不須要與服務器通訊。這樣一來,因爲web緩存距離客戶端「更近」,就能夠提升響應性能,並更有效率的使用應用服務器,由於服務器不用每次請求都進行頁面生成工做。
在瀏覽器和應用服務器之間,存在多種「潛在」緩存,如:客戶端瀏覽器緩存、中間緩存、內容分發網絡(CDN)和服務器上的負載平衡和反向代理。緩存,僅在反向代理和負載均衡的層面,就對性能提升有很大的幫助。html
Nginx從0.7.48版本開始,支持了相似Squid的緩存功能。這個緩存是把URL及相關組合看成Key,用md5編碼哈希後保存在硬盤上,因此它能夠支持任意URL連接,同時也支持404/301/302這樣的非200狀態碼。雖然目前官方的Nginx Web緩存服務只能爲指定URL或狀態碼設置過時時間,不支持相似Squid的PURGE指令,手動清除指定緩存頁面,可是,經過一個第三方的Nginx模塊,能夠清除指定URL的緩存。linux
Nginx的Web緩存服務主要由proxy_cache相關指令集和fastcgi_cache相關指令集構成,前者用於反向代理時,對後端內容源服務器進行緩存,後者主要用於對FastCGI的動態程序進行緩存。二者的功能基本上同樣。nginx
最新的Nginx 0.8.32版本,proxy_cache和fastcgi_cache已經比較完善,加上第三方的ngx_cache_purge模塊(用於清除指定URL的緩存),已經能夠徹底取代Squid。咱們已經在生產環境使用了 Nginx 的 proxy_cache 緩存功能超過兩個月,十分穩定,速度不遜於 Squid。web
在功能上,Nginx已經具有Squid所擁有的Web緩存加速功能、清除指定URL緩存的功能。而在性能上,Nginx對多核CPU的利用,賽過Squid很多。另外,在反向代理、負載均衡、健康檢查、後端服務器故障轉移、Rewrite重寫、易用性上,Nginx也比Squid強大得多。這使得一臺Nginx能夠同時做爲「負載均衡服務器」與「Web緩存服務器」來使用。docker
咱們只須要兩個命令就能夠啓用基礎緩存: proxy_cache_path和proxy_cache
proxy_cache_path用來設置緩存的路徑和配置,proxy_cache用來啓用緩存。數據庫
proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m
use_temp_path=off;
server {
...
location / {
proxy_cache my_cache;
proxy_pass http://my_upstream;
}
}
proxy_cache_path命令中的參數及對應配置說明以下:後端
1.用於緩存的本地磁盤目錄是/path/to/cache/瀏覽器
2.levels在/path/to/cache/設置了一個兩級層次結構的目錄。將大量的文件放置在單個目錄中會致使文件訪問緩慢,因此針對大多數部署,咱們推薦使用兩級目錄層次結構。若是levels參數沒有配置,則NGINX會將全部的文件放到同一個目錄中。緩存
3.keys_zone設置一個共享內存區,該內存區用於存儲緩存鍵和元數據,有些相似計時器的用途。將鍵的拷貝放入內存可使NGINX在不檢索磁盤的狀況下快速決定一個請求是
HIT
仍是MISS
,這樣大大提升了檢索速度。一個1MB的內存空間能夠存儲大約8000個key,那麼上面配置的10MB內存空間能夠存儲差很少80000個key。4.max_size設置了緩存的上限(在上面的例子中是10G)。這是一個可選項;若是不指定具體值,那就是容許緩存不斷增加,佔用全部可用的磁盤空間。當緩存達到這個上線,處理器便調用cache
manager來移除最近最少被使用的文件,這樣把緩存的空間下降至這個限制之下。5.inactive指定了項目在不被訪問的狀況下可以在內存中保持的時間。在上面的例子中,若是一個文件在60分鐘以內沒有被請求,則緩存管理將會自動將其在內存中刪除,無論該文件是否過時。該參數默認值爲10分鐘(10m)。注意,非活動內容有別於過時內容。NGINX不會自動刪除由緩存控制頭部指定的過時內容(本例中Cache-Control:max-age=120)。過時內容只有在inactive指定時間內沒有被訪問的狀況下才會被刪除。若是過時內容被訪問了,那麼NGINX就會將其從原服務器上刷新,並更新對應的inactive計時器。
6.NGINX最初會將註定寫入緩存的文件先放入一個臨時存儲區域, use_temp_path=off命令指示NGINX將在緩存這些文件時將它們寫入同一個目錄下。咱們強烈建議你將參數設置爲off來避免在文件系統中沒必要要的數據拷貝。use_temp_path在NGINX1.7版本和NGINX Plus R6中有所介紹。
最終, proxy_cache命令啓動緩存那些URL與location部分匹配的內容(本例中,爲/
)。你一樣能夠將proxy_cache命令添加到server部分,這將會將緩存應用到全部的那些location中未指定本身的proxy_cache命令的服務中。
NGINX內容緩存的一個很是強大的特性是:當沒法從原始服務器獲取最新的內容時,NGINX能夠分發緩存中的陳舊(stale,編者注:即過時內容)內容。這種狀況通常發生在關聯緩存內容的原始服務器宕機或者繁忙時。比起對客戶端傳達錯誤信息,NGINX可發送在其內存中的陳舊的文件。NGINX的這種代理方式,爲服務器提供額外級別的容錯能力,並確保了在服務器故障或流量峯值的狀況下的正常運行。爲了開啓該功能,只須要添加proxy_cache_use_stale命令便可:
location / {
...
proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504;
}
按照上面例子中的配置,當NGINX收到服務器返回的error,timeout或者其餘指定的5xx錯誤,而且在其緩存中有請求文件的陳舊版本,則會將這些陳舊版本的文件而不是錯誤信息發送給客戶端。
NGINX提供了豐富的可選項配置用於緩存性能的微調。下面是使用了幾個配置的例子:
proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m
use_temp_path=off;
server {
...
location / {
proxy_cache my_cache;
proxy_cache_revalidate on;
proxy_cache_min_uses 3;
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
proxy_cache_lock on;
proxy_pass http://my_upstream;
}
}
配置解釋以下:
proxy_cache_revalidate指示NGINX在刷新來自服務器的內容時使用GET請求。若是客戶端的請求項已經被緩存過了,可是在緩存控制頭部中定義爲過時,那麼NGINX就會在GET請求中包含If-Modified-Since字段,發送至服務器端。這項配置能夠節約帶寬,由於對於NGINX已經緩存過的文件,服務器只會在該文件請求頭中Last-Modified記錄的時間內被修改時纔將所有文件一塊兒發送。
proxy_cache_min_uses設置了在NGINX緩存前,客戶端請求一個條目的最短期。當緩存不斷被填滿時,這項設置便十分有用,由於這確保了只有那些被常常訪問的內容纔會被添加到緩存中。該項默認值爲1。
proxy_cache_use_stale中的updating參數告知NGINX在客戶端請求的項目的更新正在原服務器中下載時發送舊內容,而不是向服務器轉發重複的請求。第一個請求陳舊文件的用戶不得不等待文件在原服務器中更新完畢。陳舊的文件會返回給隨後的請求直到更新後的文件被所有下載。
當proxy_cache_lock被啓用時,當多個客戶端請求一個緩存中不存在的文件(或稱之爲一個MISS),只有這些請求中的第一個被容許發送至服務器。其餘請求在第一個請求獲得滿意結果以後在緩存中獲得文件。若是不啓用proxy_cache_lock,則全部在緩存中找不到文件的請求都會直接與服務器通訊。
默認狀況下,NGINX須要考慮從原始服務器獲得的Cache-Control標頭。當在響應頭部中Cache-Control被配置爲Private,No-Cache,No-Store或者Set-Cookie,NGINX不進行緩存。NGINX僅僅緩存GET和HEAD客戶端請求。你也能夠參照下面的解答覆蓋這些默認值。
一、Cache-Control頭部能否被忽略?
能夠,使用proxy_ignore_headers命令。以下列配置:
ocation /images/ {
proxy_cache my_cache;
proxy_ignore_headers Cache-Control;
proxy_cache_valid any 30m;
...
}
NGINX會忽略全部/images/下的Cache-Control頭。proxy_cache_valid命令強制規定緩存數據的過時時間,若是忽略Cache-Control頭,則該命令是十分必要的。NGINX不會緩存沒有過時時間的文件。
二、NGINX可否緩存POST 請求?
能夠,使用proxy_cache_methods命令:
proxy_cache_methods GET HEAD POST;
三、NGINX 能夠緩存動態內容嗎?
能夠,提供的Cache-Control頭部能夠作到。緩存動態內容,甚至短期內的內容能夠減小在原始數據庫和服務器中加載,能夠提升第一個字節的到達時間,由於頁面不須要對每一個請求都生成一次。
四、可使用Cookie做爲緩存鍵的一部分嗎?
能夠,緩存鍵能夠配置爲任意值,如:
proxy_cache_key $proxy_host$request_uri$cookie_jessionid;
五、NGINX 如何處理字節範圍請求?
若是緩存中的文件是最新的,NGINX會對客戶端提出的字節範圍請求傳遞指定的字節。若是文件並無被提早緩存,或者是陳舊的,那麼NGINX會從服務器上下載完整文件。若是請求了單字節範圍,NGINX會盡快的將該字節發送給客戶端,若是在下載的數據流中恰好有這個字節。若是請求指定了同一個文件中的多個字節範圍,NGINX則會在文件下載完畢時將整個文件發送給客戶端。 一旦文件下載完畢,NGINX將整個數據移動到緩存中,這樣一來,不管未來的字節範圍請求是單字節仍是多字節範圍,NGINX均可以在緩存中找到指定的內容當即響應。
參考:
NGINX其餘優化