Cloudfront TTL无法正常工作

Question

我遇到了问题,并试图在论坛中回答这些问题,但没有任何成功.

为了生成缩略图,我设置了以下模式:使用NGINX和Thumbor Cloudfront的原始映像的DNS帐户Ubuntu服务器

用户将原始图像上传到S3,将在请求前通过Cloudfront通过Ubuntu Server提取:

http://cloudfront.account/thumbor-server/http://s3.aws ...

最重要的是,我们经常在Cloudfront中丢失对象,我希望它们在缓存中保留360天.我通过Cloudfront URL获得以下回复:

Cache-Control:max-age=31536000
Connection:keep-alive
Content-Length:4362
Content-Type:image/jpeg
Date:Sun, 26 Oct 2014 09:18:31 GMT
ETag:"cc095261a9340535996fad26a9a882e9fdfc6b47"
Expires:Mon, 26 Oct 2015 09:18:31 GMT
Server:nginx/1.4.6 (Ubuntu)
Via:1.1 5e0a3a528dab62c5edfcdd8b8e4af060.cloudfront.net (CloudFront)
X-Amz-Cf-Id:B43x2w80SzQqvH-pDmLAmCZl2CY1AjBtHLjN4kG0_XmEIPk4AdiIOw==
X-Cache:Miss from cloudfront

刷新后,我得到:

Age:50
Cache-Control:max-age=31536000
Connection:keep-alive
Date:Sun, 26 Oct 2014 09:19:21 GMT
ETag:"cc095261a9340535996fad26a9a882e9fdfc6b47"
Expires:Mon, 26 Oct 2015 09:18:31 GMT
Server:nginx/1.4.6 (Ubuntu)
Via:1.1 5e0a3a528dab62c5edfcdd8b8e4af060.cloudfront.net (CloudFront)
X-Amz-Cf-Id:slWyJ95Cw2F5LQr7hQFhgonG6oEsu4jdIo1KBkTjM5fitj-4kCtL3w==
X-Cache:Hit from cloudfront

我的Nginx响应如下:

Cache-Control:max-age=31536000
Content-Length:4362
Content-Type:image/jpeg
Date:Sun, 26 Oct 2014 09:18:11 GMT
Etag:"cc095261a9340535996fad26a9a882e9fdfc6b47"
Expires:Mon, 26 Oct 2015 09:18:11 GMT
Server:nginx/1.4.6 (Ubuntu)

为什么Cloudfront不按指示存储我的对象？Max-Age设定？提前谢谢了.

Answer 1

您的第二个请求显示该对象确实已缓存.我假设你看到了,但问题并没有说清楚.

该Cache-Control: max-age只规定最高在任何特定的边缘位置的的Cloudfront缓存的对象的年龄.保证对象保持不存在的最小时间间隔......毕竟,Cloudfront是一个缓存,根据定义它是不稳定的.

如果不经常请求边缘位置中的对象,CloudFront可能会逐出对象 - 在对象到期日之前删除对象 - 为更受欢迎的对象腾出空间.

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

此外,没有Cloudfront作为整体具有对象副本的概念.每个边缘位置的缓存似乎独立于其他位置运行,因此对于来自不同Cloudfront边缘位置的相对流行对象的多个请求并不罕见.

如果您正在尝试调解后端服务器上的负载,可能有必要在您面前放置一些您控制的缓存,如清漆,鱿鱼,另一个nginx或自定义解决方案,这就是我的方式在我的系统中实现这一点.

或者,您可以在处理后将每个结果存储在S3中,然后在尝试再次调整对象大小之前,先配置现有服务器以检查S3.

那为什么有一个记录在案的"最小"TTL？

在上面引用的同一页面上,您还会发现:

对于Web分发,如果向对象添加Cache-Control或Expires标头,还可以指定CloudFront在将另一个请求转发到源之前将对象保留在缓存中的最短时间.

我可以看到为什么这个,以及评论中引用的尖端短语,如下......

在CloudFront将另一个请求转发到您的源以确定更新版本是否可用之前,对象在CloudFront缓存中的最短时间(以秒为单位). 

......似乎与我的答案相矛盾.然而,没有矛盾.

简单来说,最小ttl为内部解释建立了一个较低的边界Cache-Control: max-age,覆盖 - 在Cloudfront内 - 由原始服务器发送的任何较小的值.服务器说缓存它1天,最多,但配置的最小ttl是2天？Cloudfront会忘记它在max-age标头中看到的内容,并且可能无法在接下来的2天后续请求中再次检查原点,而不是在1天后再次检查.

缓存的性质决定了对所有明显模糊性的正确解释:

您的配置限制了Cloudfront可以提供对象的缓存副本的时间长度,以及它不应该继续从其缓存中返回对象的时间点.他们没有强制Cloudfront必须维护缓存副本多长时间,因为Cloudfront MAY可以随时驱逐一个对象.

如果您Cache-Control:正确设置标题,Cloudfront会将较大的max-age或最小TTL视为您希望它们在不咨询原始服务器的情况下提供缓存副本的最长时间.

随着您的网站流量增加,这应该不再是一个问题,因为您的对象将更"受欢迎",但从根本上说,没有办法要求Cloudfront维护对象的副本.