Celery en producción — elección de broker, semántica de retry, y lo que Flower te dice de verdad

Celery es una de esas herramientas cuyos defaults son casi correctos. Casi. La política de retry por defecto reintenta para siempre. acks_late por defecto es False, así que un crash de worker pierde el job. El broker por defecto para «arranque rápido» es Redis sin persistencia activada, así que un reinicio de Redis pierde toda tarea en curso.

Este es el setup de Celery de producción que ejecutamos para clientes Python gestionados — elección de broker, config de worker, política de retry, y el monitoreo que de verdad saca a la luz problemas.

Una tarea base con los defaults seguros

from celery import Celery, shared_task
 
app = Celery('app', broker='redis://redis:6379/0', backend='redis://redis:6379/1')
app.conf.update(
    task_acks_late=True,
    task_reject_on_worker_lost=True,
    task_track_started=True,
    worker_prefetch_multiplier=1,
    broker_connection_retry_on_startup=True,
)
 
@shared_task(bind=True, autoretry_for=(IOError,), retry_backoff=True,
             retry_jitter=True, retry_kwargs={'max_retries': 5})
def send_email(self, to, subject):
    ...

acks_late=True y prefetch_multiplier=1 juntos significan: toma una tarea a la vez, solo acknowledge tras el éxito. Combinados con retry_backoff y un tope max_retries, los jobs no desaparecen en un bucle de retry.

El artículo completo cubre:

• Redis vs RabbitMQ: cuándo cada uno es el broker correcto
• Idempotencia — la propiedad que las tareas deberían tener pero rara vez tienen
• Enrutar tareas a colas dedicadas para priorización y aislamiento
• Flower: las métricas que importan (profundidad de cola, latencia de tarea, tasa de retry)
• Celery beat para tareas programadas — y la historia de elección de líder que nadie te advierte
• Ciclo de vida de workers: max-tasks-per-child, fugas de memoria, interacción con OOM-killer

Entregamos este patrón de Celery en cada stack Python gestionada con trabajo en segundo plano.