我对了解在Rails应用程序中处理大文件上传的不同方法，2-5GB文件感兴趣。
我明白为了传输这么大的文件，需要将它分成较小的部分。我已经做了一些研究，以下是我目前的进展。
我曾在几个网站上遇到这个问题，使用了你上面介绍的一些技巧以及其他一些未提到的技巧。好消息是，实际上允许大规模上传文件是相当现实的。
很多取决于你上传文件后实际要做什么...你需要对文件进行更多处理，就越接近你的服务器。如果你需要对上传文件进行即时处理，你可能需要使用纯Rails解决方案。如果不需要进行任何处理，或者它不是时间关键性的，则可以开始考虑“混合”解决方案...
信不信由你，我实际上使用mod_porter非常成功。 Mod_porter使Apache完成应用程序通常执行的一系列任务。它有助于在上传期间不占用线程和大量内存。它会生成一个本地文件，便于处理。如果您注意处理上传的文件的方式(考虑流)，即使对于传统上相当昂贵的操作，整个过程也可以使用非常少的内存。这种方法只需要非常少的实际设置才能使应用程序正常工作，并且无需实际修改您的代码，但它确实需要特定的环境( Apache服务器)以及配置的能力。
我也使用jQuery-File-Upload非常成功，它支持分块和可恢复上传等好的功能。如果没有像mod_porter这样的东西，即使在上传期间，它仍然可以占用整个执行线程，但如果正确执行，它应该对内存有不错的表现。这也会生成一个“接近”的文件，因此易于处理。这种方法需要调整您的视图层来实现，并且不能在所有浏览器中使用。
您提到FTP和BitTorrent作为可能的选项。这些选项并不像您想象的那样糟糕，因为您仍然可以将文件获取得非常接近服务器。它们甚至不是相互排斥的，这很好，因为（正如您指出的那样）它们需要另一个可能不存在于上传计算机上的客户端。基本上，这是通过设置一个区域将它们导出，并且该区域对您的应用程序可见来实现的。然后，如果您需要进行任何处理，您可以运行cron作业（或任何其他方法）监视上传位置以触发服务器的处理方法。这不能让您获得以上方法所能提供的即时响应，但是您可以将间隔设置得足够小以获得非常接近的时间。这种方法唯一的真正优势是所使用的协议更适合传输大型文件，但从我的经验来看，额外的客户端需求和分段过程通常会超过任何好处。http://aws.amazon.com/articles/1434
如果你使用CarrierWave
我也想列出一些选项，以帮助其他寻找真实解决方案的人。
我使用Rails 6和Ruby 2.7，这个应用程序的主要目的是创建类似于Google Drive的环境，使用户可以上传图像和视频，然后再次处理它们以获得高质量。
显然，我们尝试了使用Sidekiq后台作业进行本地处理，但在大型上传（如1GB及以上）期间，它会变得不可承受。
我们尝试了tuts.io，但我个人认为它不像Jquery文件上传那样容易设置。
因此，我们尝试使用AWS...按照下面列出的步骤进行移动，它就像一个魅力一样工作....直接从浏览器上传到S3。
Acceleration，React库显示上传进度，一旦上传完成，Rails回调API会再次验证其在S3 BUCKET中的存在，如mybucket/user_id/file_uploaded_slug，然后通过简单的提示消息向用户确认。