Verwenden von Sellerie mit Django für die Verarbeitung von Hintergrundaufgaben

German (Deutsch) translation by Nikol Angelowa (you can also view the original English article)

Webanwendungen fangen normalerweise einfach an, können aber ziemlich komplex werden, und die meisten von ihnen überschreiten schnell die Verantwortung, nur auf HTTP-Anfragen zu antworten.

Wenn das passiert, muss man unterscheiden zwischen dem, was sofort passieren muss (normalerweise im HTTP-Request-Lebenszyklus) und dem, was schließlich passieren kann. Warum das? Denn wenn Ihre Anwendung mit Datenverkehr überlastet wird, machen einfache Dinge wie diese den Unterschied.

Vorgänge in einer Webanwendung können als kritische Vorgänge oder Vorgänge zur Anforderungszeit und als Hintergrundaufgaben klassifiziert werden, die außerhalb der Anforderungszeit stattfinden. Diese ordnen sich den oben beschriebenen zu:

muss sofort erfolgen: Vorgänge zur Anforderungszeit
muss irgendwann passieren: Hintergrundaufgaben

Vorgänge zur Anforderungszeit können in einem einzigen Anforderungs-/Antwort-Zyklus ausgeführt werden, ohne sich Sorgen machen zu müssen, dass der Vorgang abläuft oder der Benutzer eine schlechte Erfahrung macht. Gängige Beispiele sind CRUD (Create, Read, Update, Delete)-Datenbankoperationen und die Benutzerverwaltung (Login/Logout-Routinen).

Hintergrundaufgaben sind unterschiedlich, da sie in der Regel recht zeitaufwendig und fehleranfällig sind, meist aufgrund von externen Abhängigkeiten. Einige gängige Szenarien bei komplexen Webanwendungen sind:

Senden von Bestätigungs- oder Aktivitäts-E-Mails
tägliches Crawlen und Scrapen von Informationen aus verschiedenen Quellen und Speichern dieser
Datenanalyse durchführen
Löschen nicht benötigter Ressourcen
Exportieren von Dokumenten/Fotos in verschiedene Formate

Hintergrundaufgaben sind der Schwerpunkt dieses Tutorials. Das am häufigsten verwendete Programmiermuster für dieses Szenario ist die Producer Consumer Architecture.

Vereinfacht lässt sich diese Architektur so beschreiben:

Produzenten erstellen Daten oder Aufgaben.
Aufgaben werden in eine Warteschlange gestellt, die als Aufgabenwarteschlange bezeichnet wird.
Verbraucher sind dafür verantwortlich, die Daten zu konsumieren oder die Aufgaben auszuführen.

Normalerweise rufen die Verbraucher Aufgaben aus der Warteschlange nach dem First-In-First-Out-Verfahren (FIFO) oder gemäß ihren Prioritäten ab. Die Verbraucher werden auch als Arbeiter bezeichnet, und diesen Begriff werden wir durchgehend verwenden, da er mit der Terminologie der diskutierten Technologien übereinstimmt.

Welche Aufgaben können im Hintergrund bearbeitet werden? Aufgaben, die:

sind für die Grundfunktionalität der Webanwendung nicht zwingend erforderlich
können nicht im Anforderungs-/Antwortzyklus ausgeführt werden, da sie langsam sind (E/A-intensiv usw.)
hängen von externen Ressourcen ab, die möglicherweise nicht verfügbar sind oder sich nicht wie erwartet verhalten
muss möglicherweise mindestens einmal wiederholt werden
müssen nach einem Zeitplan ausgeführt werden

Celery ist die De-facto-Wahl für die Verarbeitung von Hintergrundaufgaben im Python/Django-Ökosystem. Es hat eine einfache und klare API und lässt sich wunderbar in Django integrieren. Es unterstützt verschiedene Technologien für die Aufgabenwarteschlange und verschiedene Paradigmen für die Arbeiter.

In diesem Tutorial erstellen wir eine Django-Spielzeug-Webanwendung (die sich mit realen Szenarien befasst), die die Verarbeitung von Hintergrundaufgaben verwendet.

Dinge einrichten

Angenommen, Sie sind bereits mit Python-Paketverwaltung und virtuellen Umgebungen vertraut, dann installieren wir Django:

1	$ pip install Django

Ich habe beschlossen, noch eine weitere Blogging-Anwendung zu erstellen. Der Fokus der Anwendung wird auf Einfachheit liegen. Ein Benutzer kann einfach ein Konto erstellen und ohne großen Aufwand einen Beitrag erstellen und auf der Plattform veröffentlichen.

Richten Sie das quick_publisher Django-Projekt ein:

1	$ django-admin startproject quick_publisher

Lassen Sie uns die App starten:

1	$ cd quick_publisher
2	$ ./manage.py startapp main

Wenn ich ein neues Django-Projekt starte, erstelle ich gerne eine main-Anwendung, die unter anderem ein benutzerdefiniertes Benutzermodell enthält. Meistens stoße ich auf Einschränkungen des standardmäßigen Django-User-Modells. Ein benutzerdefiniertes User-Modell bietet uns den Vorteil der Flexibilität.

# main/models.py

from django.db import models
from django.contrib.auth.models import AbstractBaseUser, PermissionsMixin, BaseUserManager


class UserAccountManager(BaseUserManager):
    use_in_migrations = True

    def _create_user(self, email, password, **extra_fields):
        if not email:
            raise ValueError('Email address must be provided')

        if not password:
            raise ValueError('Password must be provided')

        email = self.normalize_email(email)
        user = self.model(email=email, **extra_fields)
        user.set_password(password)
        user.save(using=self._db)
        return user

    def create_user(self, email=None, password=None, **extra_fields):
        return self._create_user(email, password, **extra_fields)

    def create_superuser(self, email, password, **extra_fields):
        extra_fields['is_staff'] = True
        extra_fields['is_superuser'] = True

        return self._create_user(email, password, **extra_fields)


class User(AbstractBaseUser, PermissionsMixin):

    REQUIRED_FIELDS = []
    USERNAME_FIELD = 'email'

    objects = UserAccountManager()

    email = models.EmailField('email', unique=True, blank=False, null=False)
    full_name = models.CharField('full name', blank=True, null=True, max_length=400)
    is_staff = models.BooleanField('staff status', default=False)
    is_active = models.BooleanField('active', default=True)

    def get_short_name(self):
        return self.email

    def get_full_name(self):
        return self.email

    def __unicode__(self):
        return self.email

Lesen Sie unbedingt die Django-Dokumentation, wenn Sie nicht mit der Funktionsweise benutzerdefinierter Benutzermodelle vertraut sind.

Jetzt müssen wir Django anweisen, dieses Benutzermodell anstelle des Standardmodells zu verwenden. Fügen Sie diese Zeile zur Datei quick_publisher/settings.py hinzu:

1	AUTH_USER_MODEL = 'main.User'

Wir müssen auch die main-Anwendung zur Liste INSTALLED_APPS in der Datei quick_publisher/settings.py hinzufügen. Wir können jetzt die Migrationen erstellen, anwenden und einen Superuser erstellen, um sich beim Django-Admin-Panel anmelden zu können:

1	$ ./manage.py makemigrations main
2	$ ./manage.py migrate
3	$ ./manage.py createsuperuser

Lassen Sie uns nun eine separate Django-Anwendung erstellen, die für Beiträge verantwortlich ist:

1	$ ./manage.py startapp publish

Definieren wir ein einfaches Post-Modell in publisher/models.py:

from django.db import models
from django.utils import timezone
from django.contrib.auth import get_user_model


class Post(models.Model):
    author = models.ForeignKey(get_user_model())
    created = models.DateTimeField('Created Date', default=timezone.now)
    title = models.CharField('Title', max_length=200)
    content = models.TextField('Content')
    slug = models.SlugField('Slug')

    def __str__(self):
        return '"%s" by %s' % (self.title, self.author)

Das Verbinden des Post-Modells mit dem Django-Administrator erfolgt in der Datei publisher/admin.py wie folgt:

from django.contrib import admin
from .models import Post


@admin.register(Post)
class PostAdmin(admin.ModelAdmin):
    pass

Lassen Sie uns abschließend die publisher-Anwendung mit unserem Projekt verknüpfen, indem Sie sie zur Liste INSTALLED_APPS hinzufügen.

