ZeroMQ选择性发布/子模式？

Question

我正在尝试为 N 前端服务器和 M 后端工作者设计ZeroMQ架构，前端服务器会将任务发送到后端那些。前端服务器确实有关于后端服务器的信息，但后端服务器不了解前端服务器。我有两种类型的任务，一种类型应该使用循环，只去一个后端服务器，而其他类型应该广播到所有后端服务器。我不想拥有一个中央经纪人，因为这将是单点故障。

对于第一类任务，请求/响应模式似乎是正确的，而对于第二类，它将是发布者/订阅者模式。但是这两种模式结合起来怎么样？如果我想向所有或仅一个随机后端服务器发送消息，是否有任何模式允许我在发送时选择？

我提出的解决方案就是使用发布者/订阅者，并使用后端服务器ID预先添加消息，如果它发送给所有人，则会提供一些魔术值。但是，这会产生很多不必要的流量。是否有更清洁，更有效的方法呢？

Answer 1

我可能会使用pub sub message envelopes - 如果您通过UDP使用发布/订阅广播我不相信它会产生不必要的网络流量，但它会产生额外的处理，但是像大多数这些东西一样它是一个设计优雅与性能之间的权衡。 ØMQ倾向于首先采用性能路线，但我倾向于测量它并使用量化的性能结果来确定这是否可以接受。

对我来说，优雅的解决方案是使用两组套接字，因为这本身就是通过系统区分工作流程 - 而使用单个套接字是以非ØMQ方式混合的东西，这些应该是不同的允许对于未来的变化和动态/不稳定的系统。

Answer 2

我认为唯一的可能性是使用DEALER-ROUTER组合。前端的经销商，后端的路由器。每个前端服务器应包含一个用于每个后端服务器的DEALER套接字（用于广播）和一个顶层的DEALER套接字，用于循环连接到所有后端服务器。现在让我解释原因。

1. 在这种严重的情况下你无法真正使用PUB-SUB，因为该模式可以非常轻松地以静默方式丢弃消息，而不会排队。所以实际上发布到PUB的消息可以到达SUB的任何子集，因为它在后台连接（dis）。因此，您需要通过循环分配给所有后台服务器的DEALER套接字来模拟广播。如果后端部分未连接，它将对消息进行排队，但要注意HWM。唯一的最终解决方案是使用心跳来了解后端何时死亡并破坏分配给它的套接字。
2. 后台的ROUTER套接字是一种逻辑解决方案，因为您可以异步接受任意数量的请求，因为它是一个ROUTER套接字，将响应发送回请求任务的前端非常容易。通过在后台服务器中使用单个ROUTER，您可以使它们甚至不知道发生广播的事实，他们将所有内容视为对它们的直接请求。广播纯粹是前端的事情。此解决方案的唯一问题可能是，如果您的后端服务器速度不够快，所有前端服务器可能会将其填满，以便它到达HWM并开始丢弃软件包。您可以通过让更多线程/进程处理来自ROUTER套接字的消息来防止这种情况。 zmq_proxy（）是这个东西的有用函数。

希望这会有所帮助; - ）