使用 Ruby on Rails 重新生成静态缓存的最佳方式是什么？答案

【问题标题】：What's the most optimal way to regenerate static cache with Ruby on Rails?使用 Ruby on Rails 重新生成静态缓存的最佳方式是什么？
【发布时间】：2012-09-22 19:51:47
【问题描述】：

我有一个相当慢的控制器动作，它会在这里和那里做一些报告。我只需要每隔几天刷新一次数据，所以静态缓存结果是不费吹灰之力的。

问题是，该操作需要几分钟才能完成，我不确定使旧数据过期并用新数据替换它们的最佳方法是什么。

现在只有通用过期/请求的问题是几分钟（操作运行的时间）这些数据不可用。

是否有任何合理的方法可以仅使用 Rails 中的静态缓存机制来克服这一差距？还是我应该以不同的方式重建整个事物？

【问题讨论】：

标签： ruby-on-rails caching

【解决方案1】：

Rails 有一种内置方式，可以在旧缓存过期时使用更长的时间，而新的缓存值正在重新生成。这是与:expires_in 结合使用的:race_condition_ttl 设置，如Rails Guides on Caching 中所述。

使用 Rails 片段缓存，语法应该是：

<% cache 'my_awesome_cache_key', :expires_in => 12.hours.to_i, :race_condition_ttl => 12.hours.to_i %>
  # This block will be cached
<% end %>

结果：

1) 第一次请求：缓存为空，因此将执行块并将结果写入缓存
2) 未来 24 小时内的所有请求：将直接从缓存中提供服务（新鲜）
3a) 24 小时后但在宽限期内的第一个请求将从当时稍微陈旧的缓存中提供服务；缓存将在后台重新生成：块在完成后立即执行并写入缓存
3b) 24 小时后但超出宽限期的第一个请求将按 1) 处理，即不直接提供但会执行块，将写入缓存并提供请求。

race_condition_ttl 的引入是为了防止多个进程同时重新生成缓存，这将导致所有进程在高度请求的资源上一次从数据库中读取数据等，但我认为它应该适用于您的情况.

如何选择:expires_in 和:race_condition_ttl 的时间是你的选择，我建议这样计算：expires_in + race_condition = expires_in_that_you_would_usually_set。这样，缓存会更频繁地重新生成，但也更新鲜，特别是如果动作/视图不经常呈现。

【讨论】：

如果内容手动过期，您是否知道这会如何表现，即：expire_page :action => ...？页面是否仍会从缓存中提供（直到达到 race_condition_ttl）？
手动过期和基于时间的过期应该没有区别。只要缓存键保持不变并且请求在race_condition_ttl 内，我认为它应该可以按预期工作。
.to_i 方法在 12.hours 上不是必需的，因为它已经返回了 Fixnum。