2011-04-22 275 views
3

在分佈式緩存場景中,通常建議使用還是避免存儲在緩存中的單片對象?最佳實踐緩存:單片緩存數據與細粒度緩存數據

我正在使用EAV架構支持的服務,因此我們將緩存放在適當位置以最大限度地減少從數據庫中檢索所有主要記錄和相應屬性集合時EAV施加的感知性能不足。我們將在服務啓動時啓動緩存。

我們沒有特別頻繁地調用所有產品 - 客戶端在首次使用對象映射填充本地緩存後調用差異。爲了執行該差異,分佈式緩存將需要反映對數據庫中各個記錄的更改,這些記錄是在任意基礎上執行的,並且需要根據客戶端要求的差異來處理更改。

首先想到的是使用列表或字典來存儲分佈式緩存中的記錄 - 獲取整個集合,在本地內存中操作或搜索它,將整個集合放回到緩存中。後來的想法導致了用單獨的記錄填充緩存的想法,每個記錄都以一種方式使它們從緩存中可單獨檢索/可更新。這導致想知道哪些方法在更新所有數據時會更高效。

我們使用的是Windows Server AppFabric,因此我們可以使用BulkGet操作。但我不相信有批量更新的概念。

關於分佈式緩存對象大小是否存在普遍的想法?如果我們對所有項目有更多的請求,我會擔心網絡帶寬,但至少現在對所有項目的需求應該相當小。

是的,我們將測試和分析每種方法,但我想知道是否有任何超出當前思維範圍的內容在此考慮。

+0

在最近的.Net Rocks播客中,有一些關於這個話題的討論,其中客人是Udi Dahan。播客是關於CQRS的,他們討論了模式的一個關鍵優勢是如何實現更好的緩存。可能會給你一些想法... – 2011-04-22 00:29:17

回答

3

所以在我們的場景中,似乎單片緩存對象將成爲首選。在數據中心使用大型管道時,幾乎沒有可察覺的時間讓大約30 MB的序列化產品數據穿過導線。使用Dictionary<TKey, TValue>,我們能夠快速找到收藏中的產品,以便返回或更新單個項目。

由於數以千計的單個實體,都遠低於1 MB,在緩存中,批量操作只需要很長時間。網絡操作中的延遲太多。

編輯:我們現在正在考慮維護實體和單體集合的實體,因爲對於整體來說,檢索單個實體似乎是一個相當昂貴的生產數據集過程。