Телеграмм чат группы itarchitect страница 3462

Нет, не по типам сообщений, а по изменяемым сущностям. По очереди на сущность - но с разными типами сообщений.

Спорно

00:42пожаловаться #1

PD

Спорно в чем?
Персистентные акторы - так и работают.
Cadence - так и работает.
Да даже какой-нибудь centrifugo примерно так и работает

00:43пожаловаться #2

GK

Подписываться как? Получается, клиенты должны подписываться на изменения всех сущностей?

00:43пожаловаться #3

PD

В смысле "подписываться", это же не про pub-sub, а про queue

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

VN

V N in Архитектура ИТ-решений

Нет, не по типам сообщений, а по изменяемым сущностям. По очереди на сущность - но с разными типами сообщений.

Но если я правильно понял, то здесь же тоже есть потенциальная проблема, когда сущности взаимоизменяют состояния друг друга...

00:44пожаловаться #5

GK

Спорно в том, что явно не всем клиентам нужны все изменения (разные типы сообщений) сущности

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

PD

V N

Но если я правильно понял, то здесь же тоже есть потенциальная проблема, когда сущности взаимоизменяют состояния друг друга...

Ну, они не изменяют, они отправляют события в чужую очередь (как в акторных моделях).
Хотя обычно хватает оркестрации, где один flow отправляет эти события всем, кому нужно.

00:45пожаловаться #7

GK

Ну, они не изменяют, они отправляют события в чужую очередь (как в акторных моделях).
Хотя обычно хватает оркестрации, где один flow отправляет эти события всем, кому нужно.

Ну не в очередь, а в инбокс. Это разные вещи

00:46пожаловаться #8

PD

Спорно в том, что явно не всем клиентам нужны все изменения (разные типы сообщений) сущности

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

00:46пожаловаться #9

PD

Ну не в очередь, а в инбокс. Это разные вещи

Ээ, а что такое инбокс, как не queue?

00:46пожаловаться #10

GK

Ээ, а что такое инбокс, как не queue?

Да что угодно. Таблица в базе. Очередь - один из вариантов.

00:46пожаловаться #11

PD

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

00:47пожаловаться #12

PD

Да что угодно. Таблица в базе. Очередь - один из вариантов.

Это упорядоченный список с доступом через FIFO. Т.е. очередь )

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

GK

Это упорядоченный список с доступом через FIFO. Т.е. очередь )

Ваще ты прав)

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

PD

Так у меня первое решение и сделано на таблицах в базе. Но оно медленное, выше 2K MPS на дешевом железе не прыгнуть и масштабируется фигово. На FDB можно сделать с горизонтальным масштабированием, но очень не хочется тратить время, а лучше бы взять готовое )

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

N

Nikolay in Архитектура ИТ-решений

Таблица в базе - это все же не очередь.

00:51пожаловаться #16

GK

Так у меня первое решение и сделано на таблицах в базе. Но оно медленное, выше 2K MPS на дешевом железе не прыгнуть и масштабируется фигово. На FDB можно сделать с горизонтальным масштабированием, но очень не хочется тратить время, а лучше бы взять готовое )

Да это понятно. Я хотел подчеркнуть, что в реализации Inbox могут быть альтернативы)

00:51пожаловаться #17

PD

Nikolay

Таблица в базе - это все же не очередь.

Если к ней доступ только через FIFO (не важно, как реализован, есть много вариантов) - то очередь.

00:51пожаловаться #18

GK

Если к ней доступ только через FIFO (не важно, как реализован, есть много вариантов) - то очередь.

+

00:52пожаловаться #19

PD

Да это понятно. Я хотел подчеркнуть, что в реализации Inbox могут быть альтернативы)

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