RabbitMQ distribuido

Agustin Bassi

Ago 19, 2021 ‧ 7 min estimados ‧ #rabbitmq #cluster #federation #shovel

Contenido

Objetivos

RabbitMQ distribuido

Clustering

Federation

Shovels

Comparación de soluciones

Conclusiones

Bibliografía

Licencia

Objetivos

En este artículo veremos una breve introducción a las posibilidades que existen para intercomunicar brokers RabbitMQ entre sí. Lo que vas a ver en este documento son los siguientes temas:

RabbitMQ distribuido

Utilizar AMQP para el desarrollo de aplicaciones y sistemas propone desde el primer momento la distribución entre las partes. Por un lado se encuentra el broker donde se conectan los productores para enviar sus mensajes, y por otro lado, los consumidores se conectan al broker para obtener los mensajes publicados.

Si bien este es el panorama más simple, a menudo es necesario distribuir mensajes entre distintos brokers RabbitMQ; hay tres formas de lograrlo. Por un lado, se puede configurar un cluster con N brokers, por otro lado, se puede realizar la federación de brokers para recibir datos desde brokers remotos y finalmente, se puede utilizar el plugin Shovel, un cliente que toma datos de una entidad fuente y los envía a una entidad de destino.

En este artículo vamos a realizar una descripción general sobre cada método de comunicación entre brokers. Tené en cuenta que los enfoques no son mutuamente excluyentes y se pueden combinar de cualquier manera.

Clustering

La agrupación en clúster conecta varias máquinas entre sí de forma transparente para los clientes. Este diseño asume que las conexiones de red son razonablemente fiables y proporcionan una latencia similar a la de una LAN, por lo que es recomendable que garantices una buena comunicación antes de realizar esta configuración.

Por otro lado, todos los nodos del clúster deben ejecutar versiones compatibles de RabbitMQ y Erlang. Para realizar la comunicación, los nodos se autentican entre sí mediante una clave previamente compartida que suelen instalar las herramientas de deploy automático.

Los hosts, los exchanges, usuarios, permisos y host virtuales se replican automáticamente en todos los nodos de un clúster. Las colas pueden estar ubicadas en un solo nodo o replicar su contenido para una mayor disponibilidad. Las colas de quórum son un tipo de cola replicada que se centra en la seguridad de los datos. Las colas clásicas se pueden duplicar opcionalmente.

La agrupación en clústeres puede ayudar a mejorar la disponibilidad, la seguridad de los datos y mantener más conexiones simultáneas. En esta imagen podés ver un diagrama de una solución en clusters.

Federation

La federación es un plugin del core de RabbitMQ que permite que un exchange o queue en un broker reciba mensajes publicados en un exchange o queue en otro broker remoto. La comunicación entre brokers se realiza a través de AMQP y puede ser autenticada con SSL. Para que la federación suceda es necesario configurar adecuadamente el plugin con los usuarios y los permisos correspondientes.

Los brokers federados están conectados con enlaces unidireccionales punto a punto; es decir, sólo un broker recibe lo que se publica en otro, pero no lo inverso. De forma predeterminada, los mensajes se reenvían una única vez a través de un enlace de federación, pero este reenvío se puede aumentar para permitir topologías más complejas.

La federación resulta útil para vincular brokers remotos sin necesidad de configuración adicional en la fuente de datos origen. Esto permite realizar topologías de comunicación donde desde un nodo central se pueda reenviar mensajes a múltiples brokers que se unen a la red a demanda. En esta imagen podemos ver un diagrama simple de comunicación federada entre brokers.

Shovels

La funcionalidad que provee el plugin Shovel es intercomunicar brokers tomando datos desde un origen y enviarlos a un destino. Es conceptualmente similar a conectarlos con la Federación, aunque en este caso el plugin trabaja de manera más simple, ya que es un cliente de RabbitMQ que toma los datos de un exchange o queue de origen que los reenvía a un exchange o queue de destino.

Mientras que la federación tiene como objetivo proporcionar una distribución de exchanges y queues mediante policies, la funcionalidad de shovel intercambia datos entre entidades particulares. Generalmente se suele utilizar cuando se necesita un control más preciso del que brinda la federación.

La comunicación mediante el plugin Shovel se puede realizar de manera dinámica en tiempo de ejecución o estática, teniendo que reiniciar el broker para cargar adecuadamente los enlaces. En esta imagen podemos ver un diagrama simple de comunicación entre brokers utilizando el plugin Shovel.

Comparación de soluciones

Ahora que ya vimos una descripción general de cada tipo de solución, veamos algunas comparaciones entre las mismas para brindar un mejor panorama.

Federation/Shovel

Clustering

Conclusiones

En este artículo realizamos una muy breve introducción a las posibilidades que existen para intercomunicar brokers RabbitMQ entre sí. Al momento de realizar las configuraciones será necesario que consultes la documentación de los clusters, de federación o de shovels. Resumiendo, en este artículo vimos los siguientes temas.

Bibliografía

Licencia

Este material es distribuido bajo licencia Creative Commons BY-SA 4.0. Podés encontrar detalles sobre el uso del material en este link.