Телеграмм чат группы scalability

14:40пожаловаться #1

N

Nikolay in Scalability Camp — чат про распределенные системы (и про HPC)

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

Zlata Obukhovskaya in Scalability Camp — чат про распределенные системы (и про HPC)

14:40пожаловаться #2

ZO

Nikolay

интересный вопрос. это наверное зависит от многих факторов. в том числе какая семантика доставки нас интересует. Например, если клиент был оффлайн. Должен ли он получить все ивенты, когда он вновь станет онлайн. А так же видится важным сколько таких клиентов и сколько каналов они слушают. Например если у нас подразумевается, что возможет 1миллион клиентов и 1 миллион каналов( которые условно топики), то решение одно, а если клиентов и топиков очень мало, то можно построить такое на другом наборе систем .

Я думаю, что устаревшие ивенты можно успешно фильтровать на фронте

Andrey Terekhov in Scalability Camp — чат про распределенные системы (и про HPC)

14:42пожаловаться #3

AT

Я думаю, что устаревшие ивенты можно успешно фильтровать на фронте

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

Andrey Terekhov in Scalability Camp — чат про распределенные системы (и про HPC)

14:44пожаловаться #4

AT

Вообще у меня был вопрос, что лучше использовать, чтобы апдейты в базе слать через вебсокеты на фронт?

а хочется совсем без софтовой прослойки, т.е. чтобы события из базы напрямую генерились?

Zlata Obukhovskaya in Scalability Camp — чат про распределенные системы (и про HPC)

14:45пожаловаться #5

ZO

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

Пока я не могу придумать кейса, где нужна exactly once доставка ивентов

Zlata Obukhovskaya in Scalability Camp — чат про распределенные системы (и про HPC)

14:45пожаловаться #6

ZO

а хочется совсем без софтовой прослойки, т.е. чтобы события из базы напрямую генерились?

На самом деле нет. Я могу отправлять эти ивенты в софтовую прослоку в том месте, где происходит запись в базу. Просто я хотела узнать, какие архитектурные решения для такого кейса существуют

Slach in Scalability Camp — чат про распределенные системы (и про HPC)

14:47пожаловаться #7

S

Пока я не могу придумать кейса, где нужна exactly once доставка ивентов

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

таким хранилищем может быть clickhouse

Andrey Terekhov in Scalability Camp — чат про распределенные системы (и про HPC)

14:53пожаловаться #8

AT

На самом деле нет. Я могу отправлять эти ивенты в софтовую прослоку в том месте, где происходит запись в базу. Просто я хотела узнать, какие архитектурные решения для такого кейса существуют

Ну я тогда присоединяюсь к вопросу, потому что хочется ответить что-то в общих чертах про очереди)
Типа берём событие, присваиваем ему тэги, шлём в шину, а дальше рассылаем по нужным очередям/комнатам/подпискам или всем подряд. Про rmq наверно особо смысла и нет говорить?

Oleg Sidorkin in Scalability Camp — чат про распределенные системы (и про HPC)

14:55пожаловаться #9

OS

Мы у себя прямо в базе держали очередь "эвентов" с растущей версией. Когда клиент приходил, он присылал свою версию, ему выгружались все "эвенты", (смёрдженные в один большой "эвент") с новой версией. Если очередь становилась слишком длинной, то считали, что проще выгрузить ему таблицу целиком, и удаляли очередь.

Alexey Prudnikov in Scalability Camp — чат про распределенные системы (и про HPC)

14:59пожаловаться #10

AP

именно! :)

Не пробовали Debezium?

https://debezium.io/documentation/reference/architecture.html

Судя по описанию архитектуры, как раз реализуется нужный кейс.

Сам давно присматриваюсь к этой штуке, но никак руки не доходят попробовать.

Zlata Obukhovskaya in Scalability Camp — чат про распределенные системы (и про HPC)

15:02пожаловаться #11

ZO

Ну я тогда присоединяюсь к вопросу, потому что хочется ответить что-то в общих чертах про очереди)
Типа берём событие, присваиваем ему тэги, шлём в шину, а дальше рассылаем по нужным очередям/комнатам/подпискам или всем подряд. Про rmq наверно особо смысла и нет говорить?

