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

Question

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

• 将所有上传接收者线程订阅到单个主题。每 接收者线程必须根据上传ID或过滤消息 找到属于它的通知的东西。
• 将每个接收者线程订阅到代表的新主题 特别上传。假设主题是这个似乎更合理 在ZeroMQ中便宜，即保持他们和他们不需要太多资源 可以自动过期。我希望新的上传内容可以达到几十个 每秒文件，单个上传处理可能需要多达几个 从理论上说，我可以有多达几千个主题 在同一时刻。我也许并不总是能够 由于各种故障模式而取消订阅。

Answer 1

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

虽然更新的版本可能会使用 PUB - 主题过滤，但早期的ZeroMQ版本确实使用了 SUB - 侧方法，这意味着所有（网络）消息传输流量都转到所有SUB - s作为分配处理工作负载的可接受的惩罚，否则需要在PUB上以尽可能低的延迟处理侧的。

这对于在开放式分布式系统关联中的情况很重要，版本的同质性是不可执行的。

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

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

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

  

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

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

最佳下一步？

一种公平的方法是模拟每个受质疑的方法并对它们进行基准测试，在体外缩放到预期静态标度的{1.0x，1.5x，2.0x，5.0x}，以获得有关数据的定量支持与正在审查的替代战略相关的实际间接费用，业绩和延迟。

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