v2.0 to ostatnia paczka programu. Dodaje cztery moduły - schema-registry, authorization, share-groups i capstones - oraz trzy scenariusze o tematach diskless w module storage, ćwiczenie DR active-active w module dr i partycjonowanie świadome racka w module producer, łącznie 24 nowe scenariusze. Odblokowuje w free play poziomy governance i diskless, a program Symulatora Kafki osiąga 136 ze 136.

To także wydanie, w którym przebudowaliśmy playground wokół tych scenariuszy. Od v1.9 zmieniła się niemal każda jego część: kanwa ma trzy widoki, oś czasu stała się czymś, co da się czytać, inspektory odpowiadają na pytania zamiast wyliczać pola, a terminal nie zasłania już kanwy.

Co jest w v2.0

Schema Registry (schema-registry, 3 scenariusze). Subjecty i wersje, co sprawdza kompatybilność backward, forward i full oraz zmiana łamiąca zgodność odrzucona, zanim zostanie zarejestrowana.

Autoryzacja (authorization, 2 scenariusze). Kontrola dostępu na ścieżce danych - jak ACL albo powiązanie roli RBAC zezwala na produkowanie lub mu odmawia, gdy autoryzator domyślnie wszystkiego zabrania.

Oba moduły trafiają do free play razem z nowym poziomem governance: kontrolkami Schema Registry, ACL i RBAC oraz kafka-acls w terminalu, więc wszystko, co pokazują scenariusze, możesz samodzielnie odtworzyć i zepsuć.

Share groups (share-groups, 9 scenariuszy). Semantyka kolejki w Kafce, wprowadzona w KIP-932:

Share groups zmieniają sposób konsumowania z Kafki, a zestawienie ich z klasycznymi grupami konsumentów pokazuje, co dokładnie jest inne.

Scenariusze zwieńczające (capstones, 5 scenariuszy). Scenariusze end-to-end łączące trwałość, transakcje, storage, multi-DC i governance, w których dzieje się kilka rzeczy naraz: potok płatności exactly-once, który przetrwa utratę regionu, failover regionalny bez utraty danych, migracja bez przestoju z Cluster Linking, wielo-DC szkielet zdarzeń active-active oraz potok strojony jednocześnie pod przepustowość i opóźnienie.

Disaster recovery (dr, 1 scenariusz więcej). Ćwiczenie DR active-active: tracisz region west, przenosisz jego producenta i grupę konsumentów do east i piszesz dalej, a potem restartujesz west i przenosisz je z powrotem. Nic nie jest promowane, a ceną są rekordy, których west nigdy nie zmirrorował.

Producent (producer, 1 scenariusz więcej). Partycjonowanie świadome racka, nowość w Kafce 4.4: producent trzyma rekordy bez klucza we własnej strefie dostępności, dopóki ta strefa nie straci swoich liderów. Więcej niżej, w części Apache Kafka 4.4.

Tematy diskless (kierunek KIP-1150, szkic KIP-1163/1164)

Temat diskless trzyma dane partycji w object storage zamiast na dyskach brokerów. Broker buforuje rekordy z wielu partycji i wysyła je jako jeden obiekt WAL; koordynator diskless przydziela offsety w chwili zatwierdzenia tego obiektu i dopiero wtedy produce zostaje potwierdzony. Repliki budują swój log, odczytując obiekt z powrotem ze storage, a nie pobierając danych od lidera, a producenci i konsumenci korzystają z repliki we własnej strefie dostępności (AZ).

Stan rzeczy: KIP-1150 został przyjęty jako kierunek, natomiast KIP-1163 i KIP-1164, które określają, jak to działa, wciąż mają status Under Discussion (implementację śledzi KAFKA-19161). Modelujemy bieżący szkic i w całym symulatorze oznaczamy go jako „KIP draft”. Nazwy i zachowanie mogą się zmienić, zanim cokolwiek z tego trafi do Kafki.

Trzy scenariusze (storage, 05.4.1-05.4.3):

  • Diskless: ścieżka zapisu - dwóch producentów i dwie partycje dzielą jeden obiekt WAL, żaden offset nie istnieje, dopóki koordynator go nie zatwierdzi, a repliki odczytują dane z powrotem z object storage.
  • Brak replikacji między AZ - te same 3 rekordy trafiają do tematu klasycznego i diskless rozłożonych na trzy AZ; karta Cross-AZ traffic kończy się wynikiem 7 przeskoków dla klasycznego i 0 dla diskless.
  • Ceną jest opóźnienie - ten sam produce z acks=all zostaje potwierdzony po 300 ms w temacie klasycznym i po 1300 ms w temacie diskless, a seria, która zapełnia bufor, po 800 ms. Czasy są przeskalowane w górę, żeby każdy krok był widoczny.

