Warum nicht einfach in der Anfrage?
Alles, was länger als ein oder zwei Sekunden dauert, gehört aus der Webanfrage heraus. Sonst:
- wartet der Nutzer vor einer weißen Seite,
- bricht irgendwann der Proxy mit einem Zeitfehler ab,
- und die halb erledigte Arbeit ist verloren, ohne dass jemand es merkt.
Der bessere Weg: Die Anfrage legt eine Aufgabe in eine Warteschlange und antwortet sofort. Ein Worker nimmt sie von dort und arbeitet sie ab.
Wie eine Warteschlange arbeitet
Die Warteschlange liegt meist in Redis oder in der Datenbank. Sie sorgt dafür, dass keine Aufgabe verloren geht, wenn ein Worker abstürzt – sie wird dann erneut ausgegeben.
Bei zu vielen wartenden Aufgaben startet man mehr Worker – das ist der einfachste Fall horizontaler Skalierung, weil Worker sich untereinander nichts merken.
Wie es bei Branchway läuft
Ein Worker ist eine App ohne öffentliche Adresse: derselbe Quelltext, anderer Startbefehl. Er bekommt dieselben Umgebungsvariablen und erreicht dieselbe Datenbank wie die Web-App.
Für wiederkehrende Arbeiten gibt es zeitgesteuerte Aufgaben – sie starten nach Plan, laufen einmal und beenden sich wieder. Abgerechnet wird nur die Laufzeit.
Häufige Fragen
Brauche ich Redis für eine Warteschlange?
Nicht zwingend. Für wenige Aufgaben pro Minute genügt eine Tabelle in der Datenbank. Redis lohnt sich, wenn es viele Aufgaben sind oder die Verzögerung klein sein soll.
Was passiert bei einem Deployment mitten in einer Aufgabe?
Der Worker bekommt ein Stopp-Signal und sollte die laufende Aufgabe zu Ende bringen oder zurücklegen. Aufgaben, die das nicht können, laufen später erneut – siehe Wiederholbarkeit.