7年前关闭。
我目前正在使用Java和Spring MVC开发一项服务，用户可以在其中上传视频文件。这些可以稍后通过我们的API检索。
当通过我们的API加载视频文件时，我们只是完整地发送文件（作为下载），就没有流式传输或多部分传输。我了解这只有在达到特定文件大小后才有效。是否有人建议最大文件大小为多少？即我们应该从哪个文件大小开始使用视频流服务？
最佳答案
实际上，这是一个相当复杂的问题，因为要考虑多个因素。我将列出每种方法的优缺点，并最终提供替代解决方案。
一次下载/上传整个文件：
->优点：
易于编程
->缺点：
一旦用户尝试上载一个2 GB的文件，该文件将被保存在服务器的内存中，然后再保存到文件系统或保存到文件系统的任何位置。您可以想象，如果有100个用户这样做，您的服务器将崩溃。您可以在Servlet容器级别上限制请求的大小，但随后将限制用户。另一种方法是也将其限制在应用程序级别，但是仍然限制了用户。几年前，tomcat的默认上传大小为2097152（2兆）。不确定现在有多少，但是即使将其增大到10mb或100mb，也遇到了我描述的问题：当多个用户尝试上传大文件时，它们就会存储在内存中。
使用流媒体下载/上传文件
->优点：
在保存之前，流式传输不需要将所有内容都显示在内存中。这是一种更优雅的方法，并且在所有方面绝对比发送所有内容更好。另外，您可能会绕过公司环境中的大多数问题，例如发送大文件，防火墙，Servlet容器限制等。
另外，如果您使用进度条实现流传输，则向系统发送大文件的用户不会认为它崩溃了，这将大大改善您的用户体验。
->缺点：
并不是很多，但是实施起来却有点困难。使用像commons的IOUtils这样的库，在实现流式解决方案时应该没有任何问题。
如您所见，在大多数情况下，不管文件大小如何，流化内容的效果都更好，但是，如果仍然要使用整个文件解决方案，则可以在该区域中使用10MB的限制。这取决于您希望视频的大小。
需要注意的一件事是，如果您还希望使用流技术来允许用户查看视频内容，则不必要地给servlet容器增加了不应做的事情：流视频。 Servlet容器用于回答http请求，并且根据设计是由池使用的，这些池可重用那些预期寿命较短的http请求的线程。在某一点上可能会变得很明显，即HTTP Servlet容器不适合同时流式传输视频和服务HTTP请求。一种可能的解决方案是您的用户使用您的api将文件上传到视频服务器，然后使用该视频服务器（甚至可能位于其他位置）将视频流式传输回用户。您可以看看这个：http：//www.red5.org/
您可以从此设置中得到的是：
->您减轻了HTTP服务器上的负载，并且将其用于实现以下目的：服务HTTP请求
->您可以减少应用程序的复杂性，因为流，播放等内容不是由您的应用程序处理，而是由视频服务器处理。