Пришел убийца Celery для Django

На протяжении почти 20 лет разработчики Django обходили одну очевидную проблему: отсутствует родной способ выполнения фоновых процессов. Отправка электронных писем, обработка загрузок, анализ отчетов или вызов сторонних API зависели от сторонних инструментов, и Celery стал де-факто стандартом уже в конце 2000-х.

Этот неофициальный стандарт имел свою цену. Командам приходилось добавлять отдельный брокер, пул работников и стек мониторинга лишь для того, чтобы избежать блокировки единого HTTP-запроса, даже для тривиальных задач, таких как «отправить приветственное письмо» или «пересчитать счетчик».

Сообщество сигнализировало о этой проблеме более десяти лет через тикеты, блоги и конференции. То, что на самом деле хотели люди, звучало просто: стандартизированный встроенный API для асинхронной работы, который не навязывал бы Redis, RabbitMQ или конкретную реализацию воркера каждому проекту.

Вместо этого экосистема раскололась. Некоторые команды полностью перешли на Celery, другие выбрали Huey, RQ или собственные созданные очереди. Замена одной на другую означала инвазивные переписывания, потому что каждая библиотека поставляла свои собственные декораторы, объекты результата и семантику повторных попыток, встроенные непосредственно в код приложения.

Это давление в конечном итоге оформилось в официальное предложение по улучшению Django от ключевого разработчика Джейка Ховарда. Его предложение о Django Tasks Framework предполагает минимальный, подключаемый фреймворк задач Django, который будет находиться в ядре, определит публичное API и позволит бэкендам конкурировать в деталях реализации.

Дизайн Ховарда провел четкую грань: Django будет определять, как вы объявляете и ставите задачи в очередь, в то время как сторонние бекенды будут отвечать за хранение, рабочие процессы и масштабирование. Это разделение напоминает то, как Django обрабатывает базы данных или кэши, и оно сразу же нашло отклик у поддерживающих, уставших связывать бизнес-логику с одной библиотекой очередей.

Django 6.0, выпущенный в декабре 2025 года после альфа-версии в сентябре, бета-версии в октябре и RC1 в ноябре, становится реальностью для этой инициативы. Новая задача по модулям поставляется в составе фреймворка, а не как дополнение, и каждый новый проект теперь имеет первоклассную историю фоновых задач с первого дня.

С архитектурной точки зрения это знаменует собой поворотный момент в развитии асинхронных представлений Django или фреймворка миграций. Фоновая работа больше не является "внешней системой, которую вы приклеиваете позже", а становится основной возможностью, на базе которой могут строиться другие функции, сторонние приложения и будущие DEP.

Новая Django Tasks Framework в Django 6.0 четко выделяет определение задач и их выполнение. Основной Django теперь стандартизирует способ объявления задачи и добавления ее в очередь, но отказывается диктовать, что запускает эту очередь, как выглядят работники или где хранятся задачи. Эта разделенность превращает задачи в подключаемый API-слой, а не в монолитного фоновую работу, встроенную в ORM или стек запросов.

В центре системы находится декоратор @task. Вы просто добавляете его к обычной функции, и Django регистрирует ее как задачу с метаданными, такими как имя очереди, приоритет и необходимость использования контекста задачи. Задачи должны находиться на уровне модуля, принимать аргументы, которые можно сериализовать в JSON, и возвращать значения. Кроме того, они могут выбрать параметр `takes_context=True`, чтобы получать объект контекста, предоставляющий информацию о количестве попыток и ID `TaskResult`.

Как только функция становится задачей, вы передаете работу фрейму с помощью `enqueue()`. Из синхронного кода вы вызываете `enqueue(my_task, *args, **kwargs)`; из асинхронного кода бэкенды могут предоставить `aenqueue()` для того же API, только с использованием await. Внутренне Django передает этот вызов настроенному бэкенду, который решает, означает ли это отправку сообщения в Redis, запись в Postgres или выполнение чего-то совершенно индивидуального.

