PricingLoginStart free
FastAPI बैकएंड डेवलपमेंट बूटकैंप · पाठ

Celery Beat के साथ निर्धारित और आवधिक जॉब

Celery Beat से दोहराए जाने वाले जॉब चलाइए और अनेक वर्करों में क्रॉन-शैली की समय-सारणी का सुरक्षित समन्वय कीजिए।

पाठ 4, कुल 4 में से13 चरण

Celery Beat के साथ निर्धारित और आवधिक जॉब, CoddyKit पर FastAPI बैकएंड डेवलपमेंट बूटकैंप का एक निःशुल्क पाठ है। यह 4 में से 4वाँ पाठ है। इस अध्ययन पथ के 3 तक कोई भी पाठ पूरा पढ़ना निःशुल्क है — इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ व्यावहारिक अभ्यास भी उपलब्ध कराता है। यह FastAPI बैकएंड डेवलपमेंट बूटकैंप सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। FastAPI बैकएंड डेवलपमेंट बूटकैंप पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

सेलेरी बीट क्यों?

आपका FastAPI app सेलेरी के साथ एक-बार चलने वाले background tasks आसानी से शुरू कर देता है, लेकिन कुछ काम एक schedule पर चलने चाहिए: हर सुबह सारांश ईमेल भेजना, हर 10 मिनट में छोड़ी गई carts को expire करना, या हर रात analytics की दोबारा गणना करना।

सेलेरी बीट एक scheduler process है। यह स्वयं tasks execute नहीं करता — यह हर tick पर जागता है, तय करता है कि कौन-से tasks due हैं, और उन्हें broker (Redis/RabbitMQ) में भेज देता है। आपके सामान्य celery worker processes उन्हें उठाकर चलाते हैं।

  • बीट = due tasks प्रकाशित करने वाली घड़ी।
  • वर्कर = उन्हें चलाने वाली कार्य-शक्ति।

यही अलगाव periodic jobs को scale करने का पूरा कारण है: एक बीट, कई वर्कर।

Schedule परिभाषित करना

Schedules सेलेरी app में conf.beat_schedule के अंतर्गत रहती हैं। प्रत्येक entry किसी नाम को एक dict से जोड़ती है, जिसमें task path, एक schedule (सेकंड, timedelta या crontab) और वैकल्पिक args/kwargs होते हैं।

सबसे सरल schedule एक निश्चित interval है। नीचे cleanup task हर 30 सेकंड में चलता है। Task path string worker के registered नाम से बिल्कुल मेल खानी चाहिए।

from celery import Celery
from datetime import timedelta

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

@app.task(name="tasks.cleanup_sessions")
def cleanup_sessions():
    # delete expired sessions from the DB
    return "cleaned"

app.conf.beat_schedule = {
    "cleanup-every-30s": {
        "task": "tasks.cleanup_sessions",
        "schedule": timedelta(seconds=30),
    },
}

crontab() के साथ Cron-शैली के schedules

Fixed intervals मोटे होते हैं। वास्तविक calendar logic — "हर कार्यदिवस 07:30 पर" — के लिए celery.schedules.crontab का उपयोग करें। यह Unix cron fields की नकल करता है: minute, hour, day_of_week, day_of_month, month_of_year।

  • crontab(minute=0, hour=0) — हर दिन आधी रात।
  • crontab(minute="*/15") — हर 15 मिनट।
  • crontab(hour=7, minute=30, day_of_week="1-5") — सोमवार से शुक्रवार, 07:30 बजे।

जिन fields को सेट नहीं किया जाता, उनका default * (हर मान) होता है, बिल्कुल crontab line की तरह।

from celery.schedules import crontab

app.conf.beat_schedule = {
    "morning-digest": {
        "task": "tasks.send_digest",
        "schedule": crontab(hour=7, minute=30, day_of_week="1-5"),
    },
    "quarter-hour-sync": {
        "task": "tasks.sync_inventory",
        "schedule": crontab(minute="*/15"),
    },
}

