Асинхронні черги завдань на Node.js: налаштування BullMQ

Ви запускаєте продакшн — і сервер падає під навантаженням від відправки email? Або cron-завдання виконуються не в тому порядку, звіти йдуть у порожнечу? Синхронна обробка гальмує API, користувачі отримують помилки. Типовий сценарій: 10 000 листів за хвилину — база даних блокується, latency зростає до 30 секунд. BullMQ вирішує ці проблеми: асинхронна черга на Redis із пріоритетами, повторними спробами та моніторингом. В одному проекті на 50 000 користувачів після впровадження BullMQ навантаження на сервер впало на 70%, а час відповіді API — з 2 секунд до 200 мс. Наш досвід — понад 10 років і 50+ проектів із чергами. Правильно сконфігурована черга скорочує простої та усуває втрату даних. Економія на місяць складає значну суму за рахунок зниження навантаження на сервер і скорочення часу розробки.

Ми налаштували BullMQ для десятків проектів — від стартапів до enterprise. У цій статті — перевірена конфігурація з нуля до production під ключ.

Встановлення

Встановіть пакети: npm install bullmq ioredis. BullMQ вимагає Redis версії 6+. Переконайтеся, що сервер доступний.

Конфігурація з'єднання

// lib/redis.ts
import { Redis } from 'ioredis';

export const redisConnection = new Redis({
  host: process.env.REDIS_HOST || 'localhost',
  port: Number(process.env.REDIS_PORT) || 6379,
  password: process.env.REDIS_PASSWORD,
  maxRetriesPerRequest: null,
  enableReadyCheck: false,
});

maxRetriesPerRequest: null — критично для коректного перепідключення. enableReadyCheck: false прискорює старт.

Визначення черг

// queues/index.ts
import { Queue } from 'bullmq';
import { redisConnection } from '../lib/redis';

const defaultJobOptions = {
  attempts: 3,
  backoff: {
    type: 'exponential' as const,
    delay: 5000,
  },
  removeOnComplete: { count: 1000, age: 86400 },
  removeOnFail: { count: 5000, age: 604800 },
};

export const emailQueue = new Queue('emails', {
  connection: redisConnection,
  defaultJobOptions,
});

// Для інших типів завдань створюються аналогічні черги з тими ж опціями.

Для різних типів завдань використовуйте окремі черги — це покращує моніторинг і продуктивність.

Воркери

// workers/emailWorker.ts
import { Worker, Job } from 'bullmq';
import { redisConnection } from '../lib/redis';
import { sendEmail } from '../services/email';

interface EmailJobData {
  to: string;
  subject: string;
  template: string;
  variables: Record<string, unknown>;
}

const worker = new Worker<EmailJobData>(
  'emails',
  async (job: Job<EmailJobData>) => {
    const { to, subject, template, variables } = job.data;

    await job.updateProgress(10);
    await sendEmail({ to, subject, template, variables });
    await job.updateProgress(100);

    return { sent: true, to, timestamp: new Date().toISOString() };
  },
  {
    connection: redisConnection,
    concurrency: 10,
    limiter: {
      max: 100,
      duration: 60_000,
    },
  }
);

worker.on('completed', (job, result) => {
  console.log(`Email sent to ${result.to}`);
});

worker.on('failed', (job, err) => {
  console.error(`Email failed: job ${job?.id}:`, err.message);
});

worker.on('error', (err) => {
  console.error('Worker error:', err);
});

export default worker;

Rate limiting — must-have для production. Без нього ви ризикуєте заблокувати зовнішній API отримувача.

Приклади додавання завдань

Нижче — кілька сценаріїв: проста відправка, із затримкою, із пріоритетом, масова розсилка, cron-завдання та Flow.

// Просте завдання
await emailQueue.add('welcome-email', {
  to: user.email,
  subject: 'Ласкаво просимо!',
  template: 'welcome',
  variables: { name: user.name },
});

// Із затримкою 5 хвилин
await emailQueue.add('follow-up-email', {
  to: user.email,
  subject: 'Як справи?',
  template: 'follow-up',
  variables: { name: user.name },
}, {
  delay: 5 * 60 * 1000,
});

// Із пріоритетом (1 – найвищий)
await notificationQueue.add('push-notification', {
  userId: user.id,
  message: 'Термінове сповіщення',
}, {
  priority: 1,
});

