缓存大量对象的方法（ASP.NET缓存vs静态对象和单独缓存对象vs字典）

Question

我正在编写一个控件，显示页面上的项目列表。数据库包含（可说）与1000页（可说）相关（多对多）的50,000个项目。

而不是编写一个存储过程来从数据库返回给定页面的一组完整项目（即所有列，为了水合项目对象列表），我正在考虑执行以下操作来呈现一个清单：

• 在应用程序启动时，缓存所有上市项目
• 获得SP为项目
• 通过按键&从缓存中检索匹配对象的列表循环只返回键值

初步测试表明，这比从每个页面请求的数据库中提供列表执行得更快。由于每个页面请求只查找现有对象，而不是每个请求都创建一个私有列表（当流量很高，请求大页面时内存消耗非常高），它似乎也会减少整体内存消耗。

所以现在我正在与其他开发人员讨论如何实现缓存。我们已经想出了几个选项，而这正是我将不胜感激您的意见：

• 使用ASP.NET HttpContext.Current.Cache
• 使用静态/单身对象

在每个这些也有一个选择是否：每个项目对象

1. 缓存单独
2. 构建字典（或类似的立st）包含所有项目对象，然后缓存字典

读取性能是主要关心的问题。维护是次要的问题 - 我们将防御地编写我们的GetItems方法来检查每个项目是否在缓存中，如果没有，从数据库中检索它并将其插入到缓存中。

我知道有没有正确的答案......有利弊&缺点的一切。我只是想看看人们是否有可以分享上述任何一个方面的缺陷，或者如果任何方法突出表现为迄今为止表现最好的，或者特别难以合并新数据。

谢谢

Answer 1

我会去缓存的方法。其中一些原因如下：

1. 您可以控制在释放内存之前对象将保存在缓存中的时间。在重负载的情况下，这可能会让服务器响应得更好。
2. 如果值得付出努力，我甚至可能会走得更远，并使用某种分布式缓存，以便在应用程序池回收中幸存下来。想到了Memcache和NCache。

我不喜欢Singleton方法。在我看来，当你可以完美地使用Cache时，你会重新发明轮子。并发性将成为缓存问题，您将失去使用分布式缓存的灵活性。无论采取什么方法，我都会创建一个包装类来存储和从缓存中检索对象，这将允许您在将来无缝地从传统缓存更改为分布式缓存。