Как спроектировать Kafka Produce (раздел), чтобы гарантировать этот частичный порядок при потреблении?

Question

Вот мой случай:

Система создает сообщения для одной топи c, и существует два вида сообщений:

A. сообщения новых пользователей

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

помечено как: U1, U2, ... Un.

B. сообщения об изменении метаданных атрибута пользователя

Например: пользователь имеет два атрибута name, email, затем добавил пользовательский атрибут profile.

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

помечается как: M

Когда мы используем этот топи c, нам нужно гарантировать частичные заказы:

• Данные того же пользователя должны соответствовать его порядку.

• потребление изменения метаданных должно всегда: до использования сообщения пользовательских данных после этого изменения, после сообщения пользовательских данных до этого изменения.

Пример:

естественный порядок сообщения:

(0: U1) -> (1: U2) -> (2: U1) -> (3: У3) -> (4: U1) -> (5: М) -> (6: U1) -> (7: U2) -> (8: U2) -> (9: М) -> (10: U1 )

принятый заказ потребления:

(0: U1) -> (2: U1) -> (3: U3) -> (1: U2) -> (4: U1) -> (5: M) -> (7: U2) -> (6: U1) -> ...

Вопрос

Если в нем нет M, я могу помещать разные пользовательские данные в разные разделы, чтобы увеличить их, но учтите наличие требования заказа M, могу ли я сделать другой раздел для этой топи c?

Answer 1

Вы можете использовать любой вид идентификатора пользователя (должен быть равен «сообщениям новых пользователей» и «сообщениям об изменении метаданных атрибутов пользователя» того же пользователя и в то же время уникальным для конкретного пользователя) в качестве ключа Kafka сообщение. Таким образом, данные будут разбиты на разделы на основе идентификатора пользователя, и вы гарантируете, что данные одного пользователя будут go в одном разделе, сохраняя порядок. Таким образом, вы можете масштабировать с несколькими разделами.

При создании сообщений для topi c, убедитесь, что синхронно производите данные, например, дождитесь получения первого сообщения перед отправкой второго.