Django i Celery: Asynchroniczne Przetwarzanie Zadań oraz Pytania Rekrutacyjne 2026

Współczesne aplikacje webowe wymagają znacznie więcej niż tylko obsługi żądań HTTP. Wysyłanie e-maili, generowanie raportów, przetwarzanie obrazów czy synchronizacja danych z zewnętrznymi API — to wszystko operacje, które nie powinny blokować głównego wątku aplikacji Django. Właśnie w takich scenariuszach Celery okazuje się niezastąpionym narzędziem, umożliwiającym asynchroniczne przetwarzanie zadań w sposób niezawodny i skalowalny.

W 2026 roku znajomość integracji Django z Celery stanowi jeden z kluczowych wymogów stawianych programistom Python podczas rozmów kwalifikacyjnych. Niniejszy artykuł omawia konfigurację Celery w projekcie Django, pisanie i wysyłanie zadań, zarządzanie kolejkami, zadania periodyczne, monitoring oraz praktyki produkcyjne — a na koniec przedstawia najczęstsze pytania rekrutacyjne z tego zakresu.

Integracja Celery z Django — konfiguracja projektu

Pierwszym krokiem jest utworzenie pliku celery.py w głównym katalogu projektu Django. Plik ten inicjalizuje instancję Celery, wskazuje na ustawienia Django i automatycznie wykrywa zadania zdefiniowane w aplikacjach.

# myproject/celery.py
import os
from celery import Celery

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

app = Celery('myproject')
app.config_from_object('django.conf:settings', namespace='CELERY')
app.autodiscover_tasks()

Metoda config_from_object z parametrem namespace='CELERY' sprawia, że wszystkie ustawienia Celery w settings.py muszą być poprzedzone prefiksem CELERY_. Dzięki autodiscover_tasks() Celery automatycznie przeszukuje moduły tasks.py we wszystkich zarejestrowanych aplikacjach Django.

Następnie należy skonfigurować brokera wiadomości i backend wyników w pliku settings.py. Redis jest najczęściej wybieranym brokerem ze względu na prostotę konfiguracji i niski narzut:

# myproject/settings.py
CELERY_BROKER_URL = 'redis://localhost:6379/0'
CELERY_RESULT_BACKEND = 'redis://localhost:6379/1'
CELERY_ACCEPT_CONTENT = ['json']
CELERY_TASK_SERIALIZER = 'json'
CELERY_RESULT_SERIALIZER = 'json'
CELERY_TIMEZONE = 'UTC'

Warto zwrócić uwagę na rozdzielenie baz danych Redis — broker wykorzystuje bazę 0, a backend wyników bazę 1. Serializacja JSON jest zalecanym formatem ze względu na bezpieczeństwo (w przeciwieństwie do pickle, który pozwala na deserializację dowolnych obiektów Python).

Pisanie i wysyłanie zadań asynchronicznych

Zadania w Celery definiuje się za pomocą dekoratora @shared_task. Parametr bind=True umożliwia dostęp do instancji zadania (obiekt self), co jest niezbędne przy implementacji logiki ponawiania prób.

# orders/tasks.py
from celery import shared_task
from django.core.mail import send_mail
from orders.models import Order

@shared_task(bind=True, max_retries=3, default_retry_delay=60)
def send_order_confirmation(self, order_id: int) -> str:
    """Send confirmation email for a completed order."""
    try:
        order = Order.objects.select_related('user').get(id=order_id)
        send_mail(
            subject=f'Order #{order.id} Confirmed',
            message=f'Your order totaling {order.total} has been confirmed.',
            from_email='noreply@example.com',
            recipient_list=[order.user.email],
        )
        return f'Email sent for order {order_id}'
    except Order.DoesNotExist:
        return f'Order {order_id} not found'
    except Exception as exc:
        # Retry on transient failures (SMTP timeout, etc.)
        raise self.retry(exc=exc)

