Siūlau paskaityti paskaitos "Hadoop. ZooKeeper" stenogramą iš serijos "Metodai paskirstytiems didelių duomenų kiekių apdorojimui programoje Hadoop"
Kas yra ZooKeeper, jo vieta Hadoop ekosistemoje. Netiesa apie paskirstytą skaičiavimą. Standartinės paskirstytos sistemos diagrama. Sunkumai koordinuojant paskirstytas sistemas. Tipiškos koordinacijos problemos. „ZooKeeper“ dizaino principai. ZooKeeper duomenų modelis. znode vėliavėlės. Sesijos. Kliento API. Primityvai (konfigūracija, narystė grupėje, paprasti užraktai, lyderio rinkimai, užrakinimas be bandos efekto). ZooKeeper architektūra. ZooKeeper DB. ZAB. Užklausų tvarkytojas.
Šiandien kalbėsime apie „ZooKeeper“. Šis dalykas yra labai naudingas. Jis, kaip ir bet kuris „Apache Hadoop“ produktas, turi logotipą. Jame vaizduojamas vyras.
Prieš tai daugiausia kalbėjome apie tai, kaip ten galima apdoroti duomenis, kaip juos saugoti, tai yra, kaip juos kažkaip panaudoti ir kažkaip su jais dirbti. Ir šiandien norėčiau šiek tiek pakalbėti apie paskirstytų programų kūrimą. Ir „ZooKeeper“ yra vienas iš tų dalykų, leidžiančių supaprastinti šį reikalą. Tai savotiška paslauga, skirta tam tikram procesų sąveikos paskirstytose sistemose, paskirstytose programose koordinavimui.
Tokių programų poreikis kasdien didėja, todėl mūsų kursas yra apie tai. Viena vertus, „MapReduce“ ir ši paruošta sistema leidžia išlyginti šį sudėtingumą ir išlaisvinti programuotoją nuo rašymo primityvų, tokių kaip sąveika ir procesų koordinavimas. Tačiau, kita vertus, niekas negarantuoja, kad to vis tiek nereikės daryti. MapReduce ar kitos paruoštos sistemos ne visada visiškai pakeičia kai kuriuos atvejus, kurių negalima įgyvendinti naudojant šį. Įskaitant patį „MapReduce“ ir daugybę kitų „Apache“ projektų; iš tikrųjų jie taip pat yra platinamos programos. Kad būtų lengviau rašyti, jie parašė „ZooKeeper“.
Kaip ir visas su Hadoop susijusias programas, ją sukūrė Yahoo! Dabar tai taip pat yra oficiali „Apache“ programa. Jis nėra taip aktyviai vystomas kaip HBase. Jei einate į JIRA HBase, tai kiekvieną dieną yra krūva klaidų pranešimų, krūva pasiūlymų ką nors optimizuoti, t.y. gyvenimas projekte nuolat vyksta. O ZooKeeper, viena vertus, yra gana paprastas produktas, kita vertus, tai užtikrina jo patikimumą. Ir jį naudoti gana paprasta, todėl jis tapo Hadoop ekosistemos programų standartu. Taigi pagalvojau, kad būtų naudinga jį peržiūrėti, kad suprasčiau, kaip jis veikia ir kaip juo naudotis.
Tai nuotrauka iš mūsų paskaitos. Galima sakyti, kad jis yra statmenas viskam, ką iki šiol svarstėme. Ir viskas, kas čia nurodyta, vienaip ar kitaip veikia su ZooKeeper, t.y., tai paslauga, kuri naudoja visus šiuos produktus. Nei HDFS, nei „MapReduce“ nerašo savo panašių paslaugų, kurios tiktų jiems. Atitinkamai naudojamas ZooKeeper. Ir tai supaprastina kūrimą ir kai kuriuos dalykus, susijusius su klaidomis.
Iš kur visa tai? Atrodytų, lygiagrečiai skirtinguose kompiuteriuose paleidome dvi programas, sujungėme jas styga arba tinkleliu ir viskas veikia. Bet bėda ta, kad Tinklas yra nepatikimas, o jei užuostumėte srautą ar pažiūrėtumėte, kas ten vyksta žemu lygiu, kaip klientai sąveikauja tinkle, dažnai galite pamatyti, kad kai kurie paketai yra prarasti arba išsiųsti iš naujo. Ne veltui buvo išrasti TCP protokolai, leidžiantys nustatyti tam tikrą seansą ir garantuoti pranešimų pristatymą. Bet bet kuriuo atveju net TCP ne visada gali jus išgelbėti. Viskam yra skirtas laikas. Tinklas gali tiesiog trumpam nutrūkti. Jis gali tiesiog mirksėti. Ir visa tai lemia tai, kad negalite pasikliauti tinklo patikimumu. Tai yra pagrindinis skirtumas nuo lygiagrečių programų rašymo, kurios veikia viename kompiuteryje arba viename superkompiuteryje, kur nėra Tinklo, kur atmintyje yra patikimesnė duomenų mainų magistralė. Ir tai yra esminis skirtumas.
Be kita ko, naudojant tinklą, visada yra tam tikras delsimas. Diskas taip pat jį turi, bet tinkle jo daugiau. Vėlavimas yra tam tikras delsos laikas, kuris gali būti mažas arba gana reikšmingas.
Keičiasi tinklo topologija. Kas yra topologija - tai mūsų tinklo įrangos išdėstymas. Yra duomenų centrų, ten stovi stelažai, yra žvakių. Visa tai galima vėl prijungti, perkelti ir pan. Į visa tai taip pat reikia atsižvelgti. Keičiasi IP pavadinimai, keičiasi maršrutas, kuriuo keliauja mūsų srautas. Į tai taip pat reikia atsižvelgti.
Tinklas taip pat gali keistis įrangos atžvilgiu. Iš praktikos galiu pasakyti, kad mūsų tinklo inžinieriai labai mėgsta periodiškai ką nors atnaujinti ant žvakių. Staiga pasirodė nauja programinė įranga ir jie nebuvo ypač suinteresuoti kai kuriais Hadoop klasteriais. Jie turi savo darbą. Jiems svarbiausia, kad tinklas veiktų. Atitinkamai, jie nori ką nors ten iš naujo įkelti, atlikti aparatinės įrangos mirksėjimą, o aparatinė įranga taip pat periodiškai keičiasi. Į visa tai kažkaip reikia atsižvelgti. Visa tai turi įtakos mūsų paskirstytai programai.
Dažniausiai žmonės, kurie dėl kokių nors priežasčių pradeda dirbti su dideliais duomenų kiekiais, mano, kad internetas yra beribis. Jei ten yra kelių terabaitų failas, galite jį perkelti į savo serverį ar kompiuterį ir atidaryti naudodami kaip ir žiūrėti. Yra dar viena klaida Vim pažiūrėk į rąstus. Niekada to nedarykite, nes tai blogai. Nes Vim bando viską buferizuoti, įkelti į atmintį, ypač kai pradedame judėti per šį žurnalą ir kažko ieškoti. Tai dalykai, kurie yra pamiršti, bet verti dėmesio.
Paprasčiau parašyti vieną programą, kuri veikia viename kompiuteryje su vienu procesoriumi.
Kai mūsų sistema auga, norime visa tai lygiagretinti ir lygiagreti ne tik kompiuteryje, bet ir klasteryje. Kyla klausimas: kaip derinti šį reikalą? Mūsų programos gali net nesąveikauti viena su kita, tačiau keliuose serveriuose lygiagrečiai vykdėme kelis procesus. O kaip stebėti, kad jiems viskas klostytųsi gerai? Pavyzdžiui, jie ką nors siunčia internetu. Jie turi parašyti apie savo būseną kur nors, pavyzdžiui, kokioje nors duomenų bazėje ar žurnale, tada sukaupti šį žurnalą ir kažkur jį analizuoti. Be to, reikia atsižvelgti į tai, kad procesas veikė ir veikė, staiga jame atsirado kokia nors klaida arba jis sugedo, tada kaip greitai mes apie tai sužinosime?
Akivaizdu, kad visa tai galima greitai stebėti. Tai taip pat gerai, tačiau stebėjimas yra ribotas dalykas, leidžiantis kai kuriuos dalykus stebėti aukščiausiu lygiu.
Kai norime, kad mūsų procesai pradėtų sąveikauti vienas su kitu, pavyzdžiui, siųsti vienas kitam kokius nors duomenis, tada taip pat kyla klausimas – kaip tai atsitiks? Ar bus kokia nors lenktynių sąlyga, ar jie perrašys vienas kitą, ar teisingai atkeliaus duomenys, ar pakeliui kas nors bus prarasta? Reikia sukurti kažkokį protokolą ir pan.
Visų šių procesų koordinavimas nėra trivialus dalykas. Ir tai verčia kūrėją nusileisti į dar žemesnį lygį ir rašyti sistemas arba nuo nulio, arba ne visai nuo nulio, tačiau tai nėra taip paprasta.
Jei sugalvojote kriptografinį algoritmą ar net jį įgyvendinate, tai nedelsdami išmeskite, nes greičiausiai jis jums netiks. Greičiausiai jame bus daugybė klaidų, kurias pamiršote nurodyti. Niekada nenaudokite jo niekam rimtam, nes jis greičiausiai bus nestabilus. Nes visi egzistuojantys algoritmai buvo labai seniai išbandyti laiko. Jį trikdo bendruomenė. Tai atskira tema. Ir čia tas pats. Jei yra galimybė pačiam neįdiegti kažkokio procesų sinchronizavimo, tai geriau to nedaryti, nes tai gana sudėtinga ir veda į nestabilų nuolatinio klaidų paieškos kelią.
Šiandien mes kalbame apie ZooKeeper. Viena vertus, tai yra karkasas, kita vertus, tai paslauga, kuri palengvina kūrėjo gyvenimą ir kiek įmanoma supaprastina logikos įgyvendinimą bei mūsų procesų koordinavimą.
Prisiminkime, kaip gali atrodyti standartinė paskirstyta sistema. Apie tai ir kalbėjome – HDFS, HBase. Yra pagrindinis procesas, kuris valdo darbininkų ir vergų procesus. Jis atsakingas už užduočių koordinavimą ir paskirstymą, darbuotojų paleidimą iš naujo, naujų paleidimą ir krovinių paskirstymą.
Pažangesnis dalykas yra Koordinavimo tarnyba, tai yra perkelti pačią koordinavimo užduotį į atskirą procesą, plius lygiagrečiai paleisti kažkokį atsarginį arba budėjimo Master, nes gali nepavykti Master. Ir jei Meistras kris, tada mūsų sistema neveiks. Vykdome atsarginę kopiją. Kai kurios teigia, kad pagrindinį failą reikia kopijuoti į atsarginę kopiją. Tai taip pat galima patikėti Koordinavimo tarnybai. Tačiau šioje diagramoje už darbuotojų koordinavimą atsakingas pats Meistras, čia tarnyba koordinuoja duomenų replikacijos veiklą.
Pažangesnė parinktis yra tada, kai visą koordinavimą atlieka mūsų tarnyba, kaip paprastai. Jis prisiima atsakomybę, kad viskas veiktų. Ir jei kažkas neveikia, mes apie tai išsiaiškiname ir bandome apeiti šią situaciją. Bet kokiu atveju mums lieka Šeimininkas, kuris kažkaip bendrauja su vergais ir per kokią nors paslaugą gali siųsti duomenis, informaciją, žinutes ir pan.
Yra dar pažangesnė schema, kai neturime Master, visi mazgai yra pagrindiniai vergai, skirtingi savo elgesiu. Tačiau jiems vis tiek reikia bendrauti vieniems su kitais, todėl dar liko tam tikra tarnyba šiems veiksmams koordinuoti. Tikriausiai Cassandra, kuri veikia šiuo principu, tinka šiai schemai.
Sunku pasakyti, kuri iš šių schemų veikia geriau. Kiekvienas turi savų pliusų ir minusų.
Ir nereikia bijoti kai kurių dalykų su Mokytoju, nes, kaip rodo praktika, jis nėra toks imlus nuolatiniam tarnavimui. Čia svarbiausia pasirinkti tinkamą šios paslaugos prieglobos sprendimą atskirame galingame mazge, kad jis turėtų pakankamai išteklių, kad, jei įmanoma, vartotojai neturėtų ten prieigos, kad jie netyčia neužmuštų šio proceso. Tačiau tuo pačiu metu tokioje schemoje daug lengviau valdyti darbuotojus iš pagrindinio proceso, t.y. ši schema yra paprastesnė įgyvendinimo požiūriu.
Ir ši schema (aukščiau) tikriausiai yra sudėtingesnė, bet patikimesnė.
Pagrindinė problema – daliniai gedimai. Pavyzdžiui, kai mes siunčiame žinutę per tinklą, įvyksta kažkoks nelaimingas atsitikimas, ir tas, kuris siuntė pranešimą, nežinos, ar jo pranešimas buvo gautas ir kas atsitiko gavėjo pusėje, nežinos, ar pranešimas buvo tinkamai apdorotas. , t.y. jis negaus jokio patvirtinimo.
Atitinkamai mes turime apdoroti šią situaciją. O paprasčiausia – išsiųsti šią žinutę dar kartą ir palaukti, kol gausime atsakymą. Šiuo atveju neatsižvelgiama į tai, ar pasikeitė imtuvo būsena. Galime išsiųsti žinutę ir pridėti tuos pačius duomenis du kartus.
„ZooKeeper“ siūlo būdus, kaip susidoroti su tokiais atsisakymais, o tai taip pat palengvina mūsų gyvenimą.
Kaip minėta šiek tiek anksčiau, tai panašu į kelių gijų programų rašymą, tačiau pagrindinis skirtumas yra tas, kad paskirstytose programose, kurias kuriame skirtingose mašinose, vienintelis būdas bendrauti yra tinklas. Iš esmės tai yra bendra-nieko architektūra. Kiekvienas procesas ar paslauga, kuri veikia viename kompiuteryje, turi savo atmintį, diską, savo procesorių, kurio su niekuo nesidalina.
Jei viename kompiuteryje rašome kelių gijų programą, tuomet duomenų mainams galime naudoti bendrą atmintį. Ten turime konteksto jungiklį, procesai gali persijungti. Tai turi įtakos našumui. Viena vertus, klasterio programoje tokio dalyko nėra, tačiau yra problemų su tinklu.
Atitinkamai, pagrindinės problemos, kylančios rašant paskirstytas sistemas, yra konfigūracija. Rašome kažkokią paraišką. Jei tai paprasta, tada kode užkoduojame visokius skaičius, bet tai nepatogu, nes jei nusprendžiame, kad vietoj pusės sekundės skirtojo laiko norime vienos sekundės skirtojo laiko, reikia iš naujo sukompiliuoti programą ir vėl viską išvynioti. Vienas dalykas, kai jis yra viename įrenginyje, kai galite jį tiesiog paleisti iš naujo, bet kai turime daug mašinų, turime nuolat viską kopijuoti. Turime pabandyti, kad programa būtų konfigūruojama.
Čia kalbame apie statinę sistemos procesų konfigūraciją. Tai nėra visiškai, galbūt operacinės sistemos požiūriu, tai gali būti statinė mūsų procesų konfigūracija, t. y. tai yra konfigūracija, kurios negalima tiesiog paimti ir atnaujinti.
Taip pat yra dinaminė konfigūracija. Tai yra parametrai, kuriuos norime pakeisti skrydžio metu, kad jie ten būtų paimti.
kame cia problema? Atnaujinome konfigūraciją, išleidome, o kas? Problema gali būti ta, kad viena vertus, mes išleidome konfigūraciją, bet pamiršome apie naują dalyką, konfigūracija liko ten. Antra, kol diegėme, kai kuriose vietose konfigūracija buvo atnaujinta, o kitur – ne. Ir kai kurie mūsų programos procesai, kurie veikia viename kompiuteryje, buvo paleisti iš naujo naudojant naują konfigūraciją, o kažkur - su sena. Dėl to mūsų paskirstyta programa gali būti nenuosekli konfigūracijos požiūriu. Ši problema yra dažna. Dinaminei konfigūracijai tai labiau aktualu, nes reiškia, kad ją galima pakeisti iš karto.
Kita problema – narystė grupėje. Visada turime kažkokį darbininkų rinkinį, visada norime žinoti, kuris iš jų gyvas, kuris miręs. Jei yra Meistras, tai jis turi suprasti, kuriuos darbuotojus galima nukreipti pas klientus, kad jie atliktų skaičiavimus ar dirbtų su duomenimis, o kuriuos ne. Nuolat iškylanti problema yra ta, kad turime žinoti, kas dirba mūsų klasteryje.
Kita tipiška problema – lyderių rinkimai, kai norime žinoti, kas vadovauja. Vienas iš pavyzdžių yra replikacija, kai turime tam tikrą procesą, kuris gauna rašymo operacijas ir atkartoja jas su kitais procesais. Jis bus lyderis, visi kiti jam paklus, seks paskui jį. Reikia parinkti tokį procesą, kad jis būtų visiems vienareikšmiškas, kad neišeitų, kad parenkami du lyderiai.
Taip pat yra abipusiai išskirtinė prieiga. Čia problema sudėtingesnė. Yra toks dalykas kaip mutex, kai rašote kelių gijų programas ir norite, kad prieiga prie kokio nors resurso, pavyzdžiui, atminties ląstelės, būtų apribota ir vykdoma tik vienos gijos. Čia išteklius galėtų būti abstraktesnis. Ir skirtingos programos iš skirtingų mūsų tinklo mazgų turėtų gauti tik išskirtinę prieigą prie tam tikro šaltinio, o ne tam, kad kiekvienas galėtų jį pakeisti ar ką nors ten parašyti. Tai vadinamosios spynos.
„ZooKeeper“ leidžia vienaip ar kitaip išspręsti visas šias problemas. Ir aš parodysiu pavyzdžiais, kaip tai leidžia jums tai padaryti.
Nėra blokuojančių primityvų. Kai pradedame ką nors naudoti, šis primityvus nelauks, kol įvyks koks nors įvykis. Labiausiai tikėtina, kad šis dalykas veiks asinchroniškai, todėl procesai netruks, kol jie kažko laukia. Tai labai naudingas dalykas.
Visos klientų užklausos apdorojamos bendrosios eilės tvarka.
O klientai turi galimybę gauti pranešimą apie kokios nors būklės pasikeitimus, apie duomenų pasikeitimus, kol klientas pats nepamatys pasikeitusių duomenų.
„ZooKeeper“ gali dirbti dviem režimais. Pirmasis yra atskiras, viename mazge. Tai patogu atliekant bandymus. Jis taip pat gali veikti klasterio režimu bet kuriame serverių skaičiuje. Jei turime 100 mašinų klasterį, tai nebūtina, kad jis veiktų 100 mašinų. Pakanka pasirinkti keletą mašinų, kuriose galėsite paleisti ZooKeeper. Ir jis išpažįsta didelio prieinamumo principą. Kiekviename veikiančiame egzemplioriuje „ZooKeeper“ saugo visą duomenų kopiją. Vėliau papasakosiu, kaip jis tai daro. Jis neskaldo duomenų ir neskirsto jų. Viena vertus, tai yra minusas, kad negalime daug saugoti, kita vertus, to daryti nereikia. Tai ne tam skirta, tai ne duomenų bazė.
Duomenys gali būti talpinami kliento pusėje. Tai yra standartinis principas, kad nenutrauktume paslaugos ir neapkrautume tomis pačiomis užklausomis. Protingas klientas paprastai apie tai žino ir saugo tai talpykloje.
Pavyzdžiui, čia kažkas pasikeitė. Yra tam tikra programa. Buvo išrinktas naujas vadovas, atsakingas, pavyzdžiui, už rašymo operacijų apdorojimą. Ir mes norime atkartoti duomenis. Vienas iš sprendimų yra įdėti jį į kilpą. Ir mes nuolat abejojame savo paslauga – ar kas nors pasikeitė? Antrasis variantas yra optimalesnis. Tai laikrodžio mechanizmas, leidžiantis pranešti klientams, kad kažkas pasikeitė. Tai pigesnis būdas išteklių atžvilgiu ir patogesnis klientams.
Klientas yra vartotojas, kuris naudojasi ZooKeeper.
Serveris yra pats „ZooKeeper“ procesas.
„Znode“ yra pagrindinis „ZooKeeper“ dalykas. Visi zmazgai yra saugomi ZooKeeper atmintyje ir yra suskirstyti į hierarchinę diagramą medžio pavidalu.
Yra dviejų tipų operacijos. Pirmasis yra atnaujinimas/rašymas, kai kuri nors operacija pakeičia mūsų medžio būseną. Medis yra dažnas.
Ir gali būti, kad klientas neįvykdo vienos užklausos ir yra atjungtas, bet gali sukurti seansą, per kurį sąveikauja su ZooKeeper.
„ZooKeeper“ duomenų modelis primena failų sistemą. Yra standartinis šaknis, o tada mes ėjome tarsi per katalogus, kurie eina iš šaknies. Ir tada pirmojo lygio, antrojo lygio katalogas. Tai visi znodai.
Kiekvienas zmazgas gali saugoti tam tikrus duomenis, dažniausiai ne itin didelius, pavyzdžiui, 10 kilobaitų. Ir kiekvienas znode gali turėti tam tikrą skaičių vaikų.
Znodai būna kelių tipų. Juos galima sukurti. O kurdami znode nurodome tipą, kuriam jis turėtų priklausyti.
Yra du tipai. Pirmoji yra trumpalaikė vėliava. Znode gyvena seanso metu. Pavyzdžiui, klientas nustatė seansą. Ir kol ši sesija gyva, ji egzistuos. Tai būtina, kad nebūtų pagaminti ko nors nereikalingo. Tai taip pat tinka tais momentais, kai mums svarbu seanso metu saugoti duomenų primityvus.
Antrasis tipas yra nuosekli vėliava. Tai padidina skaitiklį kelyje į znode. Pavyzdžiui, mes turėjome katalogą su programa 1_5. Ir kai sukūrėme pirmąjį mazgą, jis gavo p_1, antrasis - p_2. Ir kiekvieną kartą iškviečiant šį metodą, praeiname visą kelią, nurodant tik dalį kelio, ir šis skaičius automatiškai didėja, nes nurodome mazgo tipą – nuoseklų.
Įprastas znode. Ji visada gyvens ir turės vardą, kurį jai sakome.
Kitas naudingas dalykas – laikrodžio vėliavėlė. Jei jį įdiegsime, klientas gali užsiprenumeruoti kai kuriuos konkretaus mazgo įvykius. Vėliau pateiksiu pavyzdį, kaip tai daroma. Pats „ZooKeeper“ praneša klientui, kad mazgo duomenys pasikeitė. Tačiau pranešimai negarantuoja, kad bus gauti nauji duomenys. Jie tiesiog sako, kad kažkas pasikeitė, todėl jūs vis tiek turite palyginti duomenis vėliau su atskirais skambučiais.
Ir kaip jau sakiau, duomenų eiliškumą lemia kilobaitai. Ten nereikia kaupti didelių tekstinių duomenų, nes tai ne duomenų bazė, tai veiksmų koordinavimo serveris.
Truputį papasakosiu apie užsiėmimus. Jei turime kelis serverius, galime skaidriai pereiti iš serverio į serverį naudodami seanso identifikatorių. Tai gana patogu.
Kiekviena sesija turi tam tikrą skirtąjį laiką. Sesija apibrėžiama pagal tai, ar klientas tos sesijos metu ką nors siunčia serveriui. Jei per skirtąjį laiką jis nieko neperdavė, seansas nutrūksta arba klientas gali jį uždaryti pats.
Jame nėra tiek daug funkcijų, bet su šia API galite atlikti įvairius veiksmus. Tas skambutis, kurį matėme sukuriant, sukuria znode ir užima tris parametrus. Tai yra kelias į znode, ir jis turi būti nurodytas visas nuo šaknies. Taip pat tai yra keletas duomenų, kuriuos norime ten perkelti. Ir vėliavos tipas. Ir po sukūrimo jis grąžina kelią į znode.
Antra, galite jį ištrinti. Apgaulė yra ta, kad antrasis parametras, be kelio į znode, gali nurodyti versiją. Atitinkamai, tas zmazgas bus ištrintas, jei jo versija, kurią mes perdavėme, yra lygiavertė iš tikrųjų egzistuojančiai.
Jei nenorime tikrinti šios versijos, tiesiog perduodame argumentą „-1“.
Trečia, ji patikrina, ar nėra znode. Grąžina „true“, jei mazgas egzistuoja, „false“, kitaip.
Tada pasirodo vėliavėlės laikrodis, leidžiantis stebėti šį mazgą.
Galite nustatyti šią vėliavėlę net neegzistuojančiame mazge ir gauti pranešimą, kai ji pasirodys. Tai taip pat gali būti naudinga.
Yra dar pora iššūkių gautiData. Aišku, kad duomenis galime gauti per znode. Taip pat galite naudoti vėliavos laikrodį. Tokiu atveju jis nebus įdiegtas, jei nėra mazgo. Todėl jūs turite suprasti, kad jis egzistuoja, ir tada gauti duomenis.
Taip pat yra Nustatyti duomenis. Pateikiame versiją. Ir jei mes tai perduosime, tam tikros versijos znode duomenys bus atnaujinti.
Taip pat galite nurodyti „-1“, kad neįtrauktumėte šio patikrinimo.
Kitas naudingas metodas yra gauti Vaikai. Taip pat galime gauti visų jam priklausančių zmazgų sąrašą. Tai galime stebėti nustatydami vėliavos laikrodį.
Ir metodas sync leidžia siųsti visus pakeitimus iš karto, taip užtikrinant, kad jie būtų išsaugoti ir visi duomenys būtų visiškai pakeisti.
Jei brėžtume analogijas su įprastu programavimu, tai kai naudojate tokius metodus kaip rašymas, kurie įrašo kažką į diską, o po to grąžina jums atsakymą, nėra garantijos, kad įrašėte duomenis į diską. Ir net tada, kai operacinė sistema yra įsitikinusi, kad viskas buvo parašyta, pačiame diske yra mechanizmai, kuriuose procesas vyksta per buferių sluoksnius ir tik po to duomenys dedami į diską.
Dažniausiai naudojami asinchroniniai skambučiai. Tai leidžia klientui dirbti lygiagrečiai su skirtingais prašymais. Galite naudoti sinchroninį metodą, tačiau jis yra mažiau produktyvus.
Dvi operacijos, apie kurias kalbėjome, yra atnaujinimas / rašymas, kurios keičia duomenis. Tai yra kurti, setData, sinchronizuoti, ištrinti. Ir skaityti yra, getData, getChildren.
Dabar keli pavyzdžiai, kaip galite sukurti primityvus darbui paskirstytoje sistemoje. Pavyzdžiui, susiję su kažko konfigūracija. Atsirado naujas darbuotojas. Pridėjome mašiną ir pradėjome procesą. Ir yra šie trys klausimai. Kaip ji pateikia užklausą „ZooKeeper“ konfigūruoti? Ir jei norime pakeisti konfigūraciją, kaip ją pakeisti? O po to, kai jį pakeitėme, kaip tai gauna tie darbuotojai, kuriuos turėjome?
„ZooKeeper“ tai gana paprasta. Pavyzdžiui, yra mūsų znode medis. Čia yra mūsų programos mazgas, jame sukuriame papildomą mazgą, kuriame yra duomenys iš konfigūracijos. Tai gali būti arba nebūti atskiri parametrai. Kadangi dydis yra mažas, konfigūracijos dydis paprastai taip pat yra mažas, todėl čia visiškai įmanoma jį laikyti.
Jūs naudojate metodą gautiData gauti darbuotojo konfigūraciją iš mazgo. Nustatykite tiesą. Jei dėl kokių nors priežasčių šis mazgas neegzistuoja, mes apie jį informuosime, kai jis pasirodys arba pasikeis. Jei norime žinoti, kad kažkas pasikeitė, tai nustatome kaip tiesa. Ir jei pasikeis duomenys šiame mazge, mes apie tai sužinosime.
Nustatyti duomenis. Nustatome duomenis, nustatome „-1“, t.y. netikriname versijos, darome prielaidą, kad visada turime vieną konfigūraciją, nereikia saugoti daug konfigūracijų. Jei jums reikia daug saugoti, turėsite pridėti dar vieną lygį. Čia manome, kad yra tik vienas, todėl atnaujiname tik naujausią, todėl netikriname versijos. Šiuo metu visi klientai, kurie anksčiau užsiprenumeravo, gauna pranešimą, kad kažkas pasikeitė šiame mazge. O gavę duomenis, jie taip pat turi prašyti duomenų dar kartą. Pranešimas yra tai, kad jie negauna pačių duomenų, o tik pranešimus apie pasikeitimus. Po to jie turi paprašyti naujų duomenų.
Antrasis primityvaus naudojimo variantas yra grupės narystė. Turime paskirstytą programą, yra krūva darbuotojų ir norime suprasti, kad jie visi yra vietoje. Todėl jie turi užsiregistruoti, kad dirba mūsų programoje. Taip pat mes norime sužinoti, ar iš Master proceso, ar kur nors kitur, apie visus šiuo metu turimus aktyvius darbuotojus.
Kaip tai darome? Programai sukuriame darbuotojų mazgą ir ten pridedame polygį naudodami kūrimo metodą. Turiu klaidą skaidrėje. Čia tau reikia nuoseklus nurodykite, tada visi darbuotojai bus sukurti po vieną. Ir programa, prašydama visų duomenų apie šio mazgo vaikus, gauna visus esamus aktyvius darbuotojus.
Tai toks baisus įgyvendinimas, kaip tai galima padaryti „Java“ kode. Pradėkime nuo pabaigos, nuo pagrindinio metodo. Tai mūsų klasė, sukurkime jos metodą. Kaip pirmąjį argumentą naudojame host, kur jungiamės, t.y. nustatome jį kaip argumentą. O antras argumentas – grupės pavadinimas.
Kaip atsiranda ryšys? Tai paprastas naudojamos API pavyzdys. Čia viskas palyginti paprasta. Yra standartinės klasės ZooKeeper. Perduodame jai šeimininkus. Ir nustatykite skirtąjį laiką, pavyzdžiui, 5 sekundes. Ir mes turime narį, vadinamą connectSignal. Iš esmės mes sukuriame grupę perduodamu keliu. Duomenų ten nerašome, nors kažkas galėjo būti parašyta. Ir mazgas čia yra nuolatinio tipo. Iš esmės tai yra įprastas įprastas mazgas, kuris egzistuos visą laiką. Čia sukuriama sesija. Tai yra paties kliento įgyvendinimas. Mūsų klientas periodiškai siųs pranešimus, nurodančius, kad sesija yra gyva. O kai baigiame seansą, skambiname uždaryti ir viskas, seansas iškrenta. Tai daroma tuo atveju, jei mums kas nors nukristų, kad ZooKeeper apie tai sužinotų ir nutrauktų seansą.
Kaip užrakinti išteklius? Čia viskas yra šiek tiek sudėtingiau. Turime darbuotojų rinkinį, yra tam tikras šaltinis, kurį norime užrakinti. Norėdami tai padaryti, sukuriame atskirą mazgą, pavyzdžiui, vadinamą lock1. Jeigu mums pavyko tai sukurti, vadinasi, čia gavome spyną. O jei mums nepavyko jo sukurti, tai darbuotojas bando gauti getData iš čia, o kadangi mazgas jau sukurtas, tai čia įdedame stebėtoją ir tą akimirką, kai pasikeis šio mazgo būsena, mes apie tai sužinosime. Ir mes galime pabandyti turėti laiko jį atkurti. Jei paėmėme šį mazgą, paėmėme šį užraktą, tada po to, kai mums nebereikės užrakto, mes jo atsisakysime, nes mazgas egzistuoja tik seanso metu. Atitinkamai, jis išnyks. O kitas klientas kitos sesijos metu galės paimti šio mazgo užraktą, tiksliau, gaus pranešimą, kad kažkas pasikeitė ir galės pabandyti tai padaryti laiku.
Dar vienas pavyzdys, kaip galima pasirinkti pagrindinį lyderį. Tai yra šiek tiek sudėtingesnė, bet ir gana paprasta. Kas čia vyksta? Yra pagrindinis mazgas, kuris sujungia visus darbuotojus. Bandome gauti duomenis apie lyderį. Jei tai įvyko sėkmingai, t. y. gavome tam tikrus duomenis, tada mūsų darbuotojas pradeda sekti šį lyderį. Jis mano, kad lyderis jau yra.
Jei vadovas dėl kokių nors priežasčių mirė, pavyzdžiui, nukrito, tada bandome sukurti naują vadovą. Ir jei mums pavyksta, mūsų darbuotojas tampa lyderiu. Ir jei kas nors šiuo metu sugebėjo sukurti naują lyderį, mes stengiamės suprasti, kas tai yra, ir tada sekti jį.
Čia atsiranda vadinamasis bandos efektas, t.y., kai lyderis miršta, lyderiu tampa tas, kuris yra pirmas laiku.
Užfiksuodami išteklius galite pabandyti naudoti šiek tiek kitokį metodą, kuris yra toks. Pavyzdžiui, norime gauti užraktą, bet be herto efekto. Tai sudarys tai, kad mūsų programa prašo visų jau esamo mazgo su užraktu mazgo ID sąrašų. Ir jei prieš tai mazgas, kuriam sukūrėme užraktą, yra mažiausias iš gautų rinkinių, tai reiškia, kad užfiksavome užraktą. Patikriname, ar gavome užraktą. Kaip patikrinimą, bus sąlyga, kad ID, kurį gavome kurdami naują užraktą, yra minimalus. O jei gavome, tai dirbame toliau.
Jei yra tam tikras ID, kuris yra mažesnis už mūsų užraktą, mes įdedame stebėtoją prie šio įvykio ir laukiame pranešimo, kol kažkas pasikeis. Tai yra, mes gavome šią spyną. Ir kol jis nenukris, mes netapsime minimaliu id ir negausime minimalaus užrakto ir taip galėsime prisijungti. O jei ši sąlyga netenkinama, tai iš karto einame čia ir bandome dar kartą gauti šią spyną, nes per tą laiką galėjo kažkas pasikeisti.
Iš ko susideda ZooKeeper? Yra 4 pagrindiniai dalykai. Tai apdorojimo procesai – Užklausa. Taip pat „ZooKeeper Atomic Broadcast“. Yra Įsipareigojimų žurnalas, kuriame įrašomos visos operacijos. Ir pati In-memory Replicated DB, ty pati duomenų bazė, kurioje saugomas visas šis medis.
Verta paminėti, kad visos rašymo operacijos atliekamos per užklausų procesorių. O skaitymo operacijos patenka tiesiai į atminties duomenų bazę.
Pati duomenų bazė yra visiškai atkartota. Visi ZooKeeper egzemplioriai saugo visą duomenų kopiją.
Norint atkurti duomenų bazę po gedimo, yra Įsipareigojimo žurnalas. Standartinė praktika yra tokia, kad prieš duomenims patenkant į atmintį, jie ten įrašomi, kad sugedus būtų galima atkurti šį žurnalą ir atkurti sistemos būseną. Taip pat naudojamos periodinės duomenų bazės momentinės nuotraukos.
„ZooKeeper Atomic Broadcast“ yra dalykas, naudojamas pakartotiniams duomenims palaikyti.
ZAB viduje parenka lyderį ZooKeeper mazgo požiūriu. Kiti mazgai tampa jos sekėjais ir tikisi iš jos tam tikrų veiksmų. Jei jie gauna įrašus, jie juos visus persiunčia vadovui. Pirmiausia jis atlieka rašymo operaciją, o paskui siunčia pranešimą apie tai, kas pasikeitė jo sekėjams. Tiesą sakant, tai turi būti atliekama atomiškai, ty viso dalyko įrašymo ir transliavimo operacija turi būti atliekama atomiškai, taip garantuojant duomenų nuoseklumą.
Jis apdoroja tik rašymo užklausas. Pagrindinė jo užduotis yra paversti operaciją operacijos atnaujinimu. Tai yra specialiai sukurta užklausa.
Ir čia verta paminėti, kad tos pačios operacijos atnaujinimų idempotencija yra garantuota. Kas tai yra? Šis dalykas, jei jis bus įvykdytas du kartus, bus tos pačios būsenos, t. y. pati užklausa nepasikeis. Ir tai reikia padaryti, kad įvykus avarijai galėtumėte iš naujo paleisti operaciją, taip atšaukdami šiuo metu nukritusius pakeitimus. Tokiu atveju sistemos būsena taps vienoda, t. y. neturėtų būti taip, kad tų pačių, pavyzdžiui, atnaujinimo procesų serija sukeltų skirtingas galutines sistemos būsenas.
Šaltinis: www.habr.com