【问题标题】:rails server to server image transfers with heroku's local file system使用heroku的本地文件系统进行rails服务器到服务器的图像传输
【发布时间】:2012-12-21 17:13:51
【问题描述】:

我正在创建一个网络服务来从用户指定的外部站点获取一堆图像并将它们存储在 S3 上。

该应用托管在 heroku 上。

heroku 应用的流程:
1.调用www.example.com/image.jpg并在本地保存文件
2.将图片处理成不同大小
3.上传图片到S3

我很担心heroku 的ephemeral file system。我只是将它用作 /tmp 存储,但我担心它会遇到限制。如果用户从他们的本地机器上传,那么我可以直接上传到 S3,但由于它来自另一台服务器,我看不到方法。

有没有人在尝试处理大量文件时遇到 heroku 的临时本地文件系统问题?

【问题讨论】:

  • 在执行此操作时是否遇到任何问题,或者您只是在执行此操作之前寻找其他人的经验?另外,你能定义“手数”吗?
  • 我没有遇到问题。寻找其他人的经验。还不确定有多少,这与规模无关,更多的是关于 heroku 上的临时文件系统的可靠性。如果我每分钟制作 1000 张图像,我总是可以添加更多的测功机,但如果 10% 的时间本地文件存储崩溃,那么它是不可行的
  • 我认为,如果您每分钟持续处理 1000 张图像并且您不想冒丢失任何图像的风险,那么您肯定希望在处理您的工作时将图像存储在某个可靠的地方队列。 Heroku 中的文件系统不能保证存在很长时间。

标签: ruby-on-rails heroku amazon-s3


【解决方案1】:

使用 PaperClip,您可以选择为您的图片提供 remote_url。您仍然可以直接上传到 S3 并避免使用 Heroku 文件系统的风险。

【讨论】:

  • 您是否知道这是否在内存中完成所有处理?还是需要使用 /tmp 存储以便 imagemagick 可以对其进行操作?感谢您的反馈!
  • 抱歉,我不确定 Heroku 的 ImageMagick 实现,但由于 resize-and-upload-to-S3 设置在临时文件系统之前工作,我猜它要么在内存中,要么在Heroku 为 ImageMagick 提供了创建可靠本地副本所需的权限。他们确实建议先将原始文件保存到 S3,然后使用后台工作人员进行图像处理,这样就不会捆绑测功机,从而影响最终用户体验。
猜你喜欢
  • 2014-01-04
  • 2013-11-14
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-12-29
  • 1970-01-01
  • 2015-03-01
  • 1970-01-01
相关资源
最近更新 更多