Яка мета обміну повідомленнями на основі пари / ключа Кафки? [зачинено]

Всі приклади з Кафки | виробники показують 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_id, а потім підключити споживача для отримання потокових подій (подій, що зберігаються в атрибутах значення). Це може дозволити вам обробляти будь-яку максимальну історію послідовностей подій користувача для створення функцій у ваших моделях машинного навчання.

Мені ще потрібно з’ясувати, чи можливо це чи ні. Постійно оновлюватиму мою відповідь з подальшими деталями.