Celery in Produktion — Broker-Wahl, Retry-Semantik und was Flower Ihnen tatsächlich sagt

Celery ist eines dieser Werkzeuge, dessen Defaults fast richtig sind. Fast. Die Standard-Retry-Policy versucht es ewig erneut. Standard-acks_late ist False, also lässt ein Worker-Crash den Job fallen. Standard-Broker für „Quick Start" ist Redis ohne aktivierte Persistenz, also verliert ein Redis-Restart jeden in-flight Task.

Dies ist das Produktions-Celery-Setup, das wir für gemanagte Python-Kunden fahren — Broker-Wahl, Worker-Konfig, Retry-Policy, und das Monitoring, das Probleme tatsächlich ans Tageslicht bringt.

Ein Baseline-Task mit den sicheren Defaults

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 und prefetch_multiplier=1 zusammen bedeuten: einen Task zur Zeit nehmen, erst nach Erfolg ack-en. Kombiniert mit retry_backoff und einem max_retries-Cap verschwinden Jobs nicht in einer Retry-Schleife.

Der vollständige Beitrag behandelt:

• Redis vs RabbitMQ: wann jeder der richtige Broker ist
• Idempotenz — die Eigenschaft, die Tasks haben sollten, aber selten haben
• Tasks an dedizierte Queues routen für Priorisierung und Isolation
• Flower: die Metriken, die zählen (Queue-Tiefe, Task-Latenz, Retry-Rate)
• Celery beat für geplante Tasks — und die Leader-Election-Story, vor der niemand warnt
• Worker-Lifecycle: max-tasks-per-child, Memory-Leaks, die OOM-Killer-Interaktion

Wir liefern dieses Celery-Pattern auf jedem gemanagten Python-Stack mit Background-Work aus.