Powrót do bloga
Nowości

Apache Kafka 4.0 – Co nowego w tym przełomowym wydaniu?

10 min

Apache Kafka 4.0 – Co nowego w tym przełomowym wydaniu?

Wersja 4.0 otwiera nowy rozdział w historii Apache Kafka: oficjalne pożegnanie z ZooKeeperem, nowy protokół grup konsumenckich, wczesna wersja obsługi kolejek, ulepszone transakcje, zmiany w Kafka Streams i masa innych usprawnień. Ten post podsumowuje najważniejsze nowości, ich wpływ na codzienną pracę z Kafką oraz wskazówki dotyczące migracji.

KRaft zamiast ZooKeeper

(Koniec pewnej ery)

Najbardziej przełomową zmianą w wersji 4.0 jest pełne przejście z ZooKeepera na KRaft (Kafka Raft Metadata). ZooKeeper nie jest już wspierany – Kafka 4.0 wymaga KRaft. W praktyce:

  • Mniej złożoności: nie musimy utrzymywać osobnego klastra ZooKeeper.
  • Wydajniejszy konsensus: metadane Kafki obsługuje wewnętrzny protokół Raft. Szybsze aktualizacje, wybory lidera i replikacja.
  • Migracja z ZooKeeper: jeśli masz klaster 3.x oparty o ZK, musisz przed podniesieniem do 4.0 wykonać migrację narzędziami dostępnymi w serii 3.x (m.in. KIP-866).
  • Brak wstecznej kompatybilności z ZK: 4.0 nie uruchomi się w trybie ZooKeeper – to największe wyzwanie operacyjne.

Jeżeli dopiero zaczynasz przygodę z Kafką, nie musisz martwić się ZooKeeperem – KRaft to nowy standard.

Nowy protokół grup konsumenckich (KIP-848)

(Koniec z długimi „stop-the-world” rebalansami)

Druga kluczowa zmiana to nowa generacja protokołu konsumenckiego. Dotychczas przy każdej zmianie w grupie (np. dołączył nowy konsument) Kafka zatrzymywała na chwilę przetwarzanie i rozdzielała partycje od nowa. Przy dużych grupach mogło to powodować poważne lagi.

  • Co się zmieniło?
    Teraz broker potrafi rebalansować konsumentów znacznie szybciej i bez “zamrażania” całej grupy.
  • Jak włączyć?
    Broker 4.0 obsługuje nowy protokół domyślnie, ale klienci muszą go ręcznie włączyć ustawiając group.protocol=consumer.
  • Efekt: dużo szybsza reakcja na skalowanie, awarie i zmiany topologii w grupach.

Jeśli masz duże wdrożenia, ta poprawa będzie mocno odczuwalna: mniej przerw w przetwarzaniu i bardziej płynny streaming.

Kolejki w Kafka (KIP-932, Early Access)

(Pierwszy krok w stronę modelu point-to-point)

W Kafka 4.0 pojawia się wczesna wersja obsługi kolejek (point-to-point), czyli mechanizmu pozwalającego na dostarczenie danej wiadomości do dokładnie jednego konsumenta w grupie współdzielonej.

  • Share group: zamiast „klasycznej” grupy konsumenckiej, tworzymy share group, w której wielu konsumentów „zjada” rekordy z jednego tematu, niczym kolejkę.
  • Bez nowego typu obiektu: wszystko odbywa się nadal w ramach zwykłych tematów Kafki, ale logika przypisywania rekordów konsumentom pozwala zachować semantykę kolejki (jeden rekord – jeden konsument).
  • Early Access: funkcjonalność jest eksperymentalna – fajna do prototypów, ale do produkcji podchodziłbym ostrożnie. Może jeszcze zabraknąć pewnych udogodnień.

Jeśli do tej pory używałeś RabbitMQ czy JMS wyłącznie ze względu na wzorzec point-to-point, to wkrótce Kafka może wystarczyć także w tych przypadkach.

Usprawnienia niezawodności i dostępności

(Mocniejsza ochrona przed awariami)

Transakcje bez „zombie”

(KIP-890)

W przypadku używania transakcji w Kafce (aby zapewnić exactly-once semantics), wersja 4.0 zmniejsza ryzyko pozostawienia zombie transactions po awarii producenta.

  • Lepsze wykrywanie nierozwiązanych transakcji: broker automatycznie kończy lub anuluje transakcje, które mogły utknąć w stanie niepewności po crashu.

