为什么要将资产直接上传到 S3？
我见过很多代码示例/插件促进将资产直接上传到 S3。例如，如果您有一个带有头像的用户对象，文件上传字段将直接加载到 S3。
我认为这是可能的唯一方法是，如果用户对象已在数据库中创建，并且您的 S3 存储桶 + 路径类似于
user_avatars.domain.com/some/id/partition/medium.jpg
但是，如果您有一个图像标签在未上传头像时尝试访问该 URL，那么它会产生不好的结果。您将如何处理检查是否存在？
而且，对于大多数有很多协会的人来说，这似乎不太有效。例如，如果用户有很多歌曲/mp3，您会将它们存储在哪里以及如何访问它们。
此外，您的验证也会被删除。
我很难想象直接上传到 S3（或任何云）是个好主意的情况，并希望人们能够澄清正确的用例，或者告诉我为什么我的逻辑不正确。
I have seen quite a few code samples/plugins that promote uploading assets directly to S3. For example, if you have a user object with an avatar, the file upload field would load directly to S3.
The only way I see this being possible is if the user object is already created in the database and your S3 bucket + path is something like
user_avatars.domain.com/some/id/partition/medium.jpg
But then if you had an image tag that tried to access that URL when an avatar was not uploaded, it would yield a bad result. How would you handle checking for existence?
Also, it seems like this would not work well for most has many associations. For example, if a user had many songs/mp3s, where would you store those and how would you access them.
Also, your validations will be shot.
I am having trouble thinking of situations where direct upload to S3 (or any cloud) is a good idea and was hoping people could clarify either proper use cases, or tell me why my logic is incorrect.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
为什么要为存储/带宽/备份/等付费？什么时候你可以让云端的人为你处理？
S3（和其他基于云的存储选项）可以为您解决所有令人头疼的问题。您可以获得所需的所有存储、良好的分发网络（几乎肯定比您自己拥有的更好，除非您支付高级 CDN）和备份。
允许用户直接上传到 S3 可以减轻您更多的带宽负载。我可以看到跟踪问题，但 S3 可以很容易地处理这种情况。如果您查看直接上传方法，您会发现可以在成功上传时强制重定向。
然后，亚马逊会将以下内容传递给重定向处理程序：
bucket、key、etag这将为您提供跟踪上传资产所需的信息成功。直接上传可以让您两全其美。您获取跟踪信息并卸载您的带宽。
检查此链接了解详细信息：Amazon S3：使用 POST 基于浏览器的上传
Why pay for storage/bandwidth/backups/etc. when you can have somebody in the cloud handle it for you?
S3 (and other Cloud-based storage options) handle all the headaches for you. You get all the storage you need, a good distribution network (almost definitely better than you'd have on your own unless you're paying for a premium CDN), and backups.
Allowing users to upload directly to S3 takes even more of the bandwidth load off of you. I can see the tracking concerns, but S3 makes it pretty easy to handle that situation. If you look at the direct upload methods, you'll see that you can force a redirect on a successful upload.
Amazon will then pass the following to the redirect handler:
bucket,key,etagThat should give you what you need to track the uploaded asset after success. Direct uploads give you the best of both worlds. You get your tracking information and it unloads your bandwidth.
Check this link for details: Amazon S3: Browser-Based Uploads using POST
如果您在 Heroku 上托管 Rails 应用程序，原因很可能是 Heroku 不允许上传大于 4MB 的文件：
http://docs.heroku.com/s3#direct-upload
所以如果你愿意如果您的用户能够上传大文件，这是唯一的前进方向。
If you are hosting your Rails application on Heroku, the reason could very well be that Heroku doesn't allow file-uploads larger than 4MB:
http://docs.heroku.com/s3#direct-upload
So if you would like your users to be able to upload large files, this is the only way forward.
记住网络服务器是如何工作的。
除非您使用某种异步 Web 设置，就像您可以使用 Node.JS 或 Erlang 实现的那样（仅举 2 个示例），否则您的 Web 应用程序服务的每个上传请求都会占用整个进程或线程，而文件正在上传。正在上传。
想象一下您正在上传一个几兆字节大的文件。大多数互联网用户没有非常快的上行链路，因此您的网络服务器花费大量时间无所事事。虽然它什么也没做，但它无法满足任何其他请求。这意味着您的用户开始从服务器收到长时间的延迟和/或错误响应。这意味着他们开始使用其他网站来完成同样的事情。您始终可以运行更多进程和线程，但每个进程和线程都会消耗额外的内存，这最终意味着额外的美元。
通过直接上传到 S3，除了 Justin Niessner 提到的带宽节省和 Thomas Watson 提到的 Heroku 解决方法之外，您还可以让 Amazon 担心这个问题。您可以让单进程网络服务器有效地处理非常大的上传，因为它将实际功能转移给亚马逊。
所以，是的，设置起来更复杂，并且您必须处理回调来跟踪事物，但是如果您处理的不是非常小的文件（甚至在这些情况下）之外的任何内容，为什么要花更多的钱呢？
编辑：修正错别字
Remember how web servers work.
Unless you're using a sort of async web setup like you could achieve with Node.JS or Erlang (just 2 examples), then every upload request your web application serves ties up an entire process or thread while the file is being uploaded.
Imagine that you're uploading a file that's several megabytes large. Most internet users don't have tremendously fast uplinks, so your web server spends a lot of time doing nothing. While it's doing all of that nothing, it can't service any other requests. Which means your users start to get long delays and/or error responses from the server. Which means they start using some other website to get the same thing done. You can always have more processes and threads running, but each of those costs additional memory which eventually means additional $.
By uploading straight to S3, in addition to the bandwidth savings that Justin Niessner mentioned and the Heroku workaround that Thomas Watson mentioned, you let Amazon worry about that problem. You can have a single-process webserver effectively handle very large uploads, since it punts that actual functionality over to Amazon.
So yeah, it's more complicated to set up, and you have to handle the callbacks to track things, but if you deal with anything other than really small files (and even in those cases), why cost yourself more money?
Edit: fixing typos