我不确定这样的设计问题是否适合这里，但根据 https://meta.stackexchange.com/questions/41469/is-there-a-stack-overflow-for-design-questions，它并不是完全禁止的。
在我的系统中，我有许多节点可以下载大文件并处理它们。每个文件都由一个唯一的标签标识。基于该标签，节点可以构建正确的URL并下载相应的文件。文件会随着时间的推移而变化（通常），因此节点必须不断下载它们并保持处理。
在我当前的架构中，我为不同的节点分配了不同的标签集（不重叠）。但这不是一个理想的解决方案，因为文件的大小会发生变化，因此工作并不总是均匀分布的。此外，处理容错也更加复杂，因为我需要为每个处理节点进行热备份以进行故障转移。
我认为一种可能的解决方案是有一个标签队列（FIFO），每个节点将从head获取一个标签，进行处理，然后将其返回到队列的末尾。此解决方案解决了均匀工作分配的问题，但再次引入了另一个容错问题。如果节点在处理过程中失败，那么我们将丢失标签，这在这个特定的系统中是不可接受的。现在，我们可以有一个进程来监视队列的内容（如果它具有所有标签）。
但我正在寻找一个更优雅、更合理的解决方案，可以解决均匀的工作分配和容错问题，而不会在这个特定系统中过于复杂。有什么想法吗？
我会继续使用队列方法，但通过确认机制来增加容错能力，例如您可以在 Amazon SQS（请参阅此处）或 RabbitMQ（请参阅此处，在"消息确认"下）中找到的机制。
这个想法是，当使用者从队列中提取项目时，该项目不会从队列中删除。只有在使用者确认成功处理该项目后，才会将其从队列中删除。如果使用者拉取一个项目并且在规定的时间内未确认，则该消息将在队列中再次可用，并且不同的使用者将处理该消息。
请注意，这可能会造成同一消息被处理两次的情况。如果您处理操作是幂等的（即执行两次操作会产生与执行一次相同的结果），这是可以的，但如果不是，则需要添加自定义保护来处理这种情况。
简而言之，如果您担心可靠性，请使用可用的可靠队列服务之一，例如上面提到的服务。