file-upload - 大规模上传的服务器负载和可扩展性

Question

我想将用户的数百万个音频项目上传到我的服务器。当前的应用程序旨在提供内容，对它们进行转码，最后通过 ftp 发送到存储服务器。我想知道:

应用服务器是否可以在扩展到更多服务器(承载Web应用程序负载)后承担用户评论、上传、转码等庞大任务？

如果上述问题的答案是肯定的，这是正确的和最好的方法吗？因为一个好的架构是将转码发送到存储服务器等待完成工作并向应用服务器发送响应，但同时它具有更多的复杂性和不安全性。

这类网站的常用方法是什么？

如果我将上传和转码作业发送到存储服务器，它是否在长期可扩展性方面与企业存储技术兼容？

5- 当前的应用程序基于 PHP。是否可以将 tmp 文件夹移动到另一台服务器以克服上传过载？

感谢您回答 tmp 文件夹问题 5。我的意思是 Apache 中的 tmp 文件夹。我知道在移动到最终存储目的地(例如:存储服务器或任何解决方案)之前所有上传的文件都存储在 apache 的 tmp 文件夹中。我想知道这是否是 apache 的规则，所有上传的文件都应该首先位于应用程序服务器中，那么我如何控制、扩展并将这种大量存储负载重定向到临时存储或服务器？我的意思是作为 appche 的 tmp 文件夹的服务器或存储解决方案在发送到最终存储位置之前只是上传文件的访客。我已经研究和设计了有关扩展数据库、存储、负载平衡、内存缓存等的所有内容，但这是我 Unresolved 问题之一。用户新到达主服务器的文件将在缩放架构中发生在哪里？对此的常见解决方案是什么？ (在一个盒子解决方案中，所有文件在 appche 的 tmp 目录中都是临时的，但对于大量内容和缩放系统？)。
问候

Answer 1

由于我觉得我不能回答这个(我想添加评论，但我的文字太长了)，一些想法:

如果你正在创建一个如此大的系统(听起来)，你应该进行一些性能测试，看看有多少并发连接/上传，......无论你的架构可以处理什么。正如我常说的:如果你不知道:“不，它不能”。

我认为处理重负载的最佳方法(这是:大量上传，需要来自应用服务器的大量阻塞线程(-> 这意味着，我不会使用应用服务器来处理文件上传)。执行所有重载异步操作(转码)(例如将上传的文件排队，然后处理它们)。在任何情况下，应用程序服务器都不应该等待转码系统的响应-> 只需告诉用户，他的文件将被处理并发送完成后给他一条消息(或其他任何东西)。你可以使用像 gearman 这样的东西。

我会搜索现有架构，这些架构也必须处理大量上传/转换(例如 flickr)，只需转到 Slideshare 并搜索“flickr”或“可扩展的网络架构”

我不太明白这一点——但我会根据服务器的任务(例如应用服务器、数据库服务器、传输服务器、存储等)使用服务器——每台服务器都应该做，他能做的最好。

当你说tmp文件夹时，我恐怕不知道你在说什么。

祝你好运