zeromq - 了解 ZeroMQ：如何将文件从多个源发送到单个接收器？

Question

我有一堆不断生成文件的服务器。这些文件需要发送到一个中心位置。这些文件永远不会超过 50MB。我计划使用 ZeroMQ 来发送这些文件（封装在消息中），以便不会同时在中心位置写入文件（例如，使用 scp 进行传输会在目标上启动许多磁盘写入进程）。

我可以看到一些使用 ZeroMQ 的方法：

1. 在生产者上使用 REQ 套接字，在消费者上使用单个 REP 套接字。这可能会奏效，但我认为它会使速度较慢的生产者挨饿，因为没有公平的排队。此外，如果 REP 套接字不可用，我不确定 REQ 套接字是否会丢弃消息。
2. 在生产者上使用 PUSH 套接字，在消费者上使用 PULL 套接字。这对消费者有公平的排队，文档说 PUSH 套接字永远不会丢弃消息。但是，它完全可靠吗？

我的可靠性要求是：

1. 消息（在我的案例文件中）不应该丢失。所以我想以这样一种方式构建它，即消费者收到的每条消息都会向生产者确认。
2. 来自特定生产者的消息应该按照它们产生的顺序被接收。
3. 生产者可以来来去去，他们应该抵制消费者在一段时间内不可用。

什么样的套接字适合这种应用？任何指向我应该查看哪种 zmq 模式的指针都会很棒。

Answer 1

REQ/REP 方法似乎是该任务的最佳选择，因为消息数量少且需要高可靠性。

1. 以允许您找出创建顺序的方式将文件存储在每个生产者上（文件名中的时间或数据库中的文件索引）
2. 每个生产者都应该选择最旧的文件，将其发送到套接字并等待 ACK 回复。确认后应删除文件（或标记为已交付）。
3. 消费者应从套接字读取文件内容，将其刷新到磁盘并随后发送 ACK 消息。
4. 生产者只有在收到前一个文件的确认后才应该发送下一个文件。

这可能有效，但是我在这里看到了一个主要问题：几个生产者将淹没消费者的网络接口，即使他们没有在消费者上插入磁盘或生成进程。在任何使用生产者发起的文件传输的设计中，这都应该是一个问题。PUSH/PULL 套接字也会有同样的问题。

还有一点需要注意：ZeroMQ 消息在内存中缓冲，直到收到整个消息。因此，每个发送 50MB 文件的 20 个生产者在峰值时需要 1GB RAM。

作为替代方案，我建议仅向生产者发送文件名，并按顺序提取文件。