Ich erstelle Webanwendungen auf Django. Grundsätzlich handelt es sich hierbei um SaaS-Services für Unternehmen. Alle diese Anwendungen erfordern asynchrone Aufgaben. Für ihre Implementierung verwende ich Sellerie. In dem Artikel werde ich anhand von Codebeispielen über Situationen berichten, in denen ich Sellerie verwende.
Sellerie ist ein System zur Verwaltung von Aufgabenwarteschlangen. Grundsätzlich in der Lage 2 Dinge: Aufgaben aus der Warteschlange nehmen und Aufgaben nach einem Zeitplan ausführen. Der Warteschlangenbroker ist normalerweise RabbitMQ oder Redis. Die Aufgaben werden in die Warteschlange gestellt, und dann nehmen Sellerie-Mitarbeiter sie von dort und führen sie aus.
Für Sellerie können Sie sich eine Anwendung in fast jeder Anwendung vorstellen, aber dann werde ich nur die Fälle beschreiben, in denen ich sie selbst verwende.
1. Geplante Aufgaben
Oft gibt es Aufgaben, die an einem bestimmten Datum und zu einer bestimmten Uhrzeit erledigt werden müssen: Senden Sie eine Erinnerung an den Benutzer, beenden Sie den Testzeitraum des Kontos, veröffentlichen Sie einen Beitrag in sozialen Netzwerken.
In Sellerie kann beim Aufrufen der Aufgabe der
ETA- Parameter angegeben werden - der Zeitpunkt, zu dem die Aufgabe gestartet werden muss. Wenn Sie Aufgaben jedoch auf diese Weise planen, stellt sich heraus, dass sie sehr unzuverlässig sind: Sie werden möglicherweise nicht gestartet und können unangenehm abgebrochen werden.
Ein zuverlässigerer Weg ist die Verwendung des Sellerie-Beat-Zeitplans. Erstellen Sie also einen Zeitplan, in dem Aufgaben ausgeführt werden, die mit einer bestimmten Häufigkeit oder zu einem bestimmten Zeitpunkt beginnen. Wenn Sie beispielsweise einen Beitrag nach einem Zeitplan in sozialen Netzwerken veröffentlichen müssen, wird die entsprechende Aufgabe einmal pro Minute gestartet. Wenn Sie den Testzeitraum für Ihr Konto beenden müssen, können Sie die Aufgabe einmal täglich ausführen.
Im Taskstarter erhalten wir alle Instanzen, für die die geplante Zeit bereits gekommen ist. Wir gehen die Instanzen durch und nennen für jede die Hauptaufgabe. Als Argumente übergeben wir nur die Instanz-ID, um die Warteschlange nicht mit unnötigen Daten zu verstopfen. Wir können sofort alle Instanzen durchgehen und Aktionen ausführen, aber meistens ist es besser, für jede Instanz eine separate Aufgabe aufzurufen. Wir werden also die Ausführung beschleunigen, und wenn ein Fehler auftritt, betrifft dies nur eine der Aufgaben.
2. Lange Computer- und API-Aufrufe von WSGI
WSGI bezieht sich auf den Kontext, in dem Anforderungen von Benutzern verarbeitet werden (Anforderungs-Antwort-Zyklus). Im Gegensatz zum Kontext asynchroner Aufgaben - Sellerie.
Um eine reaktionsfähige Schnittstelle zu erstellen, müssen alle Schaltflächen sofort reagieren und dürfen den Rest der Benutzeroberfläche nicht blockieren. Zu diesem Zweck wird nach dem Blockieren der Taste ein Spinner darauf platziert und eine Ajax-Anfrage an den Server gesendet. Wenn die Bearbeitung der Anfrage länger als ein paar Sekunden dauert, können Sie die Berechnung in die Sellerie-Aufgabe verschieben.
In WSGI rufen wir task auf und geben eine Antwort zurück. Entriegeln Sie vorne den Knopf und entfernen Sie den Spinner. Wir zeigen dem Benutzer eine Nachricht, dass die Aktion ausgeführt wird. Parallel dazu wird eine Sellerie-Aufgabe ausgeführt, die nach Abschluss eine Antwort auf den Web-Socket zurückgibt. Nachdem wir das Ergebnis auf der Vorderseite erhalten haben, zeigen wir es dem Benutzer.
Sie können externe API-Aufrufe separat von WSGI unterscheiden. In diesem Fall werden alle Aufrufe unabhängig von der Dauer ihrer Ausführung über die Sellerie-Task gestartet. Dies ist Schutz vor dem Narren. Es sollte keine Situation geben, in der die Benutzeroberfläche aufgrund der Unzugänglichkeit einer externen API einfriert.
3. Herausforderungen vom Tornado
Für die Integration in ein soziales Netzwerk, ein Telegramm oder einen Zahlungsdienst benötigen Sie eine Webhook-URL, über die Benachrichtigungen gesendet werden. Die Anzahl der Anfragen kann nicht immer im Voraus berechnet werden, aber höchstwahrscheinlich übersteigt ihre Anzahl die Anfragen von Benutzern. Diese Anfragen werden empfangen, bis sie eine Antwort mit dem Code 200 erhalten.
Für die Verarbeitung solcher Anforderungen eignet sich das asynchrone Tornado-Framework. Um die Verarbeitung in Tornado nicht synchron zu machen, sollten keine Blockierungsvorgänge ausgeführt werden. Hier wird Sellerie benötigt. Der Tornado-Handler empfängt die Anforderung, validiert die Daten, ruft die Sellerie-Aufgabe auf und gibt eine erfolgreiche Antwort zurück.