Webapplicaties beginnen meestal eenvoudig, maar kunnen vrij complex worden en de meesten overschrijden snel de verantwoordelijkheid om alleen op HTTP-verzoeken te reageren.

Wanneer dat gebeurt, moet er een onderscheid worden gemaakt tussen wat er onmiddellijk moet gebeuren (meestal in de levenscyclus van HTTP-aanvragen) en wat er uiteindelijk kan gebeuren. Waarom is dat? Welnu, omdat uw toepassing overbelast raakt met verkeer, maken eenvoudige dingen zoals deze het verschil. 

Bewerkingen in een webtoepassing kunnen worden geclassificeerd als kritieke of aanvraag-tijdbewerkingen en achtergrondtaken, diegene die buiten de aanvraagtijd plaatsvinden. Deze mappen naar de hierboven beschreven: 

• moet onmiddellijk gebeuren: aanvragen voor een aanvraag
• moet uiteindelijk gebeuren: achtergrondtaken

Verzoek-tijd operaties kunnen worden uitgevoerd op een enkele verzoek / respons-cyclus zonder zorgen te maken dat de operatie zal verlopen of dat de gebruiker een slechte ervaring zou kunnen hebben. Veelvoorkomende voorbeelden zijn CRUD-bewerkingen (Create, Read, Update, Delete) en gebruikersbeheer (aanmeldings- / afmeldingsroutines).

Achtergrondtaken zijn anders, omdat ze meestal behoorlijk tijdrovend zijn en gevoelig voor mislukken zijn, meestal als gevolg van externe afhankelijkheden. Enkele veel voorkomende scenario's bij complexe webtoepassingen zijn:

• e-mails met bevestiging of activiteit verzenden
• dagelijks crawlen en scrapen van informatie uit verschillende bronnen en deze opslaan
• gegevensanalyse uitvoeren
• onnodige bronnen verwijderen
• exporteren van documenten / foto's in verschillende formaten

Achtergrondtaken staan ​​centraal in deze zelfstudie. Het meest gebruikte programmeringspatroon voor dit scenario is de Producent consumentenarchitectuur. 

In eenvoudige bewoordingen kan deze architectuur als volgt worden beschreven: 

• Producenten maken gegevens of taken.
• Taken worden in een wachtrij geplaatst die de takenwachtrij wordt genoemd. 
• Consumenten zijn verantwoordelijk voor het gebruik van de gegevens of het uitvoeren van de taken. 

Gewoonlijk halen de consumenten taken uit de wachtrij in een first-in-first-out (FIFO) -manier of volgens hun prioriteiten. De consumenten worden ook werknemers genoemd en dat is de term die we overal zullen gebruiken, omdat deze consistent is met de terminologie die wordt gebruikt door de besproken technologieën.

Welke soorten taken kunnen op de achtergrond worden verwerkt? Taken die:

• zijn niet essentieel voor de basisfunctionaliteit van de webtoepassing
• kan niet worden uitgevoerd in de verzoek / reactiecyclus omdat ze traag zijn (I / O intensief, etc.)
• afhankelijk van externe bronnen die mogelijk niet beschikbaar zijn of zich niet gedragen zoals verwacht
• moet mogelijk minstens één keer opnieuw worden geprobeerd
• moeten volgens een schema worden uitgevoerd

Celery is de de facto keuze voor verwerking van achtergrondtaak in het Python / Django-ecosysteem. Het heeft een eenvoudige en duidelijke API en het integreert prachtig met Django. Het ondersteunt verschillende technologieën voor de taakwachtrij en verschillende paradigma's voor de werknemers.

