12

我一直在阅读有关拉取和推送 CDN 的信息。我一直在使用 Cloudfront 作为调整大小图像的拉式 CDN：

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

稍后，当客户端向云端请求 URL 时，云端没有图像，因此它必须将其转发到我的服务器，其中：

  • 接收请求
  • 从 S3 拉取图像
  • 调整图像大小
  • 将图像推送回 Cloudfront

但是，这需要几秒钟，当您第一次上传美丽的图像并想看到它时，这真的很烦人。延迟似乎主要是下载/重新上传时间，而不是调整大小，这非常快。

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

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

这避免了整个下载/重新上传周期，使常见尺寸非常快，但仍然可以访问不太常见的尺寸（尽管第一次有延迟）。但是，要做到这一点，我需要将图像推送到 Cloudfront。这：

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

似乎暗示它可以完成，但我所看到的其他一切都没有提到它。我的问题是：有可能吗？还是我缺少此问题的其他解决方案？

4

3 回答 3

6

我们已经尝试与不同的 CDN 提供商进行类似的事情，对于 CloudFront，如果 CloudFront 分发使用您的自定义来源。

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

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

于 2012-05-08T01:50:35.520 回答
5

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 相同。
于 2013-10-24T23:45:55.433 回答
2

AFAIK CloudFront 使用 S3 存储桶作为数据存储。因此，在调整图像大小后，您应该能够将调整大小的图像直接保存到 CloudFront 使用的 S3 存储桶中。

于 2012-05-02T18:54:50.790 回答