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