将文件推送到Amazon Cloudfront:可能吗？

Question

我一直在读拉动和推送CDN.我一直在使用Cloudfront作为调整大小图像的拉CDN:

• 从客户端接收图像
• 将图像放入S3

稍后,当客户端向Cloudfront请求URL时,Cloudfront没有映像,因此必须将其转发到我的服务器,其中:

• 收到请求
• 从S3拉出图像
• 调整图像大小
• 将图像推回到Cloudfront

然而,这需要几秒钟,这是一个非常恼人的等待,当你第一次上传你美丽的图像,并希望看到它.延迟似乎主要是下载/重新上载时间,而不是调整大小,这是非常快的.

是否可以主动将已调整大小的图像推送到Cloudfront并将其附加到URL,以便将来的请求可以立即获得准备好的图像？理想情况下我想

• 从客户端接收图像
• 将图像放入S3
• 调整常见尺寸的图像大小
• 先发制人地将这些规模推向云端

这避免了整个下载/重新上载周期,使得常见的大小非常快,但仍然可以访问不太常见的大小(尽管第一次有延迟).但是,要做到这一点,我需要将图像推送到Cloudfront.这个:

http://www.whoishostingthis.com/blog/2010/06/30/cdns-push-vs-pull/

似乎暗示它可以做到,但我见过的其他一切都没有提到它.我的问题是:有可能吗？或者我有什么其他解决方案可以解决这个问题吗？

Answer 1

我们已经尝试与不同的 CDN 提供商进行类似的事情，对于 CloudFront，如果 Cloudfront 发行版正在使用您的自定义原产地。

我能想到的一种方法，也正如@Xint0 提到的那样，是设置另一个 S3 存储桶来专门托管您想要推送的那些文件（在您的情况下是那些调整大小的图像）。基本上，您将有两个 cloudFront 发行版，一个用于提取那些很少访问的文件，另一个用于推送那些经常访问的文件以及您希望调整大小的图像。这听起来有点复杂，但我相信这是您必须做出的权衡。

我可以推荐你看的另一点是 EdgeCast，它是另一个 CDN 提供商，他们确实提供了名为 load_to_edge 的功能（我上个月花了很多时间将它与我们的服务集成，这就是为什么我记得很清楚）它确实正是您所期望的。他们还支持自定义来源拉动，因此也许您可以在那里进行试用。

Answer 2

OP要求推送CDN解决方案,但听起来他真的只是想让事情变得更快.我冒昧地说你可能不需要实现CDN推送,你只需要优化你的原始服务器模式.

那么,OP,我将假设你最多只支持少数图像尺寸 - 比方说128x128,256x256和512x512.听起来你在S3中拥有这些图像的原始版本.

这是当前在缓存未命中时发生的事情:

1. CDN收到128x128版图像的请求
2. CDN没有该图像,因此它从您的源服务器请求它
3. 您的源服务器接收请求
4. 您的源服务器从S3下载原始图像(可能是更大的图像)
5. 您的原点调整该图像的大小并将其返回CDN
6. CDN将该图像返回给用户并缓存它

你应该做什么代替:

根据您的具体情况,这里有一些选项.

您可以使用当前的设置快速修复以下内容:

1. 如果你必须从S3获取你的原始图像,你基本上是这样做,以便缓存未命中导致每个图像的下载时间与原始大小的图像一样长.如果可能的话,您应该尝试将原始图像存储在原始服务器可以快速访问的某个位置.根据您的设置,这里有一百万个不同的选项,但从S3获取它们是所有这些中最慢的.至少你没有使用Glacier;).
2. 您没有缓存已调整大小的图像.这意味着Cloudfront使用的每个边缘节点都将请求此图像,这将触发整个调整大小过程.Cloudfront可能拥有数百个单独的边缘节点服务器,这意味着每个映像有数百个丢失和调整大小.根据Cloudfront对分层分发的作用,以及如何设置文件头,它可能实际上并不那么糟糕,但它不会很好.
3. 我在这里走出困境,但我打赌你没有设置自定义过期标题,这意味着Cloudfront只会将这些图像缓存24小时.如果您的图像在上传后是不可变的,那么您将真正受益于返回到期标头,告知CDN长时间不检查新版本.

以下是一些可能更好的模式的想法:

1. 当有人上传新图像时,立即将其转码为您支持的所有尺寸,并将其上传到S3.然后只需将您的CDN指向该S3存储桶即可.这假设您拥有可管理数量的受支持图像大小.但是,我要指出,如果你支持太多的图像大小,CDN可能是错误的解决方案.您的缓存命中率可能很低,以至于CDN确实妨碍了.如果是这种情况,请参阅下一点.
2. 如果你支持连续调整大小(例如,我可以请求image_57x157.jpg或image_315x715.jpg等等,服务器会返回它)那么你的CDN实际上可能会通过引入一个额外的跳跃而不会从你的起源.在这种情况下,我可能会在所有可用区域中启动EC2实例,在它们上安装源服务器,然后根据客户端IP将图像URL交换到适合区域的源(有效地滚动您自己的CDN).

如果你真的想推送到Cloudfront:

你可能不需要,但如果你只是必须,这里有几个选项:

1. 编写脚本以使用webpagetest.org API从世界各地的不同地方获取图像.从某种意义上说,你将拉动命令推送到所有不同的边缘位置.这不能保证填充每个边缘位置,但您可能会接近.请注意,我不确定webpagetest.org会如何以这种方式使用它,但我没有看到任何关于它的使用条款(IANAL).
2. 如果您不想使用第三方或冒险使用webpagetest.org,只需在每个区域中启动一个微EC2实例,并使用它们来获取内容,与#1相同.