并行 Req/Rep 通过 Pub/Sub
Parallel Req/Rep via Pub/Sub
我有多个服务器，在任何时候，只有一个将是领导者，可以响应请求，所有其他服务器只是丢弃请求。问题是客户端不知道哪个服务器是领导者。
我已经尝试在客户端上使用 pub 套接字来处理并行请求，但是我无法为响应计算出正确的语义。关于如何让服务器响应特定客户端。
我尝试过的一个 hacky 解决方案是在客户端上有一个子套接字来在所有服务器上发布套接字，领导者通过发布带有过滤器的消息来响应，这样它只发送到客户端。
但是我无法通过这种方式收到任何响应，服务器认为它发送了消息并且客户端认为它订阅了 "" 但随后没有收到任何东西...
所以我想知道是否有更合适的方法来做到这一点？我认为 dealer/router 发送给特定客户端可能会起作用，但我不确定该怎么做。
基本上我正在尝试做一个标准 Req/Rep 但是对所有节点并行执行请求，而不是循环。
更新：通过在 pub 请求中发送经销商的 routing id，使远程调用幂等（仅在重复尝试时返回预先计算的结果），然后通过路由器将结果发回，在接收方进行消息过滤后，它现在可以工作了。
Q : " is (there) a more proper way of doing this? "
是的。
开始应用马斯洛锤法则:
“When the only tool you have is a hammer, every problem begins to resemble a nail.”
换句话说，不要尝试用（一个）锤子解决所有问题。 PUB/SUB-archetype 旨在服务于 those-and-only-those multi-party Formal-Communications-Pattern 原型，其中许多 SUB-scribe to .recv() 一些 PUB-lisher(s) .send()-广播消息，但仅此而已。
类似地，REQ/REP-archetype 的定义和实现是为了服务 one-and-only-one multi-party 分布式 Formal-Communications-Pattern（和显然不会满足任何 use-case，它有任何其他甚至略有不同的要求）。
用户通常需要一些特殊的 non-trivial 功能，这些功能显然不是上述琐碎 Formal-Communications-Pattern 原型原语的一部分（那些 ready-made 块，在 ZeroMQ 工具箱中可用).
架构师/设计师的职责是定义、分析和实施任何更复杂的 user-specific distributed-behaviour 定义（协议）并实施它，通常使用分层组合ready-made ZeroMQ 原语。
如果有疑问，请拿 sheet 纸和铅笔，画出操场上的一小群孩子，然后画出他们的 "shouts"、他们的 "listening"、他们的 "silence"、"waiting"和"doubts"，他们或多或少的"replies"，他们不被朋友投票的"voting"和"anger"，他们在太阳和他们的 "persistence" 不要让其他人轮到他们，让他们在释放迄今为止令人愉快的摇摆自己之后坐在 "swing" 上。
所有这些都是找到（protocol-orchestrated）控制水平和行动自由水平的正确组合的一部分。
我们为您的特定 use-case.
提供了新的 distributed-behaviour、tailor-made
找到 ready-made 原始工具来匹配和实现任何 user-specific 用例的概率无限接近于零（当然，除非是自己的，user-specific use-case要求与原始原型的所有要求相匹配，但这不是 user-specific use-case，而是针对相同情况已经实现的原型的 re-use，这是 ZeroMQ 之父预见的, 不是吗？)
再次欢迎来到Zen-of-Zero的艺术。
可能
喜欢阅读
this and this and this
我有多个服务器，在任何时候，只有一个将是领导者，可以响应请求，所有其他服务器只是丢弃请求。问题是客户端不知道哪个服务器是领导者。
我已经尝试在客户端上使用 pub 套接字来处理并行请求，但是我无法为响应计算出正确的语义。关于如何让服务器响应特定客户端。
我尝试过的一个 hacky 解决方案是在客户端上有一个子套接字来在所有服务器上发布套接字，领导者通过发布带有过滤器的消息来响应，这样它只发送到客户端。
但是我无法通过这种方式收到任何响应，服务器认为它发送了消息并且客户端认为它订阅了 "" 但随后没有收到任何东西...
所以我想知道是否有更合适的方法来做到这一点？我认为 dealer/router 发送给特定客户端可能会起作用，但我不确定该怎么做。
基本上我正在尝试做一个标准 Req/Rep 但是对所有节点并行执行请求，而不是循环。
更新：通过在 pub 请求中发送经销商的 routing id，使远程调用幂等（仅在重复尝试时返回预先计算的结果），然后通过路由器将结果发回，在接收方进行消息过滤后，它现在可以工作了。
Q : " is (there) a more proper way of doing this? "
是的。
开始应用马斯洛锤法则:
“When the only tool you have is a hammer, every problem begins to resemble a nail.”
换句话说，不要尝试用（一个）锤子解决所有问题。 PUB/SUB-archetype 旨在服务于 those-and-only-those multi-party Formal-Communications-Pattern 原型，其中许多 SUB-scribe to .recv() 一些 PUB-lisher(s) .send()-广播消息，但仅此而已。
类似地，REQ/REP-archetype 的定义和实现是为了服务 one-and-only-one multi-party 分布式 Formal-Communications-Pattern（和显然不会满足任何 use-case，它有任何其他甚至略有不同的要求）。
用户通常需要一些特殊的 non-trivial 功能，这些功能显然不是上述琐碎 Formal-Communications-Pattern 原型原语的一部分（那些 ready-made 块，在 ZeroMQ 工具箱中可用).
架构师/设计师的职责是定义、分析和实施任何更复杂的 user-specific distributed-behaviour 定义（协议）并实施它，通常使用分层组合ready-made ZeroMQ 原语。
如果有疑问，请拿 sheet 纸和铅笔，画出操场上的一小群孩子，然后画出他们的 "shouts"、他们的 "listening"、他们的 "silence"、"waiting"和"doubts"，他们或多或少的"replies"，他们不被朋友投票的"voting"和"anger"，他们在太阳和他们的 "persistence" 不要让其他人轮到他们，让他们在释放迄今为止令人愉快的摇摆自己之后坐在 "swing" 上。
所有这些都是找到（protocol-orchestrated）控制水平和行动自由水平的正确组合的一部分。
我们为您的特定 use-case.
提供了新的 distributed-behaviour、tailor-made找到 ready-made 原始工具来匹配和实现任何 user-specific 用例的概率无限接近于零（当然，除非是自己的，user-specific use-case要求与原始原型的所有要求相匹配，但这不是 user-specific use-case，而是针对相同情况已经实现的原型的 re-use，这是 ZeroMQ 之父预见的, 不是吗？)
再次欢迎来到Zen-of-Zero的艺术。
可能
喜欢阅读
this and this and this