ZeroMQ 消息模式

Question

我需要创建一个分布式系统，其中我有以下节点类型：

1. 客户端 [1-n 个实例]
2. 服务器 [1-n 个实例]
3. 代理 [1 个实例 - 基本上是任何服务器的转发器]
4. 云服务器 [1 个实例 - 基本上是任何代理的转发器]

[Client] -> [Cloud Server] -> [Proxy -> Server] - 分布式设置

[客户端 -> 服务器] - 本地设置

[代理和服务器在同一个节点或网络上运行]

客户端一旦与服务器在同一网络上，也应该允许直接在服务器上连接，而不是通过云服务器/代理。

服务器可以连接多个客户端，但除了响应客户端的请求外，它还可以为客户端发布消息。 Server/Cloud Server需要通过id来区分clients节点，随时知道是否连接/断开。

据我了解，服务器应提供一个 REQ/REP 端点，以允许与代理/本地客户端以及 PUB 端点交换消息，其中代理/本地客户端将订阅来自服务器的任何通知.

关于代理，看起来我必须有两个端点；一个在内部，两个端点在外部。基本上，我将有一个 ROUTER/DEALER 端点用于 REQ/REP 和 XPUB/XSUB 端点，用于针对远程客户端的 PUB/SUB 通知。但我担心的是，外面的代理总是有一个节点要回复，只有一个节点订阅通知，这就是云服务器。

关于云服务器，看起来我将拥有类似于我上面描述的代理的东西，但与上面的代理不同，我看到 ROUTER/DEALER 和 XPUB/XSUB 填补了账单。

显然我是 ZeroMQ 的新手，它提供了很多东西。我想暂时专注于需要什么，非常感谢您的帮助。

Answer 1

嗯，ZeroMQ 是一个很好的设计和构建系统的工具，但我首先要推荐给任何人，无论是热心的年轻新手，还是经验丰富的动手经验丰富的计算机科学老手， “忘记将所有模式都视为即插即用的解决方案。”

在构建了“一些”分布式、低延迟系统后，会有许多相似之处，迟早会亲自见面。

ZeroMQ 的一些用于形式可扩展通信模式的内置原语具有“几乎”匹配的行为，但除了内置的循环步进器之外，还需要其他排序，其他一些是“几乎”匹配的，但有一些特定的步骤顺序要求，在分布式代理世界的现实中无法保证。简单地说，有很多时候，当一个人感觉“几乎”完成时，但是一些微小（或隐藏的）细节会（隐藏）调用“休斯顿，我们有问题......”

如何专注于需要的东西？

忘记以经典的顺序方式思考。

分布式系统比普通的SEQ-工具编程的单一系统要复杂几个数量级。除了主要的设计目标之外，还有很多东西在生产中可能和将出错。

重新访问设计规则并仔细检查新规则：
1. 扩展方面：定义隐藏需求 -（节点、消息大小、流量峰值）
2. 阻塞状态：定义额外的信号需求（以允许摆脱所有潜在的分布式状态死/活锁定）
3. 生存能力需求 - 分布式系统将满足丢失消息、丢失节点
4. 不连贯协议版本 - 适用于没有人可以保证分布式系统中强制统一的情况
5. 自卫需求 - 以防远程节点开始一些恐慌/有缺陷的信令/消息通道泛滥（OOP as-is 不提供自卫工具，并且无法限制远程请求者注入调用，构建了一套保护工具，用于内部自我修复保护，以防对象服务被外部调用者过度使用或误用，从而加强您的设计免受此类错误/恶意操作模式的影响，正常的、典型的 OOP 模型方法通常无法保护自己免受 ) 的影响。

---

最好的下一步：

现实世界的系统架构必须包含更多的“线路”

如果您的代码努力进入生产状态，而不是仅仅停留在学术界的示例，则必须做更多的工作，以便为敌对的现实世界生产环境提供生存能力。

这样做的绝佳视角以及使用 ZeroMQ 进行现实设计的好读物是 Pieter HINTJEN 的书“Code Connected, Vol.1” (may check my posts on ZeroMQ to find the book's direct pdf-link) .

ZeroMQ 的共同之父 Martin SUSTRIK 的另一篇精彩文章来自 low-level truths about the ZeroMQ implementation details & scale-ability

---

_{结语：另外，REQ/REP 原始行为通信模式在现实世界中本身是危险的，因为它可以使通信进程对在发生传输（无论出于何种原因）丢失了一个数据包，并且“钟摆”式消息传递变得不完整并永远锁定。}