n8n: Часть 5 — Масштабирование: режим очереди, воркеры и task runners

Когда один процесс n8n перестаёт справляться с числом запусков, его масштабируют: выносят выполнение сценариев в отдельные процессы-воркеры, приём веб-хуков — в отдельные процессы, а пользовательский код — в изолированные task runners. Как включить режим очереди, описано во второй части цикла; здесь — как устроено масштабирование и как им управлять.

Сначала о «лёгких» и «тяжёлых» воркерах

В сообществе часто говорят о разделении воркеров на «лёгкие» (быстрые сценарии: веб-хуки, уведомления) и «тяжёлые» (обработка файлов, долгие запросы к ИИ). Важно понимать: именованных очередей в n8n нет. В документации нет ни переменной QUEUES, ни настройки очереди у сценария, ни переменной N8N_WORKER_CONCURRENCY. Все воркеры одной установки берут задачи из одной очереди в Redis, и выбрать, какой воркер выполнит конкретный сценарий, нельзя.

Разделить нагрузку можно другими способами — они описаны ниже.

Из чего состоит масштабированная установка

• Основной экземпляр (main) — интерфейс, API, расписания; ставит запуски в очередь.
• Redis — очередь задач.
• Воркеры — процессы n8n worker, которые забирают запуски из очереди и выполняют их.
• Webhook-процессоры — процессы n8n webhook, которые принимают входящие веб-хуки.
• PostgreSQL — общая база; с SQLite распределённая схема не поддерживается.

Все процессы должны использовать один и тот же N8N_ENCRYPTION_KEY, иначе воркеры не смогут расшифровать учётные данные. Двоичные данные в режиме очереди нельзя хранить в файловой системе — документация рекомендует внешнее хранилище S3.

Воркеры и параллелизм

Воркер запускается командой n8n worker. Число одновременных запусков на одном воркере задаёт флаг --concurrency, по умолчанию 10:

n8n worker --concurrency=5

Нагрузку масштабируют двумя рычагами: числом воркеров (горизонтально) и --concurrency каждого (вертикально). Если сценарии тяжёлые по памяти — меньше параллелизма на воркер и больше воркеров; если это в основном ожидание внешних API — параллелизм можно поднять.

Общий предохранитель — переменная N8N_CONCURRENCY_PRODUCTION_LIMIT: максимальное число одновременно выполняемых рабочих (production) запусков. По умолчанию -1 — ограничение выключено.

Ручные запуски из редактора по умолчанию выполняются на основном экземпляре. Чтобы они тоже шли на воркеры, задают OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS=true — документация рекомендует это для продакшена.

Webhook-процессоры

Если сценарии запускаются веб-хуками, приём запросов выносят в отдельные процессы:

n8n webhook

Балансировщик направляет пути /webhook/* на пул webhook-процессоров, а на основном экземпляре приём рабочих веб-хуков отключают переменной N8N_DISABLE_PRODUCTION_MAIN_PROCESS=true. Так всплеск входящих запросов не мешает работе интерфейса.

Task runners

Код из узла Code выполняется в task runners — отдельных процессах, изолированных от n8n. Каждый runner по умолчанию выполняет до 5 задач одновременно (N8N_RUNNERS_MAX_CONCURRENCY), задача останавливается через 300 секунд (N8N_RUNNERS_TASK_TIMEOUT).

Есть два режима:

• internal — runner запускается дочерним процессом n8n под тем же пользователем. С n8n 3.0 режим объявлен устаревшим: код, вырвавшийся из песочницы, получает доступ ко всему, что есть у n8n, включая сохранённые учётные данные;
• external — рядом с n8n работает отдельный контейнер n8nio/runners (версия образа должна совпадать с версией n8n), связь защищена общим секретом N8N_RUNNERS_AUTH_TOKEN.

В режиме очереди каждому воркеру нужен свой контейнер с runners. Переменная N8N_RUNNERS_ENABLED с n8n 2.0 устарела — task runners включены всегда.

Как всё-таки разделить «лёгкое» и «тяжёлое»

Поскольку очередь одна, разделение делают на уровне установок и сценариев:

1. Отдельная установка n8n для тяжёлых задач. Свой основной экземпляр, свой Redis и свои воркеры — например, для обработки документов или работы с ИИ. Лёгкие сценарии вызывают тяжёлые через веб-хук или HTTP-запрос.
2. Webhook-процессоры отдельно от воркеров. Приём запросов остаётся быстрым, даже когда воркеры заняты.
3. Параллелизм под характер нагрузки. Для установки с тяжёлыми сценариями — небольшой --concurrency и больше памяти на воркер.
4. Вынос тяжёлого кода из n8n. Долгую обработку файлов часто проще выполнить во внешнем сервисе, а n8n оставить роль дирижёра.

Минимальный набор переменных

EXECUTIONS_MODE=queue
QUEUE_BULL_REDIS_HOST=redis
DB_TYPE=postgresdb
N8N_ENCRYPTION_KEY=один-и-тот-же-ключ-на-всех-процессах
OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS=true
N8N_RUNNERS_MODE=external
N8N_RUNNERS_AUTH_TOKEN=общий-секрет

Типичные ошибки

• Разные ключи шифрования у основного экземпляра и воркеров — сценарии падают на расшифровке учётных данных.
• SQLite в режиме очереди — не поддерживается.
• Двоичные данные на диске основного экземпляра — воркеры их не видят.
• Один контейнер runners на всю установку — в режиме очереди он нужен каждому воркеру.
• Поиск настройки «очередь сценария» — её нет; разделяйте нагрузку отдельными установками.

Полезные ссылки

• n8n: включение режима очереди
• n8n: полная документация (разделы о переменных окружения и task runners)