Navrhuji, abyste si přečetli přepis přednášky "Hadoop. ZooKeeper" ze série "Metody pro distribuované zpracování velkých objemů dat v Hadoopu"
Co je ZooKeeper, jeho místo v ekosystému Hadoop. Nepravdy o distribuovaném počítání. Schéma standardního distribuovaného systému. Potíže s koordinací distribuovaných systémů. Typické problémy s koordinací. Principy návrhu ZooKeeperu. Datový model ZooKeeper. příznaky znode. Relace. Klientské rozhraní API. Primitiva (konfigurace, členství ve skupině, jednoduché zámky, volba vůdce, zamykání bez stádního efektu). Architektura ZooKeeper. ZooKeeper DB. ZAB. Zpracovatel žádosti.
Dnes budeme mluvit o ZooKeeper. Tato věc je velmi užitečná. Stejně jako každý produkt Apache Hadoop má logo. Zobrazuje muže.
Před tím jsme si povídali hlavně o tom, jak se tam dají data zpracovávat, jak je uchovávat, tedy jak je nějak využít a nějak s nimi pracovat. A dnes bych chtěl trochu mluvit o vytváření distribuovaných aplikací. A ZooKeeper je jednou z věcí, které vám umožňují zjednodušit tuto záležitost. Jedná se o druh služby, která je určena pro jakousi koordinaci interakce procesů v distribuovaných systémech, v distribuovaných aplikacích.
Potřeba takových aplikací je každým dnem stále větší, o tom je náš kurz. Na jedné straně vám MapReduce a tento hotový rámec umožňuje vyrovnat tuto složitost a osvobodit programátora od primitiv psaní, jako je interakce a koordinace procesů. Ale na druhou stranu nikdo nezaručí, že se to stejně nebude muset udělat. MapReduce nebo jiné hotové frameworky ne vždy zcela nahrazují některé případy, které nelze pomocí tohoto implementovat. Včetně samotného MapReduce a spousty dalších projektů Apache; ve skutečnosti jsou to také distribuované aplikace. A aby bylo psaní jednodušší, napsali ZooKeeper.
Stejně jako všechny aplikace související s Hadoopem byl vyvinut společností Yahoo! Nyní je to také oficiální aplikace Apache. Není tak aktivně vyvíjen jako HBase. Pokud půjdete do JIRA HBase, tak se každý den objeví hromada hlášení o chybách, hromada návrhů na optimalizaci něčeho, tedy život v projektu neustále běží. A ZooKeeper je na jednu stranu poměrně jednoduchý produkt a na druhou stranu to zajišťuje jeho spolehlivost. A jeho použití je poměrně snadné, a proto se stalo standardem v aplikacích v rámci ekosystému Hadoop. Tak jsem si řekl, že by bylo užitečné si to prohlédnout, abych pochopil, jak to funguje a jak to používat.
Toto je obrázek z nějaké přednášky, kterou jsme měli. Dá se říci, že je ortogonální ke všemu, co jsme dosud uvažovali. A vše, co je zde uvedeno, v té či oné míře funguje se ZooKeeperem, tedy je to služba, která využívá všechny tyto produkty. HDFS ani MapReduce nepíší své vlastní podobné služby, které by pro ně konkrétně fungovaly. V souladu s tím se používá ZooKeeper. A to zjednodušuje vývoj a některé věci související s chybami.
Odkud to všechno pochází? Zdálo by se, že jsme spustili dvě aplikace paralelně na různých počítačích, propojili je provázkem nebo do sítě a vše funguje. Problém je ale v tom, že Síť je nespolehlivá, a pokud jste šňupali provoz nebo se podívali na to, co se tam děje na nízké úrovni, jak klienti na Síti komunikují, často můžete vidět, že některé pakety jsou ztraceny nebo znovu odeslány. Ne nadarmo byly vynalezeny protokoly TCP, které umožňují vytvořit určitou relaci a zaručit doručení zpráv. Ale v každém případě ani TCP vás nemůže vždy zachránit. Vše má časový limit. Síť může na chvíli jednoduše spadnout. Může to jen blikat. A to vše vede k tomu, že se nemůžete spolehnout na spolehlivost sítě. To je hlavní rozdíl oproti psaní paralelních aplikací, které běží na jednom počítači nebo na jednom superpočítači, kde není síť, kde je v paměti spolehlivější sběrnice pro výměnu dat. A to je zásadní rozdíl.
Mimo jiné je při používání Sítě vždy určitá latence. Disk to má taky, ale Síť toho má víc. Latence je určitá doba zpoždění, která může být malá nebo poměrně významná.
Topologie sítě se mění. Co je topologie - to je umístění našich síťových zařízení. Jsou tam datová centra, jsou tam stojany, které tam stojí, jsou tam svíčky. To vše lze znovu připojit, přesunout atd. S tím vším je také potřeba počítat. Mění se IP jména, mění se směrování, kterým náš provoz putuje. I to je potřeba vzít v úvahu.
Síť se může změnit i z hlediska vybavení. Z praxe mohu říci, že naši síťoví inženýři opravdu rádi pravidelně něco na svíčkách aktualizují. Najednou vyšel nový firmware a nějak zvlášť je nezajímal nějaký Hadoop cluster. Mají vlastní práci. Pro ně je hlavní, že Síť funguje. Proto tam chtějí něco znovu nahrát, provést flashování na svém hardwaru a hardware se také pravidelně mění. S tím vším je třeba nějak počítat. To vše ovlivňuje naši distribuovanou aplikaci.
Obvykle lidé, kteří z nějakého důvodu začnou pracovat s velkým množstvím dat, věří, že internet je neomezený. Pokud tam je soubor o několika terabajtech, můžete jej přenést na server nebo počítač a otevřít pomocí kočka a dívat se. Další chyba je v Elán podívejte se na protokoly. Nikdy to nedělejte, protože je to špatné. Vim se totiž snaží vše ukládat do vyrovnávací paměti, načítat vše do paměti, zvláště když začneme procházet tímto logem a něco hledat. To jsou věci, na které se zapomíná, ale stojí za zvážení.
Je jednodušší napsat jeden program, který běží na jednom počítači s jedním procesorem.
Až náš systém poroste, chceme to všechno paralelizovat a paralelizovat nejen na počítači, ale také na clusteru. Nabízí se otázka: jak tuto záležitost koordinovat? Naše aplikace spolu možná ani neinteragují, ale spustili jsme několik procesů paralelně na několika serverech. A jak hlídat, aby jim vše klapalo? Například něco pošlou přes internet. Musí někde psát o svém stavu, například v nějaké databázi nebo logu, pak tento log agregovat a pak někde analyzovat. Navíc musíme vzít v úvahu, že proces fungoval a fungoval, najednou se v něm objevila nějaká chyba nebo se zhroutil, jak rychle se to pak dozvíme?
Je jasné, že to vše lze rychle sledovat. To je také dobré, ale monitorování je omezená věc, která vám umožňuje sledovat některé věci na nejvyšší úrovni.
Když chceme, aby se naše procesy začaly vzájemně ovlivňovat, například si posílat nějaká data, pak také vyvstává otázka – jak se to stane? Dojde k nějakému race condition, budou se navzájem přepisovat, dorazí data správně, ztratí se cestou něco? Musíme vyvinout nějaký druh protokolu atd.
Koordinace všech těchto procesů není triviální věc. A nutí vývojáře sestoupit na ještě nižší úroveň a psát systémy buď od nuly, nebo ne úplně od nuly, ale to není tak jednoduché.
Pokud přijdete s kryptografickým algoritmem nebo jej dokonce implementujete, okamžitě ho zahoďte, protože vám s největší pravděpodobností nebude fungovat. S největší pravděpodobností bude obsahovat spoustu chyb, které jste zapomněli poskytnout. Nikdy jej nepoužívejte na nic vážného, protože bude s největší pravděpodobností nestabilní. Protože všechny existující algoritmy byly testovány časem po velmi dlouhou dobu. Je to odposloucháváno komunitou. Toto je samostatné téma. A tady je to stejné. Pokud je možné neimplementovat nějakou synchronizaci procesů sami, pak je lepší to nedělat, protože je to poměrně komplikované a vede vás to nejistou cestou neustálého hledání chyb.
Dnes mluvíme o ZooKeeper. Na jednu stranu je to framework, na druhou stranu je to služba, která developerovi usnadňuje život a maximálně zjednodušuje implementaci logiky a koordinace našich procesů.
Připomeňme si, jak může vypadat standardní distribuovaný systém. To je to, o čem jsme mluvili - HDFS, HBase. Existuje hlavní proces, který řídí pracovníky a podřízené procesy. Je zodpovědný za koordinaci a distribuci úkolů, restartování pracovníků, spouštění nových a distribuci zátěže.
Pokročilejší věcí je koordinační služba, tedy přesunout samotnou koordinační úlohu do samostatného procesu, plus paralelně spustit nějaký záložní nebo pohotovostní Master, protože Master může selhat. A pokud Mistr spadne, náš systém nebude fungovat. Spouštíme zálohování. Některé uvádí, že Master musí být replikován do zálohy. To může být také svěřeno koordinační službě. Ale v tomto diagramu je za koordinaci pracovníků zodpovědný sám Master, zde služba koordinuje aktivity replikace dat.
Pokročilejší možností je, když veškerou koordinaci zajišťuje naše služba, jak se obvykle dělá. Přebírá odpovědnost za to, že vše funguje. A pokud něco nefunguje, zjistíme to a pokusíme se tuto situaci obejít. V každém případě nám zbývá Mistr, který nějak interaguje s otroky a může posílat data, informace, zprávy atd. prostřednictvím nějaké služby.
Existuje ještě pokročilejší schéma, kdy nemáme Mastera, všechny uzly jsou master slave, liší se svým chováním. Stále však potřebují vzájemně komunikovat, takže stále zbývá nějaká služba, která tyto akce koordinuje. Pravděpodobně Cassandra, která funguje na tomto principu, do tohoto schématu zapadá.
Těžko říct, které z těchto schémat funguje lépe. Každý má své pro a proti.
A není třeba se některých věcí s Mistrem bát, protože, jak ukazuje praxe, není tak náchylný k neustálé službě. Zde jde především o to vybrat správné řešení pro hostování této služby na samostatném výkonném uzlu, aby měla dostatek prostředků, aby tam pokud možno neměli uživatelé přístup, aby tento proces náhodou nezabili. Zároveň je ale v takovém schématu mnohem snazší řídit pracovníky z Master procesu, to znamená, že toto schéma je z hlediska implementace jednodušší.
A toto schéma (výše) je pravděpodobně složitější, ale spolehlivější.
Hlavním problémem jsou dílčí poruchy. Když například posíláme zprávu přes síť, dojde k nějaké nehodě a ten, kdo zprávu odeslal, nebude vědět, zda byla jeho zpráva přijata a co se stalo na straně příjemce, nebude vědět, zda byla zpráva zpracována správně. , tedy nedostane žádné potvrzení.
Podle toho musíme tuto situaci zpracovat. A nejjednodušší je odeslat tuto zprávu znovu a počkat, až obdržíme odpověď. V tomto případě se nebere v úvahu, zda se změnil stav přijímače. Můžeme poslat zprávu a přidat stejná data dvakrát.
ZooKeeper nabízí způsoby, jak se s takovým odmítnutím vypořádat, což nám také usnadňuje život.
Jak již bylo zmíněno trochu dříve, je to podobné psaní vícevláknových programů, ale hlavní rozdíl je v tom, že v distribuovaných aplikacích, které stavíme na různých strojích, je jediným způsobem komunikace síť. V podstatě se jedná o sdílenou architekturu. Každý proces nebo služba, která běží na jednom stroji, má vlastní paměť, svůj disk, svůj procesor, který s nikým nesdílí.
Pokud na jednom počítači napíšeme vícevláknový program, pak můžeme pro výměnu dat využít sdílenou paměť. Máme tam přepínač kontextu, procesy se mohou přepínat. To ovlivňuje výkon. Na jednu stranu nic takového v programu na clusteru není, ale problémy se sítí jsou.
V souladu s tím jsou hlavní problémy, které vznikají při psaní distribuovaných systémů, konfigurace. Píšeme nějakou aplikaci. Pokud je to jednoduché, pak v kódu natvrdo zakódujeme nejrůznější čísla, ale to je nepohodlné, protože pokud se rozhodneme, že místo časového limitu půl sekundy chceme časový limit jednu sekundu, musíme aplikaci překompilovat a vše znovu vyklopit. Jedna věc je, když je to na jednom počítači, když ho můžete restartovat, ale když máme mnoho strojů, musíme neustále kopírovat všechno. Musíme se pokusit, aby byla aplikace konfigurovatelná.
Zde mluvíme o statické konfiguraci pro systémové procesy. Není to úplně, možná z pohledu operačního systému se může jednat o statickou konfiguraci pro naše procesy, tedy o konfiguraci, kterou nelze jednoduše vzít a aktualizovat.
K dispozici je také dynamická konfigurace. To jsou parametry, které chceme za chodu měnit, aby se tam vychytaly.
Co je tady za problém? Aktualizovali jsme konfiguraci, spustili ji, tak co? Problém může být v tom, že jsme na jednu stranu config rozjeli, ale na novou věc zapomněli, config tam zůstal. Za druhé, když jsme zaváděli, konfigurace byla na některých místech aktualizována, na jiných ne. A některé procesy naší aplikace, které běží na jednom počítači, byly restartovány s novou konfigurací a někde se starou. To může vést k tomu, že naše distribuovaná aplikace bude nekonzistentní z hlediska konfigurace. Tento problém je běžný. Pro dynamickou konfiguraci je to relevantnější, protože to znamená, že ji lze měnit za běhu.
Dalším problémem je členství ve skupině. Vždy máme nějakou skupinu pracovníků, vždy chceme vědět, kdo z nich je naživu, kdo z nich je mrtvý. Pokud existuje Master, pak musí rozumět tomu, které pracovníky lze přesměrovat na klienty, aby prováděli výpočty nebo pracovali s daty, a které nikoli. Problém, který se neustále objevuje, je, že potřebujeme vědět, kdo v našem klastru pracuje.
Dalším typickým problémem jsou volby lídrů, kdy chceme vědět, kdo je velí. Jedním příkladem je replikace, kdy máme nějaký proces, který přijímá operace zápisu a pak je replikuje mezi jiné procesy. Bude vůdcem, všichni ostatní ho budou poslouchat, budou ho následovat. Je potřeba zvolit postup tak, aby byl pro všechny jednoznačný, aby to nedopadlo tak, že jsou vybráni dva vedoucí.
Existuje také vzájemně se vylučující přístup. Zde je problém složitější. Existuje něco jako mutex, když píšete vícevláknové programy a chcete, aby byl přístup k nějakému zdroji, například paměťové buňce, omezen a prováděn pouze jedním vláknem. Zde může být zdrojem něco abstraktnějšího. A různé aplikace z různých uzlů naší sítě by měly dostávat pouze výhradní přístup k danému zdroji, a ne proto, aby ho každý mohl změnit nebo tam něco napsat. Jedná se o tzv. zámky.
ZooKeeper vám umožňuje vyřešit všechny tyto problémy do té či oné míry. A na příkladech ukážu, jak vám to umožňuje.
Neexistují žádná blokovací primitiva. Když něco začneme používat, toto primitivum nebude čekat, až dojde k nějaké události. S největší pravděpodobností bude tato věc fungovat asynchronně, což umožní procesům, aby se nezasekly, zatímco na něco čekají. To je velmi užitečná věc.
Všechny požadavky klientů jsou zpracovávány v pořadí obecné fronty.
A klienti mají možnost dostávat upozornění o změnách v nějakém stavu, o změnách údajů, než klient sám uvidí změněné údaje.
ZooKeeper může pracovat ve dvou režimech. První je samostatný, na jednom uzlu. To je vhodné pro testování. Může také pracovat v režimu clusteru na libovolném počtu serverů. Pokud máme cluster 100 strojů, tak není nutné, aby fungoval na 100 strojích. Stačí vybrat několik strojů, na kterých můžete ZooKeeper spustit. A vyznává princip vysoké dostupnosti. V každé spuštěné instanci ZooKeeper ukládá celou kopii dat. Později vám řeknu, jak to dělá. Nerozděluje data ani je nerozděluje. Na jednu stranu je mínus, že toho neumíme moc skladovat, na druhou stranu to není potřeba dělat. K tomu to není určeno, není to databáze.
Data lze ukládat do mezipaměti na straně klienta. Toto je standardní princip, abychom nepřerušovali službu a nezatěžovali ji stejnými požadavky. Chytrý klient o tom obvykle ví a uloží to do mezipaměti.
Tady se například něco změnilo. Existuje nějaký druh aplikace. Byl zvolen nový vedoucí, který je zodpovědný například za zpracování operací zápisu. A chceme data replikovat. Jedním z řešení je dát to do smyčky. A neustále zpochybňujeme naši službu - změnilo se něco? Druhá možnost je optimálnější. Jedná se o mechanismus sledování, který umožňuje upozornit klienty, že se něco změnilo. Jedná se o méně nákladnou metodu z hlediska zdrojů a pro klienty pohodlnější.
Klient je uživatel, který používá ZooKeeper.
Server je samotný proces ZooKeeper.
Znode je klíčová věc v ZooKeeper. Všechny uzly jsou uloženy v paměti ZooKeeperem a jsou organizovány ve formě hierarchického diagramu ve formě stromu.
Existují dva typy operací. První je update/write, kdy nějaká operace změní stav našeho stromu. Strom je obyčejný.
A je možné, že klient nedokončí jeden požadavek a je odpojen, ale může vytvořit relaci, prostřednictvím které komunikuje se ZooKeeperem.
Datový model ZooKeeper připomíná systém souborů. Je tam standardní root a pak jsme jakoby procházeli adresáře, které jdou z rootu. A pak katalog první úrovně, druhé úrovně. To jsou všechny znody.
Každý znode může uložit nějaká data, obvykle ne příliš velká, například 10 kilobajtů. A každý znode může mít určitý počet dětí.
Znody přicházejí v několika typech. Mohou být vytvořeny. A při vytváření znode určíme typ, ke kterému má patřit.
Existují dva typy. První je efemérní vlajka. Znode žije v rámci relace. Klient například vytvořil relaci. A dokud bude tato relace živá, bude existovat. To je nutné, aby nevzniklo něco zbytečného. To se hodí i pro chvíle, kdy je pro nás důležité ukládat datová primitiva v rámci relace.
Druhým typem je sekvenční příznak. Zvyšuje počítadlo na cestě do znodu. Měli jsme například adresář s aplikací 1_5. A když jsme vytvořili první uzel, obdržel p_1, druhý - p_2. A když tuto metodu voláme pokaždé, projdeme celou cestu, označující pouze část cesty, a toto číslo se automaticky zvýší, protože označujeme typ uzlu – sekvenční.
Normální znode. Vždy bude žít a mít jméno, které jí řekneme.
Další užitečnou věcí je vlajka hodinek. Pokud to nainstalujeme, tak se klient může přihlásit k odběru některých událostí pro konkrétní uzel. Později vám ukážu na příkladu, jak se to dělá. ZooKeeper sám oznámí klientovi, že se data na uzlu změnila. Upozornění však nezaručují, že nějaká nová data dorazila. Jednoduše říkají, že se něco změnilo, takže stále musíte porovnávat data později pomocí samostatných hovorů.
A jak jsem již řekl, pořadí dat je určeno po kilobajtech. Není zde potřeba ukládat velká textová data, protože to není databáze, je to server pro koordinaci akcí.
Řeknu vám něco málo o sezeních. Pokud máme více serverů, můžeme se transparentně přesouvat ze serveru na server pomocí identifikátoru relace. Je to docela pohodlné.
Každá relace má nějaký časový limit. Relace je definována tím, zda klient během této relace něco posílá na server. Pokud během timeoutu nic neodesílal, relace odpadá, případně si ji klient může sám ukončit.
Nemá tolik funkcí, ale s tímto API můžete dělat různé věci. Toto volání, které jsme viděli vytvořit, vytvoří znode a vezme tři parametry. Toto je cesta k uzlu a musí být zadána celá od kořene. A také to jsou některá data, která tam chceme přenést. A typ vlajky. A po vytvoření vrací cestu do znodu.
Za druhé, můžete jej smazat. Trik je v tom, že druhý parametr, kromě cesty k uzlu, může specifikovat verzi. V souladu s tím bude tento uzel odstraněn, pokud jeho verze, kterou jsme přenesli, je ekvivalentní té, která skutečně existuje.
Pokud nechceme tuto verzi kontrolovat, pak jednoduše předáme argument "-1".
Za třetí, kontroluje existenci znodu. Vrací hodnotu true, pokud uzel existuje, v opačném případě vrací hodnotu false.
A pak se objeví flag watch, což vám umožní sledovat tento uzel.
Tento příznak můžete nastavit i na neexistujícím uzlu a obdržet upozornění, když se objeví. To může být také užitečné.
Ještě pár výzev getData. Je jasné, že data můžeme přijímat přes znode. Můžete také použít flag watch. V tomto případě se nenainstaluje, pokud neexistuje žádný uzel. Proto musíte pochopit, že existuje, a poté přijímat data.
Existuje také SetData. Zde předáváme verzi. A pokud to předáme dál, aktualizují se údaje o uzlu určité verze.
Můžete také zadat "-1" pro vyloučení této kontroly.
Další užitečnou metodou je getChildren. Můžeme také získat seznam všech znodů, které k němu patří. Můžeme to sledovat nastavením sledování vlajky.
A metoda synchronizovat umožňuje odeslat všechny změny najednou, čímž zajistí, že budou uloženy a všechna data byla kompletně změněna.
Pokud nakreslíme analogie s konvenčním programováním, pak když použijete metody jako zápis, které něco zapíší na disk, a poté, co vám vrátí odpověď, není zaručeno, že jste data zapsali na disk. A i když je operační systém přesvědčen, že vše bylo zapsáno, na samotném disku existují mechanismy, kdy proces prochází vrstvami vyrovnávacích pamětí a teprve poté jsou data umístěna na disk.
Většinou se používají asynchronní hovory. To umožňuje klientovi pracovat paralelně s různými požadavky. Můžete použít synchronní přístup, ale je méně produktivní.
Dvě operace, o kterých jsme mluvili, jsou aktualizace/zápis, které mění data. Jsou to create, setData, sync, delete. A read is existuje, getData, getChildren.
Nyní několik příkladů, jak můžete vytvořit primitiva pro práci v distribuovaném systému. Například související s konfigurací něčeho. Objevil se nový pracovník. Přidali jsme stroj a zahájili proces. A jsou zde následující tři otázky. Jak se dotazuje ZooKeeper na konfiguraci? A pokud chceme změnit konfiguraci, jak ji změníme? A poté, co jsme to změnili, jak to dostanou ti pracovníci, které jsme měli?
ZooKeeper to poměrně usnadňuje. Například existuje náš strom znode. Zde je uzel pro naši aplikaci, v něm vytvoříme doplňkový uzel, který obsahuje data z konfigurace. Tyto mohou, ale nemusí být samostatné parametry. Protože je velikost malá, velikost konfigurace je obvykle také malá, takže je docela možné ji zde uložit.
Používáte metodu getData získat konfiguraci pro pracovníka z uzlu. Nastavte na true. Pokud z nějakého důvodu tento uzel neexistuje, budeme o tom informováni, když se objeví, nebo když se změní. Pokud chceme vědět, že se něco změnilo, nastavíme to na true. A pokud se data v tomto uzlu změní, budeme o tom vědět.
SetData. Nastavíme data, nastavíme „-1“, čili nekontrolujeme verzi, předpokládáme, že máme vždy jednu konfiguraci, nepotřebujeme ukládat mnoho konfigurací. Pokud potřebujete uložit hodně, budete muset přidat další úroveň. Zde se domníváme, že existuje pouze jedna, takže aktualizujeme pouze tu nejnovější, takže verzi nekontrolujeme. V tuto chvíli dostávají všichni klienti, kteří se dříve přihlásili k odběru, upozornění, že se v tomto uzlu něco změnilo. A poté, co je obdrží, musí také o data znovu požádat. Upozornění spočívá v tom, že nedostávají samotná data, ale pouze upozornění na změny. Poté musí požádat o nová data.
Druhá možnost použití primitiva je skupinové členství. Máme distribuovanou aplikaci, je tu spousta pracovníků a chceme pochopit, že jsou všichni na svém místě. Proto se musí sami zaregistrovat, že pracují v naší aplikaci. A také se chceme dozvědět, ať už z Master procesu, nebo někde jinde, o všech aktivních pracovnících, které aktuálně máme.
Jak to uděláme? Pro aplikaci vytvoříme pracovní uzel a přidáme tam podúroveň pomocí metody create. Mám chybu na snímku. Tady potřebujete sekvenční specifikovat, pak budou všichni pracovníci vytvořeni jeden po druhém. A aplikace, která požaduje všechna data o potomcích tohoto uzlu, přijme všechny aktivní pracovníky, kteří existují.
To je tak hrozná implementace toho, jak to lze udělat v kódu Java. Začněme od konce, hlavní metodou. Toto je naše třída, pojďme vytvořit její metodu. Jako první argument použijeme host, kde se připojujeme, tj. nastavíme jej jako argument. A druhým argumentem je název skupiny.
Jak ke spojení dojde? Toto je jednoduchý příklad použitého rozhraní API. Vše je zde poměrně jednoduché. Existuje standardní třída ZooKeeper. Předáváme mu hostitele. A nastavte timeout např. na 5 sekund. A máme člena s názvem connectedSignal. V podstatě vytváříme skupinu podél přenášené cesty. Nepíšeme tam data, i když něco zapsáno být mohlo. A uzel zde je trvalého typu. V podstatě se jedná o obyčejný pravidelný uzel, který bude existovat neustále. Zde je vytvořena relace. Jedná se o samotnou implementaci klienta. Náš klient bude posílat periodické zprávy, že relace je aktivní. A když relaci ukončíme, zavoláme blízko a je to, relace odpadne. To pro případ, že by nám něco spadlo, aby se o tom ZooKeeper dozvěděl a přerušil relaci.
Jak uzamknout zdroj? Zde je vše trochu složitější. Máme soubor pracovníků, existuje nějaký zdroj, který chceme uzamknout. Za tímto účelem vytvoříme samostatný uzel, například nazvaný zámek1. Kdybychom to dokázali vytvořit, tak tady máme zámek. A pokud se nám ho nepodařilo vytvořit, tak se worker snaží odtud získat getData, a protože uzel již byl vytvořen, tak sem dáme watcher a v momentě, kdy se stav tohoto uzlu změní, budeme o tom vědět. A můžeme se pokusit mít čas to znovu vytvořit. Pokud jsme vzali tento uzel, vzali tento zámek, pak poté, co již zámek nepotřebujeme, jej opustíme, protože uzel existuje pouze v rámci relace. V souladu s tím zmizí. A další klient si v rámci další relace bude moci vzít zámek na tento uzel, respektive dostane upozornění, že se něco změnilo a může se o to včas pokusit.
Další příklad toho, jak si můžete vybrat hlavního vůdce. To je trochu složitější, ale také relativně jednoduché. Co se tam děje? Existuje hlavní uzel, který agreguje všechny pracovníky. Snažíme se získat data o vůdci. Pokud se to stalo úspěšně, tj. obdrželi jsme nějaká data, náš pracovník začne sledovat tohoto vůdce. Věří, že vůdce již existuje.
Pokud vůdce z nějakého důvodu zemřel, například odpadl, pokusíme se vytvořit nového vůdce. A pokud uspějeme, pak se náš pracovník stane vůdcem. A pokud se někomu v tuto chvíli podařilo vytvořit nového vůdce, pak se snažíme pochopit, kdo to je, a pak ho následovat.
Zde vzniká tzv. stádní efekt, tedy stádový efekt, protože když zemře vůdce, stane se vůdcem ten, kdo je v čase první.
Při zachycování zdroje můžete zkusit použít trochu jiný přístup, který je následující. Například chceme získat zámek, ale bez hert efektu. Bude spočívat v tom, že naše aplikace požaduje seznamy všech ID uzlů pro již existující uzel se zámkem. A pokud předtím uzel, pro který jsme vytvořili zámek, je nejmenší ze sady, kterou jsme obdrželi, znamená to, že jsme zámek zachytili. Zkontrolujeme, zda jsme obdrželi zámek. Jako kontrola bude podmínka, že id, které jsme obdrželi při vytváření nového zámku, je minimální. A pokud jsme to dostali, pracujeme dále.
Pokud existuje určité id, které je menší než náš zámek, pak na tuto událost nasadíme hlídače a čekáme na upozornění, dokud se něco nezmění. To znamená, že jsme dostali tento zámek. A dokud nespadne, nestaneme se minimálním id a neobdržíme minimální zámek a tím pádem se budeme moci přihlásit. A pokud tato podmínka není splněna, pak okamžitě jdeme sem a pokusíme se získat tento zámek znovu, protože se během této doby mohlo něco změnit.
Z čeho se ZooKeeper skládá? Existují 4 hlavní věci. Jedná se o procesy zpracování - Žádost. A také ZooKeeper Atomic Broadcast. Existuje Commit Log, kde jsou zaznamenány všechny operace. A samotnou In-memory Replicated DB, tedy samotnou databázi, kde je celý tento strom uložen.
Stojí za zmínku, že všechny operace zápisu procházejí přes Request Processor. A operace čtení jdou přímo do databáze In-memory.
Samotná databáze je plně replikována. Všechny instance ZooKeeper ukládají úplnou kopii dat.
Pro obnovení databáze po havárii existuje protokol Commit. Standardní praxí je, že než se data dostanou do paměti, zapíší se tam, aby v případě havárie bylo možné tento protokol přehrát a obnovit stav systému. Používají se také pravidelné snímky databáze.
ZooKeeper Atomic Broadcast je věc, která se používá k údržbě replikovaných dat.
ZAB interně vybere odkaz z pohledu uzlu ZooKeeper. Ostatní uzly se stanou jejími následovníky a očekávají od ní nějaké akce. Pokud obdrží příspěvky, předají je všechny vedoucímu. Nejprve provede operaci zápisu a poté pošle zprávu o tom, co se změnilo, svým následovníkům. To ve skutečnosti musí být provedeno atomicky, to znamená, že záznam a vysílání celé věci musí být provedeno atomicky, čímž je zaručena konzistence dat.
Zpracovává pouze požadavky na zápis. Jeho hlavním úkolem je transformovat operaci do transakční aktualizace. Toto je speciálně vygenerovaný požadavek.
A zde stojí za zmínku, že idempotence aktualizací pro stejnou operaci je zaručena. co to je? Tato věc, pokud je provedena dvakrát, bude mít stejný stav, tj. samotný požadavek se nezmění. A to je třeba udělat, abyste v případě havárie mohli restartovat operaci, a tím vrátit zpět změny, které v tuto chvíli odpadly. V tomto případě se stav systému stane stejný, tj. nemělo by se stát, že série stejných, například aktualizačních procesů, vedla k různým konečným stavům systému.
Zdroj: www.habr.com