Preskoči na glavni sadržaj

40 odabranih Kafka intervju pitanja👍

CainongPosao i intervjuiIntervju pitanja i teorija4471 reči15 minuta

Danas delim sa čitaocima članak koji je priložio čitalac Cainong: 40 odabranih Kafka intervju pitanja👍.

Krećemo🚗

Kafku je prvobitno razvio LinkedIn — to je distribuirani, skalabilni, tolerantni na greške sistem za objavljivanje-pretplatu (publish-subscribe) koji podržava particije (Partition), replike (replica) i zasnovan je na Zookeeper okviru. Kafka je pogodna za offline i online obradu poruka. To je jedna od važnih komponenti distribuiranih aplikacionih sistema, a široko se koristi i u obradi velikih podataka (big data). Kafka je razvijena u Scala jeziku, a njena Java verzija se zove Jafka. LinkedIn je 2010. godine poklonio ovaj sistem Apache fondaciji, gde je postao jedan od vrhunskih open-source projekata.

Nadamo se da će ovih 40 intervju pitanja poslužiti kao putokaz za učenje Kafke — od osnova ka naprednim temama, pokrivajući maksimalno celokupan sadržaj pitanja i odgovora o Kafki (priprema + ponavljanje u jednom koraku)

1. Dizajn Kafke

Kafka grupiše poruke po topic-u. Program koji objavljuje poruke naziva se Producer, a program koji ih čita naziva se Consumer. Radi u klasteru i može se sastojati od jedne ili više usluga; svaka usluga se zove Broker. Producer šalje poruke preko mreže Kafka klasteru, klater pruža poruke potrošačima, a broker u sredini igra ulogu posrednika koji čuva poruke.

Važne komponente Kafke

1) Producer: proizvođač poruka — terminal ili usluga koja objavljuje poruke u Kafka klaster

2) Broker: jedan Kafka čvod je jedan Broker; više Broker-a mogu činiti Kafka klaster.

Ako neki Topic ima n Partition-a, a klaster ima n Broker-a, onda svaki Broker čuva po jednu Partition tog Topic-a

Ako neki Topic ima n Partition-a, a klaster ima m+n Broker-a, onda samo n Broker-a čuva po jednu Partition tog Topic-a

Ako neki Topic ima n Partition-a, a broj Broker-a u klasteru je manji od n, onda će jedan Broker čuvati jednu ili više Partition-a tog Topic-a — ova situacija treba izbegavati jer dovodi do neuravnoteženosti podataka u klasteru

3) Topic: tema poruka — svaka poruka objavljena u Kafka klaster svrstava se ovde; Kafka je orijentisana ka Topic-u

4) Partition: Partition je fizička podela Topic-a; jedan Topic se može podeliti na više Partition-a, a svaka Partition je uređen, nepromenljiv niz zapisa. Unutar jedne teme particije su uredne, ali se ne može garantovati redosled poruka kroz sve particije teme.

5) Consumer: terminal ili usluga koja čita poruke iz Kafka klastera

6) Consumer Group: svaki Consumer pripada jednoj Consumer Group; svaku poruku može čitati samo jedan Consumer iz jedne Consumer Group, ali je mogu čitati više različitih Consumer Group-a.

7) Replica: kopija Partition-a, služi za obezbeđivanje visoke dostupnosti Partition-a.

8) Controller: jedan od servera u Kafka klasteru, zadužen za Leader election i razne Failover operacije.

9) Zookeeper: Kafka preko Zookeeper-a čuva meta podatke klastera

2. Razlozi za visoke performanse Kafke

  1. Koristi PageCache keširanje
  2. Sekvencijalno pisanje na disk
  3. Zero-copy tehnologija
  4. Pull model povlačenja

3. Princip efikasnog skladištenja fajlova u Kafci

  1. Kafka deli veliki fajl jedne Partition-a Topic-a na više malih segmenata fajlova; kroz više malih segmenata lako se periodicno čiste ili brišu fajlovi koji su već obrađeni, čime se smanjuje zauzeće diska
  2. Preko indeksnih informacija može brzo locirati Message i odrediti maksimalnu veličinu odgovora
  3. Mapiranjem svih indeksnih meta podataka u memory, izbegava se disk I/O operacija nad Segment fajlovima
  4. Retkim skladištenjem indeksnog fajla može se drastično smanjiti prostor koji zauzimaju indeksni meta podaci