Pre-Vote w KRaft

(KIP-996)

Dodano mechanizm Pre-Vote w procesie wyboru lidera partycji/ kontrolera, co zapobiega pochopnym re-elekcjom przy krótkotrwałych problemach sieci.

  • Efekt: mniej „niepotrzebnych” failoverów i bardziej stabilny klaster.

Eligible Leader Replicas (preview)

(KIP-966)

Na razie eksperymentalnie wprowadzono koncepcję ELR, dzięki której w razie awarii lidera na lidera wybrana zostanie tylko replika w pełni zsynchronizowana.

  • Minimalizacja ryzyka utraty danych: wybór takiej repliki, która na pewno ma wszystkie zatwierdzone zapisy.
  • Status podglądu: włączasz świadomie, aby testować. W przyszłości to prawdopodobnie stanie się standardem.

Automatyczny rebootstrap klientów

(KIP-1102)

W sytuacjach, gdy metadane klastra się zmieniają, klienci (producenci, konsumenci) mogą teraz proaktywnie ponawiać pobranie konfiguracji.

  • Mniej „utknięcia”: jeśli topologia się zmieni, klienci sami się „odświeżą” bez czekania na twardą awarię.

Nowe opcje klienckie i narzędzia administracyjne

Reset offsetu wg czasu

(KIP-1106)

Możemy teraz ustawić np. auto.offset.reset=by_duration:P30D, co oznacza, że konsument bez offsetu zacznie czytać od punktu sprzed 30 dni. To wygodne przy dłuższej retencji (np. archiwach w tiered storage), żeby uniknąć masowej konsumpcji całej historii.

Metryki aplikacji klienckich na brokerze

(KIP-1076)

Broker może zbierać rozszerzone metryki klientów (producentów, konsumentów) – w tym takie, które sami zdefiniujemy w aplikacji.

  • Lepszy monitoring: operatorzy widzą w jednym miejscu (na brokerze) zarówno standardowe wskaźniki (przepustowość, opóźnienia), jak i metryki biznesowe.

Nowe narzędzie kafka-groups.sh

(KIP-1043, KIP-1099)

Z racji nowych protokołów i typów grup (np. share) pojawiła się potrzeba lepszego narzędzia do zarządzania grupami.

  • kafka-groups.sh wypisze wszystkie grupy (klasyczne, nowe, współdzielone itd.) i ich status.
  • Poprawiono też istniejące skrypty (kafka-consumer-groups.sh, kafka-share-groups.sh), żeby rozumiały nowe rodzaje grup i protokołów.

Zmiany domyślnych konfiguracji (KIP-1030)

Duże wydania to okazja do wprowadzenia lepszych wartości domyślnych. Warto kilka z nich odnotować:

  1. linger.ms = 5 ms (wcześniej 0)
    Producent domyślnie czeka do 5 ms, zanim wyśle pakiet wiadomości. Zwiększa to batching i przepustowość.

  2. message.timestamp.after.max.ms = 3600000 ms (1h)
    Broker odrzuci wiadomości „z przyszłości” przesuniętej o więcej niż 1 godzinę. Chroni to przed przypadkowo złym zegarem systemowym.

  3. num.recovery.threads.per.data.dir = 2 (wcześniej 1)
    Broker szybciej będzie się uruchamiał (szybsza analiza logów przy starcie).

  4. Domyślne wątki dla tiered storage – wprowadzono konkretne limity (np. 10) zamiast -1, co zapobiega nadmiernemu obciążeniu w razie złej konfiguracji.

  5. Podniesienie minimalnych wartości dla niektórych parametrów (np. log.segment.bytes min. 1 MB zamiast… 14 bajtów). Chroni to przed patologiczną konfiguracją.

Wymagania środowiskowe – Java 17 i Log4j2

Java

  • Broker i Connect muszą działać na Java 17.
  • Klienci (Producer, Consumer, Kafka Streams) – co najmniej Java 11.

To oznacza koniec wsparcia dla Javy 8. Jeśli masz architekturę wciąż opartą o tę wersję, przed aktualizacją do Kafki 4.0 konieczne będzie przejście na nowszą JDK.

Logowanie

Kafka 4.0 przechodzi w pełni na Log4j2, rezygnując z przestarzałego Log4j 1.x.

  • Konwersja konfiguracji: dołączono narzędzie log4j-transform-cli, które próbuje automatycznie przerobić stare pliki log4j.properties na nowy format.
  • Lepsze bezpieczeństwo: unikasz problemów typu Log4Shell, dostajesz też wydajniejsze appendery.

