刪除 NGINX 快取會導致關鍵的 Unlink 錯誤進入錯誤日誌

已發佈: 2025年2月15日上午11:25:02 [UTC]

本文介紹如何從 NGINX 的快取中刪除項目，而不會讓日誌檔案充斥著錯誤訊息。雖然一般不建議這種方法，但在某些特殊情況下可能會有用。

該頁面是由英語機器翻譯而來的，以便盡可能多的人可以訪問。不幸的是，機器翻譯還不是一項完善的技術，因此可能會出現錯誤。如果您願意，可以在這裡查看原始英文版本：

Deleting NGINX Cache Puts Critical Unlink Errors in Error Log

本文中的資訊是基於在 Ubuntu Server 14.04 x64 上執行的 NGINX 1.4.6 上的 FastCGI 快取。對於其他版本來說它可能有效，也可能無效。

（2025 年更新：從我寫原始帖子到現在，很多事情都發生了變化。伺服器速度更快，價格更便宜，因此我實際上不推薦本文中描述的方法，即我嘗試微觀管理緩存過期，只是為了節省幾代額外的動態內容。我會將內容留在這裡以供將來參考，以防有人出於某種原因確實需要它。

將幾個網站從 Apache 遷移到 NGINX 之後，我開始非常喜歡它的內建快取功能，它在大多數情況下運作得非常好，不需要我進行太多幹預。

但是，對於其中一個網站，我確實需要自己清除快取（完全清除和刪除單個條目）的能力。 NGINX 的免費社群版僅支援基於時間的快取過期（即，您可以將其設定為檢查一小時、一天等後是否發生了變化）。但是如果沒有可靠的方法提前確定某種資源何時會改變該怎麼辦？例如，我不知道要過一個小時、一天還是一年我才能回來編輯這篇文章的內容——如果快取一天就可以了，為什麼只快取一個小時？

這時就需要手動清除快取的能力（或讓你的 Web 應用程式通知 NGINX 應該清除某些內容）。 NGINX 背後的人們清楚地意識到了這一點的必要性，因為其產品的付費版本支持該功能 - 但儘管他們有權以任何他們想要的方式設置許可，但當此功能是我真正需要的唯一付費功能時，價格對我來說有點高。

幸運的是，事實證明您可以自己從快取目錄中刪除文件，NGINX 將會發現這一點並從您的後端順利獲取新副本。但是，如果您在不調整配置的情況下執行此操作，一段時間後您可能會在錯誤日誌中看到一大堆類似於此的訊息：

2015/03/04 17:35:24 [crit] 16665#0: unlink() \"/path/to/nginx/cache/9/a0/53eb903773998c16dcc570e6daebda09\" failed (2: No such file or directory)

看起來這些錯誤發生在 NGINX 本身試圖在fastcgi_cache_path指令的inactive參數指定的時間之後刪除快取條目時。預設值僅為 10 分鐘，但您可以將其設定為您想要的任何值。如果您將其設定為 10 年，則您可能不太可能在此期間沒有重新啟動伺服器，因此記憶體中的關鍵索引會在此期間清除。如果你這樣做，你是否需要確保自己清除緩存，NGINX 將不再為你執行此操作。

我發現一個很奇怪的事實：由於快取條目不存在而無法刪除，這被視為嚴重錯誤。事實上，它的嚴重性分類如此之高意味著，僅透過忽略低於某個閾值的日誌條目是不可能擺脫它的。一旦從後端獲取新的副本，該條目就會再次存在，所以在我看來，這最多應該是一個警告。

現在，如果由於權限問題或第三方問題而無法刪除快取條目，那將是一個嚴重錯誤，因為它可能導致 NGINX 在快取過期之後很長時間繼續提供快取內容，但清理過程似乎並沒有做出這種區分。