我一直在阅读拉动和推送CDN。我一直在使用Cloudfront作为调整大小图像的拉CDN:
稍后,当客户端向Cloudfront请求URL时,Cloudfront没有该映像,因此必须将其转发到我的服务器,其中:
- 接收请求
- 从S3中提取图片
- 调整图片大小
- 将图片推回Cloudfront
然而,这需要几秒钟,这是一个非常烦人的等待,当你第一次上传你的美丽图像,并希望看到它。延迟似乎主要是下载/重新上载时间,而不是调整大小,这非常快。
是否可以主动将已调整大小的图像推送到Cloudfront并将其附加到URL,以便将来的请求可以立即获得准备好的图像?理想情况下我想
- 从客户端接收图片
- 将图像放入S3
- 调整常用尺寸的图片
- 先发制人地将这些尺寸推向云端
这避免了整个下载/重新上载周期,使得常见的大小非常快,但仍然可以访问不太常见的大小(尽管第一次有延迟)。但是,要做到这一点,我需要将图像推送到Cloudfront。这样:
http://www.whoishostingthis.com/blog/2010/06/30/cdns-push-vs-pull/
似乎暗示可以做到,但我见过的其他一切都没有提到它。我的问题是:有可能吗?或者我还缺少其他解决方案吗?
3 个答案:
答案 0 :(得分:5)
OP要求推送CDN解决方案,但听起来他真的只是想让事情变得更快。我冒昧地说你可能不需要实现CDN推送,你只需要优化你的原始服务器模式。
所以,OP,我假设你最多只支持少数图像尺寸 - 比方说128x128,256x256和512x512。听起来你在S3中也有这些图像的原始版本。
这是当前在缓存未命中时发生的事情:
- CDN收到128x128版图片的请求
- CDN没有该图像,因此它从您的原始服务器请求它
- 您的源服务器收到请求
- 您的原始服务器从S3下载原始图像(可能是较大的图像)
- 您的来源调整该图片的大小并将其返回CDN
- CDN将该图像返回给用户并将其缓存
醇>
你应该做什么:
根据您的具体情况,这里有一些选项。
以下是您可以使用当前设置快速修复的一些内容:
- 如果你必须从S3中获取原始图像,那么你基本上是这样做的,这样一个缓存未命中会导致每个图像的下载时间与原始大小的图像一样长。如果可能的话,您应该尝试将原始图像存储在原始服务器可以快速访问的某个位置。根据您的设置,这里有一百万个不同的选项,但从S3获取它们是所有这些中最慢的。至少你没有使用Glacier;)。
- 您没有缓存已调整大小的图像。这意味着Cloudfront使用的每个边缘节点都将请求此图像,这将触发整个调整大小过程。 Cloudfront可能拥有数百个单独的边缘节点服务器,这意味着每个映像有数百个丢失和调整大小。根据Cloudfront对分层分发的作用以及您如何设置文件头,它实际上可能 不好,但它不会很好。
- 我在这里走出困境,但我打赌你没有设置自定义过期标题,这意味着Cloudfront只会将这些图像缓存24小时。如果您的图片在上传后是不可变的,那么您将真正受益于返回过期标题,告知CDN长时间不检查新版本。
醇>
以下是一些可能更好的模式的想法:
- 当有人上传新图片时,请立即将其转码为您支持的所有尺寸,并将其上传到S3。然后只需将您的CDN指向该S3存储桶即可。这假设您拥有可管理数量的受支持图像大小。但是,我要指出,如果你支持太多的图像大小,CDN可能是错误的解决方案。您的缓存命中率可能很低,以至于CDN确实妨碍了。如果是这种情况,请参阅下一点。
- 如果你支持连续调整大小(例如,我可以请求image_57x157.jpg或image_315x715.jpg等等,服务器会返回它),那么你的CDN实际上可能会通过引入一个额外的跃点而不卸载来帮助你很多来自你的起源。在这种情况下,我可能会在所有可用区域中启动EC2实例,在它们上安装源服务器,然后根据客户端IP将图像URL交换到适合于区域的源(有效地滚动您自己的CDN)。
醇>
如果你真的想推送到Cloudfront:
您可能不需要,但如果您只是必须,这里有几个选项:
- 将脚本写入use the webpagetest.org APIs,以便从世界各地的不同地方获取您的图片。从某种意义上说,你将拉动命令推送到所有不同的边缘位置。这不能保证填充每个边缘位置,但您可能会接近。请注意,我不确定webpagetest.org如何以这种方式使用它,但我没有看到任何关于它的使用条款(IANAL)。
- 如果您不想使用第三方或冒险使用webpagetest.org,只需在每个地区启动微型EC2实例,然后使用这些实例获取内容,与#1相同。
醇>
答案 1 :(得分:4)
我们已尝试与不同的CDN提供商进行类似的事情,对于CloudFront,我不认为现有方法可以将您的特定内容推送到节点/边缘(我们称之为预馈送) cloudfront distribution正在使用您的自定义源。
我能想到的一种方式,也就像@Xint0所提到的那样,设置另一个S3存储桶来专门托管你想要推送的文件(在你的情况下是那些调整大小的图像)。基本上,您将拥有两个cloudFront分配,一个用于提取很少访问的文件,另一个用于推送经常访问的文件以及您希望调整大小的图像。这听起来有点复杂,但我相信这是你必须做出的权衡。
我建议你看一下另一点是EdgeCast,它是另一个CDN提供商,他们确实提供了一个名为load_to_edge的功能(我上个月花了很多时间将它与我们的服务集成,这就是为什么我清楚地记得它,它完全符合你的期望。他们还支持自定义原点拉动,所以也许你可以在那里进行试验。
答案 2 :(得分:2)
AFAIK CloudFront使用S3存储桶作为数据存储。因此,在调整图像大小后,您应该能够将调整大小的图像直接保存到CloudFront使用的S3存储桶中。