ZMQ 模式；发送然后接收答案

【问题标题】：ZMQ patterns; send then receiveZMQ 模式；发送然后接收
【发布时间】：2014-12-16 18:34:36
【问题描述】：

我一直在阅读有关 zmq 设计模式的信息，但似乎没有发现它适合我的需要。

1. Box A sends info (json) to Box B and C; B and C gets different info from each other  
2. Boxes B and C do some work based on info received from Box A  
3. After finishing the work, Boxes B and C sends result back to Box A

转发设备（http://learning-0mq-with-pyzmq.readthedocs.org/en/latest/pyzmq/devices/forwarder.html）可以实现第1步和第2步，但不能实现第3步，对吗？

有什么模式可以用来实现吗？
它是简单的请求/回复模式吗？
如果是这样，是否有一个集中的请求/回复模式，以便框 A 不选择框 B 和 C，而是框 A 将信息发送到中心，它知道发送到框 B 和 C 并将结果发送回框 A？

【问题讨论】：

标签： zeromq pyzmq

【解决方案1】：

这看起来像是指南中的一个非常基本的负载平衡模式。 A 是控制器，将成为 ROUTER，而工作人员 B 和 C 是 DEALERS。消息传递很简单；经销商向控制器发送初始消息说“我准备好了”。然后控制器将工作分配给准备好的工作人员。

此拓扑与 Jason 的答案相反。您选择哪一个取决于您希望如何扩展您的应用程序。当控制器分发工作时，它真的应该交给准备好处理它的工人。使用保证的负载平衡模式。

【讨论】：

【解决方案2】：

这是一个非常基本的 DEALER/ROUTER 模式。

DEALER 套接字是循环的，这意味着它将向框 B 发送一个请求，然后向框 C 的下一个请求，然后向框 B 的下一个请求，等等。如果您想保留任何工作直到工作人员完成，您只需要知道当前可用工人的数量。

在框 B 和框 C 上，使用 ROUTER 套接字（如果您的用例足够简单，则使用 REP 套接字，但这会限制您的选择）。收到工作，处理，发回，等待更多工作。

the guide中有很多这样的例子，我推荐你阅读。

【讨论】：

这种拓扑的主要问题出现在应用程序扩展时。如果工作比工人多，则应该将工作分配给能够处理它的工人。使用这种模式，无论分配的工作人员是否忙碌以及工作包的相对大小，工作都会以循环方式分配给工作人员。这可能会导致瓶颈。负载平衡模式避免了这些瓶颈。
你说得对，自从我第一次阅读指南以来已经快一年了，我对这个特定模式的记忆刚刚被翻转，反转套接字是更健壮的模式（至少在一般情况下）案例）...但是我们两个答案的主要建议保持不变：阅读指南，它解决了所有这样的基本用例。