YV
по постгресу почитаю, спасибо
есть подход мультиплексирования запросов. Под mysql тоже что-то было на этот счет
Size: a a a
2021 February 10
w
тогда узким место становится связь с этим "кто-то другой"
непонятно что нужно сделать. но как упоминалось раньше "кто-то другой" класть данные в базу или выполнять какие-то действия
YV
но суть в том, что для кролика можно это реализовать самому
YV
я привел пример про mysql для "keywords for google". можно создать промежуточный слой, который будет держать коннекты с кролликом постоянно (это может быть как php в формате всяких RR, так и что-то другое, например демон на go)
S
Всем привет. Скажите, кто сталкивался с проблемой, как решали. Работа c rabbitmq. Проблема - постоянный коннект к нему в php (так как у нас php родился и умер на каждый запрос). Сейчас это - 10к-15к запросов в минуту. Консьюмеры понятно - поднялись и держать коннект. А вот с отправкой сообщений - беда.
w
но суть в том, что для кролика можно это реализовать самому
имел в виду другой язык использовать на котором проще реализовать демона. ну или как вариант запускать консьюмера с нужной периодичностью и считывать сообщения
MG
С консьюмерами проблем нет. Есть проблема с отправкой сообщения.
MG
В пакете ничего не нашел
BD
С консьюмерами проблем нет. Есть проблема с отправкой сообщения.
Можешь попробовать использовать редис для транзита сообщений в mq
M
на одном из проектов использовали подход когда сообщения не сразу слали в Rabbit, а предварительно сообщения писались в БД, а от туда уже вычитывались и отправлялись в Rabbit.
Плюсы решения будет:
- возможность "отправки" сообщения обернуть в транзакию, тем самым сделав гарантию отправки в Rabbit. Не будет ложных или потерянных сообщений в rabbit'е
- отправка происходит ассинхронно, проще масштабировать, уходит проблем коннекта на каждый запрос
Минусы:
- доп задержка перед попаданием сообщения в rabbit
Плюсы решения будет:
- возможность "отправки" сообщения обернуть в транзакию, тем самым сделав гарантию отправки в Rabbit. Не будет ложных или потерянных сообщений в rabbit'е
- отправка происходит ассинхронно, проще масштабировать, уходит проблем коннекта на каждый запрос
Минусы:
- доп задержка перед попаданием сообщения в rabbit
BD
Можешь попробовать использовать редис для транзита сообщений в mq
Но тогда уже и саму очередь на редисе можно сделать.
M
в целом стандартный подход, как со всем, что можно сделать ассинхроно: отправки писем, сообщений, расчет статистики и тп
AT
на одном из проектов использовали подход когда сообщения не сразу слали в Rabbit, а предварительно сообщения писались в БД, а от туда уже вычитывались и отправлялись в Rabbit.
Плюсы решения будет:
- возможность "отправки" сообщения обернуть в транзакию, тем самым сделав гарантию отправки в Rabbit. Не будет ложных или потерянных сообщений в rabbit'е
- отправка происходит ассинхронно, проще масштабировать, уходит проблем коннекта на каждый запрос
Минусы:
- доп задержка перед попаданием сообщения в rabbit
Плюсы решения будет:
- возможность "отправки" сообщения обернуть в транзакию, тем самым сделав гарантию отправки в Rabbit. Не будет ложных или потерянных сообщений в rabbit'е
- отправка происходит ассинхронно, проще масштабировать, уходит проблем коннекта на каждый запрос
Минусы:
- доп задержка перед попаданием сообщения в rabbit
О! Вот чтобы такие костыли не делать мы и сделали SDK для temporal.io
M
ну я бы не назвал такие вещи костылями, это скорей архитектурное решение. Но если есть инструменты предназначенные упростить эту часть, то круто
MG
Проблема в том, что реббит и является тем местом, которое поможет с ассинхронностью. И вот оно падает. Да, можно через базу. Можно сразу из базы читать, если кончьюмеры в этом же сервисе
MG
А редис мы сразу заюзали - и он умер
MG
Так что, не вытягивал
AT
ну я бы не назвал такие вещи костылями, это скорей архитектурное решение. Но если есть инструменты предназначенные упростить эту часть, то круто
пока просто то да, но когда начинаешь думать о at-most-once, ретрайях, таймаутах то решение превращается в трудноподдерживаемого монстра
w
Всем привет. Скажите, кто сталкивался с проблемой, как решали. Работа c rabbitmq. Проблема - постоянный коннект к нему в php (так как у нас php родился и умер на каждый запрос). Сейчас это - 10к-15к запросов в минуту. Консьюмеры понятно - поднялись и держать коннект. А вот с отправкой сообщений - беда.
так а кто тогда отправляет сообщения если пхп умер?
MG
Умер пхп - когда закончил обработку запроса. В обработку запроса - входит так же отправка сообщения в реббит