CloudFront TTL 过期和失效之间的区别？

Question

CloudFront 通过 CloudFront TTL 设置在源使对象过期与调用 invalidate 之间有什么实际区别？

Answer 1

总体思路是，您使用 TTL 来设置 CloudFront 用来确定从 CloudFront 缓存提供服务的每个单独对象的最长时间，而无需与源进行进一步交互。

\n\n

默认 TTLCache-Control ：当源未提供相关指令时，对象可以在 CloudFront 缓存中保留而不被视为过时的最长时间。CloudFront不会Cache-Control将标头添加到响应中。

\n\n

最小 TTL：如果源提供的 Cache-Control: s-maxage 值（或者，如果不存在，则 Cache-Control: max-age 值）小于此值，CloudFront 会忽略它并假定它可以将对象保留在缓存时间不超过此。例如，如果最小 TTL 设置为 900，但响应包含Cache-Control: max-age=300，CloudFront 会忽略 300 并可能将对象缓存最多 900 秒。标Cache-Control头不会被修改，并按收到的样子返回给查看者。

\n\n

最大 TTL：如果源提供了Cache-Control指示对象可以缓存超过此时间的指令，则 CloudFront 会忽略该指令并假定继续从缓存提供对象的时间不得超过最大 TTL。

\n\n

请参阅Amazon CloudFront 开发人员指南中的指定对象在 CloudFront 边缘缓存中保留的时间（过期） 。

\n\n

因此，这三个值控制 CloudFront 使用什么来确定缓存的响应是否仍然“足够新鲜”以返回给后续查看者。这并不意味着 CloudFront 在 TTL 过期后清除缓存的对象。相反，CloudFront可能会保留该对象，但不会在过期后提供该对象，除非先向源发送请求以查看该对象是否已更改。

\n\n

CloudFront 不会主动检查已过期对象的新版本的来源 - 它仅检查是否再次请求它们（同时仍在缓存中），然后确定它们已过期。当它这样做时，它通常使用诸如 之类的指令发送一个条件请求If-Modfied-Since。这为源提供了响应选项304 Not Modified，告诉 CloudFront 缓存的对象仍然可用。

\n\n

有时会出现一个误解，TTL 指示 CloudFront 缓存对象的时间。它不是这么做的。它告诉 CloudFront允许缓存响应多长时间，而无需对源进行重新验证。CloudFront 内的缓存存储没有相关费用，并且根据定义，缓存是短暂的，因此很少请求的对象可能会在 TTL 过期之前从缓存中清除。

\n\n

\n

如果不经常请求边缘站点中的对象，CloudFront 可能会逐出该对象\xe2\x80\x94在其过期日期之前删除该对象\xe2\x80\x94，以便为最近请求的对象腾出空间。

\n\n

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html

\n

\n\n

在下一个请求时，CloudFront 将再次从源请求该对象。

\n\n

另一个误解是 CloudFront 的缓存是整体的。事实并非如此。每个全局边缘都有自己独立的缓存，将对象缓存在通过其请求的边缘中。每个全局边缘还有一个上游区域缓存（在最近的 EC2 区域；每个区域可能不止一个，但这没有记录），对象也将存储在其中，允许其他附近的全局边缘找到该对象在最近的区域缓存中，但 CloudFront 不会在内部进一步搜索缓存对象。为了提高性能，它只会在缓存未命中时转到原点。

\n\n

请参阅CloudFront 如何与区域边缘缓存配合使用。

\n\n

失效则完全不同，并且应谨慎使用——只有AWS 账户每月提交的前 1000 个失效路径是免费的。（一个路径可以匹配多个文件，并且该路径/*匹配发行版中的所有文件）。

\n\n

失效请求具有创建失效的时间戳，并向所有区域发送一条消息，指示它们按照这些方式执行某些操作（没有记录确切的算法，但这准确地描述了最终效果）：

\n\n

\n
• 从缓存中删除所有匹配的文件${path}（如果它们之前已缓存${timestamp}）
\n
• 同时，由于这可能需要一些时间，因此如果您收到任何对${path}之前缓存的文件匹配的请求${timestamp}，请不要使用缓存的文件，因为它们不再可用。
\n

\n\n

一旦整个网络都收到消息，失效请求就被认为完成。失效本质上是一种幂等操作，从某种意义上说，使实际上不存在的文件失效并不是一个错误，因为失效是告诉边缘在以下情况下使此类文件失效：存在）失效。

\n\n

由此可见，正确的做法不是选择其中之一，而是酌情使用两者。设置您的 TTL（或选择“使用原始缓存标头”并配置您的原始服务器始终以适当的值返回它们），然后仅在必要时使用失效来清除所选内容或所有内容的缓存，如果您\'我犯了一个错误，或者对网站进行了重大更改。

\n\n

然而，最佳实践不是指望失效，而是在对象更改时使用缓存清除技术。缓存清除意味着更改所请求的实际对象。例如，在最简单的实现中，这可能意味着您在 HTML 中将 /pics/cat1.png 更改为 /pics/cat2.png，而不是在需要新图像时将新图像保存为 /pics/cat1.png。将一个文件替换为同一 URL 上的另一个文件的问题是浏览器也有缓存，并且可能会继续显示旧图像。

\n\n

另请参见使对象无效。

\n\n

另请注意，主 TTL 不用于错误响应。默认情况下，类似的响应404 Not Found会缓存 5 分钟。这是错误缓存最小 TTL，旨在使您的源服务器免于接收可能继续失败的请求，但仅持续几分钟。

\n