Navrhujem, aby ste si prečítali prepis prednášky "Hadoop. ZooKeeper" zo série "Metódy pre distribuované spracovanie veľkých objemov údajov v Hadoop"
Čo je ZooKeeper, jeho miesto v ekosystéme Hadoop. Nepravdy o distribuovaných výpočtoch. Schéma štandardného distribuovaného systému. Ťažkosti s koordináciou distribuovaných systémov. Typické problémy s koordináciou. Princípy za dizajnom ZooKeeper. Dátový model ZooKeeper. znode vlajky. Relácie. Klientské rozhranie API. Primitívy (konfigurácia, členstvo v skupine, jednoduché zámky, voľba vodcu, zamykanie bez stádového efektu). Architektúra ZooKeeper. ZooKeeper DB. ZAB. Spracovateľ žiadosti.
Dnes budeme hovoriť o ZooKeeper. Táto vec je veľmi užitočná. Rovnako ako každý produkt Apache Hadoop má logo. Zobrazuje muža.
Predtým sme hovorili hlavne o tom, ako sa tam dajú dáta spracovať, ako ich uložiť, teda ako ich nejako využiť a nejako s nimi pracovať. A dnes by som rád povedal niečo o vytváraní distribuovaných aplikácií. A ZooKeeper je jednou z vecí, ktoré vám umožňujú zjednodušiť túto záležitosť. Ide o druh služby, ktorá je určená na určitý druh koordinácie interakcie procesov v distribuovaných systémoch, v distribuovaných aplikáciách.
Potreba takýchto aplikácií je každým dňom viac a viac, o tom je náš kurz. Na jednej strane vám MapReduce a tento hotový rámec umožňuje vyrovnať túto zložitosť a oslobodiť programátora od písacích primitív, ako je interakcia a koordinácia procesov. Ale na druhej strane nikto nezaručí, že to aj tak nebude treba urobiť. MapReduce alebo iné hotové rámce nie vždy úplne nahradia niektoré prípady, ktoré nie je možné implementovať pomocou tohto. Vrátane samotného MapReduce a mnohých ďalších projektov Apache; v skutočnosti sú to tiež distribuované aplikácie. A aby bolo písanie jednoduchšie, napísali ZooKeeper.
Rovnako ako všetky aplikácie súvisiace s Hadoop, bola vyvinutá spoločnosťou Yahoo! Teraz je to tiež oficiálna aplikácia Apache. Nie je tak aktívne vyvinutý ako HBase. Ak idete na JIRA HBase, tak každý deň prichádza kopa hlásení o chybách, kopa návrhov na optimalizáciu niečoho, t.j. život v projekte neustále beží. A ZooKeeper je na jednej strane relatívne jednoduchým produktom a na druhej strane to zabezpečuje jeho spoľahlivosť. A je celkom jednoduchý na používanie, a preto sa stal štandardom v aplikáciách v rámci ekosystému Hadoop. Preto som si myslel, že by bolo užitočné si ho preštudovať, aby som pochopil, ako funguje a ako ho používať.
Toto je obrázok z nejakej prednášky, ktorú sme mali. Dá sa povedať, že je ortogonálny ku všetkému, čo sme doteraz uvažovali. A všetko, čo je tu uvedené, v tej či onej miere funguje so ZooKeeperom, t.j. je to služba, ktorá využíva všetky tieto produkty. Ani HDFS, ani MapReduce nepíšu svoje vlastné podobné služby, ktoré by pre nich konkrétne fungovali. V súlade s tým sa používa ZooKeeper. A to zjednodušuje vývoj a niektoré veci súvisiace s chybami.
Odkiaľ toto všetko pochádza? Zdalo by sa, že sme paralelne spustili dve aplikácie na rôznych počítačoch, prepojili ich reťazcom alebo do siete a všetko funguje. Problém je však v tom, že sieť je nespoľahlivá a ak ste načuchali prevádzku alebo ste sa pozreli na to, čo sa tam deje na nízkej úrovni, ako klienti komunikujú v sieti, často môžete vidieť, že niektoré pakety sa stratia alebo znova odoslajú. Nie nadarmo boli vynájdené protokoly TCP, ktoré vám umožňujú vytvoriť určitú reláciu a zaručiť doručovanie správ. V každom prípade vás však ani TCP nemôže vždy zachrániť. Všetko má časový limit. Sieť môže jednoducho na chvíľu spadnúť. Môže to len blikať. A to všetko vedie k tomu, že sa nemôžete spoľahnúť na spoľahlivosť siete. Toto je hlavný rozdiel od písania paralelných aplikácií, ktoré bežia na jednom počítači alebo na jednom superpočítači, kde nie je sieť, kde je spoľahlivejšia zbernica na výmenu dát v pamäti. A to je zásadný rozdiel.
Okrem iného pri používaní Siete vždy existuje určitá latencia. Disk to má tiež, ale Sieť má toho viac. Latencia je určitý čas oneskorenia, ktorý môže byť malý alebo dosť významný.
Topológia siete sa mení. Čo je topológia - to je umiestnenie našich sieťových zariadení. Sú tam dátové centrá, sú tam stojany, ktoré tam stoja, sú tam sviečky. Toto všetko je možné znovu pripojiť, presunúť atď. Toto všetko je tiež potrebné vziať do úvahy. Menia sa IP mená, mení sa smerovanie, ktorým prechádza naša prevádzka. Toto je tiež potrebné vziať do úvahy.
Sieť sa môže zmeniť aj z hľadiska vybavenia. Z praxe môžem povedať, že naši sieťoví inžinieri naozaj radi pravidelne niečo aktualizujú na sviečkach. Zrazu vyšiel nový firmvér a nejaký klaster Hadoop ich zvlášť nezaujímal. Majú svoju prácu. Pre nich je hlavné, že Sieť funguje. Preto tam chcú niečo znova nahrať, urobiť flashovanie na svojom hardvéri a hardvér sa tiež pravidelne mení. S tým všetkým treba nejako počítať. To všetko ovplyvňuje našu distribuovanú aplikáciu.
Ľudia, ktorí z nejakého dôvodu začnú pracovať s veľkým množstvom údajov, sa zvyčajne domnievajú, že internet je neobmedzený. Ak je tam súbor s niekoľkými terabajtmi, môžete si ho vziať na server alebo počítač a otvoriť ho pomocou ako a sledujte. Je tu ďalšia chyba elán pozri si protokoly. Nikdy to nerobte, pretože je to zlé. Pretože Vim sa snaží všetko ukladať do vyrovnávacej pamäte, načítať všetko do pamäte, najmä keď začneme prechádzať týmto protokolom a niečo hľadať. To sú veci, na ktoré sa zabúda, no stoja za zváženie.
Jednoduchšie je napísať jeden program, ktorý beží na jednom počítači s jedným procesorom.
Keď sa náš systém rozrastie, chceme to všetko paralelizovať a paralelizovať nielen na počítači, ale aj na klastri. Vynára sa otázka: ako túto záležitosť koordinovať? Naše aplikácie možno ani navzájom neinteragujú, ale paralelne sme spustili niekoľko procesov na niekoľkých serveroch. A ako sledovať, či im všetko ide? Napríklad niečo posielajú cez internet. Musia niekde písať o svojom stave, napríklad v nejakej databáze alebo protokole, potom tento protokol agregovať a potom ho niekde analyzovať. Navyše musíme vziať do úvahy, že proces fungoval a fungoval, zrazu sa v ňom objavila nejaká chyba alebo sa zrútil, ako rýchlo sa to potom dozvieme?
Je jasné, že toto všetko sa dá rýchlo sledovať. To je tiež dobré, ale monitorovanie je obmedzená vec, ktorá vám umožňuje sledovať niektoré veci na najvyššej úrovni.
Keď chceme, aby sa naše procesy začali navzájom ovplyvňovať, napríklad aby sme si posielali nejaké dáta, potom vyvstáva aj otázka – ako sa to stane? Nastane nejaký race condition, prepíšu sa navzájom, dorazia dáta správne, stratí sa niečo po ceste? Potrebujeme vyvinúť nejaký protokol atď.
Koordinácia všetkých týchto procesov nie je triviálna vec. A núti vývojára ísť na ešte nižšiu úroveň a písať systémy buď od nuly, alebo nie úplne od nuly, ale to nie je také jednoduché.
Ak prídete s kryptografickým algoritmom alebo ho dokonca implementujete, okamžite ho zahoďte, pretože s najväčšou pravdepodobnosťou to pre vás nebude fungovať. S najväčšou pravdepodobnosťou bude obsahovať veľa chýb, ktoré ste zabudli poskytnúť. Nikdy ho nepoužívajte na nič vážne, pretože bude s najväčšou pravdepodobnosťou nestabilný. Pretože všetky existujúce algoritmy boli testované časom veľmi dlho. Je to odpočúvané komunitou. Toto je samostatná téma. A tu je to rovnako. Ak je možné neimplementovať nejaký druh synchronizácie procesov sami, potom je lepšie to nerobiť, pretože je to dosť komplikované a vedie vás to vratkou cestou neustáleho hľadania chýb.
Dnes hovoríme o ZooKeeper. Na jednej strane je to framework, na druhej strane je to služba, ktorá vývojárovi uľahčuje život a čo najviac zjednodušuje implementáciu logiky a koordinácie našich procesov.
Pripomeňme si, ako môže vyzerať štandardný distribuovaný systém. To je to, o čom sme hovorili - HDFS, HBase. Existuje hlavný proces, ktorý riadi pracovníkov a podriadené procesy. Je zodpovedný za koordináciu a rozdeľovanie úloh, reštartovanie pracovníkov, spúšťanie nových a rozloženie záťaže.
Pokročilejšou vecou je koordinačná služba, teda presunúť samotnú koordinačnú úlohu do samostatného procesu, plus paralelne spustiť nejaký druh zálohy alebo pohotovostného Master, pretože Master môže zlyhať. A ak Majster padne, potom náš systém nebude fungovať. Spúšťame zálohovanie. Niektoré uvádzajú, že Master musí byť replikovaný do zálohy. Toto môže byť zverené aj koordinačnej službe. Ale v tomto diagrame je za koordináciu pracovníkov zodpovedný samotný Majster; tu služba koordinuje aktivity replikácie údajov.
Pokročilejšou možnosťou je, keď všetku koordináciu zabezpečuje naša služba, ako sa to zvyčajne robí. Preberá zodpovednosť za to, že všetko funguje. A ak niečo nefunguje, zistíme to a pokúsime sa túto situáciu obísť. V každom prípade nám zostáva Majster, ktorý nejakým spôsobom interaguje s otrokmi a môže cez nejakú službu posielať dáta, informácie, správy atď.
Existuje ešte pokročilejšia schéma, keď nemáme Majstra, všetky uzly sú master slave, odlišné svojim správaním. Stále však musia navzájom spolupracovať, takže stále existuje nejaká služba na koordináciu týchto akcií. Pravdepodobne Cassandra, ktorá funguje na tomto princípe, vyhovuje tejto schéme.
Je ťažké povedať, ktorá z týchto schém funguje lepšie. Každý má svoje pre a proti.
A nie je potrebné sa niektorých vecí s Majstrom báť, pretože, ako ukazuje prax, nie je taký náchylný neustále slúžiť. Tu ide hlavne o výber správneho riešenia pre hosťovanie tejto služby na samostatnom výkonnom uzle, aby mala dostatok zdrojov, aby tam, ak je to možné, používatelia nemali prístup, aby tento proces náhodou nezabili. Zároveň je však v takejto schéme oveľa jednoduchšie riadiť pracovníkov z Master procesu, t.j. táto schéma je z hľadiska implementácie jednoduchšia.
A táto schéma (vyššie) je pravdepodobne zložitejšia, ale spoľahlivejšia.
Hlavným problémom sú čiastkové poruchy. Napríklad, keď pošleme správu cez sieť, stane sa nejaká nehoda a ten, kto správu odoslal, nebude vedieť, či bola jeho správa prijatá a čo sa stalo na strane príjemcu, nebude vedieť, či bola správa spracovaná správne. , teda nedostane žiadne potvrdenie.
Podľa toho musíme túto situáciu spracovať. A najjednoduchšie je poslať túto správu znova a počkať, kým nedostaneme odpoveď. V tomto prípade sa neberie do úvahy, či sa zmenil stav prijímača. Môžeme poslať správu a pridať rovnaké údaje dvakrát.
ZooKeeper ponúka spôsoby, ako sa vysporiadať s takýmito odmietnutiami, čo nám tiež uľahčuje život.
Ako už bolo spomenuté trochu skôr, je to podobné ako pri písaní viacvláknových programov, ale hlavný rozdiel je v tom, že v distribuovaných aplikáciách, ktoré staviame na rôznych strojoch, je jediným spôsobom komunikácie sieť. V podstate ide o architektúru zdieľanej bez ničoho. Každý proces alebo služba, ktorá beží na jednom stroji, má svoju pamäť, vlastný disk, vlastný procesor, ktorý s nikým nezdieľa.
Ak na jednom počítači napíšeme viacvláknový program, potom môžeme využívať zdieľanú pamäť na výmenu dát. Máme tam prepínač kontextu, procesy sa môžu prepínať. To ovplyvňuje výkon. Na jednej strane v programe na klastri nič také nie je, no sú tu problémy so sieťou.
Preto sú hlavné problémy, ktoré vznikajú pri písaní distribuovaných systémov, konfigurácia. Píšeme nejakú prihlášku. Ak je to jednoduché, potom v kóde natvrdo zakódujeme všetky možné čísla, ale je to nepohodlné, pretože ak sa rozhodneme, že namiesto polsekundového časového limitu chceme časový limit jednej sekundy, potom musíme aplikáciu prekompilovať a všetko znova rozvinúť. Jedna vec je, keď je to na jednom počítači, keď ho môžete reštartovať, ale keď máme veľa počítačov, musíme neustále kopírovať všetko. Musíme sa pokúsiť, aby bola aplikácia konfigurovateľná.
Tu hovoríme o statickej konfigurácii pre systémové procesy. Toto nie je úplne, možno z pohľadu operačného systému môže ísť o statickú konfiguráciu pre naše procesy, teda o konfiguráciu, ktorú nemožno jednoducho prevziať a aktualizovať.
K dispozícii je tiež dynamická konfigurácia. To sú parametre, ktoré chceme za chodu meniť, aby sa tam vychytali.
Aký je tu problém? Aktualizovali sme konfiguráciu, spustili ju, tak čo? Problém môže byť v tom, že na jednej strane sme rozbalili konfiguráciu, ale zabudli sme na novú vec, konfigurácia tam zostala. Po druhé, počas zavádzania sa konfigurácia na niektorých miestach aktualizovala, na iných nie. A niektoré procesy našej aplikácie, ktoré bežia na jednom počítači, boli reštartované s novou konfiguráciou a niekde so starou. To môže viesť k tomu, že naša distribuovaná aplikácia bude nekonzistentná z hľadiska konfigurácie. Tento problém je bežný. Pre dynamickú konfiguráciu je to relevantnejšie, pretože to znamená, že sa dá meniť za chodu.
Ďalším problémom je členstvo v skupine. Vždy máme nejaký súbor robotníkov, vždy chceme vedieť, ktorý z nich je nažive, ktorý z nich je mŕtvy. Ak existuje Majster, potom musí pochopiť, ktorí pracovníci môžu byť presmerovaní na klientov, aby vykonávali výpočty alebo pracovali s údajmi, a ktorí nie. Problém, ktorý neustále vzniká, je, že musíme vedieť, kto v našom klastri pracuje.
Ďalším typickým problémom sú voľby lídrov, keď chceme vedieť, kto má na starosti. Jedným príkladom je replikácia, keď máme nejaký proces, ktorý prijíma operácie zápisu a potom ich replikuje medzi iné procesy. On bude vodca, všetci ostatní ho budú poslúchať, budú ho nasledovať. Je potrebné zvoliť postup tak, aby bol pre všetkých jednoznačný, aby to nedopadlo tak, že sa vyberú dvaja lídri.
Existuje aj vzájomne sa vylučujúci prístup. Problém je tu zložitejší. Existuje niečo ako mutex, keď píšete viacvláknové programy a chcete, aby bol prístup k nejakému zdroju, napríklad pamäťovej bunke, obmedzený a vykonávaný iba jedným vláknom. Tu môže byť zdrojom niečo abstraktnejšie. A rôzne aplikácie z rôznych uzlov našej Siete by mali dostať iba exkluzívny prístup k danému zdroju a nie preto, aby ho každý mohol zmeniť alebo tam niečo napísať. Ide o takzvané zámky.
ZooKeeper vám umožňuje vyriešiť všetky tieto problémy do tej či onej miery. A na príkladoch ukážem, ako vám to umožňuje.
Neexistujú žiadne blokovacie primitívy. Keď niečo začneme používať, toto primitívum nebude čakať, kým nastane nejaká udalosť. S najväčšou pravdepodobnosťou bude táto vec fungovať asynchrónne, čo umožní procesom nezamrznúť, kým na niečo čakajú. Toto je veľmi užitočná vec.
Všetky požiadavky klientov sa spracúvajú v poradí podľa všeobecného poradia.
A klienti majú možnosť dostať notifikáciu o zmenách v niektorom stave, o zmenách v údajoch, skôr ako klient sám uvidí zmenené údaje.
ZooKeeper môže pracovať v dvoch režimoch. Prvý je samostatný, na jednom uzle. To je vhodné na testovanie. Môže tiež pracovať v klastrovom režime na ľubovoľnom počte serverov. Ak máme klaster 100 strojov, potom nie je potrebné, aby fungoval na 100 strojoch. Stačí vybrať niekoľko strojov, na ktorých môžete spustiť ZooKeeper. A vyznáva princíp vysokej dostupnosti. V každej spustenej inštancii ZooKeeper ukladá celú kópiu údajov. Neskôr vám poviem, ako to robí. Nerozdeľuje údaje ani ich nerozdeľuje. Na jednej strane je mínus, že nevieme veľa skladovať, na druhej strane to netreba robiť. Na to nie je určený, nie je to databáza.
Dáta je možné ukladať do vyrovnávacej pamäte na strane klienta. Ide o štandardný princíp, aby sme neprerušili službu a nezaťažovali ju rovnakými požiadavkami. Inteligentný klient o tom zvyčajne vie a uloží to do vyrovnávacej pamäte.
Napríklad tu sa niečo zmenilo. Existuje nejaký druh aplikácie. Bol zvolený nový vedúci, ktorý je zodpovedný napríklad za spracovanie operácií zápisu. A chceme replikovať dáta. Jedným z riešení je dať to do slučky. A neustále spochybňujeme našu službu - zmenilo sa niečo? Druhá možnosť je optimálnejšia. Ide o mechanizmus hodiniek, ktorý vám umožňuje upozorniť klientov, že sa niečo zmenilo. Ide o menej nákladnú metódu z hľadiska zdrojov a pre klientov pohodlnejšia.
Klient je používateľ, ktorý používa ZooKeeper.
Server je samotný proces ZooKeeper.
Znode je kľúčová vec v ZooKeeper. Všetky uzly sú uložené v pamäti ZooKeeperom a sú usporiadané vo forme hierarchického diagramu vo forme stromu.
Existujú dva typy operácií. Prvým je update/write, kedy nejaká operácia zmení stav nášho stromu. Strom je obyčajný.
A je možné, že klient nedokončí jednu požiadavku a je odpojený, ale môže vytvoriť reláciu, prostredníctvom ktorej komunikuje so ZooKeeperom.
Dátový model ZooKeeper sa podobá súborovému systému. Je tam štandardný root a potom sme prechádzali akoby cez adresáre, ktoré idú z rootu. A potom katalóg prvej úrovne, druhej úrovne. Toto sú všetky znody.
Každý uzol môže uložiť nejaké dáta, zvyčajne nie príliš veľké, napríklad 10 kilobajtov. A každý uzol môže mať určitý počet detí.
Znody prichádzajú v niekoľkých typoch. Môžu byť vytvorené. A pri vytváraní uzla určíme typ, ku ktorému má patriť.
Sú dva typy. Prvou je efemérna vlajka. Znode žije v rámci relácie. Klient napríklad vytvoril reláciu. A kým bude táto relácia živá, bude existovať. Je to potrebné, aby sa nevyrábalo niečo zbytočné. To sa hodí aj v momentoch, keď je pre nás dôležité ukladať dátové primitívy v rámci relácie.
Druhým typom je sekvenčný príznak. Zvyšuje počítadlo na ceste do znodu. Napríklad sme mali adresár s aplikáciou 1_5. A keď sme vytvorili prvý uzol, dostal p_1, druhý - p_2. A keď túto metódu zavoláme zakaždým, prejdeme celú cestu, pričom uvedieme len časť cesty a toto číslo sa automaticky zvýši, pretože označujeme typ uzla – sekvenčný.
Pravidelný uzol. Vždy bude žiť a mať meno, ktoré jej povieme.
Ďalšou užitočnou vecou je vlajka hodiniek. Ak ho nainštalujeme, tak si klient môže odoberať nejaké udalosti pre konkrétny uzol. Neskôr vám ukážem na príklade, ako sa to robí. ZooKeeper sám upozorní klienta, že údaje na uzle sa zmenili. Upozornenia však nezaručujú, že prišli nejaké nové údaje. Jednoducho povedia, že sa niečo zmenilo, takže aj tak musíte údaje neskôr porovnávať samostatnými hovormi.
A ako som už povedal, poradie údajov je určené po kilobajtoch. Nie je potrebné ukladať veľké textové dáta, pretože nejde o databázu, ale o akčný koordinačný server.
Poviem vám niečo o reláciách. Ak máme viacero serverov, môžeme sa transparentne presúvať zo servera na server pomocou identifikátora relácie. Je to celkom pohodlné.
Každá relácia má určitý časový limit. Relácia je definovaná tým, či klient počas tejto relácie niečo odošle na server. Ak počas timeoutu nič neodoslal, relácia padá, prípadne si ju môže klient sám uzavrieť.
Nemá toľko funkcií, ale s týmto API môžete robiť rôzne veci. Toto volanie, ktoré sme videli vytvoriť, vytvára znode a má tri parametre. Toto je cesta k uzlu a musí byť špecifikovaná úplne od koreňa. A aj toto sú niektoré údaje, ktoré tam chceme preniesť. A typ vlajky. A po vytvorení vráti cestu do uzla.
Po druhé, môžete ho odstrániť. Trik je v tom, že druhý parameter, okrem cesty k uzlu, môže špecifikovať verziu. V súlade s tým bude tento uzol odstránený, ak jeho verzia, ktorú sme preniesli, je ekvivalentná verzii, ktorá skutočne existuje.
Ak túto verziu nechceme kontrolovať, potom jednoducho prejdeme argumentom "-1".
Po tretie, kontroluje existenciu uzla. Ak uzol existuje, vráti hodnotu true, v opačnom prípade vráti hodnotu false.
A potom sa objaví flag watch, ktorý vám umožní sledovať tento uzol.
Tento príznak môžete nastaviť aj na neexistujúcom uzle a dostať upozornenie, keď sa objaví. To môže byť tiež užitočné.
Existuje niekoľko ďalších výziev getData. Je jasné, že dáta môžeme prijímať cez znode. Môžete tiež použiť vlajkové hodinky. V tomto prípade sa nenainštaluje, ak neexistuje žiadny uzol. Preto musíte pochopiť, že existuje, a potom prijímať údaje.
Je tu tiež SetData. Tu uvádzame verziu. A ak to postúpime ďalej, aktualizujú sa údaje o uzle určitej verzie.
Môžete tiež zadať "-1" na vylúčenie tejto kontroly.
Ďalšou užitočnou metódou je getChildren. Môžeme tiež získať zoznam všetkých uzlov, ktoré k nemu patria. Môžeme to sledovať nastavením sledovania vlajky.
A metóda synchronizovať umožňuje odoslať všetky zmeny naraz, čím sa zabezpečí ich uloženie a úplná zmena všetkých údajov.
Ak nakreslíme analógie s bežným programovaním, tak keď použijete metódy ako zápis, ktoré niečo zapíšu na disk a potom, čo vám vrátia odpoveď, nie je zaručené, že ste dáta zapísali na disk. A aj keď je operačný systém presvedčený, že všetko bolo napísané, na samotnom disku existujú mechanizmy, v ktorých proces prechádza vrstvami vyrovnávacích pamätí a až potom sú údaje umiestnené na disk.
Väčšinou sa používajú asynchrónne hovory. To umožňuje klientovi pracovať paralelne s rôznymi požiadavkami. Môžete použiť synchrónny prístup, ale je menej produktívny.
Dve operácie, o ktorých sme hovorili, sú aktualizácia/zápis, ktoré menia dáta. Sú to create, setData, sync, delete. A read is existuje, getData, getChildren.
Teraz niekoľko príkladov, ako môžete vytvoriť primitíva pre prácu v distribuovanom systéme. Napríklad súvisiaci s konfiguráciou niečoho. Objavil sa nový pracovník. Pridali sme stroj a začali proces. A tu sú nasledujúce tri otázky. Ako sa pýta ZooKeeper na konfiguráciu? A ak chceme zmeniť konfiguráciu, ako ju zmeníme? A keď sme to zmenili, ako to získajú tí pracovníci, ktorých sme mali?
ZooKeeper to robí relatívne jednoduchým. Napríklad je tu náš strom znode. Nachádza sa tu uzol pre našu aplikáciu, v ňom vytvoríme doplnkový uzol, ktorý obsahuje údaje z konfigurácie. Môžu, ale nemusia to byť samostatné parametre. Keďže veľkosť je malá, veľkosť konfigurácie je zvyčajne tiež malá, takže je celkom možné ju tu uložiť.
Používate metódu getData na získanie konfigurácie pre pracovníka z uzla. Nastavte na true. Ak z nejakého dôvodu tento uzol neexistuje, budeme o tom informovaní, keď sa objaví, alebo keď sa zmení. Ak chceme vedieť, že sa niečo zmenilo, tak to nastavíme na true. A ak sa údaje v tomto uzle zmenia, budeme o tom vedieť.
SetData. Nastavíme údaje, nastavíme „-1“, t.j. nekontrolujeme verziu, predpokladáme, že máme vždy jednu konfiguráciu, nepotrebujeme ukladať veľa konfigurácií. Ak potrebujete uložiť veľa, budete musieť pridať ďalšiu úroveň. Tu sa domnievame, že existuje len jedna, takže aktualizujeme iba najnovšiu verziu, takže verziu nekontrolujeme. V tejto chvíli všetci klienti, ktorí sa predtým prihlásili na odber, dostávajú upozornenie, že sa v tomto uzle niečo zmenilo. A potom, čo ich dostanú, musia si o údaje znova vyžiadať. Upozornenie spočíva v tom, že nedostávajú samotné údaje, ale iba upozornenie na zmeny. Potom musia požiadať o nové údaje.
Druhá možnosť použitia primitíva je členstvo v skupine. Máme distribuovanú aplikáciu, je tu veľa pracovníkov a chceme pochopiť, že všetci sú na svojom mieste. Preto sa musia sami zaregistrovať, že pracujú v našej aplikácii. A tiež sa chceme dozvedieť, či už z Master procesu alebo niekde inde, o všetkých aktívnych pracovníkoch, ktorých momentálne máme.
Ako to urobíme? Pre aplikáciu vytvoríme pracovný uzol a pomocou metódy create tam pridáme podúroveň. Mám chybu na snímke. Tu potrebujete sekvenčné špecifikovať, potom sa postupne vytvoria všetci pracovníci. A aplikácia, ktorá požaduje všetky údaje o potomkoch tohto uzla, dostane všetkých aktívnych pracovníkov, ktorí existujú.
Toto je taká hrozná implementácia toho, ako sa to dá urobiť v kóde Java. Začnime od konca, s hlavnou metódou. Toto je naša trieda, vytvorme jej metódu. Ako prvý argument použijeme host, kde sa pripájame, t.j. nastavíme ho ako argument. A druhým argumentom je názov skupiny.
Ako dôjde k spojeniu? Toto je jednoduchý príklad použitého API. Všetko je tu pomerne jednoduché. Existuje štandardná trieda ZooKeeper. Odovzdávame mu hostiteľov. A nastavte časový limit napríklad na 5 sekúnd. A máme člena s názvom ConnectedSignal. V podstate vytvárame skupinu pozdĺž prenášanej cesty. Nepíšeme tam údaje, aj keď niečo mohlo byť napísané. A uzol tu je perzistentného typu. V podstate ide o obyčajný pravidelný uzol, ktorý bude existovať neustále. Tu je vytvorená relácia. Ide o realizáciu samotného klienta. Náš klient bude pravidelne posielať správy o tom, že relácia je aktívna. A keď ukončíme reláciu, zavoláme zavrieť a je to, relácia prepadne. To pre prípad, že by nám niečo spadlo, aby sa o tom dozvedel ZooKeeper a prerušil reláciu.
Ako uzamknúť zdroj? Tu je všetko trochu komplikovanejšie. Máme súbor pracovníkov, existuje nejaký zdroj, ktorý chceme uzamknúť. Aby sme to dosiahli, vytvoríme samostatný uzol, napríklad s názvom lock1. Ak by sme to dokázali vytvoriť, tak tu máme zámok. A ak sa nám ho nepodarilo vytvoriť, tak sa pracovník odtiaľto snaží získať getData a keďže uzol je už vytvorený, tak sem dáme watcher a v momente, keď sa zmení stav tohto uzla, budeme o tom vedieť. A môžeme sa pokúsiť mať čas na jeho opätovné vytvorenie. Ak sme vzali tento uzol, vzali tento zámok, potom keď už zámok nepotrebujeme, opustíme ho, pretože uzol existuje iba v rámci relácie. V súlade s tým zmizne. A ďalší klient v rámci ďalšej relácie bude môcť tento uzol uzamknúť, respektíve dostane upozornenie, že sa niečo zmenilo a môže sa o to pokúsiť včas.
Ďalší príklad, ako si môžete vybrať hlavného vodcu. Toto je trochu zložitejšie, ale tiež relatívne jednoduché. Čo sa tu deje? Existuje hlavný uzol, ktorý agreguje všetkých pracovníkov. Snažíme sa získať údaje o vodcovi. Ak sa to stalo úspešne, t. j. dostali sme nejaké údaje, náš pracovník začne nasledovať tohto vodcu. Verí, že vodca už existuje.
Ak vodca z nejakého dôvodu zomrel, napríklad spadol, pokúsime sa vytvoriť nového vodcu. A ak uspejeme, potom sa náš pracovník stane vodcom. A ak sa niekomu v tejto chvíli podarilo vytvoriť nového vodcu, potom sa snažíme pochopiť, kto to je, a potom ho nasledovať.
Tu vzniká takzvaný stádový efekt, teda stádový efekt, pretože keď vodca zomrie, vodcom sa stane ten, kto je v čase prvý.
Pri zachytávaní zdroja môžete skúsiť použiť trochu iný prístup, ktorý je nasledovný. Napríklad chceme získať zámok, ale bez hertového efektu. Bude spočívať v tom, že naša aplikácia si vyžiada zoznamy všetkých ID uzlov pre už existujúci uzol so zámkom. A ak je predtým uzol, pre ktorý sme vytvorili zámok, najmenší zo súboru, ktorý sme dostali, znamená to, že sme zámok zachytili. Skontrolujeme, či sme dostali zámok. Ako kontrola bude podmienka, že ID, ktoré sme dostali pri vytváraní nového zámku, je minimálne. A ak sme ho dostali, pracujeme ďalej.
Ak existuje určité ID, ktoré je menšie ako náš zámok, potom na túto udalosť nasadíme strážcu a čakáme na upozornenie, kým sa niečo nezmení. To znamená, že sme dostali tento zámok. A kým nespadne, nestaneme sa minimálnym id a nedostaneme minimálny zámok, a teda sa budeme môcť prihlásiť. A ak táto podmienka nie je splnená, okamžite ideme sem a pokúsime sa znova získať tento zámok, pretože sa počas tejto doby mohlo niečo zmeniť.
Z čoho ZooKeeper pozostáva? Sú 4 hlavné veci. Ide o procesy spracovania - Žiadosť. A tiež ZooKeeper Atomic Broadcast. Existuje Commit Log, kde sa zaznamenávajú všetky operácie. A samotná In-memory Replicated DB, teda samotná databáza, kde je uložený celý tento strom.
Stojí za zmienku, že všetky operácie zápisu prechádzajú cez Request Processor. A operácie čítania idú priamo do databázy In-memory.
Samotná databáza je plne replikovaná. Všetky inštancie ZooKeeper ukladajú úplnú kópiu údajov.
Na obnovenie databázy po havárii existuje denník Commit. Štandardnou praxou je, že predtým, ako sa dáta dostanú do pamäte, sú tam zapísané, aby v prípade zlyhania bolo možné tento protokol prehrať a obnoviť stav systému. Používajú sa aj pravidelné snímky databázy.
ZooKeeper Atomic Broadcast je vec, ktorá sa používa na udržiavanie replikovaných údajov.
ZAB interne vyberá vodcu z pohľadu uzla ZooKeeper. Ostatné uzly sa stávajú jej nasledovníkmi a očakávajú od nej nejaké akcie. Ak dostanú príspevky, pošlú ich všetky vedúcemu. Najprv vykoná operáciu zápisu a potom pošle správu o tom, čo sa zmenilo jeho nasledovníkom. Toto sa v skutočnosti musí vykonávať atomicky, t. j. nahrávacia a vysielacia operácia celej veci sa musí vykonávať atomicky, čím je zaručená konzistencia dát.
Spracováva iba požiadavky na zápis. Jeho hlavnou úlohou je transformovať operáciu na transakčnú aktualizáciu. Toto je špeciálne vygenerovaná požiadavka.
A tu stojí za zmienku, že idempotencia aktualizácií pre rovnakú operáciu je zaručená. Čo to je? Táto vec, ak sa vykoná dvakrát, bude mať rovnaký stav, t.j. samotná požiadavka sa nezmení. A to je potrebné urobiť, aby ste v prípade havárie mohli reštartovať operáciu, čím sa vrátia späť zmeny, ktoré momentálne vypadli. V tomto prípade sa stav systému zmení, t.j. nemalo by sa stať, že séria rovnakých, napríklad aktualizačných procesov, viedla k rôznym konečným stavom systému.
Zdroj: hab.com