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

Question

我正在尝试构建一个 ZeroMQ 模式，其中，

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

服务器会将传入的客户端任务分配给可用的工作人员(将映射到服务器上的核心数)

这些任务运行时间很长(以小时为单位)并且需要执行大量本地 I/O

在每个任务执行(迭代)期间，将有数据/消息(可能按 [GB] s 的顺序)在客户端和服务器 worker 之间来回发送

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

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

Answer 1

Q : "What would be the right ZMQ Pattern?"

基于项目 1 - 5 下发布的所有要求的复杂组成，我敢说，权利不会使用一个标准的、内置的、ZeroMQ 简单的原始通信原型(prototype)模式，而是创建一个(M + N + 1 热备用足够健壮的多层应用程序特定组合？ )(自弹性？)信令消息基础设施，涵盖您当前的所有(并且可能为任何 future 的应用程序级别的需求扩展)，就像这里描述的更简单的方式 distributed-computing用例，但实现了一个微不足道的远程 SigKILL。

是的，最好的办法是创建(并维护)你自己的正式信号，应用程序级别可以处理和交互——比如检测死 worker 的心跳+允许重新恢复这些失败的工作正确检测到的故障(很可能重新定位和/或重新安排发生，并且相应的资源不是静态预先映射的，而是在重新启动的时刻在物理上最可行的地方 - 所以更多的遥测信号将有所帮助您决定是否恢复此类失败的微型作业)。
ZeroMQ 是一个非常棒的框架，适合这种复杂的信令和消息传递层次结构，因此您的系统架构师的想象力是这个概念的唯一上限。
ZeroMQ 将承担其余的工作，轻松轻松地完成所有艰苦的工作。