Всем привет! Кейс - рассылка уведомлений 5-ти тысячам пользователей Сейчас: Для рассылки

всем - запускается JOB, которая в фоне добавляет другие JOB с низким приоритетом очереди на отправку сообщения пользователю.
Получается 1-я JOB порождает и добавляет в очередь 5-тысяч JOB.

Но возникает проблема, так как запрос на рассылку поступает на контроллер из веб-приложения, то некоторые умудряются запустить рассылку 2 и более раз

Как предотвратить запуск рассылки если уже идет рассылка?

Я предположил несколько вариантов:

1. Упаковать все в Batch и мониторить по идентификатору - но наполнить переменную $job (как показано в документации) 5-ю тысячями объектов NotifyJob в которую я передам каждого пользователя - слишком жирно для памяти

2. Сделать определенное поле в кеше, но тогда - как обязать последнюю Job сменить статус на "нет рассылки"

Лок с id рассылки с некоторым ttl

А можете расписать идею пошире. А то не понял немного

Вот как вариант https://laravel.com/docs/10.x/queues#unique-jobs

Стремный вариант. Надо угадать, время, количество. И если ттл не закончится то нельзя запустить, хотя очередь уже может рассосаться

Да... Я понял уже что надо все завернуть в одну джобу и поставить на нее безлимитный тайм чтобы она обрабатвала 5тысяч пользователей а ошибочных пропускала

для чего порождать 5к задач, если можно обойтись одной? в момент создания очереди определяем ее уникальный идентификатор который позволит провести дедубликацию. пример. берем айди пользователя и json реквеста. складываем, берем от строки хэш. это и будет уникальный идентификатор под этим идентификатором кладем данные в редиску (не заставляйте базу отдавать вам такие большие ответы, не любит он такого) перед тем как задиспатчить джобу - проверяем есть ли такая запись в редиске? есть - скипаем, нет - диспатчим в джобу передаем только идентификатор редиски. не пихайте 5к айдишников, они уже хранятся отдельно (для параноиков используем файл вместо редиски) далее джоба поднимается и начинает вычитывать айдишники. взяла пачку в 10 штук, исполнила, записала прогресс. взяла, исполнила, записала. прогресс. упала, поднялась, проверила диф между основных хранилищем и тем что записано в прогрессе и продолжает выполняться. но возможно стоит посмотреть в сторону сервисов предоставляющих услуги батч рассылки. одним запросом вы отправляете все эмейлы и забываете.

5к задач было сделано для параллельного и независимого отправления уведомлений. Сейчас задумался над тем чтобы упаковать все в одну джобу и для массовой рассылки ею и ограничиться

если у вас 300 почтовых серверов которые асинхронно выполняют рассылку - ну может быть и круто параллельно и независимо делать рассылку а если у вас 1 почтовый сервре который в 1 потоке синхронно обрабатывает ваши запросы - так может ну его нафиг спамить конкурентными запросами его? ладно если у вас 1 воркер на этой очереди, все ваши джобы одна за другой будут отрабатывать. а если 10 воркеров? я хз что у вас за почтовый сервер, но он может и обидеться под нагрузкой

Там телеграм рассылка и параллельно по 2, 3 джобы

Думаю вы правы. Пересмотрим подход

ааа, вы телегу пушите? тогда развлекайтесь конечно)) хз сколько там тротлинг, но я бы на всякий случай чекнул этот момент)))

Развлекайтесь?))) в чем подвох?))

если тротлинга нет и телега вас не пошлет нахрен - то нет ниакого подвоха. я не читал апи телеги, но на 98% уверен что что то там с тротлингом должно быть...

Там троттлинг. Есть. Но мы делаем таймаут когда он появляется

ну тут уже дело ваше. первоначальный запрос вроде закрыли)

Спасибо огромное ✅👍👍👍

Причем тут угадывание? У тебя есть прогнозное время, за которое Джоба должна нагенерить других джоб. Твоя задача - не сделать оверлап. Это решается легко и разными способами. https://divinglaravel.com/dispatching-unique-jobs-to-laravel-queues Вот пример, про который я писал. Что в нем стремного?

>Как предотвратить запуск рассылки если уже идет рассылка? консюмить очередь и если там есть месаги не запускать просто?