4. Prednosti i nedostaci Kafke

Prednosti

  • Visoke performanse, visok protok, niska latencija: brzina proizvodnje i čitanja poruka dostiže 100.000 u sekundi
  • Visoka dostupnost: sve poruke se trajno čuvaju na disku i podržavaju backup podataka radi sprečavanja gubitka
  • Visoka istovremenost: podržava hiljade klijenata koji istovremeno čitaju i pišu
  • Tolerancija na greške: dozvoljava pad čvorova u klasteru (ako je broj replika n, dozvoljava pad n-1 čvora)
  • Visoka skalabilnost: Kafka klaster podržava hot scaling, bez zaustavljanja

Nedostaci

  • Nema kompletan set alata za nadzor
  • Ne podržava izbor teme pomoću wildcards

5. Scenariji upotrebe Kafke

  1. Agregacija logova: prikuplja logove raznih usluga i upisuje ih u Kafka message queue na čuvanje
  2. Sistem poruka: široko se koristi kao middleware za poruke
  3. Decoupling sistema: nakon završetka važne operacije, šalje se poruka, a druge usluge obavljaju preostale operacije
  4. Ravnomerenje opterećenja (peak shaving): obično se koristi u seckil ili snapping aktivnostima, da ublaži pritisak koji u kratkom vremenu nastaje zbog visokog protoka na sajtu
  5. Asinhrona obrada: kroz asinhroni mehanizam, poruku je moguće staviti u red bez trenutne obrade, pa je obraditi kad je potrebno

6. Pojam particija (Partition) u Kafci

Topic je logički pojam koji se može dalje podeliti na više particija; jedna particija pripada samo jednom topic-u, pa se često naziva i topic-partition (Topic-Partition). Poruke u različitim particijama iste teme su različite. Sa aspekta skladišta, particija se može posmatrati kao log file koji se može nadovezivati; kada se poruka doda u log fajl particije, dodeljuje joj se specifičan offset. Offset je jedinstveni identifikator poruke u particiji, i Kafka njime garantuje redosled poruka unutar particije. Međutim, offset se ne proteže kroz particije — drugim rečima, Kafka garantuje redosled unutar particije, a ne unutar cele teme.

Unutar particije je uveden pojam više replika (replica), čiji se broj povećava radi veće otpornosti na katastrofe. Različite replike iste particije čuvaju iste poruke. Odnos između replika je jedan master, više slugu — master replika je zadužena za čitanje i pisanje, dok slave replike samo sinhronizuju poruke. Replike se nalaze na različitim broker-ima; kada master replika padne, jedna od slave replika se unapređuje u master.

7. Pravila particionisanja u Kafci

  1. Ako je Partition izričito naveden, ta vrednost se direktno koristi kao Partition
  2. Ako Partition nije naveden ali postoji key, uzima se Hash vrednost key-a i deli se modulom sa brojem Partition-a topic-a da bi se dobila Partition vrednost
  3. Ako nema ni Partition ni key, prilikom prvog poziva generiše se slučajan ceo broj (koji se pri svakom narednom pozivu uvećava), koji se zatim deli modulom sa ukupnim brojem dostupnih Partition-a topic-a — to je tzv. round-robin algoritam

8. Zašto Kafka particiše poruke

  1. Olakšava proširenje u klasteru — svaka Partition se može prilagoditi mašini na kojoj se nalazi, a jedan Topic može imati više Partition-a, pa klaster može primiti proizvoljno velike količine podataka
  2. Povećava istovremenost, jer se čitanje i pisanje mogu vršiti po particijama

9. Tok rada producenta u Kafci

  1. Kada pristigne poruka, prvo se obavija u ProducerRecord objekat
  2. Taj objekat se serijalizuje (može se koristiti podrazumevana ili prilagođena serijalizacija)
  3. Vrši se particionisanje poruke — pri tome se dobijaju meta podaci klastera i odlučuje u koju particiju kog topic-a će poruka biti poslata
  4. Particionisana poruka se ne šalje direktno serveru, već se stavlja u bafer producenta; više poruka se pakuje u Batch, čija je podrazumevana veličina 16KB
  5. Nakon što se Sender nit pokrene, iz bafera uzima batch-eve koji su spremni za slanje
  6. Sender nit šalje batch po batch ka serveru

