Wenn Ihr Job zu komplex für Crons ist

Cron-Jobs sind gut. Aber manchmal ist ein Cron-Job einfach nicht genug. Ab und zu einen Task laufen zu lassen, mag für manche Aufgaben gut sein, aber was ist, wenn Sie eine wirklich große Aufgabe haben? Eine Aufgabe, die die Kraft eines lang laufenden Prozesses benötigt.

Für diese großen Aufgaben reicht ein Cron-Job einfach nicht aus.

Was Sie brauchen, ist eine dedizierte Worker-Instanz; Worker-Anwendungsinstanzen, die Upsun natürlich anbietet.

Was ist falsch an Cron?

Cron-Aufgaben sind gut für das, wofür sie gut sind: Relativ simple Einzelaufgaben, die zu einer bestimmten Zeit oder in einem bestimmten Intervall ausgeführt werden. Upsun hat benutzerdefinierte Cron-Jobs von Anfang an unterstützt. Sie haben allerdings eine Reihe von Einschränkungen:

• Cron-Aufgaben auf Upsun laufen auf demselben Container wie Ihre Anwendungsinstanz, was bedeutet, dass sie um Ressourcen konkurrieren.
• Eine Cron-Aufgabe ist entweder erfolgreich oder scheitert komplett, was sie für eine Aufgabe, an der inkrementell gearbeitet werden kann, schlecht geeignet macht.
• Cron-Jobs werden nicht öfter als alle 5 Minuten ausgeführt, was bedeutet, dass eine Aufgabe, die "jetzt, aber nicht in der Webanforderung" erledigt werden muss, erst 5 Minuten später erfolgen kann.
• Eine laufende Cron-Aufgabe blockiert Deployments
• Wenn eine Cron-Aufgabe noch läuft, wenn sie das nächste Mal ausgelöst wird, können sie sich gegenseitig in die Quere kommen und den Zustand der Anwendung durcheinander bringen, es sei denn, sie sind sehr, sehr umsichtig, wie sie geschrieben ist.

Als allgemeine Faustregel gilt, dass Cron-Jobs verwendet werden sollten, wenn etwas zu einem bestimmten Zeitpunkt geschehen muss. Zum Beispiel, wenn Sie einen CSV-Export jeden Tag nach Mitternacht übertragen müssen.

Was ist ein Worker?

Worker sind allgemeiner und flexibler als Cron-Jobs. Sie arbeiten im Allgemeinen iterativ an kleinteiligen Aufgaben, wie eine Queue, und da sie ein persistenter Prozess sind, können sie eine Aufgabe sofort bearbeiten, sobald sie in die Queue gestellt wurde.

Bei Upsun ist ein Worker eine parallele Instanz Ihrer Anwendung, die nicht auf Webanfragen reagiert. Stattdessen führt er einen anderen, persistenten Hintergrundprozess aus. Es ist genau derselbe Code, der nur einen anderen Prozess ausführt, als auf eingehende Webanfragen zu reagieren.

Auf diese Weise ist es unglaublich einfach, Ihre Anwendung zunächst auf herkömmliche, synchrone Weise zu implementieren und mit trivialen Änderungen die Schwerstarbeit träge und asynchron zu gestalten. Dies ist nützlich für die Massenverarbeitung, für die Handhabung großer Queues, für langlaufende Aufgaben oder für alles andere, was so schnell wie möglich erledigt werden muss, ohne dass die Webanforderung dafür blockiert wird".

(Wenn Sie eine völlig separate Anwendung benötigen, die möglicherweise in einer anderen Sprache geschrieben ist, sollten Sie sich unsere Unterstützung für mehrere Anwendungen ansehen ).

Es ist auch möglich, verschiedene Anwendungen zu kombinieren. Ein wöchentlicher Massenversand könnte beispielsweise durch eine Cron-Aufgabe ausgelöst werden, die einmal pro Woche ausgeführt wird und eine lange Liste von E-Mails in die Queue stellt, die zu bearbeiten sind. Ein Worker würde dann sofort damit beginnen, diese Queue zu durchforsten und eine E-Mail nach der anderen zu versenden.(Das Versenden von E-Mails ist sehr viel zeitaufwändiger als das Einreihen der zu erledigenden Aufgaben in die Queue). Das ist viel robuster und potenziell auch schneller; Sie können sogar mehrere identische Worker erstellen, um die Queue noch schneller abzuarbeiten.

Durch den Einsatz von Upsun-Workern kann Ihre Webanwendung schneller und reaktionsschneller werden, während gleichzeitig die Latenzzeit Ihrer Hintergrundaufgaben verringert und das gesamte System robuster und einfacher zu verwalten wird.

Toll, und wie funktioniert das?

Das Einrichten eines Workers ist ganz einfach. Für den einfachsten Fall fügen Sie einfach etwas wie das Folgende in Ihre ./.upsun/config. yaml-Dateiein :

applications: 
	myapp: 
		<snip> 
			workers: 
				queue: 
					commands: 
						start: | php worker.php

Dies führt dazu, dass Ihre Anwendung in zwei separaten Containern bereitgestellt wird: Einer zur Bearbeitung von Webanfragen (genau wie jetzt) und ein zweiter Container namens "queue" mit genau demselben Code, der worker.php anstelle eines Webservers ausführt. Es muss natürlich nicht unbedingt ein PHP-Skript sein. Es kann jeder Befehl sein, den Ihr Anwendungscontainer ausführen kann.

Eine Drupal-Website kann zum Beispiel das Modul Drush Waiting Queue verwenden, um ihre Queue als echte Queue laufen zu lassen, anstatt huckepack auf Cron zu setzen. Eine Ruby on Rails-Anwendung kann sidekiq mit einer persistenten Valkey-Instanz verwenden , um eine lange Queue von Hintergrundaufgaben zu durchlaufen. Symfony- oder Laravel-Entwickler können dasselbe mit dem PHP-Port von Resqeue tun, während Python-Anwender sich für Celery entscheiden können .

Worker können auch von einem dedizierten Queue-Server unterstützt werden, der eine feinere Funktionalität bietet, wie z. B. die RabbitMQ Message-Queue. Es ist Ihre Anwendung, also wählen Sie den Ansatz, der für Sie am besten funktioniert.

Worker sind natürlich viel flexibler als nur die oben gezeigten Zeilen, aber in der Dokumentation finden Sie eine ausführliche Beschreibung, wie Sie eine Worker-Instanz an Ihre Bedürfnisse anpassen und sogar mehrere Worker für verschiedene Aufgaben einrichten können.

Für komplexe Aufgaben können Sie einen echten Worker-Prozess für die Aufgabe einsetzen.