ASP.NET 数据缓存设计

Question

我的 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 次]）并返回每种模式的缓存项？

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

Answer 1

值得深思。

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

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

Answer 2

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

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

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

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

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

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

优点和缺点

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