Kilka istotnych elementów tego wzorca zasługuje na uwagę. Po pierwsze, do zadania przekazywany jest order_id (typ prosty), a nie obiekt modelu — serializacja obiektów ORM prowadziłaby do problemów z nieaktualnymi danymi. Po drugie, select_related('user') minimalizuje liczbę zapytań do bazy danych. Po trzecie, mechanizm self.retry(exc=exc) ponawia zadanie do trzech razy z 60-sekundowym odstępem w przypadku przejściowych awarii, takich jak timeout serwera SMTP.

Wysyłanie zadania z poziomu widoku Django jest niezwykle proste — wystarczy wywołać metodę .delay():

# orders/views.py
from orders.tasks import send_order_confirmation

def complete_order(request, order_id):
    # ... process payment, update order status ...
    send_order_confirmation.delay(order_id)
    return redirect('order_success', order_id=order_id)

Metoda .delay() jest skróconą wersją .apply_async(). Zadanie trafia do kolejki brokera i jest przetwarzane przez dostępnego workera, podczas gdy użytkownik natychmiast otrzymuje przekierowanie na stronę sukcesu — bez oczekiwania na wysłanie e-maila.

Routing zadań i zarządzanie kolejkami

W aplikacjach produkcyjnych różne typy zadań mają odmienne wymagania dotyczące zasobów i priorytetów. Routing zadań pozwala kierować konkretne zadania do dedykowanych kolejek:

# myproject/settings.py
CELERY_TASK_ROUTES = {
    'orders.tasks.send_order_confirmation': {'queue': 'notifications'},
    'reports.tasks.generate_monthly_report': {'queue': 'reports'},
    'images.tasks.resize_upload': {'queue': 'media'},
}

Każda kolejka może być obsługiwana przez osobnego workera z indywidualną konfiguracją współbieżności i puli procesów:

# Start notification worker (fast tasks, high concurrency)
celery -A myproject worker -Q notifications -c 8 --loglevel=info

# Start report worker (slow tasks, limited concurrency)
celery -A myproject worker -Q reports -c 2 --loglevel=info

# Start media worker (CPU-bound, prefork pool)
celery -A myproject worker -Q media -c 4 -P prefork --loglevel=info

Taka architektura zapewnia, że długotrwałe raporty nie blokują szybkich powiadomień, a zadania wymagające dużej mocy obliczeniowej (np. przetwarzanie obrazów) działają w puli procesów prefork zamiast domyślnej puli wątków. Współbieżność -c 8 dla powiadomień oznacza, że worker może obsługiwać jednocześnie osiem zadań — co jest odpowiednie dla operacji I/O-bound, takich jak wysyłanie e-maili.

Zadania periodyczne z Celery Beat

Celery Beat to planista zadań, który wysyła zadania do workerów zgodnie ze zdefiniowanym harmonogramem. Konfiguracja odbywa się bezpośrednio w settings.py:

# myproject/settings.py
from celery.schedules import crontab

CELERY_BEAT_SCHEDULE = {
    'cleanup-expired-sessions': {
        'task': 'accounts.tasks.cleanup_expired_sessions',
        'schedule': crontab(hour=3, minute=0),  # Daily at 3 AM UTC
    },
    'sync-inventory': {
        'task': 'inventory.tasks.sync_external_inventory',
        'schedule': 300.0,  # Every 5 minutes
    },
    'generate-weekly-digest': {
        'task': 'notifications.tasks.send_weekly_digest',
        'schedule': crontab(hour=9, minute=0, day_of_week='monday'),
    },
}

Uruchomienie procesu Beat odbywa się osobnym poleceniem:

celery -A myproject beat --loglevel=info

Należy pamiętać, że w środowisku produkcyjnym powinien działać dokładnie jeden proces Beat — uruchomienie wielu instancji skutkowałoby wielokrotnym wysyłaniem tych samych zadań. Rozszerzenie django-celery-beat umożliwia zarządzanie harmonogramem przez panel administracyjny Django, co jest szczególnie przydatne, gdy harmonogram musi być modyfikowany bez wdrażania nowego kodu.

Monitoring z Flower