In deze tutorial gaan we een webtoepassing voor Django-speelgoed maken (die zich bezighoudt met real-world scenario's) die achtergrondtaakverwerking gebruikt.

Dingen opzetten

Ervan uitgaande dat u al bekend bent met Python-pakketbeheer en virtuele omgevingen, laten we Django installeren:

$ pip installeer Django

Ik heb besloten om nog een andere blogtoepassing te bouwen. De focus van de toepassing ligt op eenvoud. Een gebruiker kan eenvoudig een account maken en zonder al te veel gedoe een bericht maken en publiceren op het platform. 

Stel de quick_publisher Django-project:

$ django-admin startproject quick_publisher

Laten we de app starten:

$ cd quick_publisher $ ./manage.py startapp main

Bij het starten van een nieuw Django-project maak ik graag een hoofd toepassing die, onder andere, een aangepast gebruikersmodel bevat. Vaker wel dan niet, stuit ik op beperkingen van de standaard Django Gebruiker model. Een gewoonte hebben Gebruiker model geeft ons het voordeel van flexibiliteit.

# main / models.py van django.db importeer modellen van django.contrib.auth.models import AbstractBaseUser, PermissionsMixin, BaseUserManager class UserAccountManager (BaseUserManager): use_in_migrations = True def _create_user (self, email, password, ** extra_fields): if niet e-mail: verhoog ValueError ('E-mailadres moet worden opgegeven') indien geen wachtwoord: verhoog ValueError ('Wachtwoord moet worden opgegeven') email = self.normalize_email (email) user = self.model (email = email, ** extra_fields) user.set_password (wachtwoord) 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, wachtwoord, ** extra_fields) class User (AbstractBaseUser, PermissionsMixin): REQUIRED_FIELDS = [] USERNAME_FIELD = 'email' objecten = UserAccountManager () email = models.EmailField ('email', unique = True, blank = False, null = False) full_name = models.CharField ('volledige naam', leeg = True, null = True, max_length = 400) is_staff = models.BooleanField ('personeelsstatus' , 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

Zorg ervoor dat je de Django-documentatie raadpleegt als je niet bekend bent met hoe aangepaste gebruikersmodellen werken.

Nu moeten we Django vertellen om dit gebruikersmodel te gebruiken in plaats van het standaardmodel. Voeg deze regel toe aan de quick_publisher / settings.py het dossier:

AUTH_USER_MODEL = 'main.User' 

We moeten ook het hoofd toepassing op de INSTALLED_APPS lijst in de quick_publisher / settings.py het dossier. We kunnen nu de migraties maken, deze toepassen en een superuser maken om zich aan te melden bij het Django-adminpaneel:

$ ./manage.py makemigraties main $ ./manage.py migrate $ ./manage.py createuperuser

Laten we nu een afzonderlijke Django-applicatie maken die verantwoordelijk is voor berichten:

$ ./manage.py startapp publiceren

Laten we een eenvoudig postmodel definiëren in uitgever / models.py:

van django.db importmodellen van django.utils import tijdzone van django.contrib.auth import get_user_model class Post (models.Model): author = models.ForeignKey (get_user_model ()) created = models.DateTimeField ('Gecreëerde datum', standaard = timezone.now) title = models.CharField ('Title', max_length = 200) content = models.TextField ('Content') slug = models.SlugField ('Slug') def __str __ (self): return '"% s "door% s '% (self.title, self.author)

Het aansluiten van de Post model met de Django-admin wordt gedaan in de uitgever / admin.py bestand als dit:

van django.contrib importeer admin van .models importeer Post @ admin.register (Post) class PostAdmin (admin.ModelAdmin): pas

Tot slot, laten we de uitgeverij toepassing met ons project door het toe te voegen aan de INSTALLED_APPS lijst.

We kunnen nu de server draaien en naar gaan http: // localhost: 8000 / admin / en maak onze eerste berichten zodat we iets hebben om mee te spelen:

$ ./manage.py-server

Ik hoop dat je je huiswerk hebt gedaan en je hebt de berichten gemaakt. 

Laten we verder gaan. De volgende voor de hand liggende stap is om een ​​manier te creëren om de gepubliceerde berichten te bekijken. 

# publisher / views.py van django.http import Http404 van django.shortcuts import render van .models importeer Post def view_post (request, slug): try: post = Post.objects.get (slug = slug) behalve Post.DoesNotExist: raise Http404 ("Poll bestaat niet") return render (request, 'post.html', context = 'post': post)

Laten we onze nieuwe weergave koppelen aan een URL in: quick_publisher / urls.py

# quick_publisher / urls.py van django.conf.urls import url van django.contrib import admin van publisher.views import view_post urlpatterns = [url (r '^ admin /', admin.site.urls), url (r '^ (? P[a-zA-Z0-9 \ -] +) ', view_post, name = "view_post")]

Laten we tot slot de sjabloon maken waarin het bericht wordt weergegeven: uitgever / templates / post.html

       
post.title
 
post.content
 
Gepubliceerd door post.author.full_name op post.created
  

We kunnen nu naar http: // localhost: 8000 / the-slug-van-the-post-you-created / in de browser gaan. Het is niet bepaald een wonder van webdesign, maar het maken van mooie berichten valt buiten het bestek van deze tutorial.

Bevestigingsmails verzenden

Dit is het klassieke scenario:

• U maakt een account op een platform.
• U geeft een e-mailadres op dat uniek moet worden geïdentificeerd op het platform.
• Het platform controleert of u inderdaad de eigenaar van het e-mailadres bent door een e-mail te sturen met een bevestigingslink.
• Totdat u de verificatie uitvoert, kunt u het platform niet (volledig) gebruiken.

Laten we een toevoegen is_verified vlag en de verification_uuid op de Gebruiker model:

# main / models.py import uuid class User (AbstractBaseUser, Permissions Mix): REQUIRED_FIELDS = [] USERNAME_FIELD = 'email' objecten = UserAccountManager () email = models.EmailField ('email', unique = True, blanco = False, null = False) full_name = models.CharField ('volledige naam', leeg = 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) # Voeg de 'is_verified' vlag toe verification_uuid = models.UUIDField ('Unique Verification UUID', default = uuid.uuid4) def get_short_name (self): retour self.email def get_full_name (self): return self.email def __unicode __ (self): return self.email

Laten we deze gelegenheid gebruiken om het gebruikersmodel aan de beheerder toe te voegen:

van django.contrib importeer admin van .models import User @ admin.register (User) class UserAdmin (admin.ModelAdmin): pass

Laten we de wijzigingen in de database weergeven:

$ ./manage.py migratiemigraties $ ./manage.py migreren

We moeten nu een stuk code schrijven dat een e-mail verzendt wanneer een gebruikersinstantie wordt gemaakt. Dit is waar Django-signalen voor zijn, en dit is een perfecte gelegenheid om dit onderwerp aan te raken. 

Signalen worden afgevuurd voordat / nadat bepaalde gebeurtenissen in de toepassing plaatsvinden. We kunnen callback-functies definiëren die automatisch worden geactiveerd wanneer de signalen worden geactiveerd. Om een ​​callback-trigger te maken, moeten we deze eerst verbinden met een signaal.

We gaan een callback maken die wordt geactiveerd nadat een gebruikersmodel is gemaakt. We voegen deze code toe na de Gebruiker modeldefinitie in: main / models.py

van django.db.models importeer signalen van django.core.mail import send_mail def user_post_save (afzender, instantie, signaal, * args, ** kwargs): indien niet instance.is_verified: # Verstuur verificatie email send_mail ('Verifieer uw QuickPublisher-account ',' Volg deze link om uw account te verifiëren: "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 = Gebruiker)

Wat we hier hebben gedaan, is dat we een a hebben gedefinieerd user_post_save functie en verbond het met de post_save signaal (een dat wordt geactiveerd nadat een model is opgeslagen) verzonden door de Gebruiker model-.

Django stuurt niet alleen e-mails uit; het moet gekoppeld zijn aan een e-mailservice. Voor de eenvoud kunt u uw Gmail-inloggegevens toevoegen quick_publisher / settings.py, of je kunt je favoriete e-mailprovider toevoegen. 

Dit is hoe de configuratie van Gmail eruit ziet:

EMAIL_USE_TLS = True EMAIL_HOST = 'smtp.gmail.com' EMAIL_HOST_USER = '@ gmail.com 'EMAIL_HOST_PASSWORD =''EMAIL_PORT = 587

Om dingen uit te testen, gaat u naar het admin-paneel en maakt u een nieuwe gebruiker aan met een geldig e-mailadres dat u snel kunt controleren. Als alles goed is gegaan, ontvang je een e-mail met een verificatielink. De verificatie routine is nog niet klaar. 

Ga als volgt te werk om het account te verifiëren:

# main / views.py van django.http import Http404 van django.shortcuts importeren renderen, omleiden van .models importeren Gebruiker def huis (verzoek): return render (request, 'home.html') def verify (request, uuid): probeer: user = User.objects.get (verification_uuid = uuid, is_verified = False) behalve User.DoesNotExist: raise Http404 ("User bestaat niet of is al geverifieerd") user.is_verified = True user.save () return redirect ( 'huis')

Verbind de weergaven in: quick_publisher / urls.py

# quick_publisher / urls.py van django.conf.urls import url van django.contrib import admin van publisher.views import view_post van main.views import home, verifieer urlpatterns = [url (r '^ $', home, name = " home "), url (r '^ admin /', admin.site.urls), url (r '^ verifiëren / (? P[a-z0-9 \ -] +) / ', verify, name = "verify"), url (r' ^ (? P[a-zA-Z0-9 \ -] +) ', view_post, name = "view_post")]

Vergeet ook niet om een ​​te maken home.html bestand onder main / templates / home.html. Het wordt weergegeven door de huis uitzicht.

Probeer het hele scenario opnieuw uit te voeren. Als alles in orde is, ontvangt u een e-mail met een geldige verificatie-URL. Als u de URL volgt en vervolgens de beheerder incheckt, kunt u zien hoe het account is geverifieerd.

E-mails asynchroon verzenden

Dit is het probleem met wat we tot nu toe hebben gedaan. Je hebt misschien gemerkt dat het creëren van een gebruiker een beetje traag is. Dat komt omdat Django de verificatie-e-mail verzendt binnen de aanvraagtijd. 

Dit is hoe het werkt: we sturen de gebruikersgegevens naar de Django-applicatie. De applicatie maakt een Gebruiker model en maakt vervolgens een verbinding met Gmail (of een andere service die u hebt geselecteerd). Django wacht op het antwoord en pas daarna geeft het antwoord op onze browser. 

Hier komt Celery binnen. Controleer eerst of het is geïnstalleerd:

$ pip installeer Celery

We moeten nu een Celery-applicatie maken in onze Django-applicatie:

# quick_publisher / celery.py import os van selderijimport Celery os.environ.setdefault ('DJANGO_SETTINGS_MODULE', 'quick_publisher.settings') app = Celery ('quick_publisher') app.config_from_object ('django.conf: settings') # Load taakmodules van alle geregistreerde Django app-configs. app.autodiscover_tasks ()

Celery is een takenwachtrij. Het ontvangt taken van onze Django-applicatie en het zal ze op de achtergrond uitvoeren. Selderij moet worden gekoppeld aan andere diensten die optreden als makelaars. 

Makelaars bemiddelen tussen het verzenden van berichten tussen de webapplicatie en Celery. In deze zelfstudie gebruiken we Redis. Redis is eenvoudig te installeren en we kunnen er gemakkelijk mee aan de slag zonder al te veel gedoe.

U kunt Redis installeren door de instructies op de Redis Quick Start-pagina te volgen. U moet de Redis Python-bibliotheek installeren, pip install redis, en de bundel die nodig is voor het gebruik van Redis en Celery: pip install selderij [redis].

Start de Redis-server in een aparte console als deze: $ redis-server

Laten we de selderij / Redis gerelateerde configs toevoegen quick_publisher / settings.py:

# REDIS gerelateerde instellingen 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 '

Voordat iets in Celery kan worden uitgevoerd, moet het als een taak worden verklaard. 

Hier is hoe dit te doen:

# main / tasks.py import logging van django.urls import reverse van django.core.mail import send_mail van django.contrib.auth import get_user_model van 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 ('Verifieer uw QuickPublisher-account', 'Volg deze link om uw account te verifiëren:' http: // localhost: 8000% s '% reverse (' verify ') , kwargs = 'uuid': str (user.verification_uuid)), '[email protected]', [user.email], fail_silently = False,) behalve UserModel.DoesNotExist: logging.warning ("Geprobeerd om verificatie te verzenden email naar niet-bestaande gebruiker '% s' "% user_id)

Wat we hier hebben gedaan, is dit: we hebben de verzendverificatie-e-mailfunctionaliteit verplaatst naar een ander bestand met de naam tasks.py. 

Een paar opmerkingen:

• De naam van het bestand is belangrijk. Celery doorloopt alle apps in INSTALLED_APPS en registreert de taken in tasks.py bestanden.
• Let op hoe we de send_verification_email functie met @ app.task. Dit vertelt Celery dat dit een taak is die in de takenwachtrij wordt uitgevoerd.
• Let op hoe we als argument verwachten gebruikersnaam liever dan een Gebruiker voorwerp. Dit komt omdat we problemen kunnen hebben bij het serialiseren van complexe objecten bij het verzenden van de taken naar Celery. Het is het beste om ze eenvoudig te houden.

Teruggaan naar main / models.py, de signaalcode verandert in:

van django.db.models importeer signalen van main.tasks import send_verification_email def user_post_save (afzender, instantie, signaal, * args, ** kwargs): indien niet instance.is_verified: # Verstuur verificatie email send_verification_email.delay (instance.pk) signalen .post_save.connect (user_post_save, sender = Gebruiker)

Let op hoe we de .vertraging methode op het taakobject. Dit betekent dat we de taak naar Celery sturen en we wachten niet op het resultaat. Als we het hebben gebruikt send_verification_email (instance.pk) in plaats daarvan zouden we het nog steeds naar Celery sturen, maar wachten tot de taak is voltooid, wat niet is wat we willen.

Voordat u begint met het maken van een nieuwe gebruiker, is er een vangst. Selderij is een service en we moeten het starten. Open een nieuwe console, zorg ervoor dat u de juiste virtualenv activeert en navigeer naar de projectmap.

$ selderijwerker - Een quick_publisher - loglevel = debug --concurrency = 4

Dit start vier Celery-procesarbeiders. Ja, nu kun je eindelijk gaan en een nieuwe gebruiker maken. Merk op dat er geen vertraging is en let op de logboeken in de Celery-console en kijk of de taken correct worden uitgevoerd. Dit zou er ongeveer zo uit moeten zien:

[2017-04-28 15: 00: 09.190: DEBUG / MainProcess] Taak geaccepteerd: main.tasks.send_verification_email [f1f41e1f-ca39-43d2-a37d-9de085dc99de] pid: 62065 [2017-04-28 15: 00: 11.740: INFO / PoolWorker-2] Taak main.tasks.send_verification_email [f1f41e1f-ca39-43d2-a37d-9de085dc99de] is geslaagd in 2.5500912349671125s: Geen

Periodieke taken met selderij

Hier is nog een veelvoorkomend scenario. De meeste volwassen webtoepassingen sturen e-mails van gebruikers over de levenscyclus om hen betrokken te houden. Enkele veelvoorkomende voorbeelden van lifecycle-e-mails:

• maandelijkse verslagen
• activiteitenmeldingen (likes, vriendschapsverzoeken, etc.)
• herinneringen om bepaalde acties te voltooien ("Vergeet niet om uw account te activeren")

Dit is wat we gaan doen in onze app. We gaan tellen hoe vaak elk bericht is bekeken en sturen een dagelijks rapport naar de auteur. Eenmaal per dag gaan we door alle gebruikers, halen we hun berichten op en sturen we een e-mail met een tabel met de berichten en het aantal weergaven.

Laten we het veranderen Post model zodat we het scenario voor weergavetellingen kunnen aanpassen.

class Post (models.Model): author = models.ForeignKey (Gebruiker) created = models.DateTimeField ('Gecreëerde datum', default = timezone.now) title = models.CharField ('Title', max_length = 200) content = modellen .TextField ('Content') slug = models.SlugField ('Slug') view_count = models.IntegerField ("View Count", default = 0) def __str __ (self): retourneer '"% s" door% s'% ( self.title, self.author)

Zoals altijd, wanneer we een model wijzigen, moeten we de database migreren:

$ ./manage.py migratiemigraties $ ./manage.py migreren

Laten we ook het view_post Django-weergave om weergaven te tellen:

def view_post (request, slug): try: post = Post.objects.get (slug = slug) behalve Post.DoesNotExist: raise Http404 ("Poll bestaat niet") post.view_count + = 1 post.save () return render (request, 'post.html', context = 'post': post)

Het zou handig zijn om de kijkcijfers in de sjabloon. Voeg dit toe 

Bekeken post.view_count keer

 ergens binnen de uitgever / templates / post.html het dossier. Bekijk nu een paar keer een mening over een bericht en zie hoe de teller toeneemt.

Laten we een Celery-taak maken. Omdat het over berichten gaat, zal ik het plaatsen uitgever / tasks.py:

van django.template import Template, Context van django.core.mail import send_mail van django.contrib.auth import get_user_model van quick_publisher.celery import app van publisher.models import Post REPORT_TEMPLATE = "" "Zo deed u het tot nu toe: % voor bericht in berichten% "post.title": post.view_count keer bekeken | % endfor% "" "@ app.task def send_view_count_report (): voor gebruiker 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 ('berichten': berichten)), '[email protected]', [user.email], fail_silently = False,)

