我已经阅读了0MQ指南,并且理解了基本的套接字类型:PUSH
/PULL
,REQ
/REP
和PUB
/SUB
。
但是,我对于ROUTER
/DEALER
和X
套接字(例如XSUB
/XPUB
,XREQ
/XREP
)感到非常困惑。
这些套接字类型有哪些用例?
我已经阅读了0MQ指南,并且理解了基本的套接字类型:PUSH
/PULL
,REQ
/REP
和PUB
/SUB
。
但是,我对于ROUTER
/DEALER
和X
套接字(例如XSUB
/XPUB
,XREQ
/XREP
)感到非常困惑。
这些套接字类型有哪些用例?
ZeroMQ "sockets" 看起来像是一个基于套接字的设备,但仔细一看,这个智能库实际上增加了一个正式的通信模式(顺便提一下,它使用了真正的 socket),该模式具有分层设计以内部解决详细信息,例如内部弹性缓冲、内部 1:N 公平队列发送/轮询和内部 ioThread 负载平衡等。
在这些内部智能子系统之上,即基本的正式通信模式之上,名称尽可能地类似于人类行为,如 (one)PUB
-lishes + (others)-SUB
-scribe,ZeroMQ 构建了更强大的消息传递方案的“地面层”。
作为一个好助手,我们可以不说 PUB
-socket,而是想象一个 SUB
、XPUB
或 DEALER
更像是一个带有“行为”的实体,坐在电话线的一端,它有一些硬连线的习惯,在电话交谈中可以使用。
所以,一些实体可以相互通信,例如 PUB
可以与一个或多个 SUB
交流 - 不知道连接到他的电话线上有多少个/是否有任何一个(是)连接到他的电话线上(是的,PUB
可以有许多传出电话线 - 并且可以检查可用的 ZeroMQ 传输类,PUB
可以“公开用于呼入电话”的或以其他方式部署 - (哦,是的,甚至 PUB
可以拿起他的电话之一,拨打(.connect() 向)选定的 SUB
或 XSUB
对手!很酷……(是的,许多 ZeroMQ 功能都被设计进去了))- 这些都是并行进行的。
SUB
可以自行决定并订阅过滤器,决定从电话线路中听取什么和不听取什么。自然而然地,有些人在其预先布线的行为范围内根本无法普遍地相互通话,并且能够有意义地进入可行的对话,但是可以与其“友好”(行为兼容)的对等方交谈(例如,PAIR
有一次机会去响铃并与另一个PAIR
-buddy进行交流)。
更深入了解这些构建块,包括XPUB
/XSUB
的动机,为什么它们必须扩展平原的PUB
/SUB
原语,最好的推荐方法是阅读Pieter Hintjens的书籍《Code Connected, Volume 1》(可下载为pdf)。
(在我看来,这是一本必读的书,不仅涉及ZeroMQ的智能属性,还涉及思维方式的转变和其他激励人心的想法)。
ROUTER
/DEALER
& DEALER
/ROUTER
这些正式的通信模式在图37中得到很好的说明,并在该书中讨论。值得一读,而不仅仅是在这里获取几个单词。
ROUTER
对DEALER
的示例(一个1对N用例),其中一个服务器异步地与多个工作进程交谈,可以被倒置以获得非常有用的N对1体系结构,其中各种客户端与单个服务器交谈,并且异步执行此操作。因此,确切的用例由您的设计需求确定。
XPUB
/XSUB
用例一旦到达 ZeroMQ 原始元素的 "中介" 连接模式,XPUB
/XSUB
代理 "设备" 提供了比仅仅作为 .bind()
& .connect()
的代理更多的附加服务。它还通过读取 XPUB
socket 端来 "解释" 消息内容(检查传入的 zmq.SUBSCRIBE
并通过代理自己的 XSUB
将其传递到实际的发布者方)这就是 XSUB
和 XPUB
的主要用例。
像这样逐元素掌握 ZMQ 防御系统并不是目标本身。相反,它是一种 LEGO 样式的构建项目特定分布式消息模式的构件工具箱,根据更复杂的需求合作 - 单节点故障后的自我修复,性能可扩展性,自适应重配置和许多其他。
仅有一张图片,图60:
典型的实际应用需要远远超出仅仅重复使用基本的 PAIR
/PAIR
,XREQ
/XREP
等原始元素,这些原始元素适合于您的更高级别设计需求,并在您全局设计控制下添加行为策略,使用这些低级别原型。
为了安排代码,值得先花时间阅读书籍而不是相反。
这将为您节省许多 "Aha!" 瞬间。