10. Pakovanje poruka u Kafci

U Kafci Producer može gurati podatke u Batch režimu radi veće efikasnosti. Kafka Producer može akumulirati poruke u memoriji do određene količine, a zatim ih poslati kao jedan Batch. Veličina Batch-a se kontroliše kroz parametre Produecera, i to iz tri dimenzije:

  • Broj akumuliranih poruka (npr. 500)
  • Vremenski interval akumulacije (npr. 100ms)
  • Akumulirana veličina podataka (npr. 64KB)

Povećanjem veličine Batch-a smanjuje se broj mrežnih zahteva i disk I/O operacija; konkretne parametre treba balansirati između efikasnosti i pravovremenosti.

11. Modeli čitanja poruka u Kafci

Kafka prati tradicionalni model koji većina sistema poruka koristi: Producer gura poruke ka Broker-u, a Consumer ih preuzima od Broker-a.

Ako se koristi Push model, Consumer teško može obraditi poruke koje upstream šalje različitim brzinama.

Prednost Pull modela je u tome što Consumer sam može odlučiti da li će od Broker-a povući podatke u batch-u. Mana Pull modela je što, ako Broker nema poruke za čitanje, Consumer neprestano rotira u petlji čekajući novu poruku. Da bi se to izbeglo, Kafka ima parametar koji omogućava Consumer-u da blokira dok ne stigne nova poruka.

12. Kako Kafka implementira balansiranje opterećenja i failover

Balansiranje opterećenja znači ravnomerno raspoređivanje opterećenja sistema na sve servere koji učestvuju u radu, prema određenim pravilima, čime se maksimalno garantuje ukupna efikasnost i stabilnost rada sistema

Balansiranje opterećenja

Kafkino balansiranje opterećenja znači da svaki Broker ima jednaku šansu da pruži uslugu Kafka klijentima (proizvođačima i potrošačima), pa se opterećenje raspoređuje na sve mašine u klasteru. Kafka implementira balansiranje opterećenja kroz inteligentan izbor lidera particija — pametan Leader election algoritam ravnomerno raspoređuje Leadere svih Partition-a na sve mašine klastera, čime se na nivou celog sistema postiže balansiranje opterećenja.

Failover

Kafkin failover se ostvaruje preko mehanizma sesija — svaki Kafka server se nakon pokretanja registruje na Zookeeper serveru u obliku sesije. Čim server naiđe na problem, sesija sa Zookeeper-om se ne može održati, istekne i veza se prekida; tada Kafka klaster bira drugi server koji u potpunosti menja ovog i nastavlja da pruža uslugu.

13. Uloga Zookeeper-a u Kafci

Kafka je distribuirani sistem izgrađen pomoću Zookeeper-a. Svi Kafka Broker-i se pri pokretanju registruju na Zookeeper-u, koji ih objedinjeno koordinira i upravlja njima. Ako bilo koji čvod padne, može se oporaviti iz prethodno pohranjenog offset-a preko Zookeeper-a, jer on periodicno čuva offset-e. Poruke istog Topic-a se dele na više particija i raspoređuju na više Broker-a, a ove informacije o particijama i njihovoj vezi sa Broker-ima takođe održava Zookeeper.

14. Koje sistemske alate Kafka pruža

  • Kafka alat za migraciju: pomaže u migraciji brokera sa jedne verzije na drugu
  • Mirror Maker: alatka koja omogućava da se slika jednog Kafka klastera pruži drugom
  • Provera potrošača: za zadati skup tema i grupa potrošača, prikazuje temu, particije i vlasnike

15. Odnos potrošača i grupa potrošača u Kafci i implementacija balansiranja opterećenja