Elke keer dat u wijzigingen in de Celery-taken aanbrengt, moet u het proces Celery opnieuw starten. Selderij moet taken ontdekken en herladen. Voordat we een periodieke taak maken, moeten we dit testen in de Django-shell om te controleren of alles werkt zoals het bedoeld is:

$ ./manage.py shell In [1]: from publisher.tasks import send_view_count_report In [2]: send_view_count_report.delay ()

Hopelijk heb je een handig rapport ontvangen in je e-mail. 

Laten we nu een periodieke taak maken. Doe open quick_publisher / celery.py en registreer de periodieke taken:

# quick_publisher / celery.py import os van selderijimport Celery from selderery.schedules import crontab os.environ.setdefault ('DJANGO_SETTINGS_MODULE', 'quick_publisher.settings') app = Celery ('quick_publisher') app.config_from_object ('django.conf : instellingen ') # Laad taakmodules van alle geregistreerde Django app-configs. app.autodiscover_tasks () app.conf.beat_schedule = 'send-report-every-single-minute': 'task': 'publisher.tasks.send_view_count_report', 'schedule': crontab (), # wijziging in 'crontab (minuut = 0, uur = 0) 'als u wilt dat het dagelijks om middernacht wordt uitgevoerd,

Tot nu toe hebben we een schema gemaakt dat de taak zou uitvoeren publisher.tasks.send_view_count_report elke minuut zoals aangegeven door de crontab () notatie. U kunt ook verschillende Celery Crontab-schema's opgeven. 

