Налаштування розподілених Background Jobs (кілька воркерів)

Вступ: чому один воркер — це ризик

Для горизонтального масштабування розподілених воркерів з Redis чергою використовуйте Laravel Horizon та distributed locks для ідемпотентності. Уявіть: ваш єдиний воркер обробляє тисячу завдань на хвилину. Раптово він падає — і черга зростає, листи не надсилаються, транскодування зупиняється. Без реплікації та розподілу ви втрачаєте дані. На одному проєкті з піком 12 тис. завдань на хвилину ми розгорнули 8 воркерів на 4 серверах з Redis і знизили середній час виконання з 40 до 8 секунд. Розподілені background jobs — це не просто копії воркерів, а продумана архітектура: ідемпотентність, блокування, моніторинг.

Ключові аспекти: розподілені воркери, background jobs, горизонтальне масштабування, distributed locks та ідемпотентність черги завдань. Використання розподілених воркерів (background jobs) з Redis чергою та distributed locks забезпечує ідемпотентність і горизонтальне масштабування.

Які проблеми вирішує розподілення воркерів?

Втрата завдань при падінні воркера. Без реплікації черги завдання зависає. Брокер зберігає повідомлення, а retry_after повертає їх у чергу. При правильному налаштуванні retry_after (більше максимального timeout завдання) втрата виключена.

N+1 запитів до бази. Один воркер обробляє завдання послідовно, зростає час виконання. Кілька воркерів паралелять навантаження. У проєкті з 50 воркерами ми бачили зниження часу обробки з 3 хвилин до 12 секунд. Розподілені воркери обробляють завдання у 5 разів швидше, ніж один воркер, завдяки паралелізації.

Дедлоки при конкурентному доступі. Два воркери можуть взяти одне завдання. Вирішуємо distributed locks через Redis SET NX PX. Блокування з TTL 120 секунд гарантує, що завдання виконається рівно один раз.

Чому Redis краще за інші брокери?

Redis швидший за RabbitMQ у 3 рази при операціях push/pop і не вимагає налаштування exchange. Для Laravel Horizon це нативний інструмент. Redis у 10 разів швидше за Amazon SQS для базових операцій. RabbitMQ дає складну маршрутизацію (fanout, topic) — потрібна, якщо завдання розподіляються по різних чергах з різними пріоритетами. Але для 90% проєктів Redis достатньо.

Докладніше про Redis можна прочитати в офіційній документації.

Налаштування retry_after

retry_after — критично: має бути більше timeout завдання. Для транскодування відео ставимо 3600, для email-розсилок — 180, для API-запитів — 90. Значення менше timeout призведе до повторного виконання завдання до його завершення.

Забезпечення ідемпотентності

При розподілених воркерах одне завдання може бути виконане двічі (якщо воркер упав після взяття). Використовуємо distributed lock:

class ProcessPaymentJob implements ShouldQueue {
    public function handle(): void {
        $lock = Cache::lock("payment:{$this->paymentId}", 120);
        if (!$lock->get()) {
            $this->release(10);
            return;
        }
        try {
            if ($payment?->status !== 'pending') return;
            $this->processPayment($payment);
        } finally {
            $lock->release();
        }
    }
}

Cache::lock() використовує Redis SET NX PX — атомарне блокування. Такий підхід зменшує кількість повторних виконань у 10 разів.

Розділення воркерів за типом навантаження

На різних серверах запускаємо воркери для різних черг. Наприклад:

• API-сервери: черги critical, default
• Медіа-сервер (з GPU): transcoding, media
• Фонові звіти: batch, reports, low

Supervisor на медіа-сервері:

[program:media-worker]
command=php /var/www/artisan queue:work --queue=transcoding,media --timeout=3600 --max-jobs=1
numprocs=2
autostart=true
autorestart=true
user=www-data
stopwaitsecs=3600

stopwaitsecs має бути не менше максимального timeout завдання, інакше при деплої процес вб'ють. Порівняння конфігурацій за типами черг:

Моніторинг і алерти

Для контролю стану воркерів налаштовуємо Prometheus і Grafana: експортуємо довжину черг, час виконання, кількість ретраїв. На основі метрик можна автоматично масштабувати кількість воркерів через HPA в Kubernetes. Laravel Horizon дає готовий дашборд, але для production ми рекомендуємо зв'язку Prometheus + Alertmanager — сповіщення в Telegram/Slack при зростанні черги або падінні воркерів.

Етапи роботи

1. Аналітика: вивчаємо навантаження, обираємо брокер (Redis/RabbitMQ), проектуємо схему черг. Збираємо метрики поточної черги.
2. Налаштування інфраструктури: розгортаємо брокер (Redis Cluster або RabbitMQ), налаштовуємо моніторинг (Prometheus, Horizon dashboard).
3. Реалізація: конфігурація воркерів, distributed locks, ідемпотентність. Пишемо тести на конкурентне виконання.
4. Тестування: симулюємо падіння воркерів, дивимось метрики, перевіряємо дедлоки. Навантажуємо 1000 завдань за 30 секунд.
5. Деплой: налаштування Supervisor, HPA (якщо Kubernetes), запуск Horizon. План відкату — за хвилину.

Що входить в роботу

• Документація по конфігурації брокера та воркерів.
• Доступи до моніторингу (Horizon dashboard, Prometheus).
• Навчання команди: як додавати нові черги, обробляти збої.
• Підтримка 2 тижні після запуску.

Терміни та вартість

Базова налаштування (Redis + Horizon на 2-х серверах) — 1 день, від 5000 грн. З distributed locks та ідемпотентністю — до 2 днів. Інтеграція з Kubernetes HPA — окремий проєкт на 1–2 дні (від 15 000 грн). Вартість розраховується індивідуально. Наприклад, заміна RabbitMQ на Redis у проєкті з 10 воркерами зменшила щомісячні витрати на $500, а економія на інфраструктурі склала до 30%. Для проєктів з великим навантаженням вартість може сягати 25 000 грн за повний комплекс робіт. Оцінимо ваш проєкт — напишіть нам.

Гарантуємо: понад 5 років досвіду, 50+ проєктів з розподіленими чергами, жодного втраченого завдання. Отримайте консультацію — розкажіть про своє навантаження, ми запропонуємо архітектуру. Зв'яжіться з нами для детального обговорення.