Yii Framework

Всем привет!

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

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

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

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

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

адекватное решение

Melodic писал(а): ↑2017.09.20, 13:09Но это не помогло, очередь начинает забиваться.

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

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

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

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

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

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

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

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

почему у нас одно событие оказывается в двух потоках?

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

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

а можно пример как реализуют optimistic lock в event sourcing ? Я это представляю как событие примерно такого содержания
и composite primary key по полям aggregate_id и version. Но может как-то по другому делают, вместо того чтобы хранить в каждом событии incremented_aggregate_version_number и current_aggregate_version_number.

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

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

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

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

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

Как быть?

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

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

А если до обработки события в оригинале что-то поменялось?

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

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

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

Это может привести к потере согласованности.

anton_z писал(а): ↑2017.11.13, 08:42 Это может привести к потере согласованности.

Она и так в очереди обновляется с задержкой. А для полной согласованности нужно хранить всё в payload.

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

Это понятно и называется Eventual Consistency. С дерганием consistency не будет вообще.