Какова цель обмена сообщениями Kafka на основе пар ключ / значение? [закрыто]

Все примеры из Кафки | производители показывают ProducerRecordпару ключ / значение не только как один и тот же тип (все примеры показывают <String,String>), но и как одно и то же значение . Например:

producer.send(new ProducerRecord<String, String>("someTopic", Integer.toString(i), Integer.toString(i)));

Но в документации Kafka я не могу найти, где объясняется концепция ключ / значение (и ее основная цель / полезность). В традиционном обмене сообщениями (ActiveMQ, RabbitMQ и т. Д.) Я всегда запускал сообщение в определенной теме / очереди / обмене. Но Kafka - первый брокер, которому, похоже, требуются пары ключ / значение, а не просто обычное строковое сообщение.

Итак, я спрашиваю: какова цель / полезность требования от производителей присылать пары KV?

Kafka использует абстракцию распределенного журнала , состоящего из разделов . Разделение журнала на разделы позволяет масштабировать систему.

Ключи используются для определения раздела в журнале, к которому добавляется сообщение. В то время как значение - это фактическая полезная нагрузка сообщения. Примеры на самом деле не очень "хорошие" в этом отношении; обычно у вас будет сложный тип в качестве значения (например, тип кортежа, JSON или аналогичный), и вы извлечете одно поле в качестве ключа.

См .: http://kafka.apache.org/intro#intro_topics и http://kafka.apache.org/intro#intro_producers

В общем, ключ и / или значение nullтоже могут быть . Если ключ является nullслучайным, будет выбран раздел. Если задано значение, nullоно может иметь специальную семантику «удаления» в случае, если вы включите сжатие журналов вместо политики сохранения журналов для темы ( http://kafka.apache.org/documentation#compaction ).

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

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

Еще один интересный вариант использования

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

Мне еще предстоит выяснить, возможно это или нет. Я буду продолжать обновлять свой ответ с более подробной информацией.