Consumer Group je Kafka jedinstven, skalabilan i tolerantan mehanizam potrošača. Unutar jedne grupe može biti više Consumer-a koji dele jedan globalno jedinstven Group ID. Svi Consumer-i u grupi se koordiniraju kako bi čitali sve particije (Partition) pretplaćenih tema (Topic). Naravno, svaku Partition može čitati samo jedan Consumer iz iste Consumer Group. Potrošači unutar grupe mogu se implementirati pomoću više niti; broj potrošača obično ne prelazi broj particija, a najbolje je da budu u celobrojnom odnosu, kako ne bi bilo potrošača u praznom hodu.

Consumer se pretplaćuje na Partition-e Topic-a, a ne na pojedinačne Message. Zato u istom trenutku Consumer-i koji su pretplaćeni na istu particiju nužno pripadaju različitim Consumer Group-ama

Odnos između Consumer Group i Consumer-a se dinamički održava — kada jedan Consumer proces padne ili zaglavi, Partition-e koje je on čitao se preraspoređuju na ostale Consumer-e u grupi; kada novi Consumer uđe u Consumer Group, takođe se jedan ili više Partition-a prebacuje sa drugih Consumer-a na tog novog člana.

Balansiranje opterećenja

Kada se pokrene Consumer, navodi se grupa kojoj želi da pristupi, pomoću konfiguracionog parametra: Group.id

Da bi se održao odnos između Consumer-a i Consumer Group-a, Consumer periodicno šalje heartbeat coordinator-u (coodinator); ako heartbeat istekne ili ga coordinator ne primi, smatra se da je taj Consumer napustio grupu, pa se Partition-e koje je on čitao prebacuju na ostale Consumer-e iste grupe — ovaj proces se naziva rebalance (ponovno balansiranje).

16. Uloga offset-a poruke u Kafci

Tokom proizvodnje, porukama u particiji se dodeljuje sekvencijalni ID broj, koji se naziva offset. Glavna uloga offset-a je da jedinstveno razlikuje svaku poruku u particiji. Kafka skladišni fajlovi se svi nazivaju po obrascu offset.kafka

17. Kada se u procesu proizvodnje javlja QueueFullException i kako se obrađuje

Kada se javlja

Kada producent pokuša da šalje poruke brže nego što Broker može da ih obradi, obično se javlja QueueFullException.

Kako rešiti

Prvo proceniti da li producent može usporiti brzinu proizvodnje; ako ne može, korisnik mora dodati dovoljno Broker-a da prihvati povećano opterećenje. Ili odabrati blokirajuću proizvodnju — postaviti Queue.enQueueTimeout.ms na -1; tada, ako je red pun, producent će blokirati umesto da odbacuje poruke. Ili tolerisati ovu izuzetak i odbaciti poruke.

18. Kako Consumer čita poruke iz zadate particije

Kada Consumer čita poruke, šalje Broker-u fetch zahtev da pročita poruke iz konkretne particije. Consumer može navesti offset poruke u logu i od te pozicije početi čitanje; pošto Consumer ima kontrolu nad offset-om, može se vratiti unazad i ponovo pročitati prethodne poruke.

Takođe se može koristiti seek(Long topicPartition) da se odabere pozicija čitanja.

19. Pojmovi Replica, Leader i Follower

Partition u Kafci je uređen log poruka. Da bi se ostvarila visoka dostupnost, koristi se mehanizam backup-a — isti podaci se kopiraju na više Broker-a, a ti backup log-ovi su Replica, sa ciljem sprečavanja gubitka podataka.

Podrazumevano, sve replike svih Partition-a se ravnomerno raspoređuju na sve Broker-e. Čim Broker na kojem se nalazi lider repluka padne, Kafka bira novog lidera iz follower repluka koji nastavlja da pruža uslugu.

Leader: lider među replikama. Odgovoran je za pružanje usluge ka spolja i interakciju sa klijentima. Producent uvek šalje poruke Leader repliki, a Consumer uvek čita poruke od Leader-a.

Follower: pratilac među replikama. Pasivno prati Leader-a i ne može komunicirati sa spoljnim svetom. Samo šalje zahteve Leader-u tražeći da mu pošalje najnovije proizvedene poruke, kako bi ostao u sinhronizaciji.

20. Značaj Replike

Replica osigurava da objavljene poruke ne budu izgubljene i garantuje visoku dostupnost Kafke. Takođe omogućava nesmetan rad pri bilo kakvim mašinskim greškama, greškama programa, ili nadogradnji softvera i proširenju kapaciteta.

