我使用ZMQ设计了一个pub/sub架构。我需要最大的可靠性和可扩展性，并且在所提供的各种可能性中迷失了方向。ZMQ pub/sub可靠/可扩展设计
目前，我收到了一个由经纪人链接的发布者和订阅者。代理是一个简单的转发器设备，为发布者提供前端，为订阅者提供后端。
我需要处理代理程序崩溃或断开连接时的情况，并提高整体可伸缩性。
好了，所以我想添加多个经纪人，出版商将循环赛的经纪人将消息发送到，而用户只想订阅所有这些代理。
然后，我需要一种方法来获取可能的经纪人的名单，所以我写了一个名字服务，提供按需代理的列表。发布者和订阅者询问哪些经纪人要连接到这个服务。
我还写了一种“懒海盗”的（即尝试/重试一前一后）的情况下，可靠的名称服务的主名称服务下降。
我开始想，我设计它错误的，因为代码库是不停止的规模和复杂性增加。我迷失在ZMQ提供的各种可能性的丛林中。
也许路由器/经销商的基础可以在这里使用？
任何建议非常感谢！
这是不可能的，因为它是在这么多的假设，其中许多可能是错误的前提，直接回答你的问题。
由于使用了错误的方法，你会迷路。将0MQ看作是一种语言，你还不十分清楚。如果你试图写出“最大的可靠性和可扩展性”，那么你最终会得到哥斯拉的呕吐物。
所以：使用我在指南中使用的方法。从核心消息流的最小解决方案开始，并使其正常工作。仔细想想要使用的插座的种类。然后进行渐进式改进，每次完全测试以确保您了解实际发生的情况。定期重构代码，因为您发现它越来越多。继续，直到你有一个稳定的最低版本1.不要在开始时瞄准“最大”的任何东西。
最后，当你已经理解了问题的更好，再从头开始，再次，建立在几个步骤的工作模式。
重复，直到你完全主宰了这个问题，并学会了解决问题的最佳方法。
这似乎是最复杂的，从试图使代理服务坚持一个失败的情况下造成的。在应用程序级别解决这个问题可以提供最大程度的灵活性，但如果您从头开始，则需要最大的努力。
而不是在应用程序级别处理此问题，您可以改为在网络级别处理此问题。像处理任何其他简单的网络服务一样对待您的代理，并在主服务器不可用时使用IP故障切换机制（例如，起搏器/ corosync，UCARP等）将虚拟IP地址故障转移到辅助服务。
这极大地简化了您的发布商和订阅者，因为您不需要名称服务。他们只需要知道单个虚拟IP地址。 ZMQ将负责根据需要重新连接服务（即发生故障转移时）。