Django Sellerie Beat Admin Update Cron Zeitplan Periodische Task nicht wirksam

9

Ich betreibe eine Website mit Django 10, RabbitMQ und Sellerie 4 auf CentOS 7.

Meine Sellerie-Beat- und Sellerie-Worker-Instanzen werden vom Supervisor gesteuert und ich benutze den Django-Sellerie-Datenbank-Scheduler.

Ich habe eine Cron-Style-Aufgabe mit dem Cronsheduler in Django-admin eingeplant.

Wenn ich Sellerie-Beat- und Worker-Instanzen starte, wird der Job wie erwartet ausgelöst.

Wenn aber die Zeit in Django-admin geändert wird, werden die Änderungen nicht übernommen, es sei denn, ich starte die Sellerie-Beat-Instanz neu.

Gibt es etwas, das ich vermisse oder muss ich meinen eigenen Scheduler schreiben?

Celery Beat, mit dem 'django_celery_beat.schedulers.DatabaseScheduler' lädt den Zeitplan aus der Datenbank. Laut dem folgenden Dokument sollte Sellery Beat dazu gezwungen werden neu laden:

Ein Zeitplan, der in einem bestimmten Intervall (z. B. alle 5 Sekunden) ausgeführt wird. • django_cellery_beat.models.CrontabSchedule EIN Zeitplan mit Felder mögen Einträge im cron: Minute Stunde Wochentag Tag_des_Monats Monat_Jahr.

django_celery_beat.models.PeriodicTasks Dieses Modell wird nur als Index verwendet, um zu verfolgen, wann sich der Zeitplan geändert hat. Immer wenn Sie eine PeriodicTask aktualisieren, wird auch ein Zähler in dieser Tabelle inkrementiert, der den Sellerieschlag angibt Service, um den Zeitplan von der Datenbank neu zu laden. Wenn Sie periodische Aufgaben in großen Mengen aktualisieren, müssen Sie den Zähler manuell aktualisieren:

%Vor%

Von dem oben genannten würde ich erwarten, dass der Sellerie-Beat-Prozess den Tisch regelmäßig auf Änderungen überprüft.

    
Steve 13.11.2016, 23:04
quelle

2 Antworten

1

Ich habe eine Lösung von:

  1. Erstellen eines separaten Arbeitsprozesses, der eine RabbitMQ-Warteschlange verwendet.
  2. Wenn Django die Datenbank aktualisiert, wird eine Nachricht an die Warteschlange gesendet, die den Namen des Sellery Beat-Prozesses enthält (Name, der von der Supervisor-Konfiguration definiert wird).
  3. Der Worker-Prozess startet dann den genannten Sellerie Beat-Prozess erneut.

Ein bisschen langatmig, aber macht den Job. Erleichtert außerdem die Verwaltung mehrerer Django-Apps auf demselben Server, die dieselbe Funktionalität erfordern.

    
Steve 15.11.2016, 19:43
quelle
2

ich habe den Sellerie von 4.0 auf 3.1.25, django auf 1.9.11 geändert und djcellery 3.1.17 installiert. Dann noch einmal testen, es ist OK. Also, vielleicht ist es ein Fehler.

    
kenda zheng 16.11.2016 03:15
quelle