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