查询数据的缓存策略

Question

我目前正在为数据库密集的项目构建存储库（已经执行了性能测试，因此需要缓存，因此我要问）

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

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

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

这是一个合适的策略吗？或者可能有更好的技术？

Answer 1

这是一种合理的方法，我之前已经走过这条路线，最好将它用于简单的缓存。

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

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

例如，如果用户更新客户的电子邮件地址，该地址位于单独的表中但通过外键关联，则事情也会变得棘手。

除了数据库缓存之外，您还应该考虑输出缓存。例如，如果您有一个显示上个月销售数据的表格，则此方法非常有效。该表可以存储在另一个文件中，该文件包含在一堆想要显示该表的其他页面中。现在，如果您使用销售数据表缓存该文件，那些其他页面在请求此文件时，缓存引擎可以直接从磁盘获取它，并且业务逻辑层甚至不会被命中。这不是一直适用，但对自定义控件非常有用。

工作单元格式

了解Unit of Work模式也很有帮助。

  

当您将数据拉入和拉出时   一个数据库，重要的是要保持   跟踪你改变了什么;   否则，将不会写入该数据   回到数据库。同样的你   必须插入您创建的新对象   并删除您删除的任何对象。

     

您可以使用每个更改数据库   更改为您的对象模型，但这   可以导致很多非常小的   数据库调用，最终成为   非常慢。此外，它需要你   让交易开放   整个互动，这是   如果你有生意，这是不切实际的   跨越多个的交易   要求。情况更糟   如果你需要跟踪   你读过的对象，你可以避免   读数不一致。

     

工作单元跟踪   你在商业中所做的一切   可能影响的交易   数据库。当你完成后，它就会成功   完成所有需要完成的事情   由于改变了数据库   你的工作。

Answer 2

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

的链接

此链接包含类似的cache dependency solution。 （它用于文件而不是数据库。您需要根据上面的msdn链接进行一些更改，以便对数据库具有缓存依赖性）

希望这会有所帮助：）

Answer 3

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