我正在开发一个 ASP.NET MVC 项目，并且已经到了要开始考虑缓存策略的地步。我试图让我的框架尽可能开放，以便在缓存中使用。
根据我在 Scott Hanselman 的播客中听到的内容，StackOverflow.com 使用页面输出缓存并将该内容压缩并放入 RAM。听起来这对于用户范围的缓存非常有用，但对于个性化页面之类的内容，您必须为每个用户缓存一个版本，这可能很快就会失控。
因此，对于缓存策略。应该使用哪个，输出缓存、数据缓存还是结合使用？我的第一个想法是两者，但就缓存依赖项而言，它听起来可能会有点复杂。
我们正在大规模（每天 300 万次访问）网站（新闻门户）进行 API 和输出缓存。该站点主要由匿名用户使用，但我们确实有经过身份验证的用户，并且由于站点的一些个性化部分，我们为他们缓存了一个完整的站点，我必须承认我们在内存压力方面绝对没有问题。
因此，我的建议是在 API 缓存中缓存所有可以缓存的内容，这样您的输出缓存重建速度会更快。
当然，请密切注意性能计数器中的缓存比率值。您应该会看到 >95% 的缓存命中数。
另一个需要注意的是缓存失效，如果你有很多相关的内容，这是一个大问题。例如，您缓存音乐内容，而有关一张专辑或歌曲的信息可能会显示并缓存在几百页上。如果那首歌有任何变化，您必须使所有这些页面无效，这可能会出现问题。
归根结底，缓存是 ASP.NET 的最佳特性之一，它做得非常好，您可以信赖它。
小心过度激进的缓存。尽管缓存是一种有助于提高性能的工具，但如果使用不当，它实际上会使性能变得更差。
如果不了解有关您的项目的更多详细信息，我无法回答输出缓存或数据缓存是否更适合您。我可以帮助提供几个示例，说明何时使用一个而不是另一个。
如果您有一个经常在许多不同视图中使用的特定数据集，那么最好使用数据缓存。如果您的数据获取操作相对于您的数据呈现非常常见且成本高昂，您将使用它。如果您有多个使用相同数据的视图，则可以节省数据获取时间。
如果您有一个使用非常特定的数据集的视图，并且该视图的呈现很复杂，并且该视图经常被请求（例如，堆栈溢出的主页），那么您将从输出缓存中受益匪浅。
所以最后，这真的取决于你的需要，小心使用缓存不正确。