Suosittelen lukemaan luennon "Hadoop. ZooKeeper" transkription sarjasta "Menetelmät suurten tietomäärien hajautettuun käsittelyyn Hadoopissa"
Mikä on ZooKeeper, sen paikka Hadoop-ekosysteemissä. Hajautettua tietojenkäsittelyä koskevia valheita. Kaavio tavallisesta hajautetusta järjestelmästä. Vaikeus hajautettujen järjestelmien koordinoinnissa. Tyypillisiä koordinaatioongelmia. ZooKeeperin suunnittelun periaatteet. ZooKeeper-tietomalli. znode liput. Istunnot. Asiakassovellusliittymä. Primitiivit (kokoonpano, ryhmäjäsenyys, yksinkertaiset lukot, johtajan valinta, lukitus ilman laumavaikutusta). ZooKeeper-arkkitehtuuri. ZooKeeper DB. ZAB. Pyynnön käsittelijä.
Tänään puhumme ZooKeeperistä. Tämä asia on erittäin hyödyllinen. Sillä, kuten kaikilla Apache Hadoop -tuotteilla, on logo. Se kuvaa miestä.
Ennen tätä puhuttiin lähinnä siitä, miten dataa siellä voidaan käsitellä, miten sitä tallennetaan, eli miten sitä jotenkin käytetään ja miten sen kanssa työskennellä. Ja tänään haluaisin puhua hieman hajautettujen sovellusten rakentamisesta. Ja ZooKeeper on yksi niistä asioista, joiden avulla voit yksinkertaistaa tätä asiaa. Tämä on eräänlainen palvelu, joka on tarkoitettu jonkinlaiseen prosessien vuorovaikutuksen koordinointiin hajautetuissa järjestelmissä, hajautetuissa sovelluksissa.
Tällaisten sovellusten tarve kasvaa päivä päivältä, siitä kurssillamme on kyse. Toisaalta MapReducen ja tämän valmiin kehyksen avulla voit tasoittaa tätä monimutkaisuutta ja vapauttaa ohjelmoijan kirjoittamasta primitiivisiä, kuten vuorovaikutusta ja prosessien koordinointia. Mutta toisaalta, kukaan ei takaa, ettei tätä tarvitse tehdä joka tapauksessa. MapReduce tai muut valmiit puitteet eivät aina korvaa täysin joitain tapauksia, joita ei voida toteuttaa tällä. Mukaan lukien itse MapReduce ja joukko muita Apache-projekteja; itse asiassa ne ovat myös hajautettuja sovelluksia. Ja kirjoittamisen helpottamiseksi he kirjoittivat ZooKeeperin.
Kuten kaikki Hadoop-sovellukset, sen on kehittänyt Yahoo! Se on nyt myös virallinen Apache-sovellus. Sitä ei kehitetä yhtä aktiivisesti kuin HBasea. Jos menet JIRA HBaseen, niin siellä tulee joka päivä nippu bugiraportteja, joukko ehdotuksia jonkin asian optimoimiseksi, eli elämä projektissa jatkuu jatkuvasti. Ja ZooKeeper on toisaalta suhteellisen yksinkertainen tuote, ja toisaalta tämä varmistaa sen luotettavuuden. Ja se on melko helppokäyttöinen, minkä vuoksi siitä on tullut standardi Hadoop-ekosysteemin sovelluksissa. Joten ajattelin, että olisi hyödyllistä tarkistaa se ymmärtääkseni, miten se toimii ja miten sitä käytetään.
Tämä on kuva jostain luennolta, joka meillä oli. Voimme sanoa, että se on ortogonaalinen kaikkeen, mitä olemme tähän mennessä tarkastelleet. Ja kaikki tässä mainittu toimii tavalla tai toisella ZooKeeperin kanssa, eli se on palvelu, joka käyttää kaikkia näitä tuotteita. HDFS tai MapReduce eivät kirjoita omia vastaavia palvelujaan, jotka toimisivat erityisesti heille. Vastaavasti käytetään ZooKeeperiä. Ja tämä yksinkertaistaa kehitystä ja joitain virheisiin liittyviä asioita.
Mistä tämä kaikki tulee? Näyttää siltä, että käynnistimme kaksi sovellusta rinnakkain eri tietokoneissa, liitimme ne merkkijonoon tai verkkoon, ja kaikki toimii. Mutta ongelma on, että verkko on epäluotettava, ja jos haistelit liikennettä tai katsot mitä siellä tapahtuu alhaisella tasolla, kuinka asiakkaat ovat vuorovaikutuksessa verkossa, voit usein nähdä, että jotkut paketit katoavat tai lähetetään uudelleen. Ei turhaan keksitty TCP-protokollat, joiden avulla voit muodostaa tietyn istunnon ja taata viestien toimituksen. Mutta joka tapauksessa edes TCP ei voi aina pelastaa sinua. Kaikella on aikakatkaisu. Verkko voi yksinkertaisesti katketa hetkeksi. Se voi vain vilkkua. Ja kaikki tämä johtaa siihen, että et voi luottaa verkon luotettavuuteen. Tämä on tärkein ero rinnakkaisten sovellusten kirjoittamiseen, jotka toimivat yhdessä tietokoneessa tai yhdessä supertietokoneessa, jossa ei ole verkkoa ja jossa muistissa on luotettavampi tiedonsiirtoväylä. Ja tämä on perustavanlaatuinen ero.
Muun muassa verkkoa käytettäessä on aina tietty latenssi. Levyllä on myös se, mutta verkossa on sitä enemmän. Latenssi on viiveaika, joka voi olla joko pieni tai melko merkittävä.
Verkon topologia muuttuu. Mikä on topologia - tämä on verkkolaitteidemme sijoitus. On datakeskuksia, siellä on telineitä, siellä on kynttilöitä. Kaikki tämä voidaan kytkeä uudelleen, siirtää jne. Tämä kaikki on myös otettava huomioon. IP-nimet muuttuvat, reititys, jonka kautta liikenne kulkee, muuttuu. Tämä on myös otettava huomioon.
Verkko voi myös muuttua varustelutasolla. Käytännössä voin sanoa, että verkkoinsinöörimme todella haluavat päivittää ajoittain jotain kynttilöitä. Yhtäkkiä ilmestyi uusi laiteohjelmisto, eivätkä he olleet erityisen kiinnostuneita jostain Hadoop-klusterista. Heillä on oma työpaikkansa. Heille tärkeintä on, että verkko toimii. Vastaavasti he haluavat ladata jotain sinne uudelleen, tehdä vilkkua laitteistoonsa, ja myös laitteisto vaihtuu ajoittain. Kaikki tämä on jotenkin otettava huomioon. Kaikki tämä vaikuttaa hajautettuun sovellukseemme.
Yleensä ihmiset, jotka alkavat jostain syystä työskennellä suurten tietomäärien kanssa, uskovat, että Internet on rajaton. Jos siellä on usean teratavun tiedosto, voit viedä sen palvelimellesi tai tietokoneellesi ja avata sen käyttämällä miten ja katso. Toinen virhe löytyy puhti katso lokit. Älä koskaan tee tätä, koska se on huonoa. Koska Vim yrittää puskuroida kaiken, ladata kaiken muistiin, varsinkin kun alamme liikkua tämän lokin läpi ja etsiä jotain. Nämä ovat asioita, jotka unohtuvat, mutta harkitsemisen arvoisia.
On helpompi kirjoittaa yksi ohjelma, joka toimii yhdessä tietokoneessa yhdellä prosessorilla.
Kun järjestelmämme kasvaa, haluamme rinnastaa sen kaiken ja rinnastaa sen paitsi tietokoneessa myös klusterissa. Herää kysymys: miten tämä asia koordinoidaan? Sovelluksemme eivät ehkä edes ole vuorovaikutuksessa toistensa kanssa, mutta suoritimme useita prosesseja rinnakkain useilla palvelimilla. Ja kuinka valvoa, että kaikki menee hyvin heille? Esimerkiksi he lähettävät jotain Internetin kautta. Heidän täytyy kirjoittaa tilastaan jonnekin, esimerkiksi johonkin tietokantaan tai lokiin, sitten koota tämä loki ja sitten analysoida se jonnekin. Lisäksi meidän on otettava huomioon, että prosessi toimi ja toimi, siinä ilmeni yhtäkkiä jokin virhe tai se kaatui, niin kuinka nopeasti saamme siitä selvää?
On selvää, että kaikkea tätä voidaan seurata nopeasti. Tämä on myös hyvä, mutta seuranta on rajoitettu asia, jonka avulla voit seurata joitain asioita korkeimmalla tasolla.
Kun haluamme prosessiemme alkavan olla vuorovaikutuksessa toistensa kanssa, esimerkiksi lähettävän toisilleen jotain dataa, herää myös kysymys - miten tämä tapahtuu? Tuleeko jonkinlainen kilpailutilanne, ylikirjoittavatko ne toisensa, saapuvatko tiedot oikein, katoaako mitään matkan varrella? Meidän on kehitettävä jonkinlainen protokolla jne.
Kaikkien näiden prosessien koordinointi ei ole vähäpätöinen asia. Ja se pakottaa kehittäjän menemään vielä alemmalle tasolle ja kirjoittamaan järjestelmiä joko tyhjästä tai ei aivan tyhjästä, mutta tämä ei ole niin yksinkertaista.
Jos keksit salausalgoritmin tai jopa otat sen käyttöön, heitä se heti pois, koska todennäköisesti se ei toimi sinulle. Se sisältää todennäköisesti joukon virheitä, jotka olet unohtanut ilmoittaa. Älä koskaan käytä sitä mihinkään vakavaan, koska se on todennäköisesti epävakaa. Koska kaikki olemassa olevat algoritmit on testattu ajan toimesta hyvin pitkään. Yhteisö häiritsee sitä. Tämä on erillinen aihe. Ja se on sama täällä. Jos on mahdollista olla toteuttamatta jonkinlaista prosessisynkronointia itse, on parempi olla tekemättä tätä, koska se on melko monimutkaista ja johtaa jatkuvasti virheiden etsimisen horjuvalle polulle.
Tänään puhumme ZooKeeperistä. Yhtäältä se on viitekehys, toisaalta se on palvelu, joka helpottaa kehittäjän elämää ja yksinkertaistaa logiikan toteuttamista ja prosessiemme koordinointia mahdollisimman paljon.
Muistetaan, miltä tavallinen hajautettu järjestelmä voisi näyttää. Tästä puhuimme - HDFS, HBase. On Master-prosessi, joka hallitsee työntekijöitä ja orjaprosesseja. Hän vastaa tehtävien koordinoinnista ja jakamisesta, työntekijöiden uudelleenkäynnistämisestä, uusien käynnistämisestä ja kuorman jakamisesta.
Edistyksellisempi asia on Koordinointipalvelu, eli itse koordinointitehtävän siirtäminen erilliseen prosessiin sekä jonkinlaisen vara- tai valmiusmasterin ajaminen rinnakkain, koska Master saattaa epäonnistua. Ja jos Mestari kaatuu, järjestelmämme ei toimi. Suoritamme varmuuskopion. Jotkut toteavat, että isäntä on kopioitava varmuuskopioon. Tämä voidaan myös uskoa koordinointipalveluun. Mutta tässä kaaviossa päällikkö itse vastaa työntekijöiden koordinoinnista, tässä palvelu koordinoi tietojen replikointitoimintoja.
Edistyksellisempi vaihtoehto on, kun kaikki koordinointi hoituu palvelussamme, kuten yleensä tehdään. Hän ottaa vastuun siitä, että kaikki toimii. Ja jos jokin ei toimi, otamme siitä selvää ja yritämme kiertää tämän tilanteen. Joka tapauksessa meille jää isäntä, joka jollakin tavalla on vuorovaikutuksessa orjien kanssa ja voi lähettää dataa, tietoa, viestejä jne. jonkin palvelun kautta.
On olemassa vieläkin edistyneempi järjestelmä, kun meillä ei ole isäntä, kaikki solmut ovat master-orjia, käyttäytymisellään erilaisia. Mutta heidän on silti oltava vuorovaikutuksessa toistensa kanssa, joten näiden toimien koordinoimiseen on vielä jonkin verran palvelua jäljellä. Luultavasti Cassandra, joka toimii tällä periaatteella, sopii tähän järjestelmään.
On vaikea sanoa, mikä näistä järjestelmistä toimii paremmin. Jokaisella on omat hyvät ja huonot puolensa.
Ja joitain asioita Mestarin kanssa ei tarvitse pelätä, koska, kuten käytäntö osoittaa, hän ei ole niin herkkä jatkuvalle palvelemiselle. Tärkeintä tässä on valita oikea ratkaisu tämän palvelun isännöintiin erillisessä tehokkaassa solmussa, jotta sillä on tarpeeksi resursseja, jotta käyttäjillä ei ole mahdollisuuksien mukaan pääsyä sinne, jotta he eivät vahingossa tapa tätä prosessia. Mutta samaan aikaan tällaisessa järjestelmässä on paljon helpompi hallita työntekijöitä Master-prosessista, eli tämä järjestelmä on yksinkertaisempi toteutuksen kannalta.
Ja tämä järjestelmä (yllä) on luultavasti monimutkaisempi, mutta luotettavampi.
Suurin ongelma on osittaiset epäonnistumiset. Esimerkiksi kun lähetämme viestin verkon kautta, tapahtuu jonkinlainen onnettomuus, jolloin viestin lähettäjä ei tiedä onko hänen viestinsä vastaanotettu ja mitä tapahtui vastaanottajan puolella, ei tiedä onko viesti käsitelty oikein. , eli hän ei saa mitään vahvistusta.
Näin ollen meidän on käsiteltävä tämä tilanne. Ja yksinkertaisin asia on lähettää tämä viesti uudelleen ja odottaa, kunnes saamme vastauksen. Tässä tapauksessa ei oteta huomioon, onko vastaanottimen tila muuttunut. Saatamme lähettää viestin ja lisätä samat tiedot kahdesti.
ZooKeeper tarjoaa tapoja käsitellä tällaisia kieltäytymisiä, mikä myös helpottaa elämäämme.
Kuten aiemmin mainittiin, tämä on samanlaista kuin monisäikeisten ohjelmien kirjoittaminen, mutta suurin ero on, että hajautetuissa sovelluksissa, jotka rakennamme eri koneille, ainoa tapa kommunikoida on verkko. Pohjimmiltaan tämä on jaettu-ei mitään -arkkitehtuuri. Jokaisella yhdellä koneella toimivalla prosessilla tai palvelulla on oma muisti, oma levy, oma prosessori, jota se ei jaa kenenkään kanssa.
Jos kirjoitamme monisäikeisen ohjelman yhdelle tietokoneelle, voimme käyttää jaettua muistia tietojen vaihtamiseen. Meillä on siellä kontekstin kytkin, prosessit voivat vaihtaa. Tämä vaikuttaa suorituskykyyn. Toisaalta klusterin ohjelmassa ei ole sellaista, mutta verkossa on ongelmia.
Näin ollen tärkeimmät hajautettuja järjestelmiä kirjoitettaessa ilmenevät ongelmat ovat konfigurointi. Kirjoitamme jonkinlaista hakemusta. Jos se on yksinkertaista, koodaamme koodiin kaikenlaisia numeroita, mutta tämä on hankalaa, koska jos päätämme, että puolen sekunnin aikakatkaisun sijaan haluamme yhden sekunnin aikakatkaisun, meidän on käännettävä sovellus uudelleen ja rullaa kaikki uudelleen. Se on yksi asia, kun se on yhdellä koneella, kun sen voi vain käynnistää uudelleen, mutta kun meillä on useita koneita, meidän on jatkuvasti kopioitava kaikki. Meidän on yritettävä tehdä sovelluksesta konfiguroitava.
Tässä puhumme järjestelmäprosessien staattisista määrityksistä. Tämä ei ole kokonaan, ehkä käyttöjärjestelmän näkökulmasta, se voi olla staattinen konfiguraatio prosesseillemme, eli tämä on konfiguraatio, jota ei voi yksinkertaisesti ottaa ja päivittää.
On myös dynaaminen kokoonpano. Nämä ovat parametreja, joita haluamme muuttaa lennossa, jotta ne poimitaan sieltä.
Mikä tässä on ongelmana? Päivitimme asetukset, otimme sen käyttöön, mitä sitten? Ongelmana voi olla se, että toisaalta otimme konfiguraation käyttöön, mutta unohdimme uuden asian, konfiguraatio jäi sinne. Toiseksi julkaisun aikana kokoonpano päivitettiin joissakin paikoissa, mutta ei toisissa. Ja jotkut sovelluksemme prosessit, jotka toimivat yhdessä koneessa, käynnistettiin uudelleen uudella konfiguraatiolla ja jossain vanhalla. Tämä voi johtaa siihen, että hajautettu sovelluksemme on epäjohdonmukainen kokoonpanon näkökulmasta. Tämä ongelma on yleinen. Dynaamisen kokoonpanon kannalta se on merkityksellisempi, koska se tarkoittaa, että sitä voidaan muuttaa lennossa.
Toinen ongelma on ryhmään kuuluminen. Meillä on aina joukko työntekijöitä, haluamme aina tietää, kuka heistä on elossa, kumpi on kuollut. Jos on Master, hänen on ymmärrettävä, mitkä työntekijät voidaan ohjata asiakkaiden luo suorittamaan laskelmia tai työskentelemään datan kanssa ja mitkä eivät. Jatkuvasti esiin nouseva ongelma on, että meidän on tiedettävä, kuka klusterissamme työskentelee.
Toinen tyypillinen ongelma on johtajavaalit, kun haluamme tietää, kuka on vastuussa. Yksi esimerkki on replikointi, kun meillä on jokin prosessi, joka vastaanottaa kirjoitustoiminnot ja replikoi ne sitten muiden prosessien kesken. Hän on johtaja, kaikki muut tottelevat häntä, seuraavat häntä. On tarpeen valita prosessi niin, että se on yksiselitteinen kaikille, jotta ei käy ilmi, että valitaan kaksi johtajaa.
On myös toisensa poissulkeva pääsy. Tässä ongelma on monimutkaisempi. On olemassa sellainen asia kuin mutex, kun kirjoitat monisäikeisiä ohjelmia ja haluat pääsyn johonkin resurssiin, esimerkiksi muistisoluun, rajoitetun ja suorittavan vain yhden säikeen. Tässä resurssi voisi olla jotain abstraktimpaa. Ja verkkomme eri solmujen eri sovellusten tulisi saada vain eksklusiivinen pääsy tiettyyn resurssiin, ei niin, että kaikki voivat muuttaa sitä tai kirjoittaa sinne jotain. Nämä ovat niin sanottuja lukkoja.
ZooKeeper antaa sinun ratkaista kaikki nämä ongelmat tavalla tai toisella. Ja näytän esimerkein, kuinka sen avulla voit tehdä tämän.
Ei ole olemassa estäviä primitiivejä. Kun alamme käyttää jotain, tämä primitiivinen ei odota mitään tapahtumaa. Todennäköisesti tämä asia toimii asynkronisesti, jolloin prosessit eivät jumiudu odottaessaan jotain. Tämä on erittäin hyödyllinen asia.
Kaikki asiakaspyynnöt käsitellään yleisen jonon järjestyksessä.
Ja asiakkailla on mahdollisuus saada ilmoitus jonkin tilan muutoksista, muutoksista tiedoissa, ennen kuin asiakas näkee muuttuneet tiedot itse.
ZooKeeper voi toimia kahdessa tilassa. Ensimmäinen on erillinen, yhdessä solmussa. Tämä on kätevä testaukseen. Se voi myös toimia klusteritilassa millä tahansa määrällä palvelimia. Jos meillä on 100 koneen klusteri, sen ei tarvitse toimia 100 koneella. Riittää, kun valitset useita koneita, joilla voit käyttää ZooKeeperiä. Ja se tunnustaa korkean saatavuuden periaatteen. Jokaiseen käynnissä olevaan esiintymään ZooKeeper tallentaa koko kopion tiedoista. Kerron myöhemmin, kuinka hän sen tekee. Se ei sirpaloi tietoja tai osioita sitä. Toisaalta se on miinus, että emme voi tallentaa paljon, toisaalta tätä ei tarvitse tehdä. Sitä ei ole suunniteltu tähän tarkoitukseen, se ei ole tietokanta.
Tiedot voidaan tallentaa välimuistiin asiakaspuolella. Tämä on vakioperiaate, jotta emme keskeytä palvelua emmekä lataa sitä samoilla pyynnöillä. Älykäs asiakas yleensä tietää tämän ja tallentaa sen välimuistiin.
Esimerkiksi täällä on jotain muuttunut. On olemassa jonkinlainen sovellus. Valittiin uusi johtaja, joka vastaa esimerkiksi kirjoitustoimintojen käsittelystä. Ja haluamme kopioida tiedot. Yksi ratkaisu on laittaa se silmukkaan. Ja kyseenalaistamme jatkuvasti palveluamme - onko mikään muuttunut? Toinen vaihtoehto on optimaalinen. Tämä on kellomekanismi, jonka avulla voit ilmoittaa asiakkaille, että jokin on muuttunut. Tämä on resurssien kannalta halvempi menetelmä ja kätevämpi asiakkaille.
Asiakas on käyttäjä, joka käyttää ZooKeeperiä.
Palvelin on itse ZooKeeper-prosessi.
Znode on avainasia ZooKeeperissä. ZooKeeper tallentaa kaikki zsolmut muistiin ja on järjestetty hierarkkisen kaavion muodossa puun muodossa.
Toimintoja on kahdenlaisia. Ensimmäinen on päivitys/kirjoitus, kun jokin operaatio muuttaa puumme tilaa. Puu on yleinen.
Ja on mahdollista, että asiakas ei suorita yhtä pyyntöä ja yhteys katkeaa, mutta voi luoda istunnon, jonka kautta se on vuorovaikutuksessa ZooKeeperin kanssa.
ZooKeeperin tietomalli muistuttaa tiedostojärjestelmää. Siellä on vakiojuuri ja sitten menimme ikään kuin juuresta lähtevien hakemistojen läpi. Ja sitten luettelo ensimmäisen tason, toisen tason. Tämä on kaikki znodeja.
Jokainen znode voi tallentaa tietoja, yleensä ei kovin suuria, esimerkiksi 10 kilotavua. Ja jokaisella znodella voi olla tietty määrä lapsia.
Znodeja on useita tyyppejä. Ne voidaan luoda. Ja kun luot znodea, määritämme tyypin, johon sen pitäisi kuulua.
Niitä on kahta tyyppiä. Ensimmäinen on lyhytaikainen lippu. Znode elää istunnon sisällä. Esimerkiksi asiakas on perustanut istunnon. Ja niin kauan kuin tämä istunto on elossa, se on olemassa. Tämä on välttämätöntä, jotta ei tuottaisi mitään tarpeetonta. Tämä sopii myös hetkiin, jolloin meille on tärkeää tallentaa dataprimitiivit istunnon sisään.
Toinen tyyppi on peräkkäinen lippu. Se kasvattaa laskuria matkalla znodeen. Meillä oli esimerkiksi hakemisto sovelluksella 1_5. Ja kun loimme ensimmäisen solmun, se sai p_1, toisen - p_2. Ja kun kutsumme tätä menetelmää joka kerta, ohitamme koko polun, mikä osoittaa vain osan polusta, ja tämä numero kasvaa automaattisesti, koska ilmoitamme solmun tyypin - peräkkäinen.
Tavallinen znode. Hän elää aina ja hänellä on nimi, jonka kerromme hänelle.
Toinen hyödyllinen asia on kellolippu. Jos asennamme sen, asiakas voi tilata joitain tapahtumia tietylle solmulle. Näytän sinulle myöhemmin esimerkin avulla, kuinka tämä tehdään. ZooKeeper itse ilmoittaa asiakkaalle, että solmun tiedot ovat muuttuneet. Ilmoitukset eivät kuitenkaan takaa, että uusia tietoja on saapunut. He vain sanovat, että jokin on muuttunut, joten sinun on silti verrattava tietoja myöhemmin erillisillä puheluilla.
Ja kuten jo sanoin, tietojen järjestys määräytyy kilotavuissa. Sinne ei tarvitse tallentaa suurta tekstidataa, koska se ei ole tietokanta, se on toimintojen koordinointipalvelin.
Kerron teille vähän istunnoista. Jos meillä on useita palvelimia, voimme siirtyä avoimesti palvelimelta toiselle istuntotunnisteen avulla. Se on varsin kätevää.
Jokaisessa istunnossa on jonkinlainen aikakatkaisu. Istunto määritellään sen mukaan, lähettääkö asiakas mitään palvelimelle istunnon aikana. Jos hän ei lähettänyt mitään aikakatkaisun aikana, istunto katkeaa tai asiakas voi sulkea sen itse.
Siinä ei ole niin paljon ominaisuuksia, mutta voit tehdä erilaisia asioita tällä API:lla. Tämä puhelu, jonka näimme luovan, luo zsolmun ja ottaa kolme parametria. Tämä on polku znodeen, ja se on määritettävä kokonaan juuresta alkaen. Ja myös tämä on joitain tietoja, jotka haluamme siirtää sinne. Ja lipun tyyppi. Ja luomisen jälkeen se palauttaa polun znodeen.
Toiseksi voit poistaa sen. Temppu tässä on, että toinen parametri, znode-polun lisäksi, voi määrittää version. Vastaavasti tämä znode poistetaan, jos sen siirtämämme versio vastaa todellisuudessa olemassa olevaa versiota.
Jos emme halua tarkistaa tätä versiota, välitämme yksinkertaisesti argumentin "-1".
Kolmanneksi se tarkistaa znode:n olemassaolon. Palauttaa tosi, jos solmu on olemassa, false muussa tapauksessa.
Ja sitten lippukello tulee näkyviin, jonka avulla voit seurata tätä solmua.
Voit asettaa tämän lipun jopa olemattomalle solmulle ja saada ilmoituksen, kun se tulee näkyviin. Tästä voi myös olla hyötyä.
Pari haastetta lisää getData. On selvää, että voimme vastaanottaa tietoja znoden kautta. Voit myös käyttää lippukelloa. Tässä tapauksessa se ei asennu, jos solmua ei ole. Siksi sinun on ymmärrettävä, että se on olemassa, ja sitten vastaanotettava tiedot.
On myös SetData. Tässä välitetään versio. Ja jos välitämme tämän eteenpäin, tietyn version znode-tiedot päivitetään.
Voit myös määrittää "-1" sulkeaksesi tämän tarkistuksen pois.
Toinen hyödyllinen menetelmä on saada lapsia. Voimme myös saada luettelon kaikista siihen kuuluvista znodeista. Voimme valvoa tätä asettamalla lippukellon.
Ja menetelmä synkronoida mahdollistaa kaikkien muutosten lähettämisen kerralla, mikä varmistaa, että ne tallennetaan ja kaikki tiedot on muutettu kokonaan.
Jos vedämme analogioita tavallisen ohjelmoinnin kanssa, silloin kun käytät menetelmiä, kuten kirjoitus, jotka kirjoittavat jotain levylle ja sen jälkeen kun se palauttaa sinulle vastauksen, ei ole takeita siitä, että olet kirjoittanut tiedot levylle. Ja vaikka käyttöjärjestelmä on varma, että kaikki on kirjoitettu, itse levyllä on mekanismeja, joissa prosessi kulkee puskurikerrosten läpi, ja vasta sen jälkeen tiedot asetetaan levylle.
Useimmiten käytetään asynkronisia puheluita. Näin asiakas voi työskennellä rinnakkain erilaisten pyyntöjen kanssa. Voit käyttää synkronista lähestymistapaa, mutta se on vähemmän tuottava.
Kaksi toimintoa, joista puhuimme, ovat päivitys/kirjoitus, jotka muuttavat tietoja. Näitä ovat luo, setData, synkronointi, poista. Ja luku on olemassa, getData, getChildren.
Nyt muutama esimerkki siitä, kuinka voit tehdä primitiivisiä työskentelyä hajautetussa järjestelmässä. Esimerkiksi liittyen jonkin kokoonpanoon. Uusi työntekijä on ilmestynyt. Lisäsimme koneen ja aloitimme prosessin. Ja siinä on seuraavat kolme kysymystä. Kuinka se kysyy ZooKeeperiltä määrityksiä? Ja jos haluamme muuttaa kokoonpanoa, kuinka muutamme sitä? Ja kun muutimme sen, kuinka ne työntekijät, jotka meillä oli, saavat sen?
ZooKeeper tekee tästä suhteellisen helppoa. Esimerkiksi siellä on znode-puumme. Tässä on solmu sovelluksellemme, luomme siihen lisäsolmun, joka sisältää tiedot kokoonpanosta. Nämä voivat olla erillisiä parametreja tai eivät. Koska koko on pieni, myös konfiguraatiokoko on yleensä pieni, joten se on täysin mahdollista tallentaa tänne.
Käytät menetelmää getData saada työntekijän asetukset solmusta. Aseta todeksi. Jos tätä solmua ei jostain syystä ole olemassa, saamme siitä tiedon, kun se ilmestyy tai kun se muuttuu. Jos haluamme tietää, että jokin on muuttunut, asetamme sen todeksi. Ja jos tämän solmun tiedot muuttuvat, tiedämme siitä.
SetData. Asetamme tiedot, asetamme "-1", eli emme tarkista versiota, oletamme, että meillä on aina yksi konfiguraatio, meidän ei tarvitse tallentaa useita määrityksiä. Jos haluat tallentaa paljon, sinun on lisättävä toinen taso. Tässä uskomme, että niitä on vain yksi, joten päivitämme vain uusimman, joten emme tarkista versiota. Tällä hetkellä kaikki aiemmin tilaaneet asiakkaat saavat ilmoituksen, että jotain on muuttunut tässä solmussa. Ja saatuaan tiedot heidän on myös pyydettävä tiedot uudelleen. Ilmoitus on, että he eivät saa itse tietoja, vaan vain ilmoituksen muutoksista. Tämän jälkeen heidän on pyydettävä uusia tietoja.
Toinen vaihtoehto primitiivin käyttämiselle on ryhmän jäsenyys. Meillä on hajautettu sovellus, siellä on joukko työntekijöitä ja haluamme ymmärtää, että he ovat kaikki paikallaan. Siksi heidän on rekisteröitävä itsensä työskentelevänsä sovelluksessamme. Ja haluamme myös saada selville, joko Master-prosessista tai jostain muualta, kaikista aktiivisista työntekijöistämme, joita meillä tällä hetkellä on.
Miten tämä tehdään? Sovellusta varten luomme työntekijöiden solmun ja lisäämme siihen alitason luomismenetelmällä. Minulla on virhe diassa. Täällä tarvitset peräkkäinen määritä, niin kaikki työntekijät luodaan yksitellen. Ja sovellus, joka pyytää kaikkia tietoja tämän solmun lapsista, vastaanottaa kaikki olemassa olevat aktiiviset työntekijät.
Tämä on niin kauhea toteutus kuinka tämä voidaan tehdä Java-koodissa. Aloitetaan lopusta päämenetelmällä. Tämä on meidän luokkamme, luodaan sen menetelmä. Ensimmäisenä argumenttina käytämme hostia, johon olemme yhteydessä, eli asetamme sen argumentiksi. Ja toinen argumentti on ryhmän nimi.
Miten yhteys syntyy? Tämä on yksinkertainen esimerkki käytetystä API:sta. Täällä kaikki on suhteellisen yksinkertaista. Siellä on vakioluokan ZooKeeper. Annamme sille isännät. Ja aseta aikakatkaisu esimerkiksi 5 sekuntiin. Ja meillä on jäsen nimeltä connectSignal. Pohjimmiltaan luomme ryhmän lähetetyn polun varrelle. Emme kirjoita sinne dataa, vaikka jotain olisi voitu kirjoittaa. Ja solmu tässä on pysyvää tyyppiä. Pohjimmiltaan tämä on tavallinen tavallinen solmu, joka on olemassa koko ajan. Täällä istunto luodaan. Tämä on asiakkaan itsensä toteuttama toteutus. Asiakkaamme lähettää ajoittain viestejä, jotka osoittavat, että istunto on käynnissä. Ja kun lopetamme istunnon, soitamme kiinni ja siinä se, istunto kaatuu. Tämä tapahtuu siltä varalta, että jotain putoaa meille, jotta ZooKeeper saa tiedon ja katkaisee istunnon.
Kuinka lukita resurssi? Tässä kaikki on hieman monimutkaisempaa. Meillä on joukko työntekijöitä, on resursseja, jotka haluamme lukita. Tätä varten luomme erillisen solmun, esimerkiksi nimeltä lock1. Jos pystyimme luomaan sen, meillä on lukko täällä. Ja jos emme pystyneet luomaan sitä, niin työntekijä yrittää saada getData täältä, ja koska solmu on jo luotu, niin laitamme tarkkailijan tähän ja sillä hetkellä, kun tämän solmun tila muuttuu, tiedämme siitä. Ja voimme yrittää saada aikaa luoda se uudelleen. Jos otimme tämän solmun, otimme tämän lukon, sitten kun emme enää tarvitse lukkoa, hylkäämme sen, koska solmu on olemassa vain istunnon sisällä. Vastaavasti se katoaa. Ja toinen asiakas voi toisen istunnon puitteissa ottaa tämän solmun lukon, tai pikemminkin, hän saa ilmoituksen, että jokin on muuttunut ja hän voi yrittää tehdä sen ajoissa.
Toinen esimerkki siitä, kuinka voit valita pääjohtajan. Tämä on hieman monimutkaisempi, mutta myös suhteellisen yksinkertainen. Mitä täällä tapahtuu? Siellä on pääsolmu, joka yhdistää kaikki työntekijät. Yritämme saada tietoja johtajasta. Jos tämä tapahtui onnistuneesti, eli saimme joitain tietoja, niin työntekijämme alkaa seurata tätä johtajaa. Hän uskoo, että johtaja on jo olemassa.
Jos johtaja kuoli jostain syystä, esimerkiksi putosi, yritämme luoda uuden johtajan. Ja jos onnistumme, työntekijästämme tulee johtaja. Ja jos joku onnistui tällä hetkellä luomaan uuden johtajan, yritämme ymmärtää kuka hän on ja sitten seurata häntä.
Tässä syntyy ns. laumailmiö eli laumailmiö, koska kun johtaja kuolee, johtajaksi tulee ajoissa ensimmäinen.
Kun otat resurssia, voit yrittää käyttää hieman erilaista lähestymistapaa, joka on seuraava. Haluamme esimerkiksi saada lukon, mutta ilman hert-efektiä. Se koostuu siitä, että sovelluksemme pyytää luetteloita kaikista solmutunnuksista jo olemassa olevalle solmulle, jossa on lukko. Ja jos ennen sitä solmu, jolle loimme lukon, on pienin vastaanottamistamme joukosta, tämä tarkoittaa, että olemme ottaneet lukon. Tarkistamme, että olemme vastaanottaneet lukon. Tarkistuksena on ehto, että uuden lukon luomisen yhteydessä saamamme tunnus on minimaalinen. Ja jos saimme sen, työskentelemme edelleen.
Jos jokin tunnus on pienempi kuin lukkomme, laitamme tapahtumaan tarkkailijan ja odotamme ilmoitusta, kunnes jokin muuttuu. Eli saimme tämän lukon. Ja ennen kuin se putoaa, meistä ei tule vähimmäistunnusta emmekä saa vähimmäislukkoa, joten voimme kirjautua sisään. Ja jos tämä ehto ei täyty, menemme heti tänne ja yritämme saada tämän lukon uudelleen, koska jokin on saattanut muuttua tänä aikana.
Mistä ZooKeeper koostuu? On 4 pääasiaa. Tämä on käsittelyprosessit - Pyyntö. Ja myös ZooKeeper Atomic Broadcast. On Commit Log, johon kaikki toiminnot kirjataan. Ja itse muistissa oleva replikoitu DB, eli itse tietokanta, johon tämä koko puu on tallennettu.
On syytä huomata, että kaikki kirjoitustoiminnot kulkevat pyyntöprosessorin kautta. Ja lukutoiminnot menevät suoraan muistin sisäiseen tietokantaan.
Itse tietokanta on täysin replikoitu. Kaikki ZooKeeperin esiintymät tallentavat täydellisen kopion tiedoista.
Tietokannan palauttamiseksi kaatumisen jälkeen on olemassa Commit-loki. Vakiokäytäntö on, että ennen kuin tiedot pääsevät muistiin, ne kirjoitetaan sinne, jotta jos se kaatuu, tämä loki voidaan toistaa ja järjestelmän tila voidaan palauttaa. Ja säännöllisiä tilannekuvia tietokannasta käytetään myös.
ZooKeeper Atomic Broadcast on asia, jota käytetään replikoitujen tietojen ylläpitämiseen.
ZAB valitsee sisäisesti johtajan ZooKeeper-solmun näkökulmasta. Muut solmut tulevat hänen seuraajiksi ja odottavat häneltä joitain toimia. Jos he saavat merkintöjä, he välittävät ne kaikki johtajalle. Hän suorittaa ensin kirjoitustoiminnon ja lähettää sitten viestin siitä, mikä on muuttunut hänen seuraajilleen. Tämä on itse asiassa suoritettava atomisesti, eli koko jutun tallennus- ja lähetysoperaatio on suoritettava atomisesti, mikä takaa tietojen johdonmukaisuuden.
Se käsittelee vain kirjoituspyynnöt. Sen päätehtävänä on muuttaa toiminto tapahtumapäivitykseksi. Tämä on erityisesti luotu pyyntö.
Ja tässä on syytä huomata, että saman toiminnon päivitysten idempotenssi on taattu. Mikä se on? Tämä asia, jos se suoritetaan kahdesti, on samassa tilassa, eli itse pyyntö ei muutu. Ja tämä on tehtävä, jotta kaatumisen sattuessa voit käynnistää toiminnan uudelleen ja peruuttaa tällä hetkellä pudonneet muutokset. Tällöin järjestelmän tilasta tulee sama, eli ei pitäisi olla niin, että sarja samoja, esimerkiksi päivitysprosesseja, johtaisi järjestelmän erilaisiin lopputiloihin.
Lähde: will.com