Wir können jetzt den Server ausführen und zu http://localhost:8000/admin/ gehen und unsere ersten Beiträge erstellen, damit wir etwas zum Spielen haben:

1	$ ./manage.py runserver

Ich vertraue darauf, dass Sie Ihre Hausaufgaben gemacht und die Beiträge erstellt haben.

Lass uns weitermachen. Der nächste offensichtliche Schritt besteht darin, eine Möglichkeit zum Anzeigen der veröffentlichten Beiträge zu erstellen.

# publisher/views.py

from django.http import Http404
from django.shortcuts import render
from .models import Post


def view_post(request, slug):
    try:
        post = Post.objects.get(slug=slug)
    except Post.DoesNotExist:
        raise Http404("Poll does not exist")

    return render(request, 'post.html', context={'post': post})

Verknüpfen wir unsere neue Ansicht mit einer URL in: quick_publisher/urls.py

# quick_publisher/urls.py

from django.conf.urls import url
from django.contrib import admin

from publisher.views import view_post

urlpatterns = [
    url(r'^admin/', admin.site.urls),
    url(r'^(?P<slug>[a-zA-Z0-9\-]+)', view_post, name='view_post')
]

Schließlich erstellen wir die Vorlage, die den Beitrag rendert in: publisher/templates/post.html

<!DOCTYPE html>
<html>
<head lang="en">
    <meta charset="UTF-8">
    <title></title>
</head>
<body>
    <h1>{{ post.title }}</h1>
    <p>{{ post.content }}</p>
    <p>Published by {{ post.author.full_name }} on {{ post.created }}</p>
</body>
</html>

Wir können jetzt im Browser zu http://localhost:8000/the-slug-of-the-post-you-created/ gehen. Es ist nicht gerade ein Wunder des Webdesigns, aber gut aussehende Beiträge zu erstellen, würde den Rahmen dieses Tutorials sprengen.

Senden von Bestätigungs-E-Mails

Hier ist das klassische Szenario:

Sie erstellen ein Konto auf einer Plattform.
Sie geben eine auf der Plattform eindeutig zu identifizierende E-Mail-Adresse an.
Die Plattform überprüft, ob Sie tatsächlich der Inhaber der E-Mail-Adresse sind, indem sie eine E-Mail mit einem Bestätigungslink sendet.
Bis Sie die Verifizierung durchgeführt haben, können Sie die Plattform nicht (vollständig) nutzen.

Fügen wir ein is_verified-Flag und die verification_uuid zum User-Modell hinzu:

# main/models.py
import uuid


class User(AbstractBaseUser, PermissionsMixin):

    REQUIRED_FIELDS = []
    USERNAME_FIELD = 'email'

    objects = UserAccountManager()

    email = models.EmailField('email', unique=True, blank=False, null=False)
    full_name = models.CharField('full name', blank=True, null=True, max_length=400)
    is_staff = models.BooleanField('staff status', default=False)
    is_active = models.BooleanField('active', default=True)
    is_verified = models.BooleanField('verified', default=False) # Add the `is_verified` flag
    verification_uuid = models.UUIDField('Unique Verification UUID', default=uuid.uuid4)

    def get_short_name(self):
        return self.email

    def get_full_name(self):
        return self.email

    def __unicode__(self):
        return self.email

Lassen Sie uns diese Gelegenheit nutzen, um dem Administrator das Benutzermodell hinzuzufügen:

from django.contrib import admin
from .models import User


@admin.register(User)
class UserAdmin(admin.ModelAdmin):
    pass

Lassen Sie uns die Änderungen in der Datenbank widerspiegeln:

1	$ ./manage.py makemigrations
2	$ ./manage.py migrate

Wir müssen jetzt einen Code schreiben, der eine E-Mail sendet, wenn eine Benutzerinstanz erstellt wird. Dafür gibt es Django-Signale, und dies ist eine perfekte Gelegenheit, dieses Thema anzusprechen.

Signale werden ausgelöst, bevor/nachdem bestimmte Ereignisse in der Anwendung auftreten. Wir können Callback-Funktionen definieren, die automatisch ausgelöst werden, wenn die Signale ausgelöst werden. Um einen Callback-Trigger zu machen, müssen wir ihn zuerst mit einem Signal verbinden.

