заказ через перегородки в кафке

Question

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

Могут быть два типа событий, которые я получу в качестве входных данных, и на основании этого я добавлю их в Kafka.

1. События, связанные с пользователями.
2. События, связанные с группами.

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

Кроме того, я хочу поддерживать порядок на основе времени.

Если я создаю разделение на уровне пользователя, массовое обновление будет невозможно на стороне потребителя.

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

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

Answer 1

Из документации kafka: https://kafka.apache.org/documentation/#intro_consumers

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

, так что вы можете сделать лучшеедолжен иметь один раздел - одну тему.

Answer 2

Кроме того, я хочу поддерживать порядок на основе времени.

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

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

Если я создаю разделение на уровне пользователя, массовое обновление будет невозможно на стороне потребителя.

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

Звучит как очень простая схема обмена сообщениями, когда у вас есть одна очередь (на самом деле она поддерживается одной темой с одним разделом), которая используется несколькими пользователями. На самом деле любой технологии обмена сообщениями в пабах здесь будет достаточно (например, обмен фанатами RabbitMQ).

Сообщения в очереди содержат информацию, являются ли они group updates или user updates - потребители затем фильтруют входные данные в зависимости от того, что их интересует.

Для обсуждения альтернативы: одна очередь для group updates, а другая для user updates - я понимаю, что этого будет недостаточно из-за требований заказа - можно получить group update независимо от user update, ломая заказ.