So kontrollieren Sie den Rückstau in einer PHP-Queue, ohne das Problem zu verschärfen

Eine Job-Queue ermöglicht es, Aufgaben außerhalb des unmittelbaren Anfragepfads auszuführen: Benachrichtigungen zu versenden, Dateien zu verarbeiten oder Daten zu synchronisieren. Wenn jedoch mehr Jobs eingehen, als die Consumer abschließen können, entsteht ein Rückstau. Die Verzögerung kann sich in verspäteten Bestätigungen, veralteten Daten oder Jobs zeigen, die nie abgeschlossen werden – mit Auswirkungen sowohl auf die Nutzer als auch auf die Teams, die die Anwendung betreiben.

Um über das Vorgehen zu entscheiden, reicht es nicht aus, nur die Anzahl ausstehender Nachrichten zu betrachten. Entscheidend sind ihr Alter, die Geschwindigkeit, mit der sie eingehen und abgeschlossen werden, die Art der Arbeit und der Zustand der Abhängigkeiten. Zusätzliche Consumer können helfen, wenn Kapazität fehlt, aber auch die Abfragen an eine bereits überlastete Datenbank vervielfachen. Eine sichere Reaktion beginnt damit, Messwerte zu erfassen und das Muster zu erkennen.

Was der Rückstau zeigt – und welche Metriken fehlen

Die Anzahl ausstehender Jobs ist eine Momentaufnahme, keine Erklärung. Sie kann während eines Lastanstiegs wachsen und anschließend ohne Eingreifen wieder sinken – oder stabil bleiben, während der älteste Job immer länger wartet. Um zu beurteilen, wie sich der Rückstau in einer PHP-Queue kontrollieren lässt, sollten Sie daher gemeinsam folgende Werte beobachten:

• Eingangsrate: angenommene Jobs pro Zeiteinheit.
• Ausgangsrate: abgeschlossene Jobs pro Zeiteinheit, wobei abgeschlossene Jobs von fehlgeschlagenen Versuchen unterschieden werden.
• Wartezeit: wie lange der älteste Job bereits wartet, sowie Wartezeit-Perzentile, sofern verfügbar.
• Verarbeitungsdauer: wie lange die einzelnen Jobtypen dauern und wie sich diese Dauer verändert.
• Fehler und Wiederholungsversuche: Fehlerquote, Anzahl der Versuche und ob Jobs in eine Fehler- oder Quarantäne-Queue verschoben werden.
• Zustand der Consumer und Abhängigkeiten: aktive Prozesse, Neustarts, CPU- und Speicherauslastung, Datenbankverbindungen und Latenz externer Dienste.

Die Ausgangsrate sollte tatsächlich abgeschlossene, nutzbringende Arbeit abbilden: Wird jeder Versuch als abgearbeiteter Job gezählt, kann das einen Kreislauf aus Fehlern und Wiederholungsversuchen verschleiern. Wichtig ist außerdem, nach Queue oder Aufgabentyp aufzuschlüsseln. Ein globaler Durchschnitt kann verbergen, dass ein Jobtyp die anderen blockiert.

Diagnostizieren Sie das Muster, bevor Sie die Kapazität ändern

Vergleichen Sie die Metriken in einem für den Betrieb geeigneten Zeitfenster mit dem üblichen Systemverhalten. Die Muster geben Hinweise für die Untersuchung, beweisen aber für sich genommen nicht die Ursache.