Wir erstellen einen Rückruf, der ausgelöst wird, nachdem ein Benutzermodell erstellt wurde. Wir werden diesen Code nach der Definition des User-Modells in: main/models.py hinzufügen

from django.db.models import signals
from django.core.mail import send_mail


def user_post_save(sender, instance, signal, *args, **kwargs):
    if not instance.is_verified:
        # Send verification email
        send_mail(
            'Verify your QuickPublisher account',
            'Follow this link to verify your account: '
                'http://localhost:8000%s' % reverse('verify', kwargs={'uuid': str(instance.verification_uuid)}),
            'from@quickpublisher.dev',
            [instance.email],
            fail_silently=False,
        )

signals.post_save.connect(user_post_save, sender=User)

Was wir hier gemacht haben, ist, dass wir eine user_post_save-Funktion definiert und mit dem post_save-Signal verbunden haben (das nach dem Speichern eines Modells ausgelöst wird), das vom User-Modell gesendet wird.

Django versendet nicht nur selbst E-Mails; es muss an einen E-Mail-Dienst gebunden sein. Der Einfachheit halber können Sie Ihre Gmail-Anmeldeinformationen in quick_publisher/settings.py hinzufügen oder Ihren bevorzugten E-Mail-Anbieter hinzufügen.

So sieht die Gmail-Konfiguration aus:

EMAIL_USE_TLS = True
EMAIL_HOST = 'smtp.gmail.com'
EMAIL_HOST_USER = '<YOUR_GMAIL_USERNAME>@gmail.com'
EMAIL_HOST_PASSWORD = '<YOUR_GMAIL_PASSWORD>'
EMAIL_PORT = 587

Um die Dinge zu testen, gehen Sie in das Admin-Panel und erstellen Sie einen neuen Benutzer mit einer gültigen E-Mail-Adresse, die Sie schnell überprüfen können. Wenn alles gut gegangen ist, erhalten Sie eine E-Mail mit einem Bestätigungslink. Die Überprüfungsroutine ist noch nicht fertig.

So verifizieren Sie das Konto:

# main/views.py

from django.http import Http404
from django.shortcuts import render, redirect
from .models import User


def home(request):
    return render(request, 'home.html')


def verify(request, uuid):
    try:
        user = User.objects.get(verification_uuid=uuid, is_verified=False)
    except User.DoesNotExist:
        raise Http404("User does not exist or is already verified")

    user.is_verified = True
    user.save()

    return redirect('home')

Schließen Sie die Ansichten an: quick_publisher/urls.py

# quick_publisher/urls.py

from django.conf.urls import url
from django.contrib import admin

from publisher.views import view_post
from main.views import home, verify

urlpatterns = [
    url(r'^$', home, name='home'),
    url(r'^admin/', admin.site.urls),
    url(r'^verify/(?P<uuid>[a-z0-9\-]+)/', verify, name='verify'),
    url(r'^(?P<slug>[a-zA-Z0-9\-]+)', view_post, name='view_post')
]

Denken Sie auch daran, eine home.html-Datei unter main/templates/home.html zu erstellen. Es wird von der home-Ansicht gerendert.

Versuchen Sie, das gesamte Szenario noch einmal auszuführen. Wenn alles in Ordnung ist, erhalten Sie eine E-Mail mit einer gültigen Bestätigungs-URL. Wenn Sie der URL folgen und dann beim Administrator nachsehen, können Sie sehen, wie das Konto verifiziert wurde.

Asynchrones Senden von E-Mails

Hier ist das Problem mit dem, was wir bisher gemacht haben. Möglicherweise haben Sie bemerkt, dass das Erstellen eines Benutzers etwas langsam ist. Das liegt daran, dass Django die Verifizierungs-E-Mail innerhalb der Anfragezeit sendet.

So funktioniert es: Wir senden die Benutzerdaten an die Django-Anwendung. Die Anwendung erstellt ein User-Modell und stellt dann eine Verbindung zu Gmail (oder einem anderen von Ihnen ausgewählten Dienst) her. Django wartet auf die Antwort und gibt erst dann eine Antwort an unseren Browser zurück.

Hier kommt Celery ins Spiel. Stellen Sie zunächst sicher, dass es installiert ist:

1	$ pip install Celery

