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

в минимальном комплекте?

есть какие-то начитанные данные, но пока не понимаю назначения всего что начитал "что зачем и для чего", просто вижу "можно так-то"

например.
задачи (для примера):
1) когда юзер авторизуется заносить его в три места.
2) покупки юзеров агрегировать и пересчитывать время от времени

exchange:
user, payment

queue:
user.events.registered, payment.commands, payment.events.processed

consumer:
user.events.registered.app1
user.events.registered.app2
user.events.registered.app3
payments.events.processed
payments.commands

Как при обработке команд например будет перейти к цепочкам если понадобится более одного действия на консюмере?

Чем лучше запускать процессы, в каком месте позволять обрабатывать сообщения параллельно? Так-то команды обычно выполняются одна за другой, но есть какие-то точки (которые я пока не понимаю) позволяющие некоторые из них выполнять не мешая другим

Как организуются задачи требующие запуска не одного процесса, а нескольких причем желательно с временным перерывом, типа процесс платежа начался - обработали, ожидаем оплаты, которая может не произойти

Ну вот эти моменты разжевать... псевдокодом ли, или примерами на "птичках"

Давай начнем с кейса периодически чет пересчитывать. Чем крон не устраивает?

Кроны и очереди вообще разные штуки. Они не заменяемые.

Ну можно поэмулировать очереди через крон. Складываешь таски в базу, а потом выполняешь раз в минуту батчами.

Почему эмулировать? это будет настоящая очередь, просто консьюмер раз с минуту запускается ) Крон это штук которая запускает задачи интервально, или по времени разово. Ни больше ни меньше. Шедулер короче.

А для сборки батчей чем пользоваться удобно? Я вот доклад послушал сейчас где рекомендовали для кроля на клиентской стороне батч формировать. В моем случае юзеры регаются то часто то редко. Если бы это был псевдокод на каком-то rxjs то там стояло бы два триггера - временной и количественный, и по одному из них срабатывала бы отправка батча в очередь. Но это значит что мне сначала надо эти регистрации накопить где-то, и поскольку пхп это разные таки процессы на каждого юзера, то снова бд. и из бд в очередь, чтобы... запустить обработку. То есть получается что крон как раз временной триггер, тогда как количественный может быть сделан на хендлере закидывающем в БД чтоли? Закинул одну, увидел что их двадцать собралось, пнул очередь, та запустила скрипт тот же что и в кроне висит. Тогда очередь что-то вроде управляющего исполнителями, которые могут быть на других машинах.

Я честно говоря вопроса не понял, у вас уже какая то комбинация крона кролика и батчей пошла. Зачем вам какие то временные, количественные батчи уже? Я про батч упомянул, потому что кроном забирать по 1 таске раз в минуту, но это прям для совсем лоу трафика

В оригинале звучало, что крон и очереди дополняют друг друга, и был контраргумент что одно можно заменить другим. Я попробовал прокомментировать свою точку зрения и ждал либо опровержения либо поддержки на самом деле, нежели ответа на вопрос. То есть если бы код писался на реактивном каком-то языке, то была бы переменная в которую накапливается батч, к примеру обработка каждые 10 входящих, пакетная. Но бывает так что поток остановился и месяц висит 5 входящих. И тогда нужен таймер и запустить по времени, не важно сколько скопилось. С этой точки зрения и крон и очередь дополняют друг друга. С другой стороны в некоторых очередях должно быть какое-то решение для запуска каждые N секунд, но они вроде не совсем про это предназначены... В технике сначала был генератор который валил в 1000 тактов, поверху поставили импульсный генератор, который собирал по 3-4-5 тактов по необходимости, и получился публичный канал, где кто не прочитал - тот пропустил. Поверху накатили накопитель - получился приватный канал, где ты точно прочтешь, но позже. А потом накатили подтверждение, чтобы знать что делать если ты прочел, получилась шина команд. Можно накатить еще "что делать если через 5 сек не прочел" но крон именно с этой стороны начинает, а в остальное не умеет

А в MQ нельзя таймаутить события очереди?

и зачем?

Мы все еще про кролика и его очереди?

Просто прокомментировал, что одно другое скорее дополняет чем заменяет, но от крона врядли удатся отказаться в целях контроля застывших пачек. Впрочем пока задачи не перешли в фазу "делать пачками" можно отказаться. Когда перешли - либо очередь надо учить по времени само-тригерриться, либо крон должен вызывать скрипт, который пинает очередь

Сорри тут не понял, а для чего пачками? (пока выглядит как сильно лишнее)

Или я что-то не понимаю, или вы про очередь. Как ее тригерить, чем ее тригерить? Она не в памяти приложения. Мы же все еще про php и кролика? Ну да есть какие то особые кейсы, где надо что то пробатчить, чтобы например потом в одном запросе куда то отправить, но это вопросы оптимизации уже, и они врядли у вас, когда вы говорите что трафика у вас не так уж и много Очередь в кролике, а вы просто достаете оттуда по 1 сообщению, если оно там есть

да, такие объемы чтобы пачками почти недостижимы в обычной программе. я вот об этом из доклада того узнал. у чела 20000 в секунду входящих, и кролик "больше не умеет". то есть они как-то сделали что в следующую секунду можно еще 20000, а конкретно в эту - нет, и сообщения теряются. и лектор рекомендовал собрать в пачки и пачками слать в рэббит, что увеличит размер боди сообщения в байтах, но вырастет число заявок в секунду

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

Зачем? Они и так ее делают.

тот редкий кейз когда в секунду может прийти 30000 заявок, и 10000 из них потеряются из-за того что кролик лимитирован как апи гугла - 20тыщ в сек

Чтобы накопить такой объем перед батчем, вам нужно минимум неумирающее приложение которое выдержит такой rps, что уже маловероятно на 1 машине

думаю да, я так теоретически размышляю, я ж в этом не варю почти

Можно получается поднять 2 кролика в кубере и проблема решится до 30к в сек?