Celery hija l-għodda standard għall-għamil ta' kompiti fil-isfond u ppjanati f'Django — xogħol li m'għandux jibbaċċa l-HTTP request (li jibgħat emails, ipproċessja tal-fajls, sejħiet lill-APIs bil-ħin twil) jew li jaħdem skond skeda. Il-kompiti jiġu mmexxjati fil-kju u ppproċessati b'mod asinkronu minn prosessi separati ta' worker.## Il-problema li Celery tissolvi```python
❌ doing slow work inline blocks the response — the user waits, risks timeouts
def register(request):
user = create_user(request.POST)
send_welcome_email(user) # slow — the user waits for the email to send
generate_report(user) # even slower
return redirect("home") # finally responds after all that
python
Għal xogħol bil-ħin twil inline, l-utenti jsiru jistennew u hemm riskju ta' timeout tal-request. Celery spostahom għal workers fil-isfond biex ir-request irraggel lura minnuċa.## Id-definizzjoni u għad-sejħa ta' kompitu ta' Celery
tasks.py — define a task
from celery import shared_task
@shared_task
def send_welcome_email(user_id):
user = User.objects.get(id=user_id)
send_email(user.email, "Welcome!") # runs in a WORKER, not the web process
in a view — QUEUE the task instead of running it inline
def register(request):
user = create_user(request.POST)
send_welcome_email.delay(user.id) # .delay() queues it → returns IMMEDIATELY
return redirect("home") # user gets a fast response
Id-dekorator `@shared_task` jiddefinisċi kompitu; `.delay()` (jew `.apply_async()`) jmexxiha fil-kju għal worker biex ipproċessaha b'mod asinkronu — il-view m'għandha jsibut.## L-arkitetturatext
Django (web) --.delay()--> BROKER (Redis/RabbitMQ) --> CELERY WORKER (processes the task)
(the message queue) (separate process/machine)
text
Components:
✓ Broker (Redis or RabbitMQ) — holds the queue of pending tasks
✓ Celery worker(s) — separate processes that pull and execute tasks
✓ Result backend (optional) — stores task results/status
Run workers separately: `celery -A myproject worker`
```## Kompiti ppjanati / perjodiċi (Celery Beat)```python
# run tasks on a schedule (like cron) via Celery Beat
CELERY_BEAT_SCHEDULE = {
"daily-report": {
"task": "myapp.tasks.generate_daily_report",
"schedule": crontab(hour=0, minute=0), # every midnight
},
}
```## Karatteristiċi ta' affidabilità```python
@shared_task(bind=True, max_retries=3, default_retry_delay=60)
def sync_data(self):
try:
do_sync()
except Exception as exc:
raise self.retry(exc=exc) # automatic retries on failure
``````text
✓ Retries with backoff (resilience against transient failures)
✓ Task persistence (queued tasks survive restarts via the broker)
✓ Scheduling (Celery Beat — periodic/cron-like tasks)
✓ Rate limiting, concurrency control, task routing/priorities
✓ Workers scale independently of web servers
```## Għaliex ikun importanti Kumpiti fil-isfond b'Celery huma għarfien essenzjali għall-ibnija ta' applikazzjonijiet Django responsivi u skalabbli, peress li ħafna bżonniet real-world jeħtieġu xogħol li m'għandux isseħħ inline matul request.Huwa importanti li tinftiehem għaliex il-problema fundamentali — li tisporta xogħol bil-ħin twil jew differit (li jibgħat emails, ipproċessja ta' immaġini/fajls, ġenerazzjoni ta' rapporti, sejħat lill-APIs esterni bil-ħin twil, sinkronizzazzjoni tad-data) mill-ċiklu ta' request-response — tinsab ovunqu fl-applikazzjonijiet ta' produzzjoni.Meta tagħmel xogħol bħal dan inline, l-utenti jsiru jistennew, hemm riskju ta' timeout tal-request, u tintilef ix-xogħol jekk ifalli, billi **Celery** tippermettilok tirraggel lura għall-utent immedjatament filwaqt li **workers** separati jpproċessaw ix-xogħol b'mod asinkronu u affidabbli.Lil hinn mill-offloading asinkronu sempliċi, Celery tipprovdi kapaċitajiet kritiċi tal-produzzjoni: **kompiti ppjanati/perjodiċi** (via Celery Beat, li tissolvi l-cron għal skedulazzjoni ta' livell ta' applikazzjoni — rapporti ġomnjali, kompiti tal-qolli, sinkronizzazzjonijiet rikorrenti), **retries awtomatiċi b'backoff** (resilienza kontra l-fallimenti transitorji), **persistenza tal-kompitu** (il-kompiti fil-kju jissurvjivaw ir-restarts via il-broker, għalhekk ix-xogħol m'intelefx), u **scaling indipendenti** ta' workers mill-web servers.Il-għarfien tal-arkitettura ta' Celery (il-broker bħal Redis/RabbitMQ li jżomm il-kju, workers li jpproċessaw il-kompiti, il-result backend), kif jiddefinixxi u jmexxi il-kompiti (`@shared_task`, `.delay()`), skedula tal-xogħol perjodiċi, u konfigurazzjoni tal-karatteristiċi ta' affidabilità hija għarfien validu ta' livell senior għall-ibnija ta' sistemi Django ta' produzzjoni li jittrattaw xogħol tqil jew differit b'eleganza.Peress li l-ipproċessar fil-isfond hija rekwiżit komuni u importanti għal applikazzjonijiet responsivi u robusti — u Celery hija s-soluzzjoni de facto standard fl-ekosistema ta' Django — li tmastikanenha hija ħila praktika, frekwentement rilevanti li tirrifletti l-abbilità li tippjana applikazzjonijiet Django real-world lil hinn mill-ħandfil sempliċi sinkronu ta' request.
