Коллеги, сейчас очередь на database - есть ли смысл менять

на redis и это все проходит безболезнено? То есть я меняю место хранения джобов и получаю полную совместимость?

Может и так работать, если нагрузки на базу серьёзной нет. А переход просто сделать и безболезненно. Но если уже стоит редис - я бы конечно лучше его использовал бы.

Что подразумеваем под нагрузкой серьезной? Просто сейчас расставлены приоритеты на джобах. Бывает по 5000 джоб максимум

Это значит, что твои джобы могут тормозить базу и другие запросы из-за этого могут подвисать. Для объективной картины нужно смотреть мониторинг сервера в пиковые нагрузки. Но, если вообще в это не вникать и стоит редис - просто все перенастрой и все. Если редис не стоит - учитывай, что все 5000 джобов будут писаться в редис, то есть в оперативную память сервера. А с другой стороны... Если у тебя и так все нормально работает - зачем тебе редис? 5000 джобов это не так и много

В будущем хотим на rabbitmq перейти все равно... Хотя опятт таки. Спор у нас - для коммуникации межсервисной - раббит а внутри сервиса пускай локальное хранилище джоб

Ктото говорит что все джобы и все события убирать в раббит. что думаешь?

Та там по сути все тоже. Но если редис будет использоваться для кеша то для очередей я бы использовал раббит. Все от масштаба проекта и его роста зависит. В идеале отделить разные задачи на разные сервисы. Но если нет на это бюджетов и строков - тогда можно и нужно все лепить в одно😁

Основная проблема с дефолт очередями на ларе на бд, с которой я сталкивался - это дедлоки при увеличении потоков обработки (кроме общей нагрузки на бд, про что уже сказали). Хочется сделать обработку на бд - high likely упрешься

поэтому и существует большое количество альтернатив базам данных. реляционные базы все таки заточены не под очереди.

Очереди на базах нужно делать, когда транзакции нужны

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

Иногда нужно гарантировать «все или ничего» между записью в базу и созданием job. Проще всего это сделать, когда все записи проходят внутри транзакции. Иначе могут быть разные варианты. Запись в базу и создание job с гарантией от базы может быть в одной транзакции на одном коннекте.

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

С такими же гарантиями и без откатов по принципу Саги? А если еще при этом Шардинг и репликация есть и все это потом на разные тачки поедет, то наверняка другое решение будет удобным :)

Например, даже в простом кейсе - записали в базу, а джобу в редис записать не смогли, ибо редис сдох. Как обеспечим гарантию?

ну понятно что такие же гарантии как субд по транзакционности я не дам)))) но и такой уровень согласованности тоже крайне редкое явление (по шкале где слева "php для сайтов", посередине "ищу разработчика на фортране в 2023" а справа "крайне редкое явление") если вам нужны подобные гарантии так тут вокруг вашей задачи накручено будет столько что "кастомное транзакционное решение для увеличения производительности работы очередей" затеряется среди других прикольных архитектурных решений. а насиловать бд последнее дело

Ну на одном из проектов, есть несколько типов очередей. У каждого есть свои sla (в том числе по производительности), гарантии и ограничения. И дальше уже разработчик выбирает, что и как использовать. Крайности - почти всегда плохо.

будем считать что в данном диалоге вы предоставили более весомые аргументы. хоть мы и не спорили)))