我们正在向我们的 Web 应用程序添加一项功能，其中上传的文件（到应用服务器）由后台工作者（其他机器）处理。
应用程序的性质决定了这些文件会保留一段时间。在工作器上执行的代码知道文件何时变得无关紧要，并应在那时删除该文件。
我的直觉是要求我们的系统管理员使用 NFS 设置一个共享文件夹。任何 Web 服务器都可以将文件保存到 NFS，任何工作人员都可以拿起它来处理它。信号和编排工作通过共享 Redis 实例中的数据进行。
关于 NFS，我被告知：
通常，对于这种用例，我们会将所有上传请求路由到单个 Web 服务器。处理上传的服务器会将文件写入目录，例如 /data/shared/uploads，然后以只读方式同步到所有其他服务器。
听起来他们不喜欢 NFS。我问他们有什么问题。他们告诉我：
对于 NFS 或任何其他共享文件系统，问题始终是相同的 - 它会引入单点故障。不仅如此，它还会将所有服务器紧密耦合在一起。一台服务器的问题会影响其他服务器，这违背了负载平衡和解耦的目的。
我们目前的规模是拥有多个 Web 服务器和工作器，但数据库和 Redis 实例仍然只有一个。因此，我们已经存在紧密耦合的单点故障。
NFS 是否存在如此大的问题以至于上述论点成立？
答案1
NFS 背景
NFS 在工作时很好，但由于 NFS 是 31 年前的协议，因此存在许多问题。当然，有新版本可以修复一些问题，但也带来了其他问题。
主要问题是 NFS 是如何失败的。由于 NFS 客户端和服务器都是基于内核的，因此大多数 NFS 中断都会导致整个服务器重新启动。在soft模式下，任何 fs 操作（读取/写入/mkdir/...）都可能在中间失败，并且并非所有应用程序都能够处理这种情况。因此，NFS 很多时候都在hard模式下运行，这意味着这些操作可能会永远挂起（积累越来越多的挂起进程）。失败的原因包括短暂的临时网络中断、配置错误等。此外，它不仅不会失败，反而会减慢一切速度。
如果您出于任何原因选择 NFS，则应该在 TCP 模式下使用它，因为在 UDP 中超过 1 Gbit/s 且速度更快时很可能会发生数据损坏（手册页也会对此发出警告）。
其他选择
我的建议是 - 如果你真的不需要 NFS，就不要使用它。我不知道哪个顶级网站（FB、Google 等）会使用 NFS，因为通常对于 Web 来说，有更好的方法来实现这一点。
问题中提到的同步解决方案本身就很好，通常你可以忍受几秒钟的延迟。例如，你可以从上传文件的 Web 服务器将文件提供给上传者（上传者希望它是实时的）。这样他就可以立即看到它，而其他用户将在同步作业运行 1 分钟后看到它。
另一个解决方案是将文件存储在数据库中，如果需要，数据库本身可以进行复制。或者使用一些分布式存储，如 Amazon S3。
在您的示例中，您还可以将文件存储在受保护的文件夹中的 Web 服务器上，工作人员在需要处理这些文件时会通过 HTTP 获取这些文件。数据库表中包含有关文件及其位置的信息。
答案2
这取决于。
NFS 确实需要可靠的文件服务器，至少对于挂载来说是这样hard。另一方面，您可以指定soft挂载，然后远程文件系统将变得不可靠但无阻塞。与任何好的工具一样，您需要决定您想从它那里得到什么，以及它是否可以交付；这将告诉您是否适合使用它。
所以：当中央文件服务器不可用时，您希望您的应用程序发生什么？ 如果所有工作人员都看到共享空间的相同视图很重要，那么hard挂载是正确的选择：如果文件服务器宕机，那么一切应该停止工作。任何通过本地缓存来避免文件服务器宕机的解决方法都存在缓存不一致问题的风险。如果您采用这种方式，请注意，许多人都制造了（昂贵但出色的）高可用性、高性能 NFS 服务器；如果您的应用程序大获成功，您可以放弃其中一个来帮助正常运行时间和扩展。
另一方面，如果缓存一致性不是问题，并且工作人员看到 FS 的近似正确版本就足够了，那么您需要一个本地缓存的 FS。NFS 本身并不擅长这一点；他们的集中上传和定期同步到只读本地缓存方法就是一个例子。
另一方面，如果当中央 FS 停机时，工作进程可以继续运行，而看不到中央 FS，那么soft挂载可能正是您想要的。一旦 FS 恢复运行，您就可以重新启动工作进程。
NFS 并非天生就不稳定或不可靠。与任何好的工具一样，它能做到它所说的。根据我的经验，大多数问题都是因为人们在部署数据包之前没有仔细阅读数据包而引起的；大多数好的工具不会自动扩展来执行它们没有设计要做的事情，尽管你经常可以折磨它们来适应。弄清楚你需要什么，然后决定 NFS 是否适合你。