Cloudfront TTL 不起作用 [英] Cloudfront TTL not working

问题描述

我遇到了一个问题，并试图按照论坛中的答案进行操作，但没有任何成功.

I'm having a problem and tried to follow answers here in forum, but with no success whatsoever.

为了生成缩略图，我设置了以下架构:原始图像的 S3 帐户使用 NGINX 和 Thumbor 的 Ubuntu 服务器云前线

In order to generate thumbnails, I have set up the following schema: S3 Account for original images Ubuntu Server using NGINX and Thumbor Cloudfront

用户将原始图像上传到 S3，它将在请求前通过 Ubuntu Server 和 Cloudfront 拉取:

The user uploads original images to S3, which will be pulled through Ubuntu Server with Cloudfront in front of the request:

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

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

The big deal is, that we often loose objects in Cloudfront, I want them to stay 360 days in cache. I get following response through 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 响应如下:

My Nginx responses as following:

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 设置了吗?非常感谢.

Why does Cloudfront not store my objects as indicated? Max-Age is set? Many thanks in advance.

推荐答案

您的第二个请求表明该对象确实已被缓存.我想你看到了，但问题没有说清楚.

Your second request shows that the object was indeed cached. I assume you see that, but the question doesn't make it clear.

Cache-Control: max-age 仅指定 Cloudfront 缓存中任何特定边缘位置的对象的最大年龄.没有保证您的对象持续存在的最短时间间隔……毕竟，Cloudfront 是一个缓存，根据定义它是易变的.

The Cache-Control: max-age only specifies the maximum age of your objects in the Cloudfront Cache at any particular edge location. There is no minimum time interval for which your objects are guaranteed to persist... after all, Cloudfront is a cache, which is volatile by definition.

如果边缘站点中的对象不经常被请求，CloudFront 可能会驱逐该对象——在其到期日期之前删除该对象——为更受欢迎的对象腾出空间.

If an object in an edge location isn't frequently requested, CloudFront might evict the object—remove the object before its expiration date—to make room for objects that are more popular.

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

此外，没有 Cloudfront 作为一个整体拥有对象副本的概念.每个边缘站点的缓存似乎都独立于其他站点运行，因此经常会看到来自不同 Cloudfront 边缘站点的对相对流行对象的多个请求.

Additionally, there is no concept of Cloudfront as a whole having a copy of your object. Each edge location's cache appears to operate independently of the others, so it's not uncommon to see multiple requests for relatively popular objects coming from different Cloudfront edge locations.

如果您试图调节后端服务器上的负载，那么在其前面放置某种您控制的缓存可能是有意义的，例如清漆、鱿鱼、另一个 nginx 或自定义解决方案，这就是我在我的系统中实现这一目标的方式.

If you are trying to mediate the load on your back-end server, it might make sense to place some kind of cache that you control, in front of it, like varnish, squid, another nginx or a custom solution, which is how I'm accomplishing this in my systems.

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

Alternately, you could store every result in S3 after processing, and then configure your existing server to check S3, first, before attempting the work of resizing the object again.

那为什么有一个记录在案的最低限度"?TTL?

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

On the same page quoted above, you'll also find this:

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

For web distributions, if you add Cache-Control or Expires headers to your objects, you can also specify the minimum amount of time that CloudFront keeps an object in the cache before forwarding another request to the origin.

我可以理解为什么会这样，以及评论中引用的提示短语，如下...

I can see why this, and the tip phrase cited on the comment, below...

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

The minimum amount of time (in seconds) that an object is in a CloudFront cache before CloudFront forwards another request to your origin to determine whether an updated version is available. 

...似乎与我的回答相矛盾.然而，这并不矛盾.

...would seem to contradict my answer. There is no contradiction, however.

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

The minimum ttl, in simple terms, establishes a lower boundary for the internal interpretation of Cache-Control: max-age, overriding -- within Cloudfront -- any smaller value sent by the origin server. Server says cache it for 1 day, max, but configured minimum ttl is 2 days? Cloudfront forgets about what it saw in the max-age header and may not check the origin again on subsequent requests for the next 2 days, rather than checking again after 1 day.

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

The nature of a cache dictates the correct interpretation of all of the apparent ambiguity:

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

Your configuration limits how long Cloudfront MAY serve up cached copies of an object, and the point after which it SHOULD NOT continue to return the object from its cache. They do not mandate how long Cloudfront MUST maintain the cached copy, because Cloudfront MAY evict an object at any time.

如果您正确设置了 Cache-Control: 标头，Cloudfront 会将 max-age 或您的最小 TTL 中的较大者视为您希望它们的最长时间无需再次咨询源服务器即可提供缓存副本.

If you set the Cache-Control: header correctly, Cloudfront will consider the larger of max-age or your Minimum TTL as the longest amount of time you want them to serve up the cached copy without consulting the origin server again.

随着您网站流量的增加，这应该会变得不那么重要，因为您的对象会更受欢迎"，但基本上没有办法强制 Cloudfront 维护对象的副本.

As your site traffic increases, this should become less of an issue, since your objects will be more "popular," but fundamentally there is no way to mandate that Cloudfront maintain a copy of an object.

这篇关于Cloudfront TTL 不起作用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！