हर entry के लिए args और options देना

हर schedule entry में arguments और प्रति-call options हो सकते हैं। अलग-अलग entries में उसी task को अलग तरह से parameterize करने के लिए args (positional) या kwargs (keyword) का उपयोग करें। options dict आपको periodic task को किसी खास queue में भेजने, expires सेट करने या priority बदलने देता है।

Periodic jobs के लिए expires महत्वपूर्ण है: यदि बीट कोई task queue में डाल दे, लेकिन workers पर काम का दबाव हो, तो expired message देर से चलने और कतार में जमा होने के बजाय discard हो जाता है।

from celery.schedules import crontab

app.conf.beat_schedule = {
    "warm-cache-eu": {
        "task": "tasks.warm_cache",
        "schedule": crontab(minute="*/5"),
        "kwargs": {"region": "eu-west"},
        "options": {"queue": "cache", "expires": 120},
    },
    "warm-cache-us": {
        "task": "tasks.warm_cache",
        "schedule": crontab(minute="*/5"),
        "kwargs": {"region": "us-east"},
        "options": {"queue": "cache", "expires": 120},
    },
}

Decorator के साथ schedules register करना

एक बहुत बड़े beat_schedule dict के बजाय, आप on_after_configure signal और app.add_periodic_task का उपयोग करके entries को tasks के पास register कर सकते हैं। इससे schedule उस code के साथ रहती है जिसे वह trigger करती है और पुराने string paths से बचा जा सकता है।

add_periodic_task(schedule, signature, name=...) पहले interval या crontab और उसके बाद task signature लेता है। Arguments पहले से शामिल करने के लिए आप task.s(arg) दे सकते हैं।

from celery import Celery
from celery.schedules import crontab

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

@app.task
def rotate_logs(target):
    return f"rotated {target}"

@app.on_after_configure.connect
def setup_periodic_tasks(sender, **kwargs):
    sender.add_periodic_task(
        crontab(hour=3, minute=0),
        rotate_logs.s("app.log"),
        name="nightly-log-rotation",
    )

Timezones: schedule की सबसे बड़ी bug

डिफ़ॉल्ट रूप से सेलेरी crontab के समय को UTC में समझता है। यदि आप स्थानीय 07:00 की अपेक्षा से crontab(hour=7) लिखते हैं, तो आपका job गलत wall-clock समय पर चलेगा। हमेशा timezone स्पष्ट रूप से सेट करें और सोच-समझकर निर्णय लें।

  • timezone — वह zone जिसमें crontab के समय evaluate किए जाते हैं।
  • enable_utc=True — आंतरिक timestamps को UTC में रखें (अनुशंसित), और फिर भी crontabs को अपने चुने हुए timezone में evaluate करें।

Timezone को config में स्थिर रूप से तय करें, ताकि host के स्थानीय TZ की परवाह किए बिना हर developer और हर server सहमत हो।

app.conf.update(
    timezone="Europe/Istanbul",
    enable_utc=True,
)

# crontab(hour=9, minute=0) now means 09:00 Europe/Istanbul,
# stored/transmitted internally as UTC.

बीट चलाना और persistent schedule file

आप scheduler को अपनी अलग process के रूप में शुरू करते हैं। डिफ़ॉल्ट scheduler अपनी "last run" स्थिति एक छोटी file में रखता है, ताकि restart के बाद वह हर चीज़ को फिर से न चलाए।

  • celery -A app beat -l info — बीट चलाएँ।
  • --schedule /var/run/celerybeat-schedule — shelve state file का स्थान।
  • Development में आप worker + beat को साथ चला सकते हैं: celery -A app worker -B, लेकिन production में -B का उपयोग कभी न करें — इससे घड़ी एक worker के lifetime से बँध जाती है।

Production में ठीक एक बीट process चलाएँ। दो बीट = हर periodic task दो बार चलेगा।

Workers के बीच single-scheduler नियम

