n8n queue mode Redis: коли виходити з режиму одного інстансу
Практичний гід із n8n queue mode Redis: ознаки, що один інстанс уже не справляється, нові вимоги та ключові налаштування.
Перевірено за наведеними джерелами .
Ознаки того, що один інстанс перестає справлятися
Якщо ви хостите n8n самостійно, перша версія, яку ви запускаєте, майже завжди — це regular mode: один процес, який тригерить, виконує й обслуговує редактор. Це добре працює, доки продакшн-трафік не починає приходити сплесками, і саме тоді вперше згадують n8n queue mode Redis. Згідно з документацією n8n для self-hosted, regular mode не обмежує кількість одночасних продакшн-виконань, через що event loop може захлинатися; стелю можна задати через N8N_CONCURRENCY_PRODUCTION_LIMIT.
Ця різниця важлива, коли ви вирішуєте, чи n8n queue mode Redis — правильна відповідь. Обмеження конкурентності — це захист: воно тримає інтерфейс чуйним, відмовляючись запускати все одразу. Queue mode — це пропускна здатність: він додає машини, які реально роблять роботу. Якщо ваш інстанс перевантажується лише зрідка, спершу спробуйте обмеження. Якщо ж беклог сталий і черга ніколи не спорожняється, вам потрібні додаткові потужності.
Документація n8n не називає обсягу виконань, за якого один інстанс перестає справлятися, тож сприймайте наведені нижче симптоми як спостереження, а не як поріг.
Sources: Control concurrency | Deploy | n8n Docs
Як працює queue mode і що він вимагає
У queue mode головний інстанс перестає виконувати роботу сам. Він створює виконання й передає його ID у Redis, який ставить його в чергу для наступного вільного воркера — так описано в документації n8n. Воркери забирають задачі, виконують їх і записують результати у спільну базу даних. У ваших воркфлоу нічого не змінюється; змінюється лише те, де вони виконуються.
Шлях одного виконання в queue mode
- Тригер: Головний інстанс отримує тригер і створює виконання.
- Постановка в чергу: Він передає ID виконання в Redis, замість того щоб запускати воркфлоу самому.
- Підхоплення: Наступний вільний воркер бере задачу з черги.
- Виконання: Воркер виконує воркфлоу, використовуючи спільний ключ шифрування для читання облікових даних.
- Збереження: Результати записуються у спільну базу PostgreSQL.
Цей поділ створює реальні вимоги до self-hosted n8n. Розподілена конфігурація queue mode не підтримується на SQLite, тож спершу потрібна спільна база PostgreSQL. Ключ шифрування головного інстансу має бути спільним для кожного воркера й вебхук-процесора, інакше вони не зможуть розшифрувати збережені облікові дані. Redis стає компонентом, який ви тепер експлуатуєте й моніторите.
Обмеження за редакціями варто перевірити ще до планування архітектури. Multi-main high availability для queue mode — це self-hosted Enterprise-функція, а на n8n Cloud queue mode доступний лише на планах Enterprise і має бути увімкнений командою n8n. Серед варіантів хостингу n8n саме self-hosting дає вам контроль над топологією.
Sources: Enable queue mode | Deploy | n8n Docs, Understand concurrency | Deploy | n8n Docs
Базова конфігурація n8n queue mode Redis і розмір пулу воркерів
Перемикання режимів — це здебільшого змінні середовища. EXECUTIONS_MODE має бути встановлено в queue на головному інстансі та на всіх воркерах. Налаштування підключення до Redis відповідають задокументованим значенням n8n за замовчуванням: QUEUE_BULL_REDIS_HOST за замовчуванням localhost, порт — 6379, з опційними username, password, індексом бази даних і TLS.
Саме на масштабуванні команди помиляються. n8n рекомендує ставити конкурентність воркера на 5 або більше і попереджає, що багато воркерів із низькою конкурентністю кожен можуть вичерпати пул з'єднань з базою даних. Тож масштабуйте кількість воркерів, а не знижуйте конкурентність. Документація n8n не дає формули зв'язку кількості воркерів із навантаженням, тож починайте з малого й спостерігайте.
| Компонент | Роль | Що треба вирішити |
|---|---|---|
| PostgreSQL | Спільний стан для всіх процесів | Спершу мігруйте з SQLite; SQLite тут не підтримується |
| Redis | Ставить ID виконань у чергу для воркерів | Хост, порт, облікові дані та чи вмикати TLS |
| Головний інстанс | Тригерить і ставить у чергу, обслуговує редактор | EXECUTIONS_MODE встановлено в queue |
| Воркери | Виконують воркфлоу з черги | Конкурентність 5 або вище, далі додавайте більше воркерів |
| Ключ шифрування | Дає воркерам читати збережені облікові дані | Той самий ключ, розданий кожному процесу |
Розбір від спільноти n8n за лютий 2025 року показує, наскільки скромною може бути перша лабораторія з n8n queue mode Redis: мережа Docker із Redis, Postgres, головним інстансом і контейнерами-воркерами, які спільно використовують один env-файл. Там використовуються паролі у відкритому вигляді без TLS, тож сприймайте це як лабораторну вправу, а не як продакшн-орієнтир.
Sources: Enable queue mode | Deploy | n8n Docs, Queue mode | Deploy | n8n Docs, Queue Mode guide [How to scale up n8n] - English 🇬🇧 - n8n Community
Вебхуки, великі відповіді та перевірка
Як редакційне емпіричне правило: додавайте окремі вебхук-процесори лише тоді, коли саме прийом вебхуків є реальним вузьким місцем. Хай там що ви вирішите, кожен вебхук-процесор потребує того самого ключа шифрування, що й головний інстанс і воркери, інакше він не зможе читати збережені облікові дані.
Великі відповіді заслуговують на увагу, бо в queue mode відповіді вебхуків проходять через Redis. n8n документує ліміт розміру релею зі значенням за замовчуванням 64 MiB і радить закладати приблизно в 1,5 раза більше пам'яті Redis на кожну відповідь «у польоті»; це оцінка вендора без зазначеної методики вимірювання. Вивантаження завеликих тіл через N8N_WEBHOOK_RESPONSE_RELAY_OFFLOAD_ENABLED варто вмикати на воркерах лише після того, як усі головні та вебхук-інстанси працюють на n8n 2.34.0 або новішій, і для цього потрібен режим бінарних даних, який зберігає дані.
Перевірка проста: запустіть тестовий воркфлоу і переконайтеся, що він з'являється в логах воркера, а не головного інстансу. Усе це спирається на документацію вендора плюс один допис спільноти від окремого автора, а незалежних бенчмарків пропускної здатності чи затримки тут немає, тож виміряйте власне навантаження, перш ніж обіцяти потужність.
- Мігруйте базу даних на PostgreSQL і переконайтеся, що інстанс нормально працює на ній.
- Підніміть Redis і забезпечте доступ до нього з хоста n8n.
- Встановіть EXECUTIONS_MODE у queue і роздайте спільний ключ шифрування кожному процесу.
- Запустіть два воркери з конкурентністю 5 або вище і виконайте тестовий воркфлоу.
- Перевірте логи воркера, щоб підтвердити, що виконання пішло з головного інстансу.
- Як редакційне емпіричне правило: розглядайте відокремлення прийому вебхуків лише тоді, коли він явно став вузьким місцем.
Sources: Enable queue mode | Deploy | n8n Docs, Queue mode | Deploy | n8n Docs
Поетапна міграція, яку реально довести до кінця
Висновок недраматичний. Якщо ви хостите n8n самостійно, залишайтеся в regular mode з обмеженням продакшн-конкурентності доти, доки воно тримає, і переходьте лише тоді, коли сталий беклог показує, що справжня потреба — додаткові потужності. Перевіряйте вимоги до редакції до проєктування топології, а не після.
Серед варіантів хостингу n8n саме n8n queue mode Redis є точкою, де n8n перестає бути застосунком, який ви встановили, і стає інфраструктурою, яку ви експлуатуєте. Плануйте чергування on-call і моніторинг Redis разом із конфігурацією.
Sources: Control concurrency | Deploy | n8n Docs, Enable queue mode | Deploy | n8n Docs
