Teilen Sie eine große Operation in kleine idempotente Aufgaben mit stabiler Kennung und explizitem Status auf. Wiederholen Sie vorübergehende Fehler mit zunehmendem Abstand und einer Obergrenze, verschieben Sie dauerhafte Fehler in eine Prüfwarteschlange. Überwachen Sie das Alter der ältesten Aufgabe, die Anzahl der Fehlschläge, die Verarbeitungszeit und ausbleibende Worker-Läufe. Begrenzen Sie die Parallelität entsprechend der Kapazität abhängiger Dienste.
Aufgabenwarteschlangen in WordPress verlagern langsame oder vorübergehend unzuverlässige Arbeit aus der Web-Anfrage heraus. Ein Import, die Erzeugung einer Datei, eine Synchronisierung oder ein größerer E-Mail-Batch sollten Nutzer nicht auf einem Ladebildschirm festhalten. Das Einreihen einer Aufgabe in den Action Scheduler oder eine eigene Warteschlange garantiert für sich genommen jedoch nicht, dass sie nur einmal, in der richtigen Reihenfolge und ohne Verlust ausgeführt wird.
Eine zuverlässige Verarbeitung benötigt eine kleine Arbeitseinheit, einen Status, einen Idempotenzschlüssel, eine Retry-Richtlinie und betriebliche Überwachung. Diese Anleitung behandelt das Design von Queue und Workern. Sie unterscheidet sich von der Diagnose des WP-Crons selbst: Der Scheduler kann einen Worker starten, die Queue muss jedoch eigenständig wissen, was wartet, was fehlgeschlagen ist und wie sicher fortgefahren werden kann.
Entscheiden Sie, was in die Warteschlange gehört
In eine Queue gehören Aufgaben, die langsam sind, im Batch laufen oder von einem entfernten Dienst abhängen und nicht vor der Antwort an den Nutzer abgeschlossen sein müssen. Die Web-Anfrage validiert zunächst die Eingabe und speichert die Absicht zuverlässig, anschließend gibt sie eine Kennung und einen verständlichen Status zurück. Die kritische Berechtigungsprüfung und die grundlegende Validierung dürfen nicht ohne Grund auf später verschoben werden.
Gestalten Sie eine Aufgabe als eine geschäftliche Operation mit begrenzter Laufzeit und begrenztem Speicher. Teilen Sie die Verarbeitung von zehntausend Produkten in Seiten oder einzelne Datensätze mit Cursor auf. Zu kleine Aufgaben können großen Overhead erzeugen; eine große, unteilbare Aufgabe wird nach einem Fehler komplett wiederholt. Prüfen Sie den Umfang durch Messungen.
Speichern Sie den Status und einen idempotenten Schlüssel
Jeder Job hat einen Typ, einen sicheren Payload, einen Status, eine Anzahl von Versuchen, einen Verfügbarkeitszeitpunkt und einen stabilen Schlüssel des Geschäftsvorgangs. Der Payload enthält keine Geheimnisse, wenn diese erst zur Laufzeit sicher geladen werden können. Speichern Sie statt der gesamten Bestellung deren ID und die gewünschte Version, damit sich entscheiden lässt, ob der Job noch aktuell ist.
Der Worker prüft vor einem Seiteneffekt, ob das Ergebnis nicht bereits existiert. Beim Erstellen einer Sendung verwendet er denselben idempotenten Schlüssel auch in der entfernten API, sofern diese ihn unterstützt. Nach einem Absturz zwischen dem entfernten Erfolg und dem lokalen Schreibvorgang sucht der nächste Versuch zuerst nach dem Ergebnis. Der Status „erledigt“ wird erst nach allen bestätigten Schritten gesetzt.
- Eindeutiger Typ und sicherer Payload
- Idempotenzschlüssel der Operation
- Anzahl der Versuche und nächster Ausführungszeitpunkt
- Nachvollziehbares Ergebnis oder Fehlerursache
Unterscheiden Sie zwischen temporären, dauerhaften und unbekannten Fehlern
Timeouts, Rate Limits und kurze Ausfälle sind meist vorübergehend, daher werden sie mit exponentiellem Backoff und zufälliger Streuung wiederholt. Ein ungültiger Wert oder ein fehlendes Mapping lässt sich durch Wiederholung nicht beheben; die Aufgabe kommt mit einem konkreten Grund in eine Prüfwarteschlange. Ein unbekanntes Ergebnis erfordert zuerst eine Statusabfrage, keinen blinden weiteren Schreibvorgang.
Begrenzen Sie die Anzahl der Versuche und das maximale Alter entsprechend der geschäftlichen Auswirkung. Löschen Sie die Aufgabe nach Erreichen des Limits nicht. Bewahren Sie die Diagnosemetadaten auf, benachrichtigen Sie den Verantwortlichen und bieten Sie eine sichere Wiederholung nach Behebung der Ursache an. Der Retry-Button muss eine Sperre erhalten und die Idempotenz ebenso beachten wie der automatische Worker.
Steuern Sie Nebenläufigkeit, Reihenfolge und Kapazität
Zwei Worker dürfen nicht gleichzeitig dieselbe Aufgabe bearbeiten. Verwenden Sie einen atomaren Claim oder eine Sperre mit angemessenem Ablauf und einen Heartbeat bei langen Aufgaben. Ein veralteter Claim darf erst nach einer sicheren Zeitspanne in die Warteschlange zurückkehren. Eine globale Sperre für alles verringert hingegen unnötig den Durchsatz unabhängiger Aufgaben.
Garantieren Sie eine Reihenfolge nur dort, wo der Geschäftsprozess sie erfordert. Ereignisse einer einzelnen Bestellung lassen sich anhand eines Schlüssels serialisieren, während unabhängige Produkte parallel verarbeitet werden. Legen Sie ein Limit für gleichzeitige Zugriffe auf die Datenbank und die externe API fest. Backpressure verhindert, dass ein großer Import kleine dringende Aufgaben aus der verfügbaren Kapazität verdrängt.
Überwachen Sie die Warteschlange wie einen Produktionsdienst
Überwachen Sie die Anzahl wartender Aufgaben, das Alter der ältesten Aufgabe, die Laufzeit, die Erfolgsquote, Wiederholungen und Fehler nach Typ. Eine separate Warnung erfasst einen Worker, der gar nicht gestartet ist. Das Dashboard zeigt das Geschäftsobjekt und die Korrelations-ID ohne sensiblen Payload, damit der Betrieb eine Bestellung oder einen Import finden kann.
Testen Sie in der Staging-Umgebung parallele Ausführung, einen Absturz nach jedem Seiteneffekt, Timeouts, Rate Limits und die Wiederholung nach einer Fehlerbehebung. Bereinigen Sie die abgeschlossene Historie regelmäßig gemäß der Aufbewahrungsregel, nicht jedoch aktive oder fehlerhafte Aufgaben. Das Runbook beschreibt das Pausieren des Producers, das Abarbeiten des Backlogs und die Prüfung der Vollständigkeit nach einem Vorfall.
Häufige Fragen
Ist der Action Scheduler dasselbe wie WP-Cron?
Nein. Action Scheduler erfasst einzelne Aktionen, Status und Versuche; der Mechanismus zu ihrer Ausführung kann WP-Cron oder einen System-Runner nutzen. Beide Ebenen benötigen eine eigene Kontrolle und ein eigenes Monitoring.
Warum wurde ein Job in der Warteschlange zweimal ausgeführt?
Bei einem Timeout oder einem parallelen Worker kann es zu Wiederholungen kommen. Der Worker muss daher idempotent sein, einen atomaren Claim verwenden und vor einer Nebenwirkung ein bereits vorhandenes Ergebnis prüfen.
Wie lässt sich eine fehlgeschlagene Aufgabe sicher wiederholen?
Beheben und klassifizieren Sie zunächst die Ursache, prüfen Sie, ob kein Teilergebnis entstanden ist, und verwenden Sie dann denselben Idempotenzschlüssel und einen kontrollierten Retry. Bewahren Sie sowohl den ursprünglichen Verlauf als auch den neuen Versuch auf.
Quellen und weiterführende Lektüre
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
