Вступ: чому один воркер — це ризик
Для горизонтального масштабування розподілених воркерів з 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 достатньо.
| Брокер | Пропускна здатність | Складність | Routing | Надійність |
|---|---|---|---|---|
| Redis | 100k msg/s | Низька | Простий | Redis Sentinel/Cluster |
| RabbitMQ | 50k msg/s | Середня | Fanout, Topic | Кластер з mirrors |
| SQS | 10k msg/s | Висока | Обмежений | Керований AWS |
Докладніше про 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 завдання, інакше при деплої процес вб'ють. Порівняння конфігурацій за типами черг:
| Тип черги | Timeout | retry_after | Кількість воркерів |
|---|---|---|---|
| critical | 90 | 120 | 4 |
| default | 300 | 360 | 8 |
| transcoding | 3600 | 3700 | 2 |
| batch | 600 | 650 | 1 |
Моніторинг і алерти
Для контролю стану воркерів налаштовуємо Prometheus і Grafana: експортуємо довжину черг, час виконання, кількість ретраїв. На основі метрик можна автоматично масштабувати кількість воркерів через HPA в Kubernetes. Laravel Horizon дає готовий дашборд, але для production ми рекомендуємо зв'язку Prometheus + Alertmanager — сповіщення в Telegram/Slack при зростанні черги або падінні воркерів.
Приклад налаштування Prometheus експортера для черги
Для експорту метрик черги Redis використовуйте `phpredis-exporter` або спеціальний пакет для Laravel. В Kubernetes налаштуйте ServiceMonitor, щоб Prometheus автоматично збирав метрики.Етапи роботи
- Аналітика: вивчаємо навантаження, обираємо брокер (Redis/RabbitMQ), проектуємо схему черг. Збираємо метрики поточної черги.
- Налаштування інфраструктури: розгортаємо брокер (Redis Cluster або RabbitMQ), налаштовуємо моніторинг (Prometheus, Horizon dashboard).
- Реалізація: конфігурація воркерів, distributed locks, ідемпотентність. Пишемо тести на конкурентне виконання.
- Тестування: симулюємо падіння воркерів, дивимось метрики, перевіряємо дедлоки. Навантажуємо 1000 завдань за 30 секунд.
- Деплой: налаштування 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+ проєктів з розподіленими чергами, жодного втраченого завдання. Отримайте консультацію — розкажіть про своє навантаження, ми запропонуємо архітектуру. Зв'яжіться з нами для детального обговорення.