ASP.NET数据缓存设计

Question

我在我的BLL中有方法与数据库交互并根据定义的条件检索数据。
返回的数据是常见问题解答对象的集合，其定义如下：
FAQID， FAQContent， AnswerContent
我想缓存返回的数据，以尽量减少数据库交互。现在
，根据用户选择的选项，我不得不返回的以下两种：

• 勾住ShowAll：的所有数据。
• ShowAnsweredOnly： faqList.Where（！Answercontent = NULL）
• ShowUnansweredOnly： faqList.Where（！AnswerContent = NULL）

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

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

Answer 1

深思熟虑。

• 你缓存了多少条记录，表有多大？
• 可以为缓存保留多少中间层资源？
• 每种类型的数据有多少？
  • 客户端过滤有多快？
• 数据多久改变一次？
  • 它由相同的应用程序实例更改多久？
  • 其他应用程序或服务器端作业的更改频率如何？
• 什么是您的缓存失效策略？
• 如果你返回陈旧的数据会发生什么？
• 你可以/应该利用主动缓存失效，如SqlDependency或LinqToCache？

如果数据集很大，那么在客户端进行过滤将会很慢，并且您需要缓存两个单独的结果（如果ALL是另外两个的结合，则不需要第三个结果）。如果数据经常变化，那么高速缓存将频繁地返回过时的项目，而不是主动缓存失效。如果您控制所有更新路径并且只有一个中间层实例应用程序，但在中间层中可实现主动缓存失效，但如果这些前提条件之一未得到满足，则会变得非常困难。

Answer 2

它基本上取决于数据是多么易变，有多少数据以及访问的频率。

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

这并不是全部坏 - 如果差异不是太大，那么你可能会确定cachnig很多。

需要考虑的另一点是数据是如何相关的。如果FAQ项目在已回答和未回答之间切换，那么将基础数据缓存为一个是合理的 - 否则将项目拆分到您想要的位置。

另外，在内存中的数据工作，并把数据库作为一个附加...

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

优点和缺点

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