https://zookeeper.apache.org/doc/current/zookeeperOver.html
Ve výchozím nastavení Zookeeper replikuje všechna vaše data do každého uzlu a umožňuje klientům sledovat data kvůli změnám. Změny jsou klientům odesílány velmi rychle (v omezeném čase). Můžete také vytvořit "efemérní uzly", které jsou odstraněny během stanovené doby, pokud se klient odpojí. ZooKeeper je vysoce optimalizován pro čtení , zatímco zápisy jsou velmi pomalé (protože jsou obecně odesílány každému klientovi, jakmile dojde k zápisu). A konečně, maximální velikost "souboru" (znode) v Zookeeper je 1 MB, ale obvykle to budou jednotlivé řetězce.
Dohromady to znamená, že zookeeper není určen k ukládání velkého množství dat a už vůbec ne mezipaměti. Místo toho je to pro správu srdečních tepů/vědět, které servery jsou online, ukládání/aktualizaci konfigurace a případně předávání zpráv (ačkoli pokud máte velké #s zpráv nebo vysoké nároky na propustnost, něco jako RabbitMQ bude pro tento úkol mnohem lepší).
V zásadě ZooKeeper (a Curator, který je na něm postaven) pomáhá při manipulaci s mechanikou shlukování - srdeční frekvence, distribuce aktualizací/konfigurace, distribuované zámky atd.
Není to opravdu srovnatelné s Redis, ale pro konkrétní otázky...
-
Nepodporuje žádné výpočty a pro většinu datových souborů nebude moci ukládat data s jakýmkoli výkonem.
-
Replikuje se do všech uzlů v clusteru (neexistuje nic jako clustering Redis, kde lze distribuovat data). Všechny zprávy jsou plně atomicky zpracovávány a jsou sekvenovány, takže nedochází k žádným skutečným transakcím. Lze jej POUŽÍT k implementaci celoklastrových zámků pro vaše služby (ve skutečnosti je to velmi dobré) a na samotných znodech je spousta zamykacích primitiv, která řídí, které uzly k nim přistupují.
-
Jistě, ale ZooKeeper zaplňuje mezeru. Je to nástroj pro to, aby si distribuované aplikace pěkně hrály s více instancemi, ne pro ukládání/sdílení velkého množství dat. Ve srovnání s použitím IMDG pro tento účel bude Zookeeper rychlejší, spravuje srdeční tep a synchronizaci předvídatelným způsobem (se spoustou API pro usnadnění této části) a má „push“ paradigma místo „pull“, takže uzly jsou velmi rychle upozorněn na změny.
Citace z propojené otázky...
Kanonickým příkladem použití Zookeeper je výpočet s distribuovanou pamětí
... je, IMO, trochu zavádějící. Použili byste jej k orchestraci výpočtu, nikoli k poskytování dat. Řekněme například, že jste museli zpracovat řádky 1-100 tabulky. Můžete vložit 10 uzlů ZK s názvy jako "1-10", "11-20", "21-30" atd. Klientské aplikace by na tuto změnu byly automaticky upozorněny ZK a první by chytil " 1-10" a nastavte dočasný uzel clients/192.168.77.66/processing/rows_1_10
Další aplikace to uvidí a přejde ke zpracování další skupinou. Skutečná data pro výpočet by byla uložena jinde (tj. Redis, SQL databáze atd.). Pokud uzel v průběhu výpočtu selhal, mohl to vidět jiný uzel (po 30–60 sekundách) a znovu převzít úlohu.
Řekl bych, že kanonickým příkladem ZooKeeper je volba vůdce. Řekněme, že máte 3 uzly -- jeden je master a další 2 jsou podřízené. Pokud velitel sestoupí, novým vůdcem se musí stát otrokářský uzel. Tento typ věcí je ideální pro ZK.