我正在使用 ZMQ 设计一个发布/订阅架构。我需要最大的可靠性和可扩展性，我有点迷失在所提供的各种可能性中。
目前，我有一组发布者和订阅者，由经纪人链接。代理是一个简单的转发设备，为发布者提供前端，为订阅者提供后端。
我需要处理代理崩溃或断开连接的情况，并提高整体可扩展性。
好的，所以我想添加多个代理，发布者将轮询代理发送消息，订阅者只需订阅所有这些代理。
然后我需要一种方法来检索可能的代理列表，所以我编写了一个名称服务，可以按需提供代理列表。发布者和订阅者询问该服务要连接到哪些代理。
我还写了一种“懒惰的海盗”（即一个接一个地尝试/重试）可靠的名称服务，以防主要名称服务失败。
我开始认为我设计错了，因为代码库的大小和复杂性不断增加。我迷失在 ZMQ 提供的可能性丛林中。
也许基于路由器/经销商的东西可以在这里使用？
任何建议都非常感谢！
不可能直接回答您的问题，因为它基于很多假设，其中许多可能是错误的。
你迷路了，因为你使用了错误的方法。将 0MQ 视为一种语言，一种您还不太了解的语言。如果你一开始就试图写“最大的可靠性和可扩展性”，你最终会得到哥斯拉的呕吐物。
所以：使用我在指南中使用的方法。从核心消息流的最小解决方案开始，并使其正常工作。仔细考虑要使用的正确类型的套接字。然后进行增量改进，每次都进行全面测试以确保您了解实际情况。随着您发现代码不断增长，请定期重构代码。继续，直到你有一个稳定的最小版本 1。不要一开始就以“最大”任何东西为目标。
最后，当您更好地理解问题时，从头开始，一次又一次地，通过几个步骤建立一个工作模型。
重复直到你完全控制了这个问题并学会了解决它的最佳方法。
似乎大部分复杂性源于试图在发生故障时使代理服务持续存在。在应用程序级别解决此问题可为您提供最高程度的灵活性，但如果您是从头开始，则需要付出最大的努力。
您可以在网络级别处理，而不是在应用程序级别处理此问题。像对待任何其他简单的网络服务一样对待您的代理，并使用 IP 故障转移机制（例如，起搏器/corosync、UCARP 等）在主服务不可用时将虚拟 IP 地址故障转移到辅助服务。
这大大简化了您的发布者和订阅者，因为您不需要名称服务。他们只需要知道单个虚拟 IP 地址。ZMQ 将负责在必要时重新连接到服务（即，当发生故障转移时）。