与“简单”UDP及其多播实现相比，ZMQ的性能（我是指发送所有消息时的延迟，许多消息到多个接收器的最大扇出率）是什么？
假设我有一个静态“发送者”，它必须向许多“接收者”发送消息 . 具有简单TCP传输的PUB / SUB模式似乎非常适合处理此类任务 - ZMQ在没有我们努力的情况下做了很多事情，一个ZMQ套接字足以处理甚至多个连接 .
但是，我担心的是：ZMQ可以在后台创建许多TCP套接字，即使我们没有“看到”那个 . 这可能会造成延迟 . 但是，如果我创建“通用”UDP套接字并将使用多播传输所有消息 - 那么将只有一个套接字（多播），因此我认为延迟问题将得到解决 . 说实话，我想在TCP上使用ZMQ和PUB / SUB . 我的担忧有效吗？
2 回答
我认为你不能以这种方式比较它们 . 这取决于对你来说重要的事情 .
TCP提供可靠性，您可以通过在发送时设置阻止/重试选项来确定丢失是否比延迟更重要 .
mcast可以节省网络带宽，尤其是当您的网络有多个网段/路由器时 .
zeromq中的其他选项
使用
zmq_proxy分割/共享tcp连接的负载使用带pgm / epgm的pub / sub，它只是一个多播的层（我用这个）
使用新的收音机菜单模式（此时您有有限的订阅选项）
http://api.zeromq.org/4-2:zmq-udp
在幕后，"source"和"destination"识别（简化）了一个TCP "socket"，因此每个对等方的每个方向都会有一个套接字（有关如何设置/识别套接字的更完整描述） ，见here和here） . 这与ZMQ无关，ZMQ将设置与TCP所需的套接字完全相同的套接字 . 如果您选择使用多播，则可以对此进行优化，但ZMQ不会在后台使用多播为您优化此项，PUB / SUB see here除外 .
根据James Harvey的回答，ZMQ已经添加了对UDP的支持，所以你可以使用它，如果你不需要或不需要TCP的开销，但根据你所说的，你想继续使用TCP，这很可能大多数应用程序的更好选择（即我们在设计应用程序时经常无意识地期望TCP的可靠性，如果我们知道我们正在做什么，则应该只选择UDP） .
鉴于此，您应该假设ZMQ与TCP一样高效，使其能够与低级套接字管理相关 . 在您的情况下，使用PUB / SUB，您已经在使用多播 . 我觉得你很好 .