我目前正在使用 Java 和 Spring MVC 开发一项服务，用户可以在其中上传视频文件。稍后可以通过我们的 API 检索这些内容。
当通过我们的 API 加载视频文件时，我们只是完整地发送文件，作为下载，没有流式传输或多部分。我知道这只有在文件大小达到一定程度后才有效。有人对最大文件大小应该是多少有建议吗？ IE。我们应该开始使用视频流服务的文件大小是多少？
最佳答案
实际上，这是一个相当复杂的问题，因为需要考虑多种因素。我将列出每种方法的优缺点，并最终提供替代解决方案。
一次下载/上传整个文件:
->优点: 易于编程
->缺点: 一旦用户尝试上传 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请求 ->您可以降低应用程序的复杂性，因为流媒体、播放等内容不是由您的应用程序处理，而是由视频服务器处理。
关于java - 什么时候视频文件太大而无法在没有流式传输/分段的情况下发送？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/13489596/