我正在尝试为N个前端服务器和M个后端工作者设计ZeroMQ架构，前端服务器将任务发送到后端服务器 . 前端服务器确实有关于后端服务器的信息，但后端服务器不了解前端服务器 . 我有两种类型的任务，一种类型应该使用循环，只去一个后端服务器，而其他类型应该广播到所有后端服务器 . 我不想拥有一个中央经纪人，因为这将是单点故障 .
对于第一类任务，请求/响应模式似乎是正确的，而对于第二类，它将是发布者/订阅者模式 . 但是这两种模式结合起来怎么样？如果我想向所有或仅一个随机后端服务器发送消息，是否有任何模式允许我在发送时选择？
我提出的解决方案就是使用发布者/订阅者并使用后端服务器ID预先添加消息，如果它发送给所有人，则会提供一些魔术值 . 但是，这会产生很多不必要的流量 . 有更干净，更有效的方法吗？
2 回答
我可能会使用pub sub message envelopes - 如果你认为它会产生不必要的网络流量，但它会产生额外的处理，但是像大多数这些东西一样，它倾向于测量它并使用量化的性能结果来决定这是否可以接受 .
对我来说，优雅的解决方案是使用两组套接字，因为这本身就是通过系统区分工作流程 - 而使用单个套接字以非ØMQ方式混合，这些应该是不同的，以便将来进行更改和动态/不稳定的系统 .
我认为唯一的可能性是使用DEALER-ROUTER组合 . 前端的经销商，后端的路由器 . 每个前端服务器应包含一个用于每个后端服务器的DEALER套接字（用于广播）和一个顶层的DEALER套接字，用于循环连接到所有后端服务器 . 现在让我解释一下原因 .
您可以在后台连接't really use PUB-SUB in such a critical case, because that pattern can very easily drop messages silently, it does not queue. So in fact the message posted to PUB can arrive to any subset of SUB since it'（dis） . 因此，您需要通过循环分配给所有后台服务器的DEALER套接字来模拟广播 . 如果后端部分未连接，它将对消息进行排队，但要注意HWM . 唯一的最终解决方案是使用心跳来了解后端何时死机并破坏分配给它的套接字 .
后台的ROUTER套接字是一种逻辑解决方案，因为您可以异步接受任意数量的请求，因为它是一个ROUTER套接字，将响应发送回请求任务的前端非常容易 . 通过在后台服务器中使用单个ROUTER，您可以使它们甚至不知道发生广播的事实，他们将所有内容视为对它们的直接请求 . 广播纯粹是前端的事情 . 此解决方案的唯一问题可能是，如果您的后端服务器速度不够快，所有前端服务器可能会填满它，以便它到达HWM并开始丢弃软件包 . 您可以通过让更多线程/进程处理来自ROUTER套接字的消息来防止这种情况 . zmq_proxy（）是这个东西的一个有用的函数 .
希望这可以帮助 ;-）