有：
当PUB发送消息并且订阅者收到消息时，一切正常。
我的问题是两个订户之一停止工作。我希望PUB丢弃的所有消息都将入队，并在其活跃时发送给“死”订户。这不会发生。当订户重新连接到发布者时，该时间段内（从无效到有效）发送的所有消息都将丢失。
我正在尝试使用py0mq在python中进行编码。
Morover，我注意到，如果不是关闭python订阅者进程，而是尝试添加time.sleep（10），则PUB将消息排队，当订阅者唤醒时，将发送所有消息。如果进程关闭（CTRL + C）并重新启动，则不会发生这种情况。
但是，如果我尝试用发布者和订阅者之间的connect（）来反转bind（），则该应用程序将按我的要求工作。但是在这种情况下，存在很大的问题。我无法将更多订阅者与一个发布者关联，因为订阅者绑定在不同的端口上，而发布者只能在一个端口上进行连接。
我该如何解决？救命！
答案 0 :(得分：0)
“我的问题是...” 可解决的
ZeroMQ是一个智能的高性能信令/消息框架，旨在提供由可扩展形式通信原型组成的服务层。经过多年优化，以实现低延迟，高性能，几乎线性扩展以及易于使用的类似于人类行为的代理分布行为（例如一种 REQ -est，另一个将 REP -ly）。
这一切都是无经纪人的，也就是说，没有像“中间人”这样的东西可以重新发送消息，这种存储是在这样的时间跨框架基础结构分派的。服务中断。
这并不意味着，如果确实需要这种属性集，就不能在应用程序层上实现这种功能。定义所有要添加的功能（时间戳，消息存储，NACK / POSACK消息传递的索引计数器标志，用于请求丢失消息的专用双向协议等），将是设计者的职责。
因此，这部分是可解决的，但它既不消耗资源，也不增加基本框架的延迟，该基本框架使用Zen-of-Zero（Zero-of-Zero（Zero-of-Zero（zero-copy， ，零保修-如果存在损坏的零件，则不提供原始消息的确切副本，或者不提供任何内容，等等。）
在更新的ZeroMQ版本中甚至有一个直接对立的功能，即.setsockopt( ZMQ_CONFLATE, 1 )方法，该方法允许Context实例数据管理器丢弃来自单个交易对手的消息中除了最“新鲜”消息以外的所有消息。消息队列，因此，在下一个请求时，将传递最新消息，但不传递其他消息。这对于许多应用场景非常方便，在这些应用场景中，“旧”消息如果不立即传递便会丢失其值，并且CONFLATE模式不允许通过缓慢或不稳定的连接来移动它们，因此（间接地）确定了优先级仅分发世界上“最新”状态的消息（丢弃陈旧的消息还可以减少队列管理资源和工作负荷，不是吗？）。
如果ZeroMQ概念对您的设计工作来说是新手，请务必阅读Pieter HINTJENS的书，不仅是ZeroMQ框架本身的圣经，或者至少可以读一下{{{ 3}}部分。
Morover，我注意到...
是的，这将很好地工作，因为两个分布式Context实例都使用单独的线程，这些线程仍保持联系，即使Python解释器被指示去.sleep()（这样做，但不是协议专用数据泵双方的保持连接的信令工作）
如果我尝试将
.bind()转换为.connect()
哦，请确保它必须采取这种方式。试想一下BBC广播电台的情况-全世界所有的人都知道广播电台要听，而BBC电台的雇员都不会知道所有广播电台的听众，因此永远无法“建立”从BBC到所有人的联系，因为它们每个都有一个唯一的地址，这是广播公司的先验未知，因此广播公司无法从其侧面建立相同的基础结构）。 ZeroMQ PUB -故事的意思是一样的-您在广告“中央”地址以进行连接，每个想要和可以的人都会。反之亦然。
无论如何，在您将来的设计作品中享受ZeroMQ的世界。值得掌握。
答案 1 :(得分：0)
如果没有很多其他工作/代码，ZeroMQ将不支持此功能。
如果您确实需要一个发布者/订阅者消息系统，订阅者可以在没有任何损失的情况下来来去去，那么使用为提供该功能而构建的系统会容易得多。
一个这样的系统是kafka： https://kafka.apache.org/intro
如果您真的想使用zeromq，则最近启动了一个类似的项目。 https://github.com/zeromq/dafka