Flower to webowy interfejs monitorowania Celery, który zapewnia wgląd w stan workerów, kolejek i zadań w czasie rzeczywistym:

# Install and run Flower
pip install flower
celery -A myproject flower --port=5555

Flower udostępnia informacje o aktywnych, zarezerwowanych i ukończonych zadaniach, statystyki workerów, długości kolejek oraz historię wykonania zadań. W środowisku produkcyjnym Flower powinien być zabezpieczony mechanizmem uwierzytelniania (np. --basic_auth=user:password) i dostępny wyłącznie przez VPN lub wewnętrzną sieć.

Do bardziej zaawansowanego monitoringu warto rozważyć integrację z narzędziami takimi jak Prometheus i Grafana — eksporter celery-exporter udostępnia metryki Celery w formacie kompatybilnym z Prometheus.

Django 6.0 — wbudowany system zadań a Celery

Django 6.0 wprowadza wbudowany framework do obsługi zadań w tle (oparty na PEP 703 i usprawnieniach GIL). Nowy system oferuje uproszczoną konfigurację dla prostych scenariuszy — nie wymaga zewnętrznego brokera wiadomości do podstawowych przypadków użycia.

Jednakże Celery pozostaje niezbędnym narzędziem w następujących sytuacjach:

• Zaawansowany routing zadań — kierowanie zadań do dedykowanych kolejek i workerów
• Zadania periodyczne — Celery Beat oferuje dojrzały i elastyczny mechanizm planowania
• Ponowne próby z wykładniczym cofaniem — wbudowany mechanizm retry w Celery jest bardziej rozbudowany
• Łańcuchy i grupy zadań — orkiestracja złożonych przepływów pracy (chains, groups, chords)
• Skalowanie horyzontalne — Celery wspiera rozproszone przetwarzanie na wielu maszynach
• Monitoring produkcyjny — Flower i integracja z Prometheus/Grafana

W praktyce wbudowany system Django 6.0 sprawdza się w prostych zadaniach (np. wysłanie pojedynczego e-maila), natomiast Celery pozostaje standardem w architekturach wymagających niezawodności, skalowalności i zaawansowanej orkiestracji.

Pytania rekrutacyjne — Django i Celery

Poniżej przedstawiono najczęściej zadawane pytania podczas rozmów kwalifikacyjnych dotyczących integracji Django z Celery w 2026 roku:

Czym jest Celery i dlaczego stosuje się go z Django? Celery to rozproszona kolejka zadań umożliwiająca asynchroniczne przetwarzanie operacji poza cyklem żądanie-odpowiedź Django. Stosuje się go do operacji czasochłonnych (e-maile, raporty, przetwarzanie plików), aby nie blokować głównego wątku obsługującego żądania HTTP.

Jaka jest różnica między .delay() a .apply_async()? Metoda .delay() to skrócona forma .apply_async() — przyjmuje argumenty pozycyjne i kluczowe. .apply_async() oferuje dodatkowe opcje, takie jak countdown, eta, queue, priority i link (callback).

Jak działa mechanizm ponownych prób (retry) w Celery? Dekorator @shared_task przyjmuje parametry max_retries i default_retry_delay. Wewnątrz zadania wywołuje się self.retry(exc=exc), co ponownie umieszcza zadanie w kolejce. Parametr bind=True jest wymagany do uzyskania dostępu do self.

Co oznacza parametr CELERY_TASK_ACKS_LATE? Domyślnie Celery potwierdza odebranie zadania natychmiast po jego pobraniu z kolejki. Ustawienie ACKS_LATE = True powoduje potwierdzenie dopiero po zakończeniu wykonania zadania — jeśli worker ulegnie awarii, zadanie zostanie ponownie dostarczone innemu workerowi.

Jak zapobiec wyciekom pamięci w workerach Celery? Parametr CELERY_WORKER_MAX_TASKS_PER_CHILD określa maksymalną liczbę zadań przetworzonych przez proces potomny przed jego recyklingiem. Ustawienie np. na 1000 zapobiega akumulacji pamięci w długo działających procesach.

