如何将Django主应用与Celery分离部署在不同AWS EC2服务器上

核心逻辑：Celery的任务调度依赖Broker（你当前使用的Redis），只要服务器B的Celery Worker可以正常访问服务器A的Broker，就能拉取指定队列的任务执行，默认不需要和Django主应用、MySQL直接通信（如果任务本身需要读写数据库再单独开权限即可）。

1. 服务器A侧预配置 #

服务器A为原有运行主应用的EC2实例，需要调整安全规则和Celery配置：

• 调整AWS EC2安全组规则：仅开放服务器A的Redis端口（默认6379）给服务器B的私有/公网IP访问，禁止开放到公网，避免安全风险
• 修改Redis配置：注释掉bind 127.0.0.1配置项，设置protected-mode no（Docker部署的Redis可以直接在docker-compose.yml的command参数里追加这两项配置，也可以挂载自定义配置文件），同时建议给Redis设置强密码，避免未授权访问
• 调整Django项目的Celery配置，新增专门的CPU密集型任务队列，示例配置如下：

# 项目celery.py新增配置
from kombu import Queue
# 定义两个队列，普通任务留在A实例执行，CPU密集任务发到单独队列
CELERY_TASK_QUEUES = (
    Queue('default', routing_key='default'),
    Queue('cpu_intensive', routing_key='cpu_intensive'),
)
# 给指定CPU密集任务配置路由，自动发到对应队列
CELERY_TASK_ROUTES = {
    '你的应用名.tasks.任务函数名1': {'queue': 'cpu_intensive'},
    '你的应用名.tasks.任务函数名2': {'queue': 'cpu_intensive'},
}

• 重启服务器A的Django、Celery服务，让配置生效

2. 服务器B侧部署配置 #

服务器B不需要部署Nginx、MySQL、Django主服务，仅需要和服务器A版本一致的Celery运行环境：

• 提前安装好Docker环境，拉取和服务器A完全相同的项目代码镜像（Celery Worker需要加载任务函数的代码实现，代码版本必须和主应用完全一致，否则会出现任务找不到、参数不匹配的问题）
• 编写服务器B专用的docker-compose.yml，仅保留Celery Worker服务即可，示例配置：

version: '3'
services:
  celery_cpu_worker:
    image: 你的项目镜像地址 # 和服务器A使用的Django/Celery镜像完全一致
    command: celery -A 你的项目名 worker -Q cpu_intensive --loglevel=info -c 4 
    # -c参数根据服务器B的CPU核心数调整，-Q参数指定仅消费cpu_intensive队列的任务
    environment:
      - CELERY_BROKER_URL=redis://:你的Redis密码@服务器A的私有IP:6379/0 
      # 优先用私有IP通信，延迟更低、走内网流量不收费、安全性更高
      # 如果你的CPU密集任务需要读写MySQL，额外加以下配置，同时服务器A安全组要开放3306端口给服务器B的IP
      - DB_HOST=服务器A的私有IP
      - DB_USER=你的数据库用户名
      - DB_PASSWORD=你的数据库密码
    restart: always

• 执行docker compose up -d启动服务，查看Celery日志确认Worker已成功连接到服务器A的Redis Broker
• 功能验证：在服务器A的Django Shell中调用一个CPU密集型任务，查看服务器B的Celery日志是否正常接收、执行任务，同时确认任务结果可以正常写入到Result Backend（如果用Redis作为Backend则天然支持）

3. 可选优化项 #

• 后续如果CPU密集任务量上涨，可以直接新增多台和服务器B配置相同的EC2实例，全部消费cpu_intensive队列，自动实现任务负载均衡
• 可以根据队列长度配置EC2自动扩缩容规则，低峰期减少实例数量节省成本
• 如果任务不需要返回结果，可以关闭Celery的Result Backend功能，减少Redis性能开销

内容的提问来源于stack exchange，提问作者Renan Quirino