Архитектура, управляемая событиями - темы / Stream Design

Question

Это может быть вопрос о передовой практике. Кто-нибудь, кто работал над этим, поясните примеры. Чтобы всем нам было на пользу!

Для событийно-ориентированных архитектур с Kafka / Redis, когда мы создаем темы / потоки для событий, каковы все лучшие практики, которым следует следовать.

Рассмотрим рабочий процесс обработки онлайн-заказов.

Я читал несколько блогов, в которых говорилось, что создают темы / потоки вроде order-created-events, order-deleted-events и т.д. Но мой вопрос в том, как гарантировать порядок сообщений, когда мы разбиваем их на несколько тем.

Например:

order-created-events может иметь тысячи событий и медленно обрабатываться потребителем. order-deleted-events может иметь только несколько записей в очереди, предполагая, что только 5-10% отменит заказ.

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

Надеюсь, мой вопрос ясен. Итак, как придумать дизайн тем / потоков?

Answer 1

Kafka обеспечивает последовательность только для определенного раздела.

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

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

Таким образом, независимо от того, создается, обновляется или удаляется Порядок A, они всегда должны принадлежать одному разделу.

Чтобы правильно добиться последовательности, это должно быть основой для выбора тем, а не 2 разных тем для разных занятий.