Názory k článku Nástroj MirrorMaker pro Apache Kafku

A právě na základě předaného klíče se vypočítá hash a algoritmus implementovaný v samotném brokeru rozhodne, do kterého oddílu bude zpráva uložena:

^^^
Opravte ma ak sa mýlim, ale myslím, že hash kľúča počíta producer a nie broker. Tak isto je zodpovednosť producera, do ktorej partition ,resp. ktorému brokerovi správu pošle.

nemílíš se, hash opravdu počítá producer, resp. rozhoduje podle svého nastavení do které partition data patří a takovému brokerovi je i sám pošle. Broker je v tomhle případě jen nosiš vody, vyhýbá se jakkékoliv výpočetní operaci.

máte pravdu, opravím to. Díky za upozornění

opraveno

Předpokládám, že tam budou nějaké delaye. Teď nemyslím kvůli networkingu, to je jasný, ale vůbec principem práce toho MM (a connectorech).

A co se stane při rozpadu spojení? Asi nic moc, protože se zapamatují poslední offsety a bude se pokračovat dál po navázání spojení, že?

ano i ne.

Celá kafka je založena na tom, že broker drží offsety posledních zpracovaných zpráv pro každou partition a každou consumer group. Consumer je pak odpovědný za to, aby poslal ve správný okamžit "ack" a tím posunul offset a tady je to úskalí a rozdíl jednotlivých implementací a použití.

MM2 posílá ack asynchronně vzhledem ke zpracování, pokud zpracovává hodně zpráv, vynechává ack (to se ale nedávno změnilo v nové verzi již nevynechává tak extrémně). Oři jakémkoliv výpadku tedy hrozí situace, kdy poslední zprávy mohou být zpracované, ale offset neposunutý. Existuje riziko tedy dvojitého zpracování, s tím chce počítat a při replikaci to tolik nemusí vadit.

Pokud jde jen o výpadek tcp spojení, tak to se zkouší navazovat opakovaně a pokud je doba dostatečně krátká, bez problémů pokračuje v práci.

ok díky. Takže to zaručuje "at least delivery". Jo v praxi to asi moc nevadí, pokud mají správy nějaký uniq. ID.

správně, pokud mají uniq ID. To kafka sama neřeší, používá message id jen jako vstup pro hash, z kterého jí vypadne partition (což je ale opět na straně producera, takže to může být jakkoliv).

Samotný kafka broker identifikuje zprávu jako kombinaci partition a offset, to je dost alibistické, ale dostatečně funkční.

Ke kafce musíš (můj názor) vždy mít nějakou formu deduplikace a to si musíš řešit vlastní cestou ideálně uvnitř dat. Kafka udělá vše, aby ti to nějak doručila.

Stejně tak je velký problém na straně producera, nemusí totiž vůbec dojít k řádnému odeslání do kafky (referenční implementaci producera třeba spoustu věcí bufferuje a nemusí se stihnout vše odeslat než ukončíš samotná proces).

MM2 celý problém duplicitních zpráv znásobuje. Bohužel jsem už viděl, že někdo posílá kafkou changesety (např. přičti 1), jak je zvyklý z event systémů. To nedělejte.

jj v pohodě. já jen ze začátku nevěděl jestli MM zaručuje at least once delivery nebo at most once delivery

"Bohužel jsem už viděl, že někdo posílá kafkou changesety (např. přičti 1)"

No to určitě nemůže dobře fungovat :-) Kafka obecně nezaručuje pořadí zpráv ani jednoznačné doručení. A už vůbec ne, pokud má víc oddílů .

"broker drží offsety posledních zpracovaných zpráv pro každou partition a každou consumer group" je zcela pravda, ale je možné si je ukládat i "bokem", protože offsety jsou starostí konzumenta (nebo jeho skupiny). Viděl jsem takové řešení, že offsety šly někam do Redisu, ale už si nevzpomínám přesný důvod. Resp. bylo to v době, kdy se offsety ukládaly na Zookepera, tak jestli tehdy nebyly problémy tady.

To už je pěknou řádku let, kdy offsety byly plně na starosti konzumenta, od kafky 0.8 je práce s offsety součástí consumer api. Kafka je občas obětí neskutečné zpětné kompatibility.

