message-queue - patron - rabbitmq topic

Confusión de mensajes: Pub/Sub vs Multicast vs Fan Out

Question

He estado evaluando las tecnologías de mensajería para mi empresa, pero estoy muy confundido por las diferencias conceptuales entre algunos términos:

Pub / Sub vs Multicast vs Fan Out Estoy trabajando con las siguientes definiciones:

• Pub / Sub tiene editores entregando una copia separada de cada mensaje a cada suscriptor lo que significa que existe la oportunidad de garantizar la entrega.
• Fan Out tiene una sola cola para todos los clientes que escuchan.
• La multidifusión simplemente espacia datos y si alguien está escuchando, está bien, si no, no importa. No hay posibilidad de garantizar que un cliente definitivamente reciba un mensaje.

¿Son estas definiciones correctas? ¿O es Pub / Sub el patrón y multidifusión, directo, fanout, etc. formas de lograr el patrón?

Estoy intentando trabajar con las definiciones de RabbitMQ listas para usar en nuestra arquitectura, pero estoy dando vueltas en círculos en este momento tratando de escribir las especificaciones para nuestra aplicación.

Por favor, ¿podría alguien aconsejarme si estoy en lo cierto?

Answer 1

Desde el punto de vista del intercambio electrónico, el término "Multidifusión" significa "el mensaje se coloca en el cable una vez" y todas las aplicaciones cliente que están escuchando pueden leer el mensaje del "cable". Cualquier solución que haga N copias del mensaje para los N clientes no es multidifusión. Además de examinar el código fuente, también se puede usar un "sniffer" para determinar cuántas copias del mensaje se envía por el cable desde el sistema de mensajería. Y sí, los mensajes de multidifusión son un formulario del mensaje de protocolo UDP. Ver: http://en.wikipedia.org/wiki/Multicast para una descripción general. Hace unos diez años, utilizamos el sistema de mensajería de TIBCO que admitía multidifusión. Ver: https://docs.tibco.com/pub/ems_openvms_c_client/8.0.0-june-2013/docs/html/tib_ems_users_guide/wwhelp/wwhimpl/common/html/wwhelp.htm#context=tib_ems_users_guide&file=EMS.5.091.htm

Answer 2

Tus definiciones son bastante correctas. Tenga en cuenta que la entrega garantizada no está limitada solo a pub / sub, y también se puede hacer con fanout. Y sí, pub / sub es una descripción muy básica que puede realizarse con métodos específicos como fanout, direct, etc.

Hay más patrones de mensajes que pueden serle útiles. Eche un vistazo a Patrones de integración empresarial para obtener más detalles.

Answer 3

Estoy confundido por su elección de tres términos para comparar. Dentro de RabbitMQ, Fanout y Direct son tipos de intercambio. Pub-Sub es un patrón de mensajería genérico, pero no un tipo de intercambio. Y ni siquiera mencionaron el tercer y más importante tipo de intercambio, a saber, el tema. De hecho, puede implementar el comportamiento de Fanout en un intercambio de Tema simplemente declarando múltiples colas con la misma clave de enlace. Y puede definir el comportamiento directo en un intercambio de tema declarando una cola con * como la clave de enlace comodín.

Pub-Sub generalmente se entiende como un patrón en el cual una aplicación publica mensajes que son consumidos por varios suscriptores.

Con RabbitMQ / AMQP es importante recordar que los mensajes siempre se publican en los intercambios. Luego intercambia la ruta a las colas. Y las colas entregan mensajes a los suscriptores. El comportamiento del intercambio es importante. En los intercambios de tema, la clave de enrutamiento del editor se compara con la clave de enlace del suscriptor para tomar la decisión de enrutamiento. Las claves de enlace pueden tener patrones comodín que influyen aún más en la decisión de enrutamiento. El enrutamiento más complicado se puede hacer en función del contenido de los encabezados de los mensajes mediante un tipo de intercambio de encabezados

RabbitMQ no garantiza la entrega de mensajes, pero puede obtener la entrega garantizada eligiendo las opciones correctas (modo de entrega = 2 para mensajes persistentes) y declarando intercambios y colas antes de ejecutar su aplicación para que los mensajes no se descarten.