在 Linux 服务器上配置 Django 的 Celery Beat 定时任务最稳妥的方案是将其作为独立进程运行并通过 Systemd 进行守护同时建议使用数据库存储调度配置以便动态管理。先说结论生产环境不要将 Beat 和 Worker 混在一个进程里务必分开启动并配置进程守护。适合需要长期稳定运行、任务调度规则可能需要动态调整的生产环境。先准备确保消息队列如 Redis 或 RabbitMQ可用并安装 django-celery-beat 扩展。验收通过后台管理界面查看任务最后运行时间并检查服务器日志无报错。命令速用版如果你已经完成了基础配置以下是启动 Beat 和 Worker 的核心命令通常建议分成两个终端或进程运行# 安装依赖 pip install celery django-celery-beat # 启动 Beat 调度器负责发信号 celery -A 你的项目名 beat -l info --scheduler django_celery_beat.schedulers:DatabaseScheduler # 启动 Worker 执行器负责干活 celery -A 你的项目名 worker -l info注意实际生产环境中不要直接在命令行挂起运行请使用下文提到的 Systemd 配置并确保替换“你的项目名”为实际 Django 项目名。为什么会这样Celery 的架构设计将“调度”和“执行”分开了。Beat 的作用仅仅是按照时间表向消息队列发送任务消息它不执行具体代码Worker 才是监听队列并执行任务的进程。如果将两者混在一起运行一旦 Worker 重启或阻塞调度也会中断。此外默认的 Beat 使用本地文件存储调度状态重启后会丢失执行记录。使用django-celery-beat可以将调度规则存在数据库里不仅重启不丢失还能在 Django 后台动态增删任务无需改代码重启服务。分步处理以下是基于 Systemd 的配置流程适用于大多数现代 Linux 发行版如 Ubuntu 20.04, CentOS 7。1. 安装与基础配置在 Django 项目的settings.py中注册应用并配置 Celery 入口。INSTALLED_APPS [ ... django_celery_beat, ] # 使用数据库作为调度器 CELERY_BEAT_SCHEDULER django_celery_beat.schedulers:DatabaseScheduler执行数据库迁移创建调度所需的表python manage.py migrate2. 配置环境变量文件 (.env)Systemd 服务依赖环境变量文件来加载 Django 配置。在项目根目录创建.env文件内容如下请根据实际路径修改# Django 设置模块路径必须配置 DJANGO_SETTINGS_MODULEproj.settings # 虚拟环境路径可选如果 ExecStart 已指定绝对路径 VIRTUAL_ENV/path/to/venv # 其他项目所需环境变量 SECRET_KEYyour_secret_key DEBUGFalse3. 目录权限与安全设置确保运行服务的用户如 www-data对项目目录有读写权限避免日志写入失败或静态文件错误。# 修改目录所有者 sudo chown -R www-data:www-data /path/to/your/project # 设置目录权限 sudo chmod -R 755 /path/to/your/project # 确保日志目录可写如果有特定日志目录 sudo mkdir -p /path/to/your/project/logs sudo chown -R www-data:www-data /path/to/your/project/logs4. 创建 Systemd 服务文件在/etc/systemd/system/目录下创建两个文件分别管理 Worker 和 Beat。注意使用Typesimple且不要加--detach参数。celery-worker.service:[Unit] DescriptionCelery Worker Service Afternetwork.target [Service] Typesimple Userwww-data Groupwww-data WorkingDirectory/path/to/your/project EnvironmentFile/path/to/your/project/.env ExecStart/path/to/venv/bin/celery -A proj worker -l info Restartalways [Install] WantedBymulti-user.targetcelery-beat.service:[Unit] DescriptionCelery Beat Service Afternetwork.target [Service] Typesimple Userwww-data Groupwww-data WorkingDirectory/path/to/your/project EnvironmentFile/path/to/your/project/.env ExecStart/path/to/venv/bin/celery -A proj beat -l info --scheduler django_celery_beat.schedulers:DatabaseScheduler Restartalways [Install] WantedBymulti-user.target加载配置并启动sudo systemctl daemon-reload sudo systemctl enable celery-worker sudo systemctl enable celery-beat sudo systemctl start celery-worker sudo systemctl start celery-beat怎么验证是否生效配置完成后不要盲目相信状态显示需要通过以下三个维度确认sudo journalctl -u celery-beat -f sudo journalctl -u celery-worker -f进程状态运行systemctl status celery-beat和systemctl status celery-worker确保显示active (running)。日志检查使用 journalctl 查看实时日志确认没有ConnectionRefused或ImportError报错。业务验证登录 Django Admin 后台进入Periodic tasks创建一个测试任务观察Last run at字段是否随时间更新并检查任务对应的业务结果如数据库记录变化或邮件发送。常见坑时区问题Django 的TIME_ZONE设置会影响 Beat 的触发时间。如果服务器是 UTC 时间而数据库存的是本地时间任务可能会延迟或提前 8 小时执行。建议在settings.py中明确设置TIME_ZONE Asia/Shanghai并开启USE_TZ True。多实例冲突不要在多台服务器上同时运行同一个数据库后端的 Beat 服务除非你配置了分布式锁如基于 Redis 的锁。否则多台机器会同时触发任务导致重复执行。单实例部署可忽略此项。数据库锁如果使用 SQLite 作为调度存储高并发下可能会出现数据库锁定导致任务漏发。生产环境建议使用 MySQL 或 PostgreSQL。Worker 未启动Beat 只是发令枪如果 Worker 没启动或队列配置错误任务消息会堆积在队列里不执行。务必确认 Worker 在线。环境变量缺失如果日志报错DjangoSettingsModule相关错误请检查.env文件是否正确加载以及ExecStart中是否指定了正确的虚拟环境 Python 路径。来源 https://www.zjcp.cc/ask/10914.html