Zookeeper on Hadoopi alamprojekt ja kuigi see on tuletatud hadoopist, olen märganud, et zookeeper kasutab üha enam hajutatud raamistikke väljaspool hadoopi. Täna tahan rääkida zookeeperist, see artikkel ei räägi sellest, kuidas zookeeperit kasutada, vaid millised on zookeeperi praktilised rakendused, millised rakendused võivad zookeeperi eeliseid kasutada, ning lõpuks räägime sellest, millist rolli zookeeper võib mängida hajutatud veebilehe arhitektuuris.
Zookeeper on väga usaldusväärne koordineerimissüsteem suurte hajutatud süsteemide jaoks. Selle definitsiooni põhjal teame, et loomaaiahoidja on koordineeritud süsteem, mis toimib hajutatud süsteemidel. Miks vajavad hajutatud süsteemid koordineerimissüsteemi? Põhjused on järgmised:
Hajutatud süsteemi arendamine on väga keeruline ülesanne ning see raskus peegeldub peamiselt hajutatud süsteemi "osalises ebaõnnestumises". "Osaline rike" tähendab info edastamist võrgu kahe sõlme vahel; kui võrk ebaõnnestub, ei saa saatja teada, kas vastuvõtja on sõnumi kätte saanud, ja selle rikke põhjus on keeruline, vastuvõtja võib sõnumi enne võrguviga kätte saada või mitte, või vastuvõtja protsess on surnud. Ainus viis, kuidas saatja saab päris pildi, on taasühendada vastuvõtjaga ja küsida, miks viga tekkis, mis on "osalise rikke" probleem hajutatud süsteemide arenduses.
Zookeeper on raamistik hajutatud süsteemide "osalise rikke" lahendamiseks. Zookeeper ei luba hajutatud süsteemidel vältida "osalise rikke" probleeme, kuid võimaldab hajutatud süsteemidel neid õigesti lahendada osaliste rikete korral, et hajutatud süsteemid saaksid normaalselt töötada.
Räägime loomaaia hoidja praktilisest kasutamisest:
Stsenaarium 1: On serverite grupp, mis pakub kliendile kindlat teenust (näiteks varem tehtud jaotatud veebilehe serveripoolne klaster, mis koosneb neljast serverist, et pakkuda teenuseid front-end klastrile), ja loodame, et klient leiab serveriklastristrist serveri iga kord, kui klient seda soovib, et server saaks pakkuda kliendile vajalikke teenuseid. Selle stsenaariumi jaoks peame omama programmi serverite nimekirja, kust loeme serverite nimekirja iga kord, kui klient seda soovib. Siis ei saa seda alamloendit loomulikult salvestada ühele sõlmeserverile, vastasel juhul hangub sõlm kinni ja kogu klaster ebaõnnestub, ning loodame, et see nimekiri on sel ajal väga kättesaadav. Kui salvestusloendis olev server on katki, saavad teised serverid kohe katki läinud serveri asendada ning katkine server saab nimekirjast eemaldada, nii et rikkis server saab kogu klastri tööst loobuda ning kõiki neid toiminguid ei juhi ebaõnnestunud server, vaid tavaline server klastris. See on aktiivne hajutatud andmestruktuur, mis suudab andmeelementide olekut aktiivselt muuta, kui välised tingimused muutuvad. Zookeeperi raamistik pakub seda teenust. Selle teenuse nimi on: Unified Naming Service, mis on väga sarnane javaEE JNDI teenusele.
Stsenaarium 2: Hajutatud lukuteenus. Kui hajutatud süsteem manipuleerib andmetega, näiteks loeb andmeid, analüüsib andmeid ja lõpuks muudab andmeid. Hajutatud süsteemis võivad need operatsioonid hajuda klastri erinevatesse sõlmedesse, siis tekib andmete töötlemise protsessis järjepidevuse probleem; kui see on ebajärjekindel, saame vale operatsiooni tulemuse, ühe protsessiprogrammi puhul on järjepidevuse probleem lihtne lahendada, kuid hajutatud süsteemi jõudmine on keerulisem, sest erinevate serverite operatsioonid toimuvad sõltumatutes protsessides ning vahetulemused ja protsessid tuleb edastada läbi võrgu. Siis on palju keerulisem saavutada andmetöötluse järjepidevust. Zookeeper pakub lukuteenust, mis lahendab selle probleemi, võimaldades meil tagada andmeoperatsioonide järjepidevuse hajutatud andmetoimingute tegemisel.
Stsenaarium 3: Konfiguratsiooni haldus. Hajutatud süsteemis juurutame teenuserakenduse eraldi n serverisse ning nende serverite konfiguratsioonifailid on samad (näiteks hajutatud veebiraamistikus, mille ma disainisin, on serveripoolel 4 serverit, nelja serveri programmid on samad ja konfiguratsioonifailid samad), kui konfiguratsioonifailide seadistusvalikud muutuvad, peame neid konfiguratsioonifaile ükshaaval muutma, kui serverid on suhteliselt väikesed, pole need toimingud liiga tülikad, Kui meil on palju hajutatud servereid, näiteks suure internetiettevõtte Hadoop klaster tuhandete serveritega, võib konfiguratsioonivalikute muutmine olla tülikas ja ohtlik. Praegu võib zookeeper olla kasulik, saame kasutada zookeeperit väga kättesaadava konfiguratsioonimäluna, anda see üle zookeeperile halduseks, kopeerime klastri konfiguratsioonifaili zookeeperi failisüsteemi sõlme ja kasutame zookeeperit konfiguratsioonifaili oleku jälgimiseks kõigis hajutatud süsteemides, kui leitakse, et konfiguratsioonifail on muutunud, Iga server saab Zookeeperilt teate, et sünkroniseerida konfiguratsioonifailid Zookeeperis, ning Zookeeperi teenus tagab ka, et sünkroniseerimistoiming oleks atomiline, et iga serveri konfiguratsioonifail oleks korrektselt uuendatud.
Stsenaarium 4: Paku rikete parandamise funktsioone hajutatud süsteemidele. Klastrite haldamine on keeruline ning loomaaiahoidja teenuse lisamine hajutatud süsteemi teeb klastri haldamise lihtsaks. Klastrihalduses on kõige tülikam asi sõlmede rikkete haldamine, zookeeper saab lasta klastril valida terve sõlme meistriks, peasõlm teab iga serveri praegust seisundit klastris, kui sõlm rikneb, teavitab meister teisi klastri servereid, et jagada arvutusülesandeid erinevate sõlmede vahel. Zookeeper saab mitte ainult vead leida, vaid ka kontrollida vigast serverit, näha, mis tüüpi viga serveris on; kui viga saab parandada, saab ta automaatselt parandada või öelda süsteemiadministraatorile vea põhjuse, et administraator saaks kiiresti probleemi üles leida ja sõlme vea parandada. Sul võib siiski tekkida küsimus, mida peaksin tegema, kui master on vigane? Zookeeper arvestab seda samuti: loomaaiahoidjal on sisemine "algoritm juhtide valimiseks", meistreid saab dünaamiliselt valida ning kui peremees ebaõnnestub, saab loomaaiahoidja kohe valida uue meistri klastri haldamiseks.
Räägime loomaaia töötaja omadustest:
ZooKeeper on lihtsustatud failisüsteem. See on veidi sarnane Hadoopile, kuid ZooKeeperi failisüsteem haldab väikeseid faile, samas kui Hadoop haldab väga suuri faile.
Zookeeper pakub hulgaliselt "artefakte", mis võimaldavad paljudel operatsioonidel koordineerida andmestruktuure ja protokolle. Näiteks: hajutatud järjekorrad, hajutatud lukud ja samal tasemel sõlmede grupi "juhi valimise" algoritm.
ZooKeeper on väga kättesaadav, selle enda stabiilsus on üsna hea, hajutatud klastrid saavad tugineda Zookeeperi klastrite haldamisele ning ZooKeeperit kasutatakse hajutatud süsteemide ühe punkti rikke vältimiseks.
Zookeeper kasutab lõdvalt seotud suhtlusrežiimi. See ilmneb kõige selgemalt selles, et zookeeper pakub hajutatud lukke, mida saab kasutada kohtumismehhanismina, mis võimaldab osalevatel protsessidel omavahel avastada ja suhelda ilma teiste protsesside (või võrgu) teadmiseta, ning osalevad osapooled ei pea isegi samaaegselt eksisteerima, kui nad jätavad sõnumi zookeeperisse ja pärast protsessi lõppu saab teine protsess seda sõnumit lugeda, lahutades sellega sõlmedevahelise suhte.
ZooKeeper pakub klastrile jagatud hoidlat, kust klaster saab tsentraalselt lugeda ja kirjutada jagatud infot, vältides iga sõlme jaoks jagatud operatsioonide programmeerimist ning vähendades hajutatud süsteemide arenduse raskusi.
Zookeeper vastutab peamiselt kõigi hoolivate andmete salvestamise ja haldamise eest ning seejärel vaatlejate registreerimise aktsepteerimise eest; kui nende andmete staatus muutub, vastutab ta nende vaatlejate teavitamise eest, kes on Zookeeperis registreerunud, et nad vastaksid vastavalt, et saavutada master/slave haldusrežiim, mis sarnaneb klastrile.
On näha, et zookeeper soodustab väga hajutatud süsteemide arendamist, mis muudab hajutatud süsteemid vastupidavamaks ja tõhusamaks.
Mitte kaua aega tagasi osalesin osakonna hadoop huvigrupis, paigaldasin testkeskkonda hadoopi, mapreduce'i, Hive'i ja Hbase'i ning hbase'i paigaldamisel eelnevalt zookeeperi. Zookeeper suudab teenuseid pakkuda, nii et rohkem kui pooled kolmest on 2 ja rohkem kui pool neljast on samuti kaks, nii et kolme serveri paigaldamine võib saavutada 4 serveri efekti. Hadoopi õppimise protsessis tunnen, et zookeeper on kõige raskem alamprojekt mõista, põhjus ei ole selles, et see oleks tehniliselt vastutustundlik, vaid selle rakendussuund on minu jaoks väga segane, seega algab minu esimene artikkel hadoop tehnoloogiast "Zookeeper" ja ei räägi konkreetsest tehnilisest rakendusest, kuid Zookeeperi rakenduse stsenaariumitest saan ma aru "Zookeeper'i rakenduste valdkonnast", arvan, et "zookeeperi õppimine" on poole väiksema pingutusega tõhusam.
Põhjus, miks ma tahan täna rääkida zookeeperist, on see, et täiendada hajutatud veebisaidi raamistikku oma eelmises artiklis. Kuigi kujundasin veebilehe arhitektuuri hajutatud struktuurina, tegin ka lihtsa tõrkete käsitlemise mehhanismi, näiteks südamelöögimehhanismi, kuid klastri ühte rikete punkti lahendamist pole siiski võimalik lahendada – kui server on katki, üritab klient selle serveriga ühenduda, mis põhjustab mõnede päringute blokeerimist ja serveri ressursside raiskamist. Kuid ma ei taha praegu oma raamistikku muuta, sest tunnen alati, et loomaaiahoidja teenuse lisamine olemasolevatele teenustele mõjutab veebilehe efektiivsust. Õnneks on ka meie osakond sellise probleemi leidnud, osakond arendab välja võimsa kaugkõnede raamistiku, eraldab klastrihalduse ja kommunikatsioonihalduse ning pakub tõhusaid ja kättesaadavaid teenuseid keskselt.
Üleviidud ttp://www.cnblogs.com/sharpxiajun/archive/2013/06/02/3113923.html |
Postitatud 18.07.2017 14:19:01
|
|
|
