Vlákno názorů k článku Nástroj MirrorMaker pro Apache Kafku od Ján Halaša - Ďakujem za prínosný článok aj diskusiu. Zrovna sa...

Ď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.