Event Sourcing read model

Обсуждаем, как правильно строить приложения
Ответить
Melodic
Сообщения: 87
Зарегистрирован: 2016.05.11, 17:43
Откуда: Луганск

Event Sourcing read model

Сообщение Melodic » 2017.09.20, 13:09

Всем привет!

Есть проблема с обновлением read model'и.

Проблема в том, что события приходят из очереди в разном порядке. (т.к. команды из UI обрабатывает n-ое кол-во обработчиков в разном порядке)

Попытался решить эту проблему с помощью версии агрегата и если эта версия не совпадает с (версией read model'и+1) то возвращать сообщение в очередь. Но это не помогло, очередь начинает забиваться.

Кто нибудь сталкивался с этим?)

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: Event Sourcing read model

Сообщение zelenin » 2017.09.20, 13:32

Melodic писал(а):
2017.09.20, 13:09
Попытался решить эту проблему с помощью версии агрегата и если эта версия не совпадает с (версией read model'и+1) то возвращать сообщение в очередь
адекватное решение
Melodic писал(а):
2017.09.20, 13:09
Но это не помогло, очередь начинает забиваться.
больше консьюмеров ставь, чтобы не забивалась. либо один чтобы изначально по порядку шли события (если одного хватит).

тут собственно все советы на уровне логики.

а консьюмер что делает? собирает из событий состояние read model? без участия хранилища?

Melodic
Сообщения: 87
Зарегистрирован: 2016.05.11, 17:43
Откуда: Луганск

Re: Event Sourcing read model

Сообщение Melodic » 2017.09.20, 13:47

Из событий, без участия хранилища. Из rabbitmq все приходит.

Один консьюмер не подойдёт , событий много.

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: Event Sourcing read model

Сообщение zelenin » 2017.09.20, 14:19

тогда только увеличением консьюмеров. это проще чем городить огород.

sda
Сообщения: 331
Зарегистрирован: 2013.12.19, 09:29

Re: Event Sourcing read model

Сообщение sda » 2017.10.04, 12:32

Melodic, а как вы боретесь с проблемой конкурентного доступа к write model ? Два потока получили одно и то же состояние агрегата и теперь каждый из них пытается записать свое событие в event store. Если ничего не делать, то целостность данных будет нарушена. Как пример представьте что мы списываем средства со счета пользователя. Если это одновременно делается из двух потоков, то в event store уйдет два идентичных события. Что неверно. Как решаете?

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: Event Sourcing read model

Сообщение zelenin » 2017.10.04, 12:39

sda писал(а):
2017.10.04, 12:32
Как пример представьте что мы списываем средства со счета пользователя. Если это одновременно делается из двух потоков, то в event store уйдет два идентичных события.
почему у нас одно событие оказывается в двух потоках?

anton_z
Сообщения: 353
Зарегистрирован: 2017.01.15, 15:01

Re: Event Sourcing read model

Сообщение anton_z » 2017.10.04, 12:57

с этим можно бороться блокировками

Аватара пользователя
ElisDN
Сообщения: 5001
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: Event Sourcing read model

Сообщение ElisDN » 2017.10.04, 13:04

Боремся оптимистической блокировкой в транзакции.

sda
Сообщения: 331
Зарегистрирован: 2013.12.19, 09:29

Re: Event Sourcing read model

Сообщение sda » 2017.10.04, 13:41

а можно пример как реализуют optimistic lock в event sourcing ? Я это представляю как событие примерно такого содержания

Код: Выделить всё

{
  aggregate_id: uuid,
  aggregate_type: 'User',
  event: 'UserEmailChanged',
  payload: {
    email: '...',
    version: incremented_aggregate_version_number
  },
  version: current_aggregate_version_number
}
и composite primary key по полям aggregate_id и version. Но может как-то по другому делают, вместо того чтобы хранить в каждом событии incremented_aggregate_version_number и current_aggregate_version_number.

Melodic
Сообщения: 87
Зарегистрирован: 2016.05.11, 17:43
Откуда: Луганск

Re: Event Sourcing read model

Сообщение Melodic » 2017.10.24, 16:36

А как быть с "проекцией", которая не зависит от одного конкретного агрегата?

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

Стоит ли на каждый тип таблицы(виджета) в UI делать свою проекцию?

Melodic
Сообщения: 87
Зарегистрирован: 2016.05.11, 17:43
Откуда: Луганск

Re: Event Sourcing read model

Сообщение Melodic » 2017.11.11, 19:06

Перешёл полностью на EventSourcing.
Возникла проблема, когда не хватает данных из события для обновления read модели.
Читал, что просто расширяют событие, но это получается,что domain зависит от read? Да и смущают не нужные данные в событии (они не нужны для восстановления аггрегата)

А если дёргать при обновлении read model другую read model для получения нужной инфы, то получается зависим от другой read model, которая может быть устаревшей (не успела обновиться)

Как быть?

Аватара пользователя
ElisDN
Сообщения: 5001
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: Event Sourcing read model

Сообщение ElisDN » 2017.11.11, 23:28

Дёргайте оригинальную domain model для обновления read model, если не хватает данных в payload.

anton_z
Сообщения: 353
Зарегистрирован: 2017.01.15, 15:01

Re: Event Sourcing read model

Сообщение anton_z » 2017.11.13, 08:36

ElisDN писал(а):
2017.11.11, 23:28
Дёргайте оригинальную domain model для обновления read model, если не хватает данных в payload.
А если до обработки события в оригинале что-то поменялось?

По мне - либо дергать конретную версию агрегата (если она известна в событии и есть возможность ее получить, и то непонятно что с удалением), либо модифицировать событие.
Последний раз редактировалось anton_z 2017.11.13, 08:41, всего редактировалось 1 раз.

Аватара пользователя
ElisDN
Сообщения: 5001
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: Event Sourcing read model

Сообщение ElisDN » 2017.11.13, 08:41

Тогда read model станет свежее.

anton_z
Сообщения: 353
Зарегистрирован: 2017.01.15, 15:01

Re: Event Sourcing read model

Сообщение anton_z » 2017.11.13, 08:42

ElisDN писал(а):
2017.11.13, 08:41
Тогда read model станет свежее.
Это может привести к потере согласованности.

Аватара пользователя
ElisDN
Сообщения: 5001
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: Event Sourcing read model

Сообщение ElisDN » 2017.11.13, 10:16

anton_z писал(а):
2017.11.13, 08:42
Это может привести к потере согласованности.
Она и так в очереди обновляется с задержкой. А для полной согласованности нужно хранить всё в payload.

anton_z
Сообщения: 353
Зарегистрирован: 2017.01.15, 15:01

Re: Event Sourcing read model

Сообщение anton_z » 2017.11.13, 11:04

ElisDN писал(а):
2017.11.13, 10:16
Она и так в очереди обновляется с задержкой. А для полной согласованности нужно хранить всё в payload.
Это понятно и называется Eventual Consistency. С дерганием consistency не будет вообще.

Ответить