ASP.NET 数据缓存设计

Posted 2023-03-30

【中文标题】ASP.NET 数据缓存设计

【英文标题】：ASP.NET data caching design

【发布时间】：2011-02-07 04:17:13

【问题描述】：

我的 BLL 中有与数据库交互并根据定义的条件检索数据的方法。 返回的数据是一个FAQ对象的集合，定义如下：FAQID, FAQContent, AnswerContent 我想缓存返回的数据以最小化数据库交互。 现在，根据用户选择的选项，我必须返回以下任一选项：

ShowAll：

所有数据。

ShowAnsweredOnly：

faqList.Where(Answercontent != null)

ShowUnansweredOnly：

faqList.Where(AnswerContent != null)

我的问题： 我是否应该仅缓存从 DB 返回的所有数据（例如 FAQ_ALL）并从缓存中过滤其他 faqList 模式（= 只与 DB 交互一次并从缓存项中过滤其他两种模式的数据） ?或者我应该有 3 个缓存项：FAQ_ALL、FAQ_ANSWERED 和 FAQ_UNANSWERED（=每种模式与数据库交互 [3 次]）并返回每种模式的缓存项？

如果有人告诉我每种方法的优缺点，我会很高兴。

【参考方案1】：

值得深思。

您缓存了多少条记录，表有多大？ 可以为缓存保留多少中间层资源？ 每种类型的数据有多少？ 客户端过滤的速度有多快？ 数据多久更改一次？ 同一个应用程序实例多久更改一次？ 其他应用程序或服务器端作业多久更改一次？ 您的缓存失效策略是什么？ 如果您返回过时的数据会怎样？ 您能否/是否应该利用活动缓存失效，例如 SqlDependency 或 LinqToCache？

如果数据集很大，那么在客户端进行过滤会很慢，您需要缓存两个单独的结果（如果 ALL 是其他两个结果的并集，则不需要第三个）。如果数据经常更改，那么缓存将频繁返回陈旧的项目，而没有主动缓存失效。如果您控制所有更新路径并且只有一个中间层实例应用程序，则可以在中间层实现活动缓存失效，但如果不满足其中一个先决条件，则变得非常困难。

【参考方案2】：

这基本上取决于数据的易失性、数据量以及访问频率。

例如，如果回答的数据没有太大变化，那么您可以安全地缓存一段时间；但是，如果未答复的数据发生了很大变化（并且更频繁），那么您的缓存需求可能会有所不同。如果是这种情况，将其缓存为一个数据集不太可能是最佳选择。

不过，这也不是很糟糕——如果差异不是太大，那么你可能没问题。

要考虑的另一点是数据之间的关系。如果常见问题解答项目在已回答和未回答之间切换，那么将基本数据缓存为一个是有意义的 - 否则这些项目将被拆分到您想要的位置。

或者，使用内存中的数据并将数据库视为附加组件...

我是什么意思？好吧，通常用户会点击“保存”，这将调用保存到数据库的代码；当下一个用户出现时，他们将调用从数据库中获取数据的调用。在设计方面，数据库是一等公民，在其他人看到之前，一切都必须经过它。另一种方法是基于内存中（由 BLL）保存然后保存的数据进行设计（也许是异步的）到数据库。这消除了作为瓶颈的数据库，但给您带来了一系列新问题 - 例如，如果数据库连接断开或服务器因仅在内存中的数据而死机，会发生什么？

优点和缺点

在一次调用中获取所有数据可能会更快（通过更少的调用）。 如果相关数据一次获取所有数据是有意义的。 粒度：相关且具有相似“可缓存性”的数据可以一起缓存，否则您可能希望将它们保存在单独的缓存分区中。