Názory k článku Témata, oddíly a replikace v systému Apache Kafka
-
a což je docela škoda, zookeeper dělá obří kus práce pro stabilitu a spolehlivost celé kafky, KRaft je zatím docela peklo a chvilku potrvá než se ho dočkáme, nese všechny nevýhody raftu ve spojení s divným směřováním Confluentu.
Na jeden velký projekt jsme to s Confluentem testovali a zatím spíše palec dolu, není to na větší nasazení připravené, zatím řada bugů a problémů při vysokém zatížení.
-
Uzavírá se, snaží se trh přesvědčit, že Kafka je ideální event sourcing system, protlačuje Kafku s kappa architekturou, ale zapomíná na to nejdůležitější, kafka nemá transakce, partitions se mohou časově dost rozcházet a jejich zpracování je postupné.
Celá aktivita Confluentu dost křiví trh, je to takové náboženství, kdy se více věří marketingovým proklamacím než technickým vlastnostem.
-
tak jasně, tlačí svůj produkt. My jsme ještě uvažovali o NATSu, ale Kafka kupodivu vychází líp, co se týče praktického produkčního nasazení.
re Kappa architektura: no o té jsem četl, ale to chce úplně převrátit to, jak je systém navrženej :-) a na to nikdo tady nemá koule to protlačit. Nehledě na to, že to asi v praxi vyžaduje šíleně dlouhé retence, určitě víc než naše tři dny :-)
-
Pavel TišnovskýZlatý podporovatelTo je do značné míry konfigurovatelné a *vždy* to závisí na kooperaci producenta. Zejména producent si může vynutit ack zprávy až ve chvíli, kdy ji přijme leader. To je první věc, kterou je možné nastavit (ack je běžně nastavený na nulu/false).
Dále je možné si vyžádat ack až ve chvíli, kdy ji přijmou všechny ISR (tedy in-sync replikas v daný okamžik). tím se zaručí, že i když leader zhavaruje, bude ve všech online replikách. Jde tam ještě nastavit minimální počet ISR, takže to nemusí být všechny (ale konfig.option z hlavy nedám).
Potom je možné si přes unclean.leader.election=false vynutit, aby se leaderem nikdy nestala replika, který není ISR. To může vést k situaci, kdy se "Kafka zastaví" ve chvíli, kdy se brokeři připojují a odpojují a žádný není ISR.
-
Pavel: pozor na unclean.leader.election=false, je to velice nebezpečné na stabilitu a jak píšeš, může to vést k nefunkčnosti celé kafky jen kvůli nemožnosti u nějaké partition zvolit leadera. Lepší buď změnit proces election vlastní implementací nebo jen monitorovat, kdy se leaderem stalo non ISR a data poslat znovu nebo je naopak vytáhnout z jiných partition. Chce to vždy pečlivě zvažovat při každém nasazení.
-
Pavel TišnovskýZlatý podporovatel
Díky moc za doplnění. Je to přesně tak, hlavně když se "podaří" konfigurací rozmístit repliky do brokerů tak, že vznikne smyčka.
-
To si určuješ sám v publisheru, option acks řiká na kolik replik čekáš než se ti vrátí operace jako úspěšně poslaná, zbytek replik je poté asynchronních.
Po pádu leadera proběhne volba nového leadera pro všechny partition, který leader vlastnil, dokud není zvolen nový leader, do partition se nemůže zapisovat. Volba je vesměs náhodná, je ale možnost jí upravit dle vlastních potřeb, což i děláme.
Při volbě nového leadera může dojít ke ztrátě zpráv, pokud byl zvolen leader s partition, která je out of sync (tj. zatím neproběhla asynchronní replikace a synchronní producer nevyžadova). Tohle je tradeoff mezi spolehlivostí a dostupností a je potřeba to při každém nasazení promyslet.
Při zápisu pak díky tomu může dojít k situaci, kdy ti acks=all selže, protože zrovna jeden broker není dostupný, ale data se fyzicky stihnou všude zapsat. Ty je pak zkusíš poslat znovu a dojde k duplicitě. Opět je to věc, s kterou musíš aplikačně počítat.
