فرض کنید هر شب ساعت ۰۲:۰۰ باید قیمت رقبا را بگیرید، با دادهٔ دیروز مقایسه کنید، در DB ذخیره کنید و یک گزارش کوتاه برای تیم بفرستید. اگر این کار فقط «یادم باشد اسکریپت بزنم» باشد، یک تعطیلات یا استقرار فراموش‌شده کل خط پردازش را از کار می‌اندازد. اتوماسیون زمان‌بندی‌شده همان تضمین اجرای منظم است — از cron ساده تا صف توزیع‌شده. مبنا در استخراج داده از وب و دریافت از API.

خلاصه
  • محیط عملیاتی = محرک مشخص + قفل ضد هم‌پوشانی + ثبت گزارش اجرا.
  • cron برای یک job شبانه روی یک سرور اغلب کافی است.
  • چند منبع، تلاش مجدد سنگین، مقیاس → صف و پردازشگر.
  • رویداد لحظه‌ای: Webhook به‌جای poll مداوم.

دستی در برابر زمان‌بندی‌شده

اجرای دستی برای اشکال‌زدایی و اولین تست خوب است. وقتی SLA دارید («داده هر صبح ۰۸:۰۰ تازه باشد»)، باید زمان‌بند، پایش و مسیر هشدار داشته باشید.

مفهوم cron

زمان‌بندی بر اساس ساعت/روز (مثلاً 0 2 * * * = هر روز ۰۲:۰۰). ساده، بدون وابستگی زیاد. ریسک: دو instance همزمان (deploy دوبل) همان job را دو بار اجرا کند → distributed lock (فایل lock، Redis، یا advisory lock در PostgreSQL).

Celery Beat (مفهومی)

در استک Django رایج: Beat زمان را می‌زند، workerها task را از queue می‌گیرند. مزیت: retry داخلی، چند queue اولویت، scale worker روی چند ماشین. هزینه: Redis/RabbitMQ، ops بیشتر.

Event-based و webhook

به‌جای «هر ۵ دقیقه بپرس»، بعضی جریان‌ها با رویداد شروع می‌شوند: سفارش جدید → webhook → job enrich. scrape bulk هنوز معمولاً زمان‌بندی دارد.

Queue، retry و overlap

اگر job شبانه هنوز running است و ساعت ۰۲:۰۰ بعدی رسید، یا skip کنید یا در صف بگذارید — policy را explicit بنویسید. fetch باید با retry و DLQ همراه باشد؛ upsert idempotent تا overlap کم‌خطر باشد.

۰۲:۰۰ trigger→دریافت→پردازش→ذخیره→گزارش
نمونه نمایشی — فرایند شبانه

ثبت گزارش و پایش

هر اجرا: run_id، شروع/پایان، تعداد URL موفق/شکست، مدت. هشدار اگر دو شب پشت‌سرهم ناموفق باشد یا اگر مدت غیرعادی باشد (نشانهٔ گیر کردن). خروجی را به فرمت ذخیره مناسب هدایت کنید.

چه زمانی cron کافی است؟

یک یا چند scrape شبانه، یک سرور، retry ساده در خود اسکریپت، حجم متوسط. وقتی چند tenant، صدها task، SLA سخت، یا worker scale لازم است → queue/Celery (یا scheduler ابری معادل).

اشتباه رایج

cron بدون lock روی دو سرور = duplicate request به منبع و رکورد تکراری در DB.

در عمل چه انتخابی کنیم؟

MVP: cron + lock + لاگ فایل. رشد: Celery Beat + پایش + جدا کردن دریافت و یکدست‌سازی. بعد از جمع‌آوری داده خام، پاک‌سازی را همان زمان‌بند یا وظیفه بعدی اجرا کنید. سرویس: اتوماسیون و اتوماسیون گردش کار.