Python-Hintergrundjobs: Celery, RQ, Dramatiq und APScheduler im Vergleich

Früher oder später muss jede Python-Webanwendung Arbeit außerhalb des Requests erledigen: die E-Mail nach dem Zurücksenden der Antwort verschicken, den Bericht generieren, den Upload verarbeiten, den wackeligen Drittanbieter-Aufruf wiederholen. Diese Arbeit inline zu erledigen, macht Ihre App langsam und fragil; richtig gemacht brauchen Sie ein Hintergrundjob-System. Die Schwierigkeit liegt in der Auswahl. Celery, RQ, Dramatiq und APScheduler führen alle „Hintergrundaufgaben aus“, lösen aber unterschiedliche Probleme. Dieser Leitfaden vergleicht sie ehrlich, damit Sie gleich das richtige Werkzeug wählen.

Das gemeinsame mentale Modell

Aufgabenwarteschlangen haben alle dieselbe Grundstruktur. Ihre App stellt einen Job (einen Funktionsnamen plus Argumente) in einen Broker: meist Redis oder RabbitMQ: ein. Separate Worker-Prozesse holen Jobs aus der Warteschlange und führen sie aus, wobei sie Wiederholungen, Fehler und Ergebnisse behandeln. Ihr Webprozess bleibt schnell, weil er nur einstellt; die langsame Arbeit findet woanders statt.

  web app ──enqueue──▶ [ BROKER: Redis/RabbitMQ ] ──▶ worker pool ──▶ done
   (fast)                  holds the queue            (does the slow work)

   Same shape for Celery, RQ, and Dramatiq.
   They differ in features, simplicity, and operational weight.

Celery: der funktionsreiche Platzhirsch

Celery ist der langjährige Standard: das leistungsfähigste und am weitesten verbreitete System. Es unterstützt mehrere Broker, komplexe Workflows (Ketten, Gruppen, Akkorde), geplante Aufgaben über seinen Beat-Scheduler, Ratenbegrenzung, Wiederholungen und eine tiefgreifende Konfigurationsoberfläche. Diese Leistungsfähigkeit hat jedoch ihren Preis: Celery ist bekannt für Konfigurationskomplexität und betriebliche Fallstricke, und die Fülle kann für einfache Anforderungen überwältigend sein.

# tasks.py
from celery import Celery

app = Celery("app", broker="redis://localhost:6379/0", backend="redis://localhost:6379/1")

@app.task(bind=True, max_retries=3, autoretry_for=(ConnectionError,), retry_backoff=True)
def send_receipt(self, order_id: int) -> None:
    order = Order.objects.get(id=order_id)        # pass an ID, not the object
    email.send(order.email, render_receipt(order))

# Enqueue from your web app — returns instantly, work happens on a worker.
send_receipt.delay(order_id=42)

# Run workers:  celery -A tasks worker --concurrency=8
# Periodic:     celery -A tasks beat   (Celery's built-in scheduler)

RQ: einfach aus Prinzip

RQ (Redis Queue) ist das Gegenstück zu Celery: Es ist klein, lesbar und macht genau eines: Python-Funktionen über Redis auf Workern ausführen. Wenn Sie den Quellcode an einem Nachmittag lesen können (was fast möglich ist), können Sie sein Verhalten in der Produktion nachvollziehen. Der Kompromiss sind weniger Funktionen und die Beschränkung auf Redis, aber für einen großen Teil der Anwendungen ist das genau genug.

from redis import Redis
from rq import Queue

# Any plain function is a job — no decorator required.
def send_receipt(order_id: int) -> None:
    order = Order.objects.get(id=order_id)
    email.send(order.email, render_receipt(order))

queue = Queue(connection=Redis())
queue.enqueue(send_receipt, 42, retry=Retry(max=3))   # enqueue and move on

# Run a worker:  rq worker

Dramatiq: der moderne Mittelweg

Dramatiq wurde entwickelt, um den Großteil von Celery's Nützlichkeit zu bewahren, dabei aber einfacher und standardmäßig zuverlässiger zu sein. Es bietet vernünftiges Verhalten ab Werk: automatische Wiederholungen, Nachrichtenaltersgrenzen und Zuverlässigkeitsfunktionen, die Sie anderswo selbst zusammenbauen oder abstimmen müssen. Für Teams, denen Celery zu schwer und RQ zu karg ist, ist Dramatiq oft der ideale Kompromiss.

import dramatiq

# Retries and sane defaults are built in; you opt into specifics per actor.
@dramatiq.actor(max_retries=3, time_limit=30_000)
def send_receipt(order_id: int) -> None:
    order = Order.objects.get(id=order_id)
    email.send(order.email, render_receipt(order))

send_receipt.send(42)        # enqueue

# Run workers:  dramatiq tasks

APScheduler: ein anderes Werkzeug für eine andere Aufgabe

APScheduler ist keine Aufgabenwarteschlange: es ist ein Scheduler. Seine Aufgabe ist es, Code basierend auf einem Zeitauslöser auszuführen: jede Stunde, jeden Wochentag um 9 Uhr, in dreißig Minuten. Es ist die prozessinterne Antwort auf „mach das nach Zeitplan“. Wichtig: Es bietet von sich aus keinen verteilten Worker-Pool mit Wiederholungen und Warteschlangen; für geplante Arbeit, die auch schwer ist oder skalieren muss, ist das übliche Muster, dass ein Scheduler lediglich Jobs in eine Aufgabenwarteschlange einstellt.

from apscheduler.schedulers.background import BackgroundScheduler
from apscheduler.triggers.cron import CronTrigger

scheduler = BackgroundScheduler()

# Don't do the heavy work here — just drop a job onto the real task queue.
@scheduler.scheduled_job(CronTrigger(hour=2, minute=0))   # every day at 02:00
def nightly_reports():
    for tenant_id in active_tenant_ids():
        generate_report.delay(tenant_id)    # Celery/RQ/Dramatiq does the actual work

scheduler.start()

Der Entscheidungsleitfaden

Betriebliche Wahrheiten für alle

Was auch immer Sie wählen, die gleichen Realitäten gelten: Machen Sie Tasks idempotent, denn sie werden gelegentlich mehr als einmal ausgeführt; halten Sie Task-Argumente klein und serialisierbar (übergeben Sie eine ID, kein riesiges Objekt); konfigurieren Sie Wiederholungen mit Backoff für vorübergehende Fehler und einen Dead-Letter-Pfad für dauerhafte; und überwachen Sie Ihre Queue-Tiefe, denn ein still wachsender Rückstau ist die Art, wie Hintergrundsysteme unbemerkt versagen.

Üben unterwegs

Lernen Sie Python, die kostenlose Android-App

Jedes Thema dieser Serie gibt es auch in der App: mundgerechte Lektionen, ausführbare Beispiele, Quizze, Miniprojekte und einen Offline-Python-Spielplatz, der auf Ihrem Handy läuft.

Jetzt bei Google Play App-Seite ansehen