我已經繼承了一個系統，其中來自SQL RDBMS的不太可能更改的數據緩存在Web服務器上。服務器場中的應用程序緩存是否值得複雜？
這是個好主意嗎？我理解它的邏輯 - 我不需要需要查詢數據庫中的每個請求數據，因爲它不會更改，所以只需將其保存在內存中並保存數據庫調用。但是，我不禁想到這並不能給我任何東西。 SQL是基本的。例如：
SELECT StatusId, StatusName FROM Status WHERE Active = 1
這給我少於10條記錄。我的數據庫與我的Web服務器位於同一個數據中心。現代數據庫是設計的來存儲和調用數據。我的應用程序緩存真的比數據庫調用更有效嗎？
問題出在我有服務器場時，必須想出一種方法來保持服務器之間的高速緩存同步。也許我低估了數據庫調用的成本。保持數據在內存中的性能優勢是否值得保持每個服務器的高速緩存在數據更改時保持同步的複雜性？
還有其他因素可能會發揮作用，例如使用EF可以爲簡單的數據檢索添加相當多的額外處理。請求數量，而不僅僅是數據量可能是一個因素。
未來的設計可能會影響您的決定 - 也許高速緩存會移到其他地方並且不再位於同一位置。
沒有正確的答案給你的問題。在你的情況下，也許沒有優勢。雖然使用緩存的而不是已經有缺點 - 您必須更改現有的代碼。
緩存的好處與您需要緩存項目的次數和獲取緩存項目的成本有關。如果您每次都必須運行查詢，那麼您的狀態表即使只有10行，也可能「昂貴」：建立連接（如果需要），執行查詢，通過網絡傳遞數據等。如果足夠頻繁地使用，好處可能會增加並且很重要。比如說，你需要檢查一次1000次或每個網站請求的狀態，你已經保存了1000次查詢，你的數據庫可以做更有用的事情，而你的網絡沒有加載喋喋不休。對於您的Web服務器，從緩存中檢索項目的成本通常很小（除非您緩存數以萬計或數十萬項內容）。所以從緩存中取出東西幾乎每次都要比查詢數據庫快。如果你的數據庫是你的系統的瓶頸（這是很多系統的情況），那麼緩存肯定是有用的。
但是底線是，如果沒有運行基準測試或瞭解您如何使用數據的細節，很難說是或否。我只強調了一些要考慮的事情。
至少，它可以避免從池中借用連接，讓連接用於真正需要數據庫的事情。這可以減少高負載情況下的連接池延遲。但我們都知道緩存是一個棘手的問題，所以你的問題確實很有意義。 –