W free play: preset Diskless 3 AZ, przełącznik diskless dla każdego tematu i suwaki czasów diskless. Kanwa zyskuje tor object storage z własną osią czasu, tacki WAL pod każdym brokerem i plakietkę koordynatora, a panel metryk kartę Cross-AZ traffic. W terminalu kafka-topics --create --config diskless.enable=true tworzy temat diskless, a kafka-diskless-metadata (samo w sobie narzędzie ze szkicu, jeszcze nieobecne w Apache Kafka) pokazuje offsety per partycja i listuje obiekty WAL w storage.

Kompromis w skrócie: mniej ruchu replikacyjnego między AZ, wolniejsze produce - szkic celuje w opóźnienie produce około 500 ms na P50 i 1-2 s na P99. Klasyczna Kafka już teraz potrafi czytać z followera w tej samej AZ (KIP-392), więc diskless dokłada brak replikacji broker-broker i produce, który nie musi docierać do lidera.

Apache Kafka 4.4

Model odpowiada teraz Apache Kafce 4.4, wydanej w tym tygodniu. Porównaliśmy 4.3.0 z 4.4.0 i nie znaleźliśmy żadnej wartości domyślnej, wyniku CLI ani komunikatu błędu, na których opiera się symulator, a które by się zmieniły, więc w scenariuszach wszystko działa jak dotąd.

v2.0 modeluje jedną nowość z 4.4: partycjonowanie świadome racka po stronie producenta (KIP-1123). Przy partitioner.rack.aware=true i ustawionym client.rack domyślny partycjoner wysyła rekordy bez klucza do partycji, których lider jest w strefie dostępności producenta, a gdy w tej strefie nie ma lidera, do dowolnej partycji, dzięki czemu ruch produkcyjny zostaje w strefie. Nowy scenariusz Partycjonowanie świadome racka pokazuje oba przypadki. W free play inspektor producenta ma przełącznik, a producenci, z którymi startuje sandbox, mogą wybrać swój client.rack. Bez client.rack producent odrzuca to ustawienie, tak jak Kafka.

Kolejki dead-letter dla share groups (KIP-1191), kolejna nowość z 4.4, nie są jeszcze modelowane.

Przebudowany playground

Trzy sposoby patrzenia na klaster

Kanwa ma teraz trzy widoki, przełączane z jej paska narzędzi:

  • Brokers to znajomy obraz: producenci po lewej, klaster pośrodku, grupy konsumentów i share groups po prawej.
  • Lanes rysuje po jednym wierszu na partycję na wspólnej osi offsetów: repliki jedna pod drugą, lider na górze, a high watermark jako jedna linia przez wszystkie. Follower z opóźnieniem ma wyraźnie krótszy log, log zatrzymanego brokera stoi w miejscu, a każdy konsument siedzi na swojej pozycji odczytu, z zatwierdzonym offsetem i lagiem. Jednym rzutem oka widzisz, gdzie w logu jest każdy.
  • Matrix służy do klastrów zbyt dużych, by je narysować: tabela z tematami w wierszach i brokerami w kolumnach oraz cztery soczewki - Failures, Balance, Lag i Traffic - które ją kolorują i sortują od najgorszego. Najechanie na brokera pokazuje, temat po temacie, co klaster by stracił, zanim go zatrzymasz. Duży klaster w free play sam otwiera się w widoku Matrix.

Kanwa pokazuje, co się zmieniło

Zmiany stanu odgrywają się teraz na elemencie, który się zmienił, zamiast jako ogólny impuls: znaczniki high watermark przesuwają się do nowego offsetu, korona lidera przechodzi ze starego lidera na nowego, a etykieta ISR followera przyjmuje kolor zmiany. Wyprodukowany rekord ląduje we własnej komórce logu, zatłoczona kanwa rysuje rekordy jako krótkie smugi, a zatrzymany broker zostaje na kanwie, wyblakły, więc widać, co tam wcześniej było. Na kanwach wieloregionowych link mirrorujący pokazuje swoje RPO, każde pasmo DC mówi, ile kosztowałaby jego utrata, podział sieci pokazuje, która strona nadal obsługuje ruch, pasek KRaft liczy swoją większość, a tor share group pokazuje przy każdym rekordzie licznik blokady i liczbę dostarczeń.

Oś czasu, którą da się czytać

Na desktopie dolny dok to teraz jednowierszowa szyna: klatki stoją w swoim rzeczywistym czasie symulacji, więc seria wygląda jak skupisko, a spokojny odcinek jak przerwa, i przewija się ją, przeciągając wzdłuż. Po otwarciu jej torów zdarzeń każde zdarzenie przebiegu zostaje rozłożone na tory produce, replikacji, brokerów i konsumpcji, awarie na czerwono, z zaznaczonym głównym zdarzeniem każdej klatki.

