EventStore Конкурирующие потребительские заказы

Question

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

Сначала я предполагал, что япотребуется обеспечить порядок, но это требование зависит от сообщения.В случае оформления покупок в корзине, где я хочу узнать итоги, я могу добавить итоги независимо от порядка - получить сообщение, обновить базу данных SQL и подтвердить сообщение.

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

Мои вопросы, с которыми мне нужна помощь, пожалуйста:

1. Какой тип сообщений должен быть важен при заказе, иКак это можно решить, используя сообщения «как есть»?

2. Как узнать, от какого события следует подписаться, когда процессы присоединяются / уходят? Я вижу возможные проблемы с синхронизацией, которые могут вызвать подписку.быть запрошенным в сообщении, которое было только что обработано другим процессом?

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

Answer 1

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

• Добавить элемент
• Обновить количество элементов
• Удалить элемент

У вас могут быть последовательности типа A: «Добавить элемент, удалить элемент» или B: «Добавить элемент, Обновить количество элементов (до 2), Обновить количество элементов (до 3)».Для A, если вы обрабатываете удаление до добавления, очевидно, у вас проблемы.Для B, если вы обработаете два числа элементов обновления не по порядку, вы получите неправильный конечный счет.

Обычно это масштабируется с использованием некоторой схемы шардирования, где подмножество всех агрегатоввыделяются для каждого осколка.Я полагаю, что для Event Store это можно сделать, создав пользовательскую проекцию с использованием partitionBy, чтобы разделить поток на несколько потоков (также называемых «осколками»).Затем вам нужно каким-то образом выделить разделы / сегменты для обработки узлов.Некоторые технологии построены вокруг этого подхода к горизонтальному масштабированию (на ум приходят Kafka и Kinesis).