Zgodność wsteczna i uwagi migracyjne

Usunięte stare protokoły klienta

Broker 4.0 nie współpracuje z klientami starszymi niż v2.1. Jeśli w systemie wciąż masz bardzo stare aplikacje (np. 0.10, 0.11), one przestaną działać po podniesieniu brokerów.

Usunięte stare formaty wiadomości

Wersja 4.0 nie obsługuje formatu logów sprzed KIP-98 (v0 i v1). Przed migracją trzeba przejść na format v2+ (co i tak większość już dawno zrobiła).

Migracja z ZooKeeper do KRaft

Nie można „bezpośrednio” podnieść z wersji ZK do 4.0. Najpierw trzeba skorzystać z mechanizmów migracji metadanych dostępnych w serii 3.x (np. 3.3+ lub 3.5).

Planowanie aktualizacji

  • Przed aktualizacją brokerów do 4.0:
    1. Zaktualizuj aplikacje klienckie (konsumenci, producenci, Kafka Streams) do co najmniej 2.1+.
    2. Upewnij się, że serwer i Connect będą gotowe na Java 17.
    3. Przeanalizuj zmiany domyślnych konfiguracji KIP-1030.
    4. (Jeśli używasz ZooKeepera) przejdź na KRaft w 3.x.
  • Przetestuj w środowisku testowym. Zmiany w logowaniu i protokołach mogą wpłynąć na narzędzia, integracje i skrypty.

Nowości w Kafka Streams

  1. Foreign-key joins bez duplikacji klucza (KIP-1104)
    Możesz łączyć tabele/strumienie „po polu w wartości” bez konieczności sztucznego przenoszenia klucza do sekcji key. Mniej kodu, większa wygoda.

  2. ProcessorWrapper (KIP-1112)
    Pozwala „owijać” procesory (nawet te tworzone w DSL) wspólną logiką przekrojową (np. globalne logowanie, obsługa błędów) zamiast powielać kod w każdym module.

  3. RETRY w ProductionExceptionHandler (KIP-1065)
    Do tej pory mieliśmy tylko FAIL albo IGNORE. Teraz można ponawiać wysyłkę do wyjściowego tematu w razie chwilowych błędów (np. brak tematu, sieć). Zwiększa niezawodność.

  4. Nowe metryki stanu wątków (KIP-1091)
    Teraz łatwiej wykryć, czy wątek strumieni utknął w błędzie albo tkwi w stanie REBALANCING. Świetne do monitoringu i automatyzacji reakcji.

Kafka Connect i replikacja

  1. Usunięcie endpointu /tasks-config (KIP-970)
    Teraz jedynym właściwym jest /connectors/{connector}/tasks. Jeśli skrypty używały starego adresu, trzeba je poprawić.

  2. Replikacja tematów -internal/.internal (KIP-1074)
    MirrorMaker 2 wcześniej z automatu pomijał tematy kończące się na -internal. Teraz można je w razie potrzeby replikować przez proste ustawienie konfiguracyjne.

  3. Wyłączanie heartbeatów (KIP-1089)
    Przy złożonych topologiach replikacji (różne connectory działające między tymi samymi klastrami) można wyłączyć replikację tematu heartbeats, by uniknąć konfliktów i duplikacji.

  4. Java 17 i Jakarta EE (KIP-1032)
    Connect też wymaga Javy 17 i używa bibliotek Jakarta zamiast starych JavaEE. Jeśli piszesz własne pluginy, sprawdź zgodność API.

Podsumowanie

Apache Kafka 4.0 to:

  • Koniec z ZooKeeperem – prostsza architektura KRaft.
  • Nowy protokół konsumencki – szybsze rebalansy.
  • Wczesny dostęp do kolejek – poszerzenie modelu pub-sub o point-to-point.
  • Wzmocniona niezawodność – Pre-Vote, ELR, lepsza obsługa transakcji.
  • Ułatwienia dla deweloperów – reset offsetu wg czasu, automatyczny rebootstrap klientów, lepsze narzędzia do zarządzania grupami, ProcessorWrapper w Streams.
  • Nowoczesne środowisko – obowiązkowo Java 17 na brokerach, Log4j2, rezygnacja z przestarzałych protokołów.