4

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

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

我想出的解决方案只是使用发布者/订阅者，并在消息前面加上后端服务器 ID 和一些魔法值（如果它是针对所有人的）。但是，这会产生很多不必要的流量。有没有更清洁、更有效的方法呢？

4

2 回答 2

1

我认为唯一的可能性是使用 DEALER-ROUTER 组合。前端是DEALER，后端是ROUTER。每个前端服务器都应为每个后端服务器（用于广播）包含一个 DEALER 套接字，并且顶部的一个 DEALER 套接字同时连接到所有后端服务器以用于循环事物。现在让我解释一下原因。

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

希望这可以帮助 ;-）

于 2013-01-15T00:48:34.953 回答
1

我可能会使用pub sub 消息信封- 如果您通过 UDP 使用 pub/sub 广播，我不相信它会产生不必要的网络流量，但它会导致额外的处理，但是就像大多数这些事情一样，这是一个权衡设计优雅和性能。ØMQ倾向于先走性能路线，但我更倾向于衡量它并使用量化的性能结果来决定这是否可以接受。

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

于 2012-05-15T11:56:30.157 回答