应用程序的性质意味着这些文件会持续一段时间.在worker上执行的代码知道文件何时变得无关紧要,并且应该在那时删除该文件.
我的直觉是要求我们的系统管理员使用NFS设置共享文件夹.任何Web服务器都可以将文件保存到NFS中,任何工作人员都可以将其提取出来进行处理.信号与信号编排工作通过共享Redis实例中的数据进行.
关于NFS,有人告诉我：
Typically,for this kind of use case,we route all upload requests to
a single web server. The server that handles uploads will write the
files to a directory,say /data/shared/uploads which is then
synchronized in a read-only fashion to all other servers.
听起来他们不喜欢NFS.我问问题是什么.有人告诉我：
In regards to NFS or any other shared file system,the problem is
always the same – it introduces a single point of failure. Not only
that,it also tightly couples all servers together. Problems with one
server can affect the others,which defeats the purpose of load
balancing and de-coupling.
我们目前处于多个Web服务器和工作者的规模,但仍然是单个DB和Redis实例.因此,我们已经存在与我们紧密耦合的单点故障.
NFS是否有问题以至于上述参数有效？
解决方法
NFS工作正常,但有很多问题,因为NFS是31年前的协议.当然有新版本,它修复了一些东西,但带来了其他问题.
主要问题是NFS如何失败.由于NFS客户端和服务器都是基于内核的,因此大多数NFS中断都会导致整个服务器重新启动.在软模式下,任何fs操作(读/写/ mkdir / …)都可能在某些事情中失败,并非所有应用程序都能够处理.因此,很多时候NFS在硬模式下运行,这意味着这些操作可以永久挂起(累积越来越多的挂起进程).失败的原因是例如短暂的临时网络中断,配置错误等.而不是失败它可以减慢一切.
如果您出于任何原因选择NFS,则应在TCP模式下使用它,如在超过1 Gbit / s的UDP中,并且很可能发生更快的数据损坏(手册页也警告它).
其他选择
我建议 – 如果你真的不需要NFS,不要使用它.我不知道TOP网站(FB,谷歌……)中有哪些网站通常会使用NFS,有更好的方法来实现这一目标.
问题中提到的同步解决方案本身很好,通常你可以忍受几秒钟的延迟.例如,您可以从上传它的网络服务器向上传者(希望它上线)提供文件.因此他立即看到它,其他用户将在同步作业运行1分钟后看到它.
另一种解决方案是将文件存储在数据库中,如果需要,可以复制数据库.或者使用像Amazon S3这样的分布式存储.
在您的示例中,您还可以将文件存储在受保护文件夹中的Web服务器上,并且工作人员在希望处理它们时将通过HTTP获取它们.将有数据库表,其中包含有关文件及其位置的信息.
