缓存数据与缓存输出

Question

我在web应用程序中缓存方面的经验不多，但我正在尝试在这个领域培养自己，并在ASP.NET MVC中尝试各种技术和方法。

我在网上看到的大多数教程和文章都提到了输出缓存([OutputCache(VaryByParam="...")])、各种甜甜圈缓存方法等。

在我看到的在线文章中，只有一小部分讨论在数据/业务层之上缓存查询的方法，这些方法可以借助System.Runtime.Caching或其他键值存储来实现。

我一直认为web应用程序中常见的瓶颈是昂贵的或经常执行的查询，而不是将其呈现为HTML的部分。至少从我自己在项目上的经验来看，我一直都是这样的。

主观上，与数据/业务层的缓存相比，输出缓存也是一种“更脏”的方法。为什么它被提升这么多？仅仅是因为它更容易实现吗？还是我漏掉了一些要点？

的输出缓存实际上比数据/业务层的缓存更有好处吗？我应该把重点放在哪种web应用程序上？如何在这两者之间找到平衡？

缓存技术通常被认为是web开发中的一个困难主题，如果能更深入地了解输出缓存与数据缓存方法的不同之处、优势和弱点，那就太好了。

Answer 1

在需要在显示数据之前执行复杂查询或计算或花费大量时间(将数据转换为HTML)的应用程序中，输出缓存有很大的好处。这不仅涉及执行复杂的查询，还涉及对数据执行计算。对于大容量的网站，即使是为数据库中的产品列表提供HTML的简单操作也会占用大量的资源。

通过使用输出缓存，不需要查询数据库、返回结果、解析结果并将其转换为要显示的HTML。请求可以访问hit服务器，甚至不必通过应用程序服务器。

通常，输出缓存要容易得多:您可以查看应用程序生成的输出，并确定这个输出不需要在每个请求中动态生成，所以您可以缓存它。

应用程序数据缓存要复杂得多，因为您必须在非常细粒度的级别上决定是否要缓存某些内容。它还会对代码库产生很大影响，因为缓存代码与应用程序代码混在一起，您必须担心缓存失效之类的事情，而输出缓存位于应用程序的“顶部”，甚至不必考虑到这种缓存。

很难说什么时候要使用输出缓存，什么时候要使用应用程序数据缓存。两者之间的界线在某一点上也变得模糊。如果您缓存昂贵的计算结果，但是将其与来自实时查询的数据结合起来，因为您需要该部分的实时数据，那么该计算“应用程序数据”缓存或“输出”缓存的结果是缓存的吗？