快取應用中的錯誤模式

做得很糟糕的快取會產生不良影響。盡量不要快取資料；如果你真的需要，確保你的做法正確。

在電腦科學中只有兩件艱難的事情：快取失效和為事物命名。

– phil karlton

為了確保我們在說同一件事情，當我說「快取」，我指的是一種加快應用的實踐，主要方式是通過記住之前的應答並使用它們對後續同樣的請求進行應答，從而掩蓋緩慢的依賴。

正如phil karlton在他著名的sound byte上簡單提到的，快取是乙個很微妙的問題。它包含了我在過去幾年遇到的一系列常見的錯誤，從而可能導致不必要的混亂延遲。

以下是我所看到的一些錯誤，以及我們應該如何應對。

當你了解到你的依賴太慢這個事實的時候，這些依賴是難以使用的，因此你在執行時甚至不會嘗試他們。在你的應用啟動時預先填充快取而不是查詢你依賴的服務，就是在承認你的依賴不適用於你的目標。如果這是乙個第三方服務，那你可能沒什麼辦法，但這個技術經常可以被用於避免一定要讓你的服務與目標匹配。

從那時起，他們服務太慢的事實被隱藏了。沒有理由去優化或者改進解決方案，因為快取能夠保證第二次請求更快；所以為什麼要擔心呢，對吧？

在solid裡面的s是什麼意思？單一職責。如果你的快取直接整合到你的服務層，並且你沒法不用快取執行，你絕對是違反了這條原則。這不是我讚美這條原則的美德的地方。

這是指忙目地將快取應用到所有外部呼叫來保證響應性，而不考慮其影響。更嚴重的是，這種方法會導致開發者和運營者甚至不知道快取在發生，而假定底層的服務的可靠性很高，這不是正確的。

有時候快取的實踐可能會依賴像redis這樣的資料儲存，它們有用於按需清空快取的工具。

其餘的實踐，比如手動分配記憶體快取或甚至一些主流框架提供的快取都不會暴露任何快取管理工具。這導致運營人員只有乙個選擇，即重啟服務來清空記憶體。（更糟糕的是，查詢快取對應的檔案系統的位置，然後手動清空它。）

我看到，一些發布的軟體需要花費比正常來說多幾個小時的時間供組員來一層一層處理快取，將之清空或等待過期，然後處理下一層快取。在這個過程中這個系統是離線的，因為它甚至無法保證內部一致。

對此最自然的反應是想出乙個解決辦法，通常是破壞快取。我們考慮一下這個辦法。為你剛剛部署的特性提供乙個解決方案，想想需要花費的時間、精力和認知負荷，只是為了補償你剛剛花費在快取上的時間、精力和認知負荷。

除錯乙個快取系統同時成為了乙個挑戰，因為全力投入乙個困難的除錯過程會導致遺漏或忘記一些不相關的事情。3個小時的混亂後，你意識到你還沒有測試你做出的特性改變呢。

投資探查工具，找出你的應用程式緩慢的原因，並修復它。減少重複的執行路徑。整理糟糕的查詢執行計畫。正確使用索引。如果你在使用s3或blob儲存你的資料，你可以使用redis建立你自己的索引。redis不僅僅是乙個快取。你可以機智地使用它來獲取很多好處，而不涉及快取帶來的問題。

快取是乙個有用的工具，但它很容易被毫無徵兆地濫用。

不要使用快取，除非不得不使用；尋找你能找到的其他方式。在你使用快取這個鈍刀之前，優化你的應用。

如果你遇到任何快取帶來的基本問題，請告訴我，我可以把問題加到列表中。