我们正在向我们的networking应用程序添加一个function，其中上传的文件（到应用程序服务器）由后台工作人员（其他机器）处理。
应用程序的性质意味着这些文件在一定的时间内存在。 在worker上执行的代码知道文件何时变得不相关，并且应该在那个时候删除文件。
我的直觉是要求我们的系统pipe理员使用NFSbuild立共享文件夹。 任何Web服务器都可以将文件保存到NFS中，任何工作人员都可以将其保存起来。 信令和编排工作通过共享Redis实例中的数据进行。
关于NFS，我被告知：
通常，对于这种用例，我们将所有上传请求路由到单个Web服务器。 处理上传的服务器将把文件写入一个目录，比如/ data / shared / uploads，然后以只读的方式将其同步到所有其他服务器。
听起来他们不喜欢NFS。 我问问题是什么。 有人告诉我：
对于NFS或任何其他共享文件系统，问题总是相同的 – 它引入了单点故障。 不仅如此，它还将所有服务器紧密结合在一起。 一台服务器出现的问题会影响到其他服务器，从而破坏了负载平衡和解耦的目的。
目前，我们有多个Web服务器和工作人员，但仍然是单一的DB和Redis实例。 所以我们已经有了一些我们紧密联系在一起的失败点。
NFS是如此的有问题以至于上面的参数是有效的？
NFS背景
NFS虽然可以工作，但是有很多问题，因为NFS是31岁的协议。 当然有新的版本，可以解决一些问题，但会带来其他问题。
主要问题是NFS如何失败。 由于NFS客户端和服务器都是基于内核的，所以大多数NFS中断导致整个服务器重新启动。 在soft模式下，任何fs操作（读/写/ mkdir / …）都可能在某些事情中失败，并不是所有的应用程序都能够处理这个操作。 由于这个原因，很多时候NFS运行在hard模式下，这意味着这些操作可以永久挂起（积累越来越多的挂起进程）。 出现故障的原因是短暂的networking中断，configuration错误等。 而不是失败，它可以放慢一切。
如果您出于某种原因selectNFS，则应该在TCP模式下使用它，就像在1 Gbit / s以上的UDP一样，并且很可能会发生更快的数据损坏（手册页也会对此进行警告）。
其他选项
我会build议 – 如果你真的不需要NFS，不要使用它。 我不知道任何从TOP网站（FB，Google，…），这将通常用于networking使用NFS有更好的方法来实现这一点。
问题中提到的同步解决scheme很好，通常你可以忍受几秒钟的延迟。 例如，您可以将文件从上传的networking服务器上传到上传者（希望网站上的人员可以上线）。 所以他立即看到它，其他用户在同步作业运行1分钟后会看到它。
另一个解决scheme是将文件存储在数据库中，如果需要，可以复制它本身。 或者使用一些分布式存储，如Amazon S3。
在您的示例中，您还可以将文件存储在受保护的文件夹中的Web服务器上，并且工作人员在想要处理它们时可以通过HTTP获取它们。 将有数据库表与关于文件和他们的位置的信息。
这取决于。
NFS确实需要一个可靠的文件服务器，至less在hard上是这样的。 另一方面，您可以指定soft安装，然后远程文件系统变得不可靠，但不阻塞。 像任何好的工具一样，你需要决定你想要什么，以及它是否可以交付; 这会告诉你是否适合使用。
那么： 当中央文件服务器不可用时，您想要在应用程序中发生什么？ 如果所有工作人员都看到共享空间的相同视图是很重要的，那么hard安装是正确的方法：如果文件服务器closures，所有内容都应停止工作。 任何caching本地caching文件服务器的解决方法都有可能导致caching不一致的问题。 如果采取这种方式，请注意，不同的人制作（昂贵，但是优秀的）高可用性，高性能的NFS服务器; 如果您的应用程序取得了巨大的成功，您可以将其中的一个放入其中以帮助正常运行时间和缩放比例。
另一方面，如果caching一致性不是问题，并且工作人员看到一个近似正确的FS版本就足够了，那么你就需要一个本地caching的FS。 NFS本身并不擅长; 他们的中央上传和定期同步到只读本地caching的方法就是一个例子。
另一方面，如果工作人员在下降的时候可以继续看不到中央财政司司长的话，那么soft安装可能就是你想要的。 一旦你得到了FS备份，你可以重新启动工人。
NFS本身并不稳定或不可靠。 就像任何好的工具一样，它会做它所要做的事情。 我的经历中的大部分问题都是由于人们在部署之前不仔细阅读数据包而造成的。 大多数好的工具不会自动扩展到做他们没有devise的事情，尽pipe通常你可以折磨他们以适应。 弄清楚你需要什么，并决定NFS是否适合你。