Przesunięcia przechowywane w Zookeeperze lub Kafce?

Question

Jestem nieco zdezorientowany tym, gdzie są zachowane przesunięcia podczas używania Kafki i Zookeepera. Wygląda na to, że przesunięcia w niektórych przypadkach są przechowywane w Zookeeperze, w innych przypadkach są przechowywane w Kafce.

Co decyduje o tym, czy przesunięcie jest przechowywane w Kafce czy w Zookeeperze? A jakie są plusy i minusy?

NB: Oczywiście, mógłbym również zapisać przesunięcie w moim własnym miejscu w jakimś innym magazynie danych, ale to nie jest częścią obrazu tego postu.

Nieco więcej szczegółów na temat mojej konfiguracji:

• uruchomić te wersje: KAFKA_VERSION = "0.10.1.0" SCALA_VERSION = "2.11"
• podłączyć do Kafka/Heca użyciu Kafka-węzeł z moim Aplikacja NodeJS.

Answer 1

Starsze wersje Kafki (fabrycznie 0,9) Przesunięcia magazynowe w ZK tylko, gdy nowsza wersja Kafki, przez magazynu domyślnego offsetu w wewnętrznym temacie Kafka nazywa __consumer_offsets (nowsza wersja nadal może zobowiązać się do ZK chociaż).

Zaletą oddania offsetów brokerowi jest to, że konsument nie zależy od ZK, a zatem klienci muszą jedynie rozmawiać z brokerami, co upraszcza ogólną architekturę. Ponadto, w przypadku dużych wdrożeń z dużą ilością konsumentów, ZK może stać się wąskim gardłem, podczas gdy Kafka może z łatwością poradzić sobie z tym ładunkiem (popełnianie offsetu to to samo, co pisanie do tematu, a Kafka bardzo dobrze tutaj się skaluje - w rzeczywistości domyślnie __consumer_offsets jest utworzony z 50 partycji IIRC).

Nie jestem zaznajomiony z NodeJS lub węzłem kafka - zależy to od implementacji klienta, w jaki sposób dokonywane są korekty.

Krótka historia: jeśli używasz brokerów 0.10.1.0, możesz zatwierdzić przesunięcia do tematu __consumer_offsets. Ale to zależy od twojego klienta, jeśli implementuje ten protokół.

Bardziej szczegółowo, zależy to od wersji brokera i klienta (i używanego interfejsu API klienta), ponieważ starsi klienci mogą rozmawiać z nowszymi brokerami. Po pierwsze, musisz mieć wersję brokera i klienta o numerze 0.9 lub większą, aby móc pisać korekty w tematach Kafki. Ale jeśli starszy klient łączy się z brokerem 0.9, nadal będzie zatwierdzał przesunięcia do ZK.

Dla konsumentów Java:

To zależy od tego, co konsument korzysta: Przed 0.9 istnieją dwa „stare konsument” a mianowicie „konsument wysoki poziom” i „konsument niski poziom”. Obie, dokonaj przesunięć bezpośrednio do ZK. Od 0.9, obaj konsumenci zostali połączeni w jednego konsumenta, zwanego "nowym konsumentem" (zasadniczo jednoczy on API niskiego poziomu i wysokiego poziomu dla obu starych konsumentów - oznacza to, że w 0.9 istnieją trzy rodzaje konsumentów). Nowy konsument dokonuje rekompensaty dla brokerów (tj. Wewnętrznego tematu Kafki). Aby uzyskać lepszą aktualizację, istnieje również możliwość "podwójnego zatwierdzenia" przesunięć przy użyciu starego klienta (od 0.9). Jeśli włączysz to przez dual.commit.enabled, przesunięcia są zatwierdzane dla ZK i tematu __consumer_offsets. Umożliwia to przejście ze starego interfejsu API konsumenta do nowego interfejsu API konsumenta podczas przenoszenia przesunięć z tematu ZK na numer __consumer_offsets.

Answer 2

Wszystko zależy od tego, z którego konsumenta korzystasz. Powinieneś wybrać odpowiedniego konsumenta na podstawie swojej wersji Kafki.

dla wersji 0.8 brokerów używać HighLevelConsumer. Przesunięcia dla twoich grup są przechowywane w zookeeper.

Dla brokerów 0.9 i nowszych należy użyć nowego ConsumerGroup. Przesunięcia są przechowywane u brokerów kafka.

Należy pamiętać, że HighLevelConsumer nadal będzie działać z wersjami po 0.8, ale zostały one wycofane w wersji 0.10.1, a wsparcie prawdopodobnie wkrótce zniknie. Opcja ConsumerGroup ma opcje migracji ruchomych, które ułatwiają przejście z wersji HighLevelConsumer, jeśli użytkownik zdecydował się go użyć.