Inspektory, które odpowiadają na pytania

Prawy panel zaczyna teraz od pytań, które zadajesz. Partycja wygląda jak linijka jej offsetów, broker jak to, co tracisz, gdy się zatrzyma, temat jak tor na każdą partycję, producent jak jego ścieżka wysyłki, a grupa konsumentów jak tory albo siatka partycji. Why wymienia, co się zepsuło i dlaczego, Metrics są pogrupowane według roli, a niektóre inspektory pokazują, co stanie się dalej, a nie tylko bieżący stan. Widoki wieloregionowe dostają kartę DR, która pokazuje log każdego regionu i niezmirrorowany ogon jako RPO.

Kanwa robi miejsce terminalowi

Terminal CLI Kafki nadal dokuje się pod kanwą, ale kanwa robi mu teraz miejsce, zamiast chować się pod nim - więc kafka-server-stop i padający broker-1 są na ekranie jednocześnie, a terminal ma całą szerokość kanwy na to, co wpisujesz, i na to, co wypisują narzędzia. Na szerokim ekranie przycisk dock side na jego pasku tytułu przenosi go do kolumny obok kanwy. Wynik zachowuje kolumny, a menu hostów to tabela ssh ze wszystkimi brokerami i kontrolerami. Pliki konfiguracyjne brokerów odpowiadają Kafce 4.4, a kafka-reassign-partitions --generate oraz drenowanie brokera przed jego usunięciem działają tak jak na prawdziwym klastrze.

Pierwsze kroki bez wycieczki

Modalna wycieczka z 13 krokami zniknęła. Jej miejsce zajmuje karta Getting started w rogu kanwy: te same tematy w formie checklisty, przez którą idziesz w dowolnej kolejności, każdy z przyciskiem „Show me”. Pomoc to teraz materiał referencyjny, w którym się czegoś szuka, scenariusz pisany z góry można rozgałęzić do sandboxa z Undo, scenariusze same podsuwają ruchy „Try it yourself” i to, co zrobić dalej, a udostępniony link odtwarza teraz drogę do stanu, który pokazuje.

Nowy wygląd i przegląd dostępności

Cała strona, łącznie z playgroundem, ma nowy wygląd oparty na kawce z naszej nazwy: ciemny atrament, niebieski połysk i szarość, przy czym każda para kolorów tekstu spełnia WCAG AA. Razem z nim przyszły skip linki i nazwane regiony, szyna scenariuszy z jednym przystankiem tabulacji, kontrast AA dla nieaktywnych regionów, informacja zwrotna przy naciśnięciu i większe cele dotykowe, a także ruch, który respektuje prefers-reduced-motion, zachowując przenikania i rezygnując z przesunięć. Układ na telefon doczekał się osobnego przeglądu, aż po test sprawdzający, że każda etykieta wciąż się mieści.

Poza playgroundem

Sam playground nie jest indeksowany, więc wyszukiwarki nigdy nie widziały tekstu jego scenariuszy. Teraz każdy scenariusz ma własną stronę pod /kafka-simulator/scenarios/: wstęp i podsumowanie, każdy krok z linkiem „Open at this step”, prawdziwą klatkę kanwy, po której można przechodzić krok po kroku, oraz konfiguracje Kafki, których dotyczy. Z v2.0 daje to 136 stron.

Obok nich są strony troubleshootingowe dla błędów i objawów Kafki - co oznacza problem, jakie są prawdopodobne przyczyny, jak go naprawić i czego nie robić, czy klient sam ponawia próbę - każda połączona ze scenariuszami, w których problem występuje, otwartymi dokładnie w tym momencie. W tym wydaniu dołącza do nich strona o autoryzacji. Changelog czyta się teraz jak notki wydań na osi czasu.

Jeszcze jedno

W tym wydaniu coś ukryliśmy. Znalezienie tego zostawiamy wam.

Koniec roadmapy

v2.0 domyka to, co zaczęło się w v1.0: jedenaście paczek wydawanych co dwa tygodnie, 136 scenariuszy, od anatomii pojedynczego brokera po kolejki i scenariusze zwieńczające obejmujące całą platformę. Wszystko działa w przeglądarce, deterministycznie, zgodnie z semantyką Apache Kafki 4.4, bez backendu i bez telemetrii na temat twoich scenariuszy.

Program jest kompletny, ale symulator to sandbox, a nie kurs, który się kończy. Otwórz symulator, zbuduj coś i to zepsuj.