Вступление: почему один воркер — это риск
Представьте: ваш единственный воркер обрабатывает тысячу задач в минуту. Внезапно он падает — и очередь нарастает, письма не отправляются, транскодирование стопорится. Без репликации и распределения вы теряете данные. На одном проекте с пиком 12 тыс задач в минуту мы развернули 8 воркеров на 4 серверах с Redis и снизили среднее время выполнения с 40 до 8 секунд. Распределённые background jobs — это не просто копии воркеров, а продуманная архитектура: идемпотентность, блокировки, мониторинг.
Какие проблемы решаем
Потеря задач при падении воркера. Без репликации очереди задача зависает. Брокер хранит сообщения, а retry_after возвращает их в очередь. При правильной настройке retry_after (больше максимального timeoute задачи) потеря исключена.
N+1 запросов к базе. Один воркер обрабатывает задачи последовательно, растёт время выполнения. Несколько воркеров параллелят нагрузку. В проекте с 50 воркерами мы видели снижение времени обработки с 3 минут до 12 секунд.
Дедлоки при конкурентном доступе. Два воркера могут взять одну задачу. Решаем distributed locks через Redis SET NX PX. Блокировка с TTL 120 секунд гарантирует, что задача выполнится ровно один раз.
Почему Redis чаще выбирают для очередей?
Redis быстрее RabbitMQ в 3 раза при операциях push/pop и не требует настройки exchange. Для Laravel Horizon это нативный инструмент. 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 UDP |
Подробнее о 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 — атомарная блокировка.
Разделение воркеров по типу нагрузки
На разных серверах запускаем воркеры для разных очередей. Например:
- 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 день. С distributed locks и идемпотентностью — до 2 дней. Интеграция с Kubernetes HPA — отдельный проект на 1–2 дня. Стоимость рассчитывается индивидуально. Оценим ваш проект — напишите нам.
Гарантируем: более 5 лет опыта, 50+ проектов с распределёнными очередями, ни одной потерянной задачи. Получите консультацию — расскажите о своей нагрузке, мы предложим архитектуру. Свяжитесь с нами для детального обсуждения.