Predlagam, da preberete zapis predavanja "Hadoop. ZooKeeper" iz serije "Metode za porazdeljeno obdelavo velikih količin podatkov v Hadoopu"
Kaj je ZooKeeper, njegovo mesto v ekosistemu Hadoop. Neresnice o porazdeljenem računalništvu. Diagram standardnega porazdeljenega sistema. Težave pri usklajevanju porazdeljenih sistemov. Tipične težave s koordinacijo. Načela zasnove ZooKeeperja. Podatkovni model ZooKeeper. zastave znode. Seje. API odjemalca. Primitivni (konfiguracija, članstvo v skupini, enostavna zaklepanja, izvolitev vodje, zaklepanje brez učinka črede). Arhitektura ZooKeeper. ZooKeeper DB. ZAB. Obravnavalec zahtev.
Danes bomo govorili o ZooKeeperju. Ta stvar je zelo uporabna. Tako kot vsak izdelek Apache Hadoop ima logotip. Upodablja moškega.
Pred tem smo se pogovarjali predvsem o tem, kako se lahko tam obdelujejo podatki, kako jih hraniti, torej kako jih nekako uporabljati in nekako delati z njimi. In danes bi rad nekaj govoril o gradnji porazdeljenih aplikacij. In ZooKeeper je ena tistih stvari, ki vam omogoča, da to zadevo poenostavite. To je neke vrste storitev, ki je namenjena nekakšni koordinaciji interakcije procesov v porazdeljenih sistemih, v porazdeljenih aplikacijah.
Potreba po takšnih aplikacijah je vsak dan večja, temu je namenjen naš tečaj. Po eni strani vam MapReduce in to že pripravljeno ogrodje omogočata, da izravnate to zapletenost in osvobodite programerja pisanja primitivov, kot sta interakcija in koordinacija procesov. Toda po drugi strani nihče ne jamči, da tega vseeno ne bo treba storiti. MapReduce ali druga že pripravljena ogrodja ne nadomestijo vedno v celoti nekaterih primerov, ki jih s tem ni mogoče implementirati. Vključno s samim MapReduce in kopico drugih projektov Apache; so pravzaprav tudi distribuirane aplikacije. In za lažje pisanje so napisali ZooKeeper.
Kot vse aplikacije, povezane s Hadoopom, ga je razvil Yahoo! Zdaj je tudi uradna aplikacija Apache. Ni tako aktivno razvit kot HBase. Če greš na JIRA HBase, potem je vsak dan kup poročil o napakah, kup predlogov za optimizacijo nečesa, torej življenje v projektu nenehno teče. In ZooKeeper je po eni strani razmeroma enostaven izdelek, po drugi strani pa to zagotavlja njegovo zanesljivost. In je precej enostaven za uporabo, zato je postal standard v aplikacijah znotraj ekosistema Hadoop. Zato sem mislil, da bi ga bilo koristno pregledati, da bi razumeli, kako deluje in kako ga uporabljati.
To je slika z nekega predavanja, ki smo ga imeli. Lahko rečemo, da je pravokoten na vse, kar smo do sedaj obravnavali. In vse, kar je tukaj navedeno, v eni ali drugi meri deluje z ZooKeeperjem, to je storitev, ki uporablja vse te izdelke. Niti HDFS niti MapReduce ne pišeta lastnih podobnih storitev, ki bi posebej delovale zanju. V skladu s tem se uporablja ZooKeeper. In to poenostavi razvoj in nekatere stvari, povezane z napakami.
Od kod vse to? Zdi se, da smo vzporedno zagnali dve aplikaciji na različnih računalnikih, ju povezali z nizom ali mrežo in vse deluje. Toda težava je v tem, da je omrežje nezanesljivo in če ste povohali promet ali pogledali, kaj se tam dogaja na nizki ravni, kako odjemalci komunicirajo v omrežju, lahko pogosto vidite, da so nekateri paketi izgubljeni ali ponovno poslani. Ni zaman, da so bili izumljeni protokoli TCP, ki vam omogočajo, da vzpostavite določeno sejo in zagotovite dostavo sporočil. Toda v vsakem primeru vas tudi TCP ne more vedno rešiti. Vse ima časovno omejitev. Omrežje lahko za nekaj časa preprosto odpade. Lahko samo utripa. In vse to vodi v dejstvo, da se ne morete zanesti na zanesljivost omrežja. To je glavna razlika od pisanja vzporednih aplikacij, ki tečejo na enem računalniku ali na enem superračunalniku, kjer ni omrežja, kjer je bolj zanesljivo vodilo za izmenjavo podatkov v pomnilniku. In to je temeljna razlika.
Med drugim je pri uporabi omrežja vedno določena zakasnitev. Tudi disk ga ima, ampak Network ga ima več. Zakasnitev je čas zakasnitve, ki je lahko majhen ali zelo velik.
Topologija omrežja se spreminja. Kaj je topologija - to je postavitev naše omrežne opreme. Obstajajo podatkovni centri, obstajajo stojala, ki tam stojijo, obstajajo sveče. Vse to je možno na novo povezovati, premikati itd. To vse je treba tudi upoštevati. Spremenijo se imena IP, spremeni se usmerjanje, po katerem potuje naš promet. Tudi to je treba upoštevati.
Omrežje se lahko spremeni tudi glede opreme. Iz prakse lahko rečem, da naši omrežni inženirji res radi občasno posodabljajo nekaj na svečah. Nenadoma je prišel ven nov firmware in jih neki Hadoop cluster ni posebej zanimal. Imajo svojo službo. Za njih je glavno, da omrežje deluje. V skladu s tem želijo nekaj znova naložiti tja, narediti utripanje na svoji strojni opremi, strojna oprema pa se tudi občasno spremeni. Vse to je treba nekako upoštevati. Vse to vpliva na našo porazdeljeno aplikacijo.
Običajno ljudje, ki iz nekega razloga začnejo delati z velikimi količinami podatkov, verjamejo, da je internet neomejen. Če je tam datoteka z več terabajti, jo lahko prenesete na svoj strežnik ali računalnik in jo odprete z uporabo mačka in pazi. Prihaja še ena napaka Vim poglej dnevnike. Nikoli ne počni tega, ker je slabo. Ker Vim poskuša vse medpomniti, vse naložiti v pomnilnik, še posebej, ko se začnemo premikati po tem dnevniku in nekaj iskati. To so stvari, ki so pozabljene, a vredne premisleka.
Lažje je napisati en program, ki deluje na enem računalniku z enim procesorjem.
Ko naš sistem raste, ga želimo vzporediti vsega, in to ne le na računalniku, ampak tudi na gruči. Postavlja se vprašanje: kako to zadevo uskladiti? Naše aplikacije morda sploh ne komunicirajo med seboj, vendar smo izvajali več procesov vzporedno na več strežnikih. In kako spremljati, da jim gre vse dobro? Na primer, nekaj pošljejo po internetu. Nekje morajo pisati o svojem stanju, na primer v nekakšni bazi podatkov ali dnevniku, nato pa ta dnevnik združiti in ga nato nekje analizirati. Poleg tega moramo upoštevati, da je proces deloval in deloval, nenadoma se je v njem pojavila kakšna napaka ali se je zrušil, kako hitro bomo potem izvedeli za to?
Jasno je, da je vse to mogoče hitro spremljati. Tudi to je dobro, vendar je spremljanje omejena stvar, ki omogoča spremljanje nekaterih stvari na najvišji ravni.
Ko želimo, da naši procesi začnejo sodelovati drug z drugim, na primer, da si pošiljajo neke podatke, potem se pojavi tudi vprašanje - kako se bo to zgodilo? Bo prišlo do kakšnega dirkalnega stanja, se bodo prepisali, bodo podatki prispeli pravilno, se bo kaj izgubilo na poti? Razviti moramo nekakšen protokol itd.
Usklajevanje vseh teh procesov ni nepomembna stvar. In to prisili razvijalca, da se spusti na še nižjo raven in napiše sisteme iz nič ali ne povsem iz nič, vendar to ni tako preprosto.
Če si izmislite kriptografski algoritem ali ga celo implementirate, ga takoj zavrzite, ker najverjetneje ne bo deloval za vas. Najverjetneje bo vseboval kup napak, ki ste jih pozabili navesti. Nikoli ga ne uporabljajte za kaj resnega, ker bo najverjetneje nestabilen. Ker so vsi algoritmi, ki obstajajo, že zelo dolgo preizkušeni s časom. Prisluškovala mu je skupnost. To je posebna tema. In tukaj je tako. Če je možno, da sami ne izvajate neke vrste sinhronizacije procesov, potem je bolje, da tega ne storite, ker je precej zapleteno in vas vodi na trhlih poteh nenehnega iskanja napak.
Danes govorimo o ZooKeeperju. Po eni strani je ogrodje, po drugi strani pa storitev, ki razvijalcu olajša življenje in čim bolj poenostavi implementacijo logike in koordinacijo naših procesov.
Spomnimo se, kako bi lahko izgledal standardni porazdeljeni sistem. O tem smo govorili - HDFS, HBase. Obstaja glavni proces, ki upravlja delavce in podrejene procese. Odgovoren je za koordinacijo in distribucijo nalog, ponovni zagon delavcev, zagon novih in porazdelitev bremena.
Naprednejša stvar je Coordination Service, se pravi, da samo koordinacijsko nalogo premakneš v ločen proces, poleg tega pa vzporedno zaženeš še kakšno backup ali standby Master, ker Master lahko odpove. In če Mojster pade, potem naš sistem ne bo deloval. Izvajamo varnostno kopijo. Nekateri navajajo, da je treba Master kopirati v varnostno kopijo. To lahko zaupa tudi Službi za koordinacijo. Toda v tem diagramu je Master sam odgovoren za koordinacijo delavcev; tukaj storitev usklajuje dejavnosti replikacije podatkov.
Naprednejša možnost je, da za celotno koordinacijo skrbi naš servis, kot je to običajno. Prevzame odgovornost za to, da vse deluje. In če nekaj ne deluje, to izvemo in poskušamo to situacijo obiti. V vsakem primeru nam ostane Gospodar, ki nekako komunicira s sužnji in lahko prek neke storitve pošilja podatke, informacije, sporočila itd.
Obstaja še bolj napredna shema, ko nimamo Masterja, so vsa vozlišča glavni sužnji, različni v svojem obnašanju. Vendar morajo še vedno sodelovati drug z drugim, tako da je še vedno nekaj storitev za usklajevanje teh dejanj. Verjetno Cassandra, ki deluje na tem principu, ustreza tej shemi.
Težko je reči, katera od teh shem deluje bolje. Vsak ima svoje prednosti in slabosti.
In pri Mojstru se nekaterih stvari ni treba bati, saj, kot kaže praksa, ni tako dovzeten za nenehno služenje. Glavna stvar pri tem je izbrati pravo rešitev za gostovanje te storitve na ločenem zmogljivem vozlišču, tako da ima dovolj virov, da uporabniki tam, če je mogoče, nimajo dostopa, da slučajno ne ubijejo tega procesa. Hkrati pa je v taki shemi veliko lažje upravljati delavce iz Master procesa, torej je ta shema preprostejša z vidika implementacije.
In ta shema (zgoraj) je verjetno bolj zapletena, vendar bolj zanesljiva.
Glavni problem so delne okvare. Na primer, ko pošljemo sporočilo po omrežju, pride do neke vrste nesreče in tisti, ki je poslal sporočilo, ne bo vedel, ali je bilo njegovo sporočilo prejeto in kaj se je zgodilo na strani prejemnika, ne bo vedel, ali je bilo sporočilo pravilno obdelano , torej ne bo prejel nobene potrditve.
V skladu s tem moramo to situacijo obravnavati. Najpreprostejša stvar je, da ponovno pošljemo to sporočilo in počakamo, da prejmemo odgovor. V tem primeru se ne upošteva, ali se je stanje sprejemnika spremenilo. Lahko pošljemo sporočilo in dvakrat dodamo iste podatke.
ZooKeeper ponuja načine za reševanje takšnih zavrnitev, kar nam olajša življenje.
Kot smo malo prej omenili, je to podobno pisanju večnitnih programov, vendar je glavna razlika v tem, da je v porazdeljenih aplikacijah, ki jih gradimo na različnih strojih, edini način za komunikacijo omrežje. V bistvu je to arhitektura brez skupne rabe. Vsak proces ali storitev, ki teče na enem stroju, ima svoj pomnilnik, svoj disk, svoj procesor, ki si ga ne deli z nikomer.
Če pišemo večnitni program na enem računalniku, potem lahko za izmenjavo podatkov uporabimo skupni pomnilnik. Tam imamo preklop konteksta, procesi se lahko preklopijo. To vpliva na zmogljivost. Po eni strani tega v programu na gruči ni, vendar so težave z omrežjem.
Skladno s tem so glavne težave, ki nastanejo pri pisanju porazdeljenih sistemov, konfiguracija. Pišemo nekakšno vlogo. Če je preprosto, potem v kodo trdo kodiramo vse vrste številk, vendar je to neprijetno, ker če se odločimo, da namesto pol sekunde želimo časovno omejitev ene sekunde, potem moramo znova prevesti aplikacijo in vse znova razvaljajte. Ena stvar je, ko je na enem stroju, ko ga lahko samo znova zaženeš, ko pa imamo veliko strojev, moramo nenehno vse kopirati. Poskusiti moramo narediti aplikacijo nastavljivo.
Tukaj govorimo o statični konfiguraciji sistemskih procesov. To ni povsem, morda z vidika operacijskega sistema, morda je statična konfiguracija za naše procese, to je konfiguracija, ki je ni mogoče preprosto vzeti in posodobiti.
Obstaja tudi dinamična konfiguracija. To so parametri, ki jih želimo sproti spreminjati, da se tam poberejo.
Kaj je tukaj problem? Posodobili smo konfiguracijo, jo uvedli, in kaj? Težava je morda v tem, da smo po eni strani konfiguracijo razgrnili, a pozabili na novo stvar, konfiguracija je ostala tam. Drugič, med uvajanjem je bila konfiguracija na nekaterih mestih posodobljena, na drugih pa ne. Nekateri procesi naše aplikacije, ki se izvajajo na enem računalniku, so bili znova zagnani z novo konfiguracijo, nekje pa s staro. To lahko povzroči, da je naša porazdeljena aplikacija nedosledna z vidika konfiguracije. Ta težava je pogosta. Za dinamično konfiguracijo je bolj relevantna, ker pomeni, da jo je mogoče spreminjati sproti.
Druga težava je članstvo v skupini. Vedno imamo nek nabor delavcev, vedno želimo vedeti, kateri od njih je živ, kdo mrtev. Če obstaja Master, potem mora razumeti, katere delavce je mogoče preusmeriti k strankam, da izvajajo izračune ali delajo s podatki, in katere ne. Težava, ki se nenehno pojavlja, je, da moramo vedeti, kdo dela v našem grozdu.
Druga značilna težava so volitve voditeljev, ko želimo vedeti, kdo je glavni. En primer je replikacija, ko imamo nek proces, ki prejme pisalne operacije in jih nato replicira med drugimi procesi. On bo vodja, vsi ostali ga bodo ubogali, mu sledili. Izbrati je treba proces, ki bo nedvoumen za vse, da se ne izkaže, da sta izbrana dva voditelja.
Obstaja tudi medsebojno izključujoč dostop. Problem je tu bolj kompleksen. Obstaja nekaj takega, kot je mutex, ko pišete večnitne programe in želite, da je dostop do nekega vira, na primer pomnilniške celice, omejen in ga izvaja samo ena nit. Tukaj bi lahko bil vir nekaj bolj abstraktnega. In različne aplikacije iz različnih vozlišč našega omrežja bi morale prejeti samo ekskluzivni dostop do danega vira in ne tako, da ga lahko vsak spremeni ali tam nekaj napiše. To so tako imenovane ključavnice.
ZooKeeper vam omogoča, da v eni ali drugi meri rešite vse te težave. In s primeri bom pokazal, kako vam to omogoča.
Ni blokirnih primitivov. Ko začnemo nekaj uporabljati, ta primitiv ne bo čakal, da se zgodi kakršen koli dogodek. Najverjetneje bo ta stvar delovala asinhrono in s tem omogočila, da procesi ne bodo obviseli, medtem ko bodo na nekaj čakali. To je zelo uporabna stvar.
Vse zahteve strank se obdelajo po vrstnem redu splošne čakalne vrste.
In odjemalci imajo možnost prejemati obvestilo o spremembah nekega stanja, o spremembah podatkov, preden odjemalec sam vidi spremenjene podatke.
ZooKeeper lahko deluje v dveh načinih. Prvi je samostojen, na enem vozlišču. To je priročno za testiranje. Prav tako lahko deluje v načinu gruče na poljubnem številu strežnikov. Če imamo gručo 100 strojev, potem ni nujno, da deluje na 100 napravah. Dovolj je, da izberete več strojev, na katerih lahko poganjate ZooKeeper. In izpoveduje načelo visoke razpoložljivosti. ZooKeeper na vsakem delujočem primerku shrani celotno kopijo podatkov. Kasneje vam bom povedal, kako mu to uspe. Podatkov ne razdeli ali particionira. Po eni strani je minus, da ne moremo veliko shraniti, po drugi strani pa tega ni treba početi. Ni zasnovano za to, ni zbirka podatkov.
Podatke je mogoče predpomniti na strani odjemalca. To je standardno načelo, da ne prekinemo storitve in je ne naložimo z istimi zahtevami. Pameten odjemalec običajno ve za to in shrani v predpomnilnik.
Tukaj se je na primer nekaj spremenilo. Obstaja nekakšna aplikacija. Izvoljen je bil nov vodja, ki je odgovoren na primer za obdelavo zapisovalnih operacij. In podatke želimo ponoviti. Ena od rešitev je, da ga postavite v zanko. In nenehno se sprašujemo o naših storitvah - ali se je kaj spremenilo? Druga možnost je bolj optimalna. To je mehanizem za opazovanje, ki vam omogoča, da stranke obvestite, da se je nekaj spremenilo. To je cenejša metoda v smislu sredstev in bolj priročna za stranke.
Naročnik je uporabnik, ki uporablja ZooKeeper.
Strežnik je sam proces ZooKeeper.
Znode je ključna stvar v ZooKeeperju. ZooKeeper shrani vse znode v pomnilnik in jih organizira v obliki hierarhičnega diagrama v obliki drevesa.
Obstajata dve vrsti operacij. Prvi je posodobitev/pisanje, ko neka operacija spremeni stanje našega drevesa. Drevo je običajno.
In možno je, da stranka ne izpolni ene zahteve in je prekinjena, lahko pa vzpostavi sejo, prek katere komunicira z ZooKeeperjem.
Podatkovni model ZooKeeperja je podoben datotečnemu sistemu. Obstaja standardni koren in potem smo šli kot skozi imenike, ki gredo iz korena. In potem katalog prve stopnje, druge stopnje. To so vse znode.
Vsaka znoda lahko shrani nekaj podatkov, običajno ne zelo velikih, na primer 10 kilobajtov. In vsak znode ima lahko določeno število otrok.
Znodes je na voljo v več vrstah. Lahko se ustvarijo. In ko ustvarjamo znode, določimo tip, ki naj mu pripada.
Obstajata dve vrsti. Prva je efemerna zastava. Znode živi znotraj seje. Na primer, stranka je vzpostavila sejo. In dokler bo ta seja živa, bo obstajala. To je potrebno, da ne proizvedemo nepotrebnega. To je primerno tudi za trenutke, ko je pomembno, da hranimo podatkovne primitive znotraj seje.
Druga vrsta je zaporedna zastavica. Poveča števec na poti do znode. Na primer, imeli smo imenik z aplikacijo 1_5. In ko smo ustvarili prvo vozlišče, je prejelo p_1, drugo - p_2. In ko vsakič pokličemo to metodo, posredujemo celotno pot, ki označuje le del poti, in ta številka se samodejno poveča, ker označujemo vrsto vozlišča - zaporedno.
Redni znode. Vedno bo živela in imela bo ime, ki ji ga povemo.
Druga uporabna stvar je zastavica za uro. Če ga namestimo, potem se odjemalec lahko naroči na nekatere dogodke za določeno vozlišče. Kasneje vam bom na primeru pokazal, kako se to naredi. ZooKeeper sam obvesti stranko, da so se podatki na vozlišču spremenili. Vendar obvestila ne zagotavljajo, da so prispeli novi podatki. Preprosto pravijo, da se je nekaj spremenilo, zato je treba podatke kasneje še primerjati z ločenimi klici.
In kot sem že rekel, je vrstni red podatkov določen s kilobajti. Tam ni treba shranjevati velikih besedilnih podatkov, ker to ni zbirka podatkov, je strežnik za usklajevanje dejanj.
Povedal vam bom nekaj o sejah. Če imamo več strežnikov, se lahko pregledno premikamo od strežnika do strežnika z uporabo identifikatorja seje. To je zelo priročno.
Vsaka seja ima neke vrste časovno omejitev. Seja je definirana s tem, ali odjemalec med to sejo pošlje kaj strežniku. Če med časovno omejitvijo ni oddal ničesar, seja odpade, ali pa jo klient sam zapre.
Nima toliko funkcij, vendar lahko s tem API-jem počnete različne stvari. Ta klic, ki smo ga videli ustvariti, ustvari znode in sprejme tri parametre. To je pot do znode in mora biti podana v celoti od korena. In tudi to je nekaj podatkov, ki jih želimo prenesti tja. In vrsto zastave. In po ustvarjanju vrne pot do znode.
Drugič, lahko ga izbrišete. Trik je v tem, da lahko drugi parameter poleg poti do znode poda različico. V skladu s tem bo ta znode izbrisan, če je njegova različica, ki smo jo prenesli, enakovredna tisti, ki dejansko obstaja.
Če te različice ne želimo preveriti, preprosto posredujemo argument »-1«.
Tretjič, preveri obstoj znode. Vrne true, če vozlišče obstaja, drugače pa false.
In nato se prikaže zastavica, ki vam omogoča spremljanje tega vozlišča.
To zastavico lahko nastavite tudi na neobstoječe vozlišče in prejmete obvestilo, ko se pojavi. To je lahko tudi koristno.
Še nekaj izzivov je getData. Jasno je, da lahko podatke prejemamo prek znode. Uporabite lahko tudi uro z zastavo. V tem primeru se ne bo namestil, če ni vozlišča. Zato morate razumeti, da obstaja, in nato prejeti podatke.
Je tudi SetData. Tukaj podajamo različico. In če to posredujemo naprej, se bodo podatki o znode določene različice posodobili.
Določite lahko tudi "-1", da izključite to preverjanje.
Druga uporabna metoda je getChildren. Dobimo lahko tudi seznam vseh znodov, ki mu pripadajo. To lahko spremljamo z nastavitvijo nadzora zastavic.
In metoda sinhronizacijo omogoča, da se vse spremembe pošljejo hkrati, s čimer se zagotovi, da so shranjene in da so vsi podatki popolnoma spremenjeni.
Če potegnemo analogijo z običajnim programiranjem, potem ko uporabljate metode, kot je pisanje, ki nekaj zapišejo na disk in potem, ko vam vrnejo odgovor, ni nobenega zagotovila, da ste podatke zapisali na disk. In tudi ko je operacijski sistem prepričan, da je vse zapisano, obstajajo mehanizmi v samem disku, kjer gre proces skozi plasti vmesnih pomnilnikov in šele nato se podatki namestijo na disk.
Večinoma se uporabljajo asinhroni klici. To stranki omogoča vzporedno delo z različnimi zahtevami. Lahko uporabite sinhroni pristop, vendar je manj produktiven.
Dve operaciji, o katerih smo govorili, sta posodobitev/pisanje, ki spreminjata podatke. To so create, setData, sync, delete. In branje obstaja, getData, getChildren.
Zdaj pa nekaj primerov, kako lahko naredite primitive za delo v porazdeljenem sistemu. Na primer v zvezi s konfiguracijo nečesa. Pojavil se je nov delavec. Dodali smo stroj in začeli postopek. In tu so naslednja tri vprašanja. Kako ZooKeeper poizveduje za konfiguracijo? In če želimo spremeniti konfiguracijo, kako jo spremenimo? In potem, ko smo ga spremenili, kako ga dobijo tisti delavci, ki smo jih imeli?
ZooKeeper to razmeroma enostavno naredi. Na primer, tu je naše drevo znode. Tu je vozlišče za našo aplikacijo, v njem ustvarimo dodatno vozlišče, ki vsebuje podatke iz konfiguracije. To so lahko ali pa tudi ne ločeni parametri. Ker je velikost majhna, je običajno majhna tudi velikost konfiguracije, zato jo je povsem mogoče shraniti tukaj.
Uporabljate metodo getData da dobite konfiguracijo za delavca iz vozlišča. Nastavite na true. Če iz nekega razloga to vozlišče ne obstaja, bomo o tem obveščeni, ko se pojavi ali ko se spremeni. Če želimo vedeti, da se je nekaj spremenilo, potem to nastavimo na true. In če se podatki v tem vozlišču spremenijo, bomo za to vedeli.
SetData. Nastavimo podatke, nastavimo “-1”, torej ne preverjamo različice, predvidevamo, da imamo vedno eno konfiguracijo, ni nam treba shranjevati veliko konfiguracij. Če morate veliko shraniti, boste morali dodati še eno raven. Tu verjamemo, da je samo ena, zato posodabljamo samo najnovejšo, tako da ne preverjamo različice. V tem trenutku vsi naročniki, ki so bili predhodno naročeni, prejmejo obvestilo, da se je v tem vozlišču nekaj spremenilo. In potem, ko jih prejmejo, morajo podatke tudi znova zahtevati. Obvestilo je, da ne prejmejo samih podatkov, ampak samo obvestilo o spremembah. Po tem morajo zahtevati nove podatke.
Druga možnost za uporabo primitive je članstvo v skupini. Imamo distribuirano aplikacijo, obstaja kup delavcev in želimo razumeti, da so vsi na svojem mestu. Zato se morajo sami registrirati, da delajo v naši aplikaciji. Prav tako želimo izvedeti, bodisi iz Master procesa ali kje drugje, o vseh aktivnih delavcih, ki jih trenutno imamo.
Kako naj to naredimo? Za aplikacijo ustvarimo delovno vozlišče in vanj dodamo podnivo z uporabo metode create. Imam napako na prosojnici. Tukaj potrebujete zaporedno določite, potem bodo vsi delavci ustvarjeni enega za drugim. In aplikacija, ki zahteva vse podatke o otrocih tega vozlišča, prejme vse aktivne delavce, ki obstajajo.
To je tako grozna izvedba tega, kako je to mogoče storiti v kodi Java. Začnimo od konca, z glavno metodo. To je naš razred, ustvarimo njegovo metodo. Kot prvi argument uporabimo host, kjer se povezujemo, torej ga nastavimo kot argument. In drugi argument je ime skupine.
Kako pride do povezave? To je preprost primer API-ja, ki se uporablja. Tukaj je vse razmeroma preprosto. Obstaja standardni razred ZooKeeper. Prenesemo mu gostitelje. In nastavite časovno omejitev, na primer, na 5 sekund. In imamo člana z imenomconnectedSignal. V bistvu ustvarimo skupino vzdolž prenesene poti. Podatkov tam ne pišemo, čeprav bi lahko kaj zapisali. In vozlišče tukaj je trajnega tipa. V bistvu je to običajno običajno vozlišče, ki bo obstajalo ves čas. Tukaj se ustvari seja. To je implementacija same stranke. Naša stranka bo pošiljala občasna sporočila, da je seja živa. In ko zaključimo sejo, pokličemo close in to je to, seja odpade. To je v primeru, da nam kaj odpade, da ZooKeeper to izve in prekine sejo.
Kako zakleniti vir? Tukaj je vse malo bolj zapleteno. Imamo nabor delavcev, obstaja nekaj virov, ki jih želimo zakleniti. Da bi to naredili, ustvarimo ločeno vozlišče, na primer imenovano lock1. Če smo ga lahko ustvarili, potem imamo tu ključavnico. In če nam ga ni uspelo ustvariti, potem delavec poskuša pridobiti getData od tukaj, in ker je vozlišče že ustvarjeno, potem tukaj postavimo opazovalca in v trenutku, ko se stanje tega vozlišča spremeni, bomo vedeli za to. In lahko poskusimo imeti čas, da ga ponovno ustvarimo. Če smo vzeli to vozlišče, vzeli to ključavnico, potem ko ključavnice ne bomo več potrebovali, jo bomo opustili, saj vozlišče obstaja samo znotraj seje. V skladu s tem bo izginilo. In drug odjemalec bo v okviru druge seje lahko zaklenil to vozlišče, oziroma bo prejel obvestilo, da se je nekaj spremenilo in lahko poskusi to storiti pravočasno.
Še en primer, kako lahko izberete glavnega voditelja. To je nekoliko bolj zapleteno, a tudi relativno preprosto. Kaj se tukaj dogaja? Obstaja glavno vozlišče, ki združuje vse delavce. Poskušamo pridobiti podatke o vodji. Če se je to zgodilo uspešno, tj. prejeli smo nekaj podatkov, potem naš delavec začne slediti temu vodji. Verjame, da vodja že obstaja.
Če je vodja iz nekega razloga umrl, na primer odpadel, potem poskušamo ustvariti novega vodjo. In če nam uspe, potem naš delavec postane vodja. In če je nekomu v tem trenutku uspelo ustvariti novega vodjo, potem poskušamo razumeti, kdo je to in mu slediti.
Tu nastane tako imenovani učinek črede, torej učinek črede, saj ko vodja umre, postane vodja tisti, ki je prvi po času.
Pri zajemanju vira lahko poskusite uporabiti nekoliko drugačen pristop, ki je naslednji. Na primer, želimo dobiti ključavnico, vendar brez njenega učinka. Sestavljen bo iz dejstva, da naša aplikacija zahteva sezname vseh id-jev vozlišč za že obstoječe vozlišče z zaklepanjem. In če je pred tem vozlišče, za katerega smo ustvarili ključavnico, najmanjše v nizu, ki smo ga prejeli, potem to pomeni, da smo ključavnico zajeli. Preverimo, ali smo prejeli ključavnico. Kot preverjanje bo pogoj, da je ID, ki smo ga prejeli pri ustvarjanju nove ključavnice, minimalen. In če smo ga prejeli, potem delamo naprej.
Če obstaja določen ID, ki je manjši od naše ključavnice, potem na ta dogodek postavimo opazovalca in počakamo na obvestilo, dokler se kaj ne spremeni. To pomeni, da smo prejeli to ključavnico. In dokler ne odpade, ne bomo postali minimalni id in ne bomo prejeli minimalne ključavnice in se bomo tako lahko prijavili. In če ta pogoj ni izpolnjen, gremo takoj sem in poskusimo ponovno dobiti to ključavnico, ker se je v tem času morda kaj spremenilo.
Kaj vsebuje ZooKeeper? Obstajajo 4 glavne stvari. To so procesi obdelave - Zahteva. In tudi ZooKeeper Atomic Broadcast. Obstaja Commit Log, kjer so zabeležene vse operacije. In sama podvojena baza podatkov v pomnilniku, tj. sama baza podatkov, kjer je shranjeno to celotno drevo.
Omeniti velja, da gredo vse operacije pisanja skozi procesor zahtev. Operacije branja gredo neposredno v bazo podatkov v pomnilniku.
Sama baza podatkov je v celoti podvojena. Vsi primerki ZooKeeperja shranijo popolno kopijo podatkov.
Če želite obnoviti bazo podatkov po zrušitvi, obstaja dnevnik potrditve. Standardna praksa je, da se podatki, preden pridejo v pomnilnik, zapišejo tja, tako da se lahko v primeru zrušitve ta dnevnik predvaja in obnovi stanje sistema. Uporabljajo se tudi periodični posnetki baze podatkov.
ZooKeeper Atomic Broadcast je stvar, ki se uporablja za vzdrževanje podvojenih podatkov.
ZAB interno izbere vodjo z vidika vozlišča ZooKeeper. Druga vozlišča postanejo njeni sledilci in od nje pričakujejo nekaj dejanj. Če prejmejo prijave, jih vse posredujejo vodji. Najprej izvede operacijo pisanja in nato svojim sledilcem pošlje sporočilo o tem, kaj se je spremenilo. To mora biti dejansko izvedeno atomarno, tj. operacija snemanja in oddajanja celotne stvari mora biti izvedena atomarno, s čimer je zagotovljena konsistentnost podatkov.
Obdeluje le zahteve za pisanje. Njegova glavna naloga je, da operacijo spremeni v transakcijsko posodobitev. To je posebej ustvarjena zahteva.
In tukaj je treba omeniti, da je idempotenca posodobitev za isto operacijo zagotovljena. Kaj je to? Ta stvar, če jo izvedete dvakrat, bo imela isto stanje, to pomeni, da se sama zahteva ne bo spremenila. In to je treba storiti tako, da lahko v primeru zrušitve znova zaženete operacijo in s tem vrnete spremembe, ki so trenutno odpadle. V tem primeru bo stanje sistema postalo enako, to pomeni, da se ne bi smelo zgoditi, da bi niz enakih, na primer procesov posodobitev, privedel do različnih končnih stanj sistema.
Vir: www.habr.com