使用 MemoryCache 的多个实例

问题描述 投票:0回答:3

我想使用

System.Runtime.Caching
命名空间向我的应用程序添加缓存功能,并且可能希望在多个位置和不同的上下文中使用缓存。 为此,我想使用多个 MemoryCache 实例。

但是,我看到 here 不鼓励使用多个 MemoryCache 实例:

MemoryCache 不是单例,但您应该仅创建几个或可能只有一个 MemoryCache 实例,并且缓存项目的代码应使用这些实例。

多个 MemoryCache 实例将如何影响我的应用程序? 我觉得这很奇怪,因为在我看来,在应用程序中使用多个缓存是一种非常常见的情况。

编辑:更具体地说,我有一个类应该为每个实例保留一个缓存。我应该避免使用

MemoryCache
并寻找不同的缓存解决方案吗?在这种情况下使用
MemoryCache
被认为是不好的吗?如果是,为什么?

c# .net caching .net-4.0 memorycache
3个回答
79
投票

我自己最近也经历过这个。考虑到内存中的缓存将是特定于进程的(不会在网站或本机业务应用程序或多台服务器的多个实例之间共享),除了代码组织原因(这可以在其他方式中实现)之外,拥有多个

MemoryCache
实例实际上没有任何好处。方式)。

内存缓存主要是因为其内存管理功能而打算单独使用。除了性能计数器(确实有一些开销)之外,MemoryCache 还能够在耗尽分配的内存时使项目过期。

如果缓存的当前实例超出了内存设置的限制 通过 CacheMemoryLimit 属性,缓存实现删除 缓存条目。应用程序中的每个缓存实例都可以使用 由 CacheMemoryLimit 属性指定的内存量。

来自 MemoryCache.CacheMemoryLimit 属性

通过仅使用 MemoryCache 的一个实例,它可以在整个应用程序实例中有效地应用这种内存管理。使整个应用程序中最不重要的项目过期。这可确保最大程度地使用内存,而不会超出您的硬件能力。通过限制任何一个 MemoryCache 的范围(例如类的一个实例),它无法再有效地管理应用程序的内存(因为它无法“看到”所有内容)。如果所有这些缓存都“繁忙”,您可能会更难管理内存,并且永远不会那么高效。

这在没有专用服务器的应用程序中尤其敏感。想象一下,您正在共享服务器上运行您的应用程序,其中您只分配了 150mb RAM(常见的廉价 10 美元/月托管),您需要依靠缓存来最大限度地使用它而不超过它。如果超过此内存使用量,您的应用程序池将被回收,并且您的应用程序将丢失内存缓存中的所有内容! (常见的廉价托管实践)同样的情况也适用于在某些共享公司服务器上托管的非 Web 应用程序。同样,您被告知不要占用该计算机上的所有内存并与其他一些业务应用程序和平共存。

内存限制、应用程序池回收、丢失缓存等问题是网络应用程序常见的“致命弱点”。当应用程序最繁忙时,它们会由于超出内存分配而最频繁地重置,丢失所有缓存条目,因此做了最多的工作来重新获取本来应该缓存的内容。这意味着应用程序实际上在最大负载下失去了性能而不是获得了性能。

我知道 MemoryCache 是 System.Web.Caching.Cache 实现的非 Web 特定版本,但这说明了缓存实现背后的逻辑。如果您不独占使用硬件,则相同的逻辑可以应用于非 Web 项目。请记住,如果您的缓存强制计算机开始进行页面文件交换,那么您的缓存将不再比磁盘上的缓存快。你总是希望在某个地方有一个限制,即使这个限制是 2GB 之类的。

就我而言,在阅读完相关内容后,我转而在应用程序中使用一个“公共静态 MemoryCache”,并且我只是通过缓存键来隔离缓存项目。例如,如果您想在每个实例上进行缓存,您可以使用类似“instance-{instanceId}-resourceName-{resourceId}”之类的缓存键。将其视为缓存条目的名称间隔。


6
投票

我也用了几个。一般每种类型一个。

查看

MemoryCache
,我发现它挂钩到
AppDomain
事件并维护性能计数器。我怀疑使用多个(例如 CPU、计数器和内存)会产生一些资源方面的开销,这就是不鼓励这样做的原因。


0
投票

MemoryCache
是对我来说最令人困惑的开箱即用 API 之一。

考虑使用LazyCache之类的东西,它是顶部的一层,可以让事情变得更容易

© www.soinside.com 2019 - 2024. All rights reserved.