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

Question

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

1. 可以有许多客户端连接到单个服务器端点
2. 服务器将传入的客户端任务分配给可用的工作人员（将映射到服务器上的核心数）
3. 这些任务运行时间很长（以小时为单位）并且需要执行大量本地 I/O
4. 在每个任务执行（迭代）期间，将有数据/消息（可能按[GB]s 顺序）在客户端和服务器工作者之间来回发送
5. 客户端和服务器工作人员需要知道对等端是否存在故障/错误，以便他们可以正常恢复（重试）或关闭并稍后尝试

基于以上所述，我认为该ROUTER/DEALER模式会很有用。PUB/SUB被丢弃，因为我需要知道对等方是否失败。

我尝试使用该模式的各种组合，ROUTER/DEALER但我无法确保来自客户端的多条消息在一次迭代中到达同一个工作人员。我知道我需要实现一个代理/转发器/设备，将传入消息路由到正确的接收者/处理程序/工作人员。但我无法在代理中映射前端和后端套接字。我正在研究 MajorDomo 模式，但我想必须有一个更简单的代理模型，可以将消息路由到分配的工作人员。（没有真正进入服务）

我正在寻找一些示例，如果对我可能遗漏的内容有任何或任何指导。我正在尝试在 Golang 中构建它。

标签： gozeromqpyzmq

Answer 1

问：“什么是正确的ZMQ 模式？”

基于项目 1 - 5 下发布的所有要求的复杂组合，我敢说，正确的做法不是使用标准的、内置的、ZeroMQ 琐碎原始通信原型模式中的一个，而是创建（M + N + 1 热备用足够强大？）（自弹性？）信令消息基础架构的多层应用程序特定组合，涵盖您当前的所有（并且可能为任何未来的应用程序扩展）级要求，就像这里描述的一种更简单的分布式计算用例，但实现了一个微不足道的远程 SigKILL。

是的，最好的办法是创建（并维护）你自己的正式信号，应用程序级别可以处理和交互——比如检测死工人的心跳+允许重新恢复这些失败的工作正确检测到的故障（很可能重新定位和/或重新安排发生，并且相应的资源不是静态预先映射的，而是在重新启动的时刻在物理上最可行的地方 - 所以更多的遥测信号将有所帮助您决定是否恢复此类失败的微型作业）。

ZeroMQ 是一个极好的框架，适合这种复杂的信令和消息传递层次结构，因此您的系统架构师的想象力是这个概念的唯一上限。

ZeroMQ 将承担其余的工作，轻松轻松地完成所有艰苦的工作。