Как вы обеспечиваете применение событий для чтения модели?

Question

Это легко для проекций, которые подписываются на все события из потока, вы просто сохраняете версию последнего события, примененную к вашей модели чтения.Но что вы делаете, когда проекция составлена ​​из нескольких потоков?У вас есть версия каждого потока, который участвует в проекции.Но тогда как насчет пробелов, если вы не подписаны на все события?Самое большее, вы можете утверждать, что версия больше последней.Как другие справляются с этим?Вы отвечаете на каждое событие и повышаете версию (и)?

Answer 1

Для EventStore я бы предложил использовать поток $all в качестве потока по умолчанию для любой подписки модели чтения.

Я использовал поток категорий, который по сути создает моментальный снимок данного типа сущности, но я перестал это делать, поскольку модели чтения служат для другой цели.

Может быть нежелательно использовать поток $all, поскольку он также может получать события, которые не являются событиями домена. Интеграционные события могут быть примером. В этом случае добавление некоторых атрибутов либо в контракты событий, либо в метаданные может помочь создать внутреннюю (JS) проекцию, которая создаст специальный поток all для событий домена, или любую категорию событий в этом отношении, где вы можете подписаться на. Вы также можете использовать отрицательное условие, например, отфильтровывать все системные события и события с исходным именем потока, начинающимся с Integration.

Answer 2

Помимо обработки сообщений в правильном порядке, у вас также есть проблема возобновления проекции после ее перезапуска - как вы гарантируете, что начинаете с правильного места при перезапуске?

Самый простой вариант - использовать хранилище событий или брокер сообщений, который одновременно гарантирует порядок и предоставляет какое-то глобальное поле позиции потока (такое как глобальный номер события или упорядоченная временная метка с компонентом устранения неоднозначности, таким как тип временной метки MongoDB). Хранилища событий, куда вы извлекаете события непосредственно из хранилища (например, eventstore.org или доморощенные, созданные на основе базы данных), как правило, гарантируют это. Кроме того, некоторые брокеры сообщений, такие как Apache Kafka, гарантируют порядок (опять же, это основано на запросах). Вы хотите заказать доставку хотя бы один раз, в идеале.

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

Если у вас нет этих гарантий заказа, доставки и размещения, ваша жизнь намного сложнее, и может быть трудно сделать систему полностью надежной. Вы можете:

• Удерживайте сообщения на некоторое время после их получения, прежде чем обрабатывать их, чтобы позволить другим приходить
• Наличие кода для обнаружения пропущенных или вышедших из строя сообщений. Как вы упомянули, это работает только в том случае, если вы получаете все события с глобальным порядковым номером или если вы отслеживаете все номера версий потоков, и даже тогда это не надежно во всех случаях.

Answer 3

Для каждого отдельного потока вы держите вещи в порядке, выбирая их из хранилища данных, которое знает правильный порядок.Если подумать об этом, то вы запросите хранилище данных, и вы получите Document Message back.

. Это может помочь просмотреть данные Polyglot Грега Янга talk.

Что касается синхронизации событий в нескольких потоках;нужно признать, что события в разных потоках по своей сути параллельны.

Вы можете получить некоторую слабую координацию между разными потоками, если у вас есть happens-before данные, закодированные в ваших сообщениях.«Событие B произошло в ответ на Событие A, следовательно, A произошло до B».Это дает вам частичное упорядочение.

Если вам действительно нужно полное упорядочение всего и везде, то вам нужно будет рассмотреть такие паттерны, как Часы Лампорта .