Queue und Schedule sind zwei Prozesse
Ein langer Job verzögert keinen Cron-Tick. Ein Deploy startet den Worker neu, neue Jobs laufen nie auf alten Klassen.
Die Compose-Datei hatte schon einen Queue-Container und einen Schedule-Container. Sie als einen Prozess zu behandeln war der Fehler. Ein Sitemap-Rebuild inline stahl den Minuten-Tick. Ein reserved Job mit fettem Unserialize wuchs im RSS, bis der Host swapte. php-fpm sollte das nie sehen.
Worker haben jetzt eine begrenzte Versuchszahl, ein Timeout kürzer als die Redis-Reservation und ein Speicherlimit, das den Prozess tötet bevor die Box swappt. Langsames geht in die Queue. Der Schedule-Prozess dispatcht nur.
Overlap und Alter
Lange Tasks überspringen, wenn der vorige Lauf noch aktiv ist. Zwei Kopien einer nächtlichen Cleanup auf denselben Zeilen sind der Unique-Key um 03:10. Das Gesundheitssignal ist ein Heartbeat bei jedem Tick. Ist der Stempel älter als ein paar Minuten, ist der Container tot oder blockiert.
Alerts feuern auf das Alter des ältesten Jobs, nicht auf die Tiefe. Eine tiefe Queue, die abläuft, ist in Ordnung. Ein hängender Job nicht. Fehlgeschlagene Jobs tragen Payload, Exception-Klasse und die Correlation-ID des Requests, der sie einreihte.
Deploys
Ein Release startet den Queue-Worker explizit neu. Ohne diesen Schritt hält der Worker alte Klassen im Speicher und verarbeitet neue Jobs mit veraltetem Code. Der Bug dauerte nach jedem Wechsel ein paar Minuten und sah nach Zufall aus.
Die Trennung ist die Regel. HTTP bleibt in php-fpm. Jobs in der Queue. Ticks im Schedule. Ist ein Task langsam, läuft er nicht auf dem Tick.