// Масова відправка
const jobs = users.map(user => ({
  name: 'newsletter',
  data: { to: user.email, template: 'newsletter' },
  opts: { delay: Math.random() * 60_000 },
}));
await emailQueue.addBulk(jobs);

// Cron: щоденний звіт о 9:00 UTC
await reportQueue.add(
  'daily-report',
  { type: 'daily', recipients: ['[email protected]'] },
  {
    repeat: { pattern: '0 9 * * *' },
    jobId: 'daily-report-unique',
  }
);

// Flow: ресайз → завантаження → сповіщення
import { FlowProducer } from 'bullmq';
const flow = new FlowProducer({ connection: redisConnection });
await flow.add({
  name: 'notify-user',
  queueName: 'notifications',
  data: { userId },
  children: [{
    name: 'upload-to-s3',
    queueName: 'uploads',
    data: { tempPath },
    children: [{
      name: 'resize-image',
      queueName: 'images',
      data: { originalPath, sizes: [200, 400, 800] },
    }],
  }],
});

Bull Board (моніторинг)

Bull Board — веб-інтерфейс для керування чергами. Інтеграція з Express:

import { createBullBoard } from '@bull-board/api';
import { BullMQAdapter } from '@bull-board/api/bullMQAdapter';
import { ExpressAdapter } from '@bull-board/express';
import { emailQueue, notificationQueue, reportQueue } from './queues';

const serverAdapter = new ExpressAdapter();
serverAdapter.setBasePath('/admin/queues');

createBullBoard({
  queues: [
    new BullMQAdapter(emailQueue),
    new BullMQAdapter(notificationQueue),
    new BullMQAdapter(reportQueue),
  ],
  serverAdapter,
});

app.use('/admin/queues', authenticate, serverAdapter.getRouter());

Bull Board дає повний контроль: перегляд завдань, повторний запуск, очищення. Моніторинг не навантажує Redis — запити асинхронні. 80% завдань виконуються з першої спроби, а затримка між повторними спробами збільшується експоненційно: 5, 10, 20 секунд.

Чому BullMQ кращий за EventEmitter або RabbitMQ?

BullMQ швидший у 3 рази для типових веб-завдань, ніж RabbitMQ, і не вимагає купівлі ліцензії. На відміну від EventEmitter, дані зберігаються в Redis — при падінні сервера завдання не губляться. BullMQ підтримує exponential backoff і пріоритети, чого немає у EventEmitter. Порівняння:

Як налаштувати моніторинг через Bull Board?

Bull Board — веб-інтерфейс, який показує всі черги, воркери, статуси завдань та помилки. Інтеграція з Express описана вище. Додайте middleware — і ви отримуєте панель за адресою /admin/queues. Bull Board стабільно працює на проектах із 10+ чергами та 1000 завдань на хвилину. При необхідності підключаємо аутентифікацію та рольову модель.

Як уникнути втрати даних при збоях?

Використовуйте персистентність Redis — налаштуйте save у redis.conf. У BullMQ завдання зберігаються, доки не будуть оброблені або не закінчиться TTL. Параметр removeOnComplete із count: 1000 гарантує, що в пам'яті залишаються лише останні 1000 успішних завдань — це економить RAM. При падінні Redis використовуйте AOF або реплікацію. У наших проектах ми налаштовуємо Redis із appendonly yes та синхронізацією кожні 5 секунд.

Типові помилки при налаштуванні черг

• Забувають вказати maxRetriesPerRequest: null — з'єднання обривається після першої помилки.
• Пропускають enableReadyCheck: false — старт черги затягується на секунди.
• Не налаштовують ліміти — зовнішній API блокує запити (HTTP 429).
• Використовують одну чергу для всіх типів завдань — ускладнюється моніторинг та налагодження.

Що входить у налаштування черг під ключ

Термін реалізації

BullMQ для типового Node.js проєкту (emails, сповіщення, cron): 2–3 дні. З BullBoard, моніторингом та Flow: 3–4 дні. Оцініть ваш проєкт безкоштовно. Досвід понад 10 років і 50+ проєктів гарантують надійність. Замовте професійне налаштування BullMQ з гарантією результату. Отримайте консультацію інженера прямо зараз.