Wir müssen jetzt eine Sellerie-Anwendung in unserer Django-Anwendung erstellen:

# quick_publisher/celery.py

import os
from celery import Celery

os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'quick_publisher.settings')

app = Celery('quick_publisher')
app.config_from_object('django.conf:settings')

# Load task modules from all registered Django app configs.
app.autodiscover_tasks()

Sellerie ist eine Aufgabenwarteschlange. Es empfängt Aufgaben von unserer Django-Anwendung und führt sie im Hintergrund aus. Sellerie muss mit anderen Diensten kombiniert werden, die als Broker fungieren.

Broker vermitteln das Senden von Nachrichten zwischen der Webanwendung und Sellerie. In diesem Tutorial verwenden wir Redis. Redis ist einfach zu installieren und wir können ohne großen Aufwand problemlos damit beginnen.

Sie können Redis installieren, indem Sie den Anweisungen auf der Redis-Schnellstartseite folgen. Sie müssen die Redis Python-Bibliothek, pip install redis und das für die Verwendung von Redis und Celery erforderliche Bundle installieren: pip install celery[redis].

Starten Sie den Redis-Server in einer separaten Konsole wie folgt: $ redis-server

Fügen wir die Celery/Redis-bezogenen Konfigurationen zu quick_publisher/settings.py hinzu:

# REDIS related settings 
REDIS_HOST = 'localhost' 
REDIS_PORT = '6379' 
BROKER_URL = 'redis://' + REDIS_HOST + ':' + REDIS_PORT + '/0' 
BROKER_TRANSPORT_OPTIONS = {'visibility_timeout': 3600} 
CELERY_RESULT_BACKEND = 'redis://' + REDIS_HOST + ':' + REDIS_PORT + '/0'

Bevor etwas in Sellerie ausgeführt werden kann, muss es als Aufgabe deklariert werden.

So geht's:

# main/tasks.py

import logging

from django.urls import reverse
from django.core.mail import send_mail
from django.contrib.auth import get_user_model
from quick_publisher.celery import app


@app.task
def send_verification_email(user_id):
    UserModel = get_user_model()
    try:
        user = UserModel.objects.get(pk=user_id)
        send_mail(
            'Verify your QuickPublisher account',
            'Follow this link to verify your account: '
                'http://localhost:8000%s' % reverse('verify', kwargs={'uuid': str(user.verification_uuid)}),
            'from@quickpublisher.dev',
            [user.email],
            fail_silently=False,
        )
    except UserModel.DoesNotExist:
        logging.warning("Tried to send verification email to non-existing user '%s'" % user_id)

Was wir hier getan haben, ist Folgendes: Wir haben die Funktion zum Senden von Bestätigungs-E-Mails in eine andere Datei namens task.py verschoben.

Ein paar Anmerkungen:

Der Name der Datei ist wichtig. Celery durchläuft alle Apps in INSTALLED_APPS und registriert die Aufgaben in den tasks.py-Dateien.
Beachten Sie, wie wir die Funktion send_verification_email mit @app.task ausgestattet haben. Dies teilt Celery mit, dass dies eine Aufgabe ist, die in der Aufgabenwarteschlange ausgeführt wird.
Beachten Sie, wie wir als Argument user_id und nicht als User-Objekt erwarten. Dies liegt daran, dass wir beim Senden der Aufgaben an Celery möglicherweise Probleme beim Serialisieren komplexer Objekte haben. Es ist am besten, sie einfach zu halten.

Zurück zu main/models.py wird der Signalcode zu:

from django.db.models import signals
from main.tasks import send_verification_email


def user_post_save(sender, instance, signal, *args, **kwargs):
    if not instance.is_verified:
        # Send verification email
        send_verification_email.delay(instance.pk)

signals.post_save.connect(user_post_save, sender=User)

Beachten Sie, wie wir die .delay-Methode für das Task-Objekt aufrufen. Das heißt, wir schicken die Aufgabe an Celery und warten nicht auf das Ergebnis. Wenn wir stattdessen send_verification_email(instance.pk) verwenden, würden wir es immer noch an Celery senden, aber warten, bis die Aufgabe abgeschlossen ist, was nicht das ist, was wir wollen.

