为什么Cloudfront会在几小时内从缓存中驱逐对象？
ric*_*ard 1 caching image amazon-cloudfront
Cloudfront配置为缓存来自我们应用的图像.我发现这些图像很快就从缓存中逐出.由于图像是动态生成的,因此对于我们的服务器来说这是非常激烈的.为了解决这个问题,我设置了一个测试用例.
原始标题
该图像是由我们的原始服务器送达正确Last-Modified和Expires头.
Cloudfront缓存行为
由于该站点仅为HTTPS,因此我将其设置Viewer Protocol Policy为HTTPS.Forward Headers被设置为None与Object Caching对Use Origin Cache Headers.
初始图像请求
我在11:25:11请了一张照片.这返回了以下状态和标题:
- 代码:200(OK)
缓存:没有
到期日:2016年9月29日星期四09:24:31 GMT
- 最后修改时间:2015年9月30日星期三09:24:31 GMT
- X-Cache:来自云端的小姐
后续请求
稍后重新加载(11:25:43)返回图像:
- 代码:304(未修改)
缓存:是的
到期日:2016年9月29日星期四09:24:31 GMT
- X-Cache:来自云端
几个小时后的请求
差不多三个小时后(14:16:11)我去了同一页面,图片载满了:
- 代码:200(OK)
缓存:是的
到期日:2016年9月29日星期四09:24:31 GMT
- 最后修改时间:2015年9月30日星期三09:24:31 GMT
- X-Cache:来自云端的小姐
由于图像仍然由浏览器缓存,因此可以快速加载.但我无法理解Cloudfront如何无法返回缓存的图像.因此,应用程序必须再次生成图像.
我读到Cloudfront在闲置几天后会从其缓存中驱逐文件.如上所述,情况并非如此.怎么会这样？
我读到Cloudfront在闲置几天后会从其缓存中驱逐文件.
你有官方消息来源吗？
这是官方的答案:
如果不经常请求边缘位置中的对象,CloudFront可能会逐出对象 - 在其到期日期之前删除对象 - 为最近请求的对象腾出空间.
http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html
缓存对象没有保证的保留时间,需求较低的对象更容易被驱逐......但这不是您可能没有考虑过的唯一因素.驱逐可能不是问题,也不是唯一的问题.
CloudFront缓存的对象就像薛定谔的猫一样.这是一个松散的类比,但我正在使用它:在任何给定的瞬间,对象是否"在云端缓存中"不是一个是或否的问题.
CloudFront 在37个城市中有大约53个边缘位置(您的浏览器连接并且内容是物理存储的).一些主要城市有2或3.每个点击云端的请求都被路由(通过DNS)到理论上最理想的位置 - 为简单起见,我们称之为"最接近"的边缘.
Cloudfront的内部工作原理不是公共信息,但基于观察和可能权威来源的普遍共识是这些边缘位置都是独立的.他们不共享缓存.
例如,如果您在德克萨斯州(美国)并且您的请求被路由并且被缓存在达拉斯/德克萨斯州沃思堡,并且如果赔率相等,那么您的任何请求都可能击中达拉斯的任何一个边缘位置,那么直到你得到同一个物体的两次失误,赔率大约是50/50,你的下一个请求将是未命中.如果我从我的位置请求相同的对象,我从经验中知道往往通过南本德,IN,那么我的第一次请求是未命中的几率是100%,即使它被缓存在达拉斯.
因此,对象不在缓存中,也不在缓存中,因为没有"(")(单个,全局)缓存.
CloudFront对浏览器"最近"边缘的确定也可能会随着时间的推移而发生变化.
CloudFront用于确定最近边缘的机制似乎是动态和自适应的.互联网拓扑结构的变化可以改变边缘位置倾向于接收从给定IP地址发送的请求的移位,因此在几个小时的过程中,您连接的边缘可能会发生变化.影响特定边缘的维护或中断或其他问题也可能导致来自给定源IP地址的请求被发送到与典型边缘不同的边缘,这也可能让您感觉对象被驱逐,因为新边缘的缓存会有所不同.
查看响应标头,无法确定处理每个请求的边缘位置.然而,这个信息是在所提供的CloudFront的访问日志.
我有一个fetch-and-resize图像服务,每天处理大约750,000张图像.它落后于CloudFront,我的命中/失败率约为50/50.这当然不是所有CloudFront的错,因为我的图像池超过800万,观众遍布全世界,我的max-age指令比你的短.自从我上次分析日志以确定哪些以及"未命中"看起来出乎意料时已经有一段时间了(虽然当我这样做时,确实存在一些,但它们的数量并非不合理),但这样做很容易,因为日志告诉你每个响应是一个命中还是一个未命中,以及识别边缘位置......所以你可以分析它,看看这里是否真的有一个模式.
我的服务将其所有输出内容存储在S3中,当新请求进入时,它首先向S3存储桶发送快速请求,以查看是否有可以避免的工作.如果S3返回结果,则该结果将返回到CloudFront,而不是再次执行所有提取和调整大小的工作.请注意,由于CloudFront未命中的数量,我没有实现这种功能......我从一开始就设计了这个功能,甚至在CloudFront后面测试它之前,因为 - 毕竟 - CloudFront是一个缓存,并且根据定义,缓存的内容几乎是不稳定的和短暂的.
更新:我在上面说过,通过检查来自CloudFront的请求标头,似乎无法识别转发特定请求的边缘位置......但是,通过检查源IP地址,可能会有一定程度的准确性.传入的请求.
例如,通过CloudFront发送到我的一个源服务器的测试请求从54.240.144.13到达,如果我从家中到达我的站点,或者当我从办公室到达站点时205.251.252.153 - 这些位置相距仅几英里,但在州边界的两侧,并使用两个不同的ISP.这些地址的反向DNS查找显示了这些主机名:
server-54-240-144-13.iad12.r.cloudfront.net.
server-205-251-252-153.ind6.r.cloudfront.net.
CloudFront边缘位置以最近的主要机场命名,加上任意选择的号码.对于iad12..."IAD"是华盛顿特区杜勒斯机场的国际航空运输协会(IATA)代码,所以这可能是弗吉尼亚州阿什本的边缘地点之一(有三个,可能有不同的数字代码在结束,但我不能从这个数据确认).对于ind6,"IND"与印第安纳州印第安纳波利斯的机场相匹配,所以这强烈暗示这个要求来自南边弯,IN,边缘位置.此测试的可靠性取决于CloudFront维护其反向DNS条目的一致性.没有记录在任何给定边缘位置可能有多少独立缓存; 假设只有一个,但可能有不止一个,具有增加非常少量请求的未命中率的效果,但消失在大量请求的混合中.