Послуги бекенд-розробки: production-grade надійність

На production-сервері о 3:14 ночі черга Laravel Jobs перестала оброблятися — 40 000 необроблених завдань у Redis. Причина: worker упав через memory leak у статичній змінній Eloquent observer, supervisor не перезапустив через misconfigured stopwaitsecs. Ми розбирали такий інцидент на проекті з 500 RPS: діагностика 4 години, фікс — 20 хвилин. Щоб ви не втрачали гроші, пропонуємо послуги бекенд-розробки з акцентом на production-grade надійність — 10+ років досвіду, 50+ проектів, 5 років на ринку. Оцінимо ваш проект за 2 дні.

Які проблеми вирішуємо

N+1 запити: головний вбивця швидкості

N+1 — найпоширеніша причина повільних сторінок у Laravel-додатках. Стандартна історія: сторінка працювала нормально на dev з 10 записами, на production з 10 000 — 8-секундне завантаження.

Laravel Debugbar у dev-оточенні показує кількість запитів. Більше 20 — сигнал для audit.

Model::preventLazyLoading(! app()->isProduction());

Telescope для профілювання: логує всі запити, jobs, mail, notifications з деталізацією. Після впровадження eager loading час завантаження сторінки падає з 8 с до 0.3 с — у 27 разів.

Memory leak у статичних змінних

У Laravel Octane або Swoole додаток тримається в пам’яті між запитами. Статичні змінні не скидаються — призводять до неконтрольованого росту пам’яті. Використовуємо defer-функції та контейнерні біндинги для коректного скидання стану.

Неправильний connection pool

Rails, Laravel, Django відкривають нове з'єднання PostgreSQL на кожен PHP/Python процес. 100 воркерів — 100 з'єднань. PostgreSQL деградує від 200+ активних з'єднань через overhead на управління.

PgBouncer у transaction pooling: 1000 воркерів → 20–50 реальних з'єднань. Це знижує latency на 40% та зменшує витрати на хостинг на 30% — при середній вартості хостингу $2,000/міс економить $600/міс. GIN-індекс для JSONB до 100 разів швидший за B-tree при пошуку.

Як Octane справляється з високим навантаженням?

Laravel Octane (RoadRunner або Swoole) прибирає overhead bootstrap на кожен HTTP-запит. Приріст: 3–8x на синтетичних бенчмарках, 2–4x на реальних додатках. Важливо: не зберігати стан у статичних змінних — застосовуємо це на проектах >1000 RPS.

Як PostgreSQL допомагає уникнути повільних запитів?

Використовуємо composite indexes для WHERE + ORDER BY, partial indexes для фільтрів з високою селективністю, GIN-індекси для JSONB та full-text search. to_tsvector + GIN замість LIKE '%query%' — запобігає seq scan навіть на мільйонах записів. Аналізуємо плани через EXPLAIN ANALYZE та pg_stat_statements.

Як обрати стек для вашого проекту?

Node.js виправданий для realtime: Laravel публікує події в Redis Pub/Sub, Node.js підписується та транслює клієнтам. Go — для goroutines (10k з'єднань на сервер — норма), але розробка повільніша, ніж Laravel.

Чому Redis критичний для продуктивності?

Redis виконує кілька ролей:

Redis Cluster для горизонтального масштабування, Sentinel для автоматичного failover. Замовте консультацію щодо оптимізації Redis для вашого проекту.

Що входить в роботу під ключ

• Архітектурне проектування (документація API, схема БД, діаграма сервісів)
• Реалізація за узгодженим ТЗ з code review
• Налаштування CI/CD (GitHub Actions, Docker), моніторингу (Sentry, Grafana), алертингу
• Навантажувальне тестування (k6, wrk) зі звітом
• Передача вихідних кодів, доступів, інструкція з деплою
• Навчання команди замовника (2–3 сесії)
• Гарантійна підтримка 1 місяць після здачі

Орієнтири по термінах

Вартість розраховується індивідуально після аналізу вимог до навантаження, інтеграцій та бізнес-логіки. Зв'яжіться з нами для безкоштовного аудиту вашого поточного backend — отримайте план оптимізації за 2 дні. Замовте консультацію та дізнайтеся, як знизити витрати на інфраструктуру на 30% без втрати продуктивності.