आप workers को दर्जनों pods तक horizontally scale कर सकते हैं और सेलेरी इसे संभालता है: broker प्रत्येक queued message को ठीक एक worker में वितरित करता है। लेकिन बीट घड़ी है, और आपको केवल एक घड़ी चलानी चाहिए।

यदि दो बीट processes चलती हैं, तो प्रत्येक स्वतंत्र रूप से तय करती है कि कोई task due है और उसे publish करती है, इसलिए subscribers को डुप्लिकेट executions दिखाई देते हैं। यह गलती से होने के सामान्य तरीके:

  • किसी pod की दो replicas, जो दोनों beat शुरू करती हैं।
  • worker -B का उपयोग करके उस worker deployment को 2 या अधिक replicas तक scale करना।

समाधान: worker Deployment से अलग एक dedicated Beat Deployment रखें, जिसमें replicas: 1 हो और worker Deployment को स्वतंत्र रूप से scale करें।

Idempotency: duplicates से बचे रहने वाले tasks design करना

एक ही बीट होने पर भी duplicates हो सकते हैं — गलत सेकंड पर बीट restart होना, at-least-once broker redelivery, या operator की गलती। मजबूत defense यह है कि periodic tasks को idempotent बनाया जाए: दो बार चलाने पर प्रभाव एक बार चलाने जैसा ही हो।

एक सरल pattern Redis में SET NX और expiry का उपयोग करके short-lived distributed lock बनाना है। जो lock प्राप्त करता है वही काम करता है; समवर्ती या डुप्लिकेट runs सुरक्षित रूप से skip हो जाते हैं।

import redis

r = redis.Redis(host="localhost", port=6379, db=0)

@app.task(name="tasks.charge_subscriptions")
def charge_subscriptions():
    # acquire a lock valid for 300s; only one runner proceeds
    got = r.set("lock:charge_subscriptions", "1", nx=True, ex=300)
    if not got:
        return "skipped: already running"
    try:
        # ... perform the billing run exactly once ...
        return "charged"
    finally:
        r.delete("lock:charge_subscriptions")

django-celery-beat / RedBeat के साथ database-backed schedules

डिफ़ॉल्ट file scheduler का अर्थ है कि schedule बदलने के लिए code edit करना और बीट restart करना पड़ता है। Dynamic schedules के लिए आपको ऐसा backend store चाहिए जिसे runtime पर edit किया जा सके।

  • RedBeat — schedules को Redis में store करता है; Redis-only FastAPI stack के लिए बहुत अच्छा है। beat_scheduler = "redbeat.RedBeatScheduler" सेट करें।
  • django-celery-beat — entries को SQL tables में store करता है, जिन्हें admin UI के माध्यम से edit किया जा सकता है।

RedBeat Redis-आधारित lock भी देता है, ताकि यदि आप गलती से दो बीट शुरू कर दें, तो केवल एक active scheduler रहे — single-clock नियम के लिए यह safety net है।

app.conf.update(
    redbeat_redis_url="redis://localhost:6379/1",
    beat_scheduler="redbeat.RedBeatScheduler",
    beat_max_loop_interval=5,
)

स्वतंत्र cron-due जाँच

यह समझने के लिए कि प्रत्येक tick पर बीट क्या करता है, यहाँ एक छोटा standalone simulation है: cron जैसे jobs की सूची (सेकंड में interval और last-run timestamp) देकर तय करें कि अभी कौन-से jobs due हैं। यही वह core loop है जिसे बीट चलाता है — "now" की तुलना "next due" से करना — और इसमें कोई broker नहीं है।

def due_jobs(now, jobs):
    fired = []
    for name, interval, last_run in jobs:
        if now - last_run >= interval:
            fired.append(name)
    return fired

jobs = [
    ("cleanup", 30, 0),
    ("digest", 3600, 3500),
    ("sync", 900, 100),
]

now = 1000
print(due_jobs(now, jobs))  # ['cleanup', 'sync']

