了解高级 ZeroMQ 套接字类型 [英] Understanding advanced ZeroMQ socket types
问题描述
我已经阅读了 0MQ 指南，并且了解了基本的套接字类型:PUSH/PULL, REQ/REP 和 PUB/SUB.
I've read the 0MQ guide, and I understand the basic socket types: PUSH/PULL, REQ/REP, and PUB/SUB.
我对 ROUTER/DEALER 和 X- 套接字(例如，XSUB/XPUB、XREQ/XREP).
I'm very confused though about ROUTER/DEALER and the X- sockets (e.g., XSUB/XPUB, XREQ/XREP).
这些套接字类型的用例是什么?
What are the use cases for these socket types?
推荐答案
Trivial Archetypes
ZeroMQ "sockets" 听起来像是一个面向套接字的设备，但是仔细观察这个智能库反而增加了一个正式的通信模式(顺便说一句，它使用了一个真正的 socket ) 具有分层设计以在内部处理细节，例如内部弹性缓冲、内部 1:N 公平队列发送/轮询、内部 ioThread 负载平衡，仅举几例.
Trivial Archetypes
ZeroMQ "sockets" are sounding alike a socket-oriented device, however on a closer look this smart library rather adds a Formal Communication Pattern ( which btw. uses a true socket ) that has a layered design to internally address details like internal elastic-buffering, internal 1:N Fair-Queue-Sending / Polling, internal ioThread load-balancing, to name just a few.
在这些内部智能子系统之上，也就是基本的正式通信模式——命名尽可能接近于类似人类的行为 -like- (one)-PUB-lishes + (others)-SUB-scribe -- ZeroMQ 构建更强大的消息传递方案的底层".
Atop on these internal smart subsystems, aka the elementary Formal Communication Patterns -- named as close as possible to resemble a human-alike behaviour -like- (one)-PUB-lishes + (others)-SUB-scribe -- ZeroMQ builds a "ground floor" of much more powerful messaging schemes.
作为一个好帮手，与其说PUB-socket，不如想象一个SUB、XPUB 或 DEALER 更像是一种具有-行为"的实体，坐在电话线的一端，他有一些固有的习惯，可以在打电话时使用.
As a good helper, instead of saying a PUB-socket, one may opt to imagine a SUB, XPUB or DEALER to be rather an entity-with-"behaviour", sitting on one end of the phone-line, who has some hard-wired habits, that it can use during a phone-call.
因此，某些实体可以相互交谈，例如 PUB 可以与一个或多个 SUB(s) 交谈 - 不知道有多少/如果有的话(是)连接到他的，嗯，连接到他的任何电话线(是的，PUB 可以有许多传出电话线——此外，有关详细信息，请查看 ZeroMQ 传输类可用，PUB 可以暴露来电"或以其他方式部署--(哦，是的，即使 PUB 也可以拿起他的电话线"并拨打(.connect() 对 ) 选定的 SUB 或 XSUB 交易对手！酷...(是的，设计了许多 ZeroMQ 功能))--所有这些都是并行的.
So, some entities can speak one to the other, alike PUB can speak to one or many SUB(s) - without knowing how many / if any is (are) connected to his, well, to any of his phone-lines ( yes, PUB can have many outgoing phone-lines -- plus for details check the ZeroMQ transport Classes available, that PUB can "expose for incoming calls" or otherwise deploy --( Oh yes, even PUB can "pick up one of his phone-lines" and dial ( .connect() towards ) a selected SUB or XSUB counterparty! Cool... (Yes, as many ZeroMQ features designed-in) )-- all of that in parallel.
SUB 可以自行决定和订阅过滤器，从传入的电话线听到什么和不听到什么.自然地，其他一些人根本没有在他们预先设定的行为中配备能够普遍地互相打电话并有意义地进入可行的对话，但可以与它的友好"(行为兼容)对手方交谈(例如，PAIR 有一个也是唯一的机会去和另一个 PAIR-buddy 打电话+说话).
SUB can upon its discretion decide and subscribe to filter, what to hear and what not to hear from the incoming phone-line. Naturally, some others are simply not equipped within their pre-wired behaviour to be able to universally phone each other and get meaningfully get into a viable conversation, but can talk to it's "friendly" (behavioral-compatible) counterparty ( a PAIR, as an example, has a one and the only chance to go and ring + speak to another PAIR-buddy ).
为了更深入地理解这些构建块，包括 XPUB/XSUB 的动机，为什么他们必须扩展普通的 PUB/SUB 原语，最好的方法是阅读 Pieter Hintjens 的书代码连接，第 1 卷"(可下载为 pdf).
For deeper understanding of these building blocks, incl, the XPUB/XSUB motivation, why they had to extend the plain PUB/SUB primitive, the best way one can recommend is to read Pieter Hintjens' book "Code Connected, Volume 1" ( downloadable as pdf).
(恕我直言，这是一本必读的书，不仅仅是关于 ZeroMQ 本身的智能属性，而是关于思维方式的转变和其他鼓舞人心的想法).
( IMHO a must-read book, not just about the smart properties of ZeroMQ per-se, but about the shift in mindset and other inspiring thoughts ).
这些正式的通信模式在图 37 中得到了很好的说明，并在上述书中进行了讨论.值得一读，而不是仅仅在这里读几句话.
These Formal Communication Patterns are well illustrated in Fig.37 and discussed around, in the said book. Worth reading it, than just getting a few words here.
ROUTER 到 DEALER 示例(1-to-N 用例)，其中一个服务器与多个工作人员进行异步对话颠倒"以获得非常有用的 N 对 1 架构，其中各种客户端与单个服务器通信，并异步执行此操作.因此，您的设计需要给出了确切的用例.
A ROUTER to DEALER example ( a 1-to-N use case ) where one server talks asynchronously to multiple workers can be turned "upside down" to get a very useful N-to-1 architecture where various clients talk to a single server, and do this asynchronously. So exact use-case is given by your design need.
一旦进入 ZeroMQ 原始元素之间的中介"连接模式，XPUB/XSUB 代理设备"提供一种附加服务，而不仅仅是作为 .bind() 的代理 &.connect() 到.它还解释"消息内容(检查传入的 zmq.SUBSCRIBE-s & 将它们通过代理自己的 - ) 通过读取 PUB-lisher>XSUBXPUB 套接字端.这是 XSUB 和 XPUB
Once getting to the "inter-mediated" mode of connections among the ZeroMQ primitive elements, the XPUB/XSUB proxy "device" serves one more add-on service than just being a proxy to .bind() & .connect() to. It also "interpretes" the message-content ( checking incoming zmq.SUBSCRIBE-s & transfers 'em towards the real-PUB-lisher side via the proxy own XSUB ) by reading the XPUB socket side.This is the main use case for XSUB and XPUB
逐个元素地掌握 ZMQ 武器库本身并不是目标.它是用于设计特定于项目的分布式消息传递模式的乐高式积木套件，根据更复杂的需求进行协作——单节点故障后的自我修复、性能可扩展性、自适应重新配置和许多其他.
Mastering the ZMQ arsenal element-by-element as such is not the goal per-se. It is rather a LEGO-style kit of building blocks for designing project-specific distributed messaging patterns, that co-operate according to a more complex need -- self-healing after a single node failure, performance-scaleability, adaptive-reconfiguration and many others.
一张图，图60:
典型的实际应用程序必须走得更远，而不仅仅是重用基本的PAIR/PAIR、XREQ/XREP、...原语，这些原语适合您的更高级别的设计需求，并在其上添加行为策略，在您的全局设计控制下使用这些较低级别的原型.
Typical real-world application has to go much farther than just to re-use the elementary PAIR/PAIR, XREQ/XREP, ... primitives, where these appropriately fit into your higher-level design needs, and atop of which you add a behaviour strategy, that uses these lower-level archetypes under your global design control.
为了整理代码，值得先花点时间阅读本书，反之亦然.
For getting code arranged, worth spending a time with the book first, not vice versa.
这将为您节省很多啊哈！片刻之后.
This will save you a lot of Aha! moments later.
这篇关于了解高级 ZeroMQ 套接字类型的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
