go - 什么是正确的ZMQ模式？

我正在尝试建立一个ZeroMQ模式，

可能有许多客户端连接到单个服务器端点

服务器会将传入的客户端任务分发给可用的工作程序(将映射到服务器上的内核数)

这些任务运行时间长(以小时计)，需要执行大量本地I / O

在每个任务执行(迭代)期间，客户端和服务器工作程序

之间会来回发送数据/消息(可能按[GB]的顺序)

客户端和服务器工作人员需要知道对等方是否存在故障/错误，以便他们可以正常地恢复(重试)或关闭并稍后尝试

基于以上所述，我认为ROUTER/DEALER模式将很有用。 PUB/SUB被丢弃，因为我需要知道对等方是否失败。
我尝试使用ROUTER/DEALER模式的各种组合，但是无法确保来自客户端的多个消息在一次迭代中到达同一工作线程。我知道我需要实现一个代理/转发器/设备，以将传入的消息路由到正确的收件人/处理者/工作者。但是我无法在代理中映射前端和后端套接字。我正在查看MajorDomo模式，但我想必须有一个更简单的代理模型，可以将消息路由到指定的工作程序。 (不真正涉足服务)
我正在寻找一些示例，如果对我可能缺少的内容有任何指导。 JFYI我正在尝试在Golang中构建它。

最佳答案

问:“正确的 ZMQ模式将是吗？”

如果一个人从未使用过ZeroMQ，可以在这里首先欣赏"ZeroMQ: Principles in less than Five Seconds" ，然后再深入，以了解更多细节

根据第1至5项下发布的所有要求的复杂组成，我敢说，
正确的不会使用标准的内置ZeroMQ平凡原始通信原型模式中的一个，而是要创建由(M + N + 1个热备用鲁棒性)组成的多层特定于应用程序的组合-足够吗？)(自我恢复能力？)信令消息传递基础结构，它满足了您当前的所有(并且可能会扩展为将来的任何一种)应用程序级别的需求，如此处所示，它是一种更简单的distributed-computing用例，但其中琐碎的事remote-SigKILL已实现。

是的，最好的办法是创建(并维护)自己的形式化信号，以使应用程序级别可以处理和交互—例如，检测未工作人员的心跳+允许恢复失败的工作正确检测到的故障(很可能发生了重新定位和/或重新安排，并且没有静态地预先映射相应的资源，但是在重新设置的时间点物理上最可行的故障-因此，更多遥测信令将有帮助您决定恢复此类失败的微型职位)。
ZeroMQ是适用于此类复杂信令和消息传递层次结构的绝佳框架，因此，系统架构师的想象力是此概念的唯一上限。
ZeroMQ将完成其余工作，并轻松轻松地完成所有艰苦的工作。

例子 ？
随时关注过去约6年的examples & discussions，它已经达到并有望帮助约1,300,000个StackOverflowers。

关于go - 什么是正确的ZMQ模式？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/63217758/