Bevor Sie einen neuen Benutzer erstellen, gibt es einen Haken. Sellerie ist ein Dienst, und wir müssen ihn starten. Öffnen Sie eine neue Konsole, stellen Sie sicher, dass Sie die entsprechende virtuelle Umgebung aktivieren, und navigieren Sie zum Projektordner.

1	$ celery worker -A quick_publisher --loglevel=debug --concurrency=4

Damit starten vier Sellerie-Prozessarbeiter. Ja, jetzt können Sie endlich einen anderen Benutzer erstellen. Beachten Sie, dass es keine Verzögerung gibt, und achten Sie auf die Protokolle in der Celery-Konsole, um zu sehen, ob die Aufgaben ordnungsgemäß ausgeführt werden. Das sollte ungefähr so aussehen:

[2017-04-28 15:00:09,190: DEBUG/MainProcess] Task accepted: main.tasks.send_verification_email[f1f41e1f-ca39-43d2-a37d-9de085dc99de] pid:62065

[2017-04-28 15:00:11,740: INFO/PoolWorker-2] Task main.tasks.send_verification_email[f1f41e1f-ca39-43d2-a37d-9de085dc99de] succeeded in 2.5500912349671125s: None

Periodische Aufgaben mit Sellerie

Hier ist ein weiteres häufiges Szenario. Die meisten ausgereiften Webanwendungen senden ihren Benutzern E-Mails über den Lebenszyklus, um sie zu beschäftigen. Einige gängige Beispiele für Lebenszyklus-E-Mails:

Monatliche Reportagen
Aktivitätsbenachrichtigungen (Gefällt mir, Freundschaftsanfragen usw.)
Erinnerungen an bestimmte Aktionen ("Vergiss nicht, dein Konto zu aktivieren")

Hier ist, was wir in unserer App tun werden. Wir werden zählen, wie oft jeder Beitrag angesehen wurde, und einen täglichen Bericht an den Autor senden. Einmal jeden Tag gehen wir alle Benutzer durch, rufen ihre Beiträge ab und senden eine E-Mail mit einer Tabelle mit den Beiträgen und der Anzahl der Aufrufe.

Ändern wir das Post-Modell, damit wir das Szenario mit der Anzahl der Aufrufe berücksichtigen können.

class Post(models.Model):
    author = models.ForeignKey(User)
    created = models.DateTimeField('Created Date', default=timezone.now)
    title = models.CharField('Title', max_length=200)
    content = models.TextField('Content')
    slug = models.SlugField('Slug')
    view_count = models.IntegerField("View Count", default=0)

    def __str__(self):
        return '"%s" by %s' % (self.title, self.author)

Wie immer, wenn wir ein Modell ändern, müssen wir die Datenbank migrieren:

1	$ ./manage.py makemigrations
2
3	$ ./manage.py migrate

Lassen Sie uns auch die Django-Ansicht view_post ändern, um Ansichten zu zählen:

def view_post(request, slug):
    try:
        post = Post.objects.get(slug=slug)
    except Post.DoesNotExist:
        raise Http404("Poll does not exist")
    
    post.view_count += 1
    post.save()

    return render(request, 'post.html', context={'post': post})

Es wäre nützlich, den view_count in der Vorlage anzuzeigen. Fügen Sie dies <p>Viewed {{ post.view_count }} times</p> irgendwo in der Datei publisher/templates/post.html hinzu. Machen Sie jetzt ein paar Ansichten zu einem Beitrag und sehen Sie, wie der Zähler steigt.

Lassen Sie uns eine Sellerie-Aufgabe erstellen. Da es sich um Posts handelt, platziere ich es in publisher/tasks.py:

from django.template import Template, Context
from django.core.mail import send_mail
from django.contrib.auth import get_user_model
from quick_publisher.celery import app
from publisher.models import Post


REPORT_TEMPLATE = """
Here's how you did till now:

{% for post in posts %}
        "{{ post.title }}": viewed {{ post.view_count }} times |

{% endfor %}
"""


@app.task
def send_view_count_report():
    for user in get_user_model().objects.all():
        posts = Post.objects.filter(author=user)
        if not posts:
            continue

        template = Template(REPORT_TEMPLATE)

        send_mail(
            'Your QuickPublisher Activity',
            template.render(context=Context({'posts': posts})),
            'from@quickpublisher.dev',
            [user.email],
            fail_silently=False,
        )

