PD
20-30k mps rmq закроет
А как закроет? Он же нормально работает только без персистанса и на одном сервере, т.е. без гарантий.
Size: a a a
2020 November 24
PD
Pulsar много где уже стоит. Вопрос, что мерить много или мало. Kafka, конечно лучше раскручена.
Ну, я вот не нашел год назад ничего подробного про эксплуатацию пульсара, так что не рискнул в продакшен тащить. Тем более без платной поддержки с SLA )
LV
Платная поддержка вроде есть у них. Точнее летом 2019 была, а год назад эту контору купил splunk (кажется)
PD
Ну, splunk уже не очень..
Хм, посмотреть, что-ли, еще раз на pulsar. Но меня же юротдел закопает, если еще один элемент стека согласовывать )
Хм, посмотреть, что-ли, еще раз на pulsar. Но меня же юротдел закопает, если еще один элемент стека согласовывать )
PD
У меня просто любимый кейс - очень много (десятки-сотни миллионов) топиков с небольшим числом событий (0-100).
Ну и 10K MPS на все это.
Топики долгоживущие, гарантии нужны приличные (работа в кластере, лучше всего между ДЦ, персистанс и т.п.)
Кафка тут не живет нормально
Ну и 10K MPS на все это.
Топики долгоживущие, гарантии нужны приличные (работа в кластере, лучше всего между ДЦ, персистанс и т.п.)
Кафка тут не живет нормально
PD
А пульсар такое умеет, насколько я помню
PD
(ну или напишу свое решение на FDB...)
LV
20-30k mps rmq закроет
@dphil Да, надо бы перепроверить.
2020 November 25
N
Миллионы топиков выглядит подозрительным решением. Интересно , что за решаемая такая проблема , что нужно миллион топиков.
PD
Очередь событий на пользователя, очередь событий на активный платеж и т.п.
Да даже тривиальный server messaging при большом числе активных и полуактивных пользователей требует примерно такое число разных очередей.
Ну и всякие паттерны типа персистентных акторов, cadence с сигналами и т.п. требуют очень много независимых небольших очередей.
Да даже тривиальный server messaging при большом числе активных и полуактивных пользователей требует примерно такое число разных очередей.
Ну и всякие паттерны типа персистентных акторов, cadence с сигналами и т.п. требуют очень много независимых небольших очередей.
PD
Если можно не экономить очереди, то многие задачи с "конкурентностью" начинают выглядеть простыми (типа очередь на счет со всеми операциями, очередь на изменение состояния профиля и так далее)
PD
В решениях типа Cadence фактически есть очередь на каждую бизнес-операцию (например).
IA
Ironmq был такой saas
IA
Вспомнил
GK
Если можно не экономить очереди, то многие задачи с "конкурентностью" начинают выглядеть простыми (типа очередь на счет со всеми операциями, очередь на изменение состояния профиля и так далее)
На самом деле - отдельная очередь на каждый тип сообщения
PD
На самом деле - отдельная очередь на каждый тип сообщения
Неа. Так как мне важна последовательность изменений счета (порядок), а не "все рефанды идут подряд".
Т.е. очередь как инструмент сериализации (в смысле БД), а не как транспорт.
Т.е. очередь как инструмент сериализации (в смысле БД), а не как транспорт.
PD
А делать очередь "все изменения счетов" с одним воркером - слишком медленно. А с кучей воркеров - теряется смыл.
GK
Неа. Так как мне важна последовательность изменений счета (порядок), а не "все рефанды идут подряд".
Т.е. очередь как инструмент сериализации (в смысле БД), а не как транспорт.
Т.е. очередь как инструмент сериализации (в смысле БД), а не как транспорт.
То есть отдельные очереди для всех типов сообщений каждого инстанса агрегата
PD
То есть отдельные очереди для всех типов сообщений каждого инстанса агрегата
Нет, не по типам сообщений, а по изменяемым сущностям. По очереди на сущность - но с разными типами сообщений.
PD
Ну, когда ты в базе делаешь "select for update" - то получаешь очередь событий на изменение объекта.
Но она не умеет жить долго, например.
А тут примерно про то же, но эта очередь надежная и долгоиграющая.
Но она не умеет жить долго, например.
А тут примерно про то же, но эта очередь надежная и долгоиграющая.