CloudFront TTL到期和失效之间的区别?

时间:2018-05-25 12:53:51

标签: amazon-web-services amazon-cloudfront

CloudFront通过CloudFront TTL设置何时使来自原点的对象与一个调用无效时的实际差异有什么不同?

2 个答案:

答案 0 :(得分:2)

一般的想法是,您使用TTL设置CloudFront使用的策略,以确定可以从CloudFront缓存中提供每个单独对象的最大时间,而不与源进行进一步交互。

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

最小TTL :如果源提供的Cache-Control:s-maxage值(或者,如果不存在,则为Cache-Control:max-age值)小于此值,CloudFront将忽略并假设它可以将对象保留在缓存中不超过此时间。例如,如果Minimum TTL设置为900,但响应包含Cache-Control: max-age=300,则CloudFront将忽略300并且可以将对象缓存最多900秒。 Cache-Control标题未被修改,并在收到时返回给查看者。

最大TTL :如果源提供Cache-Control指令,指示对象可以缓存超过此时间,则CloudFront将忽略该指令并假定不得继续提供该对象从缓存中长度超过最大TTL。

请参阅Amazon CloudFront开发人员指南中的Specifying How Long Objects Stay in a CloudFront Edge Cache (Expiration)

因此,这三个值控制着CloudFront使用什么来确定缓存的响应是否仍然足够新鲜"被退回给后来的观众。这并不意味着CloudFront在TTL过期后清除缓存的对象。相反,CloudFront 可能会保留该对象,但如果没有先向该来源发送请求以查看该对象是否已更改,则不会在到期后提供该对象。

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

误解有时表面是TTL指示CloudFront缓存对象多长时间。这不是它的作用。它告诉CloudFront 允许缓存响应多长时间而不对源进行重新验证。 CloudFront内的缓存存储没有相关费用,按定义缓存是短暂的,因此,很少请求的对象可能会在TTL过期之前从缓存中清除。

  

如果经常请求边缘位置中的对象,CloudFront可能会逐出对象 - 在对象到期日之前删除对象 - 为最近请求的对象腾出空间。

     

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

在下一个请求中,CloudFront将再次从源请求对象。

另一个误解是CloudFront的缓存是单一的。它不是。每个全局边都有自己独立的缓存,在边缘缓存对象,通过它们来请求它们。每个全局边缘还有一个上游区域缓存(在最近的EC2区域;每个区域可能有多个,但是没有记录),其中对象也将被存储,允许其他附近的全局边缘找到对象位于最近的区域缓存中,但CloudFront不会在内部对缓存对象进行任何进一步搜索。为了提高性能,它只是在缓存未命中的原点。

请参阅How CloudFront Works with Regional Edge Caches

失效完全不同,并且旨在谨慎使用 - 只有AWS账户每月提交的前1000个失效路径是免费的。 (路径可以匹配许多文件,路径/*匹配分发中的所有文件)。

失效请求具有创建失效时间的时间戳,并向所有区域发送消息,指示他们沿着这些行做某事(确切的算法没有记录,但这准确地说明了净效应) ):

  • 从缓存中删除与${path}匹配的所有文件,如果它们在${timestamp}
  • 之前进行了缓存
  • 同时,由于这可能需要一些时间,如果您收到${path}之前缓存的${timestamp}匹配文件的请求,请不要使用缓存文件,因为它们已不再存在可用的。

一旦整个网络收到消息,则认为失效请求已完成。失效本质上是一种幂等行为,在某种意义上说,使实际不存在的文件无效是一种错误,因为失效告诉边缘使这些文件无效如果它们存在

由此可见,正确的行动方针不是选择其中一种,而是适当地使用两者。设置您的TTL(或选择"使用原始缓存标头"并始终配置您的源服务器以使用适当的值返回它们),然后仅在必要时使用失效来清除所选内容或所有内容的缓存,可能是如果您犯了错误或对网站进行了重大更改,则必须提供。

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

另见Invalidating Objects

另请注意,主要TTL不用于错误响应。默认情况下,404 Not Found等响应会缓存5分钟。这是Error Caching Minimum TTL,旨在减轻您的原始服务器接收可能会继续失败的请求,但只会持续几分钟。

答案 1 :(得分:1)

如果我们考虑实际差异:

  • CloudFront TTL:您可以控制对象在CloudFront将另一个请求转发到您的源之前保留在CloudFront缓存中的时间。
  • 无效:从边缓存中使对象无效。下次查看者请求对象时,CloudFront将返回原点以获取对象的最新版本。

所以主要区别在于速度。如果部署新版本的应用程序,则可能需要立即使其无效。