nnt*_*ona 4 scalability file-upload
我想将用户的数百万个音频项目上传到我的服务器。当前的应用程序旨在提供内容,对其进行转码,最后通过 ftp 发送到存储服务器。我想知道:
应用程序服务器在扩展到更多服务器(以承载 Web 应用程序负载)后是否可以承担用户的巨大任务,例如评论、上传、转码?
如果上述问题的答案是肯定的,那么这是正确且最好的方法吗?因为一个好的架构是将转码发送到存储服务器等待完成工作并向应用服务器发送响应,但同时它具有更多的复杂性和不安全性。
此类网站的常用方法是什么?
如果我将上传和转码作业发送到存储服务器,它在长期可扩展性方面是否与企业存储技术兼容?
5-当前应用程序基于PHP。是否可以将 tmp 文件夹移动到另一台服务器以克服上传过载?
感谢您对 tmp 文件夹问题 5 的回答。我的意思是 Apache 中的 tmp 文件夹。我知道在移动到最终存储目的地(例如:存储服务器或任何解决方案)之前所有上传的文件都存储在apache的tmp文件夹中。我想知道这是否是 apache 的规则,所有上传的文件都应该首先位于应用程序服务器中,那么我如何控制、扩展和重定向这种大量的存储负载到临时存储或服务器?我的意思是服务器或存储解决方案作为 appche 的 tmp 文件夹,在发送到最终存储位置之前只是上传文件的访客。我研究和设计了有关数据库扩展、存储、负载平衡、内存缓存等的所有内容,但这是我未解决的问题之一。用户新到达主服务器的文件将在缩放架构中发生在哪里?对此的常见解决方案是什么?(在一盒解决方案中,所有文件都将临时存储在 appche 的 tmp 目录中,但对于大量内容和扩展系统?)。问候
| 归档时间: |
|
| 查看次数: |
2488 次 |
| 最近记录: |