Este año he comenzado leyendo. Al igual que muchos, me he propuesto aprender nuevos conocimientos y los elegidos para este mes de enero han sido RabbitMQ, Elixir y FreeBSD. El primero lo hago de la mano de Álvaro Videla y Jason J.W. Williams, a través de su libro RabbitMQ In Action. La primera pregunta a resolver: ¿Para qué necesitamos un sistema de encolado de mensajes?
Como mencionan al inicio del libro, ambos autores se conocieron después de vivir una experiencia similar y casi al unísono donde debían resolver una problemática concreta dentro de sus respectivas empresas y ambos emplearon RabbitMQ. En este libro exponen una temática básica en los primeros capítulos, de nivel medio en los capítulos intermedios y de alto nivel en su culminación. Es un repaso completo a todos los aspectos necesarios para poder emplear este tipo de soluciones. Pero, ¿para qué emplearíamos un sistema de encolado de mensajes?
¿Qué es un MQ?
En sus siglas inglesas MQ hace referencia a message queue (cola de mensajes). Es un patrón de diseño de sistemas que se comenzó a utilizar a principio de los 80. Se compone de un corredor (broker) encargado de acumular los mensajes provenientes de los productores (producers). Estos mensajes se almacenan en una serie de colas. A estas colas están suscritos los consumidores (consumers) que obtienen los mensajes al ritmo que los necesitan.
El inicio de este tipo de sistemas fue en entornos bancarios. La idea es que los productores generen mensajes, operaciones a realizar dentro del sistema. Según la cola donde se almacena el mensaje, llegará a uno o varios consumidores que podrán realizar una acción concreta. La ventaja de este sistema en contraposición al método típico de la función (o procedimiento) es su naturaleza asíncrona, el control de la cantidad de operaciones a realizar y la posibilidad de paralelizar acciones. Esto es gracias a que el mensaje puede llegar a dos consumidores diferentes encargados de realizar acciones independientes.
Problemática a resolver
A través de los últimos años el uso de Internet viene marcado por siglas como SaaS, PaaS, IaaS, ... todas ellas indicando una misma tendencia: la venta de servicios en lugar de productos. Esto acarrea una posición ventajosa para los desarrolladores de software pudiendo dar a sus clientes siempre la última versión del software mantenido en un único lugar y su pago reducido (en comparación al del producto) a través de una cuota periódica.
Pero también acarrea el problema de tener ejecutar el software en una misma infraestructura servidora para todos los clientes que desean utilizarlo al mismo tiempo.
En sistemas síncronos de cliente-servidor donde las peticiones son enviadas a un mismo punto y el cliente espera puede producirse el efecto avalancha. Recibir en un momento dado demasiadas peticiones para las cuales el sistema no está suficientemente bien dimensionado.
Respuestas asíncronas y encolado
La mejor solución ante este problema es dividir y acumular (o encolar). Ante la avalancha de peticiones el sistema puede atender rápidamente todas las llamadas respondiendo valores temporales. Empleando nuevas llamadas vía AJAX o websocket el servidor puede responder una vez se haya completado la tarea. Esto da la posibilidad al servidor intermediario de presentar otro nivel de información acerca de la espera, o incluso dejar libre al cliente para que pueda realizar más acciones.
El servidor sería en este caso un productor. Cada petición entrante del cliente la convierte en un mensaje obteniendo toda la información posible y la envía al sistema de encolado. En otro nivel y dependiendo de los recursos necesarios para resolver estas tareas, se encuentran los consumidores. Estos se encargan de tomar mensajes del broker y procesarlos.
La diferencia principal es la posibilidad de acumular todos los estados en momentos de alta carga y procesarlos poco a poco. En lugar de obtener una caída por denegación de servicio, se obtendría una demora en el procesamiento de mensajes. Este es el motivo por el que se comenzó empleando en entornos bancarios donde la velocidad no es tan importante como el hecho de realizar la operación de forma fiable.
Administración de MQ
Además de exponer los entornos y su uso, el libro se orienta también para los administradores de sistemas. Muestra como administrar RabbitMQ, configurar Nagios, controlar las colas y su correcto funcionamiento.
Cubre también la configuración de RabbitMQ no solo en un centro de datos (CPD) sino también cuando se quiere o necesita configurar en varias regiones geográficas. Posibles fallos, formas de replicación y funcionamiento.
¡Y con MQTT también!
A través del artículo XMPP y MQTT hice una pequeña introducción sobre el protocolo MQTT. Un protocolo diseñado para la transmisión de mensajes de forma segura sobre redes de conectividad intermitente o con grandes pérdidas de señal. Desgraciadamente, con los dispositivos móviles ese tipo de escenario no es difícil de replicar, dependiendo de la zona geográfica donde nos encontremos, si estamos en movimiento, si pasamos por túneles, los edificios tienen muros gruesos, etc.
RabbitMQ además de disponer de los protocolos más famosos de encolado de mensajes: STOMP y AMQP; también dispone del protocolo MQTT a través de una extensión que puede instalarse siguiendo la documentación de la web oficial. Una opción muy a tener en cuenta para la construcción de sistemas de mensajería orientado a redes móviles.
Conclusiones
Buen texto y con una grata expresión. Se hace ameno de leer y es muy completo con ejemplos de código en Python y PHP, además de algunas notas y guías para Erlang, Java y C#. Muy recomendable.
¿Y tú? ¿empleas sistemas MQ en tus desarrollos en Internet?, ¿planeas emplear sistemas asíncronos similares?
