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