是否有针对 NFS 的有效稳定性论证？

Question

我们正在向网络应用程序添加一项功能，其中上传的文件（到应用程序服务器）由后台工作人员（其他机器）处理。

应用程序的性质意味着这些文件会保留一段时间。在工作线程上执行的代码知道文件何时变得不相关，并且应该在那时删除该文件。

我的直觉是要求我们的系统管理员使用 NFS 设置共享文件夹。任何网络服务器都可以将文件保存到 NFS 中，任何工作人员都可以拿起它来处理它。信号发送和编排工作通过共享 Redis 实例中的数据进行。

关于 NFS，我被告知：

通常，对于这种用例，我们将所有上传请求路由到单个 Web 服务器。处理上传的服务器会将文件写入一个目录，例如 /data/shared/uploads，然后以只读方式同步到所有其他服务器。

听起来他们不喜欢 NFS。我问有什么问题。有人告诉我：

对于 NFS 或任何其他共享文件系统，问题总是相同的 - 它引入了单点故障。不仅如此，它还将所有服务器紧密耦合在一起。一台服务器的问题可能会影响其他服务器，这违背了负载平衡和解耦的目的。

我们目前的规模是拥有多个 Web 服务器和工作人员，但仍然是单个数据库和 Redis 实例。因此，我们已经存在紧密耦合的单点故障。

NFS 的问题是否如此严重以至于上述论点都有效？

Answer 1

NFS背景

NFS 虽然可以工作，但也有很多问题，因为 NFS 协议已经有 31 年历史了。当然，有新版本，它修复了一些问题，但也带来了其他问题。

主要问题是 NFS 如何失败。由于 NFS 客户端和服务器都是基于内核的，因此大多数 NFS 中断都会导致整个服务器重新启动。在soft模式下，任何 fs 操作（读/写/mkdir/...）都可能在某些事情中间失败，并且并非所有应用程序都能够处理该问题。因此，很多时候 NFS 都在hard模式下运行，这意味着这些操作可能会永远挂起（累积越来越多的挂起进程）。失败的原因包括短暂的临时网络中断、配置错误等。而且它不会失败，反而会减慢一切。

如果出于任何原因选择 NFS，则应该在 TCP 模式下使用它，因为在超过 1 Gbit/s 的 UDP 中，很可能会发生更快的数据损坏（手册页也对此发出警告）。

其他选项

我的建议是——如果你真的不需要 NFS，就不要使用它。我不知道顶级网站（FB、Google 等）中是否有任何网站会使用 NFS，因为通常网络有更好的方法来实现这一点。

问题本身提到的同步解决方案很好，通常您可以忍受几秒钟的延迟。例如，您可以从上传文件的网络服务器将文件提供给上传者（希望文件处于活动状态）。因此，当同步作业运行时，他会立即看到它，其他用户也会在 1 分钟后看到它。

另一种解决方案是将文件存储在数据库中，如果需要，数据库本身可以复制。或者使用一些分布式存储，例如 Amazon S3。

在您的示例中，您还可以将文件存储在网络服务器上受保护的文件夹中，工作人员在想要处理它们时可以通过 HTTP 获取它们。将有一个数据库表，其中包含有关文件及其位置的信息。