“永远”和“从不”是唯一有用的缓存持续时间吗？答案

【问题标题】：Are "forever" and "never" the only useful caching durations?“永远”和“从不”是唯一有用的缓存持续时间吗？
【发布时间】：2014-12-12 05:02:24
【问题描述】：

在 Steve Souders (at around 14:30) 的演示文稿 "Cache is King" 中，暗示实际上只有两个缓存持续时间应该用于您的资源：“永远”和“从不”（我自己的术语） .

“永远”意味着您通过设置非常高的最大年龄（例如一年）有效地使资源永久不可变。如果您想在某个时候修改资源，演示文稿建议，您只需将修改后的资源发布到不同的 URL。（建议部分或全部重命名是必要的，因为 Internet 上有大量配置错误的代理。）
“从不”表示您有效禁用所有形式的缓存，并要求浏览器在每次请求资源时下载资源。

一方面，Google 首席性能工程师给出的任何性能建议都具有重要意义。另一方面，HTTP 缓存可能是出于某种原因（不仅仅是“永远”和“从不”）设计的可变缓存持续时间，并且仅因为资源已被修改而将 URL 更改为资源似乎违背了HTTP。

你应该在实践中使用“永远”和“从不”唯一的缓存持续时间吗？这是否与网络上的其他最佳做法相冲突？

除了典型的“使用浏览器的用户”用例之外，我还想知道这些原则如何应用于 REST/超媒体 API。

【问题讨论】：

我最喜欢的缓存头是Cache-Control: private, max-age=0，可以选择与ETag组合，等于资源哈希或资源版本。在使用 Ajax 或 RESTful API 的情况下，它会产生最佳效果。例如，请参阅the answer。

标签： http caching

【解决方案1】：

许多人不同意将自己限制为您所描述的“永远”或“从不”。

一方面，它忽略了允许缓存并始终重新验证的选项。在这种情况下，如果客户端（或代理）已经缓存了资源，它会发送一个有条件的 HTTP 请求。如果客户端/代理已经缓存了资源的最新版本，那么服务器会发送一个简短的 304 响应而不是整个资源。如果客户端的（代理）副本已过期，则服务器会发送整个资源。

使用此方案，客户端将始终获得资源的最新版本，并且如果资源没有更改，将节省很多带宽。

为了节省更多带宽，可以指示客户端仅在资源超过某个时间段时重新验证。

如果坏代理是个问题，服务器可以指定只有客户端而不是代理可以缓存资源。

我发现this document 非常简洁地描述了您的缓存选项。 This page 更长，但也提供了一些很好的信息。

【讨论】：

如果因为延迟而修改了因为不好。
在避免延迟和浏览器缓存服务陈旧数据之间需要权衡。如果内容很少更改，或者可以提供陈旧的数据，则每月或更长的时间重新验证一次。

【解决方案2】：

如果您知道基础数据在任何时间长度内都是静态的，那么缓存就很有意义。我们有一个 Web 服务，它公开数据库中的数据，该数据库由来自外部源的每晚 ETL 作业填充。我们的 RESTful Web 服务仅在数据库发生变化时才进入数据库。在我们的例子中，我们确切地知道数据何时发生变化，并在 ETL 过程完成后立即使缓存失效。

【讨论】：

【解决方案3】：

理想情况下，您必须缓存直到内容更改，如果由于任何原因在内容更改时无法清除/刷新缓存，则需要一个持续时间。但事实上，如果可以的话，永远缓存或不缓存。如果您已经知道没有任何变化，则无需刷新。

【讨论】：

【解决方案4】：

“这实际上取决于”您的用例、您想要实现的目标以及您的品牌主张。

如果您只想节省一些带宽，则可以进行总成本细分。服务成本可能不会太多。例如，浏览器在优化图像点击方面非常聪明，因此请了解您的 HTTP 协议。永远，结合版本化的资源 url，和 url 重写规则可能是一个不错的选择，就像你的 Google 工程师建议的那样。

资源波动是另一个问题。例如，如果您只提供每日股票图表，则可以安全地缓存一段时间，但不能永久缓存。

您的计算成本高吗？您的用户对时效性敏感吗？数据是实时的还是固定的？例如，您可能正在为航空公司航线、飓风路径、希腊选项或向 COO 提交 BI 报告提供服务。您可能希望缓存它，但 TTL 可能会因用户类别而异，一直到从不。 Forever 不能用于实时数据，但也永远不会是错误的答案。

服务器和客户端之间的合作程度可能是另一个因素。例如，在可以分发程序并期望遵循的业务运营环境中，可能值得再次查看 TTL。

HTH。我怀疑是否有一个神奇的答案。

【讨论】：