通过 Pub/Sub 并行请求/代表

问题描述 投票:0回答:1

我有多个服务器,在任何时候,只有一个服务器是领导者,可以响应请求,所有其他服务器都会删除请求。问题是客户端不知道哪个服务器是领导者。

我尝试在客户端上使用 pub 套接字来发出并行请求,但是我无法计算出响应的正确语义。关于如何让服务器响应特定客户端。

我尝试过的一个 hacky 解决方案是在客户端上有一个子套接字来在所有服务器上发布套接字,领导者通过发布带有过滤器的消息来响应,以便它只发送到客户端。

但是我无法通过这种方式收到任何响应,服务器认为它发送了消息并且客户端相信它订阅了

""
但然后没有收到任何内容...

所以我想知道是否有更合适的方法来做到这一点?我认为潜在的经销商/路由器可以发送给特定的客户,但我不确定如何做到这一点。

本质上,我正在尝试执行标准的 Req/Rep,但是对所有节点并行执行请求,而不是循环。

更新:通过在 pub 请求中发送经销商的

routing id
,使远程调用幂等(仅在重复尝试时返回预先计算的结果),然后通过路由器将结果发送回,并在接收端进行消息过滤侧面,现在可以了。

zeromq
1个回答
1
投票

(有)更合适的方法吗?

是的。

开始应用马斯洛锤子法则

当你唯一的工具是锤子时,所有问题都开始像钉子。

换句话说,不要尝试用(一把)锤子来解决所有问题。

PUB/SUB
-原型旨在服务于那些且仅那些多方正式通信模式原型,其中许多SUB
-抄写到
.recv()
一些
PUB
- lisher(s) 
.send()
-广播消息,但没有其他。

类似地,

REQ/REP

原型的定义和实现是为了服务于唯一的多方分布式形式通信模式(并且显然不会满足任何具有任何其他单一用例的用例)甚至是稍微不同的要求)。

用户经常需要一些特殊的、不平凡的功能,这些功能显然不是上述琐碎的形式通信模式原型基元(那些现成的块,在 ZeroMQ 工具箱中提供)的一部分。

架构师/设计师的角色是定义、分析和实现任何更复杂的特定于用户的分布式行为定义(协议)并实现它,最常见的是使用现成的 ZeroMQ 原语的分层组合。

如果有疑问,拿一张纸和铅笔,在操场上画一小群孩子,并画出他们的“喊叫”,他们的“倾听”,他们的“沉默”,“等待”和“怀疑”,他们的许多或少数他们的“回复”,他们的“投票”和没有被朋友投票的“愤怒”,他们在太阳上争取一席之地的“坚持”,以及他们在结束后不让别人轮到自己坐“秋千”的“坚持”。释放迄今为止令人愉悦的摇摆自我。

所有这些都是找到(协议安排的)控制级别和行动自由级别的正确组合的一部分。

我们获得了针对您的特定用例量身定制的新分布式行为。

找到一个现成的原始工具来匹配和满足任何特定于用户的用例的概率无限接近于零(当然,除非一个人自己的特定于用户的用例需求与原始原型的所有需求相匹配,但那就是不是特定于用户的用例,而是在相同的情况下重新使用已经实现的原型,这是 ZeroMQ 之父所预见的,不是吗?)

再次欢迎来到零之禅的艺术。

也许您想阅读

这个这个这个

© www.soinside.com 2019 - 2024. All rights reserved.