Java 如果没有流媒体/多部分，视频文件何时会太大而无法发送？

我目前正在使用Java和SpringMVC开发一个服务，用户可以上传视频文件。这些可以稍后通过我们的API检索

---

当视频文件通过我们的API加载时，我们只发送完整的文件，作为下载，没有流式传输或多部分传输。我知道这只在您达到某个文件大小之前有效。有人对最大文件大小有什么建议吗？也就是说，我们应该在多大的文件大小下开始使用视频流服务呢？

这实际上是一个相当复杂的问题，因为需要考虑多个因素。我将列出每种方法的优缺点，并最终提供一种替代解决方案

立即下载/上传整个文件：

->优点： 易于编程

->缺点： 一旦用户尝试上载一个2GB的文件，该文件将在保存到文件系统或您保存它的任何位置之前存储在服务器的内存中。您可以想象，如果有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请求 ->您可以降低应用程序的复杂性，因为流媒体、播放等内容不是由应用程序处理的，而是由视频服务器处理的