n8n 队列模式怎么部署？先拆主进程与 Worker

已经运行 n8n 单实例、工作流开始排队或执行进程互相影响的开发者，可以按下文评估迁移。
计划并行处理 AI 工作流与自动化任务的小团队，可先厘清主进程、Worker 和 Redis 的职责。
负责 Docker Compose 与服务器规划的技术负责人，可重点核对数据存储、版本一致性和回滚条件。

第一步：确认 n8n 队列模式部署是否解决真实问题

队列模式把职责拆开：主实例接收触发信息并将任务放入 Redis，Worker 从队列取任务、执行流程，再把结果写入共享数据库。它改变的是任务分发与执行方式，不会缩短单条工作流中外部接口响应慢、节点计算重或串行步骤过多造成的耗时；Webhook 请求转交 Worker 也可能增加额外延迟。

先区分三种现象，避免把不同故障都用“加 Worker”处理：

• 任务持续等待，执行记录显示排队：可能是执行容量跟不上到达速度，值得进一步评估队列模式。
• 任务已开始，但某个节点长时间无响应：先检查外部 API、数据库查询、流程步骤和节点超时。拆分 Worker 不会让这个节点自动变快。
• 执行期间 CPU、内存或磁盘持续吃紧：先查清是哪类资源被占满。增加 Worker 会增加并行执行需求，也可能让同一台主机更拥挤。

迁移评估应基于已有证据，而不是一次高峰的印象。检查 n8n 执行记录中等待、失败和运行中的任务，再对照服务器的 CPU、内存、磁盘使用趋势；n8n 官方的并发控制说明也指出，执行负载过高可能导致事件循环争用和响应变差。

单实例什么时候需要拆分？

若满足以下条件，进入队列迁移评估：等待任务在正常业务时段反复累积、执行与主界面响应相互影响，并且监控显示问题集中在可并行执行负载。否则先保留单实例，排查慢节点、外部依赖和资源瓶颈；不要仅因流程数量增加就拆分。

第二步：迁移前盘点数据、数据库与密钥

先把现有部署写成一份可复核记录，至少包括：

• 当前 n8n 镜像标签或安装版本、启动命令及 Docker Compose 文件。
• 数据库类型、数据库连接参数、n8n 数据目录和实际持久化位置。
• N8N_ENCRYPTION_KEY 的来源、保管位置，以及当前实例是否使用自动生成的密钥。
• 二进制文件的存储方式：工作流是否读写文件、是否需要在执行后保留文件，以及这些文件目前保存在哪里。
• 当前数据库、配置文件和持久化目录的备份方式，以及确认备份可恢复的人和步骤。

队列模式下，主实例与 Worker 必须连到同一套 n8n 数据库和 Redis，并使用一致的加密密钥；Worker 需要该密钥才能读取数据库中保存的凭据。官方不建议用 SQLite 运行队列模式，分布式配置也不能把 SQLite 当作共享数据库。n8n 的数据库配置文档说明，自托管默认使用 SQLite，也支持配置 PostgreSQL；迁移前应核对当前数据库与目标数据库，而不是把单机默认配置直接复制到多实例环境。

还要把 Worker 和 Task Runner 分开核对。Worker 负责取队列任务并执行工作流；Task Runner 是执行 Code 节点代码的独立组件，连接的是任务代理，不是 Redis 队列。若部署启用了 Task Runner，应查看对应的官方配置说明；不要把 Task Runner 的环境变量误当成 Worker 配置。

第三步：按职责拆分 Docker Compose 服务

部署可以先按“主实例、Worker、Redis、数据库”划分职责。主实例接收触发和管理界面；Worker 执行生产工作流；Redis 暂存待执行任务；数据库保存工作流、凭据和执行数据。Worker 和主实例应使用相同 n8n 版本、数据库配置、Redis 连接、队列模式设置和加密密钥。

下面是结构框架，不是可直接上线的完整配置。镜像标签、网络、数据库凭据、密钥与持久化路径应按目标环境填写；不要使用未固定版本的镜像，也不要把真实密钥提交到代码仓库。n8n 官方的Docker Compose 部署教程可用于核对 Compose 文件布局与持久化写法；队列相关变量则以官方环境变量说明为准。

services:
  main:
    image: ${N8N_IMAGE:?填写固定版本的 n8n 镜像}
    command: start
    environment:
      EXECUTIONS_MODE: queue
      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY:?需与 Worker 一致}
      QUEUE_BULL_REDIS_HOST: redis
      QUEUE_BULL_REDIS_PORT: ${REDIS_PORT}
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      # 数据库、Redis 密码及其他必需配置按官方变量文档补齐

  worker:
    image: ${N8N_IMAGE:?与 main 使用同一版本}
    command: worker
    environment:
      EXECUTIONS_MODE: queue
      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY:?需与 main 一致}
      QUEUE_BULL_REDIS_HOST: redis
      QUEUE_BULL_REDIS_PORT: ${REDIS_PORT}
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      # 与 main 对齐其余数据库、Redis 及实例配置

  redis:
    image: ${REDIS_IMAGE:?填写固定版本}
    # 设置网络、认证与持久化策略

  postgres:
    image: ${POSTGRES_IMAGE:?填写固定版本}
    # 设置数据库、认证、网络与持久化策略

