Jaki jest cel przesyłania wiadomości opartych na parach klucz / wartość w Kafce? [Zamknięte]

Wszystkie przykłady z Kafki | producenci pokazują, że ProducerRecordpara klucz / wartość nie tylko jest tego samego typu (wszystkie przykłady pokazują <String,String>), ale ma tę samą wartość . Na przykład:

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

Ale w dokumentach Kafka nie mogę znaleźć miejsca, w którym wyjaśniono koncepcję klucz / wartość (i jej podstawowy cel / użyteczność). W tradycyjnych wiadomościach (ActiveMQ, RabbitMQ, itp.) Zawsze wysyłałem wiadomość na określony temat / kolejkę / wymianę. Ale Kafka jest pierwszym brokerem, który wydaje się wymagać par klucz / wartość zamiast zwykłej wiadomości tekstowej.

Więc pytam: jaki jest cel / przydatność wymagania od producentów wysyłania par KV?

Kafka używa abstrakcji rozproszonego dziennika składającego się z partycji . Podział logu na partycje pozwala na skalowanie systemu.

Klucze służą do określenia partycji w dzienniku, do której dołączany jest komunikat. Chociaż wartość jest rzeczywistą zawartością wiadomości. Pod tym względem przykłady w rzeczywistości nie są zbyt „dobre”; zwykle jako wartość miałbyś typ złożony (taki jak typ krotki, JSON lub podobny) i wyodrębniałeś jedno pole jako klucz.

Zobacz: http://kafka.apache.org/intro#intro_topics i http://kafka.apache.org/intro#intro_producers

Ogólnie klucz i / lub wartość mogą być nullrównież. Jeśli klucz jest nulllosową partycją, zostanie wybrana. Jeśli wartość jest równa null, może mieć specjalną semantykę „usuń” w przypadku włączenia kompaktowania dziennika zamiast zasad przechowywania dziennika dla tematu ( http://kafka.apache.org/documentation#compaction ).

Późne dodawanie ... Określenie klucza tak, aby wszystkie komunikaty z tego samego klucza trafiały do ​​tej samej partycji, jest bardzo ważne dla prawidłowego uporządkowania przetwarzania komunikatów, jeśli w grupie odbiorców będzie wielu odbiorców na dany temat.

Bez klucza dwie wiadomości na tym samym kluczu mogłyby trafić do różnych partycji i zostać przetworzone przez różnych odbiorców w grupie poza kolejnością.

Kolejny interesujący przypadek użycia

Moglibyśmy użyć atrybutu klucza w tematach Kafki do wysyłania user_ids, a następnie możemy podłączyć konsumenta do pobierania zdarzeń przesyłania strumieniowego (zdarzeń przechowywanych w atrybutach wartości). Może to umożliwić przetwarzanie dowolnej maksymalnej historii sekwencji zdarzeń użytkownika w celu tworzenia funkcji w modelach uczenia maszynowego.

Nadal muszę się dowiedzieć, czy jest to możliwe, czy nie. Będzie aktualizować moją odpowiedź o dalsze szczegóły.