Dauerhafte Verzögerungen
Workflows können zwischen Schritten mithilfe der Builder-Methode delay() für eine festgelegte Dauer pausieren. Verzögerungsschritte sind dauerhaft: Die Verzögerung wird in der Datenbank gespeichert und übersteht daher Neustarts von Workern, Deployments und Servern.
Die Methode ->delay()
Füge an beliebiger Stelle in der Workflow-Kette einen Verzögerungsschritt hinzu:
use Queuety\Queuety;
Queuety::workflow( 'drip_campaign' )
->then( SendWelcomeEmailHandler::class )
->delay( days: 1 )
->then( SendFollowUpEmailHandler::class )
->delay( days: 3 )
->then( SendFinalEmailHandler::class )
->dispatch( [ 'user_id' => 42 ] );
Der Workflow führt Folgendes aus:
SendWelcomeEmailHandlerausführen- 1 Tag warten
SendFollowUpEmailHandlerausführen- 3 Tage warten
SendFinalEmailHandlerausführen
Dauerparameter
Die Methode delay() akzeptiert beliebige Kombinationen benannter Dauerparameter:
| Parameter | Typ | Beschreibung |
|---|---|---|
$seconds |
int |
Sekunden warten |
$minutes |
int |
Minuten warten |
$hours |
int |
Stunden warten |
$days |
int |
Tage warten |
Alle Werte werden addiert. Diese Angaben sind gleichbedeutend:
->delay( seconds: 3600 )
->delay( minutes: 60 )
->delay( hours: 1 )
Du kannst sie kombinieren:
->delay( hours: 1, minutes: 30 ) // 90 minutes total
So funktionieren Verzögerungsschritte
Wenn ein Workflow einen Verzögerungsschritt erreicht, stellt Queuety einen internen __queuety_delay-Job ein, dessen Spalte available_at auf die aktuelle Uhrzeit plus die Verzögerungsdauer gesetzt ist. Der Job bleibt in der Datenbank und wird von keinem Worker übernommen, bis die Verzögerung abgelaufen ist.
Das bedeutet:
- Kein Polling. Worker prüfen die Verzögerung nicht wiederholt. Der Job wird einfach zum richtigen Zeitpunkt verfügbar.
- Kein Speicherverbrauch. Während der Wartezeit läuft nichts. Die Verzögerung existiert nur als Datenbankzeile.
- Übersteht Neustarts. Wird der Worker neu gestartet, bleibt der Verzögerungsjob mit dem korrekten
available_at-Zeitstempel in der Warteschlange.
Wird der Verzögerungsjob nach Ablauf der Verzögerung übernommen, fährt der Workflow automatisch mit dem nächsten Schritt fort.
Beispiel: verzögerte Benachrichtigungen
Sende 1 Stunde nach der Registrierung eines Benutzers eine Erinnerung, aber nur, wenn der Benutzer das Onboarding noch nicht abgeschlossen hat:
Queuety::workflow( 'onboarding_reminder' )
->then( CreateAccountHandler::class )
->delay( hours: 1 )
->then( CheckOnboardingHandler::class )
->then( SendReminderHandler::class )
->dispatch( [ 'email' => 'user@example.com' ] );
Der Schritt CheckOnboardingHandler kann den Status prüfen und mithilfe von bedingter Verzweigung die Erinnerung überspringen, wenn das Onboarding bereits abgeschlossen ist.
Beispiel: Wiederholung mit exponentieller Verzögerung
Füge zwischen wiederholungsähnlichen Schritten gezielte Verzögerungen ein:
Queuety::workflow( 'poll_external_api' )
->then( CheckStatusHandler::class, 'check' )
->delay( minutes: 5 )
->then( CheckStatusHandler::class, 'recheck' )
->delay( minutes: 15 )
->then( CheckStatusHandler::class, 'final_check' )
->then( ProcessResultHandler::class )
->dispatch( [ 'external_id' => 'abc-123' ] );
Mehrere Verzögerungen
Ein Workflow kann beliebig viele Verzögerungsschritte enthalten. Jede Verzögerung ist unabhängig und wird im Workflow-Status mit einem fortlaufenden Namen erfasst (delay_0, delay_1 usw.).
Queuety::workflow( 'multi_step_drip' )
->then( StepA::class )
->delay( hours: 2 )
->then( StepB::class )
->delay( days: 1 )
->then( StepC::class )
->delay( minutes: 30 )
->then( StepD::class )
->dispatch( $payload );