21. Šta je Geo-Replication u Kafci

Kafka zvanično pruža MirrorMaker komponentu kao rešenje za sinhronizaciju podataka u toku kroz više klastera. Pomoću MirrorMaker-a, poruke se mogu replicirati kroz više data centara ili cloud regiona. Može se koristiti u aktivni/pasivni scenario za backup i oporavak, ili u aktivni/aktivni scenario da bi se podaci smestili bliže korisnicima, ili da podrži zahteve lokalizacije podataka.

Princip realizacije je jednostavan: poruke se čitaju iz izvornog klastera, a zatim proizvode u ciljni klaster — dakle reč je o običnoj proizvodnji i čitanju poruka. Korisnik samo kroz jednostavnu Consumer i Producer konfiguraciju, a zatim pokretanjem Mirror-a, može ostvariti kvazi-real-time sinhronizaciju podataka između klastera.

22. Pojmovi AR, ISR, OSR u Kafci

  • AR: sve replike u particiji se nazivaju AR
  • ISR: sve replike koje su u određenoj meri sinhronizovane sa master replikom (uključujući i master repliku) se nazivaju ISR
  • OSR: replike koje previše zaostaju za master replikom čine OSR

23. Kada replika particije ispada iz ISR-a

Leader održava listu replika koje su u suštini sinhronizovane sa njim — ta lista se zove ISR. Svaka Partition ima svoj ISR koji Leader dinamički održava. Dinamičko održavanje znači da ako Follower previše zaostaje za Leaderom, ili duže od određenog vremena nije poslao zahtev za kopiranjem podataka, Leader ga uklanja iz ISR-a. Tek kada sve replike iz ISR-a pošalju Leader-u ACK (Acknowledgement — potvrdu), Leader vrši commit.

24. Kako postupiti kada Leader replike padne, a ISR je prazan

Može se konfigurisati unclean.leader.election:

  • true: dozvoljava OSR-u da postane Leader, ali pošto je OSR porukama znatno zaostao, mogu se javiti problemi nekonzistentnosti poruka
  • false: čeka se dok se stari Leader ne oporavi, što smanjuje dostupnost

25. Kako proceniti da li je Broker još uvek validan

  1. Broker mora moći da održava konekciju sa ZooKeeper-om; Zookeeper putem heartbeat mehanizma proverava konekciju svakog čvora.
  2. Ako je Broker Follower, mora blagovremeno sinhronizovati write operacije Leader-a, bez prevelikog kašnjenja.

26. Koliko je maksimalno bajtova poruke koje Kafka može primiti i kako se menja

Podrazumevana maksimalna veličina poruke koju Kafka može primiti je 1000000 bajtova. Ako želite da je prilagodite, u Broker-u izmenite vrednost parametra Message.max.bytes.

Treba obratiti pažnju na to da, prilikom izmene ove vrednosti, i ostali odgovarajući parametri moraju biti ispravni, inače mogu nastati sistemski problemi. Pre svega, ova vrednost mora biti manja od parametra fetch.Message.max.bytes na strani potrošača (podrazumevana vrednost 1MB, označava maksimalan broj bajtova koje potrošač može pročitati) — inače će Broker blokirati jer potrošač ne može da iskoristi tu poruku.

27. ACK mehanizam Kafke

Kafka Producer ima tri ack mehanizma, sa vrednostima parametra 0, 1 i -1

  • 0: ekvivalentno asinhronoj operaciji — Producer ne zahteva od Leader-a odgovor; pošalje poruku i smatra da je uspeo, pa nastavlja sa sledećom (batch) porukom. Ovaj mehanizam ima najnižu latenciju, ali i najgoru postojanost i pouzdanost; pri padu servera velika je verovatnoća gubitka podataka.
  • 1: podrazumevana Kafka postavka. Znači da Producer čeka da Leader potvrdi uspešan prijem podataka pre nego što pošalje sledeću (batch) poruku. Međutim, ako Leader padne, a Follower još nije kopirao podatke, doći će do gubitka podataka. Ovaj mehanizam pruža dobru postojanost i nižu latenciju.
  • -1: Nakon što Leader primi poruku, mora tražiti od svih Follower-a iz ISR liste koji su u sinhronizaciji sa Leaderom da potvrde sinhronizaciju, pa tek onda Producer šalje sledeću (batch) poruku. Ovaj mehanizam ima najbolju postojanost i pouzdanost, ali i najgoru latenciju.

