Jedną z ogromnych zalet Kafki jest jej wysoką odporność na awarie, która w dużym stopniu wynika z rozbudowanych mechanizmów replikacji.

Oto jak one działają.

Replikacja na Kafce opiera się na partycjach, to one są najmniejszym, replikowalnym elementem.

Producer

Kiedy Producer zapisuje komunikat na topic, dokonuje tego na partycji oznaczonej jako Partition Replica Leader. Jest to partycja, która została wybrana przez brokera na lidera.

Po udanym zapisie komunikat jest replikowany do tzw. followersów, czyli partycji, które są replikami lidera.
Sama liczba replik jest sterowana przez konfigurację topiku, a konkretnie przez parametr replication factor, który wskazuje, ile replik ma być utworzonych. W liczbę replik wliczany jest też lider, czyli replication factor (konfiguracja Topiku) ustawiony na wartość 3, oznacza, że mamy jednego lidera i dwie dodatkowe repliki lidera (followers).

Kolejnym krokiem, jest potwierdzenie zapisania komunika przez brokera, które jest wysyłane do Producera po zapisie.

No i tu robi się ciekawie, bo do gry wkracza zbiór In-Sync Replicas – ISR. Czyli zbór replik, które są w stanie zsynchronizowanym – wszystkie dane na poszczególnych replikach są spójne.
Domyślnie, Producer oczekuje potwierdzenia zapisu od wszystkich replik w zbiorze ISR (parametr acks ustawiony na wartość all). Jednak mamy tu pewne pole do tuningu.

Zmiana wielkości ISR
Pierwsza opcja to zmiana wielkości zbioru ISR, możesz to zrobić, ustawiając odpowiednią wartość za pomocą parametru min.insync.replicas (parametr konfiguracji Topiku). Dla przykładu, jeżeli ustawisz tę opcję na wartość 2, to oznacza, że tylko dwie repliki (wliczając lidera) muszą zapisać u siebie dany komunikat.

Zmiana liczby potwierdzeń
Druga opcja to zmiana liczby wymaganych potwierdzeń, czyli parametr acks (parametr konfiguracji Producera). Domyślna wartość – all, oznacza, że bazujemy na zbiorze ISR, jednak jeżeli zmienisz tę wartość na konkretną liczbę, np. 2, sprawisz, że Producer będzie czekał na dokładnie potwierdzenia zapisu od dokładnie dwóch partycji. Oczywiście, możesz też zmniejszyć ten parametr, do 1 – czyli tylko lider potwierdza, lub nawet do 0 – czyli działamy na zasadzie fire-and-forget, nie interesuje nas czy ktoś to poprawnie zapisał.

W przypadku konfiguracji potwierdzeń zapisu musisz wyważyć dwie kwestie. Bezpieczeństwo zapisu i wydajność. Oczekiwanie na dodatkowe potwierdzenia powoduje większe opóźnienie, co zmniejsza przepustowość Twojej aplikacji. Z drugiej strony, zbyt optymistyczne podejście do potwierdzeń, może grozić utratą danych podczas awarii.

Stan zdrowia ISR
Kolejną istotną kwestią w temacie ISR jest zadbanie o zdrowy stan tego zbioru. Czyli partycje, które wchodzą w jego skład muszą być responsywne i poprawnie funkcjonować, nie mogą być replikami widmo, które znajdują się, albo raczej znajdowały się na brokerze, który uległ awarii 2 minuty temu. Lider ISR śledzi stan zdrowia replik na podstawie ich aktywności, tzn. kiedy ostatnio repliki odpytały go o jego stan. To ile czasu lider daje replikom na odezwanie się możesz skonfigurować parametrem replica.lag.time.max.ms (parametr konfiguracji Brokera).

Consumer

Po stronie consumera nie mamy pola do manewru niestety. Jednak jest tutaj jedna kwestia, o której warto wiedzieć. Nosi ona nazwę High Watermark Offset.
Jest to wartość, która wskazuje, jaka najwyższa wartość offsetu została zapisana we wszystkich replikach w ISR. Oznacza to, że wszystkie rekordy z takim offsetem lub niższym, można uznać za zatwierdzone i trwale zapisane.
To oznacza, że dla Consumera widoczne i dostępne są tylko te rekordy, które łapią się w zakres tego znacznika, natomiast inne, do czasu kompletnego potwierdzenia nie będą możliwe do odczytania.

Jak widzisz, trochę jest tutaj fajnych mechanizmów, a więcej szczegółów, wraz z diagramami znajdziesz w artykule poniżej. Ostrzegam, jest tam dużo szczegółowego mięsa, ale warto 🙂

Źródla

• https://link.medium.com/jRqNZNdAQwb

Ten artykuł znalazł się w Mailingu EffectiveDev

Wydanie #25

Replikacja na Kafce

• 👉 Replikacja na Kafce
  Czyli jak to działa
• 👉 SOLID: Sedno LSP
  Czyli o co chodzi w Liskov Substitution Principle
• 👉 Projektowanie rozproszonego Grafu
  Czyli jak wyskalować GraphQL
• 👉 OpenAPI i IntelliJ IDEA
  Czyli co ciekawego na Twitterze

Dołącz TUTAJ
Co tydzień, podobne artykuły otrzymasz prosto do swojej skrzynki mailowej!