Каждый вызов `enqueue()` возвращает объект TaskResult, который является единой абстракцией Django по поводу “что happened с моей задачей.” Этот объект содержит уникальный идентификатор, который вы можете сохранить в своей базе данных или отправить обратно клиенту, а затем позже загрузить с помощью чего-то вроде `get_result(id)`, чтобы проверить такие поля, как статус, детали ошибки, попытки и возвращаемое значение. Пользователи фреймворка никогда не взаимодействуют напрямую с внутренними компонентами бэкенда; они общаются с TaskResult и позволяют бэкенду сопоставлять это с его собственным хранилищем.

Преднамеренная неполнота определяет этот дизайн. Django не поставляет производственный рабочий процесс, движок повторных попыток, планировщик в стиле cron и API цепочек; все это принадлежит бэкендам или сторонним библиотекам. Ядро лишь обещает, что `@task`, `enqueue()` и `TaskResult` останутся стабильными, чтобы экосистема могла строить рабочих, информационные панели и мосты к Celery, RQ или Redis на их основе.

Начальные бэкенды намеренно минималистичны. Бэкенд `immediate` выполняет задачи синхронно сразу после вызова `enqueue()`, что делает юнит-тесты и локальную отладку простыми, поскольку трассировки стека и точки остановки ведут себя так же, как обычные вызовы функций. Бэкенд `dummy` отбрасывает каждую задачу, не выполняя ничего, что идеально подходит для сред, где необходимо сохранить вызовы задач без фактического выполнения, например, в определенных тестовых или режимах «сухой прогона».

Фоновые задачи в Django в основном сводятся к одним и тем же трём делам: отправка электронных писем, обработка загрузок пользователей и взаимодействие с внешними API. Этот «80% случай использования» редко требует сложных рабочих процессов, распределённой маршрутизации или лимитирования по очередям. Ему просто нужно прекратить блокировку потока запросов, пока просыпается SMTP-сервер, ведро S3 или платежный провайдер.

Django Tasks Framework нацелен на эту аудиторию напрямую. Вы декорируете функцию с помощью @task, вызываете `enqueue()` (или `aenqueue()`), и передаете работу, такую как «отправить это письмо для сброса пароля» или «сгенерировать эскизы для этого изображения». Для многих приложений этот один шаблон охватывает сброс пароля, последовательности адаптации, отправку вебхуков, генерацию PDF и прогрев кэша.

Исторически команды использовали Celery для этих задач и в конечном итоге развертывали полный стек очередей для нескольких функций. У вас был брокер, бекенд результатов, пул рабочих, планировщик beat и лес настроек, прежде чем ваше первое сообщение покинуло здание. Django Tasks Framework убирает эту необходимость для простых случаев, стандартизируя API, оставаясь при этом нейтральным к тяжелой механике, стоящей за этим.

Думайте об этом как о входномRamp: вы выбираете один способ объявлять и добавлять задачи в очередь задолго до того, как примете решение о RabbitMQ, Redis или ферме рабочих на уровне Kubernetes. Проекты на ранних стадиях могут начать с немедленного бэкенда, а затем заменить его на рабочий процесс с реальной очередью, когда трафик и задержка это потребуют. Никакой массовой рефакторинга, никакого удаления специфичных для Celery декораторов по всему кодовой базе.

Собственные бэкенды Django остаются намеренно минималистичными: это непосредственный бэкенд, который выполняет задачи в потоке, и фиктивный бэкенд, который никогда не выполняется. Это позволяет снизить количество зависимостей, сохранить ощущение нативности Django и избежать подключения дополнительных демонов для CRUD-приложений или внутренних инструментов. Для получения подробной информации о бэкендах, контексте и обработке результатов, обратитесь к документации по фреймворку задач Django 6.0, где изложены условия, к которым подключаются сторонние рабочие процессы.

Фоновая работа в Django 6.0 начинается с обычной функции на Python, обернутой в новый декоратор @task. Минимальный пример выглядит так:

```python из django.tasks импортировать task, enqueue, aenqueue, get_result ```

