Background-Job-Architektur: Queues, Worker und Fehlerbehandlung

Jeder Produktionsvorfall mit "stillen Fehlern", zu dem ich gerufen wurde, lässt sich auf dieselbe Stelle zurückführen: ein Background-Job-System, das auf dem Dashboard in Ordnung aussah, aber wochenlang unbemerkt Arbeit verlor. Das Muster ist fast jedes Mal identisch. Ein Worker stürzt mitten in einem Task ab, die Nachricht wird erneut zugestellt, der Handler ist nicht idempotent, und eine Kundin bekommt am Ende zwei Rechnungen oder gar keine. Ein Retry-Sturm gegen eine fragile Drittanbieter-API sättigt eine ausgehende IP und löst Rate-Limiting für die gesamte Anwendung aus. Ein geplanter Job erzeugt in fünf Minuten 200.000 Einträge in der Queue, und die voreingestellte FIFO-Queue sorgt dafür, dass die dringenden Passwort-Reset-Mails hinter einem Massen-Marketing-Versand feststecken.

Eine solide Background-Job-Architektur bedeutet nicht, eine Queue-Bibliothek auszuwählen. Es geht darum, für die Fehlerzustände zu entwerfen, denen Du in Produktion begegnest: Abstürze, Timeouts, Poison-Messages, Consumer-Sättigung und Bedienfehler. Dieser Beitrag geht die Entscheidungen zu Queues, Workern und Fehlerbehandlung durch, die wirklich zählen, mit konkreten Symfony-Messenger-Beispielen für Teams, die PHP in Produktion betreiben.

Warum Background-Job-Architektur tragende Infrastruktur ist

Jede ernstzunehmende Webanwendung muss irgendwann Arbeit außerhalb des Request-Response-Zyklus erledigen. Transaktionale E-Mails versenden, PDF-Rechnungen erzeugen, mit CRM-Systemen synchronisieren, Bild-Uploads verarbeiten, geplante Exporte ausführen - all das gehört in Background-Worker und nicht in eine blockierte HTTP-Antwort.

Die Versuchung ist, das als gelöstes Problem zu behandeln: eine Job-Bibliothek installieren, sie auf Redis zeigen lassen, dispatch() aufrufen und weitermachen. Für einen Prototyp funktioniert das. In Produktion bricht es in dem Moment, in dem eines der folgenden Dinge passiert - und irgendwann passieren sie alle. Einem Consumer geht der Speicher aus und er wird vom Kernel beendet, während er eine Reservierung auf einer Nachricht hält. Ein Redis-Neustart verliert Nachrichten im Flug, die nicht persistiert wurden. Ein Drittanbieter-Webhook-Empfänger gibt eine Stunde lang 503 zurück, und naive Retries verstärken den Ausfall in Deinem eigenen System. Ein Deployment liefert einen kaputten Handler aus, der bei jeder Nachricht eine Exception wirft, und innerhalb von Minuten hat die Queue Millionen geplanter Retries.

Die Teams, die diese Vorfälle vermeiden, hatten kein Glück. Sie haben bewusste Architekturentscheidungen getroffen, die leicht zu übernehmen sind, wenn Du weißt, worauf Du achten musst.

Den richtigen Broker für Dein Lastprofil wählen

Die erste Entscheidung ist, über welchen Transport Jobs laufen. Die drei praktischen Optionen für die meisten europäischen SaaS-Teams sind Redis, RabbitMQ und eine datenbankgestützte Queue über den Doctrine-Transport. Jede hat ein anderes Fehlerprofil, und die richtige Wahl hängt von Deinen Anforderungen an Haltbarkeit und Durchsatz ab.

Redis ist schnell, einfach und die richtige Wahl für Arbeit mit hohem Volumen und geringem Risiko - Bildskalierung, Cache-Warming, Befüllung von Analytics-Pipelines. Was Redis ohne sorgfältige Konfiguration nicht bietet, ist Haltbarkeit. Ein abgestürzter Redis-Knoten mit appendonly no verliert jede Nachricht im Speicher. Selbst mit AOF-Persistenz kann eine Nachricht zwischen Enqueue und fsync verloren gehen. Für Arbeit, die Du Dir nicht leisten kannst zu verlieren, reicht Redis allein nicht aus.