• Die Eingangsrate liegt dauerhaft über der Ausgangsrate: Möglicherweise fehlt Kapazität, das Volumen ist gestiegen oder die Jobs dauern länger. Prüfen Sie jüngste Änderungen, die Zusammensetzung des Datenverkehrs und die Bearbeitungszeiten der einzelnen Aufgabentypen.
• Consumer sind aktiv, aber die Ausgangsrate ist nahezu null: Suchen Sie nach blockierten Prozessen, unbegrenzten Wartezeiten, Deadlocks, einem erschöpften Verbindungspool oder externen Aufrufen ohne Zeitlimits. Prüfen Sie Logs und nach Job-ID korrelierte Traces.
• Verarbeitungsdauer und Latenz der Abhängigkeiten steigen: Möglicherweise warten die Consumer auf die Datenbank, eine API oder den Speicher. Mehr Prozesse können die Ressourcenkonkurrenz erhöhen und die Latenz verschlechtern.
• Dieselben Jobs schlagen wiederholt fehl: Ursache könnten ungültige Daten, ein nicht behebbarer Zustand oder ein Fehler im Code sein. Prüfen Sie die Wiederholungsrichtlinie: Zu frühe Wiederholungen können einen Laststurm auslösen.
• Eine Queue wächst, während andere abgearbeitet werden: Prüfen Sie Prioritäten, die Verteilung der Consumer und ob ein Aufgabentyp die Ressourcen monopolisiert.

Achten Sie auch auf kürzliche Konfigurationsänderungen und Deployments. Vergewissern Sie sich, dass die Telemetrie zwischen einem ausgelasteten Consumer und einem laufenden, aber nicht fortschreitenden Consumer unterscheidet. Eine Prüfung, ob ein Prozess aktiv ist, garantiert nicht, dass Jobs abgeschlossen werden.

Schätzen Sie die Abarbeitungskapazität anhand beobachteter Daten

Ist die anhaltende Ausgangsrate höher als die Eingangsrate, kann sich die Queue verkleinern, solange dieser Unterschied bestehen bleibt. Als betriebliche Näherung ergibt sich die Zeit für die Abarbeitung des Rückstaus aus der Anzahl ausstehender Jobs geteilt durch die Netto-Abarbeitungskapazität: Ausgangsrate abzüglich Eingangsrate im selben Zeitraum. Ist dieser Unterschied null oder negativ, wird die Ansammlung durch längere Wartezeiten nicht behoben.

Die Schätzung ist eine Orientierung, keine Zusage für einen bestimmten Zeitpunkt der Wiederherstellung. Sie setzt voraus, dass das Tempo anhält und die Jobs eine ähnliche Zusammensetzung und Kosten verursachen. Einige wenige lang laufende Jobs, Wiederholungsversuche oder Begrenzungen einer Abhängigkeit können das Ergebnis verändern. Verwenden Sie unter realer Last beobachtete Raten und erstellen Sie nach jedem Eingriff eine neue Schätzung. Bei Aufgaben mit unterschiedlichen Kosten sollten Sie nach Aufgabentyp berechnen oder die Bearbeitungszeit messen, statt nur die Anzahl der Nachrichten zu betrachten.

Greifen Sie schrittweise und mit klaren Grenzen ein

Bevorzugen Sie reversible und begrenzte Maßnahmen. Klären Sie vor einer Änderung der Anzahl von Consumern, welche Auswirkungen die einzelnen Abhängigkeiten tolerieren und wie sich die Änderung rückgängig machen lässt.

1. Begrenzen Sie nach Möglichkeit neue Eingänge: Pausieren Sie nicht essenzielle Producer, setzen Sie Limits oder verschieben Sie Aufgaben mit niedriger Priorität. Verwerfen Sie keine Jobs ohne Geschäftsregel, Protokollierung und Wiederherstellungsmechanismus.
2. Isolieren Sie problematische Jobs: Begrenzen Sie die Anzahl der Versuche, verwenden Sie gegebenenfalls eine zunehmend längere Wartezeit und leiten Sie dauerhaft fehlgeschlagene Jobs in eine überprüfbare Fehler-Queue um. Ignorieren Sie diese Jobs nicht: Sie müssen möglicherweise korrigiert und erneut verarbeitet werden.
3. Schützen Sie Prioritäten: Trennen Sie dringende Aufgaben von Wartungs- oder Massenverarbeitungsjobs und prüfen Sie, dass weniger dringende Queues nicht unbegrenzt warten müssen.
4. Erhöhen Sie die Parallelität schrittweise: Ändern Sie die Anzahl der Consumer in kleinen Schritten und beobachten Sie Durchsatz und Auslastung. Halten Sie die Grenzen im Einklang mit verfügbaren Verbindungen, CPU, Arbeitsspeicher und Kontingenten externer Dienste.
5. Beheben Sie die Ursache: Gibt es langsame Abfragen, Blockaden oder Aufrufe ohne Timeout, beheben Sie diesen Engpass, bevor Sie dauerhaft mehr Prozesse parallel arbeiten lassen.

