Jaké otázky o Kafka mohu u pohovoru očekávat?

Už víte, že Kafka je distribuovaný protokol, a obáváte se, že tazatel půjde o úroveň hlouběji než vaše každodenní používání. Právě tam tyto otázky míří, proto tato část probírá pojmy v pořadí, v jakém je tazatelé obvykle otevírají, a upozorňuje na doplňující otázku za každým termínem.

• Témata a oddíly. Téma se dělí na oddíly, z nichž každý je seřazeným protokolem, do něhož lze pouze přidávat. Doplňující otázka: proč Kafka škáluje zápisy přidáváním oddílů místo zrychlování jediného protokolu?
• Offsety. Pozice konzumenta v oddílu. Doplňující otázka: kdo ukládá potvrzené offsety a co se stane, když konzument před potvrzením selže?
• Skupiny konzumentů. Konzumenti ve skupině si rozdělují oddíly tématu, přičemž každý oddíl může v daném okamžiku připadat nejvýše jednomu konzumentovi ve skupině. Doplňující otázka: co se stane s propustností, pokud má skupina více konzumentů než oddílů?
• Brokery a řadič. Brokery ukládají oddíly; řadič zajišťuje volbu vedoucí repliky a metadata. Doplňující otázka: co se změnilo, když Kafka přesunula metadata ze ZooKeeper na KRaft?
• Producenti a klíče. Zpráva s klíčem skončí v oddílu zvoleném pomocí hashe klíče; zpráva bez klíče se přiřadí mezi oddíly. Doplňující otázka: která z těchto možností zachová pořadí událostí jednoho zákazníka?

Odpovídejte mechanismem, ne sloganem. Říct, že oddíly umožňují paralelismus, je naprostý základ; vysvětlení, že pořadí existuje pouze uvnitř oddílu, a klíč proto určuje oblast platnosti pořadí, je odpověď, která vás posune do dalšího kola.

V této vrstvě většina uchazečů ztrácí body, protože pojmy jsou snadné, ale kompromisy nikoli. Očekávejte, že tazatel uvede určitou záruku a požádá vás, abyste ji sestavili pomocí nastavení.

• Nejvýše jednou oproti alespoň jednou. Potvrďte offset před zpracováním a můžete zprávu ztratit; nejprve ji zpracujte a potvrďte až poté a můžete ji zpracovat dvakrát. Uveďte, jaké selhání každé pořadí toleruje a kterému dává váš systém přednost.
• Idempotentní producenti a právě jednou. Idempotentní producent odstraňuje duplicitní opakované pokusy uvnitř oddílu; transakce tuto vlastnost rozšiřují napříč oddíly a na offsety konzumentů ve smyčce načíst–transformovat–vytvořit. Buďte připraveni říct, co zpracování právě jednou nepokrývá: zápis do navazující databáze mimo transakci je stále váš problém.
• Potvrzení, replikační faktor a synchronizované repliky. acks=all čeká na sadu synchronizovaných replik; min.insync.replicas určuje, na jak malý počet se tato sada smí zmenšit, než budou zápisy odmítnuty. Tazatelé se často ptají, co zde obětujete ve prospěch odolnosti dat: latenci a dostupnost během výpadku brokeru.
• Uchovávání a kompakce. Uchovávání podle času nebo velikosti odstraňuje staré segmenty; kompakce protokolu zachovává nejnovější záznam pro každý klíč. Doplňující otázka: která možnost podporuje protokol změn pro úložiště klíč–hodnota a proč?
• Vyvažování. Když se konzument připojí nebo odejde, oddíly se znovu přidělí. Doplňující otázka: jak dlouhé vyvažování ovlivní službu citlivou na latenci a jak spolupracující vyvažování a statické členství zmírňují jeho dopad?

Užitečný návyk: u každého nastavení, které zmíníte, uveďte selhání, jemuž brání, a cenu, kterou přidává. Tato struktura zodpoví otázku i její pokračování jedním dechem.

Ve výběrových kolech na seniorní pozice definice nahrazují scénáře, na nichž tazatel sleduje vaše uvažování. Typické zadání: backendový vývojář ucházející se o platformní roli v platební společnosti má navrhnout datový tok událostí, kde musí být každá transakce jednoho účtu zpracována ve správném pořadí, propustnost musí růst s provozem a výpadek brokeru nesmí způsobit ztrátu dat. Silná odpověď přiřadí zprávám klíč podle identifikátoru účtu, aby události jednoho účtu sdílely oddíl, stanoví počet oddílů pro očekávanou špičku s rezervou pro růst, nastaví replikaci a acks=all kvůli odolnosti dat a vysvětlí, jak konzumenti potvrzují offsety, aby se data po selhání přehrála, nikoli přeskočila.

Další opakující se scénáře: opožďující se konzument a způsob, jak zjistit jeho zpoždění a dohnat ho; téma s počtem oddílů, kterého litujete, a důvod, proč nové rozdělení naruší pořadí podle klíče; škodlivá zpráva, která způsobuje pád konzumenta, a vzor fronty nedoručitelných zpráv, který ji izoluje; změny schématu napříč producenty a konzumenty a přínos registru schémat. Tazatel nehledá jedinou správnou architekturu. Chce, abyste pojmenovali omezení, zvolili mechanismus a nahlas uvedli kompromis.

Před pohovorem si tyto odpovědi procvičujte nahlas, místo abyste je jen četli. K nácviku scénářů s AI tazatelem, který pokládá doplňující otázky, slouží režim procvičování na stránce simulovaného pohovoru a širší sada bank otázek podle rolí a témat je na stránce otázek k pohovoru podle role a tématu.

V konverzačním kole ano, v poctivě vymezených mezích. Nativní desktopová aplikace SubcueAI pro macOS a Windows zachycuje zvuk tazatele i váš mikrofon a zobrazuje krátké návrhy odpovědí v místním překryvném okně. Když se tedy tazatel zeptá, před čím chrání min.insync.replicas, mechanismus máte na obrazovce a můžete jej vysvětlit vlastními slovy. Rozšíření prohlížeče nabízí totéž pro hovory na kartě prohlížeče a zachycuje pouze zvuk z karty se schůzkou. Ani jedna varianta nepřidává do hovoru bota ani nic nevkládá do stránky schůzky; postup nastavení najdete na stránce návodu.

Omezení jsou důležitější než marketing. Kontrolovaný programátorský test, nahrávání obrazovky nebo firemně spravovaný notebook jsou mimo rozsah použití a živé programovací cvičení, během kterého musíte pod dohledem implementovat konzumenta, je pouze vaší prací. Asistent je nejsilnější u výše uvedených otázek na terminologii a kompromisy a nejslabší u všeho, co se zadává do hodnoticí platformy. Než se na něj spolehnete, poskytněte mu svůj životopis, aby návrhy odpovídaly práci s Kafka, kterou jste skutečně vykonávali; tento profil najdete v nástroji pro tvorbu životopisu.