我正在阅读这篇文章：
http://37signals.com/svn/posts/3113-how-key-based-cache-expiration-works
我没有使用 Rails，所以我不太了解他们的示例。
#3 中说：
当key改变时，你只需将新内容写入这个新的 钥匙。因此，如果您更新待办事项，则密钥将从 todos/5-20110218104500 到 todos/5-20110218105545，因此新的 内容是根据更新的对象编写的。
视图如何知道读取新的 todos/5-20110218105545 而不是旧的？
【问题讨论】：
标签： caching
一开始我也对此感到困惑——如果您必须从数据库中读取以查看缓存是否有效，这如何节省访问数据库的时间？但是，请参阅 2 月 12 日 Jesse 的 cmets（1、2）：
你怎么知道缓存键是什么？您必须从数据库中获取它才能知道 mtime 对吗？如果您已经从数据库中提取记录，我希望这是最大的成功，不是吗？
我错过了什么吗？
然后
请删除我的脑残评论。我刚刚意识到为什么这无关紧要：缓存是级联的，所以是的，全深度再生会导致数据库命中。下一次缓存命中将引发对顶级对象的一次数据库查询——所有后代对象都不会被查询，因为父对象的缓存包括子对象的缓存版本（因此，不需要查询）。
下面还有Paul Leader's comment 2：
宾果游戏。这就是为什么它工作得很好。如果你做对了，它不仅消除了生成 HTML 的需要，而且消除了访问数据库的任何需要。有了这个缓存系统，我们的 data-vis 应用程序几乎是即时的，它实际上是可用的，而且代码也更好。
因此，鉴于 DHH 在文章第 5 步中列出的模型和他在第 6 步中列出的视图，并且假设您已正确设置与 touch 更新时父对象的关系，并且您的部分以parent.children 甚至child.children 在嵌套部分中访问您的子数据，那么这个缓存系统应该有净收益，因为只要父缓存键仍然有效，那么parent.children 查找将永远不会发生并且将也可以从缓存等中提取。
但是，如果您的部分引用来自控制器的大量实例变量，则此方法可能毫无意义，因为当 Rails 在视图模板中看到对 cache 的调用时，这些查询已经执行了。在这种情况下，您可能最好使用其他缓存模式。
或者至少这是我对其工作原理的理解。高温
【讨论】：