---
title: "Redis для n8n queue mode — Nodbot"
source_url: "https://nodbot.ru/hosting/redis/"
canonical_url: "https://nodbot.ru/hosting/redis/"
language: "ru"
content_type: "HostingGuide"
section: "hosting"
generated_at: "2026-05-30"
word_count_source: 748
---

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

## AI summary

Практическая страница про Redis в n8n queue mode: за что отвечает Redis, какие ENV нужны main и worker, как диагностировать connection refused, зависшие jobs и ошибки конфигурации очереди.

## Best used for

Материал помогает внедрить страницу как production-runbook: понять интент, проверить риски, сохранить owner и не смешивать тему с соседними сценариями.

## Key topics

- Роль Redis в queue mode
- Минимальная схема компонентов
- ENV для Redis и workers
- Smoke-test очереди
- Monitoring Redis для n8n
- Типичные ошибки Redis n8n
- Change window для Redis
- Наблюдаемость Redis и workers
- Критерий готовности
- Что читать дальше

## Source outline

# Redis для n8n queue mode: очередь без потерянных executions [¶](#redis-dlya-n8n-queue-mode "Permanent link")

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

Сохранить в мой план[Открыть мой план](/my-plan/)

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

## Роль Redis в queue mode [¶](#rol-redis-v-queue-mode "Permanent link")

В обычном режиме 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-связность из каждого контейнера.

## Минимальная схема компонентов [¶](#minimalnaya-shema-komponentov "Permanent link")

| Компонент | Роль | Что должно совпадать |
| --- | --- | --- |
| main n8n | UI, webhooks, постановка jobs | DB, Redis, encryption key, timezone |
| worker n8n | выполнение workflow executions | тот же DB и Redis, те же credentials secrets |
| Redis | очередь Bull/jobs | доступность, auth, persistence по решению |
| Postgres | состояние workflows и executions | одна база для main и workers |
| Reverse proxy | внешний webhook endpoint | правильный WEBHOOK\_URL |

## ENV для Redis и workers [¶](#env-dlya-redis-i-workers "Permanent link")

Для 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 очереди [¶](#smoke-test-ocheredi "Permanent link")

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 [¶](#monitoring-redis-dlya-n8n "Permanent link")

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

## Типичные ошибки Redis n8n [¶](#tipichnye-oshibki-redis-n8n "Permanent link")

* включить 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 [¶](#redis-change-window "Permanent link")

При инциденте сначала определите, теряются ли события или только задерживаются. Потеря очереди требует одного 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-observability-workers "Permanent link")

## Критерий готовности [¶](#kriteriy-gotovnosti-hosting-redis "Permanent link")

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

## Что читать дальше [¶](#chto-chitat-dalshe "Permanent link")

Redis обычно появляется после настройки [production ENV](/hosting/environment-variables/) и [Postgres backup](/hosting/postgres-backup-restore/). Для полной архитектуры откройте [масштабирование n8n](/hosting/scaling/). Если ошибка уже произошла, проверьте [ECONNREFUSED](ECONNREFUSED в n8n: причины и разбор).