Comprender los tipos avanzados de zócalos ZeroMQ

Question

He leído la guía 0MQ y entiendo los tipos de socket básicos: PUSH / PULL , REQ / REP y PUB / SUB .

Sin embargo, estoy muy confundido sobre ROUTER / DEALER y los enchufes X (por ejemplo, XSUB / XPUB , XREQ / XREP ).

¿Cuáles son los casos de uso para estos tipos de socket?

Answer 1

Arquetipos Triviales

Los " zócalos " ZeroMQ suenan como un dispositivo orientado a zócalos, sin embargo, en una mirada más cercana, esta biblioteca inteligente agrega un patrón de comunicación formal (que por cierto utiliza un zócalo verdadero) que tiene un diseño en capas para abordar internamente detalles como el búfer interno , interno 1: N Fair-Queue-Sending / Polling, equilibrio de carga interno ioThread, por nombrar solo algunos.

Encima de estos subsistemas inteligentes internos, también conocidos como los patrones de comunicación formal elementales, nombrados lo más cerca posible para parecerse a un comportamiento similar al humano -como- (uno) - PUB -lish + (otros) - SUB -scribe - ZeroMQ construye un "planta baja" de esquemas de mensajería mucho más potentes.

Como un buen ayudante, en lugar de decir un socket PUB , uno puede optar por imaginar un SUB , XPUB o DEALER para ser más bien una entidad con " comportamiento " , sentado en un extremo de la línea telefónica , que tiene un poco de con cable, que puede usar durante una llamada telefónica.

Por lo tanto, algunas entidades pueden hablar entre sí, al igual que PUB puede hablar con uno o varios SUB (s), sin saber cuántos / si alguno está conectado a él, bueno, a cualquiera de sus líneas telefónicas (sí , PUB puede tener muchas líneas telefónicas salientes; además, para obtener más información, consulte las Clases de transporte ZeroMQ disponibles, que PUB puede "exponer para las llamadas entrantes" o desplegar de otra manera (Oh, sí, incluso PUB puede "tomar uno de sus teléfonos- líneas "y marque (.connect () hacia) una contraparte SUB o XSUB seleccionada. Genial ... (Sí, como muchas funciones ZeroMQ XSUB )) - todo eso en paralelo.

SUB puede, a su discreción, decidir y suscribirse para filtrar, qué escuchar y qué no escuchar de la línea telefónica entrante. Naturalmente, algunos otros simplemente no están equipados dentro de su comportamiento precableado para poder comunicarse universalmente entre sí y entrar de manera significativa en una conversación viable, pero pueden hablar con su contraparte "amigable" (compatible con el comportamiento) (un PAIR , como un ejemplo, tiene una y la única oportunidad de ir y llamar + hablar con otro PAIR -buddy).

Para una comprensión más profunda de estos bloques de construcción, incluida la motivación XPUB / XSUB , por qué tuvieron que extender la primitiva simple PUB / SUB , la mejor manera que uno puede recomendar es leer el libro de Pieter Hintjens "Código conectado, volumen 1" (descargable como pdf) .

(En mi humilde opinión, un libro de lectura obligada, no solo sobre las propiedades inteligentes de ZeroMQ per-se, sino sobre el cambio de mentalidad y otros pensamientos inspiradores).

ROUTER / DEALER Y DEALER / ROUTER

Estos patrones de comunicación formal se ilustran bien en la figura 37 y se discuten en torno a dicho libro. Vale la pena leerlo, que solo obtener algunas palabras aquí.

Un ejemplo de ROUTER a DEALER (un caso de uso de 1 a N ) en el que un servidor habla de forma asíncrona con varios trabajadores puede ponerse "al revés" para obtener una arquitectura N-a-1 muy útil en la que varios clientes hablan con un solo servidor, y hacer esto asincrónicamente Entonces, el caso de uso exacto viene dado por su necesidad de diseño.

XPUB uso de XPUB / XSUB

Una vez que se XPUB modo " intermedio " de conexiones entre los elementos primitivos ZeroMQ, el "dispositivo" proxy XPUB / XSUB sirve un servicio adicional más que simplemente ser un proxy para .bind() y .connect() . También "interpreta" el contenido del mensaje (verificando zmq.SUBSCRIBE -s y las transfiere hacia el lado real- PUB -lisher a través del proxy propio XSUB ) leyendo el lado del zócalo XPUB . Este es el caso de uso principal para XSUB y XPUB

Dominar el arsenal de ZMQ elemento por elemento como tal no es el objetivo en sí. Es más bien un kit de bloques de construcción de estilo LEGO para diseñar patrones de mensajería distribuida específicos del proyecto, que cooperan de acuerdo con una necesidad más compleja: autocuración después de una falla de un solo nodo, escalabilidad de rendimiento, reconfiguración adaptativa y muchos otros.

Solo una foto, Fig.60:

Sistemas complejos

La aplicación típica del mundo real tiene que ir mucho más allá de simplemente reutilizar las primitivas PAIR / PAIR , XREQ / XREP , ... XREP , donde estas se ajustan adecuadamente a sus necesidades de diseño de nivel superior, y encima de las cuales agrega un estrategia de comportamiento, que utiliza estos arquetipos de nivel inferior bajo su control de diseño global.

Para organizar el código, vale la pena pasar un tiempo con el libro primero, no al revés.

¡Esto te ahorrará mucho Aha! Momentos después.