缓存策略查询的数据

Question

我目前在建库的项目，该项目将成为DB密集的过程（性能测试已经进行了，并且需要高速缓存因此为什么我问）

的我现在设置的方式是每个对象都单独缓存，如果我想为它们查询对象，我将查询传递给数据库并返回所需的id。 （对于一些简单的查询，我已经缓存并管理了ID）

然后我用这些id命中缓存并将它们拉出来，任何丢失的对象都绑定到“where in”语句并触发到数据库;此时我使用缺少的ID重新填充缓存。

查询他们自己最有可能是关于分页/排序数据。

这是一个合适的策略？或者也许有更好的技术可用？

Answer 1

这是一个合理的方法，我已经走过这条路线，最好使用它来进行简单的缓存。

但是，当您更新或写入数据库时​​，您将遇到一些有趣的问题，您应该仔细处理这些情况。

例如，如果用户更新数据库中的记录，则缓存数据将会过时。在这种情况下，您将需要同时更新内存缓存或清除缓存，以便在下一个获取查询时刷新缓存。

事情也可能很麻烦，如果你例如用户更新了客户的电子邮件地址，它是在一个单独的表，但通过外键关联。

除了数据库缓存之外，您还应该考虑输出缓存。例如，如果您有一张显示上个月销售数据的表格，这种方式非常有效。该表可以存储在另一个文件中，该文件包含在希望显示该表的一堆其他页面中。现在，如果您缓存与销售数据表中的文件，当他们请求此文件的其它页面，缓存引擎可以直接从磁盘和业务逻辑层甚至不被打到它牵回家。这一直不适用，但对自定义控件非常有用。工作模式

单位

它还有助于了解Unit of Work模式。

当你进出的 数据库中提取数据时，它保持 跟踪的你已经改变了什么是重要的; 否则，该数据将不被写入 回数据库。同样你 必须插入创建 新对象，并删除您删除的任何对象。

你可以用每个 改变你的对象模型更改数据库，但这 会导致很多非常小的 数据库调用，它最终被 很慢的。此外，它需要您 有一个交易打开 整个交互，这是 不切实际，如果您有一个业务 交易跨越多个 请求。如果您需要跟踪您已阅读的 对象，则情况更糟糕，因此您可以避免 不一致的读取。工作

一个单元会跟踪你的业务 交易可能影响 数据库中做 一切。完成后，它会将 的结果作为 的结果来计算出 需要执行的所有操作。

Answer 2

我不建议自定义缓存策略。缓存很难。根据您选择的平台，您可能需要选择第三方缓存库/工具。

Answer 3

如果您使用SQLServer，则可以使用SqlCacheDependency，在数据库中的数据表发生更改时，缓存将自动重新填充。 这是SqlCacheDependency的链接

此链接包含类似的cache dependency solution。 （这是一个文件，而不是一个数据库，你将需要做出一些改变按照MSDN的链接上时对数据库缓存依赖性）

希望这有助于:)