在扩展的 PUB-SUB 拓扑中，如何防止发布者发送的消息丢失（由于 pub sub 连接延迟），而不使用 sleep 方法？答案

【问题标题】：How to prevent the loss of messages sent by publisher (due to delay in pub sub connection), without using sleep method,in extended PUB-SUB topology?在扩展的 PUB-SUB 拓扑中，如何防止发布者发送的消息丢失（由于 pub sub 连接延迟），而不使用 sleep 方法？
【发布时间】：2018-04-11 07:26:45
【问题描述】：

所以我正在使用 c++ 在 ZeroMQ 中实现扩展的 PUB/SUB 拓扑。

我有 2 个发布者、1 个中介（转发器/代理）和 2 个订阅者。

我在发布者中调用 send() 之前调用了 sleep(1) 方法。

但根据文档，这不是一种将发布者与订阅者同步的优雅方式。文档提供了一个解决方案，我们在 SUB 和 @987654329 中创建 REQ 和 REP 套接字@ 分别。但如果有多个发布者和订阅者，这会很困难。

请建议如何防止扩展 PUB-SUB 拓扑中的消息丢失。

【问题讨论】：

你想达到什么目的？您是否希望从所有发布者向所有订阅者保证交付？如果订阅速度变慢会怎样？如果出版商死了怎么办？中间人死了怎么办？ ZeroMQ 指南有一整章关于可靠的发布/订阅：zguide.zeromq.org/php:chapter5。
@jens 。目的是确保发布者发出的所有消息都到达订阅者。为此，我在发送发布者之前调用 sleep(1)，并在发布者之前运行订阅者。但我正在寻找比使用 sleep() 更好的解决方案。假设我的发布者和中介没有死，订阅者也没有减速。
如果您只是担心订阅连接阶段的消息丢失，您最好使用显式的同步形式。这需要从订阅者到发布者的反向通道，例如zguide.zeromq.org/page:all#Node-Coordination。如果您希望在所有情况下都有保证的交付，您需要在 pub/sub 之上定义一个协议，例如在需要时重新发送消息。这可能类似于 TCP 所做的。该指南也应该包含这方面的示例。或者你扩展你的转发代理来处理订阅，把它变成一个持久代理。
如果您编辑问题以包含更多信息可能会更好，例如你不关心慢速订阅者、连接丢失、死亡中间体等。我猜你指的是由于连接和订阅延迟导致的消息丢失，但你应该将其添加到问题中。

标签： c++ zeromq publish-subscribe distributed-system

【解决方案1】：

是的，
_{已知的 ZeroMQ Zen-of-Zero 并不保证所有消息都能通过，}

这意味着人们可以忽略这部分，因为它是系统设计的主要特征。

是，
REQ/REP或其他更复杂的“augmented”——简单原始可扩展正式通信原型模式的组合built-ins，可以帮助处理内置的设计属性，但所有这些步骤主要是应用程序设计人员定义、分析和实现的责任。不要指望任何魔杖，但所有这些都是共同的方面，已经find a lot of examples discussed here。

【讨论】：

是的，已知的 ZeroMQ Zen-of-Zero 并不保证所有消息都能通过，

是的，
_{已知的 ZeroMQ Zen-of-Zero 并不保证所有消息都能通过，}