适合我的场景的 ZeroMQ 架构是什么？

Question

我有一个服务 A，每隔一段时间就需要向服务集群 B1、B2 ... BN 发送一条消息。然后，所有这些服务都需要可靠地接收该消息，并向 A 发送回确认。 A 收到来自集群 B 的所有服务的确认后，需要向另一个服务集群 C1、C2 ... CN 发送消息.

正确的 ZeroMQ 模式是什么？我应该选择哪些套接字？

这似乎是一种

ROUTER-DEALER

的情况，其中 A 是

ROUTER

，Bs 和 Cs 是

DEALER

-s。我需要传输这些消息以获得递送保证，所以不确定我是否可以在这里做

PUB-SUB

。

Answer 1

问：
“正确的 ZeroMQ 模式是什么，我应该选择什么套接字？”

我敢透露一个观点，自 v.2.0 以来，在过去 15（？并计数......）年中使用 ZeroMQ 收集的。

在设计现实世界的应用程序时，不存在这样的“选择”。 ZeroMQ 内置的可扩展正式通信原型模式是智能、快速、健壮的，但请不要认为它们是“完整的”，只选择其中一种并准备好进入现场实践。

Pieter Hintjens 和 Martin Sustrik 都明确指出，只要有可能，什么是值得保证的（而其他则不是）。

因此，我们有一个保证，ZeroMQ 将交付原始版本的位精确副本（或者根本不交付任何内容，并且在这两个主要角落状态之间不交付任何内容）。

因此，我们必须在给定的内置原语“之上”设计我们需要的任何和所有逻辑，因为这样我们：

(a) 准确设计我们确实需要的东西，并且

(b) 不要过度设计任何我们不需要的东西

典型的系统由消息传递（传输）层和信令层组成，其中操作 ZeroMQ 原型原语以传递（或不传递）具有应用程序相关内容的消息，在信令层中我们使用单独构建的 ZeroMQ 链路，用于向应用程序发送信号心跳级，用于我们的应用程序级已发送或丢失的传输消息的 ACK/NACK，用于我们的应用程序级自我诊断和性能评估需求。

因此，我们的努力产生了一个相当新的生态系统的概念，它是根据 ZeroMQ 原始原型构建的，从应用程序级别来看，它们一起构成了一个智能消息传递/信令元平面。

这种元平面可以有意使用许多成对的

PUSH-PULL

-s 来实现简单、通用的节点互连（那里和后面）传输层，并且除此之外，还可以使用几个通用的和特定于服务的

PUB-SUB

-s根据需要，使用任何其他模式，对于信令层，分为多个

Context()

实例，以便微调性能并隔离优先级和资源容量。

从来没有“一刀切”的 ZeroMQ 模式，我们喜欢智能、超快速的内置原始原型，适合设计足够复杂的消息传递和信令元平面，以最好地满足我们的所有需求在我们的应用程序中。