Colas y tareas en segundo plano en Rust: escribiendo un worker asíncrono en una hora

Colas y tareas en segundo plano en Rust: escribiendo un worker asíncrono en una hora

¿Alguna vez te has preguntado por qué tu servicio web a veces se "ralentiza" cuando el usuario hace clic en el botón "Enviar"? La mayoría de las veces, la culpa la tienen las operaciones pesadas que se ejecutan directamente durante el procesamiento de la solicitud. Envío de correos electrónicos, generación de PDF, procesamiento de imágenes, integración con API externas: todo esto debería vivir su propia vida, no bloquear la respuesta al usuario. La solución son las colas y las tareas en segundo plano.

Y si estás acostumbrado a resolver este problema en Python con Celery o RQ, en Rust te espera una sorpresa. Rust no solo es rápido: proporciona un control único sobre la memoria y los hilos, lo que permite escribir workers súper eficientes que consumen recursos mínimos. En este artículo, analizaremos cómo implementar colas y tareas en segundo plano en Rust, utilizando bibliotecas y enfoques modernos. Aprenderá cómo construir un sistema de procesamiento de tareas confiable que no fallará bajo carga.

¿Por qué Rust para tareas en segundo plano? Tres ventajas no obvias

Antes de sumergirnos en el código, analicemos por qué usar Rust para colas cuando existen soluciones probadas en Python.

\n
• Rendimiento sin GC (recolector de basura). Los workers en Python pueden "congelarse" durante las pausas del recolector de basura. Rust carece de este problema: controlas cada byte de memoria. Esto es crítico para sistemas de alta carga donde cada milisegundo importa.
\n
• Asincronía "lista para usar". Rust con tokio o async-std permite manejar miles de conexiones simultáneas en un solo hilo. Puedes ejecutar cientos de workers sin temor a desbordar la memoria.
\n
• Confiabilidad. El sistema de propiedad (ownership) en Rust garantiza que no tendrás condiciones de carrera (data race) en un worker en segundo plano. Los errores se manejan explícitamente: sin excepciones ocultas.
\n

Ahora que entendemos el "por qué", pasemos al "cómo".

Eligiendo un broker de mensajes: RabbitMQ vs Redis vs NATS

Una cola de tareas no es solo una lista. Es un broker de mensajes que almacena tareas y las distribuye entre los workers. En el ecosistema de Rust, hay crates para todos los brokers populares.

RabbitMQ + lapin: el clásico del mundo de las colas

RabbitMQ es un monstruo confiable para tareas empresariales. El crate lapin proporciona una API asíncrona limpia. Es ideal si necesitas enrutamiento de mensajes, garantías de entrega y topologías complejas.

Redis + fred: simplicidad y velocidad

Redis es una navaja suiza. Con fred (cliente asíncrono de Redis) puedes crear una cola usando listas (BLPOP) o Pub/Sub. Redis es excelente para escenarios simples: "envió una tarea - obtuvo un resultado".

NATS + async-nats: broker ligero

NATS es un broker nativo de la nube con latencia mínima. Si necesitas procesar millones de mensajes por segundo en instancias pequeñas, NATS es tu elección.

En este artículo, nos centraremos en RabbitMQ, ya que proporciona el control más completo. Pero los principios serán los mismos para cualquier broker.

Escribiendo una cola en Rust: ejemplo paso a paso

Vamos a crear un sistema simple: un generador de tareas (producer) y un worker (consumer). Procesaremos tareas de envío de correo electrónico.

Paso 1: Configuración del proyecto y dependencias

Cree un nuevo proyecto:

cargo new rust_queue_demo\ncd rust_queue_demo

Agregue las dependencias en Cargo.toml:

[dependencies]\ntokio = { version = "1", features = ["full"] }\nlapin = "2.4"\nserde = { version = "1", features = ["derive"] }\nserde_json = "1"\ntracing = "0.1"\ntracing-subscriber = "0.3"\nanyhow = "1"

Usamos tokio como runtime asíncrono, lapin para RabbitMQ, serde para serializar tareas y tracing para registro.

Paso 2: Definimos la estructura de la tarea