J Oliver EventStore V2.0 вопросы

Question

Я приступаю к реализации проекта с использованием CQRS и намереваюсь использовать J Oliver EventStore V2.0 в качестве механизма сохранения событий.

1) В документации, ExampleUsage.cs использует 3 сериализатора в «BuildSerializer». Я полагаю, это просто для демонстрации гибкости процесса десериализации?

2) В случае «Перезапуск после сбоя», когда некоторые события не отправлялись, я считаю, что мне нужен код запуска, который вызывает GetUndispatchedCommits () и затем отправляет их, правильно?

3) Опять же, в «ExampleUseage.cs» было бы полезно, если бы «TakeSnapshot» добавил третье событие в хранилище событий, а затем «LoadFromSnapShotForward» не только извлекло самый последний снимок, но и извлекло события, которые были опубликованы после снимка для имитации перестройка агрегата.

4) Я не вижу возможности сохранения старых снимков. Можете ли вы привести пример использования, где они будут полезны?

5) Если у меня есть служба, которая обрабатывает получение команд и генерацию событий, какова предлагаемая стратегия для отслеживания количества событий с момента последнего снимка для данного агрегата. Я, конечно, не хочу слишком часто вызывать «GetStreamsToSnapshot».

6) В пространстве имен SqlPersistence.SqlDialects имя оператора sql называется «GetStreamsRequiringSnaphots», а не «GetStreamsRequiringSnapShots»

Answer 1

1) Есть несколько «базовых» сериализаторов - таких как Binary, JSON и BSON. Два других примера - сериализаторы GZip / Compression и Encryption являются упаковочными сериализаторами и предназначены только для изменения того, что уже было сериализовано, в поток байтов. Для примера я просто показываю гибкость. Вам не нужно шифровать, если вы не хотите. На самом деле, у меня есть работающий продукт, использующий простой JSON, который делает отладку очень простой, потому что все текстовое.

2) Обе реализации SynchronousDispatcher и AsychronousDispatcher сконфигурированы для запроса и поиска любых неотправленных коммитов. Тебе не нужно делать ничего особенного.

3) Грег Янг рассказал о том, как он «встроил» свои снимки в поток основных событий, но в высокопроизводительных системах возник ряд оптимистичных условий параллелизма и гонки. Поэтому он решил переместить их «вне группы». Я следовал этому решению по многим тем же причинам.

Кроме того, моментальные снимки действительно важны для производительности, если у вас чрезвычайно низкий SLA. Если у вас есть поток с несколькими тысячами событий и у вас нет низкого SLA, почему бы просто не взять минимальный удар по производительности вместо того, чтобы добавить дополнительную сложность в вашу систему. Другими словами, снимки являются «вспомогательными» понятиями. Они находятся в API EventStore, но являются необязательной концепцией, которую следует учитывать для определенных случаев использования.

4) Предположим, у вас была совокупность с десятками миллионов событий, и вы хотели запустить сценарий «что, если» перед самым последним снимком. Намного дешевле перейти от другого снимка вперед. Действительно хорошая вещь в том, что снимки являются вторичной концепцией, заключается в том, что если вы хотите удалить старые снимки, вы можете, и это никак не повлияет на вашу систему.

5) В каждой реализации IPersistStreams есть метод, называемый GetStreamsRequiringSnapshots. Вы предоставляете порог 50, например, который находит все потоки, имеющие 50 или более событий с момента их последнего снимка. Это может (и, вероятно, должно) быть сделано асинхронно из вашей обычной обработки.

6) «Снимки» - это правильный регистр для этого слова. Во многом как «сайт» раньше был «веб-сайт», но из-за общего использования он стал «сайт».