5

假设您在 AWS 中运行 instance1、instance2 和 instance3。

它们都在运行 Apache，您运行的 Web 应用程序需要允许用户上传图像，这在许多项目中都是如此。

此外，当您显示图像时，您需要将其裁剪为正确的大小，因此您基本上需要确保所有实例始终可以访问相同的文件。

假设一个用户将一张图片上传到instance1，另一个用户正在访问一个页面，其中相同的图像以100x100 大小显示，他点击了instance2。另一个用户试图在 instance3 上查看 300x300 大小的相同图像。以及许多其他不易预测的尺寸。

所以你基本上需要一个分布式文件系统，我使用的是 Gluster FS。因此，所有实例都可以访问相同的文件，当请求查看图像时，我有一个 PHP 脚本来检查图像是否已经调整到给定的尺寸，如果是，它将显示它们，如果不是，它将调整大小它然后再次显示。

Gluster FS 运行非常顺利，我对此非常满意，但我认为我正在重新发明轮子，AWS 应该为此提供某种解决方案。使用 top 命令我可以看到 glusterfs 总是在使用我的一些 CPU。

我还使用 CloutFront 缓存我的调整大小脚本的输出，这在很大程度上减少了服务器负载，但 Gluster FS 的运行成本仍然很高。

你可以在没有 Gluster FS 的情况下使用 rsync 和某种 cron 作业来做同样的事情，但这是很多工作而且不是很可靠，因为你需要知道什么时候触发 rsyncing 过程，你仍然不会得到很大的好处Gluster FS 提供的。我也尝试过 s3fs，我只想说这绝对是一场噩梦。

与 Gluster FS 相比，NFS 驱动器似乎也非常原始，我认为它们使用 UDP，因此它们将您的数据视为无关紧要。

那么做这样的事情的最好方法是什么？我试图找到 AWS 提供的分布式文件系统，因为我认为许多开发人员会遇到相同或相似的问题，但没有任何问题。

您可能会说只是上传到 s3，但 s3 对我没有帮助，我需要知道图像是否已经调整大小，然后调整大小并服务或只是服务，所以我需要一些我可以编写脚本的东西。

你也可能会说，你为什么不先调整所有图像的大小，然后将它们全部上传到s3，我不能这样做的原因是

  1. 大约有 100 万张图像和 100 种尺寸，所以我们正在寻找大量要转换的文件
  2. 可能每天都会添加新的尺寸，因此先调整尺寸的策略不起作用
4

1 回答 1

0

我会用 2 个 S3 存储桶接近它：

  • 主图片桶：以网站使用的原始分辨率/最佳分辨率上传图片，没有过期时间。
  • 缓存桶：创建按需图像，您可以使用timthumb以请求的大小创建它们并设置到期时间。

当用户请求图像时，您检查缓存桶中是否存在，否则您创建它，将其存储在缓存桶中并从那里分派。

注意事项：

  • 注意 timthumb，旧版本存在安全问题，您可以检查替代方案。
  • squid-cache 也有帮助，你可以用另一个 ec2 实例替换缓存桶

这只是我的方法，但请随时回复并更深入地掌握它

于 2013-07-04T08:22:21.453 回答