⑴ Nginx緩存設置教程
| 這篇文章主要介紹了Nginx緩存設置案例詳解,本篇文章通過簡要的案例,講解了該項技術的了解與使用,以下就是詳細內容,需要的朋友可以參考下 |
在開發調試web的時候，經常會碰到因瀏覽器緩存(cache)而經常要去清空緩存或者強制刷新來測試的煩惱，提供下apache不緩存配置和nginx不緩存配置的設置。在常用的緩存設置裡面有兩種方式，都是使用add_header來設置：分別為Cache-Control和Pragma。
對於站點中不經常修改的靜態內容（如圖片，JS，CSS），可以在伺服器中設置expires過期時間，控制瀏覽器緩存，達到有效減小帶寬流量，降低伺服器壓力的目的。
以Nginx伺服器為例：
【背景】：Expires是Web伺服器響應消息頭欄位，在響應http請求時告訴瀏覽器在過期時間前瀏覽器可以直接從瀏覽器緩存取數據，而無需再次請求。
【相關資料】
1、Cache-control策略
Cache-Control與Expires的作用一致，都是指明當前資源的有效期，控制瀏覽器是否直接從瀏覽器緩存取數據還是重新發請求到伺服器取數據。只不過Cache-Control的選擇更多，設置更細致，如果同時設置的話，其優先順序高於Expires。
http協議頭Cache-Control ：
值可以是public、private、no-cache、no- store、no-transform、must-revalidate、proxy-revalidate、max-age
各個消息中的指令含義如下：
Last-Modified/If-Modified-Since
其最終達到的就是等效於設置這三類html緩存技術：
⑵ 【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的緩沖，緩存優化提升性能
使用緩沖釋放後端伺服器
反向代理的一個問題是代理大量用戶時會增加伺服器進程的性能沖擊影響。在大多數情況下，可以很大程度上能通過利用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";
}
⑷ nginx如何實現負載均衡、限流、緩存、黑白名單和灰度發布
1.負載均衡配置
2.失敗重試配置
在fail_timeout時間內失敗了max_fails次請求後,認為上游伺服器不可用,就會將服務地址剔除掉,fail_timeout時間後會再次將伺服器加入存活列表進行重試。
limit_req_zone指令設置參數
參數說明
limit_req_zone定義在http塊中，$binary_remote_addr表示保存客戶端IP地址的二進制形式。
Zone定義IP狀態及URL訪問頻率的共享內存區域。zone=keyword標識區域的名字，以及冒號後面跟區域大小。16000個IP地址的狀態信息約1MB，例子區域可以存儲160000個IP地址。
Rate定義最大請求速率。示例中速率不能超過每秒10個請求。
設置限流
burs排隊大小,nodelay不限制單個請求間的時間。具體使用可以查看高並發場景如何使用nginx實現限流-實戰篇
不限流白名單
該配置說明 192.168.1.0/24網段的ip訪問是不限流的,其它限流。ip後面數字的含義
24表示子網掩碼:255.255.255.0
16表示子網掩碼:255.255.0.0
8表示子網掩碼:255.0.0.0
1.瀏覽器緩存 靜態資源緩存用expire
Response Header中添加了Expires和Cache-Control
所謂的靜態資源一般包括一直不變的圖像,如網站的logo,js、css靜態文件還有可下載的內容，媒體文件
協商緩存(add_header ETag/Last-Modified value)包括html文件,經常替換的圖片,經常需要修改的js、css文件和基本不變的api介面
不需要緩存包括用戶隱私等敏感數據,用戶經常變動的api介面
2.代理層緩存
在本地磁碟創建一個文件目錄,根據我們的配置把請求資源以k(key自定義,這邊用url的hash值)->v形式緩存到目錄里,並根據需求對內容設置緩存時長,比如狀態碼為200緩存10分鍾,其餘的緩存1分鍾等待。要清理緩存可以藉助purger的功能。如果ab測試/個性化需求時應禁用瀏覽器緩存,否則會因為緩存導致誤差。
方式一
方式二 lua+redis動態黑名單(openresty)
配置(/usr/local/openresty/nginx/conf/nginx.conf)
lua腳本編寫(ip_blacklist.lua)
1.根據cookie實現灰度發布
根據cooke查詢version值，根據version跳轉到對應的host,如果沒有匹配上的就跳轉到默認配置。
2.根據來路ip實現灰度發布
⑸ 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優化以及多級緩存
配置文件：
lua是一個小巧的腳本語言，由標准C編寫而成，幾乎在所有操作系統和平台上都可以編譯運行。其設計目的是為了嵌入應用程序中，從而為應用程序提供靈活的擴展和定製功能。
應用場景：游戲開發、獨立應用腳本、redis中嵌套調用實現類似事務的功能，web容器匯總處理NGINX的過濾緩存等等邏輯
OpenResty是一個基於Nginx與Lua的高性能web平台，由中國人章亦春發起，其內部集成了大量精良的Lua庫、第三方模塊以及大多數的依賴項。用於方便搭建能處理超高並發、擴展性極高的動態Web應用、web服務和動態網關
OpenResty簡單理解成就相當於封裝了NGINX，並且集成了LUA腳本，開發人員只需要簡單的使用其提供了模塊就可以實現相關的邏輯，而不像之前，還需要在NGINX中編寫lua的腳本。
1.拉取一個openresty的鏡像
2.隨便構建一個容器用於拷貝配置文件
3.進入容器，查找配置文件路徑（這里直接給出）
4.退出容器，復制容器中配置文件到宿主機
5.修改配置文件
1、使用Lua查詢Nginx緩存，如果有緩存，則直接將緩存中的分類數據返回
2、如果Nginx緩存中沒有分類數據，則通過Lua腳本查詢Redis，如果Redis中有數據，則將數據存入到Nginx緩存中，並返回查詢到的數據
3、如果Redis中也沒有緩存，則此時通過Lua腳本查詢Mysql，如果Mysql中有數據，將分類數據存入到Redis緩存，並返回數據
⑺ 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 緩存機制
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文件描述符緩存--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設置瀏覽器協商緩存過程詳解
一、強緩存與協商緩存的區別
強緩存：瀏覽器不與服務端協商直接取瀏覽器緩存
協商緩存：瀏覽器會先向伺服器確認資源的有效性後才決定是從緩存中取資源還是重新獲取資源
二、協商緩存運作原理
現在有一個這樣的業務情景：後端的靜態資源會不定時地發生更新，而因為瀏覽器默認使用強緩存，會默認從瀏覽器緩存中取到過時的資源。
現在我們希望瀏覽器每次獲取資源的時候都向後端確認資源是否更新，就要設置瀏覽器使用協商緩存
那麼後端如何判斷資源是否更新了呢？這時就要用到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才是真正的不進行緩存。