我目前正在使用 Java 和 Spring MVC 开发一项服务，用户可以在其中上传视频文件。这些可以稍后通过我们的 API 检索。
当视频文件通过我们的 API 加载时，我们只是完整地发送文件，作为下载，没有流式传输或多部分。我知道这仅在您达到特定文件大小之前有效。有人对最大文件大小有什么建议吗？即我们应该从哪个文件大小开始使用视频流服务？
问问题
851 次
1 回答
2
实际上，这是一个相当复杂的问题，因为需要考虑多个因素。我将列出每种方法的优缺点，并最终提供替代解决方案。
一次下载/上传整个文件：
->优点： 易于编程
->缺点： 一旦用户尝试上传一个 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 请求 -> 你降低了应用程序的复杂性，作为流、播放的东西，等不是由您的应用程序处理，而是由视频服务器处理。
于 2012-11-21T12:18:01.943 回答