Size: a a a

2020 April 12

VG

Vik Gamov in pro.kafka
humanoid
Ну и чо?
источник

VG

Vik Gamov in pro.kafka
Пиарить свою базу данных
источник

VG

Vik Gamov in pro.kafka
humanoid
источник

h

humanoid in pro.kafka
Vik Gamov
Ну и чо?
Я мало пока смыслю в кафке, но уже например без optimistic lock я не понимаю как сделать eventstore
источник

VG

Vik Gamov in pro.kafka
humanoid
Я мало пока смыслю в кафке, но уже например без optimistic lock я не понимаю как сделать eventstore
Да не нужны локи
источник

h

humanoid in pro.kafka
Vik Gamov
Да не нужны локи
А как обеспечить консистетность агрегата?
источник

VG

Vik Gamov in pro.kafka
humanoid
А как обеспечить консистетность агрегата?
В смысле?
источник

VG

Vik Gamov in pro.kafka
В кафку продюсер пишет в тот же пртишен из которого читает консьюмер
источник

h

humanoid in pro.kafka
Vik Gamov
В смысле?
Ну мы будет делать какие-то бизнес операции опираясь на старый стейт. И вот race condition
источник

h

humanoid in pro.kafka
Vik Gamov
В смысле?
Вообщем если не рассматривать kafka как ES event store, а только как брокера, то вариант с сохранением offset а основной базе норм?
источник

VG

Vik Gamov in pro.kafka
humanoid
Вообщем если не рассматривать kafka как ES event store, а только как брокера, то вариант с сохранением offset а основной базе норм?
Не совсем корректно мыслите, коллега. Kafka streams смотрел?
источник

h

humanoid in pro.kafka
Vik Gamov
Не совсем корректно мыслите, коллега. Kafka streams смотрел?
Да, я понимаю, там типа exactly_once в рамках кафки, прочитал - обработал - записал
источник

VG

Vik Gamov in pro.kafka
humanoid
Да, я понимаю, там типа exactly_once в рамках кафки, прочитал - обработал - записал
Вот и все
источник

VG

Vik Gamov in pro.kafka
Кафка будет хранить результаты агрегата в другом топике. Если народ всегда можно пересчитать из исходного топика
источник

VG

Vik Gamov in pro.kafka
Короче можно сделать и все будет ок
источник

VG

Vik Gamov in pro.kafka
https://www.confluent.io/blog/tag/event-sourcing/ рекомендую полазить тут. А я ушел в качалку
источник

h

humanoid in pro.kafka
Мб потом ответите)

Я приведу пример с optimistic lock.
Классический пример списание денег.
Подписчику приходит событие из кафки КулпенТовар(IDТовара, Сумма). Допустим мы берем проекцию аграгата/стрима/актора баланса клиента из кафки, смотрим на баланс и уменьшаем его, если не уйдет в минус. При конкрентном вычислении, оба потока обработчика получат один и тот же снапшот, кто то добавит в кафку ивент СписаноСБаланса первым, а второй все еще будет ориентироваться  на уже устаревший снапшот и будет lost update problem.
Я думаю вы прекрасно занаете эту проблему, я просто описал кейс для примера.
Как это разрешить, если сделать кафку ивент хранилишем для ивент сорсинга?
источник

h

humanoid in pro.kafka
Ссылочку почитаю, спасибо
источник

h

humanoid in pro.kafka
Vik Gamov
Да не нужны локи
Я так понимаю ответ может быть: делать один поток на один стрим/агрегат, получится однопоточная обработка, только в таком случае “ну нужны локи”
То есть по сути это будут пессимистичные локи на уровне обработчика
источник
2020 April 13

@

@Saint Java in pro.kafka
из-за чего может пропасть consumer группа с кластера?
источник