ZeroMQ：PUB/SUB 主题订阅便宜吗？

Question

问题：我有许多通过 HTTP 并行上传的文件（上传接收器）。我将它们临时存储在本地磁盘上。另一个进程（上传提交者）收到有关新上传的通知并进行特定处理（解析、提取元数据、上传到 S3 等）。上传处理完成后，我希望提交者通知上传接收者向远程上传者回复状态（提交是否正常或错误）。使用 ZeroMQ PUB/SUB 模式，会更好：

• 将所有上传接收线程订阅到单个主题。每个 接收者线程必须根据上传 ID 过滤消息或 找到属于它的通知。
• 为每个接收者线程订阅一个新主题，该主题代表 具体上传。假设主题是，这似乎更合理 ZeroMQ 很便宜，即不需要太多资源来保存它们，它们 可以自动过期。我预计新的上传量会达到几十 文件每秒，单次上传处理可能需要几个 秒，所以理论上我可以有多达数千个活动主题 在同一时间。而且我可能并不总是能够 由于各种故障模式退订。

Answer 1

^{初步通知：}
关于使用不同的ZeroMQ版本号：

虽然较新的版本可能使用 PUB 端主题过滤，但早期的 ZeroMQ 版本确实使用 SUB 端方法，这意味着所有 ( network ) 消息传输流量到所有 SUB-s 作为分配处理工作负载的可接受惩罚，否则需要在 PUB 端以尽可能低的延迟进行处理。

这对于在开放分布式系统关联中版本的同质性无法强制执行的情况很重要。

虽然您设计的架构似乎位于同一个 <localhost> 上，但性能影响仍然是非分布式的（集中的），并且可能仅涉及一些有限的延迟/优先级调整，如果在此用例期间出现整体瓶颈-缩放。

---

关于可扩展性范围 - 限制仍然比您的用例更远：

正如 Martin Sustrik（ZeroMQ 的共同父亲）详细介绍的那样，ZeroMQ 的设计预期规模可达几万：

(cit.:) " 高效订阅匹配
在 ZeroMQ 中，简单的尝试用于存储和匹配PUB/SUB 订阅。订阅机制适用于最多 10,000 个订阅，其中简单的 trie 运行良好。但是，有些用户使用了多达 150,000,000 个订阅。在这种情况下，需要更有效的数据结构。 "

Further details on design & scaling might be found interesting in this Martin's post.

---

最好的下一步？

一个公平的方法是模拟每个有问题的方法并对其进行基准测试，缩放到体外预期静态比例的 { 1.0x , 1.5x, 2.0x, 5.0x } 以获得定量支持的数据与正在审查的替代策略相关的实际开销、性能和延迟。

无论如何，Vovan，在分布式处理中享受智能信号/消息传递的世界。