Redis для queue mode n8n: настройка, память, stalled jobs и восстановление очереди ¶

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

Redis в n8n queue mode — это не “кэш для ускорения”, а транспорт для очереди задач между main instance и workers. Если Redis недоступен, workers перестают получать jobs, executions застревают, а webhooks могут отвечать нестабильно. Поэтому Redis надо настраивать как часть production-инфраструктуры, а не как случайный контейнер без volume и лимитов.

Эта инструкция разбирает практическую настройку Redis для Docker Compose, переменные n8n, мониторинг памяти, типовые ошибки и безопасное восстановление после сбоя.

Минимальная архитектура queue mode ¶

external service → n8n main/webhook → Redis queue → n8n worker → PostgreSQL/external API

Main принимает запросы, планирует executions и кладёт jobs в очередь. Worker забирает jobs и выполняет workflow. PostgreSQL хранит workflows, credentials metadata и execution state. Redis не заменяет PostgreSQL.

Docker Compose для Redis ¶

services:
  redis:
    image: redis:7-alpine
    command: >
      redis-server
      --appendonly yes
      --maxmemory 512mb
      --maxmemory-policy noeviction
    volumes:
      - redis_data:/data
    restart: unless-stopped

  n8n:
    image: n8nio/n8n:1.99.1
    environment:
      EXECUTIONS_MODE: queue
      QUEUE_BULL_REDIS_HOST: redis
      QUEUE_BULL_REDIS_PORT: 6379

  n8n-worker:
    image: n8nio/n8n:1.99.1
    command: worker
    environment:
      EXECUTIONS_MODE: queue
      QUEUE_BULL_REDIS_HOST: redis
      QUEUE_BULL_REDIS_PORT: 6379

volumes:
  redis_data:

Политика noeviction лучше, чем внезапное вытеснение данных очереди. Если Redis упирается в память, надо уменьшать нагрузку, добавлять workers или менять архитектуру, а не позволять Redis молча выкидывать ключи.

Env-переменные, которые часто забывают ¶

Smoke-test queue mode ¶

1. Запустите main, Redis и один worker.
2. Создайте workflow: Webhook → Wait 5 seconds → Respond to Webhook.
3. Активируйте workflow и отправьте POST.
4. Откройте логи worker: он должен получить job.

docker compose logs -f --tail=100 n8n-worker
redis-cli -h redis INFO memory
redis-cli -h redis PING

Если execution создаётся, но worker ничего не делает, проверьте, что worker подключён к той же Docker network и использует тот же Redis host.

Типовые симптомы и исправления ¶

Память и retention ¶

Redis не должен быть единственным буфером для бесконечного потока. Если webhook получает тысячи событий, добавьте idempotency в PostgreSQL, ограничение rate, backoff и dead-letter workflow. Queue mode масштабирует выполнение, но не исправляет плохой контракт данных.

У PostgreSQL тоже должен быть pruning executions. Иначе даже при нормальном Redis база может разрастись из-за длинной истории executions и больших payload.

Как безопасно перезапускать Redis ¶

1. Остановите входящий поток webhooks или переведите отправителя в retry.
2. Дождитесь, пока активные executions завершатся, если это возможно.
3. Перезапустите Redis.
4. Перезапустите main и workers.
5. Прогоните smoke-test queue mode.

Не удаляйте Redis volume без понимания последствий. Если jobs были в очереди, они могут потеряться или остаться в несогласованном состоянии относительно executions.

docker compose ps
docker compose logs --tail=200 n8n
docker compose logs --tail=200 n8n-worker
printenv | grep -E 'N8N_|WEBHOOK_|DB_|QUEUE_'
# перед изменениями: backup базы + проверка N8N_ENCRYPTION_KEY

Связанные материалы ¶

• Queue mode в n8n
• Ошибка подключения Redis
• Stalled jobs в Redis/Bull
• Idempotency для webhook