28. Kako Kafka consumer čita podatke

U Kafci, Producer gura poruke ka Broker-u; nakon što Consumer uspostavi konekciju sa Brokerom, aktivno Pull-a (odnosno Fetch-uje) poruke. Ovaj model ima nekoliko prednosti — prvo, Consumer može prema svojoj sposobnosti obrade blagovremeno fetch-ovati poruke i obraditi ih, i može kontrolisati napredak čitanja poruka (offset); osim toga, potrošač može kontrolisati broj poruka u svakom čitanju, ostvarujući batch čitanje.

29. Koje API-je Kafka pruža

Kafka pruža dva seta Consumer API, podeljena na High-level API i Sample API

Sample API

Ovo je API nižeg nivoa; održava konekciju sa jednim Broker-om i potpuno je stateless. Pri svakom zahtevu mora se navesti vrednost offset-a, pa je ovaj API i najfleksibilniji.

High-level API

Ovaj API enkapsulira pristup nizu Broker-a u klasteru i može transparentno čitati sledeći Topic. Sam održava stanje pročitanih poruka, odnosno pri svakom čitanju vraća sledeću poruku. High-level API takođe podržava čitanje Topic-a u grupama — ako Consumer-i imaju isto ime grupe, Kafka se ponaša kao queue message servis, a svaki Consumer ravnomerno čita podatke iz odgovarajuće Partition-e. Ako Consumer-i imaju različita imena grupa, Kafka se ponaša kao broadcast servis i emituje sve poruke Topic-a svakom Consumer-u.

30. Kako se podaci Partition-e iz Topic-a u Kafci čuvaju na disku

Više Partition-a iz Topic-a se čuvaju na Broker-u u obliku foldera; broj svake particije raste od 0, a poruke su uredne. U Partition folderu postoji više Segment-a (xxx.index, xxx.log); veličina Segment fajla odgovara veličini iz konfiguracionog fajla. Podrazumevano iznosi 1GB, ali se može prilagoditi prema potrebama. Kada prelazi 1GB, kreira se novi Segment koji se imenuje po offsetu poslednje poruke prethodnog Segment-a.

31. Kako Kafka, nakon kreiranja Topic-a, raspoređuje particije na različite Broker-e

Prilikom kreiranja Topic-a, Kafka raspoređuje particije na različite Broker-e po sledećim pravilima:

  1. Faktor replikacije ne sme biti veći od broja Broker-a.
  2. Pozicija prve replike prve particije (sa brojem 0) bira se slučajno iz Broker List-e.
  3. Pozicija prve replike ostalih particija se pomera redom u odnosu na nultu particiju. Drugim rečima, ako postoje 3 Broker-a i 3 particije, a pretpostavimo da je prva particija na drugom Broker-u, onda će druga biti na trećem Broker-u, treća na prvom Broker-u, i tako dalje. Položaj preostalih replika u odnosu na prvu repliku zapravo određuje nextReplicaShift, koji se takođe generiše slučajno.

32. Period zadržavanja logova i strategija čišćenja podataka u Kafci

Pojam

Period zadržavanja čuva sve objavljene poruke u Kafka klasteru; podaci čiji je period istekao se čiste prema strategiji čišćenja. Podrazumevano vreme zadržavanja je 7 dana; ako želite da ga promenite, u server.properties izmenite parametar log.retention.hours/minutes/ms.

Strategija čišćenja

  • Brisanje: log.cleanup.policy=delete znači da je omogućena strategija brisanja, što je i podrazumevana strategija. U početku se samo obeleži sa delete i fajl ne može biti indeksiran. Tek nakon isteka vremena definisanog parametrom log.Segment.delete.delay.ms, biće stvarno obrisan.
  • Kompresija: log.cleanup.policy=compact znači da je omogućena strategija kompresije — podaci se kompresuju tako da se čuva samo poslednja verzija podataka za svaki Key. Najpre se u konfiguraciji Broker-a postavlja log.cleaner.enable=true da se omogući cleaner; ovo je podrazumevano isključeno.