У этого похода есть минус. Когда логика записи в базу размазана по нескольких микросервисам (как у меня). А на фронте нужно получать поток ивентов, сэммитированных по сути несколькими микросервисами. И тут важна не только семантика доставки ивентов, но и консистентность данных. Сейчас я думаю, что time-bound eventual consistency подойдет, но продуктовые требования могут измениться в сторону ужесточения ограничений.

Zlata Obukhovskaya in Scalability Camp — чат про распределенные системы (и про HPC)

15:11пожаловаться #12

ZO

Подход с Debezium кажется подходит под продуктовые требования, но у меня тут вопрос, как у человека, отвечающего за управление технологическим стеком. А эта туловина она насколько распространена вообще и в каких кейсах?

D P in Scalability Camp — чат про распределенные системы (и про HPC)

15:13пожаловаться #13

DP

именно! :)

Можно написать плагин для репликации из PG. Можно взять wal2json и его вывод уже отправлять

Andrey Terekhov in Scalability Camp — чат про распределенные системы (и про HPC)

15:15пожаловаться #14

AT

У этого похода есть минус. Когда логика записи в базу размазана по нескольких микросервисам (как у меня). А на фронте нужно получать поток ивентов, сэммитированных по сути несколькими микросервисами. И тут важна не только семантика доставки ивентов, но и консистентность данных. Сейчас я думаю, что time-bound eventual consistency подойдет, но продуктовые требования могут измениться в сторону ужесточения ограничений.

Про микросервисы не было сказано, хотя это и ожидаемо)
Ну да, пониманию в чём проблема.
Субъективно по ощущениям нужен небольшой буфер, который как раз будет выстраивать все события в нужном порядке и разрешать конфликты.
Вариант с wal интересный, но если у микросервисов свои базы, и данные между ними зависимы, то всё равно наверно придётся их синхронизировать между собой, прежде чем отдавать на фронт

Zlata Obukhovskaya in Scalability Camp — чат про распределенные системы (и про HPC)

15:24пожаловаться #15

ZO

Про микросервисы не было сказано, хотя это и ожидаемо)
Ну да, пониманию в чём проблема.
Субъективно по ощущениям нужен небольшой буфер, который как раз будет выстраивать все события в нужном порядке и разрешать конфликты.
Вариант с wal интересный, но если у микросервисов свои базы, и данные между ними зависимы, то всё равно наверно придётся их синхронизировать между собой, прежде чем отдавать на фронт

У соседей есть решение с отправкой в кафка, а затем фильтрацией на прослойке, которая отдает по вэбсокетам. Синхронизацию ивентов они органиовать не могут (просто не готовы вбухать в это кучу времени), поэтому там eventual consistency. В их случае такой подход оправдан, потому что у них точек отправки этих ивентов в кафку ну вот прямо очень много.

Николай Хитров... in Scalability Camp — чат про распределенные системы (и про HPC)

15:29пожаловаться #16

НХ

У этого похода есть минус. Когда логика записи в базу размазана по нескольких микросервисам (как у меня). А на фронте нужно получать поток ивентов, сэммитированных по сути несколькими микросервисами. И тут важна не только семантика доставки ивентов, но и консистентность данных. Сейчас я думаю, что time-bound eventual consistency подойдет, но продуктовые требования могут измениться в сторону ужесточения ограничений.

можно сделать backend for frontend, который будет слушать все эти ивенты, агрегировать и дальше слать во фронт

Andrey Terekhov in Scalability Camp — чат про распределенные системы (и про HPC)

15:32пожаловаться #17

AT

Николай Хитров

можно сделать backend for frontend, который будет слушать все эти ивенты, агрегировать и дальше слать во фронт

ну вот прослойка я так понял это и делает

Николай Хитров... in Scalability Camp — чат про распределенные системы (и про HPC)

15:33пожаловаться #18

НХ

ну вот прослойка я так понял это и делает

не успел дочитать)
да, оно

Alexey Prudnikov in Scalability Camp — чат про распределенные системы (и про HPC)

15:33пожаловаться #19

AP

Подход с Debezium кажется подходит под продуктовые требования, но у меня тут вопрос, как у человека, отвечающего за управление технологическим стеком. А эта туловина она насколько распространена вообще и в каких кейсах?

У меня, к сожалению, тот же самый вопрос возникает - продукт достаточно молодой и информации по нему маловато. Знаю только, что за ним стоит Red Hat, то есть эта история не совсем на голом энтузиазме держится. Но конкретных внедрений ни сам пока не делал, ни у коллег не видел.