RabbitMQ ist die pragmatische Standardwahl für geschäftskritische asynchrone Arbeit. Persistente Queues überstehen Broker-Neustarts, Publisher Confirms geben Dir At-least-once-Zustellsemantik, und die Management-Oberfläche ist für Operatoren nützlich, die Queue-Tiefe und Consumer-Gesundheit inspizieren. Der Betriebsaufwand ist höher als bei Redis - Du betreibst eine Erlang-Anwendung, die eigenes Monitoring und Kapazitätsplanung braucht - aber die Haltbarkeitsgarantien rechtfertigen das für die meisten Produktionsfälle.

Der Doctrine-Transport, der Nachrichten in eine Tabelle Deiner Hauptdatenbank schreibt, ist eine unterschätzte Option für kleine bis mittlere Teams. Der Durchsatz ist begrenzt, aber Du bekommst transaktionales Enqueue gratis: Eine Nachricht, die in derselben Datenbanktransaktion wie die Geschäftslogik versendet wird, committet entweder beide oder rollt beide zurück. Kein separater Broker bedeutet keinen separaten Fehlerzustand zu überwachen. Für Teams, die Tausende statt Millionen Jobs pro Tag verarbeiten, ist diese Einfachheit oft der richtige Kompromiss.

Wenn Deine Anwendung alle drei Lastprofile mischt - manche Jobs sind Fire-and-forget-Analytics, manche sind Finanztransaktionen, die nie verloren gehen dürfen - lautet die richtige Antwort nicht, einen Transport zu wählen, sondern unterschiedliche Nachrichtenklassen anhand ihrer Haltbarkeitsanforderungen an unterschiedliche Transports zu routen.

Handler entwerfen, die Retries überstehen

Die wichtigste Eigenschaft eines Background-Job-Handlers ist Idempotenz: Ihn zweimal auszuführen muss dasselbe beobachtbare Ergebnis liefern wie ihn einmal auszuführen. Idempotenz ist nicht verhandelbar, weil At-least-once-Zustellung das Beste ist, was Dein Broker bieten kann. Ein Worker, der eine Nachricht verarbeitet, das Ergebnis in die Datenbank schreibt und dann abstürzt, bevor er dem Broker bestätigt, wird diese Nachricht beim Neustart erneut sehen. Wenn Dein Handler bei jeder Ausführung eine E-Mail versendet, bekommt die Kundin zwei. Wenn Dein Handler bei jeder Ausführung eine Kreditkarte belastet, hast Du ein viel größeres Problem.

Idempotenz umzusetzen bedeutet meist eines von zwei Mustern. Das erste ist die Nutzung eines natürlichen Idempotenzschlüssels aus der Geschäftsdomäne - einer Order-ID, einer Webhook-Event-ID, einer UUID einer Nutzeraktion - und zu prüfen, ob das Ergebnis bereits existiert, bevor man handelt:

#[AsMessageHandler]
final class ProcessPaymentHandler
{
    public function __construct(
        private PaymentRepository $payments,
        private StripeClient $stripe,
    ) {}

    public function __invoke(ProcessPayment $message): void
    {
        // Idempotency: skip if we already have a charge for this order
        $existing = $this->payments->findByOrderId($message->orderId);
        if ($existing !== null && $existing->isCaptured()) {
            return;
        }

        $charge = $this->stripe->charges->create([
            'amount' => $message->amountCents,
            'currency' => $message->currency,
            'idempotency_key' => sprintf('order-%d', $message->orderId),
        ]);

        $this->payments->recordCharge($message->orderId, $charge->id);
    }
}

Das zweite Muster ist das Speichern eines Logs verarbeiteter Nachrichten mit Unique Constraints, sodass das Einfügen derselben Nachrichten-ID zweimal auf Datenbankebene fehlschlägt und der Handler es als No-op behandeln kann. Beide Ansätze funktionieren; entscheidend ist, dass die Entscheidung explizit getroffen wird, nicht zufällig.

Die zweite wichtige Eigenschaft ist begrenzte Ausführungszeit. Ein Handler, der bei einem langsamen HTTP-Aufruf unbegrenzt hängen kann, wird irgendwann Deinen Worker-Pool erschöpfen. Jeder externe Aufruf in einem Handler sollte ein explizites Timeout auf Client-Ebene haben, und Handler sollten generell darauf abzielen, innerhalb von Dutzenden Sekunden fertig zu sein. Jobs, die wirklich Minuten laufen müssen, sollten in kleinere Schritte zerlegt werden, die jeweils schnell abschließen.

Retry-Strategie: Exponentielles Backoff, keine Endlosschleifen

Ein fehlgeschlagener Job sollte erneut versucht werden - aber nicht sofort und nicht für immer. Symfony Messenger stellt pro Transport eine Retry-Strategie bereit, die beide Anliegen bei richtiger Konfiguration standardmäßig korrekt behandelt:

framework:
    messenger:
        transports:
            async_critical:
                dsn: '%env(MESSENGER_TRANSPORT_DSN)%'
                retry_strategy:
                    max_retries: 5
                    delay: 2000
                    multiplier: 3
                    max_delay: 600000
                failure_transport: failed

Diese Konfiguration versucht es bis zu fünfmal, beginnend mit einer Verzögerung von 2 Sekunden, die sich bei jedem Versuch verdreifacht (2s, 6s, 18s, 54s, 162s), gedeckelt bei 10 Minuten. Das exponentielle Backoff gibt vorübergehenden Fehlern Zeit zur Erholung, ohne das Problem zu verstärken, und die Retry-Obergrenze stellt sicher, dass eine wirklich kaputte Nachricht irgendwann der Retry-Schleife in die Dead-Letter-Queue entkommt, statt für immer CPU zu verbrennen.

Ein häufiger Fehler ist, alle Exceptions gleich zu behandeln. Eine NetworkException aus einem API-Aufruf sollte wahrscheinlich erneut versucht werden - der entfernte Dienst ist vielleicht kurz nicht verfügbar. Eine ValidationException, weil die Nachricht Daten enthält, die aus der Datenbank gelöscht wurden, sollte wahrscheinlich nicht - kein noch so langes Warten lässt den referenzierten Datensatz wieder erscheinen. Messenger unterstützt diese Unterscheidung, indem Handler eine UnrecoverableMessageHandlingException werfen können, um eine Nachricht ohne Retry direkt in die Dead-Letter-Queue zu schicken:

if ($order === null) {
    throw new UnrecoverableMessageHandlingException(
        sprintf('Order %d no longer exists', $message->orderId)
    );
}

Exceptions auf diese Weise zu klassifizieren verhindert Retry-Stürme bei Nachrichten, die nie erfolgreich sein werden, und hält die Dead-Letter-Queue auf wirklich behebbare Fehler fokussiert.

Dead-Letter-Queues sind nicht optional

Eine Dead-Letter-Queue (DLQ) ist der Ort, an den Nachrichten gehen, wenn sie ihr Retry-Budget erschöpft haben oder als nicht behebbar eingestuft wurden. Eine zu betreiben ist der Unterschied zwischen stillem Datenverlust und einem diagnostizierbaren, behebbaren Fehler.

In der Praxis müssen drei Dinge vorhanden sein. Erstens muss jeder Transport ein failure_transport konfiguriert haben, damit erschöpfte Nachrichten erfasst statt verworfen werden. Zweitens muss die DLQ überwacht werden - eine wachsende Dead-Letter-Queue ist ein Produktionsalarm, keine Dashboard-Kuriosität. Drittens brauchen Operatoren Werkzeuge, um fehlgeschlagene Nachrichten zu inspizieren und erneut zu verarbeiten:

# Inspect failed messages
bin/console messenger:failed:show

# Show a specific failure in detail
bin/console messenger:failed:show 42 -vv

# Retry a failed message after fixing the underlying issue
bin/console messenger:failed:retry 42

# Remove a message that cannot be reprocessed
bin/console messenger:failed:remove 42

Eine DLQ ohne einen menschlichen Prozess, der sie überprüft, ist schlimmer als gar keine DLQ - sie schafft falsches Vertrauen, während Daten still in einer Queue auflaufen, die niemand liest. Eine wöchentliche oder tägliche DLQ-Durchsicht als Teil der Engineering-Rotation zu etablieren ist genauso wichtig wie die Infrastruktur selbst.

Priorisierung: Lass Marketing-Versände keine Passwort-Resets aushungern

Die Standardannahme einer einzelnen, FIFO-verarbeiteten Queue bricht in dem Moment zusammen, in dem ein Job mit niedriger Priorität hohes Volumen erzeugt. Einen NewsletterSender gegen 200.000 Abonnenten laufen zu lassen sollte nicht die Passwort-Reset-Mail verzögern, auf die eine Nutzerin gerade jetzt wartet.

Die Lösung sind Priority Queues: Route kritische Nachrichten an einen Transport mit dedizierter Consumer-Kapazität und geringerer Queue-Tiefe. In Symfony Messenger ist das eine Routing-Konfiguration:

framework:
    messenger:
        transports:
            critical: '%env(MESSENGER_CRITICAL_DSN)%'
            default:  '%env(MESSENGER_DEFAULT_DSN)%'
            bulk:     '%env(MESSENGER_BULK_DSN)%'

        routing:
            'App\Message\PasswordResetEmail':     critical
            'App\Message\OrderConfirmation':      critical
            'App\Message\SyncCrmContact':         default
            'App\Message\MarketingBlastSegment':  bulk