Consumer api poskytuje možnost skákat po offsetech, takže i dnes mám možnost si offsety držet bokem a dává to občas smysl, zejména, když potřebuji přecházet mezi více stavy (např. načteno, zařazeno do fronty, zpracováno, dokončeno). Skákání by ale mělo být lineární, broker vyloženě nesnáží náhodný přístup.

Zookeeper je pořád jediná spolehlivá cesta jak provozovat kafku a Confluent má stále ještě v jeho revoluční změně zásadní nedostatky.

Zookeeper je pro hodně lidí velice složitý na provoz, je to java svět s kerberosem, na kterém si kdokoliv mimo javistů vyláme zuby. V téhle konstelaci bych čekal použití redisu a už jsem to i tak viděl, nikdy jsem ale nepřišel na obhajitelnou výhodu, to už raději použiji sql databázi.

Ďakujem za prínosný článok aj diskusiu. Zrovna sa snažím vymyslieť fungovanie aplikácie s Kafkou replikovanou na dvoch prostrediach pre disaster recovery / high availability cez MirrorMaker2. Aktívne bude vždy len jedno prostredie. Po prepnutí prostredia by sa nemali stratiť nespracované správy z prvého (a rovnako pri prepnutí späť). Takže každé prostredie bude mať základné topiky a ich mirrorované verzie, na ktorých bude chcieť spracovať len správy nespracované v ich pôvodnom prostredí. Databáza aplikácie sa replikuje tiež.

Má prosím niekto skúsenosti s takýmto prostredím? Asi hlavne ako sa vyhnút duplicitnému spracovaniu správ (na oboch prostrediach) a zároveň spracovať správy, ktoré sa "nestihli spracovať" na tom druhom. Používať na to nejaké ID správ, alebo nejaký semafor určujúci, ktoré prostredie spracováva správy?

nevyhýbej se tomu, abys zprávy zpracoval vícekrát, Kafka je tak navržená a pokud se to budeš snažit vyřešit, uděláš si ještě větší problémy.

Máš tři možnosti, nepoužít kafku nebo si držet v jiné HA databázi s strong consistency informaci, co jsi zpracoval a co ne. Při konzumaci pak zjistíš, co zpracovat a co prostě ignorovat.

Třetí možnost je navrhnout aplikaci tak, aby opakované zpracování vedle ke stejnému stavu. Kafka třeba není vhodná jako fronta (posílání emailů, notifikace).

jako ze by ackoval a soucasne si ukladal offsety do jine DB v transakci? To Kafka asi neda

nikoliv offsety, ale nějaké unikátní id z vnitřku zprávy. Offsety jsou interní implementací kafky, jsou unikátní pouze v rámci partition a třeba v případě restoru se mohou přečíslovat.

1. Odebereš bulk zpráv z kafky
2. vyloučíš ty, které mají v tvé db již stav in-progress a done
3. uložíš si jejich id do vlastní db se stavem in-progress
4. zpracuješ zprávy
5. změníš si ve vlastní db stav na done
6. uděláš ack do kafky

Na pozadí můžeš mít nějaký pravidelný proces, který bude řešit co se zprávami, které mají příliš dlouho stav in-progress. Jestli je znovu načíst z kafky, jestli je vytáhnout z nějaké tvé db, jestli je znovu zpracovat či ověřit, proč se nezpracovaly. Pokud se ti problémy povede vyřešit, buď je zpracuješ přímo nebo je šoupneš do kafky jako nové zprávy a necháš je znovu projít tím procesem.

Zajistíš si deduplikaci, kafka si můžeš zprávy posílat znovu, tvůj consumer strana se nebude moci zaseknout na nevalidní zprávě a budeš mít proces, jak znovu poslat do zpracování nevalidní či opravenou zprávu. Nad tím můžeš mít reporting a grafování kolik zpráv je v in-progress, kolik jich je dokončených a k tomu nějaké alerty, když se zprávy přestanou dokončovat.

Když už se tu v komentářích tak často objevuje ta Kafka, připomnělo mi to vtip:

- Jaký je rozdíl mezi technooptimistou a technopesimistou?
- Technooptimista si myslí, že Apacha Kafka se jmenuje podle roztomilýho ptáčka. Technopesimista ví, že se jmenuje podle Franze Kafky.

:-)

dobry, to nekdy v praci pouziju!