Idempotenz ist besonders wichtig, wenn ein Job mehr als einmal ausgeführt werden kann. Gestalten Sie externe Effekte und Schreibvorgänge so, dass sie Wiederholungsversuche tolerieren, oder verwenden Sie geeignete Deduplizierungsmechanismen. Klären Sie außerdem, was passiert, wenn der Consumer nach Ausführung des Effekts, aber vor der Bestätigung der Nachricht stoppt.

Legen Sie Schwellenwerte und ein Wiederherstellungsverfahren fest

Legen Sie Schwellenwerte anhand der Serviceanforderungen fest, nicht anhand einer allgemeingültigen Zahl. Ein Alarm kann das maximale Alter oder ein Perzentil der Wartezeit, den Trend des Rückstaus, die Differenz zwischen Eingangs- und Ausgangsrate sowie die Fehlerrate kombinieren. Das Alter steht oft in engerem Zusammenhang mit den Auswirkungen für Nutzer als eine isolierte Anzahl; das Volumen hilft, das Ausmaß einzuschätzen.

Dokumentieren Sie, wer eingreift, welche Queues pausiert werden dürfen, welche Abhängigkeiten überprüft werden müssen und welche Änderungen eine Genehmigung erfordern. Halten Sie während des Vorfalls Uhrzeit, Hypothese, Maßnahme und beobachtete Wirkung fest. Prüfen Sie nach jeder Anpassung, ob die Ausgangsrate steigt, ohne dass Datenbanklatenz, externe Fehler, Ressourcenauslastung oder Anwendungsfehler unvertretbar zunehmen.

Betrachten Sie die Wiederherstellung als bestätigt, wenn Alter und Volumen dauerhaft sinken, Jobs erfolgreich abgeschlossen werden und sich die Abhängigkeiten wieder auf einem stabilen Niveau befinden. Erklären Sie das Problem nicht allein deshalb für behoben, weil der Zähler sinkt: Nachrichten könnten verworfen worden oder in einer anderen Queue aufgelaufen sein.

Checkliste, um eine erneute Ansammlung zu verhindern

• Werden Eingangsrate, tatsächlich abgeschlossene Arbeit, Alter, Verarbeitungsdauer und Wiederholungsversuche für jede Queue erfasst?
• Haben die Jobs Zeitlimits und eine endliche, angemessene Wiederholungsrichtlinie?
• Gibt es Alarme bei ausbleibendem Fortschritt und nicht nur bei hohem Volumen?
• Hält die maximale Parallelität die Grenzen gemeinsam genutzter Abhängigkeiten ein?
• Lässt sich ein problematischer Aufgabentyp isolieren, ohne die gesamte Verarbeitung anzuhalten?
• Gibt es ein dokumentiertes Verfahren, um Verarbeitung sicher zu pausieren, fortzusetzen und Jobs erneut zu verarbeiten?
• Werden Metriken und Nebenwirkungen nach Code-, Last- oder Konfigurationsänderungen überprüft?

Eine gesunde Queue ist nicht zwangsläufig leer: Schwankungen können normal sein. Entscheidend ist, dass Jobs innerhalb des vorgesehenen Servicelevels abgeschlossen werden, Fehler sichtbar sind und das System genügend Reserven hat, um Lastspitzen aufzufangen. Wer dieses Verhalten misst, kann eingreifen, bevor eine Ansammlung für Nutzer zu einer Unterbrechung wird.