如何有效地跟踪缓存密钥，从而使其失效？

Question

在一个普通的应用程序中，可以通过多种方式从数据库中检索到相同的信息。如果所有这些方法都实现了缓存，那么在更新数据库中的条目时，需要使所有这些缓存条目失效。

在更新和选择之间进行一些配对很容易。让我们以第9类中的一个产品123为例，价格为12.50美元。如果按ID选择产品：

select [...] from [Shop].[Product] where [ProductId] = 123

使用键Product<Id:123>缓存它，在更新了由ID标识的产品的价格后，就不难使这个缓存条目失效：

update [Shop].[Product] set [Price] = 14.99 where [ProductId] = 123

当您还必须记住用对应于查询的键MostExpensive<CategoryId:9>使缓存失效时，事情就变得更加困难了：

select max([Price]) from [Shop].[Product] where [CategoryId] = 9

跟踪缓存条目的有效方法是什么？如何在开发或代码评审期间，当一个或另一个数据被更改时，哪些条目必须无效？

Answer 1

MySQL基于基础表使其查询缓存无效。如果查询中使用的表是用任何INSERT、UPDATE或DELETE编辑的，那么任何缓存到该表的查询都将失效。(我知道MySQL不是最佳实践的光辉范例，但在这种情况下，它运行得非常好。)

因此，在您的示例中，如果您曾经更新过商店.产品，您可以使用对它的引用来使所有缓存无效。您将需要第二组元数据，该数据将每个表与相关的缓存条目键相关联，例如[Shop].[Product] => (Product<Id:123>, MostExpensive<CategoryId:9>)。

一个稍微有效的路由是，当那些记录未被更新时，不使那些引用表的主键的键失效。因此，如果使用ProductId 345更新记录，不要使键Product<Id:123>失效。

如果您通过缓存层传递所有查询，快速从每个查询中获取表名并处理所有缓存条目，那么它是可管理的。我觉得可能有一个完全不同的解决方案，更直接，但我现在想不出一个。