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

Question

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

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

Давайте рассмотрим рабочий процесс обработки заказов в Интернете.

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

Например:

порядок созданных событий может иметь тысячи событий и медленно обрабатываться потребитель. В порядке-удаленных-событий может быть только несколько записей в очереди, при условии, что только 5-10% отменит заказ.

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

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

Answer 1

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

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

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

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

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