Denken Sie jedes Mal, wenn Sie Änderungen an den Celery-Aufgaben vornehmen, daran, den Celery-Prozess neu zu starten. Sellerie muss Aufgaben entdecken und neu laden. Bevor wir eine periodische Aufgabe erstellen, sollten wir dies in der Django-Shell testen, um sicherzustellen, dass alles wie beabsichtigt funktioniert:

$ ./manage.py shell 

In [1]: from publisher.tasks import send_view_count_report 

In [2]: send_view_count_report.delay()

Hoffentlich haben Sie einen netten kleinen Bericht in Ihrer E-Mail erhalten.

Lassen Sie uns nun eine periodische Aufgabe erstellen. Öffnen Sie quick_publisher/celery.py und registrieren Sie die regelmäßigen Aufgaben:

# quick_publisher/celery.py

import os
from celery import Celery
from celery.schedules import crontab

os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'quick_publisher.settings')

app = Celery('quick_publisher')
app.config_from_object('django.conf:settings')

# Load task modules from all registered Django app configs.
app.autodiscover_tasks()

app.conf.beat_schedule = {
    'send-report-every-single-minute': {
        'task': 'publisher.tasks.send_view_count_report',
        'schedule': crontab(),  # change to `crontab(minute=0, hour=0)` if you want it to run daily at midnight
    },
}

Bisher haben wir einen Zeitplan erstellt, der die Aufgabe publisher.tasks.send_view_count_report jede Minute ausführen würde, wie durch die crontab()-Notation angegeben. Sie können auch verschiedene Celery Crontab-Zeitpläne angeben.

Öffnen Sie eine andere Konsole, aktivieren Sie die entsprechende Umgebung und starten Sie den Celery Beat-Dienst.

1	$ celery -A quick_publisher beat

Die Aufgabe des Beat-Dienstes besteht darin, Aufgaben in Celery gemäß dem Zeitplan zu pushen. Berücksichtigen Sie, dass der Zeitplan die Aufgabe send_view_count_report gemäß dem Setup jede Minute ausführen lässt. Es eignet sich gut zum Testen, wird jedoch nicht für eine reale Webanwendung empfohlen.

Aufgaben zuverlässiger machen

Aufgaben werden häufig verwendet, um unzuverlässige Vorgänge auszuführen, Vorgänge, die von externen Ressourcen abhängig sind oder aus verschiedenen Gründen leicht fehlschlagen können. Hier ist eine Richtlinie, um sie zuverlässiger zu machen:

Machen Sie Aufgaben idempotent. Eine idempotente Aufgabe ist eine Aufgabe, die, wenn sie auf halbem Weg gestoppt wird, den Status des Systems in keiner Weise ändert. Die Aufgabe nimmt entweder vollständige Änderungen am System vor oder gar keine.
Wiederholen Sie die Aufgaben. Wenn die Aufgabe fehlschlägt, sollten Sie sie immer wieder versuchen, bis sie erfolgreich ausgeführt wurde. Sie können dies in Sellerie mit Celery Retry tun. Eine weitere interessante Sache ist der Exponential Backoff-Algorithmus. Dies kann sich als nützlich erweisen, wenn Sie daran denken, die unnötige Belastung des Servers durch wiederholte Aufgaben zu begrenzen.

Schlussfolgerungen

Ich hoffe, dies war ein interessantes Tutorial für Sie und eine gute Einführung in die Verwendung von Celery mit Django.

Hier sind einige Schlussfolgerungen, die wir ziehen können:

Es hat sich bewährt, unzuverlässige und zeitaufwendige Aufgaben außerhalb der Anforderungszeit zu halten.
Langfristige Aufgaben sollten im Hintergrund von Worker-Prozessen (oder anderen Paradigmen) ausgeführt werden.
Hintergrundaufgaben können für verschiedene Aufgaben verwendet werden, die für die grundlegende Funktionsweise der Anwendung nicht kritisch sind.
Sellerie kann auch periodische Aufgaben mit dem celery beat-Service erledigen.
Aufgaben können zuverlässiger sein, wenn sie idempotent gemacht und erneut versucht werden (möglicherweise mit exponentiellem Backoff).