Open een andere console, activeer de juiste omgeving en start de Celery Beat-service. 

$ selderie - een beat voor een snelle_uitgever

De taak van de Beat-service is om taken in Celery volgens het schema te pushen. Houd er rekening mee dat het schema de send_view_count_report taak wordt elke minuut uitgevoerd volgens de instelling. Het is goed voor testen, maar niet aanbevolen voor een real-world webapplicatie.

Taken betrouwbaarder maken

Taken worden vaak gebruikt om onbetrouwbare bewerkingen uit te voeren, bewerkingen die afhankelijk zijn van externe bronnen of die gemakkelijk kunnen mislukken vanwege verschillende redenen. Hier is een richtlijn om ze betrouwbaarder te maken:

• Maak taken idempotent. Een idempotente taak is een taak die, als hij halverwege wordt gestopt, de toestand van het systeem op geen enkele manier verandert. De taak maakt volledige wijzigingen in het systeem of helemaal geen.
• Probeer de taken opnieuw. Als de taak mislukt, is het een goed idee om het opnieuw en opnieuw te proberen totdat het met succes is uitgevoerd. Je kunt dit in Celery doen met Celery Retry. Een ander interessant ding om naar te kijken is het Exponential Backoff-algoritme. Dit kan van pas komen als u denkt aan het beperken van onnodige belasting van de server tegen opnieuw uitgevoerde taken.

conclusies

Ik hoop dat dit een interessante tutorial voor je is geweest en een goede kennismaking met het gebruik van Celery met Django. 

Hier zijn enkele conclusies die we kunnen trekken:

• Het is een goede gewoonte om onbetrouwbare en tijdrovende taken buiten de aanvraagtijd te houden.
• Langlopende taken moeten op de achtergrond worden uitgevoerd door werkprocessen (of andere paradigma's).
• Achtergrondtaken kunnen worden gebruikt voor verschillende taken die niet essentieel zijn voor het basisfunctioneren van de toepassing.
• Selderij kan ook periodieke taken aan met behulp van de selderijzerslag service.
• Taken kunnen betrouwbaarder zijn als ze idempotent worden gemaakt en opnieuw worden geprobeerd (misschien met behulp van exponentiële backoff).