Soovitan lugeda loengu "Hadoop. ZooKeeper" stenogrammi sarjast "Meetodid suurte andmemahtude hajutatud töötlemiseks Hadoopis"
Mis on ZooKeeper, selle koht Hadoopi ökosüsteemis. Vale hajutatud andmetöötluse kohta. Standardse hajutatud süsteemi skeem. Raskused hajutatud süsteemide koordineerimisel. Tüüpilised koordinatsiooniprobleemid. ZooKeeperi disaini põhimõtted. ZooKeeperi andmemudel. znode lipud. Seansid. Kliendi API. Primitiivid (konfiguratsioon, gruppi kuulumine, lihtsad lukud, juhi valimine, lukustamine ilma karjaefektita). ZooKeeperi arhitektuur. ZooKeeper DB. ZAB. Päringu menetleja.
Täna räägime ZooKeeperist. See asi on väga kasulik. Sellel, nagu igal Apache Hadoopi tootel, on logo. See kujutab meest.
Enne seda rääkisime peamiselt sellest, kuidas seal andmeid töödelda saab, kuidas neid salvestada ehk kuidas neid kuidagi kasutada ja nendega kuidagi tööd teha. Ja täna tahaksin veidi rääkida hajutatud rakenduste loomisest. Ja ZooKeeper on üks neist asjadest, mis võimaldab teil seda asja lihtsustada. See on omamoodi teenus, mis on mõeldud hajutatud süsteemides, hajutatud rakendustes olevate protsesside interaktsiooni mingil viisil koordineerimiseks.
Vajadus selliste rakenduste järele muutub iga päevaga aina suuremaks, sellest meie kursus seisnebki. Ühest küljest võimaldab MapReduce ja see valmis raamistik seda keerukust tasandada ja vabastada programmeerija primitiivide kirjutamisest, nagu interaktsioon ja protsesside koordineerimine. Kuid teisest küljest ei garanteeri keegi, et seda niikuinii tegema ei pea. MapReduce või muud valmis raamistikud ei asenda alati täielikult mõnda juhtumit, mida ei saa selle abil rakendada. Sealhulgas MapReduce ise ja hulk teisi Apache projekte; tegelikult on need ka hajutatud rakendused. Ja kirjutamise hõlbustamiseks kirjutasid nad ZooKeeperi.
Nagu kõik Hadoopiga seotud rakendused, töötas selle välja Yahoo! Nüüd on see ka ametlik Apache rakendus. Seda ei arendata nii aktiivselt kui HBase. Kui minna JIRA HBase’i, siis iga päev tuleb hunnik veateateid, hunnik ettepanekuid millegi optimeerimiseks, st elu projektis käib pidevalt. Ja ZooKeeper on ühest küljest suhteliselt lihtne toode ja teisest küljest tagab see selle töökindluse. Ja seda on üsna lihtne kasutada, mistõttu on sellest saanud Hadoopi ökosüsteemi rakenduste standard. Seega arvasin, et oleks kasulik see üle vaadata, et mõista, kuidas see toimib ja kuidas seda kasutada.
See on pilt mõnest loengust, mis meil oli. Võime öelda, et see on ortogonaalne kõigega, mida oleme seni käsitlenud. Ja kõik, mis siin on märgitud, töötab ühel või teisel määral koos ZooKeeperiga, st see on teenus, mis kasutab kõiki neid tooteid. Ei HDFS ega MapReduce ei kirjuta oma sarnaseid teenuseid, mis nende jaoks konkreetselt töötaksid. Sellest lähtuvalt kasutatakse ZooKeeperit. Ja see lihtsustab arendamist ja mõningaid vigadega seotud asju.
Kust see kõik tuleb? Näib, et käivitasime erinevates arvutites paralleelselt kaks rakendust, ühendasime need stringiga või võrku ja kõik töötab. Aga probleem on selles, et võrk on ebausaldusväärne ja kui sa nuusutad liiklust või vaatad madalal tasemel, mis seal toimub, kuidas kliendid võrgus suhtlevad, siis on sageli näha, et osa pakette läheb kaotsi või saadetakse uuesti. Pole asjata, et leiutati TCP-protokollid, mis võimaldavad teil luua kindla seansi ja tagada sõnumite kohaletoimetamise. Kuid igal juhul ei saa isegi TCP teid alati päästa. Igal asjal on aeg. Võrk võib mõneks ajaks lihtsalt ära kukkuda. See võib lihtsalt vilkuda. Ja see kõik viib selleni, et te ei saa loota, et võrk on usaldusväärne. See on peamine erinevus paralleelsete rakenduste kirjutamisest, mis töötavad ühes arvutis või ühes superarvutis, kus puudub Võrk, kus mälus on töökindlam andmevahetussiin. Ja see on põhimõtteline erinevus.
Muuhulgas on Võrgu kasutamisel alati teatav latentsusaeg. Ka kettal on see olemas, aga võrgus on seda rohkem. Latentsus on teatav viivitusaeg, mis võib olla kas väike või üsna märkimisväärne.
Võrgu topoloogia muutub. Mis on topoloogia - see on meie võrguseadmete paigutus. Seal on andmekeskused, seal on nagid, mis seisavad, on küünlad. Seda kõike saab uuesti ühendada, teisaldada jne. Seda kõike tuleb ka arvesse võtta. IP-nimed muutuvad, meie liikluse marsruutimine muutub. Seda tuleb ka arvesse võtta.
Võrk võib muutuda ka varustuse osas. Praktikast võin öelda, et meie võrguinseneridele meeldib väga aeg-ajalt midagi küünaldel värskendada. Järsku ilmus uus püsivara ja nad ei olnud eriti huvitatud mingist Hadoopi klastrist. Neil on oma töö. Nende jaoks on peamine, et Võrk toimiks. Vastavalt sellele tahavad nad sinna midagi uuesti üles laadida, oma riistvarale vilkuma teha ja ka riistvara muutub perioodiliselt. Seda kõike tuleb kuidagi arvestada. Kõik see mõjutab meie hajutatud rakendust.
Tavaliselt usuvad inimesed, kes mingil põhjusel hakkavad töötama suure andmemahuga, et Internet on piiritu. Kui seal on mitme terabaidine fail, siis saate selle oma serverisse või arvutisse viia ja selle abil avada kass ja vaata. Sees on veel üks viga tarm vaata palke. Ärge kunagi tehke seda, sest see on halb. Sest Vim üritab kõike puhverdada, mällu laadida, eriti kui hakkame seda logi läbi liikuma ja midagi otsima. Need on asjad, mis on unustatud, kuid tasub kaaluda.
Lihtsam on kirjutada üks programm, mis töötab ühes arvutis ühe protsessoriga.
Kui meie süsteem kasvab, tahame seda kõike paralleelida ja mitte ainult arvutis, vaid ka klastris. Tekib küsimus: kuidas seda asja koordineerida? Meie rakendused ei pruugi isegi omavahel suhelda, kuid käitasime mitut protsessi paralleelselt mitmes serveris. Ja kuidas jälgida, et neil kõik hästi läheks? Näiteks saadavad nad midagi Interneti kaudu. Nad peavad kirjutama oma olekust kuhugi, näiteks mingisse andmebaasi või logisse, seejärel selle logi kokku liitma ja siis kuskil analüüsima. Lisaks peame arvestama, et protsess töötas ja töötas, äkki tekkis selles mõni viga või jooksis kokku, siis kui kiiresti me sellest teada saame?
On selge, et seda kõike saab kiiresti jälgida. See on ka hea, kuid jälgimine on piiratud asi, mis võimaldab mõnda asja kõrgeimal tasemel jälgida.
Kui tahame, et meie protsessid hakkaksid omavahel suhtlema, näiteks saadaks üksteisele mingeid andmeid, siis tekib ka küsimus – kuidas see juhtub? Kas tuleb mingi võistlusseisund, kas nad kirjutavad üksteist üle, kas andmed saabuvad õigesti, kas midagi läheb teel kaotsi? Peame välja töötama mingi protokolli jne.
Kõigi nende protsesside koordineerimine ei ole tühine asi. Ja see sunnib arendajat laskuma veelgi madalamale tasemele ja kirjutama süsteeme kas nullist või mitte päris nullist, kuid see pole nii lihtne.
Kui mõtlete välja krüptoalgoritmi või isegi rakendate seda, siis visake see kohe minema, sest suure tõenäosusega see teie jaoks ei tööta. Tõenäoliselt sisaldab see hulga vigu, mille unustasite esitada. Ärge kunagi kasutage seda millegi tõsise jaoks, sest see on tõenäoliselt ebastabiilne. Sest kõik olemasolevad algoritmid on aja poolt väga pikka aega testitud. See on kogukonna poolt häiritud. See on eraldi teema. Ja see on sama siin. Kui on võimalik mingit protsesside sünkroonimist ise mitte rakendada, siis on parem seda mitte teha, sest see on üsna keeruline ja viib teid pidevalt vigade otsimise raputavale teele.
Täna räägime ZooKeeperist. Ühest küljest on see raamistik, teisalt teenus, mis teeb arendaja elu lihtsamaks ning lihtsustab nii palju kui võimalik loogika juurutamist ja meie protsesside koordineerimist.
Meenutagem, milline võiks välja näha standardne hajutatud süsteem. See on see, millest me rääkisime - HDFS, HBase. On olemas Master protsess, mis haldab töötajaid ja orjaprotsesse. Tema ülesandeks on ülesannete koordineerimine ja jaotamine, töötajate taaskäivitamine, uute käivitamine ja koormuse jaotamine.
Arenenum asi on Coordination Service ehk koordineerimisülesande enda eraldi protsessi viimine pluss paralleelselt mingi backup või stanby Master jooksmine, sest Master võib ebaõnnestuda. Ja kui Meister kukub, siis meie süsteem ei tööta. Teeme varundust. Mõned märgid, et põhifaili tuleb varundamiseks kopeerida. Selle võib usaldada ka koordineerimisteenistusele. Kuid sellel diagrammil vastutab kapten ise töötajate koordineerimise eest, siin koordineerib teenus andmete replikatsiooni tegevusi.
Täpsem valik on see, kui kogu koordineerimisega tegeleb meie teenus, nagu tavaliselt tehakse. Ta vastutab selle eest, et kõik toimiks. Ja kui midagi ei tööta, uurime seda ja proovime sellest olukorrast mööda minna. Igal juhul jääb meile Meister, kes kuidagi suhtleb orjadega ja saab mingi teenuse kaudu andmeid, infot, sõnumeid jne saata.
On olemas veelgi arenenum skeem, kui meil ei ole Masterit, on kõik sõlmed master-slavid, oma käitumiselt erinevad. Kuid nad peavad siiski üksteisega suhtlema, nii et nende toimingute koordineerimiseks on veel mõni teenus jäänud. Tõenäoliselt sobib selle skeemi järgi Cassandra, mis töötab sellel põhimõttel.
Raske on öelda, milline neist skeemidest töötab paremini. Igal neist on oma plussid ja miinused.
Ja Meistri juures pole vaja mõnda asja karta, sest nagu praktika näitab, pole ta nii vastuvõtlik pidevale teenimisele. Peamine on siin valida õige lahendus selle teenuse majutamiseks eraldi võimsas sõlmes, et sellel oleks piisavalt ressursse, nii et võimaluse korral pole kasutajatel sinna juurdepääsu, et nad seda protsessi kogemata ei tapaks. Kuid samal ajal on sellise skeemi puhul palju lihtsam juhtida töötajaid Master-protsessist, st see skeem on rakendamise seisukohast lihtsam.
Ja see skeem (ülal) on ilmselt keerulisem, kuid usaldusväärsem.
Peamine probleem on osalised tõrked. Näiteks kui saadame sõnumi üle võrgu, juhtub mingi õnnetus ja sõnumi saatja ei tea, kas tema sõnum on kätte saadud ja mis juhtus vastuvõtja poolel, ei tea, kas sõnumit töödeldi õigesti , st ta ei saa mingit kinnitust.
Seetõttu peame seda olukorda käsitlema. Ja kõige lihtsam on see sõnum uuesti saata ja oodata, kuni saame vastuse. Sel juhul ei võeta arvesse, kas vastuvõtja olek on muutunud. Võime saata sõnumi ja lisada samu andmeid kaks korda.
ZooKeeper pakub võimalusi selliste keeldumiste lahendamiseks, mis teeb ka meie elu lihtsamaks.
Nagu veidi varem mainitud, sarnaneb see mitme lõimega programmide kirjutamisega, kuid peamine erinevus seisneb selles, et hajutatud rakendustes, mida me ehitame erinevatele masinatele, on ainus suhtlusviis võrk. Põhimõtteliselt on see jagatud-mitte-midagi-arhitektuur. Igal protsessil või teenusel, mis ühes masinas töötab, on oma mälu, oma ketas, oma protsessor, mida ta kellegagi ei jaga.
Kui kirjutame ühes arvutis mitme lõimega programmi, siis saame andmete vahetamiseks kasutada ühismälu. Meil on seal kontekstilüliti, protsessid võivad lülituda. See mõjutab jõudlust. Ühest küljest pole klastris programmis sellist asja, kuid võrguga on probleeme.
Sellest tulenevalt on peamised probleemid, mis hajutatud süsteemide kirjutamisel tekivad, konfiguratsioon. Kirjutame mingisuguse avalduse. Kui see on lihtne, siis kodeerime kõikvõimalikke numbreid koodi sisse, kuid see on ebamugav, sest kui otsustame, et poolesekundilise ajalõpu asemel tahame ühesekundilist ajalõpu, siis tuleb rakendus uuesti kompileerida ja rulli kõik uuesti lahti. Üks asi on see, kui see on ühes masinas, kui saate selle lihtsalt taaskäivitada, aga kui meil on palju masinaid, peame pidevalt kõike kopeerima. Peame proovima muuta rakenduse konfigureeritavaks.
Siin räägime süsteemiprotsesside staatilisest konfiguratsioonist. See ei ole täielikult, võib-olla operatsioonisüsteemi seisukohast võib see olla meie protsesside staatiline konfiguratsioon, st see on konfiguratsioon, mida ei saa lihtsalt võtta ja värskendada.
Samuti on dünaamiline konfiguratsioon. Need on parameetrid, mida tahame käigu pealt muuta, et need sealt üles korjataks.
Milles siin probleem on? Värskendasime konfiguratsiooni, käivitasime selle, mis siis saab? Probleem võib olla selles, et ühest küljest rullisime konfigi välja, aga unustasime uue asja ära, konfig jäi sinnapaika. Teiseks värskendati konfiguratsiooni mõnes kohas, kuid teistes kohtades mitte. Ja mõned meie rakenduse protsessid, mis töötavad ühes masinas, taaskäivitati uue konfiguratsiooniga ja kuskil vanaga. Selle tulemuseks võib olla meie hajutatud rakendus konfiguratsiooni seisukohast ebajärjekindel. See probleem on tavaline. Dünaamilise konfiguratsiooni jaoks on see asjakohasem, kuna see tähendab, et seda saab käigu pealt muuta.
Teine probleem on rühma kuulumine. Meil on alati mingi hulk töötajaid, me tahame alati teada, kes neist on elus, kes surnud. Kui on Master, siis peab ta aru saama, milliseid töötajaid saab klientide juurde suunata, et nad arvutusi teeksid või andmetega töötaksid, ja milliseid mitte. Pidevalt kerkib esile probleem, et me peame teadma, kes meie klastris töötavad.
Teine tüüpiline probleem on juhivalimised, kui tahame teada, kes juhib. Üks näide on replikatsioon, kui meil on mõni protsess, mis võtab vastu kirjutamistoiminguid ja seejärel kordab neid teiste protsesside hulgas. Temast saab juht, kõik teised kuuletuvad talle, järgivad teda. Protsess tuleb valida nii, et see oleks kõigile üheselt mõistetav, et ei tuleks välja, et valitakse kaks juhti.
Samuti on üksteist välistav juurdepääs. Siin on probleem keerulisem. On olemas selline asi nagu mutex, kui kirjutate mitme lõimega programme ja soovite, et juurdepääs mõnele ressursile, näiteks mäluelemendile, oleks piiratud ja seda teostaks ainult üks lõime. Siin võiks ressurss olla midagi abstraktsemat. Ja meie võrgu erinevate sõlmede erinevad rakendused peaksid saama ainult eksklusiivse juurdepääsu antud ressursile, mitte selleks, et kõik saaksid seda muuta või sinna midagi kirjutada. Need on nn lukud.
ZooKeeper võimaldab teil kõik need probleemid ühel või teisel määral lahendada. Ja ma näitan näidetega, kuidas see võimaldab teil seda teha.
Blokeerivaid primitiive pole. Kui hakkame midagi kasutama, ei oota see primitiiv ühegi sündmuse toimumist. Tõenäoliselt töötab see asi asünkroonselt, võimaldades seeläbi protsessidel mitte rippuda, kui nad midagi ootavad. See on väga kasulik asi.
Kõiki klientide taotlusi käsitletakse üldjärjekorras.
Ja klientidel on võimalus saada teateid mingi oleku muutustest, andmete muutumisest enne, kui klient ise muutunud andmeid näeb.
ZooKeeper saab töötada kahes režiimis. Esimene on iseseisev, ühes sõlmes. See on testimiseks mugav. See võib töötada ka klastrirežiimis mis tahes arvul serveritel. Kui meil on 100 masinast koosnev klaster, siis pole vaja, et see 100 masina peal töötaks. Piisab, kui valida mitu masinat, kus saab ZooKeeperi käivitada. Ja see järgib kõrge kättesaadavuse põhimõtet. ZooKeeper salvestab igal töötaval eksemplaril andmetest terve koopia. Hiljem räägin teile, kuidas ta seda teeb. See ei killusta andmeid ega partitsiooni. Ühest küljest on see miinus, et me ei saa palju salvestada, teisest küljest pole seda vaja teha. See pole mõeldud selleks, see pole andmebaas.
Andmeid saab vahemällu salvestada kliendi poolel. See on standardpõhimõte, et me ei katkestaks teenust ega laadiks seda samade päringutega. Nutikas klient tavaliselt teab sellest ja salvestab selle vahemällu.
Näiteks siin on midagi muutunud. Mingi rakendus on olemas. Valiti uus juht, kes vastutab näiteks kirjutamistoimingute töötlemise eest. Ja me tahame andmeid kopeerida. Üks lahendus on panna see silmusesse. Ja me küsime pidevalt oma teenuses – kas midagi on muutunud? Teine võimalus on optimaalsem. See on kellamehhanism, mis võimaldab teil teavitada kliente, et midagi on muutunud. See on ressursside poolest odavam ja klientidele mugavam meetod.
Klient on kasutaja, kes kasutab ZooKeeperit.
Server on ZooKeeperi protsess ise.
Znode on ZooKeeperi võtmeasi. ZooKeeper salvestab kõik znode mällu ja on korraldatud hierarhilise diagrammi kujul puu kujul.
Toiminguid on kahte tüüpi. Esimene on värskendamine/kirjutamine, kui mõni toiming muudab meie puu olekut. Puu on tavaline.
Ja on võimalik, et klient ei täida ühte päringut ja on katkestatud, kuid saab luua seansi, mille kaudu ta ZooKeeperiga suhtleb.
ZooKeeperi andmemudel meenutab failisüsteemi. Seal on standardjuur ja siis käisime justkui läbi kataloogidest, mis juurtest lähevad. Ja siis esimese taseme, teise taseme kataloog. See kõik on znode.
Iga znode võib salvestada mõningaid andmeid, tavaliselt mitte väga suuri, näiteks 10 kilobaiti. Ja igal znode'il võib olla teatud arv lapsi.
Znode on mitut tüüpi. Neid saab luua. Ja znode loomisel määrame tüübi, kuhu see peaks kuuluma.
Neid on kahte tüüpi. Esimene on efemeerne lipp. Znode elab seansi jooksul. Näiteks on klient loonud seansi. Ja seni, kuni see seanss elab, on see olemas. See on vajalik selleks, et mitte toota midagi mittevajalikku. See sobib ka hetkedeks, mil meie jaoks on oluline seansi sees andmeprimitiive salvestada.
Teine tüüp on järjestikune lipp. See suurendab loendurit teel znode'i. Näiteks oli meil kataloog rakendusega 1_5. Ja kui me lõime esimese sõlme, sai see p_1, teine - p_2. Ja kui me seda meetodit iga kord kutsume, läbime kogu tee, näidates ainult osa teest, ja seda arvu suurendatakse automaatselt, kuna tähistame sõlme tüüpi - järjestikune.
Tavaline znode. Ta elab alati ja tal on nimi, mille me talle ütleme.
Veel üks kasulik asi on kellalipp. Kui me selle installime, saab klient tellida mõne konkreetse sõlme sündmused. Näitan teile hiljem näitega, kuidas seda tehakse. ZooKeeper ise teavitab klienti, et sõlme andmed on muutunud. Teatised ei garanteeri siiski uute andmete saabumist. Nad lihtsalt ütlevad, et midagi on muutunud, nii et peate ikkagi hiljem andmeid võrdlema eraldi kõnedega.
Ja nagu ma juba ütlesin, määratakse andmete järjekord kilobaitidega. Sinna pole vaja suuri tekstiandmeid salvestada, sest see pole andmebaas, see on tegevuste koordineerimise server.
Ma räägin teile natuke seanssidest. Kui meil on mitu serverit, saame seansi identifikaatori abil läbipaistvalt serverist serverisse liikuda. See on üsna mugav.
Igal seansil on teatud aeg. Seanss määratakse selle järgi, kas klient saadab selle seansi ajal midagi serverisse. Kui ta ajalõpu ajal midagi ei edastanud, siis seanss katkeb või klient saab selle ise sulgeda.
Sellel pole nii palju funktsioone, kuid selle API-ga saate teha erinevaid asju. See kõne, mida nägime loomas, loob znode ja võtab kolm parameetrit. See on tee znode'i ja see peab olema täielikult määratud juurest. Ja see on ka mõned andmed, mida tahame sinna üle kanda. Ja lipu tüüp. Ja pärast loomist tagastab tee znode.
Teiseks saate selle kustutada. Siin on trikk selles, et teine parameeter saab lisaks znode-i teele määrata versiooni. Sellest lähtuvalt kustutatakse see sõlm, kui selle versioon, mille me üle kandsime, on samaväärne tegelikult eksisteeriva versiooniga.
Kui me ei soovi seda versiooni kontrollida, edastame lihtsalt argumendi "-1".
Kolmandaks kontrollib see znode olemasolu. Tagastab tõene, kui sõlm on olemas, false muul juhul.
Ja siis ilmub lipukell, mis võimaldab teil seda sõlme jälgida.
Saate määrata selle lipu isegi olematule sõlmele ja saada selle ilmumisel teatise. Sellest võib ka kasu olla.
Paar väljakutset on veel getData. On selge, et saame andmeid vastu võtta znode kaudu. Võite kasutada ka lipu kella. Sel juhul seda ei installita, kui sõlme pole. Seetõttu peate mõistma, et see on olemas, ja seejärel andmeid vastu võtma.
On olemas ka Määra andmed. Siin edastame versiooni. Ja kui me selle edasi anname, uuendatakse teatud versiooni znode andmeid.
Selle kontrolli välistamiseks võite määrata ka "-1".
Teine kasulik meetod on saada lapsed. Samuti saame nimekirja kõigist sellesse kuuluvatest znodedest. Saame seda jälgida lipukella seadmisega.
Ja meetod sünkroonida võimaldab saata kõik muudatused korraga, tagades seeläbi nende salvestamise ja kõigi andmete täieliku muutmise.
Kui tuua analoogiaid tavalise programmeerimisega, siis kui kasutate selliseid meetodeid nagu kirjutamine, mis kirjutavad midagi kettale ja pärast seda, kui see teile vastuse tagastab, pole mingit garantiid, et olete andmed kettale kirjutanud. Ja isegi kui operatsioonisüsteem on kindel, et kõik on kirjutatud, on kettal endal mehhanismid, kus protsess läbib puhvrikihte ja alles pärast seda paigutatakse andmed kettale.
Enamasti kasutatakse asünkroonseid kõnesid. See võimaldab kliendil töötada paralleelselt erinevate taotlustega. Võite kasutada sünkroonset lähenemist, kuid see on vähem produktiivne.
Kaks toimingut, millest me rääkisime, on värskendamine/kirjutamine, mis muudavad andmeid. Need on loomine, setData, sünkroonimine, kustutamine. Ja lugemine on olemas, getData, getChildren.
Nüüd mõned näited selle kohta, kuidas saate teha primitiive hajutatud süsteemis töötamiseks. Näiteks miski konfiguratsiooniga seotud. Ilmunud on uus töötaja. Lisasime masina ja alustasime protsessiga. Ja seal on järgmised kolm küsimust. Kuidas see ZooKeeperilt konfiguratsiooni päringuid teeb? Ja kui me tahame konfiguratsiooni muuta, kuidas me seda muudame? Ja pärast seda, kui me selle muutsime, kuidas need töötajad, kes meil olid, selle saavad?
ZooKeeper teeb selle suhteliselt lihtsaks. Näiteks on meie znode puu. Siin on meie rakenduse jaoks sõlm, sellesse loome täiendava sõlme, mis sisaldab konfiguratsiooni andmeid. Need võivad olla eraldi parameetrid, kuid ei pruugi olla. Kuna suurus on väike, on konfiguratsiooni suurus tavaliselt ka väike, nii et seda on siin täiesti võimalik salvestada.
Kasutate meetodit getData et hankida sõlmest töötaja konfiguratsioon. Määra tõeseks. Kui seda sõlme mingil põhjusel ei eksisteeri, teavitatakse meid sellest selle ilmumisel või muutumisel. Kui tahame teada, et miski on muutunud, siis paneme selle tõeks. Ja kui selle sõlme andmed muutuvad, saame sellest teada.
Määra andmed. Seadistame andmed, määrame “-1”, st me ei kontrolli versiooni, eeldame, et meil on alati üks konfiguratsioon, me ei pea palju konfiguratsioone salvestama. Kui teil on vaja palju salvestada, peate lisama veel ühe taseme. Usume, et siin on ainult üks, seega värskendame ainult uusimat, nii et me ei kontrolli versiooni. Hetkel saavad kõik varem liitunud kliendid teate, et selles sõlmes on midagi muutunud. Ja pärast nende kättesaamist peavad nad ka andmed uuesti nõudma. Teavitus seisneb selles, et nad ei saa andmeid ise, vaid ainult teate muudatustest. Pärast seda peavad nad küsima uusi andmeid.
Teine võimalus primitiivi kasutamiseks on rühma kuulumine. Meil on hajutatud rakendus, seal on hunnik töötajaid ja me tahame aru saada, et nad on kõik paigas. Seetõttu peavad nad end registreerima, et nad töötavad meie rakenduses. Ja me tahame ka teada saada, kas Master-protsessist või kusagilt mujalt, kõigi aktiivsete töötajate kohta, kes meil praegu on.
Kuidas me seda teeme? Rakenduse jaoks loome töötajate sõlme ja lisame sinna loomismeetodi abil alamtaseme. Mul on slaidil viga. Siin on vaja järjestikune täpsustada, siis luuakse kõik töötajad ükshaaval. Ja rakendus, mis taotleb kõiki andmeid selle sõlme laste kohta, võtab vastu kõik olemasolevad aktiivsed töötajad.
See on nii kohutav rakendus, kuidas seda Java-koodis teha. Alustame lõpust, peamise meetodiga. See on meie klass, loome selle meetodi. Esimese argumendina kasutame hosti, kus me ühendame, st seame selle argumendiks. Ja teine argument on rühma nimi.
Kuidas ühendus tekib? See on lihtne näide kasutatavast API-st. Siin on kõik suhteliselt lihtne. Seal on standardklassi ZooKeeper. Anname sellele peremehed edasi. Ja määrake ajalõpuks näiteks 5 sekundit. Ja meil on liige nimega connectSignal. Põhimõtteliselt loome edastatud teekonnal rühma. Me ei kirjuta sinna andmeid, kuigi midagi oleks võinud kirjutada. Ja siinne sõlm on püsivat tüüpi. Põhimõtteliselt on see tavaline tavaline sõlm, mis eksisteerib kogu aeg. Siin luuakse seanss. See on kliendi enda teostus. Meie klient saadab perioodiliselt teateid, mis näitavad, et seanss on elus. Ja kui seansi lõpetame, helistame kinni ja ongi kõik, seanss jääb ära. Seda juhuks, kui meie jaoks midagi ära kukub, nii et ZooKeeper saab sellest teada ja katkestab seansi.
Kuidas ressurssi lukustada? Siin on kõik veidi keerulisem. Meil on hulk töötajaid, on mingi ressurss, mida tahame lukustada. Selleks loome näiteks eraldi sõlme nimega lock1. Kui saime selle luua, siis saime siin luku. Ja kui meil ei õnnestunud seda luua, siis proovib töötaja saada siit getData ja kuna sõlm on juba loodud, siis paneme siia jälgija ja hetkel, kui selle sõlme olek muutub, saame sellest teada. Ja me võime proovida, et oleks aega selle taasloomiseks. Kui võtsime selle sõlme, võtsime selle luku, siis pärast seda, kui me lukku enam ei vaja, loobume sellest, kuna sõlm eksisteerib ainult seansi jooksul. Vastavalt see kaob. Ja teine klient saab mõne teise seansi raames selle sõlme lukustada, õigemini saab ta teate, et midagi on muutunud ja ta saab proovida seda õigel ajal teha.
Veel üks näide, kuidas saate valida peamise juhi. See on veidi keerulisem, kuid samas ka suhteliselt lihtne. Mis siin toimub? Seal on põhisõlm, mis koondab kõik töötajad. Püüame saada andmeid juhi kohta. Kui see õnnestus, st saime mõned andmed, hakkab meie töötaja seda juhti järgima. Ta usub, et juht on juba olemas.
Kui juht suri mingil põhjusel, näiteks kukkus ära, siis proovime luua uue juhi. Ja kui meil õnnestub, saab meie töötajast juht. Ja kui kellelgi õnnestus sel hetkel uus juht luua, siis püüame aru saada, kes see on, ja siis järgime teda.
Siin tekib nn karjaefekt ehk karjaefekt, sest kui juht sureb, saab juhiks see, kes on ajas esimene.
Ressursi jäädvustamisel võite proovida kasutada veidi teistsugust lähenemist, mis on järgmine. Näiteks tahame saada lukku, kuid ilma hertiefektita. See seisneb selles, et meie rakendus taotleb juba olemasoleva lukuga sõlme kõigi sõlme ID-de loendeid. Ja kui enne seda sõlm, mille jaoks luku lõime, on saadud komplektist väikseim, tähendab see, et oleme luku kinni püüdnud. Kontrollime, kas oleme luku saanud. Kontrolliks on tingimus, et uue luku loomisel saadud ID on minimaalne. Ja kui saime, siis töötame edasi.
Kui mõni id on väiksem kui meie lukk, siis paneme sellele sündmusele jälgija ja ootame teadet, kuni midagi muutub. St saime selle luku kätte. Ja kuni see ära ei kuku, me ei muutu minimaalseks ID-ks ja ei saa minimaalset lukku ja seega saame sisse logida. Ja kui see tingimus ei ole täidetud, siis läheme kohe siia ja proovime seda lukku uuesti saada, sest selle ajaga võib midagi muutunud olla.
Millest ZooKeeper koosneb? Seal on 4 peamist asja. See on töötlemisprotsess – taotlus. Ja ka ZooKeeper Atomic Broadcast. Seal on Commit Log, kus kõik toimingud salvestatakse. Ja In-memory Replicated DB ise, st andmebaas ise, kus kogu see puu on salvestatud.
Väärib märkimist, et kõik kirjutamistoimingud läbivad päringuprotsessori. Ja lugemistoimingud lähevad otse mälus olevasse andmebaasi.
Andmebaas ise on täielikult kopeeritud. Kõik ZooKeeperi eksemplarid salvestavad andmete täieliku koopia.
Andmebaasi taastamiseks pärast krahhi on olemas Commit logi. Tavapraktika on see, et enne andmete mällu jõudmist kirjutatakse need sinna kirja, et kui see kokku jookseb, saab selle logi taasesitada ja süsteemi oleku taastada. Kasutatakse ka andmebaasi perioodilisi hetktõmmiseid.
ZooKeeper Atomic Broadcast on asi, mida kasutatakse kopeeritud andmete säilitamiseks.
ZAB valib sisemiselt juhi ZooKeeperi sõlme vaatenurgast. Teised sõlmed saavad tema järgijateks ja ootavad temalt teatud toiminguid. Kui nad saavad kandeid, edastavad nad need kõik juhile. Ta teeb esmalt kirjutamisoperatsiooni ja saadab seejärel oma jälgijatele teate selle kohta, mis on muutunud. Tegelikult tuleb seda teha atomaarselt, st kogu asja salvestamine ja edastamine peab toimuma atomaarselt, tagades sellega andmete järjepidevuse.
See töötleb ainult kirjutamistaotlusi. Selle peamine ülesanne on muuta toimingu tehinguvärskenduseks. See on spetsiaalselt loodud päring.
Ja siin väärib märkimist, et sama toimingu jaoks on värskenduste idempotentsus tagatud. Mis see on? Sellel asjal on kaks korda täitmisel sama olek, st taotlus ise ei muutu. Ja seda on vaja teha selleks, et krahhi korral saaks toimingu uuesti käivitada, veeretades seeläbi tagasi hetkel ära kukkunud muudatused. Sel juhul muutub süsteemi olek samaks, st ei tohiks juhtuda, et samade, näiteks uuendusprotsesside jada viis süsteemi erinevate lõppseisunditeni.
Allikas: www.habr.com