Networking 经典文件系统问题-目录上的并发远程处理

我有一个应用程序，它处理一个目录中的文件，并将它们与处理后的输出一起移动到另一个目录。没什么特别的。引入了一个有趣的要求：

通过允许多个远程实例在同一文件存储上工作，实现容错和处理吞吐量

其他考虑事项是，我们不能假设文件系统，因为我们同时支持Windows和NFS

当然，问题是，我如何确保不同的实例不尝试并处理相同的工作，从而可能破坏工作或降低吞吐量？文件锁定可能有问题，尤其是在网络共享中。我们可以使用更复杂的方法，例如简单的数据库或消息传递框架（la-JMS或类似），但整个集群需要容错。我们不能有一个数据库或消息传递提供程序，因为它引入了单点故障

我们已经实现了一个解决方案，该解决方案使用多播消息来自我发现处理实例，并选举一个分配工作的主管。有一个暂停，以防主管倒台，另一次选举发生。然而，我们的网络库还不是很成熟，消息的实现也很笨拙

然而，我的直觉告诉我有一个更简单的方法

---

想法？

我认为您可以安全地假设重命名操作在您关心的所有网络文件系统上都是原子操作。因此，如果您将大量工作安排为单个文件（或键入单个文件），那么让每个服务器首先列出包含新工作的目录，选择一个工作，然后让它将文件重命名为自己的服务器名称（例如，机器名或IP地址）。对于同时执行相同操作的其中一个实例，重命名将成功，因此它们应随后处理该工作。对于其他人，它将失败，因此他们应该从获得的列表中选择不同的文件

---

对于新工作的创建，假设目录创建（mkdir）是原子的，但文件创建不是原子的（对于文件创建，第二个编写器可能会覆盖现有文件）。因此，如果还有多个作品制作人，请为每一件作品创建一个新的目录。

这是一个有趣的想法，但我最初想知道你关于假设重命名是原子的说法是否正确。为什么可以这样认为？我们试图涵盖的案例是在NFS上运行；它的缓存在过去给我们带来了问题。如果我们同时有一个重命名a->b和a->c操作，那么是什么机制保护我们不同时拥有b和c呢？请看一下，它定义了（对于符合XNFS的实现，应该是所有实现）缓存应该如何工作。您有属性缓存、数据缓存和目录缓存。进行缓存允许您在响应系统调用时忽略或延迟某些操作。对于rename（），允许省略getattr RPC，但不允许省略或延迟重命名RPC，这反过来又要求在服务器上是原子的。NFSv3还指定NFSPROC_RENAME在客户端上是原子的；不确定这到底意味着什么。至于您的具体示例：这不可能发生，因为从RFC1094开始，重命名在服务器上必须是原子的。因此，当源文件消失时，一个客户端肯定会从服务器收到一条错误消息。