Caching 基于密钥的缓存

我正在读这篇文章：

我没有使用rails，所以我不太理解他们的例子

它在#3中写道：

当键更改时，只需将新内容写入此新 钥匙因此，如果更新todo，则密钥将从 todos/5-20110218104500到todos/5-20110218105545，因此 内容是基于更新的对象编写的

---

视图如何知道从新的todos/5-20110218105545而不是旧的todos/5-20110218105545中读取数据？

一开始我也对此感到困惑——如果必须从数据库中读取数据以查看缓存是否有效，这如何节省对数据库的访问？然而，见Jesse 2月12日的评论（，）：

您如何知道缓存密钥是什么？您必须从数据库中获取它才能知道mtime，对吗？如果你已经从数据库中提取了记录，我认为这将是最大的成功，不是吗

我错过什么了吗

然后

请删除我的脑死亡评论。我刚刚意识到为什么这无关紧要：缓存是级联的，所以完全深度的再生会导致DB命中。下一次缓存命中将导致对顶级对象进行一次DB查询所有子对象都不会被查询，因为父对象的缓存包含子对象的缓存版本（因此，无需查询）

以下第2条：

宾果。这就是为什么它工作得很好。如果你做对了，它不仅消除了生成HTML的需要，而且还消除了对数据库的任何需要。有了这个缓存系统，我们的data vis应用程序几乎是即时的，它实际上是可用的，代码也更好

因此，考虑到DHH在本文第5步中列出的模型以及他在第6步中列出的视图，考虑到您已经正确设置了与更新时的父对象的关系，并且考虑到您的分区以父对象的身份访问子数据，甚至是嵌套分区中的子对象，那么这个缓存系统应该有一个净增益，因为只要父缓存密钥仍然有效，那么父缓存的子缓存就永远不会发生，也会从缓存中提取，等等

但是，如果您的部分引用了来自控制器的大量实例变量，则此方法可能毫无意义，因为当Rails在视图模板中看到对

cache

的调用时，这些查询已经执行了。在这种情况下，您最好使用其他缓存模式

或者至少这是我对它工作原理的理解。嗯