單個vs多個MemoryCache實例

Question

默認情況下，MemoryCache帶有默認緩存，並且可以創建額外的命名緩存。

看起來好像在不同實例中隔離不同進程的結果緩存可能有好處例如，對索引的查詢結果可以緩存在「IndexQueryResult」緩存中，並在「DatabaseQueryResult 「緩存。這是相當人爲的，但解釋了原則。

一個緩存導致驅逐的內存壓力是否會影響其他緩存呢？與其管理方式相比，.Net管理多個緩存的方式有什麼不同嗎？

考慮到多個緩存的想法，我是否浪費了自己的時間，或者是否真的有這樣的價值？

Answer 1

我不能說出前幾個問題，我很想聽到答案。不過，我可以說，我們迄今爲止在我們的產品中使用了多個緩存，並獲得了很好的體驗。這裏的好處我看到：

• 減少鍵衝突的機會：而不是想出某種方案，以確保沒有兩個單獨的值結束了同一個密鑰，我們可以簡單地創建緩存這是特定於特定存儲庫類型的，並且知道只要該存儲庫類使用其對象唯一的鍵，我們就不會發生衝突。
• 緩存清除效果更好精確性「擁有」特定緩存實例的存儲庫類型可以訂閱系統範圍事件總線上的某些事件類型，以便知道緩存的某些部分何時需要清除。如果我們幸運的話，它可以根據已發佈事件的參數來確定條目的關鍵字以純粹清除。但是，通常情況並非如此，我們必須清除整個緩存或遍歷所有緩存的值，以確定哪些內容受到已發佈事件的影響。如果我們在系統中爲所有數據類型使用單個緩存實例，那麼我們最終會爬過很多不相關的條目。通過使用單獨的緩存，我們可以將搜索範圍限制爲該特定存儲庫負責填充的值。

關於第二點：我們還構建了一個UI來公開系統中的所有緩存實例，並允許我們通過單擊按鈕來清除其中的任何緩存實例。當我們需要直接對數據庫進行更改時，這很方便，並且需要系統在不必重新啓動服務器的情況下接收這些更改。同樣，如果我們只使用一個緩存，我們就不會那麼精確：我們必須在系統範圍內清除所有緩存值，而不僅僅是與我們修改的數據類型相關的值。