Betreibe dedizierte Worker-Prozesse pro Transport, damit eine Flut von Bulk-Arbeit kritische Consumer nicht blockieren kann:

bin/console messenger:consume critical --limit=1000 --memory-limit=256M
bin/console messenger:consume default  --limit=1000 --memory-limit=256M
bin/console messenger:consume bulk     --limit=1000 --memory-limit=256M

Diese Trennung ist günstig einzurichten und verbessert sowohl die durchschnittliche als auch die Tail-Latenz für die Arbeit, die Nutzer tatsächlich bemerken, dramatisch.

Worker-Lebenszyklus: Speicher, Supervision und sauberes Herunterfahren

Worker sind langlaufende PHP-Prozesse, und PHPs Speicherverhalten über lange Laufzeiten ist nicht großartig. Ein Worker sollte regelmäßig neu starten, um Speicher zurückzugewinnen - die Flags --limit und --memory-limit bei messenger:consume erledigen das, indem sie den Prozess nach N Nachrichten oder M Megabyte sauber beenden. Ein Prozess-Supervisor - systemd, supervisord oder Kubernetes - startet den beendeten Worker dann innerhalb von Sekunden neu.

Sauberes Herunterfahren ist genauso wichtig wie der Neustart. Wenn ein Deployment einen Worker ersetzt, sollte der laufende Prozess seine aktuelle Nachricht beenden und sie dem Broker bestätigen, bevor er sich beendet, statt sie mitten im Flug zu verwerfen. Messenger behandelt SIGTERM von Haus aus korrekt, aber Dein Orchestrator braucht eine Shutdown-Gnadenfrist, die lang genug für den am längsten laufenden Handler ist - typischerweise sind 30 bis 60 Sekunden sicher.

Den Worker-Pool selbst zu überwachen ist die andere Hälfte der Gleichung. Queue-Tiefe, Consumer-Anzahl und Consumer-Lag sind die drei Metriken, die Dir sagen, ob das System gesund ist. Eine Consumer-Anzahl, die während der Geschäftszeiten auf null fällt, ist ein Pager-Alarm. Eine Queue-Tiefe, die unbegrenzt wächst, ist ein Pager-Alarm. Consumer-Lag über zehn Minuten auf einer kritischen Queue ist ein Pager-Alarm. Alles andere ist ein Dashboard. Teams mit solidem Code-Quality-Consulting haben diese Alarme typischerweise in ihre Incident Response eingebunden, bevor das Job-System in Produktion geht, nicht nach dem ersten Post-mortem zu einem stillen Fehler.

Alles zusammensetzen

Ein produktionsreifes Background-Job-System hat fünf tragende Bestandteile. Transports werden bewusst pro Haltbarkeitsprofil gewählt, mit kritischer Arbeit auf RabbitMQ oder Äquivalent statt Redis allein. Handler sind von Grund auf idempotent und werfen nicht behebbare Exceptions für Nachrichten, die nicht erfolgreich sein können. Retries nutzen exponentielles Backoff mit endlicher Obergrenze, keine Endlos-Retry-Schleifen. Jeder Transport hat eine überwachte Dead-Letter-Queue mit einem menschlichen Überprüfungsprozess. Und Priority Queues mit getrennten Worker-Pools verhindern, dass Bulk-Arbeit nutzerseitige Jobs aushungert.

Nichts davon erfordert exotische Infrastruktur. Symfony Messenger auf einem korrekt konfigurierten RabbitMQ-Cluster, betrieben mit supervisord und überwacht mit Prometheus und Grafana, läuft auf bescheidener Hardware bequem mit zig Millionen Nachrichten pro Tag. Die Investition steckt im Design, nicht im Werkzeug.

Wenn Dein Team stille Fehler, wachsende Dead-Letter-Rückstände oder Worker-Neustarts erlebt, die nie ganz mit der Queue-Tiefe Schritt halten, bietet Wolf-Tech Architektur-Reviews an, die sich speziell auf die Zuverlässigkeit asynchroner Verarbeitung konzentrieren. Wir haben die gesamte Bandbreite der oben beschriebenen Fehlerzustände auf echten Produktionssystemen debuggt, oft als Teil umfassenderer Legacy-Code-Optimierung. Erreiche uns unter hello@wolf-tech.io oder besuche wolf-tech.io für eine kostenlose Erstberatung.