33. Kakav je format Message u Kafka logu za skladištenje

Jedna Kafka Message sastoji se od header-a fiksne dužine i promenljivog body-ja poruke. Pri čuvanju Message u logu koristi se format koji se razlikuje od formata poruke koju šalje Producer. Svaki log fajl je niz log entries (stavki loga):

  1. Svaki log entry sadrži četvorobajtni ceo broj (dužina Message-a, vrednost 1+4+N).
  2. Jednobajtni magic — magic označava verziju protokola Kafka servera za ovu objavu.
  3. Četvorobajtna CRC32 vrednost — CRC32 se koristi za proveru Message-a.
  4. Na kraju N bajtova podataka poruke. Svaka poruka ima jedinstveni 64-bitni offset unutar tekuće Partition-e.

Kafka ne ograničava veličinu pojedinačne poruke, ali se generalno preporučuje da ne prelazi 1MB; uobičajena veličina poruke je između 1 i 10KB.

34. Da li Kafka podržava multi-tenant izolaciju

Multi-tenant tehnologija (multi-tenancy technology) je softverska arhitektonska tehnika koja omogućava kako u okruženju sa više korisnika deliti isti sistem ili programske komponente, i pritom osigurati izolaciju podataka između pojedinačnih korisnika.

Rešenje

Multi-tenant se omogućava konfigurisanjem koji topic može proizvoditi ili čitati podatke; podržane su i operacije sa kvotama. Administrator može definisati i sprovesti kvote za zahteve, čime kontroliše Broker resurse koje klijent koristi.

35. Strategija segmentacije logova i strategija flush-a u Kafci

Strategija segmentacije logova (Segment)

  1. log.roll.hours/ms: period rotacije logova — kada se dostigne zadati period, prisilno se generiše novi Segment. Podrazumevano 168h (7 dana).
  2. log.Segment.bytes: maksimalni kapacitet svakog Segment-a. Kada se dostigne zadati kapacitet, prisilno se generiše novi Segment. Podrazumevano 1GB (-1 znači bez ograničenja).
  3. log.retention.check.interval.ms: period provere fajlova segmenata loga. Podrazumevano 60000ms.

Strategija flush-a logova

Kafka logovi se zapravo u početku nalaze u baferu, a zatim se na osnovu stvarnih konfigurisanih strategija periodicno upisuju u log fajlove radi povećanja propusnosti.

  1. log.flush.interval.Messages: kada broj poruka dostigne ovu vrednost, podaci se upisuju u log fajl. Podrazumevana vrednost 10000.
  2. log.flush.interval.ms: kada se dostigne ovo vreme, prisilno se izvršava jedan flush. Podrazumevana vrednost null.
  3. log.flush.scheduler.interval.ms: periodična provera da li je potrebno uraditi flush. Podrazumevano veoma velika vrednost.

36. Kako se vrši master-slave sinhronizacija u Kafci

Kafka dinamički održava skup replika u sinhronizovanom stanju (a set of In-Sync Replicas), skraćeno ISR. Čvorovi u ovom skupu su visoko konzistentni sa Leaderom; bilo koja poruka se smatra „potvrđenom" tek kada je svaki čvor iz ovog skupa pročita i doda u log.

Kafka konfiguriše producer.type da odredi da li je reč o asinhronom ili sinhronom režimu — podrazumevano je sinhrono.

Sinhrona replikacija

Producer prvo preko Zookeeper-a identifikuje Leader-a, a zatim šalje poruku Leaderu; Leader po prijemu poruke upisuje je u lokalni log fajl. Tada Follower Pull-uje poruke od Leadera; povučene poruke upisuje u lokalni log, a nakon upisivanja šalje Leaderu Ack potvrdu. Tek kada Leader primi Ack od svih Follower-a, šalje Ack potvrdu nazad Produceru.

Asinhrona replikacija

