关于AWS CloudFront缓存机制的探究

Amazon CloudFront 是一项内容传输 Web 服务。它可与其他 Amazon Web Services 产品集成,帮助开发人员和企业在低延迟、高数数据传输、无最低使用承诺的环境下向最终用户轻松发布内容。CloudFront 可使用全球节点网络发布您的整个网站,包括动态、静态、流媒体和交互内容。对您的网站内容的请求将自动路由到最近节点,实现内容发布性能最佳。

简单来说,Amazon云旗下的CloudFront是一个内容分发系统,用于帮助用户缓存站点内容,在客户请求服务时就近分发。

之所以去探究它的缓存机制,是因为在最近工作过程中,使用了CloudFront服务,但是对它的缓存刷新机制并不是很清除,导致在工作中出现疑惑。于是我就去调研了一下这个服务的缓存机制。

在官方说明文档(页面链接)中描述如下:

Typically, CloudFront serves an object from an edge location until the cache duration that you specified passes—that is, until the object expires. After it expires, the next time the edge location gets a user request for the object, CloudFront forwards the request to the origin server to verify that the cache contains the latest version of the object. The response from the origin depends on whether the object has changed:

  • If the CloudFront cache already has the latest version, the origin returns a 304 status code (Not Modified).
  • If the CloudFront cache does not have the latest version, the origin returns a 200 status code (OK) and the latest version of the object.

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 have been requested more recently.

可以用以下流程图表示:

CloudFront

AWS通过以上逻辑来对图片更新做出反应,保证用户在刷新缓存后一定能够获得最新的图片。默认的缓存时间为1天,有两种模式可以选择

1、继承源服务器头部信息

2、手动指定缓存时间

当前我所使用的为第一种模式,即继承源服务器头部信息。下面给出一次访问实例。例如访问网站的一个网页:

20160223103218

我们可以看到,返回的头部状态码为304,即已经缓存。下面查看具体的返回头信息:

20160223103028

可以看到X-Cache处为cloudfront,即从CloudFront取得缓存。Server为openresty,max-age为在服务器上自定义的86400s。可以看出,确实是从服务器处继承了头部信息。

如果需要自定义缓存时间,则需要在AWS的CloudFront控制面板进行修改:

20160223103835

选择Behaviors,点击Edit,自定义其中Cache模式为Customize并自定义时间

20160223103852

CloudFront具有非常智能化的缓存管理机制,在使用默认配置的情况下即可拥有很好的用户体验。但是在定制化方面设置不够人性化,在不阅读文档的情况下很难了解其中具体的信息。

暂无评论

发表评论

电子邮件地址不会被公开。 必填项已用*标注