Redis для n8n queue mode: очередь без потерянных executions ¶

Обновлено: 2026-05-30

Redis в n8n нужен не “для ускорения всего сайта”, а для queue mode: main process кладёт executions в очередь, а workers забирают задачи и выполняют workflow. Поэтому Redis надо проверять как инфраструктурный компонент выполнения, а не как обычный cache.

Роль Redis в queue mode ¶

В обычном режиме n8n принимает событие и выполняет workflow в том же процессе. В queue mode архитектура меняется: main process обслуживает UI, webhooks и постановку задач, Redis хранит очередь, а отдельные workers выполняют jobs. Это помогает распределять нагрузку, но добавляет новую точку отказа и новые ENV-переменные.

Если Redis недоступен, queue mode не превращается автоматически в стабильный single-process режим. Jobs могут не ставиться в очередь, workers не будут получать задачи, а администратор увидит рост queued или failed executions. Поэтому перед включением queue mode нужно отдельно проверить Redis-связность из каждого контейнера.

Минимальная схема компонентов ¶

ENV для Redis и workers ¶

Для queue mode недостаточно добавить Redis-контейнер в compose. Нужно явно включить режим очереди и передать Redis-настройки всем n8n-процессам. Если worker видит другой Redis host, другой password или другую базу, он не будет обрабатывать jobs, которые создал main process.

EXECUTIONS_MODE=queue
QUEUE_BULL_REDIS_HOST=redis
QUEUE_BULL_REDIS_PORT=6379
QUEUE_BULL_REDIS_DB=0
# если включена авторизация Redis
QUEUE_BULL_REDIS_PASSWORD=stored-in-secret-manager

Не используйте `localhost` внутри Docker Compose, если Redis запущен как отдельный сервис. Для контейнера localhost — это сам контейнер, а не соседний сервис. Чаще всего connection refused возникает именно из-за неправильного host, закрытого network, неверного password или запуска worker до готовности Redis.

Smoke-test очереди ¶

1. Проверьте сетевой доступ. Из main и worker контейнеров убедитесь, что Redis host и порт доступны.
2. Запустите короткий manual workflow. Он должен появиться в executions и завершиться worker-процессом.
3. Создайте webhook test. Внешнее событие должно попасть в очередь и завершиться без ручного запуска.
4. Остановите один worker. Проверьте, что jobs не теряются и обрабатываются другим worker или остаются в очереди до восстановления.
5. Посмотрите логи Redis и n8n. Не должно быть повторяющихся connection refused, max retries или stalled jobs.

Monitoring Redis для n8n ¶

Следите за количеством queued jobs, failed executions, временем ожидания задачи, памятью Redis, reconnect-ошибками и состоянием workers. Важен не только сам Redis process, но и связь между компонентами. Redis может быть “up”, но n8n всё равно не сможет использовать очередь из-за auth, network или несовпадающих ENV.

Типичные ошибки Redis n8n ¶

• включить EXECUTIONS_MODE=queue на main, но запустить workers без тех же ENV;
• использовать Redis как cache и не понимать, что в n8n он отвечает за jobs;
• масштабировать workers, не проверив Postgres bottleneck и внешние API rate limits;
• очищать Redis вручную во время production-нагрузки и терять ожидающие задачи;
• не настроить alerts на stalled jobs и рост failed executions.

Перезапуск Redis, смена password, обновление образа или очистка данных должны выполняться в maintenance window. Перед изменением остановите webhook-источники или убедитесь, что они умеют повторять события. После изменения проверьте main process, worker process, выполнение новой job и обработку старой очереди. Только после этого можно считать queue mode рабочим.

Change window для Redis ¶

При инциденте сначала определите, теряются ли события или только задерживаются. Потеря очереди требует одного runbook, медленная обработка — другого. Для задержек обычно безопаснее уменьшить входной поток, добавить worker или ограничить тяжёлые workflows. Для риска потери событий нужно проверить persistence, retry источника и идемпотентность downstream-действий.

Для queue mode важно следить не только за тем, что Redis отвечает на ping. Полезные сигналы: длина очереди, время ожидания job, количество failed executions, число reconnect в логах worker, latency Postgres и потребление памяти Redis. Если очередь растёт, а workers загружены не полностью, проблема может быть во внешнем API, блокировках базы или слишком низком concurrency для конкретного типа workflow.

Наблюдаемость Redis и workers ¶

Критерий готовности ¶

Redis готов для n8n queue mode, если main и workers используют один Redis, smoke-test подтверждает выполнение jobs, алерты видят зависшие и failed executions, а runbook объясняет, что делать при connection refused, рестарте Redis и остановке worker. Без этих проверок масштабирование будет выглядеть как ускорение, но вести себя как новая зона риска.

Что читать дальше ¶

Redis обычно появляется после настройки production ENV и Postgres backup. Для полной архитектуры откройте масштабирование n8n. Если ошибка уже произошла, проверьте ECONNREFUSED.