2012-04-13 42 views
4

我试图设计ZeroMQ架构N前端服务器和M后端工作者,前端服务器将发送任务到后端服务器。前端服务器确实有关于后端服务器的信息,但后端服务器不知道前端服务器。我有两种类型的任务,一种类型应该使用轮循机制,并且只转到一个后端服务器,而其他类型应该被转播到所有后端服务器。我不想有一个中央经纪人,因为这将是单点失败。ZeroMQ有选择的酒吧/分模式?

对于第一种类型的任务,请求/响应模式似乎是正确的,而第二种模式则是发布者/订户模式。但是如何组合这两者呢?如果我想将消息发送到全部或只是一个随机后端服务器,是否有任何模式可以让我在发送时选择?

我提出的解决方案只是使用发布者/订阅者,并将消息与后端服务器标识相加,并在发送给所有人时使用一些魔术值。但是,这会造成很多不必要的流量。有更干净更有效的方法吗?

+1

你可以使用两套插座?所以每个后端都会在REP套接字和SUB套接字上侦听。 – 2012-04-13 16:56:33

+0

@ThomasK:我认为这就是他说他现在正在做的事情。 OP想知道是否有某种模式将功能组合到单个套接字中? – jdi 2012-04-13 16:57:25

+0

@jdi:不,他说他目前只使用一套套接字,并将后端ID放入消息中。这完全不同。 – 2012-04-13 17:00:55

回答

1

我可能会使用pub sub message envelopes - 如果你使用UDP上的pub/sub广播,我不相信它会产生不必要的网络流量,但它会产生额外的处理,但是像大多数这些东西是一种折衷在设计优雅和表现之间。 ØMQ倾向于首先考虑绩效的路线,但我倾向于衡量它,并使用量化的绩效结果来决定这是否可以接受。

对我来说,优雅的解决方案是使用两套套接字,因为这本身就是通过系统区分工作流 - 而使用单套接字以非常非ØMQ的方式进行混合,这些应该不同于考虑到未来的变化和动态/不稳定的系统。

1

我认为唯一的可能性是使用DEALER-ROUTER组合。经销商在前端,ROUTER在后端。每个前端服务器应该为每个后端服务器(用于广播)包含一个DEALER套接字,并且一个连接到所有后端服务器上的一个DEALER套接字用于循环的事情。现在让我解释一下为什么。

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

希望这有助于;-)