त्वरित जाँच: डुप्लिकेट periodic runs से बचना

आप FastAPI + सेलेरी stack को Kubernetes पर deploy करते हैं। Load संभालने के लिए आप अपने worker Deployment को 4 replicas तक scale करते हैं और हर worker को celery -A app worker -B के साथ शुरू करते हैं। Periodic tasks हर बार 4 बार चलने लगते हैं। सही समाधान क्या है?

इंटरैक्टिव पाठ में इसका उत्तर दें

पुनरावलोकन

अब आप सेलेरी बीट के साथ recurring work schedule कर सकते हैं:

  • बीट schedule करता है, workers execute करते हैं — बीट broker में due tasks publish करता है; एक बीट, कई workers।
  • Schedules beat_schedule में या add_periodic_task के माध्यम से रहती हैं; intervals के लिए timedelta और calendar logic के लिए crontab() का उपयोग करें।
  • प्रत्येक entry के args/options tasks को parameterize करते हैं और पुराने जमा हुए tasks से बचने के लिए queue/expires सेट करते हैं।
  • Timezones डिफ़ॉल्ट रूप से UTC होते हैं — timezone + enable_utc को स्पष्ट रूप से तय करें।
  • केवल एक घड़ी — production में कभी worker -B न चलाएँ; एक dedicated Beat replica चलाएँ।
  • Idempotency (Redis SET NX locks) डुप्लिकेट या redelivered runs से सुरक्षा देती है।
  • RedBeat / django-celery-beat runtime पर editable, persistent और lock-protected schedules देते हैं।
शुरुआत निःशुल्क

एआई शिक्षक के साथ FastAPI बैकएंड डेवलपमेंट बूटकैंप सीखें — निःशुल्क

अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।

पाठ्यक्रम
21
पाठ
84
निःशुल्क सीखना शुरू करेंपूरा पाठ्यक्रम देखें

अक्सर पूछे जाने वाले प्रश्न

क्या “Celery Beat के साथ निर्धारित और आवधिक जॉब” पाठ निःशुल्क है?

हाँ — FastAPI बैकएंड डेवलपमेंट बूटकैंप अध्ययन पथ के 3 तक कोई भी पाठ, जिसमें “Celery Beat के साथ निर्धारित और आवधिक जॉब” भी शामिल है, यहाँ वेब पर पूरा पढ़ना निःशुल्क है। इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ इंटरैक्टिव अभ्यास भी उपलब्ध कराता है। FastAPI बैकएंड डेवलपमेंट बूटकैंप पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

“Celery Beat के साथ निर्धारित और आवधिक जॉब” में मैं क्या सीखूँगा?

Celery Beat से दोहराए जाने वाले जॉब चलाइए और अनेक वर्करों में क्रॉन-शैली की समय-सारणी का सुरक्षित समन्वय कीजिए। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ FastAPI बैकएंड डेवलपमेंट बूटकैंप का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।

क्या FastAPI बैकएंड डेवलपमेंट बूटकैंप शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?

पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर FastAPI बैकएंड डेवलपमेंट बूटकैंप शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 4वाँ पाठ है।

“Celery Beat के साथ निर्धारित और आवधिक जॉब” पाठ पूरा करने में कितना समय लगता है?

CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।

क्या मैं इस FastAPI बैकएंड डेवलपमेंट बूटकैंप पाठ में कोड लिख और चला सकता हूँ?

हाँ। हर FastAPI बैकएंड डेवलपमेंट बूटकैंप पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।

इस पाठ्यक्रम के सभी पाठ

  1. BackgroundTasks के साथ हल्का ऑफलोडिंग
  2. Celery वर्करों को FastAPI ऐप से जोड़ना
  3. पुनःप्रयास, इडेम्पोटेंसी और डेड-लेटर प्रबंधन
  4. Celery Beat के साथ निर्धारित और आवधिक जॉब
← FastAPI बैकएंड डेवलपमेंट बूटकैंप पर वापस जाएँ