Jaka jest rola Celery Beat i jak zapewnić, że działa tylko jedna instancja? Celery Beat to proces planisty, który wysyła zadania periodyczne do kolejki. W środowisku produkcyjnym musi działać dokładnie jedna instancja — można to zapewnić za pomocą blokady w bazie danych (django-celery-beat) lub ograniczenia na poziomie systemd/supervisord.

Czym różni się pula prefork od puli gevent/eventlet? Pula prefork tworzy oddzielne procesy (idealna dla zadań CPU-bound), natomiast gevent i eventlet wykorzystują green threads (idealne dla zadań I/O-bound). Wybór puli zależy od charakterystyki zadań przetwarzanych przez danego workera.

Jak monitorować Celery w produkcji? Flower zapewnia webowy interfejs monitorowania w czasie rzeczywistym. Dla zaawansowanego monitoringu stosuje się integrację z Prometheus (celery-exporter) i Grafana, co umożliwia alerty, dashboardy i analizę trendów.

Lista kontrolna wdrożenia produkcyjnego

Przed wdrożeniem Celery na środowisko produkcyjne należy zastosować odpowiednie ustawienia zabezpieczające stabilność i niezawodność systemu:

# myproject/settings.py — Production configuration
CELERY_TASK_ALWAYS_EAGER = False  # Never True in production
CELERY_TASK_ACKS_LATE = True  # Redelivery on worker crash
CELERY_WORKER_PREFETCH_MULTIPLIER = 1  # Fair scheduling
CELERY_TASK_REJECT_ON_WORKER_LOST = True  # Reject on unexpected exit
CELERY_TASK_TIME_LIMIT = 300  # Hard kill after 5 minutes
CELERY_TASK_SOFT_TIME_LIMIT = 240  # SoftTimeLimitExceeded after 4 min
CELERY_WORKER_MAX_TASKS_PER_CHILD = 1000  # Prevent memory leaks
CELERY_BROKER_CONNECTION_RETRY_ON_STARTUP = True

Kluczowe parametry to: ACKS_LATE (ponowne dostarczenie zadania w przypadku awarii workera), TIME_LIMIT (twarde zabicie zadania po przekroczeniu limitu czasu), SOFT_TIME_LIMIT (rzucenie wyjątku SoftTimeLimitExceeded, dając zadaniu szansę na zakończenie) oraz MAX_TASKS_PER_CHILD (recykling procesów zapobiegający wyciekom pamięci).

Workery Celery w produkcji powinny być zarządzane przez systemd lub supervisord:

# /etc/systemd/system/celery-worker.service
[Unit]
Description=Celery Worker
After=network.target redis.service

[Service]
Type=forking
User=django
Group=django
WorkingDirectory=/opt/myproject
ExecStart=/opt/myproject/venv/bin/celery -A myproject worker \
    --loglevel=info --concurrency=4 --pidfile=/var/run/celery/worker.pid
ExecStop=/bin/kill -s TERM $MAINPID
Restart=always

[Install]
WantedBy=multi-user.target

Konfiguracja Restart=always zapewnia automatyczne ponowne uruchomienie workera w przypadku nieoczekiwanego zakończenia. Dyrektywa After=network.target redis.service gwarantuje, że Redis jest dostępny przed startem workera.

Podsumowanie

Integracja Django z Celery pozostaje fundamentalnym wzorcem architektonicznym w ekosystemie Python w 2026 roku. Prawidłowa konfiguracja brokera, routing zadań do dedykowanych kolejek, mechanizm ponownych prób oraz monitoring produkcyjny to elementy, których znajomość jest niezbędna zarówno podczas budowania skalowalnych aplikacji, jak i podczas rozmów kwalifikacyjnych. Warto pamiętać, że choć Django 6.0 wprowadza wbudowany system zadań, Celery wciąż dominuje w projektach wymagających zaawansowanej orkiestracji, skalowalności horyzontalnej i niezawodności na poziomie produkcyjnym.