Vlákno názorů k článku Použití databáze Redis v aplikacích naprogramovaných v Go od M_D - Řekl bych, že to HA s použitím Sentinelu...

Řekl bych, že to HA s použitím Sentinelu je trochu na pozadí vůči Redis Clusteru, ale pokud se dodrží pár podmínek, tak ten Redis+Sentinel se dá používat s doboru mírou spolehlivosti - mít to v režímu master+2 repliky, nastaveno, že master odmítá, pokud není dostupná aspoň jedna replika, poslané dávky příkazů pak završit pomocí WAIT s požadavkem na aspoň 2 repliky (čili uloženo na masteur a aspoň jedné replice), případně si po uložneí důležitějších věcí vysloveně vyžádat sync na disk a ten mít nejlépe v režimu AOF.
V podstatě se Redis v5+Sentinel dá použít i jako in RAM "náhrada" za Apache Kafku s použitím streamů (přímo uvádí, že se jí v tomto inspirovali), což je celkem příjemné, protože to jde provozovat v podstatě i v embedded prostředí, kde celou tu Kafku+ZooKeeper nemám ani šanci na těch střepech spustit.
Dá se něco i celkem pořešit pomocí disque, což je na podkladu Redisu distribuovaný msg brooker, dneska míří ze stand alone appky jako modul do Redis Clusteru.

Diky za doplneni. Mate prosim blizsi info o te nahrade Kafky? Mame s ni dost problemy (autocommity zlobi napriklad) a tak bych si mohl zkusit PoC s Redisem.

Asi k tomu je nejrozumnější základní popis zde: https://redis.io/topics/streams-intro
Sice je v té implementaci prá věcí, co mě štve, ale dá se s tím smířit.

A když vezmu, tak se dá Redis využít i jako náhrada toho ZooKeeperu, pokud jsem ho použíava jako úložiště konfiguraci a možností async informování klientů, že se nějaká položka v DB změnila. Slouží k tomu v Redisu funkcionalita "Client side caching". Nezkoušel bych to v případě spojení z klienta pomocí RESP3 protokolu (moc horká novinka, nikdy nelátáme ve verzi 1.0A :-) ), ale nad klasickým RESP2 s dvojím připojením a notifikací o změnách přes SUBSCRIBE __redis__:inva­lidate vypadá již OK ( https://redis.io/topics/client-side-caching ).

Moc diky prozkoumam a pohraju si s tim.