¿Está buscando un sistema de colas? ¿O tal vez busca uno mejor? ¡Aquí tiene toda la información que necesita!
Los sistemas de colas son el secreto mejor guardado del desarrollo backend.
Sin pretender escribir un poema en alabanza de los sistemas de colas, diría que un desarrollador backend junior se convierte en un desarrollador backend de nivel medio en cuanto aprende a integrar las colas en el sistema. Las colas mejoran la experiencia del cliente (ya veremos cómo), reducen la complejidad y mejoran la fiabilidad de un sistema.
Sin duda, para aplicaciones web muy sencillas con tráfico casi nulo y sitios web de folletos, las colas pueden ser un todo (o incluso imposibles de instalar si se está en un entorno típico de alojamiento compartido), pero todas las aplicaciones no triviales se beneficiarán de los sistemas de colas, y las aplicaciones grandes son imposibles sin colas de por medio.
Antes de empezar, un descargo de responsabilidad: si ya se siente cómodo con los sistemas de colas y desea comparar las distintas opciones, las próximas secciones introductorias le inducirán un sueño importante 🙂 Así que siéntase libre de seguir adelante. Las secciones introductorias están pensadas para quienes sólo tienen una idea vaga de los sistemas de colas o sólo han oído el nombre de pasada.
¿Qué es un sistema de colas?
Empecemos por entender qué es una cola.
Una cola es una estructura de datos en informática que imita, bueno, las colas del mundo real que vemos a nuestro alrededor. Si va a una taquilla, por ejemplo, se dará cuenta de que tendrá que colocarse al final de la cola, mientras que la persona al principio de la cola obtendrá primero el billete. Esto es lo que también llamamos el fenómeno del «primero en llegar, primero en ser atendido». En informática, es posible escribir programas que almacenen sus tareas de este modo en una cola, procesándolas una a una según el mismo orden de llegada.
Tenga en cuenta que la cola no realiza ningún procesamiento real por sí misma. Es sólo una especie de almacenamiento temporal donde las tareas esperan hasta que son recogidas por algo. Si todo esto suena demasiado abstracto, no se preocupe. Es un concepto abstracto, pero veremos ejemplos claros en la siguiente sección. 🙂
¿Por qué necesita sistemas de colas?
Sin entrar en una descripción muy larga, diría que la principal necesidad de los sistemas de colas se debe al procesamiento en segundo plano, la ejecución paralela y la recuperación ante fallos. Veámoslos con la ayuda de ejemplos:
Procesamiento en segundo plano
Supongamos que está llevando a cabo una campaña de marketing de comercio electrónico en la que el tiempo es esencial, y que su aplicación está construida de forma que dispara un correo electrónico de confirmación justo antes de que el cliente complete el pago y se le muestre la página de «gracias». Si el servidor de correo al que se está conectando se cae, la página web morirá sin más, rompiendo la experiencia del usuario.
Imagine el elevado número de solicitudes de asistencia que recibiría En este caso, es mejor empujar esta tarea de envío de correo electrónico a una cola de trabajo y mostrar al cliente la página de éxito.
Ejecución paralela
Muchos desarrolladores, especialmente los que en su mayoría codifican aplicaciones más sencillas y con poco tráfico, tienen la costumbre de utilizar cron jobs para el procesamiento en segundo plano. Esto está bien hasta que el tamaño de la entrada crece tanto que no se puede borrar. Por ejemplo, suponga que tiene una tarea cron que compila informes analíticos y los envía por correo electrónico a los usuarios y que su sistema puede procesar 100 informes por minuto.
En cuanto su aplicación crezca y empiece a recibir más de 100 peticiones por minuto de media, empezará a retrasarse cada vez más y nunca podrá completar todos los trabajos.
En un sistema de colas, esta situación puede evitarse configurando múltiples trabajadores, que pueden elegir cada uno un trabajo (que contenga 100 informes a realizar cada uno) y trabajar en paralelo para terminar la tarea mucho, mucho antes.
Recuperación en caso de fallo
Generalmente no pensamos en el fracaso como desarrolladores web. En cierto modo, damos por sentado que nuestros servidores y las API que utilizamos siempre estarán en línea. Pero la realidad es diferente: los cortes de red son demasiado comunes y las excelentes API de las que depende pueden estar caídas por problemas de infraestructura (antes de que diga «¡yo no!», no olvide el corte masivo de Amazon S3). Así que, volviendo al ejemplo de los informes, si parte de su generación de informes requiere que se conecte a la API de pagos y esa conexión se cae durante 2 minutos, ¿qué ocurre con los 200 informes que fallaron?
Sin embargo, los sistemas de colas implican unos gastos generales considerables. La curva de aprendizaje es bastante pronunciada, ya que está entrando en un dominio completamente nuevo, la complejidad de su aplicación y despliegue aumenta y los trabajos en cola no siempre pueden controlarse con una precisión del 100%. Dicho esto, hay situaciones en las que construir una aplicación sin colas simplemente no es posible.
Con eso fuera del camino, echemos un vistazo a algunas de las opciones comunes entre los backends/sistemas de colas hoy en día.
Redis
Redis es conocido como un almacén de clave-valor que se limita a almacenar, actualizar y recuperar cadenas de datos sin conocimiento de la estructura de los mismos. Aunque eso podría haber sido cierto antes, hoy Redis tiene estructuras de datos eficientes y muy útiles como listas, conjuntos ordenados e incluso un sistema Pub-Sub, lo que lo hace muy deseable para implementaciones de colas.
Las ventajas de Redis son:
- Base de datos completamente en memoria, lo que se traduce en lecturas/escrituras más rápidas.
- Altamente eficiente: Puede soportar fácilmente más de 100.000 operaciones de lectura/escritura por segundo.
- Esquema de persistencia altamente flexible. Puede optar por el máximo rendimiento a costa de una posible pérdida de datos en caso de fallos o configurarlo en modo totalmente conservador para sacrificar rendimiento por consistencia.
- Clusters soportados out of the box
Tenga en cuenta que Redis no dispone de ninguna abstracción de mensajería/colas/recuperación, por lo que deberá utilizar un paquete o crear usted mismo un sistema ligero. Un ejemplo es que Redis es el backend de cola por defecto para el framework PHP Laravel, donde un planificador ha sido implementado por los autores del framework.
Aprender Red is es fácil.
RabbitMQ
Hay algunas diferencias sutiles entre Redis y RabbitMQ, así que vamos a quitarlas de en medio primero.
En primer lugar, RabbitMQ tiene un papel más especializado y bien definido, por lo que se construyó para reflejar eso: la mensajería. En otras palabras, su punto dulce es actuar como intermediario entre dos sistemas, lo que no es el caso de Redis, que actúa como base de datos. Como resultado, RabbitMQ proporciona algunas facilidades más que faltan en Redis: enrutamiento de mensajes, reintentos, distribución de carga, etc.
Si lo piensa, las colas de tareas también pueden considerarse un sistema de mensajería, en el que el programador, los trabajadores y los «remitentes» de trabajos pueden considerarse entidades que participan en el paso de mensajes.
RabbitMQ tiene las siguientes ventajas:
- Mejores abstracciones para el paso de mensajes, reduciendo el trabajo a nivel de aplicación si lo que necesita es el paso de mensajes.
- Más resistente a fallos y cortes de energía (que Redis, al menos por defecto).
- Soporte de clúster y federación para despliegues distribuidos.
- Herramientas útiles para gestionar y supervisar sus despliegues.
- Soporte para prácticamente todos los lenguajes de programación no triviales que existen.
- Despliegue con la herramienta de su elección (Docker, Chef, Puppet, etc.).
¿Cuándo utilizar RabbitMQ? Yo diría que es una gran elección cuando sabe que necesita utilizar el paso de mensajes asíncronos pero no está preparado para enfrentarse a la enorme complejidad de algunas de las otras opciones de colas de esta lista (véase más abajo).
ActiveMQ
Si está en el espacio empresarial (o construyendo una aplicación altamente distribuida y a gran escala), y no quiere tener que reinventar la rueda todo el tiempo (y cometer errores por el camino), merece la pena echar un vistazo a ActiveMQ.
Aquí es donde ActiveMQ sobresale:
- Está implementado en Java y, por tanto, tiene una integración con Java realmente buena (sigue el estándar JMS).
- Soporta múltiples protocolos: AMQP, MQTT, STOMP, OpenWire, etc.
- Gestiona la seguridad, el enrutamiento, la caducidad de los mensajes, el análisis, etc., desde el primer momento.
- Compatible con los patrones de mensajería distribuida más populares, lo que le ahorrará tiempo y costosos errores.
Esto no quiere decir que ActiveMQ sólo esté disponible para Java. Dispone de clientes para Python, C/C , Node, .Net y otros ecosistemas, por lo que no debería preocuparle un posible colapso en el futuro. Además, ActiveMQ está construido sobre estándares completamente abiertos y construir sus propios clientes ligeros debería ser fácil.
Dicho todo esto, tenga en cuenta que ActiveMQ es sólo un broker y no incluye un backend. Aún necesitaría utilizar uno de los backends soportados para almacenar los mensajes. Lo incluí aquí porque no está atado a un lenguaje de programación en particular (como otras soluciones populares como Celery, Sidekiq, etc.)
Amazon MQ
AmazonMQ merece una rápida pero importante mención aquí. Si cree que ActiveMQ es la solución ideal para sus necesidades pero no quiere ocuparse de construir y mantener la infraestructura usted mismo, Amazon MQ ofrece un servicio gestionado para hacerlo. Soporta todos los protocolos que hace ActiveMQ — no hay ninguna diferencia en cuanto a características — ya que utiliza el propio ActiveMQ bajo la superficie.
La ventaja es que es un servicio gestionado, por lo que no tiene que preocuparse de nada más que de utilizarlo. Tiene aún más sentido para los despliegues que están en AWS, ya que puede aprovechar otros servicios y ofertas directamente desde su despliegue (transferencias de datos más rápidas, por ejemplo).
Amazon SQS
No podemos esperar que Amazon se quede quieto cuando se trata de piezas de infraestructura críticas, ¿verdad? 🙂
Y así tenemos Amazon SQS, que es un servicio de colas sencillo y totalmente alojado (literalmente) por el conocido gigante AWS. Una vez más, las sutiles diferencias son importantes, así que tenga en cuenta que SQS no tiene el concepto de paso de mensajes. Al igual que Redis, es un simple backend para aceptar y distribuir trabajos en colas.
Entonces, ¿cuándo querría utilizar Amazon SQS? He aquí algunas razones:
- Usted es un fanático de AWS y no tocará nada más (sinceramente, hay mucha gente así, y creo que no hay nada malo en ello).
- Necesita una solución alojada para asegurarse de que la tasa de fallos es cero y no se pierde ninguno de los trabajos.
- No quiere construir un cluster y tener que monitorizarlo usted mismo. O peor aún, tener que construir herramientas de monitorización cuando podría estar utilizando ese tiempo para hacer un desarrollo productivo.
- Ya ha realizado inversiones sustanciales en la plataforma de AWS y permanecer bloqueado tiene sentido desde el punto de vista empresarial.
- Quiere un sistema de colas centrado y sencillo sin ninguna de las tonterías asociadas al paso de mensajes, protocolos y demás.
En definitiva, Amazon SQS es una opción sólida para cualquiera que desee incorporar colas de trabajo a su sistema y no tener que preocuparse de instalar/supervisar las cosas por sí mismo.
Beanstalkd
Beanstalkd existe desde hace mucho tiempo y es un backend probado en batalla, rápido y sencillo para colas de trabajos. Hay algunas características de Beanstalkd que lo diferencian considerablemente de Redis:
- Es estrictamente un sistema de cola de trabajos y nada más. Usted empuja trabajos a él, que son tirados por los trabajadores de trabajo más tarde. Así que si su aplicación tiene la más mínima necesidad de paso de mensajes, le conviene evitar Beanstalkd.
- No hay estructuras de datos avanzadas como conjuntos, colas de prioridad, etc.
- Beanstalkd es lo que se denomina una cola FIFO (First In, First Out). No hay forma de ordenar los trabajos por prioridad.
- No hay opciones de agrupación.
Dicho esto, Beanstalkd es un sistema de colas hábil y rápido para proyectos sencillos que viven en un único servidor. Para muchos, es más rápido y más estable que Redis. Así que si usted está teniendo problemas con Redis que simplemente no puede resolver no importa qué, y sus necesidades son simples, Beanstalkd vale la pena intentarlo.
Conclusión
Si ha leído hasta aquí (o ha llegado hasta aquí leyendo por encima 😉 ), es muy probable que esté interesado en los sistemas de colas o que necesite uno. Si es así, la lista de esta página le servirá bien, a menos que esté buscando un sistema de colas específico para un lenguaje/marco.
Ojalá pudiera decirle que el sistema de colas es sencillo y fiable al 100%, pero no lo es. Es desordenado, y como todo está en segundo plano y sucede muy rápido (los errores pueden pasar desapercibidos y volverse muy costosos). Aun así, las colas son muy necesarias hasta cierto punto, y descubrirá que son un arma poderosa (quizá incluso la más poderosa) de su arsenal. ¡Buena suerte! 🙂