我們都知道應用程序和網站的性能是他們成功的關鍵因素。但是，使您的應用程序或網站表現更好的過程并不總是很清楚。代碼質量和基礎架構當然至關重要，但在許多情況下，您可以通過專注于一些非?；镜膽贸绦虻慕桓都夹g，對應用程序的最終用戶體驗進行大量改進。
其中一個例子是在應用程序棧中實現和優化緩存。在教程中介紹的技術可以幫助新手和高級用戶使用 Nginx 中包含的內容緩存功能，從而獲得更好的性能。
概覽
內容緩存位于客戶端和源服務器 (upstream) 之間，并保存它看到的所有內容的副本。如果客戶端請求緩存已存儲的內容，則它會直接返回內容而不連接源服務器。這提高了性能，因為內容緩存更靠近客戶端，并且更有效地使用應用程序服務器，因為它們不必每次都從頭開始生成頁面。
Web 瀏覽器和應用程序服務器之間可能存在多個緩存：客戶端的瀏覽器緩存，中間緩存，內容交付網絡（CDN）以及位于應用程序服務器前面的負載平衡器或反向代理。即使在反向代理/負載均衡器級別，緩存也可以極大地提高性能。
這里舉一個例子，比如我的站點使用 Next.js 服務器端口渲染，由于服務器性能比較差，當然 $5 的服務器，并不能期望好到那里去，能用就已經非常了不起，能進入這個局域網就好了，別期望太多。
每次打開頁面將近花費 7 秒左右，當這其中包含網絡延遲，但當我直接在服務器端(127.0.0.1) 發起請求時，時間接近 5 秒，然后再排除從數據庫獲取數據時間，服務器端渲染時間用了 4.5 秒，實在太慢，此時我能想到最快解決問題答案就是緩存，但在那里加入緩存，從每一步時間看來，在 Nginx 加入緩存最快解決問題
Nginx 通常作為應用程序堆棧中的反向代理或負載平衡器部署，并具有一整套緩存功能。下面我們將討論如何使用 Nginx 配置基本緩存。
如何設置和配置基本緩存
只需要兩個指令即可啟用基本緩存：proxy_cache_path 和 proxy_cache。
proxy_cache_path 指令設置緩存的路徑和配置，proxy_cache 用來指令激活它。
|
1
2
3
4
5
6
7
8
9
10
11
|
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 指令的參數定義了以下設置：
緩存的本地磁盤目錄稱為 /path/to/cache/。
- levels 在/path/to/cache/ 下設置一個兩級目錄層次結構。在單個目錄中包含大量文件會降低文件訪問速度，因此我們建議對大多數部署使用兩級目錄層次結構。如果 levels 未包含該參數，Nginx 會將所有文件放在同一目錄中。
- keys_zone 設置共享內存區域，用于存儲緩存鍵和元數據，例如使用計時器。擁有內存中的密鑰副本，Nginx 可以快速確定請求是否是一個 HIT 或 MISS 不必轉到磁盤，從而大大加快了檢查速度。1 MB 區域可以存儲大約 8,000 個密鑰的數據，因此示例中配置的 10 MB 區域可以存儲大約 80,000 個密鑰的數據。
- max_size 設置緩存大小的上限（在本例中為 10 千兆字節）。它是可選的; 不指定值允許緩存增長以使用所有可用磁盤空間。當緩存大小達到限制時，一個稱為緩存管理器的進程將刪除最近最少使用的緩存，將大小恢復到限制之下的文件。
- inactive 指定項目在未被訪問的情況下可以保留在緩存中的時間長度。在此示例中，緩存管理器進程會自動從緩存中刪除 60 分鐘未請求的文件，無論其是否已過期。默認值為 10 分鐘（10m）。非活動內容與過期內容不同。Nginx 不會自動刪除緩存 header 定義為已過期內容（例如 Cache-Control:max-age=120）。過期（陳舊）內容僅在指定時間內未被訪問時被刪除。訪問過期內容時，Nginx 會從原始服務器刷新它并重置 inactive 計時器。
- Nginx 首先將發往高速緩存的文件寫入臨時存儲區域，use_temp_path=off 指令指示 NGINX 將它們寫入將被高速緩存的相同目錄。我們建議您將此參數設置 off 為避免在文件系統之間進行不必要的數據復制。use_temp_path 在 Nginx 1.7.10 中引入。
最后，該 proxy_cache 指令激活與父 location 塊的 URL 匹配的所有內容的緩存（在示例中為/）。您還可以在 server 塊中包含 proxy_cache 指令; 它適用于沒有自己的 location 指令的服務器的所有塊。
當上游服務器關閉()時提供緩存內容
Nginx 內容緩存的一個強大功能是，Nginx 可以配置為在無法從原始服務器獲取新內容時從緩存中提供已緩存的內容。如果緩存資源的所有源服務器都已關閉或暫時占用，則會發生這種情況。
Nginx 不是將錯誤傳遞給客戶端，而是從緩存中提供文件的陳舊版本。這為 Nginx 代理的服務器提供了額外的容錯能力，并確保在服務器故障或流量高峰時的正常運行時間。要啟用此功能，請包含 proxy_cache_use_stale 指令：
|
1
2
3
4
|
location / { # ... proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504; } |
使用此示例配置，如果 Nginx 從原始服務器收到一個 error，timeout 或任何指定的 5xx 錯誤，并且在其緩存中具有所請求文件的過時版本，則它會傳遞過時文件，而不是將錯誤轉發到客戶端。
如何提高緩存性能
Nginx 具有豐富的可選設置，可用于微調緩存的性能。這是一個激活其中一些的例子：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
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_background_update on; proxy_cache_lock on; proxy_pass http://my_upstream; } } |
這些指令配置以下行為：
- proxy_cache_revalidate 指示 Nginx 在使用 GET 條件請求時，從源服務器刷新內容。如果客戶端請求緩存但是由緩存控制頭定義的過期的內容，則 Nginx將 If-Modified-Since 字段包含在 GET 請求的標頭中將它發送到源服務器。因為服務器只有在 Nginx 最初緩存它時自附加到文件的標題 Last-Modified 中記錄的時間以來修改了整個項目。
- proxy_cache_min_uses 設置客戶端在 Nginx 緩存之前必須請求多少次才被緩存。如果緩存不斷填滿，這將非常有用，因為它可確保只將最常訪問的項添加到緩存中。默認 proxy_cache_min_uses 設置為 1。
- 指令 updating 參數 proxy_cache_use_stale 與啟用 proxy_cache_background_update 指令相結合，指示當客戶端請求已過期或正在從原始服務器更新的項目時，Nginx 會傳遞過時的內容。所有更新都將在后臺完成。在完全下載更新的文件之前，將為所有請求返回陳舊文件。
- 與 proxy_cache_lock 啟用，如果多個客戶端請求的文件不在緩存（MISS），只有第一個這些請求是通過原始服務器的。其余請求等待滿足該請求，然后從緩存中提取文件。如果 proxy_cache_lock 未啟用，會導致緩存未命中的所有請求都將直接發送到源服務器。
跨多個硬盤拆分緩存
如果您有多個硬盤驅動器，可以使用 Nginx 在它們之間拆分緩存。以下示例根據請求 URI 將客戶端均勻分布在兩個硬盤驅動器上：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
proxy_cache_path /path/to/hdd1 levels=1:2 keys_zone=my_cache_hdd1:10m max_size=10g inactive=60m use_temp_path=off; proxy_cache_path /path/to/hdd2 levels=1:2 keys_zone=my_cache_hdd2:10m max_size=10g inactive=60m use_temp_path=off; split_clients $request_uri $my_cache { 50% “my_cache_hdd1”; 50% “my_cache_hdd2”; } server { # ... location / { proxy_cache $my_cache; proxy_pass http://my_upstream; } } |
這兩個 proxy_cache_path 指令在兩個不同的硬盤驅動器上定義了兩個緩存（my_cache_hdd1 和 my_cache_hdd2）。
split_clients 配置塊指定從一半的請求（結果50%）被緩存在 my_cache_hdd1 與另一半中 my_cache_hdd2。基于 $request_uri 變量的哈希（請求URI）確定每個請求使用哪個緩存，結果是對給定URI的請求總是緩存在同一緩存中。
請注意，此方法不能替代 RAID 硬盤設置。如果存在硬盤驅動器故障，則可能導致系統出現不可預測的行為，包括用戶看到針對故障硬盤驅動器的請求的 500 響應代碼。適當的 RAID 硬盤設置可以處理硬盤故障。
如何對 Nginx Cache 進行檢測
可以在響應頭中加入 $upstream_cache_status 變量以進行檢測
|
1
|
add_header X-Cache-Status $upstream_cache_status; |
此示例 X-Cache-Status 在響應客戶端時添加 HTTP 標頭。以下是可能的值 $upstream_cache_status：
- MISS - 在緩存中找不到響應，因此從原始服務器獲取響應。然后緩存響應。
- BYPASS - 響應是從原始服務器獲取的，而不是從緩存中提供的，因為請求與 proxy_cache_bypass 指令匹配
- EXPIRED - 緩存中的條目已過期。響應包含來自原始服務器的新內容。
- STALE- 內容過時，因為源服務器未正確響應但 proxy_cache_use_stale 已配置。
- UPDATING- 內容過時，因為條目當前正在更新以響應先前的請求，并且 proxy_cache_use_stale updating 已配置。
- REVALIDATED- proxy_cache_revalidate 指令已啟用，Nginx 驗證當前緩存的內容是否仍然有效通過（If-Modified-Since或If-None-Match）。
- HIT - 響應直接來自有效的緩存
Nginx 如何確定是否要緩存響應
默認情況下，Nginx 尊重 Cache-Control 源服務器的標頭。它不緩存響應 Cache-Control 設置為 Private，No-Cache 或 No-Store 或 Set-Cookie 在響應頭。Nginx 只緩存 GET 和 HEAD 客戶端請求。您可以按照以下答案中的說明覆蓋這些默認值。
如果 proxy_buffering 設置為 off，Nginx 不會緩存響應。on 默認的。
Nginx 是否可以忽略 Cache-Control
使用 proxy_ignore_headers 指令可以忽略 Cache-Control
|
1
2
3
4
5
6
|
location /images/ { proxy_cache my_cache; proxy_ignore_headers Cache-Control; proxy_cache_valid any 30m; # ... } |
Nginx 忽略 /images/ Cache-Control 下所有內容的標題。該指令強制緩存數據到期，如果忽略標頭則需要。Nginx 不會緩存沒有過期的文件。
Nginx 是否可以忽略 Set-Cookie
使用 proxy_ignore_headers 指令即可。
Nginx 如何緩存 POST 請求
使用 proxy_cache_methods 指令：
|
1
|
proxy_cache_methods GET HEAD POST; |
此示例啟用了POST請求的緩存。
Nginx 如何緩存動態內容
只要 Cache-Control 標頭允許。即使在很短的時間內緩存動態內容也可以減少原始服務器和數據庫的負載，從而縮短第一個字節的時間，因為不必為每個請求重新生成頁面。
如何不使用 Nginx 緩存
proxy_cache_bypass 指令
|
1
2
3
4
|
location / { proxy_cache_bypass $cookie_nocache $arg_nocache; # ... } |
該指令定義了 Nginx 立即從源服務器請求內容的請求類型，而不是首先嘗試在緩存中找到它。這有時被稱為通過緩存 “打孔”。
Nginx 使用什么緩存密鑰
Nginx 生成的密鑰的默認形式類似于以下 Nginx 變量的 MD5 哈希：$scheme$proxy_host$request_uri; 使用的實際算法稍微復雜一些。
|
1
2
3
4
5
6
7
8
9
10
11
|
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; } } |
對于此示例配置，緩存密鑰 http://www.example.org/my_image.jpg 計算為 md5(“http://my_upstream:80/my_image.jpg”)。
請注意，proxy_host 變量用于散列值而不是實際主機名（www.example.com）。proxy_host 定義為 proxy_pass 指令中指定的代理服務器的名稱和端口。
要更改用作密鑰基礎的變量，請使用該 proxy_cache_key 指令。
使用 Cookie 作為我的緩存密鑰的一部分
緩存鍵可以配置為任意值，例如：
|
1
|
proxy_cache_key $proxy_host$request_uri$cookie_jessionid; |
此示例將 JSESSIONID cookie 的值合并到緩存鍵中。具有相同 URI 但 JSESSIONID 值不同的項目將作為唯一項目單獨緩存。
Nginx 使用 ETag 標頭
在 Nginx 1.7.3 及更高版本中，ETag 標頭完全支持 If-None-Match。
Nginx 如何處理字節范圍請求
如果文件在高速緩存中是最新的，則 Nginx 遵循字節范圍請求并僅向項目客戶端提供項目的指定字節。如果文件未緩存，或者文件過時，Nginx 會從原始服務器下載整個文件。
如果請求是針對單個字節范圍的，則 Nginx 會在下載流中遇到該范圍后立即將該范圍發送到客戶端。如果請求在同一文件中指定了多個字節范圍，則 Nginx 會在下載完成時將整個文件傳送到客戶端。
下載完成后，Nginx 會將整個資源移動到緩存中，以便從緩存中立即滿足所有未來的字節范圍請求，無論是單個范圍還是多個范圍。
請注意，upstream 服務器必須支持 Nginx 的字節范圍請求，以支持對該 upstream 服務器的字節范圍請求。
Nginx 如何處理 Pragma 標頭
在 Pragma:no-cache 報頭由客戶加入到繞過所有中間緩存，直接進入到源服務器的請求的內容。Pragma 默認情況下，Nginx 不支持標頭，但您可以使用以下 proxy_cache_bypass 指令配置該功能：
|
1
2
3
4
5
|
location /images/ { proxy_cache my_cache; proxy_cache_bypass $http_pragma; # ... } |
Nginx 是否支持標頭 stale-while-revalidate 和 stale-if-error 以及擴展的 Cache-Control
Nginx 1.11.10 及更高版本中支持。這些擴展做了什么：
如果當前正在更新 stale-while-revalidate，Cache-Control HTTP 標頭的擴展允許使用陳舊的緩存響應。HTTP 標頭的 stale-if-error 擴展 Cache-Control 允許在發生錯誤時使用陳舊的緩存響應。這些頭具有比較低優先級， proxy_cache_use_stale 指令如上所述。
Nginx 是否支持 Vary 標頭
Nginx 1.7.7 以及更高版本中是支持 Vary 標頭的 。
結論
至此，您應該很好地理解 Nginx 代理緩存的工作原理以及如何正確配置 Nginx 代理緩存。如果您有任何問題或反饋，請隨時發表評論。
以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持服務器之家。
原文鏈接：https://blog.csdn.net/easylife206/article/details/101443151
