Какие инструменты используются для планирования задач (шедулинга) в Python

Слушай, а вот представь себе картину: тебе надо, чтобы какой-то кусок кода на Python выполнялся не когда ты пальцем ткнешь, а сам по себе, по расписанию. Ну, типа, каждые пять минут, или каждый день в полночь, или в последний понедельник месяца. И в голове сразу бардак: а как это, блядь, сделать? Какие инструменты взять, чтобы не выстрелить себе в ногу?

Так вот, инструментов этих — овердохуища. Но все они для разных случаев, как молоток и микроскоп. Сейчас разложу по полочкам, чтобы было понятно, какой когда брать.

1. APScheduler (Advanced Python Scheduler)

Это, типа, твой встроенный планировщик-перфекционист. Хочешь, чтобы задачи крутились прямо внутри твоего приложения, не вылезая наружу? Вот он, твой выбор. Умеет хранить расписание задач, даже если приложение перезапустилось, и поддерживает кучу триггеров: интервалы, cron-выражения, конкретные даты.

Когда брать: Идеально для какого-нибудь монолитного веб-сервиса, где планировщик должен жить в том же процессе, что и всё остальное. Просто, мощно, без лишних телодвижений.

from apscheduler.schedulers.blocking import BlockingScheduler
import datetime

def my_job():
    print(f"Задача выполнена в {datetime.datetime.now()}")

scheduler = BlockingScheduler()
# Запускать каждые 10 секунд
scheduler.add_job(my_job, 'interval', seconds=10)
scheduler.start()

Вот видишь? Объявил функцию, сказал «запускай каждые 10 секунд», и всё, пиздец. Работает.

2. Celery Beat

А это уже тяжёлая артиллерия для распределённых систем. Если у тебя несколько воркеров, очередь задач через Redis или RabbitMQ, и нужно, чтобы задачи по расписанию раскидывались по этим воркерам — то это твой ёбаный стандарт. Особенно любят его в связке с Django или Flask.

Когда брать: Когда у тебя не одно приложение, а целая ферма сервисов, и задачи должны выполняться где-то там, в облаках, а не в основном процессе.

# В конфигурации Celery (celery.py)
from celery import Celery
from celery.schedules import crontab

app = Celery('tasks', broker='redis://localhost:6379/0')

@app.on_after_configure.connect
def setup_periodic_tasks(sender, **kwargs):
    # Выполнять каждый день в 7:30 утра
    sender.add_periodic_task(
        crontab(hour=7, minute=30),
        my_task.s('hello'),
    )

Тут уже посложнее, но зато масштабируется нахуй. Задачу my_task кто-нибудь из свободных воркеров подхватит и сделает.

3. Библиотека schedule

А это, блядь, для ленивых и для простых скриптов. API у неё настолько человеческое, что даже менеджер, который в программировании нихуя не шарит, поймёт, что тут написано. Хочешь задачу раз в час? schedule.every().hour.do(job). Всё.

Когда брать: Для каких-нибудь домашних скриптиков, демонов-уборщиков логов или простых автотестов. Для продакшена, где нужна надёжность и сохранение состояния — не очень, там он, как хитрая жопа, может подвести.

import schedule
import time

def job():
    print("Я работаю...")

schedule.every(10).minutes.do(job)
schedule.every().hour.do(job)
schedule.every().day.at("10:30").do(job)

while True:
    schedule.run_pending()
    time.sleep(1)

Смотри, какая красота! Прям как на английском читаешь. Но помни — этот цикл while True должен крутиться вечно. Если скрипт упадёт — всё, расписание накрылось медным тазом.

4. Старый добрый Cron (уровень ОС)

А это, сука, классика жанра. Всё, что от тебя нужно — написать Python-скрипт и прописать его в crontab. Система сама будет его запускать в указанное время. Никаких библиотек, никаких зависимостей в коде.

Когда брать: Для задач обслуживания системы. Бэкапы базы в 3 ночи? Очистка временных файлов? Отправка сводного отчета по почте? Вот тут cron — царь и бог. Надёжный, как швейцарские часы, и не зависит от того, жив твой основной процесс или нет.

5. Airflow / Prefect

А вот это уже не просто планировщик, а целые ёперные театры для оркестрации конвейеров данных. Тут задачи могут зависеть друг от друга, перезапускаться при падении, а их выполнение можно красиво мониторить в веб-интерфейсе.

Когда брать: Когда у тебя не просто «запусти функцию», а сложный ETL-пайплайн: «скачай данные из API, распарсь, положи в хранилище, потом агрегируй, потом пошли алерт, и если на втором шаге ошибка — перезапусти только его». Для простого «позвони раз в день» — это, конечно, пиздопроебибна, слишком жирно. Но для сложных бизнес-процессов — то, что надо.

Короче, выбор, блядь, есть. Всё зависит от того, что ты строишь: простой скрипт, монолитное приложение, распределённую систему или целый конвейер данных. Главное — не пытайся гвозди микроскопом забивать, а то будет муда с ушами.