n8n Queue Mode 会把主进程接收的执行交给队列，再由 Worker 处理。它能扩展执行能力，但不会自动解决慢模型、下游限流、二进制存储或数据库瓶颈。 以下是架构与验收步骤，未在你的服务器上执行；生产改造前要备份数据库和加密密钥，并核对当前 n8n 版本对数据库、Redis、二进制数据和多主节点的要求。
本篇验收要点：主进程和 Worker 使用同一数据库、Redis 配置与 N8N_ENCRYPTION_KEY，执行模式设置为 queue。 启动 Worker 后运行多条可识别任务，从 Worker 日志、执行详情和队列状态共同确认任务不是仍在主进程执行。
开始前准备
- 已备份的 n8n 数据库和固定加密密钥
- 可用的 Redis 与官方支持数据库
- 主进程和 Worker 可访问相同依赖
- 一组不会产生真实写入的并发测试工作流
按顺序搭建
- 记录当前版本、数据库、执行量和慢任务原因。若瓶颈来自模型 API 限流，增加 Worker 反而可能放大 429。
- 为主进程配置 EXECUTIONS_MODE=queue、Redis 主机与端口，并确保所有实例使用同一 N8N_ENCRYPTION_KEY 和数据库。密钥不能通过镜像或日志泄露。
- 按官方方式启动一个 n8n worker 进程。先保持较低并发，检查它能连上数据库与 Redis，且没有凭证解密错误。
- 运行 5 条带 execution_id 的测试任务，观察主进程负责接收、Worker 负责执行。再停止 Worker，确认新任务留在队列而不是伪成功。
- 逐步增加 Worker 或并发，每次记录队列等待、执行耗时、失败率和下游 429；达到瓶颈就停止扩容并定位限制。
可复制的最小示例
核心环境变量的名字和完整选项以当前官方文档为准，形状如下：
EXECUTIONS_MODE=queue
QUEUE_BULL_REDIS_HOST=redis
QUEUE_BULL_REDIS_PORT=6379
N8N_ENCRYPTION_KEY=<all processes use the same secret>
# worker process
n8n worker --concurrency=2
怎样验收结果
验证标准是 Worker 日志出现测试执行，主进程与 Worker 能读取同一凭证，停止 Worker 后任务保持待执行且恢复后只运行一次，并发增加没有突破下游限流或造成重复写入。
- 所有进程使用相同数据库和加密密钥
- Worker 停止时队列状态可见
- 恢复后同一 execution_id 只产生一次业务结果
- 监控 Redis、数据库和下游 API 的容量
常见失败与处理
- Worker 解密凭证失败：核对 N8N_ENCRYPTION_KEY 是否完全一致。
- 任务在 Worker 间找不到文件：检查二进制数据存储是否适合队列模式。
- 扩容后 429 增加：降低并发，并按提供商限流设置速率控制。
读者下一步是先在非生产环境启动一个低并发 Worker，用停止与恢复测试确认队列可恢复且没有重复业务写入。
相关问答
Queue Mode 一定需要 Redis 吗？
当前官方队列架构使用 Redis 作为消息代理，具体支持范围应以所用版本文档为准。
可以只增加 Worker 不改数据库吗？
要先核对官方支持的数据库和部署要求；多进程共享执行状态时不能把单机文件假设直接照搬。
官方资料与适用边界
Ai菜鸟网。发布者：AI小管家，转载请注明出处：https://www.alyyhw.com/32424.html