@task( priority=5, queue_name="notifications", takes_context=True, ) def notify_user(task_context, user_id, message): """ Отправить уведомление пользователю.

# Получите метаданные об этой конкретной попытке выполнения = task_context.attempt # 1 при первой попытке, увеличивается при повторных попытках result_id = task_context.task_result_id # стабильный ID для отслеживания

# Ваша реальная логика здесь (электронная почта, пуш-уведомления, SMS и т.д.) # Вы можете записать попытку/result_id для наблюдаемости return {"status": "отправлено", "попытка": попытка, "result_id": result_id}

Эти аргументы декоратора являются основными настройками, которые предоставляет Django. priority — это числовая подсказка для бэкенда; более высокие числа означают «выполнить раньше» по сравнению с другими задачами в той же очереди. queue_name направляет работу в конкретную очередь, такую как `"notifications"` или `"image-processing"`, в то время как `takes_context=True` внедряет объект task_context в качестве первого параметра.

`task_context` превращает функцию, которую можно проигнорировать, во что-то, что вы действительно можете наблюдать. `task_context.attempt` демонстрирует, сколько раз эта задача была выполнена до текущего момента, что становится критически важным, когда ваш бэкенд добавляет повторные попытки. `task_context.task_result_id` предоставляет вам стабильный идентификатор, который вы можете сохранить в своей базе данных, журналах или аналитике, чтобы вы смогли восстановить связь с этим выполнением позже.

Добавление задач в очередь использует вспомогательную функцию enqueue() для синхронного кода. Из представления или обработчика сигнала вы можете сделать:

```python def create_order(request): # ... создать заказ, зафиксировать транзакцию ... result = enqueue( notify_user, user_id=request.user.id, message="Ваш заказ в пути!", ) # result.id == task_result_id return JsonResponse({"task_id": result.id}) ```

Асинхронный код использует `aenqueue()`, что отражает асинхронные представления и потребители Django:

```python async def async_view(request): result = await aenqueue(notify_user, user_id=1, message="Привет") return JsonResponse({"task_id": result.id}) ```

Получив `task_result_id`, статус проверки выполняются через `get_result()`:

```python from django.http import JsonResponse from django.views.decorators.http import require_GET ```

@require_GET def task_status(request, task_id): result = get_result(task_id) return JsonResponse( { "id": result.id, "status": result.status, # например, "в ожидании", "в процессе", "завершено", "не удалось" "attempts": result.attempts, # всего попыток на данный момент "value": result.value, # значение, возвращаемое notify_user, если завершено "error": result.error, # информация об ошибках специфичная для бэкенда, если не удалось } )

Эта тройка — `@task`, `enqueue()`/`aenqueue()` и `get_result()` — составляет минимально необходимые стандартизированные элементы, которые должен соблюдать каждый бэкэнд фреймворка задач Django.

Нет здесь никаких неожиданных поворотов: Django 6.0 не поставляется с встроенным воркером. Вы можете определять и добавлять задачи с помощью Django Tasks Framework, но в производственных настройках по-прежнему нужен отдельный долгосрочный процесс для извлечения заданий из бэкенда и их выполнения. Официальная документация и первоначальные обсуждения настойчиво подчеркивают это: "воркер задач Django" или его эквивалент обязательно требуется, как только вы покинете окружение разработки.

Основной API Django также упускает из виду удобства, которые пользователи Celery принимают как должное. Нет официальной поддержки автоматических повторных попыток, когда провайдер электронной почты не отвечает, нет встроенных расписаний в стиле cron, а также нет родных цепочек или групп задач. Если вам нужно "запускать это каждые 5 минут" или "начинать задачу C только после успешного выполнения A и B", вы не найдете этой логики в django.tasks.

Эти функции полностью зависят от того, какой бэкенд вы подключаете. Рабочий процесс на основе Redis, мост RQ или будущий адаптер Celery могут определить, как реализовать повторные попытки, стратегии отката, периодические задания и пайплайны с развилками/сбором. Django только обещает стабильный интерфейс: `@task`, вызовы добавления в очередь и абстракцию TaskResult, которую могут расширять бэкенды.

Дизайнеры фреймворка Django Tasks с первого дня сделали это ограничение явным. Основной Django поставляется только с немедленным бэкендом (выполняет задачи встраиваемо) и мнимым бэкендом (никогда их не выполняет), оба из которых намеренно не предназначены для продакшна. Всё, что действительно сохраняет задания, координирует рабочие процессы или управляет распределённым выполнением, поступает из сторонних пакетов.

Это разделение создает четкую линию ответственности. Django управляет интерфейсом: как вы объявляете задачи, как передаете аргументы, как проверяете результаты. Сообщество отвечает за реализацию: как задачи сериализуются, где они ставятся в очередь, как рабочие процессы масштабируются по контейнерам или регионам.

Для команд, привыкших к Celery, это ощущается почти как «металл без покрытия». Вы получаете стандартизированную, одобренную фреймворком точку входа, но теряете встроенный планировщик, инспектор и управление повторными попытками, пока ваш выбранный бэкенд не восстановит их. Ранние эксперименты уже нацелены на Redis, RQ и даже сам Celery как на бэкенды, которые поддерживают API Django Tasks Framework.

В долгосрочной перспективе это отражает существующую модель Django: ORM, кеш и почтовые службы определяют контракты, в то время как серверы Postgres, Redis и SMTP выполняют основную работу. Задачи теперь также добавляются в этот список, намеренно, неполный.

Celery построил своё королевство на одном обещании: фоновые задачи промышленного уровня для Django задолго до того, как Django начал этим заниматься. Теперь в Django 6.0 появляется Django Tasks Framework, который интегрирует объявления задач в ядро, и внезапно Celery больше не является стандартным решением, а лишь крупнейшим игроком на поле.

Рядом модели выглядят очень по-разному. Django Tasks определяет стандартный API: `@task`, функции очереди и объекты `TaskResult`, в то время как поручает хранение и выполнение подключаемым бэкендам. Celery предлагает полный стек: брокер, рабочие процессы, планировщики, хранилища результатов и десятилетие инструментов экосистемы.

Быстрое сравнение позволяет сразу увидеть разницу:

• 1Задачи Django: часть Django, минимальная конфигурация, только JSON-данные, бэкенды необходимы для реальных очередь.
• 2Celery: отдельный пакет, требует брокера, такого как Redis или RabbitMQ, поддерживает сложную сериализацию, включает в себя воркеры и планировщик beat.
• 3Задачи Django: отлично подходят для отправки электронной почты, загрузок, API-вызовов и хуков при коммите
• 4Селери: настроен для распределённых кластеров, высокой пропускной способности и многосервисных архитектур

Celery по-прежнему преобладает там, где важны масштаб и сложность. У вас есть встроенные повторные попытки с экспоненциальным увеличением времени ожидания, периодические задачи через beat и примитивы рабочих процессов, такие как цепочки, группы и аккорды, которые организуют десятки задач между многими рабочими. В крупных развертываниях регулярно обрабатываются тысячи задач в секунду через Celery, поддерживаемый Redis или RabbitMQ.

Django Tasks акцентирует внимание на эргономике. Вы остаетесь внутри Django, импортируете из `django.tasks`, декорируете функцию и вызываете `enqueue()`, не взаимодействуя с брокером напрямую. Для приблизительно "80% случаев использования" — транзакционных email-рассылок, генерации миниатюр, прогрева кэша, фан-аутов вебхуков — это ощущение нулевой зависимости внутри Django устраняет значительное препятствие для принятия.

Пользователи, которые откажутся от Celery сегодня, потеряют некоторые удобные функции. В Django 6.0 нет официального рабочего процесса, нет нативной политики повторных попыток, встроенного планирования и проверенного временем интерфейса мониторинга. Эти компоненты находятся в сторонних бэкендах и панелях управления, которые всё ещё отстают от долгосрочно развитой экосистемы Celery.

Стратегически, Django Tasks меняет стандартный вопрос, который задают команды. Новые проекты будут начинаться с основного фреймворка и только обращаться к Celery, когда требования явно требуют распределенных рабочих процессов, сложной маршрутизации или строгих SLA. Celery становится маршрутом для эскалации, а не отправной точкой.

Так убивает ли Django 6.0 Celery? Нет — он сужает территорию Celery. Фоновые задачи теперь по умолчанию принадлежат Django, в то время как Celery защищает высококлассный сегмент с многоузловыми решениями и принципом "никогда не терять задачу". Более подробные технические детали содержатся в Примечаниях к версии Django 6.0, где подробно описано, как новая Система Задач Django интегрируется с реальными бэкендами.

Celery по-прежнему выигрывает всякий раз, когда ваша фоновая работа перестает выглядеть как побочная задача и начинает напоминать собственную распределенную систему. Когда вам нужно сотни рабочих, несколько очередей, разбросанных по регионам, и предсказуемое поведение при всплесках в 10,000+ задач в секунду, десятилетний опыт Celery имеет гораздо большее значение, чем новая блестящесть Django.

Используйте Celery, когда вам нужна сложная маршрутизация вместо принципа «послал и забыл». Это означает такие функции, как: - Несколько очередей для каждого сервиса с детализированными ключами маршрутизации - Ограничение частоты выполнения и предельное количество параллельных задач для каждой задачи - Жесткие и мягкие временные лимиты, а также автоматическое поведение защиты от перегрузки

Серьезные рабочие процессы по-прежнему полагаются на поддержку AMQP и гибкость брокеров от Celery. Если ваша архитектура уже работает на RabbitMQ, Redis или даже на более экзотических брокерах, вы получаете надежные очереди, подтверждения сообщений, обмены для неудачных сообщений и семантику давления, которую Фреймворк задач Django намеренно не определяет.

Сложные пайплайны также возвращают вас к Celery. Хорды, группы, цепочки и холсты позволяют вам организовывать задачи с рассеиванием/сбором, многоэтапные ETL-пайплайны и долгосрочные рабочие нагрузки в области Data Science, которые могут охватывать десятки задач и машин. API задач Django может ставить работу в очередь, но не моделирует такой график рабочего процесса.

Мониторинг — это еще одна граница. Команды, работающие с Flower, панелями Prometheus и пользовательскими досками Grafana, построенными на потоке событий Celery, не примут «проверьте TaskResult» в качестве альтернативы. Celery предоставляет метрики для каждого рабочего процесса, глубины очереди, штормы повторных попыток и гистограммы задержки задач, которые SRE используют для поддержания SLA в рабочем состоянии.

Платформы SaaS с высокой нагрузкой, финансовые бэкенды и маркетплейсы, обрабатывающие миллионы заданий в день, по-прежнему рассматривают Celery как основную инфраструктуру. Для этого уровня проверенная семантика повторных попыток Celery, бэкенды для результатов и инструменты для операций остаются бесконечно превосходящими молодую, подключаемую прослойку Django.

Шоковые волны прокатились по миру Django почти сразу после слияния Django Tasks Framework. В течение нескольких дней после выхода кандидатов на версию 6.0 в сообществе стали появляться репозитории с "экспериментальными" бэкендами Redis, движками задач и интеграциями для администрирования, пытающимися превратить голый API в нечто, что можно действительно отправить в продакшн.

Ранние последователи нацелились на очевидный пробел: работника, готового к производству, который говорит на новом интерфейсе. Появились пакеты, которые оборачивают списки или потоки Redis, создают команду управления `worker` и сопоставляют `priority` и `queue_name` из `@task` непосредственно с структурами данных Redis, эффективно воссоздавая легковесный RQ-стиле раннер за Django Tasks Framework.

Redis быстро стал стандартной игровой площадкой. Одна семья адаптеров сосредоточена на простых настройках — единственный экземпляр Redis, FIFO-очереди, без шардинга — оптимизированных для того "80% случая" с电子почтой, обработкой изображений и вызовами вебхуков. Другой поток экспериментов включает более продвинутые функции, такие как отложенные задания, повторные попытки с нарастающей задержкой и лимиты по скорости для каждой очереди, все это доступно через простые аргументы декоратора.

Пакеты Bridge теперь нацелены на соединение существующих экосистем, а не на их замену. Вы уже можете найти прототипы, которые позволяют вам повторно использовать URL брокеров в стиле Celery, при этом маршрутизируя все определения задач через `@task`, так что ваш код выглядит нативным, но ваша инфраструктура по-прежнему опирается на защищенные работники и инструменты мониторинга Celery.

Наиболее амбициозными являются ранние эскизы "Celery backend", который позволит Celery выступать в качестве рабочего процесса за стандартным API задач Django. Идея заключается в том, что задачи остаются нативными для фреймворка, но адаптер бэкэнда переводит вызовы `enqueue()` в задачи Celery, сопоставляет идентификаторы результатов и проксирует проверки статуса, чтобы вы могли мигрировать постепенно, а не переписывать годы кода задач.

Обсуждения на почтовом списке Django, в GitHub issues и в Twitter сосредоточены вокруг трех отсутствующих аспектов: наблюдаемости, хуков жизненного цикла и усовершенствованного пользовательского интерфейса администрирования. Люди хотят структурированные события для "задача начата / повторена / завершилась неудачей", подключаемые мониторинговые бэкенды, которые могут передавать эти события в инструменты, такие как Better Stack, и первоклассные панели мониторинга, которые показывают очереди, воркеры и горячие пути прямо внутри админки Django.

Если тренд сохранится, ожидайте дарвиновскую экосистему в следующие 6–12 месяцев: полдюжины рабочих Redis, как минимум один мост Celery и несколько "все-включено" дистрибутивов, которые будут бороться за статус де-факто стандарта для задач Django 6.0.

JSON используется в первую очередь. Задачи Django сериализуют аргументы и возвращаемые значения с помощью JSON, что означает, что все, что вы передаете в задачу, должно быть совместимо с JSON: строки, числа, булевы значения, списки, словари. Если вы передадите `datetime`, `Decimal` или экземпляр модели, вы получите ошибки сериализации или тихую потерю данных, как только бэкенды начнут применять строгую типизацию.

Вы можете обойти это, но вам нужно быть предельно ясным. Преобразуйте сложные объекты в примитивные представления (идентификаторы, строки ISO 8601, обычные словари) и восстанавливайте их внутри задачи. Хорошее правило: если объект не может пройти через цикл `json.dumps()` / `json.loads()`, не отправляйте его в качестве аргумента задачи или возвращаемого значения.

Записи в базе данных вводят еще одну острую грань. Если вы ставите задачу в очередь во время представления, которое выполняется внутри `transaction.atomic()`, задача может выполниться до завершения транзакции, увидеть устаревшие данные или завершиться с ошибкой из-за отсутствующих строк. Хук Django on_commit существует именно для того, чтобы избежать этой гонки.

Шаблон для запоминания: сначала выполните запись, затем запланируйте задачу из `on_commit`. Например, после создания `Заказа` используйте `transaction.on_commit(lambda: send_order_email.enqueue(order_id=order.id))`, чтобы работник видел только зафиксированное состояние. Пропуск этого шага создаст хейзенбаги, которые проявляются только под нагрузкой или при медленных базах данных.

Рабочие процессы по-прежнему находятся вне вашего основного процесса. Вам необходимо запустить специализированный рабочий процесс (или несколько) под управлением таких систем, как systemd, Supervisor или Kubernetes Jobs. Это предполагает наличие дополнительных манифестов развертывания, проверок состояния, ведения журналов и политик перезапуска, точно так же, как вы уже делаете это для Celery.

Операционно этот новый стек уменьшает зависимости, но не обязанности. Вам все еще нужно учитывать лимиты параллелизма, обратное давление очереди и корректное завершение работы, чтобы задачи могли завершиться до остановки процессов. Для многих команд это новый оперативный уровень, а не бесплатная функция.

Мониторинг земель в категории «нужна небольшая сборка». Celery имеет Flower, экспортеры Prometheus и годы накопленных панелей инструментов; Django Tasks не предоставляет ничего из этого. Ранние бекенды показывают базовый статус через `TaskResult`, но вы, вероятно, сначала настроите пользовательские административные представления, журналы или интеграцию с APM.

Исследование исходного кода поможет. Исходный код Django Tasks Framework демонстрирует, как именно текут результаты, статусы и ошибки, на что вы будете опираться, ожидая более продвинутые сторонние интерфейсы и метрики.

Существующие проекты Django должны рассматривать Django Tasks Framework как поэтапное обновление, а не как миграцию в один день. Если вы уже используете Celery, RQ или Huey в производственной среде и они работают, продолжайте использовать их для критически важных процессов и внедряйте Django Tasks только для новых, малорисковых потоков. Полные переписывания сложных настроек Celery редко оправдывают себя в первой версии нового API.

Новые проекты, начинающиеся на Django 6.0, могут с уверенностью использовать Django Tasks для выполнения "80%": отправки электронной почты, генерации миниатюр, прогревания кэша и простых вызовов API сторонних сервисов. Обращайтесь к Celery только тогда, когда вам действительно нужны кросс-сервисные рабочие процессы, запланированные задания в больших объемах или тысячи задач в секунду через несколько очередей.

Команды, застрявшие на Django 5, могут экспериментировать уже сегодня, используя официальный backport. Установите пакет backport, подключите его в `INSTALLED_APPS` и настройте немедленный или фиктивный бекенд, чтобы избежать необходимости настраивать Redis или RabbitMQ в первый же день. Вы получите тот же декоратор `@task` и API `enqueue()`, как в Django 6.0, без необходимости глобального обновления фреймворка.

Безопасные эксперименты означают выбор несущественной функции и переключение её на задачи Django за счёт флага функции. Идеальные кандидаты включают:

• 1Электронные письма для сброса пароля или подтверждения регистрации
• 2"Спасибо за регистрацию" или "мы получили ваш заказ" уведомления
• 3Небольшие вебхуки для аналитики или сервисов логирования

Начните с переноса одного письма для сброса пароля в фоновую задачу, которая использует `on_commit()`, чтобы добавить в очередь после сохранения модели пользователя. Используйте немедленный бэкэнд в разработке, затем переключитесь на простой бэкэнд Redis и один рабочий процесс на этапе тестирования. Измерьте задержку запросов и частоту сбоев задач, прежде чем прикасаться к чему-либо связанному с доходами.

Рассматривайте сериализацию только в формате JSON как двигатель изменений, а не как ограничение: переработайте аргументы задач, сводя их к идентификаторам и примитивам, вместо того чтобы передавать полные экземпляры моделей. Такая дисциплина упрощает переключение между Celery, Redis и любым будущим адаптером Django Tasks Framework.

Стратегически Django Tasks обозначает точку зрелости для Django как полноценного веб-фреймворка. Фоновая работа теперь использует общий, основной API, что снижает количество зависимостей и делает Django более конкурентоспособным и самодостаточным для большинства веб-приложений, которым не требуется оркестрация на уровне промышленного масштаба с помощью Celery.

Что такое новый фреймворк задач Django?

Это встроенный API в Django 6.0 для определения и постановки в очередь фоновых задач. Он стандартизирует процесс создания задач, но требует отдельного бэкенда и рабочего процесса для выполнения.

Django 6.0 полностью заменяет Celery?

Нет. Этот фреймворк предназначен для более простых, распространённых случаев использования (решение на 80%) таких, как отправка электронных писем. Для сложных распределенных рабочих процессов с встроенными повторными попытками и цепочками Celery по-прежнему остается более мощным инструментом.

Включает ли фреймворк задач Django рабочего процесса?

Нет, это не так. Это сделано намеренно, чтобы сохранить ядро Django облегченным. Вам нужно настроить сторонний бэкэнд и запустить отдельный процесс рабочего, чтобы выполнять задачи.

Могу ли я использовать новый API задач с более старыми версиями Django?

Да, библиотека backport позволяет вам использовать новый API задач с Django 5, что упрощает эксперименты и подготовку к миграции на Django 6.0.