Re[2]: Eventual consistency
От: takTak  
Дата: 09.07.18 18:23
Оценка: 4 (1)
SM>имеется между разными данными в одной БД, а у меня проблема более общая — та которая в CAP-теореме — нестыковка между ответами разных узлов при чтении одних и тех же данных.
SM>И вот из-за нее все эти подходы обламываются. К примеру, клиент делает поллинг сервера и находит что добавляемые данные прочитались. Он довольный продолжает работу, снова запрашивает эти данные — но теперь запрос попадает на другой шард, там этих данных пока еще нет и получается что рано было радоваться.


ничего не понимаю...

как не работает? всё работает: следи за пальцами:
клиент делает запись А с Id = "c6e45efb-2908-45a3-bfa9-a58f6b9822fb", асинхронно команда на создание записи А попадает на какой-то сервер, на этом сервере сидит command handler, который сохраняет запись А в агрегате (Entry in EventStore) , в котором по факту сохранения происходит raise entryCreatedEvent/ message.Send(entryCreatedMessage) , все твои дб-сервера подписаны на это событие и обрабатывают асинхронно создание записи А и по прошествии обработки в свою очередь делают entryHasBeenSavedEvent, причём где-то там у тебя находится event / message handler, который считает для каждой записи A с Id = "c6e45efb-2908-45a3-bfa9-a58f6b9822fb" до трёх или пяти entryHasBeenSavedEvent's или сколько у тебя там разных инстанций базы, и после того, как это число достигнуто, обновляет список твоего изначального или всех клиентов через веб сокет

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

все остальные клиенты могут увидеть запись А только после того, как она будет сохранена в той базе, к которой они непосредственно обращаются

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

отказоустойчивой всё делается политикой повторения событий/ сообщения: если какой-то comannd / event handler не смог сохранить запись в своей базе, он из своей собственной очереди снова получит то же самое сообщение, которое он не смог обработать 5 или 105 раз в зависимости от конфигурации
Отредактировано 09.07.2018 18:29 takTak . Предыдущая версия . Еще …
Отредактировано 09.07.2018 18:25 takTak . Предыдущая версия .
Отредактировано 09.07.2018 18:23 takTak . Предыдущая версия .
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.