Dentro el desarrollo de un proyecto de software en muchas ocasiones hay que integrarse
(acoplarse) con otros actores, componentes, o sistemas internos y externos, siendo necesario
enviar o recibir información de ellos. En el mayor de los casos estas comunicaciones tienen que
estar permanentemente disponibles, ser rápidas, seguras, asíncronas y fiables entre otros
requisitos.
Una de las mejores soluciones de acoplamiento de aplicaciones heterogéneas es el manejo de
colas de mensajes.
Introducción
Las colas de mensajes (MQ) solucionan
estas necesidades, actuando de
intermediario entre emisores y destinatarios,
o en un contexto más definido, productores y
consumidores de mensajes. Se pueden usar
para reducir las cargas y los tiempos de
entrega por parte de los servidores de
aplicaciones web, ya que las tareas, que
normalmente tardarían bastante tiempo en
procesarse, se pueden delegar a un tercero
cuyo único trabajo es realizarlas.
El uso de colas de mensajes también es
bueno cuando se desea distribuir un mensaje
a múltiples destinatarios para consumo o
para realizar balanceo de carga entre
trabajadores.
Beneficios
• Garantía de entrega y orden: Los
mensajes se consumen, en el mismo
orden que llegan, y son consumidos
una única vez
• Redundancia: Los mensajes en las
colas persisten hasta que son
procesados por completo
• Desacoplamiento: Siendo capas
intermedias de comunicación entre
procesos, aportan la flexibilidad en la
definición de arquitectura de cada uno
de ellos de manera separada, siempre
que se mantenga una interfaz común
• Escalabilidad: Con más unidades de
procesamiento, existe la posibilidad
de crear más colas y de esta forma
balancear su respectiva carga
• Enrutamiento flexible: Basado en
diferentes reglas de enrutamiento o
selección de colas.
• Clusterización: Capacidad de
crecimiento horizontal
• Federación: Provee un acceso
común, a un conjunto de colas, dando
la posibilidad de poderlas gestionar
• Alta disponibilidad y Tolerancia a
fallos: Capacidad de poder disponer
redundancia ante posibles fallos
¿Qué es RabbitMQ?
• RabbitMQ es un software de encolado
de mensajes llamado broker de
mensajería o gestor de colas.
• RabbitMQ es un software de
negociación de mensajes y entra
dentro de la categoría de middleware
de mensajería.
• Es un software donde se pueden
definir colas, las aplicaciones se
pueden conectar a las mismas y
transferir/leer mensajes en ellas.
• RabbitMQ es un sistema gestor de
colas de mensajes de código abierto
que implementa el estándar AMQP
(Advanced Message Queuing
Protocol).
Que es AMQP
• AMQP - Advanced Message Queuing
Protocol
• Es un protocolo pensado para la
interoperabilidad
• Es un protocolo completamente
abierto
• Es un protocolo binario
Modelo de AMQP
Este modelo posee los siguientes elementos:
• Intercambiadores (Exchanges)
• Cola de mensajes (messages queues)
• Enlaces (Bindings)
• Reglas de Enrutamiento (Routing
Rules)
Características de RabbitMQ
• Soporte a múltiples protocolos de
mensajería: Directamente o mediante
plugins programados, tales como
AMQP 0-9-1, AMQP 1-0, STOMP,
MQTT o HTTP.
• Clientes: Existe una amplia variedad
de clientes y conectores desarrollados
para permitir la comunicación en una
gran variedad de lenguajes tales
como Java/JVM, MacOSXx, Amazon
Ec2, C/C++, Ruby, Python, Perl,
Erlang.
• Interfaz de Usuario: Existe una UI
muy completa que permite (entre
otras muchas posibilidades),
administrar los brokers generados
(crear colas, exchanges, usuarios
etc.) o incluso consultar el tráfico de
mensajes en el sistema en tiempo
real.
• Permite agrupar diferentes nodos en
un cluster que actúe como único
broker lógico, admitiendo incluso
políticas de alta disponibilidad y
mirroring.
• Permite establecer distintos brokers
en una misma máquina, así como
generar diferentes virtual hosts en los
que ubicarlos.
• Los brokers generados disponen de
un sistema de logs que informan al
administrador de las acciones que se
están llevando a cabo sobre el mismo,
facilitando la depuración de errores.
¿Cómo funciona?
• Hay aplicaciones clientes, llamadas
productores, que crean mensajes y
los entregan al broker (cola de
mensajes), otras aplicaciones,
llamadas consumidores, se conectan
a la cola y se suscriben para poder
consumir los mensajes y procesarlos.
Características de
funcionamiento
• Un mensaje puede incluir cualquier
tipo de información.
• Un software puede ser un productor,
consumidor, o ambos
simultáneamente.
• Los mensajes colocados en la cola se
almacenan hasta que el consumidor
los recupera o los consume.
• Los mensajes no se publican
directamente en una cola, en lugar de
eso, el productor envía mensajes a un
exchange. Los exchanges son
agentes de enrutamiento de
mensajes.
• Un exchange es responsable del
enrutamiento de los mensajes a las
diferentes colas: acepta mensajes del
productor y los dirige a colas de
mensajes con ayuda de atributos de
cabeceras, bindings y routing keys.
• Un binding es un “enlace” que se
configura para vincular una cola a un
exchange
• Un routing key es un atributo del
mensaje, este es utilizado por el
exchange para decidir cómo enrutar el
mensaje.
• Los exchanges, los enlaces y las
colas pueden configurarse con
parámetros tales como durable,
temporary, y auto delete en el
momento de su creación.
◦ Los exchanges declarados como
durable sobrevivirán a los reinicios
del servidor y durarán hasta que
se eliminen explícitamente.
◦ Aquellos de tipo temporary existen
hasta que el Broker se cierre.
◦ Por último, los exchanges
configurados como auto delete se
eliminan una vez que el último
objeto vinculado se ha liberado del
exchange.
Comunicación con el Broker
Para establecer una comunicación con el
broker, es necesario disponer de un usuario
que esté registrado en el mismo. RabbitMQ
permite establecer limitaciones en los
usuarios que genera, bien mediante tags
(administrator, policymaker, management o
monitoring) o mediante cada virtual host al
que este se encuentre asociado.
Conceptos Útiles
• Producer (Productor): Programa que
escribe mensajes en un
intercambiador (Exchange)
• Consumer (Consumidor): Programa
que escucha mensajes en una cola
(Queue)
• Exchange: Es el punto de entrada de
un mensaje.
• Queue: Es el punto de lectura de un
mensaje.
• Bindings: Son reglas que indican
cómo llegar de un Exchange a las
Queue asociadas.
• Routing key: Filtro asociado a un
Binging que permite seleccionar sólo
algunos mensajes para dicho binding.
• Virtual host o vhost: Un entorno
aislado, con sus propios grupos de
usuarios, exchanges, queues, ...
Tipos de Exchange
RabbitMQ tiene 4 tipos de exchange
predefinidos:
• Direct Exchange
• Topic Exchange
• Famout Exhange
• Headers Exchange
Funcionamiento estándar
El funcionamiento básico o estándar que
posee RabbitMQ es el siguiente:
1. El productor publica un mensaje para
el exchange.
2. El exchange recibe el mensaje y es
responsable del enrutamiento del
mensaje.
3. Se debe establecer un enlace entre la
cola y el exchange. En este caso,
tenemos enlaces a dos colas
diferentes del intercambio. El
intercambio enruta el mensaje a las
colas.
4. Los mensajes permanecen en la cola
hasta que sean manejados por un
consumidor
5. El consumidor maneja el mensaje
Default Exchange
El default exchange es un intercambio directo
pre-declarado sin nombre, generalmente está
referido por una cadena vacía "".
Cuando usa el intercambio predeterminado,
su mensaje será entregado a la cola con un
nombre igual a la clave de enrutamiento del
mensaje.
Cada cola se enlaza automáticamente al
intercambio predeterminado con una clave de
enrutamiento que es igual que el nombre de
la cola.
Direct Exchange
Un intercambio directo entrega mensajes a
colas basadas en una clave de enrutamiento
de mensajes.
La clave de enrutamiento es un atributo del
mensaje agregado al encabezado (header)
del mensaje por el productor.
La clave de enrutamiento se puede ver como
una "dirección" que el exchange está
utilizando para decidir cómo enrutar el
mensaje. Un mensaje va a la (s) cola (s) cuya
clave de enlace coincide exactamente con la
clave de enrutamiento del mensaje.
Ejemplo:
Se envía un mensaje con la clave de
enrutamiento pdf_log al exchange
pdf_events.
Los mensajes se enrutan a pdf_log_queue
porque la clave el rounting key (pdf_log)
coincide con el binding key (pdf_log).
Si la clave de enrutamiento de mensajes no
coincide con ninguna clave de enlace, el
mensaje será descartado.
Topic Exchange
Los intercambios temáticos o por tópicos
enrutan mensajes a colas basadas en
coincidencias de comodines entre la clave de
enrutamiento y algo llamado el patrón de
enrutamiento.
Los mensajes se enrutan a una o varias colas
en función de una coincidencia entre una
clave de enrutamiento de mensaje y este
patrón.
La clave de enrutamiento debe ser una lista
de palabras, delimitada por un punto (.).
Para el ejemplo de la gráfica: agreements.us
y agreements.eu.stockholm, identifican los
acuerdos que se establecen para una
empresa con oficinas en muchos lugares
diferentes.
Los patrones de enrutamiento pueden
contener un asterisco ("*") para hacer
coincidir una palabra en una posición
específica de la clave de enrutamiento (por
ejemplo, un patrón de enrutamiento de
"agreements. *. *. b. *" Solo coincidirá con
claves de enrutamiento donde la primera
palabra es "agreements" y la cuarta palabra
es "b").
El símbolo "#" indica coincidencia en cero o
más palabras (por ejemplo, un patrón de
enrutamiento de "agreements.eu.berlin.#"
Coincide con cualquier clave de enrutamiento
que comience por "agreements.eu.berlin").
Ejemplo
Se envía un mensaje con la clave de
enrutamiento agreements.eu.berlin a los
acuerdos de intercambio.
Los mensajes se enrutan a la cola
berlin_agreements porque el patrón de
enrutamiento de "agreements.eu.berlin.#"
coincide, asi también se enruta a la cola
all_agreements porque la clave de
enrutamiento (agreements.eu.berlin) coincide
con el patrón de enrutamiento (agreements.
#).
Fanout Exchange
El exchange Fanot copia y enruta un mensaje
recibido a todas las colas que están
vinculadas a él, independientemente de las
claves de enrutamiento o la coincidencia de
patrones como con los intercambios directos
y de temas. Las llaves proporcionadas
simplemente serán ignoradas.
Los intercambios de Fanout pueden ser útiles
cuando el mismo mensaje debe enviarse a
una o más colas con consumidores que
pueden procesar el mismo mensaje de
diferentes maneras.
La gráfica muestra un ejemplo en el que un
mensaje recibido por el intercambio se copia
y enruta a las tres colas que están vinculadas
al intercambio.
Ejemplo
Se envía un mensaje al intercambio
sport_news. El mensaje se enruta a todas las
colas (Cola A, Cola B, Cola C) porque todas
las colas están vinculadas al intercambio.
Siempre que se ignoren las claves de
enrutamiento.
Header Exchange
El header exchange intercambia la ruta en
función de los argumentos que contienen
encabezados y valores opcionales.
Son muy similares a los Topic Exchange,
pero se enruta en función de los valores de
encabezado en lugar de las claves de
enrutamiento.
Un mensaje se considera coincidente si el
valor del encabezado es igual al valor
especificado al vincularse.
La propiedad "x-match" puede tener dos
valores diferentes: "any" o "all", donde "all" es
el valor predeterminado. Un valor de "all"
significa que todos los pares de encabezado
(clave, valor) deben coincidir y un valor de
"any" significa que al menos uno de los pares
de encabezado debe coincidir. El argumento
"any"es útil para dirigir mensajes que pueden
contener un subconjunto de criterios
conocidos (desordenados).
Instalación
apt install RabbitMQ-server
Gestión del servicio
Activar desde el arranque
systemctl enable RabbitMQ-server
Iniciar el servicio
systemctl start RabbitMQ-server
Detener el servicio
systemctl stop RabbitMQ-server
Crear un usuario admin
Por defecto RabbitMQ crea un usuario guest
con contraseña guest, pero existe la
posibilidad de crear mas usuarios con
diferentes atribuciones.
• Crear usuario
RabbitMQctl add_user admin
password
• Asignar rol de administrador
RabbitMQctl set_user_tags admin
administrator
• Privilegios sobre un vhost
RabbitMQctl set_permissions -p /
admin ".*" ".*" ".*"
Interacción con Python
Para el siguiente ejemplo haremos uso de la PIKA una librería de python para el manejo de
RabbitMQ
Instalación
pip install pika
• Conexión
conexion = pika.BlockingConnection(pika.ConnectionParameters(host='localhost'))
• Apertura del canal
canal = conexion.channel()
• Cerrar conexión
conexion.close()
• Declaración de la cola
canal.queue_declare(queue='prueba')
• Envío de mensajes
Esta parte puede ser la parte complicada ya que puede establecer el tipo de exchange, la cola
de destino, el cuerpo del mensaje. En el ejemplo establecemos que la cola destino por defecto
esta establecida por routing_key.
canal.basic_publish(exchange='', routing_key='prueba', body='Hola Mundo')
productor.py
import pika
# Establecer conexión
conexion = pika.BlockingConnection(pika.ConnectionParameters(host='localhost'))
canal = conexion.channel()
# Declarar la cola
canal.queue_declare(queue='prueba')
# Publicar el mensaje
canal.basic_publish(exchange='', routing_key='prueba', body='Fundación AtixLibre')
print("Mensaje enviado.")
# Cerrar conexión
conexion.close()
Ejecución del programa productor
$ python productor.py
Mensaje enviado.
Verificación del estado de la cola
Debemos recordar que la entrega de mensajes es asíncrona, lo que representa que el mensaje
permanecerá en la cola, hasta que algún programa o aplicación la consuma.
Estado de la cola de mensajes
$ RabbitMQctl list_queues
Listing queues …
prueba 1
Recepción de mensajes
• Suscripción
Antes de poder recibir los mensajes, es necesario realizar una suscripción, la cual nos permita
recibir una llamada cada vez que haya un mensaje en cola, este proceso se llama callback.
def recepcion(canal, method, properties, body):
print("Mensaje en cola: %s" % body)
• Enlazar con la recepción
canal.basic_consume(recepcion, queue='prueba', no_ack=True)
donde:
• queue='prueba': Cola a la que se enlaza
• no_ack=True: Elimina el mensaje cuando sea servido
• Esperar otros mensajes
canal.start_consuming()
consumidor.py
import pika
# Establecer conexión
conexion = pika.BlockingConnection(pika.ConnectionParameters(host='localhost'))
canal = conexion.channel()
# Declarar la cola
canal.queue_declare(queue='prueba')
# Definir la función callback
def recepcion(ch, method, properties, body):
print("Mensaje en cola: %s" % body)
# Enganchar el callback
canal.basic_consume(recepcion, queue='prueba', no_ack=True)
# Poner en espera
print('Esperando mensajes...')
canal.start_consuming()
Ejecución del consumidor
$ python consumidor.py
Esperando mensajes...
Mensaje en cola: b'Fundación AtixLibre'
Estado de la cola
$ RabbitMQctl list_queues
Listing queues ...
prueba 0
Simulación de un Entorno de Demostración
Para una mejor comprensión realizaremos un conjunto de programas que nos permitan realizar
la simulación de la gestión de una cola de mensajes para realizar diferentes operaciones
(Registrar, Generar e Imprimir) sobre distintos tipos de documentos (Formulario de Solicitud,
Expediente Cliente, Certificado de Inscripción), donde cada uno de estos puede tener cierto
número de páginas.
Descripción de Programas
El entorno posee los siguientes programas con las diferentes funciones:
• productor.py: Programa orientado a enviar o publicar los diferentes trabajos a la cola de
mensajes
• consumidor.py: Programa orientado a recuperar los diferentes trabajos que se
encuentran en la cola de mensajes
• operaciondocumento.py: Programa orientado a simular de forma aleatoria el tipo de
documento, el tipo de trabajo a realizar, el numero de paginas de cada tipo de
documento y simular la ejecución de cada uno de estos de a cuerdo a las características
ya descritas.
• trabajo.py: programa orientado a realizar la definición de la clase trabajo, con sus
diferentes atributos y los métodos de importar y exportar que permiten serializar los
datos del mismo para ser enviados como cuerpo del mensaje a la cola respectiva.
productor.py
import pika
from trabajo import Trabajo
from operaciondocumento import documento, operacion, paginas, ejecutar
from random import randint
import time
# Establecer conexión
conexion = pika.BlockingConnection(pika.ConnectionParameters(host='localhost'))
canal = conexion.channel()
# Declarar la cola
canal.queue_declare(queue='gestion_documentos')
# Bucle infinito
while True:
# Tiempo aleatorio antes de lanzar el siguiente trabajo
time.sleep(randint(1,2))
# Generar un trabajo
t = Trabajo(operacion(), documento(), paginas())
# Publicar el mensaje
canal.basic_publish(exchange='', routing_key='gestion_documentos',
body=t.exportar().encode('utf-8'))
print("Trabajo enviado a la cola: %s" % t.exportar())
consumidor.py
import pika
from trabajo import Trabajo
from operaciondocumento import ejecutar
# Establecer conexión
conexion = pika.BlockingConnection(pika.ConnectionParameters(host='localhost'))
canal = conexion.channel()
# Declarar la cola
canal.queue_declare(queue='gestion_documentos')
# Definir la función callback
def procesar(canal, method, properties, body):
datos = body.decode('utf-8')
print("Se ha recibido un trabajo: %s" % datos)
t = Trabajo.importar(datos)
ejecutar(t)
canal.basic_ack(delivery_tag=method.delivery_tag)
# Enganchar el callback
canal.basic_consume(procesar, queue='gestion_documentos')
# Poner en espera
print('Esperando trabajos...')
canal.start_consuming()
operaciondocumento.py
import time
from random import randint
def documento ():
a = randint(1,3)
if a == 1:
td='Formulario de Solicitud'
elif a == 2:
td='Expediente Cliente'
elif a == 3:
td='Certtificado de Inscripcion'
return td
def operacion ():
b = randint(1,3)
if b == 1:
ops='Generar'
elif b == 2:
ops='Imprimir'
elif b == 3:
ops='Registrar'
return ops
def paginas():
return randint(1,10)
def ejecutar(trabajo):
if trabajo.operacion == 'Generar':
print('Generando %s ...' % trabajo.documento)
time.sleep(2)
print('Hecho!')
elif trabajo.operacion == 'Imprimir':
print('Imprimiendo %s ...' % trabajo.documento)
time.sleep(2)
print('Hecho!')
elif trabajo.operacion == 'Registrar':
print('Registrando %s ...' % trabajo.documento)
time.sleep(2)
print('Hecho!')
else:
raise NotImplementedError('Operación "%s" no soportada.' % trabajo.operacion)
trabajo.py
import json
class Trabajo:
def __init__(self, operacion, documento, paginas=None):
self.operacion = operacion
self.documento = documento
self.paginas = paginas
def exportar(self):
return json.dumps(self.__dict__)
@classmethod
def importar(cls, datos):
dic = json.loads(datos)
return cls(dic['operacion'], dic['documento'], dic['paginas'])
Ejecución del productor.py
$ python productor.py
Trabajo enviado a la cola: {"operacion": "Generar", "documento": "Formulario de
Solicitud", "paginas": 6}
Trabajo enviado a la cola: {"operacion": "Imprimir", "documento": "Formulario de
Solicitud", "paginas": 2}
Trabajo enviado a la cola: {"operacion": "Imprimir", "documento": "Certtificado de
Inscripcion", "paginas": 8}
Trabajo enviado a la cola: {"operacion": "Generar", "documento": "Formulario de
Solicitud", "paginas": 9}
Trabajo enviado a la cola: {"operacion": "Imprimir", "documento": "Formulario de
Solicitud", "paginas": 9}
Trabajo enviado a la cola: {"operacion": "Registrar", "documento": "Certtificado de
Inscripcion", "paginas": 8}
Trabajo enviado a la cola: {"operacion": "Generar", "documento": "Expediente Cliente",
"paginas": 3}
Trabajo enviado a la cola: {"operacion": "Registrar", "documento": "Formulario de
Solicitud", "paginas": 7}
Trabajo enviado a la cola: {"operacion": "Imprimir", "documento": "Expediente Cliente",
"paginas": 7}
Trabajo enviado a la cola: {"operacion": "Generar", "documento": "Expediente Cliente",
"paginas": 7}
Trabajo enviado a la cola: {"operacion": "Registrar", "documento": "Formulario de
Solicitud", "paginas": 9}
Trabajo enviado a la cola: {"operacion": "Registrar", "documento": "Expediente
Cliente", "paginas": 7}
Ejecución del consumidor.py
$ python consumidor.py
Esperando trabajos...
Se ha recibido un trabajo: {"operacion": "Generar", "documento": "Formulario de
Solicitud", "paginas": 6}
Generando Formulario de Solicitud ...
Hecho!
Se ha recibido un trabajo: {"operacion": "Imprimir", "documento": "Formulario de
Solicitud", "paginas": 2}
Imprimiendo Formulario de Solicitud ...
Hecho!
Se ha recibido un trabajo: {"operacion": "Imprimir", "documento": "Certtificado de
Inscripcion", "paginas": 8}
Imprimiendo Certtificado de Inscripcion ...
Hecho!
Se ha recibido un trabajo: {"operacion": "Generar", "documento": "Formulario de
Solicitud", "paginas": 9}
Generando Formulario de Solicitud ...
Hecho!
Se ha recibido un trabajo: {"operacion": "Imprimir", "documento": "Formulario de
Solicitud", "paginas": 9}
Imprimiendo Formulario de Solicitud ...
Hecho!
Se ha recibido un trabajo: {"operacion": "Registrar", "documento": "Certtificado de
Inscripcion", "paginas": 8}
Registrando Certtificado de Inscripcion ...
Hecho!
Se ha recibido un trabajo: {"operacion": "Generar", "documento": "Expediente Cliente",
"paginas": 3}
Generando Expediente Cliente ...
Hecho!
Se ha recibido un trabajo: {"operacion": "Generar", "documento": "Certtificado de
Inscripcion", "paginas": 5}
Generando Certtificado de Inscripcion ...
Hecho!
Administración
RabbitMQ, posee la posibilidad de realizar la administración del mismo desde consola o desde
su administrador web, para este último se debe habilitar el plugin RabbitMQ_management, el
cual permite acceder a una web de administración que también tiene su propio api rest. Los
usuarios de esta herramienta administrativa o del api, pueden tener distintos roles. Por defecto
trae un usuario guest con el mismo password. Con este usuario inicial, se pueden crear
usuarios administrativos con cada uno de los roles permitidos para acceder a la administración.
Habilitar interfaz web
RabbitMQ tiene la posibilidad de poder hacer uso de un conjunto de plugins, con el objetivo de
dotarle de posibilidades adicionales; un plugin bastante interesante es el que permite habilitar
una interfaz web para su administración.
RabbitMQ-plugins enable RabbitMQ_management
The following plugins have been enabled:
mochiweb
webmachine
RabbitMQ_web_dispatch
amqp_client
RabbitMQ_management_agent
RabbitMQ_management
Applying plugin configuration to rabbit@zeus... started 6 plugins
Dirección de acceso
http://localhost:15672/
Descripción de la Interfaz web de Administración
Página de Acceso
Pagina de Administración
Permite la Gestión de usuarios, virtualhosts y políticas de acceso
Gestión de Virtualhosts
Dashboard principal, que permite mostrar de forma gráfica, lo que acontece con el broker en
tiempo real.
Detalle de colas en funcionamiento
Detalle de las conexiones en uso
Detalle de canales que se hacen uso
Tipos de exhange disponibles
Conclusiones
Como se ha podido observar, son grandes y variadas las aplicaciones que se pueden dar a un
gestor de colas de mensajes o broker como RabbitMQ, entre las que destacan:
• Uso de un broker de mensajes para la interoperabilidad o acoplamiento de aplicaciones,
sin importar el lenguaje en que hayan sido desarrolladas cada una de éstas.
• En aplicaciones donde el tiempo de demora de ciertas operaciones no debería interferir
en el normal flujo de la aplicación, teniendo en cuenta que estas operaciones pueden ser
ejecutadas de forma asíncrona con la ayuda de broker de mensajes.
Referencias
[1] http://www.RabbitMQ.org

Más contenido relacionado

PDF
Tipos de conexiones de red
PDF
Especificación de Arquitectura de Software
PDF
Introducción al núcleo de las redes de telecomunicaciones (core networks)
PPTX
VIT 2-2014
PPT
telecomunicaciones y redes
PPTX
Transmision inalambrica
DOCX
Tabla comparativa ITIL y COBIT
Tipos de conexiones de red
Especificación de Arquitectura de Software
Introducción al núcleo de las redes de telecomunicaciones (core networks)
VIT 2-2014
telecomunicaciones y redes
Transmision inalambrica
Tabla comparativa ITIL y COBIT

La actualidad más candente (20)

PDF
Congestion control 1
PPTX
Gestión de Redes
PPTX
Protocolo ventana deslizante
PDF
Redes de siguiente generación (NGN)
PDF
Detección y Corrección de errores
PPT
IBM Websphere MQ Basic
PPTX
Transmission Control Protocol (TCP)
PDF
Implementación de hilos
PDF
Radio Frequencies for IoT
DOCX
16 x 16 banyan switch
PPTX
Telnet ppt
PPTX
Protocolo pop3
PDF
Introducción a Redes IP
PPTX
Mobile transport layer .
PPTX
2.3 procesos ligeros
PPTX
Telnet presentation
DOCX
introducción tecnologías web
PPTX
Olsr protocol ppt
PPTX
Destination Sequenced Distance Vector Routing (DSDV)
PPTX
Plan de gestion de configuración de software
Congestion control 1
Gestión de Redes
Protocolo ventana deslizante
Redes de siguiente generación (NGN)
Detección y Corrección de errores
IBM Websphere MQ Basic
Transmission Control Protocol (TCP)
Implementación de hilos
Radio Frequencies for IoT
16 x 16 banyan switch
Telnet ppt
Protocolo pop3
Introducción a Redes IP
Mobile transport layer .
2.3 procesos ligeros
Telnet presentation
introducción tecnologías web
Olsr protocol ppt
Destination Sequenced Distance Vector Routing (DSDV)
Plan de gestion de configuración de software
Publicidad

Similar a Rabbitmq (20)

PPTX
Rabbit mq
PPTX
SOA multiplataforma con rabbitmq y websockets
PDF
Mq conceptos y programacion as400
PPTX
Paso mensajes
KEY
RabbitMQ
PPTX
Patron de Arquitectura Broker
PDF
Introducción al protocolo AMQP
PDF
RabbitMQ y Symfony
PDF
Meetup En mi local funciona - Mi primer diseño con Apache Kafka
PDF
Rsqueue bundle 06.2013
ODP
Sistema de Mensajeria de Colas con ZeroMQ y Python
DOCX
Proyecto final teleprocesamiento
PDF
Clase redes
PDF
Clase redes
PPTX
SEMANA 6.pptx
DOC
Colas basadas en clases y mediciones
DOC
Colas basadas en clases y mediciones
DOC
Colas basadas en clases y mediciones
DOC
MATERIAL DE ESTUDIO
PPTX
Tema iv comunicación entre procesos
Rabbit mq
SOA multiplataforma con rabbitmq y websockets
Mq conceptos y programacion as400
Paso mensajes
RabbitMQ
Patron de Arquitectura Broker
Introducción al protocolo AMQP
RabbitMQ y Symfony
Meetup En mi local funciona - Mi primer diseño con Apache Kafka
Rsqueue bundle 06.2013
Sistema de Mensajeria de Colas con ZeroMQ y Python
Proyecto final teleprocesamiento
Clase redes
Clase redes
SEMANA 6.pptx
Colas basadas en clases y mediciones
Colas basadas en clases y mediciones
Colas basadas en clases y mediciones
MATERIAL DE ESTUDIO
Tema iv comunicación entre procesos
Publicidad

Más de Esteban Saavedra (20)

PDF
PDF
PDF
PDF
PDF
PDF
PDF
PDF
PDF
PDF
Lineas Base Migracion a Software Libre
PDF
Seguridad Sistemas de Gobierno
PDF
Tunneling: Esquivando Restricciones de Proxies y Firewalls
PDF
Bi Un Modelo Eficiente para Gerenciar Empresas
PDF
Clouds privadas
PDF
Introduccion Computacion Ubicua
PDF
Frameworks de Desarrollo Web Grails
PDF
Avances Tecnologicos
PDF
Dni Electronico Bolivia
PDF
E technologies
Lineas Base Migracion a Software Libre
Seguridad Sistemas de Gobierno
Tunneling: Esquivando Restricciones de Proxies y Firewalls
Bi Un Modelo Eficiente para Gerenciar Empresas
Clouds privadas
Introduccion Computacion Ubicua
Frameworks de Desarrollo Web Grails
Avances Tecnologicos
Dni Electronico Bolivia
E technologies

Último (20)

DOCX
TRABAJO GRUPAL (5) (1).docxjesjssjsjjskss
PPTX
CLAASIFICACIÓN DE LOS ROBOTS POR UTILIDAD
PDF
Estrategia de Apoyo de Daylin Castaño (5).pdf
PPTX
El uso de las TIC en la vida cotidiana..
PDF
Taller tecnológico Michelle lobo Velasquez
DOCX
TRABAJO GRUPAL (5) (1).docxjsjsjskskksksk
PPTX
Presentación final ingenieria de metodos
DOCX
Guía 5. Test de orientación Vocacional 2.docx
PPTX
Diapositivas Borrador Rocha Jauregui David Paolo (3).pptx
PPTX
Sistema de Gestión Integral TCA Ingenieros.pptx
DOCX
TRABAJO GRUPAL (5) (1).docxsjjsjsksksksksk
PDF
NREN - red nacional de investigacion y educacion en LATAM y Europa: Caracteri...
PPTX
Uso responsable de la tecnología - EEST N°1
PPTX
Mecanismos-de-Propagacion de ondas electromagneticas
PPTX
Tema 1 Taller de tecnologia y proceso tecnologico.pptx
PPTX
la-historia-de-la-medicina Edna Silva.pptx
PDF
Guía_de_implementación_Marco_de_gobierno_y_gestión_de_TI_Universidades.pdf
PPTX
Reconocimiento-Automatico-de-Placas-Vehiculares-con-IA.pptx
DOCX
Trabajo grupal.docxjsjsjsksjsjsskksjsjsjsj
PDF
Teoría de estadística descriptiva y aplicaciones .pdf
TRABAJO GRUPAL (5) (1).docxjesjssjsjjskss
CLAASIFICACIÓN DE LOS ROBOTS POR UTILIDAD
Estrategia de Apoyo de Daylin Castaño (5).pdf
El uso de las TIC en la vida cotidiana..
Taller tecnológico Michelle lobo Velasquez
TRABAJO GRUPAL (5) (1).docxjsjsjskskksksk
Presentación final ingenieria de metodos
Guía 5. Test de orientación Vocacional 2.docx
Diapositivas Borrador Rocha Jauregui David Paolo (3).pptx
Sistema de Gestión Integral TCA Ingenieros.pptx
TRABAJO GRUPAL (5) (1).docxsjjsjsksksksksk
NREN - red nacional de investigacion y educacion en LATAM y Europa: Caracteri...
Uso responsable de la tecnología - EEST N°1
Mecanismos-de-Propagacion de ondas electromagneticas
Tema 1 Taller de tecnologia y proceso tecnologico.pptx
la-historia-de-la-medicina Edna Silva.pptx
Guía_de_implementación_Marco_de_gobierno_y_gestión_de_TI_Universidades.pdf
Reconocimiento-Automatico-de-Placas-Vehiculares-con-IA.pptx
Trabajo grupal.docxjsjsjsksjsjsskksjsjsjsj
Teoría de estadística descriptiva y aplicaciones .pdf

Rabbitmq

  • 1. Dentro el desarrollo de un proyecto de software en muchas ocasiones hay que integrarse (acoplarse) con otros actores, componentes, o sistemas internos y externos, siendo necesario enviar o recibir información de ellos. En el mayor de los casos estas comunicaciones tienen que estar permanentemente disponibles, ser rápidas, seguras, asíncronas y fiables entre otros requisitos. Una de las mejores soluciones de acoplamiento de aplicaciones heterogéneas es el manejo de colas de mensajes. Introducción Las colas de mensajes (MQ) solucionan estas necesidades, actuando de intermediario entre emisores y destinatarios, o en un contexto más definido, productores y consumidores de mensajes. Se pueden usar para reducir las cargas y los tiempos de entrega por parte de los servidores de aplicaciones web, ya que las tareas, que normalmente tardarían bastante tiempo en procesarse, se pueden delegar a un tercero cuyo único trabajo es realizarlas. El uso de colas de mensajes también es bueno cuando se desea distribuir un mensaje a múltiples destinatarios para consumo o para realizar balanceo de carga entre trabajadores. Beneficios • Garantía de entrega y orden: Los mensajes se consumen, en el mismo orden que llegan, y son consumidos una única vez • Redundancia: Los mensajes en las colas persisten hasta que son procesados por completo • Desacoplamiento: Siendo capas intermedias de comunicación entre procesos, aportan la flexibilidad en la definición de arquitectura de cada uno de ellos de manera separada, siempre que se mantenga una interfaz común • Escalabilidad: Con más unidades de procesamiento, existe la posibilidad de crear más colas y de esta forma balancear su respectiva carga • Enrutamiento flexible: Basado en diferentes reglas de enrutamiento o selección de colas. • Clusterización: Capacidad de crecimiento horizontal • Federación: Provee un acceso común, a un conjunto de colas, dando la posibilidad de poderlas gestionar • Alta disponibilidad y Tolerancia a
  • 2. fallos: Capacidad de poder disponer redundancia ante posibles fallos ¿Qué es RabbitMQ? • RabbitMQ es un software de encolado de mensajes llamado broker de mensajería o gestor de colas. • RabbitMQ es un software de negociación de mensajes y entra dentro de la categoría de middleware de mensajería. • Es un software donde se pueden definir colas, las aplicaciones se pueden conectar a las mismas y transferir/leer mensajes en ellas. • RabbitMQ es un sistema gestor de colas de mensajes de código abierto que implementa el estándar AMQP (Advanced Message Queuing Protocol). Que es AMQP • AMQP - Advanced Message Queuing Protocol • Es un protocolo pensado para la interoperabilidad • Es un protocolo completamente abierto • Es un protocolo binario Modelo de AMQP Este modelo posee los siguientes elementos: • Intercambiadores (Exchanges) • Cola de mensajes (messages queues) • Enlaces (Bindings) • Reglas de Enrutamiento (Routing Rules) Características de RabbitMQ • Soporte a múltiples protocolos de mensajería: Directamente o mediante plugins programados, tales como AMQP 0-9-1, AMQP 1-0, STOMP, MQTT o HTTP. • Clientes: Existe una amplia variedad de clientes y conectores desarrollados para permitir la comunicación en una gran variedad de lenguajes tales como Java/JVM, MacOSXx, Amazon Ec2, C/C++, Ruby, Python, Perl, Erlang. • Interfaz de Usuario: Existe una UI muy completa que permite (entre otras muchas posibilidades), administrar los brokers generados (crear colas, exchanges, usuarios etc.) o incluso consultar el tráfico de mensajes en el sistema en tiempo real. • Permite agrupar diferentes nodos en un cluster que actúe como único broker lógico, admitiendo incluso políticas de alta disponibilidad y mirroring. • Permite establecer distintos brokers en una misma máquina, así como generar diferentes virtual hosts en los que ubicarlos. • Los brokers generados disponen de
  • 3. un sistema de logs que informan al administrador de las acciones que se están llevando a cabo sobre el mismo, facilitando la depuración de errores. ¿Cómo funciona? • Hay aplicaciones clientes, llamadas productores, que crean mensajes y los entregan al broker (cola de mensajes), otras aplicaciones, llamadas consumidores, se conectan a la cola y se suscriben para poder consumir los mensajes y procesarlos. Características de funcionamiento • Un mensaje puede incluir cualquier tipo de información. • Un software puede ser un productor, consumidor, o ambos simultáneamente. • Los mensajes colocados en la cola se almacenan hasta que el consumidor los recupera o los consume. • Los mensajes no se publican directamente en una cola, en lugar de eso, el productor envía mensajes a un exchange. Los exchanges son agentes de enrutamiento de mensajes. • Un exchange es responsable del enrutamiento de los mensajes a las diferentes colas: acepta mensajes del productor y los dirige a colas de mensajes con ayuda de atributos de cabeceras, bindings y routing keys. • Un binding es un “enlace” que se configura para vincular una cola a un exchange • Un routing key es un atributo del mensaje, este es utilizado por el exchange para decidir cómo enrutar el mensaje. • Los exchanges, los enlaces y las colas pueden configurarse con parámetros tales como durable, temporary, y auto delete en el momento de su creación. ◦ Los exchanges declarados como durable sobrevivirán a los reinicios del servidor y durarán hasta que se eliminen explícitamente. ◦ Aquellos de tipo temporary existen hasta que el Broker se cierre. ◦ Por último, los exchanges configurados como auto delete se eliminan una vez que el último objeto vinculado se ha liberado del exchange. Comunicación con el Broker Para establecer una comunicación con el broker, es necesario disponer de un usuario que esté registrado en el mismo. RabbitMQ permite establecer limitaciones en los usuarios que genera, bien mediante tags (administrator, policymaker, management o monitoring) o mediante cada virtual host al que este se encuentre asociado. Conceptos Útiles • Producer (Productor): Programa que escribe mensajes en un intercambiador (Exchange) • Consumer (Consumidor): Programa
  • 4. que escucha mensajes en una cola (Queue) • Exchange: Es el punto de entrada de un mensaje. • Queue: Es el punto de lectura de un mensaje. • Bindings: Son reglas que indican cómo llegar de un Exchange a las Queue asociadas. • Routing key: Filtro asociado a un Binging que permite seleccionar sólo algunos mensajes para dicho binding. • Virtual host o vhost: Un entorno aislado, con sus propios grupos de usuarios, exchanges, queues, ... Tipos de Exchange RabbitMQ tiene 4 tipos de exchange predefinidos: • Direct Exchange • Topic Exchange • Famout Exhange • Headers Exchange Funcionamiento estándar El funcionamiento básico o estándar que posee RabbitMQ es el siguiente: 1. El productor publica un mensaje para el exchange. 2. El exchange recibe el mensaje y es responsable del enrutamiento del mensaje. 3. Se debe establecer un enlace entre la cola y el exchange. En este caso, tenemos enlaces a dos colas diferentes del intercambio. El intercambio enruta el mensaje a las colas. 4. Los mensajes permanecen en la cola hasta que sean manejados por un consumidor 5. El consumidor maneja el mensaje Default Exchange El default exchange es un intercambio directo pre-declarado sin nombre, generalmente está referido por una cadena vacía "". Cuando usa el intercambio predeterminado, su mensaje será entregado a la cola con un nombre igual a la clave de enrutamiento del mensaje. Cada cola se enlaza automáticamente al intercambio predeterminado con una clave de enrutamiento que es igual que el nombre de la cola. Direct Exchange
  • 5. Un intercambio directo entrega mensajes a colas basadas en una clave de enrutamiento de mensajes. La clave de enrutamiento es un atributo del mensaje agregado al encabezado (header) del mensaje por el productor. La clave de enrutamiento se puede ver como una "dirección" que el exchange está utilizando para decidir cómo enrutar el mensaje. Un mensaje va a la (s) cola (s) cuya clave de enlace coincide exactamente con la clave de enrutamiento del mensaje. Ejemplo: Se envía un mensaje con la clave de enrutamiento pdf_log al exchange pdf_events. Los mensajes se enrutan a pdf_log_queue porque la clave el rounting key (pdf_log) coincide con el binding key (pdf_log). Si la clave de enrutamiento de mensajes no coincide con ninguna clave de enlace, el mensaje será descartado. Topic Exchange Los intercambios temáticos o por tópicos enrutan mensajes a colas basadas en coincidencias de comodines entre la clave de enrutamiento y algo llamado el patrón de enrutamiento. Los mensajes se enrutan a una o varias colas en función de una coincidencia entre una clave de enrutamiento de mensaje y este patrón. La clave de enrutamiento debe ser una lista de palabras, delimitada por un punto (.). Para el ejemplo de la gráfica: agreements.us y agreements.eu.stockholm, identifican los acuerdos que se establecen para una empresa con oficinas en muchos lugares diferentes. Los patrones de enrutamiento pueden contener un asterisco ("*") para hacer coincidir una palabra en una posición específica de la clave de enrutamiento (por ejemplo, un patrón de enrutamiento de "agreements. *. *. b. *" Solo coincidirá con claves de enrutamiento donde la primera palabra es "agreements" y la cuarta palabra es "b"). El símbolo "#" indica coincidencia en cero o más palabras (por ejemplo, un patrón de enrutamiento de "agreements.eu.berlin.#" Coincide con cualquier clave de enrutamiento que comience por "agreements.eu.berlin"). Ejemplo Se envía un mensaje con la clave de enrutamiento agreements.eu.berlin a los acuerdos de intercambio. Los mensajes se enrutan a la cola berlin_agreements porque el patrón de enrutamiento de "agreements.eu.berlin.#" coincide, asi también se enruta a la cola all_agreements porque la clave de enrutamiento (agreements.eu.berlin) coincide con el patrón de enrutamiento (agreements. #).
  • 6. Fanout Exchange El exchange Fanot copia y enruta un mensaje recibido a todas las colas que están vinculadas a él, independientemente de las claves de enrutamiento o la coincidencia de patrones como con los intercambios directos y de temas. Las llaves proporcionadas simplemente serán ignoradas. Los intercambios de Fanout pueden ser útiles cuando el mismo mensaje debe enviarse a una o más colas con consumidores que pueden procesar el mismo mensaje de diferentes maneras. La gráfica muestra un ejemplo en el que un mensaje recibido por el intercambio se copia y enruta a las tres colas que están vinculadas al intercambio. Ejemplo Se envía un mensaje al intercambio sport_news. El mensaje se enruta a todas las colas (Cola A, Cola B, Cola C) porque todas las colas están vinculadas al intercambio. Siempre que se ignoren las claves de enrutamiento. Header Exchange El header exchange intercambia la ruta en función de los argumentos que contienen encabezados y valores opcionales. Son muy similares a los Topic Exchange, pero se enruta en función de los valores de encabezado en lugar de las claves de enrutamiento. Un mensaje se considera coincidente si el valor del encabezado es igual al valor especificado al vincularse. La propiedad "x-match" puede tener dos valores diferentes: "any" o "all", donde "all" es el valor predeterminado. Un valor de "all" significa que todos los pares de encabezado (clave, valor) deben coincidir y un valor de "any" significa que al menos uno de los pares de encabezado debe coincidir. El argumento "any"es útil para dirigir mensajes que pueden contener un subconjunto de criterios conocidos (desordenados).
  • 7. Instalación apt install RabbitMQ-server Gestión del servicio Activar desde el arranque systemctl enable RabbitMQ-server Iniciar el servicio systemctl start RabbitMQ-server Detener el servicio systemctl stop RabbitMQ-server Crear un usuario admin Por defecto RabbitMQ crea un usuario guest con contraseña guest, pero existe la posibilidad de crear mas usuarios con diferentes atribuciones. • Crear usuario RabbitMQctl add_user admin password • Asignar rol de administrador RabbitMQctl set_user_tags admin administrator • Privilegios sobre un vhost RabbitMQctl set_permissions -p / admin ".*" ".*" ".*" Interacción con Python Para el siguiente ejemplo haremos uso de la PIKA una librería de python para el manejo de RabbitMQ Instalación pip install pika • Conexión conexion = pika.BlockingConnection(pika.ConnectionParameters(host='localhost')) • Apertura del canal canal = conexion.channel() • Cerrar conexión conexion.close() • Declaración de la cola canal.queue_declare(queue='prueba') • Envío de mensajes Esta parte puede ser la parte complicada ya que puede establecer el tipo de exchange, la cola de destino, el cuerpo del mensaje. En el ejemplo establecemos que la cola destino por defecto esta establecida por routing_key.
  • 8. canal.basic_publish(exchange='', routing_key='prueba', body='Hola Mundo') productor.py import pika # Establecer conexión conexion = pika.BlockingConnection(pika.ConnectionParameters(host='localhost')) canal = conexion.channel() # Declarar la cola canal.queue_declare(queue='prueba') # Publicar el mensaje canal.basic_publish(exchange='', routing_key='prueba', body='Fundación AtixLibre') print("Mensaje enviado.") # Cerrar conexión conexion.close() Ejecución del programa productor $ python productor.py Mensaje enviado. Verificación del estado de la cola Debemos recordar que la entrega de mensajes es asíncrona, lo que representa que el mensaje permanecerá en la cola, hasta que algún programa o aplicación la consuma. Estado de la cola de mensajes $ RabbitMQctl list_queues Listing queues … prueba 1 Recepción de mensajes • Suscripción Antes de poder recibir los mensajes, es necesario realizar una suscripción, la cual nos permita recibir una llamada cada vez que haya un mensaje en cola, este proceso se llama callback. def recepcion(canal, method, properties, body): print("Mensaje en cola: %s" % body) • Enlazar con la recepción canal.basic_consume(recepcion, queue='prueba', no_ack=True) donde: • queue='prueba': Cola a la que se enlaza • no_ack=True: Elimina el mensaje cuando sea servido
  • 9. • Esperar otros mensajes canal.start_consuming() consumidor.py import pika # Establecer conexión conexion = pika.BlockingConnection(pika.ConnectionParameters(host='localhost')) canal = conexion.channel() # Declarar la cola canal.queue_declare(queue='prueba') # Definir la función callback def recepcion(ch, method, properties, body): print("Mensaje en cola: %s" % body) # Enganchar el callback canal.basic_consume(recepcion, queue='prueba', no_ack=True) # Poner en espera print('Esperando mensajes...') canal.start_consuming() Ejecución del consumidor $ python consumidor.py Esperando mensajes... Mensaje en cola: b'Fundación AtixLibre' Estado de la cola $ RabbitMQctl list_queues Listing queues ... prueba 0 Simulación de un Entorno de Demostración Para una mejor comprensión realizaremos un conjunto de programas que nos permitan realizar la simulación de la gestión de una cola de mensajes para realizar diferentes operaciones (Registrar, Generar e Imprimir) sobre distintos tipos de documentos (Formulario de Solicitud, Expediente Cliente, Certificado de Inscripción), donde cada uno de estos puede tener cierto número de páginas. Descripción de Programas El entorno posee los siguientes programas con las diferentes funciones: • productor.py: Programa orientado a enviar o publicar los diferentes trabajos a la cola de mensajes • consumidor.py: Programa orientado a recuperar los diferentes trabajos que se encuentran en la cola de mensajes • operaciondocumento.py: Programa orientado a simular de forma aleatoria el tipo de documento, el tipo de trabajo a realizar, el numero de paginas de cada tipo de documento y simular la ejecución de cada uno de estos de a cuerdo a las características ya descritas.
  • 10. • trabajo.py: programa orientado a realizar la definición de la clase trabajo, con sus diferentes atributos y los métodos de importar y exportar que permiten serializar los datos del mismo para ser enviados como cuerpo del mensaje a la cola respectiva. productor.py import pika from trabajo import Trabajo from operaciondocumento import documento, operacion, paginas, ejecutar from random import randint import time # Establecer conexión conexion = pika.BlockingConnection(pika.ConnectionParameters(host='localhost')) canal = conexion.channel() # Declarar la cola canal.queue_declare(queue='gestion_documentos') # Bucle infinito while True: # Tiempo aleatorio antes de lanzar el siguiente trabajo time.sleep(randint(1,2)) # Generar un trabajo t = Trabajo(operacion(), documento(), paginas()) # Publicar el mensaje canal.basic_publish(exchange='', routing_key='gestion_documentos', body=t.exportar().encode('utf-8')) print("Trabajo enviado a la cola: %s" % t.exportar()) consumidor.py import pika from trabajo import Trabajo from operaciondocumento import ejecutar # Establecer conexión conexion = pika.BlockingConnection(pika.ConnectionParameters(host='localhost')) canal = conexion.channel() # Declarar la cola canal.queue_declare(queue='gestion_documentos') # Definir la función callback def procesar(canal, method, properties, body): datos = body.decode('utf-8') print("Se ha recibido un trabajo: %s" % datos) t = Trabajo.importar(datos) ejecutar(t) canal.basic_ack(delivery_tag=method.delivery_tag) # Enganchar el callback canal.basic_consume(procesar, queue='gestion_documentos') # Poner en espera print('Esperando trabajos...') canal.start_consuming()
  • 11. operaciondocumento.py import time from random import randint def documento (): a = randint(1,3) if a == 1: td='Formulario de Solicitud' elif a == 2: td='Expediente Cliente' elif a == 3: td='Certtificado de Inscripcion' return td def operacion (): b = randint(1,3) if b == 1: ops='Generar' elif b == 2: ops='Imprimir' elif b == 3: ops='Registrar' return ops def paginas(): return randint(1,10) def ejecutar(trabajo): if trabajo.operacion == 'Generar': print('Generando %s ...' % trabajo.documento) time.sleep(2) print('Hecho!') elif trabajo.operacion == 'Imprimir': print('Imprimiendo %s ...' % trabajo.documento) time.sleep(2) print('Hecho!') elif trabajo.operacion == 'Registrar': print('Registrando %s ...' % trabajo.documento) time.sleep(2) print('Hecho!') else: raise NotImplementedError('Operación "%s" no soportada.' % trabajo.operacion) trabajo.py import json class Trabajo: def __init__(self, operacion, documento, paginas=None): self.operacion = operacion self.documento = documento self.paginas = paginas def exportar(self): return json.dumps(self.__dict__) @classmethod def importar(cls, datos): dic = json.loads(datos) return cls(dic['operacion'], dic['documento'], dic['paginas'])
  • 12. Ejecución del productor.py $ python productor.py Trabajo enviado a la cola: {"operacion": "Generar", "documento": "Formulario de Solicitud", "paginas": 6} Trabajo enviado a la cola: {"operacion": "Imprimir", "documento": "Formulario de Solicitud", "paginas": 2} Trabajo enviado a la cola: {"operacion": "Imprimir", "documento": "Certtificado de Inscripcion", "paginas": 8} Trabajo enviado a la cola: {"operacion": "Generar", "documento": "Formulario de Solicitud", "paginas": 9} Trabajo enviado a la cola: {"operacion": "Imprimir", "documento": "Formulario de Solicitud", "paginas": 9} Trabajo enviado a la cola: {"operacion": "Registrar", "documento": "Certtificado de Inscripcion", "paginas": 8} Trabajo enviado a la cola: {"operacion": "Generar", "documento": "Expediente Cliente", "paginas": 3} Trabajo enviado a la cola: {"operacion": "Registrar", "documento": "Formulario de Solicitud", "paginas": 7} Trabajo enviado a la cola: {"operacion": "Imprimir", "documento": "Expediente Cliente", "paginas": 7} Trabajo enviado a la cola: {"operacion": "Generar", "documento": "Expediente Cliente", "paginas": 7} Trabajo enviado a la cola: {"operacion": "Registrar", "documento": "Formulario de Solicitud", "paginas": 9} Trabajo enviado a la cola: {"operacion": "Registrar", "documento": "Expediente Cliente", "paginas": 7} Ejecución del consumidor.py $ python consumidor.py Esperando trabajos... Se ha recibido un trabajo: {"operacion": "Generar", "documento": "Formulario de Solicitud", "paginas": 6} Generando Formulario de Solicitud ... Hecho! Se ha recibido un trabajo: {"operacion": "Imprimir", "documento": "Formulario de Solicitud", "paginas": 2} Imprimiendo Formulario de Solicitud ... Hecho! Se ha recibido un trabajo: {"operacion": "Imprimir", "documento": "Certtificado de Inscripcion", "paginas": 8} Imprimiendo Certtificado de Inscripcion ... Hecho! Se ha recibido un trabajo: {"operacion": "Generar", "documento": "Formulario de Solicitud", "paginas": 9} Generando Formulario de Solicitud ... Hecho! Se ha recibido un trabajo: {"operacion": "Imprimir", "documento": "Formulario de Solicitud", "paginas": 9} Imprimiendo Formulario de Solicitud ... Hecho! Se ha recibido un trabajo: {"operacion": "Registrar", "documento": "Certtificado de Inscripcion", "paginas": 8} Registrando Certtificado de Inscripcion ... Hecho! Se ha recibido un trabajo: {"operacion": "Generar", "documento": "Expediente Cliente", "paginas": 3} Generando Expediente Cliente ... Hecho! Se ha recibido un trabajo: {"operacion": "Generar", "documento": "Certtificado de Inscripcion", "paginas": 5} Generando Certtificado de Inscripcion ... Hecho!
  • 13. Administración RabbitMQ, posee la posibilidad de realizar la administración del mismo desde consola o desde su administrador web, para este último se debe habilitar el plugin RabbitMQ_management, el cual permite acceder a una web de administración que también tiene su propio api rest. Los usuarios de esta herramienta administrativa o del api, pueden tener distintos roles. Por defecto trae un usuario guest con el mismo password. Con este usuario inicial, se pueden crear usuarios administrativos con cada uno de los roles permitidos para acceder a la administración. Habilitar interfaz web RabbitMQ tiene la posibilidad de poder hacer uso de un conjunto de plugins, con el objetivo de dotarle de posibilidades adicionales; un plugin bastante interesante es el que permite habilitar una interfaz web para su administración. RabbitMQ-plugins enable RabbitMQ_management The following plugins have been enabled: mochiweb webmachine RabbitMQ_web_dispatch amqp_client RabbitMQ_management_agent RabbitMQ_management Applying plugin configuration to rabbit@zeus... started 6 plugins Dirección de acceso http://localhost:15672/ Descripción de la Interfaz web de Administración Página de Acceso
  • 14. Pagina de Administración Permite la Gestión de usuarios, virtualhosts y políticas de acceso Gestión de Virtualhosts
  • 15. Dashboard principal, que permite mostrar de forma gráfica, lo que acontece con el broker en tiempo real. Detalle de colas en funcionamiento
  • 16. Detalle de las conexiones en uso Detalle de canales que se hacen uso
  • 17. Tipos de exhange disponibles Conclusiones Como se ha podido observar, son grandes y variadas las aplicaciones que se pueden dar a un gestor de colas de mensajes o broker como RabbitMQ, entre las que destacan: • Uso de un broker de mensajes para la interoperabilidad o acoplamiento de aplicaciones, sin importar el lenguaje en que hayan sido desarrolladas cada una de éstas. • En aplicaciones donde el tiempo de demora de ciertas operaciones no debería interferir en el normal flujo de la aplicación, teniendo en cuenta que estas operaciones pueden ser ejecutadas de forma asíncrona con la ayuda de broker de mensajes. Referencias [1] http://www.RabbitMQ.org