Asinhrono slanje poruka u Kafci se realizuje preko interfejsa za sinhrono slanje poruka. Implementacija asinhronog slanja je jednostavna — kada klijent pošalje poruku, ona se prvo stavi u BlackingQueue red, nakon čega se odmah vraća. Producer zatim pokreće nit ProducerSendTread koja stalno uzima poruke iz reda i poziva interfejs za sinhrono slanje kako bi poruke poslala Broker-u.

Ovaj Producer-ov pristup keširanja poruka u memoriji i batch slanja kada se dostigne prag smanjuje veliki broj malih I/O operacija; previše malih I/O-a bi usporilo ukupnu mrežnu latenciju, a batch slanje zapravo poboljšava mrežnu efikasnost. Međutim, ako Producer postane nedostupan pre dostizanja praga, podaci u baferu će biti izgubljeni.

37. U kojim situacijama u Kafki može doći do gubitka / nekonzistentnosti poruka

Pri slanju poruka

Slanje poruka ima dva načina: sinhrono - sync i asinhrono - async. Podrazumevano je sinhrono, a konfiguriše se svojstvom producer.type. Kafka može i konfiguracijom svojstva acks da potvrdi proizvodnju poruka.

  • 0: znači da se ne vrši potvrda da li je prijem uspeo
  • 1: znači potvrda kada leader uspešno primi poruku
  • -1: znači potvrda kada i leader i follower uspešno prime poruku

Kada je acks = 0, ne vrši se potvrda prijema sa Kafka-om, te zbog mrežnih grešaka ili punog bafera može doći do gubitka poruka.

Kada je acks = 1, samo je leader sinhronizovan uspešno, dok follower nije završio sinhronizaciju — ako leader padne, dolazi do gubitka podataka.

Pri čitanju poruka

Kafka ima dva consumer interfejsa za čitanje poruka, low-level i high-level

  1. low-level: potrošač sam održava offset i druge vrednosti, ostvarujući punu kontrolu nad Kafka-om
  2. high-level: enkapsulira particije i offset, jednostavan za korišćenje

Ako se koristi high-level interfejs, može se desiti da potrošač preuzme poruku i odmah komituje offset, a zatim padne pre nego što stigne da je obradi — pri sledećem čitanju krenuće od pozicije offset + 1, pa će poruka na prethodnom offset-u biti izgubljena.

38. Kafka kao platforma za stream processing

Stream processing znači kontinuirano, u realnom vremenu, istovremeno i zapis po zapis obraditi podatke. Kafka je distribuirana platforma za stream processing — njen visok protok, niska latencija, visoka pouzdanost, tolerantnost na greške i visoka skalabilnost čine je veoma pogodnom kao streaming platformu.

  1. To je jednostavna, laka Java biblioteka koja se može integrisati u bilo koju Java aplikaciju
  2. Osim Kafke nema nikakvih drugih zavisnosti; koristi Kafka-ov model particija za podršku horizontalnog skaliranja i garantovanje redosleda
  3. Podržava fault-tolerant lokalni state, omogućava veoma brze i efikasne stateful operacije
  4. Podržava exactly-once semantiku
  5. Podržava obradu po jedan zapis, ostvarujući latenciju na nivou milisekundi

39. Kako rešiti problem žive blokade (livelock) pri padu potrošača

Pojam livelock-a: potrošač stalno šalje heartbeat, ali ne obrađuje poruke.

Da bi se sprečilo da potrošač u ovom stanju trajno drži particiju, obično se koristi max.poll.interval.ms mehanizam za proveru aktivnosti — ako je učestalost poziva Poll veća od maksimalnog intervala, potrošač će sam napustiti grupu, kako bi drugi potrošači mogli preuzeti tu particiju.

40. Kako Kafka garantuje redosled čitanja

Jedinica čitanja u Kafci je Partition; unutar iste Partition koristi se offset kao jedinstveni identifikator za garantovanje redosleda. Ali to garantuje redosled samo unutar Partition-e, a ne unutar čitavog Topic-a. Zato, da bismo obezbedili redosled čitanja poruka, moramo sve poruke slati u istu Partition — pri slanju možemo navesti MessageKey, pa će poruke sa istim key-em ići u istu Partition.

Referentni link: https://mp.weixin.qq.com/s/1Mcm_vAq6Qv_pP-y0lPf0g, izvor: Cainong Days, obradio: Chenmo Wang Er