与 UDP 多播相比的 ZMQ 性能

Question

与“简单”UDP 及其多播实现相比，ZMQ 的性能（我的意思是发送所有消息时的延迟，许多消息到许多接收者的最大扇出率）是什么？

假设，我有一个静态的“发送者”，它必须向许多“接收者”发送消息。带有简单 TCP 传输的 PUB/SUB 模式似乎很适合处理这样的任务 - ZMQ 无需我们的努力就能完成很多事情，一个 ZMQ 套接字足以处理甚至大量的连接。

但是，我担心的是：ZMQ 可以在后台创建许多 TCP 套接字，即使我们没有“看到”。这可能会产生延迟。但是，如果我创建“通用”UDP 套接字并使用多播传输我的所有消息 - 将只有一个套接字（多播），所以我认为延迟问题将得到解决。老实说，我想留在 TCP 上的 ZMQ 和 PUB/SUB。我的担忧有效吗？

Answer 1

我认为您无法真正以这种方式比较它们。这取决于对您来说什么是重要的。

• TCP 提供可靠性，作为发送方，您可以通过在发送时设置阻止/重试选项来选择丢失是否比延迟更重要。
• mcast 可节省网络带宽，尤其是当您的网络有多个网段/路由器时。

zeromq 中的其他选项

• 使用zmq_proxy's 来拆分/共享 tcp 连接的负载
• 将 pub/sub 与 pgm/epgm 一起使用，这只是多播的一个层（我使用这个）
• 使用新的收音机碟形图案（您的订阅选项有限）
  • http://api.zeromq.org/4-2:zmq-udp

Answer 2

在幕后，TCP“套接字”由“源”和“目标”标识（简化） - 因此您与每个对等方通信的每个方向都会有一个套接字（更完整的描述有关如何设置/识别套接字的信息，请参阅 here 和 here）。这与 ZMQ 无关，ZMQ 将设置与 TCP 所需数量完全相同的套接字。如果您选择使用多播，则可以对此进行优化，但 ZMQ 不会通过在后台使用多播为您进行优化，除了 PUB/SUB see here。

根据 James Harvey 的回答，ZMQ 增加了对 UDP 的支持，因此如果您不需要或不想要 TCP 的开销，您可以使用它，但根据您所说的，您希望继续使用 TCP，对于大多数应用程序来说，这可能是更好的选择（即，我们在设计应用程序时经常会无意识地期望 TCP 的可靠性，并且只有在我们知道自己在做什么的情况下才应该选择 UDP）。

鉴于此，您应该假设 ZMQ 在低级套接字管理方面与 TCP 一样高效。在您的情况下，使用 PUB/SUB，您已经在使用多播。我觉得你很好。