Zookeeper yra Hadoop subprojektas, ir nors jis yra kilęs iš hadoop, aš pastebėjau, kad zookeeper vis dažniau naudoja paskirstytas sistemas už hadoop ribų. Šiandien noriu pakalbėti apie zookeeper, šiame straipsnyje nebus kalbama apie tai, kaip naudotis zookeeper, bet kokie yra praktiniai zookeeper pritaikymai, kokios programos gali turėti zookeeper pranašumus ir galiausiai kalbėti apie tai, kokį vaidmenį zookeeper gali atlikti paskirstytoje svetainės architektūroje.
Zookeeper yra labai patikima koordinavimo sistema didelėms paskirstytoms sistemoms. Iš šio apibrėžimo žinome, kad zoologijos sodo prižiūrėtojas yra koordinuota sistema, veikianti paskirstytas sistemas. Kodėl paskirstytoms sistemoms reikalinga koordinavimo sistema? Priežastys yra šios:
Sukurti paskirstytą sistemą yra labai sunkus dalykas, o sunkumai daugiausia atsispindi paskirstytos sistemos "daliniame gedime". "Dalinis gedimas" reiškia informacijos perdavimą tarp dviejų tinklo mazgų, jei tinklas sugenda, siuntėjas negali žinoti, ar gavėjas gavo pranešimą, o šio gedimo priežastis yra sudėtinga, imtuvas gali būti gavęs pranešimą prieš tinklo klaidą arba gavėjo procesas neveikia. Vienintelis būdas siuntėjui gauti tikrąjį vaizdą yra vėl prisijungti prie imtuvo ir paklausti imtuvo, kodėl įvyko klaida, o tai yra "dalinio gedimo" problema kuriant paskirstytą sistemą.
"Zookeeper" yra paskirstytų sistemų "dalinio gedimo" sprendimo sistema. "Zookeeper" neleidžia paskirstytoms sistemoms išvengti "dalinio gedimo" problemų, tačiau leidžia paskirstytoms sistemoms tinkamai spręsti tokias problemas, kai susiduriama su daliniais gedimais, kad paskirstytos sistemos galėtų normaliai veikti.
Pakalbėkime apie praktinį zoologijos sodo prižiūrėtojo naudojimą:
1 scenarijus: Yra serverių grupė, teikianti tam tikrą paslaugą klientui (pavyzdžiui, anksčiau sukurtos paskirstytos svetainės serverio pusė yra klasteris, sudarytas iš keturių serverių, teikiančių paslaugas priekiniam klasteriui), ir tikimės, kad klientas gali rasti serverį serverių klasteryje kiekvieną kartą, kai klientas to paprašo, kad serveris galėtų suteikti klientui klientui reikalingas paslaugas. Šiam scenarijui savo programoje turime turėti serverių sąrašą, iš kurio kiekvieną kartą, kai klientas to prašo, skaitome serverių sąrašą. Tada šis posąrašis akivaizdžiai negali būti saugomas viename mazgo serveryje, kitaip mazgas pakibs ir visas klasteris suges, ir tikimės, kad šis sąrašas tuo metu bus labai prieinamas. Jei saugyklos sąraše esantis serveris yra sugedęs, kiti serveriai gali nedelsdami pakeisti sugedusį serverį, o sugedusį serverį galima pašalinti iš sąrašo, kad sugedęs serveris galėtų pasitraukti iš viso klasterio veikimo, o visas šias operacijas vykdys ne sugedęs serveris, o įprastas klasterio serveris. Tai aktyvi paskirstyta duomenų struktūra, kuri gali aktyviai keisti duomenų elementų būseną, kai keičiasi išorinės sąlygos. Šią paslaugą teikia "Zookeeper" sistema. Šios paslaugos pavadinimas yra: Unified Naming Service, kuris yra labai panašus į JNDI paslaugą javaEE.
2 scenarijus: paskirstyta užrakto paslauga. Kai paskirstyta sistema manipuliuoja duomenimis, pvz., skaito duomenis, analizuoja duomenis ir galiausiai keičia duomenis. Paskirstytoje sistemoje šios operacijos gali būti išsklaidytos į skirtingus klasterio mazgus, tada kyla duomenų veikimo proceso nuoseklumo problema, jei jis yra nenuoseklus, gausime neteisingą operacijos rezultatą, vienoje proceso programoje nuoseklumo problemą lengva išspręsti, tačiau sunkiau pasiekti paskirstytą sistemą, nes skirtingų serverių operacijos paskirstytoje sistemoje vyksta nepriklausomuose procesuose, o tarpiniai operacijos rezultatai ir procesai turi būti perduodami per tinklą. Tada daug sunkiau pasiekti duomenų operacijų nuoseklumą. "Zookeeper" teikia užrakto paslaugą, kuri išsprendžia šią problemą, leidžiančią užtikrinti duomenų operacijų nuoseklumą atliekant paskirstytų duomenų operacijas.
3 scenarijus: konfigūracijos valdymas. Paskirstytoje sistemoje paslaugų programą įdiegsime n serveriuose atskirai, o šių serverių konfigūracijos failai yra vienodi (pavyzdžiui, mano sukurtoje paskirstytos svetainės sistemoje serverio pusėje yra 4 serveriai, 4 serverių programos yra vienodos, o konfigūracijos failai yra vienodi), jei pasikeičia konfigūracijos failų konfigūracijos parinktys, turime pakeisti šiuos konfigūracijos failus po vieną, jei reikia pakeisti serverius yra palyginti maži, šios operacijos nėra per daug varginančios, Jei turime daug paskirstytų serverių, pavyzdžiui, didelės interneto bendrovės "Hadoop" klasterį su tūkstančiais serverių, konfigūracijos parinkčių keitimas gali būti varginantis ir pavojingas dalykas. Šiuo metu zookeeper gali būti naudingas, galime naudoti zookeeper kaip labai prieinamą konfigūracijos atmintį, perduoti tokį dalyką zookeeper valdyti, nukopijuojame klasterio konfigūracijos failą į zookeeper failų sistemos mazgą, o tada naudojame zookeeper, kad stebėtume konfigūracijos failo būseną visose paskirstytose sistemose, kai nustatoma, kad konfigūracijos failas pasikeitė, Kiekvienas serveris gaus pranešimą iš "Zookeeper" sinchronizuoti konfigūracijos failus "Zookeeper", o "Zookeeper" paslauga taip pat užtikrins, kad sinchronizavimo operacija būtų atominė, kad kiekvieno serverio konfigūracijos failas būtų tinkamai atnaujintas.
4 scenarijus: pateikite paskirstytų sistemų gedimų taisymo funkcijas. Klasterio valdymas yra sudėtingas, o pridėjus zoologijos sodo prižiūrėtojo paslaugą prie paskirstytos sistemos, mums lengva valdyti klasterį. Labiausiai varginantis dalykas klasterio valdyme yra mazgo gedimų valdymas, zookeeper gali leisti klasteriui pasirinkti sveiką mazgą kaip pagrindinį, pagrindinis mazgas žinos dabartinę kiekvieno klasterio serverio sveikatos būklę, kai mazgas sugenda, meistras praneš kitiems klasterio serveriams, kad būtų galima perskirstyti skirtingų mazgų skaičiavimo užduotis. "Zookeeper" gali ne tik rasti gedimus, bet ir patikrinti sugedusį serverį, pamatyti, koks gedimas yra gedimo serveris, jei gedimą galima ištaisyti, "zookeeper" gali automatiškai ištaisyti arba pasakyti sistemos administratoriui klaidos priežastį, kad administratorius galėtų greitai nustatyti problemą ir ištaisyti mazgo gedimą. Jums vis dar gali kilti klausimas, ką daryti, jei meistras yra sugedęs? "Zookeeper" taip pat į tai atsižvelgia, zoologijos sodo prižiūrėtojas turi vidinį "lyderių rinkimo algoritmą", meistrai gali būti dinamiškai atrenkami, o kai meistras nepavyksta, zoologijos sodo prižiūrėtojas gali iš karto pasirinkti naują meistrą klasteriui valdyti.
Pakalbėkime apie zoologijos sodo prižiūrėtojo ypatybes:
"ZooKeeper" yra supaprastinta failų sistema. Tai šiek tiek panašu į "Hadoop", tačiau "ZooKeeper" failų sistema tvarko mažus failus, o "Hadoop" - labai didelius failus.
"Zookeeper" pateikia daugybę "artefaktų", leidžiančių daugeliui operacijų koordinuoti duomenų struktūras ir protokolus. Pavyzdžiui: paskirstytos eilės, paskirstytos spynos ir to paties lygio mazgų grupės "lyderio rinkimų" algoritmas.
"ZooKeeper" yra labai prieinamas, jo paties stabilumas yra gana geras, paskirstyti klasteriai gali pasikliauti "Zookeeper" klasterių valdymu, o "ZooKeeper" naudojamas siekiant išvengti paskirstytų sistemų vieno taško gedimo problemos.
Zookeeper priima laisvai susietą sąveikos režimą. Tai akivaizdžiausiai matyti iš to, kad zookeeper teikia paskirstytus užraktus, kurie gali būti naudojami kaip paskyrimo mechanizmas, leidžiantis dalyvaujantiems procesams atrasti ir sąveikauti tarpusavyje nežinant kitų procesų (ar tinklo), o dalyvaujančios šalys net neprivalo egzistuoti tuo pačiu metu, kol jos palieka pranešimą zookeeper, o pasibaigus procesui, kitas procesas gali perskaityti šį pranešimą, taip atsiedamas ryšį tarp mazgų.
"ZooKeeper" suteikia bendrą klasterio saugyklą, iš kurios klasteris gali centralizuotai skaityti ir rašyti bendrą informaciją, išvengdamas kiekvieno mazgo bendrų operacijų programavimo ir sumažindamas paskirstytų sistemų kūrimo sunkumus.
Zookeeper daugiausia yra atsakingas už visiems rūpimų duomenų saugojimą ir tvarkymą, o tada priima stebėtojų registraciją, kai pasikeičia šių duomenų būsena, Zookeeper bus atsakingas už pranešimą tiems stebėtojams, kurie užsiregistravo Zookeeper, kad jie atitinkamai reaguotų, kad būtų pasiektas pagrindinis / vergų valdymo režimas, panašus į klasterį.
Galima pastebėti, kad zookeeper yra labai palankus paskirstytų sistemų kūrimui, todėl paskirstytos sistemos gali būti tvirtesnės ir efektyvesnės.
Ne taip seniai dalyvavau departamento hadoop interesų grupėje, ir aš įdiegiau hadoop, mapreduce, avilys ir Hbase bandymo aplinkoje, ir aš įdiegiau zookeeper iš anksto, kai įdiegti hbase. "ZooKeeper" gali teikti paslaugas, todėl daugiau nei pusė iš 3 yra 2, o daugiau nei pusė iš 4 taip pat yra du, todėl įdiegus tris serverius galima pasiekti 4 serverių efektą. Mokydamasis hadoop jaučiu, kad zookeeper yra sunkiausiai suprantamas subprojektas, priežastis ne ta, kad jis yra techniškai atsakingas, o tai, kad jo taikymo kryptis man labai paini, todėl mano pirmasis straipsnis apie hadoop technologiją prasideda nuo zookeeper ir nekalba apie konkretų techninį įgyvendinimą, tačiau iš zookeeper taikymo scenarijų suprantu zookeeper taikymo sritį, manau, kad mokymasis zookeeper bus efektyvesnis su puse pastangų.
Priežastis, kodėl šiandien noriu kalbėti apie zoologijos sodo prižiūrėtoją, yra papildyti ankstesniame straipsnyje pateiktą platinamą svetainės sistemą. Nors svetainės architektūrą sukūriau kaip paskirstytą struktūrą, taip pat sukūriau paprastą gedimų valdymo mechanizmą, pavyzdžiui, širdies plakimo mechanizmą, tačiau vis tiek nėra galimybės išspręsti vieno klasterio gedimo taško, jei serveris sugenda, klientas bandys prisijungti prie šio serverio, todėl kai kurios užklausos bus užblokuotos, taip pat bus švaistomi serverio ištekliai. Tačiau šiuo metu nenoriu keisti savo sistemos, nes visada manau, kad zoologijos sodo prižiūrėtojo paslaugos įtraukimas į esamas paslaugas turės įtakos svetainės efektyvumui. Laimei, mūsų skyrius taip pat rado tokią problemą, mūsų skyrius sukurs galingą nuotolinių skambučių sistemą, atskirs klasterio valdymą ir komunikacijos valdymą bei centralizuotai teiks efektyvias ir prieinamas paslaugas.
Perkelta iš ttp://www.cnblogs.com/sharpxiajun/archive/2013/06/02/3113923.html |
Paskelbta 2017-07-18 14:19:01
|
|
|
