Celery em produção — escolha de broker, semântica de retry, e o que o Flower de fato te diz

Celery é uma daquelas ferramentas cujos defaults estão quase certos. Quase. A política de retry padrão tenta para sempre. acks_late padrão é False, então um crash de worker perde o job. O broker padrão para «início rápido» é Redis sem persistência habilitada, então um restart do Redis perde toda tarefa em voo.

Este é o setup de Celery em produção que rodamos para clientes Python gerenciados — escolha de broker, config de worker, política de retry, e o monitoramento que de fato traz problemas à tona.

Uma tarefa base com os 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 e prefetch_multiplier=1 juntos significam: pegar uma tarefa por vez, só dar ack após sucesso. Combinados com retry_backoff e um teto de max_retries, jobs não somem em um loop de retry.

O artigo completo cobre:

• Redis vs RabbitMQ: quando cada um é o broker certo
• Idempotência — a propriedade que tarefas deveriam ter mas raramente têm
• Rotear tarefas para filas dedicadas para priorização e isolamento
• Flower: as métricas que importam (profundidade de fila, latência de tarefa, taxa de retry)
• Celery beat para tarefas agendadas — e a história de eleição de líder que ninguém avisa
• Ciclo de vida de workers: max-tasks-per-child, vazamentos de memória, interação com OOM-killer

Entregamos este padrão de Celery em cada stack Python gerenciada com trabalho em background.