Tâches de fond en Python : comparatif de Celery, RQ, Dramatiq et APScheduler

Tôt ou tard, toute application web Python doit exécuter des tâches en dehors du cycle requête-réponse : envoyer un email après avoir renvoyé la réponse, générer un rapport, traiter un fichier téléversé, relancer un appel tiers instable. Exécuter ces traitements de manière synchrone rend l'application lente et fragile ; la bonne approche consiste à utiliser un système de tâches d'arrière-plan. La difficulté, c'est de choisir le bon. Celery, RQ, Dramatiq et APScheduler permettent tous d'exécuter des tâches en arrière-plan, mais ils répondent à des problèmes différents. Ce guide les compare de manière honnête pour vous aider à choisir l'outil adapté du premier coup.

Le modèle mental partagé

Toutes les files de tâches partagent la même structure. Votre application place un job (un nom de fonction accompagné de ses arguments) dans un courtier, généralement Redis ou RabbitMQ. Des processus worker distincts extraient les jobs de la file et les exécutent, en gérant les nouvelles tentatives, les échecs et les résultats. Votre processus web reste rapide car il ne fait que placer les jobs en file ; le travail lent s'effectue ailleurs.

  web app ──enqueue──▶ [ BROKER: Redis/RabbitMQ ] ──▶ worker pool ──▶ done
   (fast)                  holds the queue            (does the slow work)

   Same shape for Celery, RQ, and Dramatiq.
   They differ in features, simplicity, and operational weight.

Celery : la solution historique riche en fonctionnalités

Celery est le choix par défaut de longue date, le plus puissant et le plus largement déployé. Il prend en charge plusieurs courtiers, des workflows complexes (chaînes, groupes, accords), des tâches planifiées via son planificateur beat, la limitation de débit, les nouvelles tentatives et une surface de configuration étendue. Cette puissance a un coût : Celery a la réputation d'être complexe à configurer et de présenter des pièges opérationnels, et son ampleur peut être écrasante pour un besoin simple.

# tasks.py
from celery import Celery

app = Celery("app", broker="redis://localhost:6379/0", backend="redis://localhost:6379/1")

@app.task(bind=True, max_retries=3, autoretry_for=(ConnectionError,), retry_backoff=True)
def send_receipt(self, order_id: int) -> None:
    order = Order.objects.get(id=order_id)        # pass an ID, not the object
    email.send(order.email, render_receipt(order))

# Enqueue from your web app — returns instantly, work happens on a worker.
send_receipt.delay(order_id=42)

# Run workers:  celery -A tasks worker --concurrency=8
# Periodic:     celery -A tasks beat   (Celery's built-in scheduler)

RQ : la simplicité par conception

RQ (Redis Queue) est l'antithèse de l'ampleur de Celery : il est petit, lisible et ne fait qu'une chose : exécuter des fonctions Python sur des workers via Redis. Si vous pouvez lire son code source en un après-midi (c'est presque possible), vous pouvez comprendre son comportement en production. Le compromis est moins de fonctionnalités et une dépendance exclusive à Redis, mais pour une grande partie des applications, c'est exactement ce qu'il faut.

from redis import Redis
from rq import Queue

# Any plain function is a job — no decorator required.
def send_receipt(order_id: int) -> None:
    order = Order.objects.get(id=order_id)
    email.send(order.email, render_receipt(order))

queue = Queue(connection=Redis())
queue.enqueue(send_receipt, 42, retry=Retry(max=3))   # enqueue and move on

# Run a worker:  rq worker

Dramatiq : le juste milieu moderne

Dramatiq a été conçu pour conserver l'essentiel de l'utilité de Celery tout en étant plus simple et plus fiable par défaut. Il offre un comportement sensé dès le départ : nouvelles tentatives automatiques, limites d'âge des messages et fonctionnalités de fiabilité qu'il faut assembler ou paramétrer ailleurs. Pour les équipes qui trouvent Celery trop lourd mais RQ trop dépouillé, Dramatiq est souvent le point d'équilibre idéal.

import dramatiq

# Retries and sane defaults are built in; you opt into specifics per actor.
@dramatiq.actor(max_retries=3, time_limit=30_000)
def send_receipt(order_id: int) -> None:
    order = Order.objects.get(id=order_id)
    email.send(order.email, render_receipt(order))

send_receipt.send(42)        # enqueue

# Run workers:  dramatiq tasks

APScheduler : un outil différent pour un travail différent

APScheduler n'est pas une file de tâches, c'est un planificateur. Son rôle est d'exécuter du code sur un déclencheur temporel : toutes les heures, chaque jour de semaine à 9 h, dans trente minutes. C'est la réponse intégrée au processus pour « fais ceci selon un planning ». Il est important de noter qu'il ne fournit pas, à lui seul, un pool de workers distribué avec nouvelles tentatives et mise en file d'attente ; pour les travaux planifiés qui sont également lourds ou doivent passer à l'échelle, le modèle courant consiste à laisser un planificateur simplement placer des jobs dans une file de tâches.

from apscheduler.schedulers.background import BackgroundScheduler
from apscheduler.triggers.cron import CronTrigger

scheduler = BackgroundScheduler()

# Don't do the heavy work here — just drop a job onto the real task queue.
@scheduler.scheduled_job(CronTrigger(hour=2, minute=0))   # every day at 02:00
def nightly_reports():
    for tenant_id in active_tenant_ids():
        generate_report.delay(tenant_id)    # Celery/RQ/Dramatiq does the actual work

scheduler.start()

Guide de décision

Réalités opérationnelles pour tous

Quel que soit votre choix, les mêmes réalités s'appliquent : rendez les tâches idempotentes, car elles s'exécuteront parfois plus d'une fois ; gardez les arguments de tâche petits et sérialisables (passez un ID, pas un objet volumineux) ; configurez les tentatives avec backoff pour les échecs transitoires et une file de lettres mortes pour les échecs permanents ; et surveillez la profondeur de votre file d'attente, car un arriéré qui s'accumule silencieusement est la façon dont les systèmes d'arrière-plan échouent de manière invisible.

Pratiquez en déplacement

Apprenez Python, l'application Android gratuite

Chaque sujet de cette série est également dans l'application : leçons en bouchées, exemples exécutables, quiz, mini-projets et un environnement Python hors ligne qui fonctionne sur votre téléphone.

Disponible sur Google Play Voir la page de l'application