示例故意没有填充所有环境变量：实际名称、默认值和兼容性可能随版本变化。启动前对照当前 n8n 的队列模式环境变量说明，逐项确认 Redis 主机、端口、认证、执行模式和数据库变量；密码与密钥不要为了方便写入公开的 Compose 文件。若使用 N8N_ENCRYPTION_KEY，主实例与 Worker 必须一致。

第四步：按顺序启动并验证任务流向

部署不要以“容器都显示运行中”作为验收。按下面的顺序检查，并留存日志与测试结果：

1. 先查 Redis 连通性。确认主实例和 Worker 使用相同的 Redis 地址、端口、认证与数据库编号；容器能启动，不等于应用已连上队列。
2. 检查主实例日志。确认执行模式与数据库连接符合预期，没有加密配置或数据库迁移错误。
3. 检查 Worker 日志。确认 Worker 已启动、可连接 Redis 与数据库；若启用了 Worker 健康检查，再检查存活和就绪状态。官方队列模式文档说明，健康检查可用于判断 Worker 是否运行，以及数据库和 Redis 连接是否就绪。
4. 运行一条可重复的测试工作流。让它经过触发、排队、Worker 执行和结果保存，再核对日志、执行记录与界面状态是否一致。
5. 观察失败与滞留。若任务进入队列却没有被处理，先检查 Worker 是否注册、两端的配置和版本是否一致，以及 Redis、数据库报错；不要先增加 Worker 数量。

n8n 队列模式中的 Worker 并发可以通过 --concurrency 调整；官方文档列出的默认值为 10，并提醒 Worker 数量与并发配置可能增加数据库连接池压力。不要把默认值当成所有工作流的推荐值：短任务与长时间等待外部服务的任务，对并发和资源的影响并不相同。先用少量并发执行实际流程，再根据等待情况、失败记录、CPU、内存和数据库负载逐步调整。

第五步：观察一段稳定负载后，再决定扩容或回退

部署通过测试后，继续观察实际业务负载。记录任务从进入队列到开始执行的等待变化，同时查看 Worker 的执行状态、CPU 和内存趋势，以及数据库与 Redis 是否出现持续压力。若有监控，比较改造前后同类时段；若没有，先保存执行记录、容器日志和系统资源采样，避免只凭主观感受下结论。

扩容的边界要明确：增加 Worker 适用于可并行执行且确实存在待处理任务的负载；它不会解决单个工作流中的串行耗时，也可能提高数据库连接、Redis 使用量和主机资源消耗。n8n 官方建议按实际使用场景运行自己的基准测试，而不是把示例测试结果直接当成目标环境的性能承诺。

用这组条件决定下一步

• 若等待任务反复累积，Worker 仍有资源余量，且数据库与 Redis 没有明显瓶颈：先小幅提高并发或增加 Worker，再重复相同测试。
• 若等待不多，主要是个别任务执行慢：回到工作流节点和外部依赖排查，不为“可能更快”而扩容。
• 若 CPU、内存或磁盘长期紧张，或增加 Worker 后数据库与 Redis 压力上升：先暂停扩容，重新评估整体主机资源与服务布局。
• 若二进制数据仍依赖文件系统模式，或备份无法恢复：暂不切换队列模式，先解决兼容与数据保护问题。

第六步：迁移前准备回滚，并逐项复核配置

切换前保存可恢复的数据库备份、Compose 配置和相关持久化数据，并单独保管加密密钥；同一台机器上的第二份文件不是机外备份，也不能代替异机恢复验证。对备份流程的责任划分和数据处理方式，还应与本站数据处理说明一并核对。

若验证失败，先停止新 Worker，避免它们继续领取任务；然后确认队列中是否有正在执行或等待的任务，并核对数据库状态，再决定如何恢复原单实例配置。回滚前要确认切换期间是否产生新执行记录或状态变化，不能仅凭重新启动旧容器就认定数据已一致。

发布新版本后，重新核对主实例、Worker、Task Runner 的版本与连接配置，并重复测试工作流。版本发布记录可作为变化线索；每次升级是否影响具体配置，仍要以该版本的正式说明和实际验收结果为准。

用对照表确认配置与服务器是否匹配

以下两张表把部署决策压缩成可核对项目：第一张对比保留单实例与拆分队列的适用条件；第二张把 XFP Cloud 页面列出的资源与服务职责对应起来。资源规格不是 n8n 的最低门槛，也不构成固定配置推荐；是否适合，仍要用实际负载验证。

表中规格与接入方式来自 XFP Cloud 当前产品信息；磁盘采用独立直连方式且没有硬件 RAID，冗余和备份需自行规划。购买前还应按实际租用周期核对计费方式说明。这些资源只能对应主实例、Worker、Redis 和数据库的自主管理，不代表提供代运维、数据库服务或备份服务。

如果当前部署是共享 VPS 或公有云实例，邻居争抢、CPU 资源边界不清、带宽与流量计费不易按长期负载估算，可能让持续运行的 Worker 和数据库更难规划；反过来，若工作流很轻、只是临时执行，或需要按秒弹性扩缩，独享物理机未必合适。完成队列验证并掌握真实资源曲线后，再按主实例、Worker、Redis 与数据库的实际需求，对照 XFP Cloud 的 AMD 独享服务器配置与系统选项判断是否迁移，而不是先选机器再猜负载。