Django 6的内置任务框架：测试后的第一印象

2025年9月28日

当我第一次听说Django 6将获得一个原生任务框架时，我承认我是持怀疑态度的。在与Celery配置搏斗多年，处理Redis/RabbitMQ设置，以及调试神秘的worker问题之后，对更简单事物的承诺感觉好得令人难以置信。但在过去一周深入研究这个新框架之后，我开始看到它在Django生态系统中的位置——以及它不适合的地方。

Django的新任务框架到底是什么？

新的任务框架，已在Django 6.0的alpha版本中发布，代表了Django处理后台工作方式的根本转变。Django首次提供了一种内置的方法来定义和排队需要在HTTP请求-响应周期之外运行的任务。

这个概念非常简单。以下是我一直在使用的基本模式：

from django.core.mail import send_mail
from django.tasks import task

@task
def email_users(emails, subject, message):
    return send_mail(subject, message, None, emails)

一旦你定义了一个任务，将其入队就非常简单：

email_users.enqueue(
    emails=["[email protected]"],
    subject="您有一条消息",
    message="您好！",
)

让我立刻震惊的是，与设置Celery相比，这感觉多么自然。无需创建单独的Celery应用程序、配置代理或管理复杂的序列化设置。它只是工作——好吧，算是吧。

注意：您仍然需要worker

这里的事情变得有趣（并且可能让一些人失望）。Django的任务框架处理任务的创建和排队，但它故意不提供worker机制。这意味着你仍然需要外部基础设施来实际执行你的任务。

此版本中包含的两个内置后端主要用于开发和测试。在生产环境中，你需要实现你自己的worker解决方案或与现有的任务处理系统集成。当你考虑到这一点时，这个设计决策是有意义的——Django仍然专注于成为一个web框架，而不是试图解决每个基础设施问题。

将其与Celery进行比较：苹果和橙子？

每个人都在问的问题是，这是否可以取代Celery。在广泛测试两者之后，我认为答案比简单的“是”或“否”更为细致。

对于复杂的分布式任务处理，Celery仍然是重量级冠军。它提供以下功能：

多个代理后端（Redis，RabbitMQ等）
复杂的路由和优先级系统
具有指数退避的内置重试机制
任务链和工作流
综合监控工具

另一方面，Django的任务框架感觉更像是一个基础，而不是一个完整的解决方案。它非常适合于更简单的用例，在这些用例中，你希望卸载基本工作，如发送电子邮件或处理上传，而无需完整的Celery设置的开销。

“对于像CMS或电子商务系统这样的复杂应用程序，Celery仍然是后台任务的完美选择。也许配置比简单的替代方案更复杂，但你的项目将来会变得更加强大。”

最近的一项比较中的这句话与我的经验产生了共鸣。对于我的个人项目和较小的客户工作，Django的任务框架正成为我的首选。但是对于具有大量处理需求的企业应用程序？Celery不会消失。

我的测试设置和初步发现

我一直在用一些常见的场景测试这个框架：

电子邮件通知

上面的电子邮件示例在我的开发环境中一直运行良好。立即后端同步处理任务，这非常适合测试。

数据处理

我创建了用于CSV处理和报告生成的任务。装饰器语法使转换现有函数变得容易：

@task
def process_user_data(user_id):
    # Heavy processing logic here
    pass

计划维护

虽然Django的框架不包括像Celery Beat这样的调度，但我一直在尝试使用cron作业在特定时间间隔对任务进行排队。

配置和后端选项

配置通过Django设置文件中的TASKS设置进行。该框架被设计为可扩展的，所以我希望我们很快会看到社区开发的Redis，数据库队列和云服务（如AWS SQS）的后端。

我所欣赏的是灵活性——你不会被锁定在特定的基础设施选择中。这与Django的理念非常吻合，即提供合理的默认值，同时允许自定义。

给Django开发人员的实用建议

经过一周的实验，这是我的建议：

何时使用Django任务

简单的电子邮件发送和通知
基本文件处理和上传
轻量级数据转换
开发和测试环境
你想避免额外基础设施的项目

何时坚持使用Celery

大量任务处理
复杂的工作流程和任务依赖关系
需要任务监控和管理UI
跨多个服务器的分布式处理
需要保证交付的关键后台作业

迁移策略

如果你目前正在使用Celery并考虑切换，我建议从小处开始。确定你最简单的后台任务并首先迁移它们。在评估Django的框架是否满足你的需求时，保持Celery用于复杂的工作流程。

展望未来

在Django 6中引入原生任务框架感觉像是一个自然的演变。它填补了开发人员的空白，他们需要基本的后台处理而无需完整的任务队列系统的复杂性。虽然它不会取代Celery用于复杂用例，但它是一个受欢迎的补充，将简化许多Django项目。

我特别兴奋地看到社区在这个基础上构建什么。可扩展的后端系统意味着我们可能会看到创新的解决方案，弥合Django的简单性和Celery的强大功能之间的差距。

目前，我喜欢将后台任务添加到我的Django项目中的简单性，而没有通常的配置麻烦。有时，少即是多。