Zookeeper er et delprojekt af Hadoop, og selvom det er afledt af hadoop, har jeg erfaret, at Zookeeper i stigende grad bruger distribuerede frameworks uden for hadoop. I dag vil jeg tale om Zookeeper, denne artikel vil ikke handle om, hvordan man bruger Zookeeper, men hvad de praktiske anvendelser af Zookeeper er, hvilke typer applikationer der kan udnytte fordelene ved Zookeeper, og til sidst tale om, hvilken rolle Zookeeper kan spille i distribueret hjemmesidearkitektur.
Zookeeper er et yderst pålideligt koordineringssystem for store distribuerede systemer. Ud fra denne definition ved vi, at zookeeper er et koordineret system, der virker på distribuerede systemer. Hvorfor har distribuerede systemer brug for et koordineringssystem? Årsagerne er som følger:
At udvikle et distribueret system er en meget vanskelig opgave, og vanskeligheden afspejles hovedsageligt i den "delvise fejl" af det distribuerede system. "Delvist fejl" refererer til overførsel af information mellem to noder i netværket; hvis netværket fejler, kan afsenderen ikke vide, om modtageren har modtaget beskeden, og årsagen til denne fejl er kompleks, modtageren kan have modtaget beskeden før netværksfejlen, eller modtagerens proces er død. Den eneste måde, afsenderen kan få det rigtige billede på, er ved at genoprette forbindelsen til modtageren og spørge modtageren, hvorfor fejlen opstod, hvilket er "delvis fejl"-problemet i udvikling af distribuerede systemer.
Zookeeper er rammen til at løse den "delvise fejl" i distribuerede systemer. Zookeeper tillader ikke distribuerede systemer at undgå "delvise fejl"-problemer, men tillader distribuerede systemer korrekt at håndtere sådanne problemer ved delvise fejl, så distribuerede systemer kan fungere normalt.
Lad os tale om den praktiske anvendelse af zookeeper:
Scenarie 1: Der er en gruppe servere, der leverer en bestemt service til klienten (for eksempel er serversiden af den distribuerede hjemmeside, jeg lavede tidligere, en klynge bestående af fire servere til at levere tjenester til front-end klyngen), og vi håber, at klienten kan finde en server i serverklyngen hver gang klienten anmoder om den, så serveren kan levere klienten de tjenester, klienten har brug for. I dette scenarie skal vi have en liste over servere i vores program, hvorfra vi læser listen over servere hver gang klienten anmoder om den. Så kan denne underliste åbenlyst ikke gemmes på en enkelt nodeserver, ellers vil noden hænge på, og hele klyngen vil fejle, og vi håber, at denne liste vil være meget tilgængelig på det tidspunkt. Hvis en server i lagringslisten er i stykker, kan andre servere straks erstatte den defekte server, og den defekte server kan fjernes fra listen, så den fejlslagne server kan trække sig ud af driften af hele klyngen, og alle disse operationer vil ikke blive drevet af den fejlede server, men af den normale server i klyngen. Dette er en aktiv distribueret datastruktur, der aktivt kan ændre tilstanden af dataelementer, når eksterne forhold ændrer sig. Zookeeper-rammen leverer denne service. Navnet på denne tjeneste er: Unified Naming Service, som minder meget om JNDI-tjenesten i javaEE.
Scenarie 2: Distribueret låseservice. Når et distribueret system manipulerer data, såsom at læse data, analysere data og til sidst ændre data. I det distribuerede system kan disse operationer være spredt til forskellige noder i klyngen, og der opstår et problem med konsistens i dataoperationen; hvis den er inkonsistent, får vi et forkert operationsresultat, i et enkelt procesprogram er konsistensproblemet let at løse, men det er sværere at nå det distribuerede system, fordi driften af forskellige servere i det distribuerede system foregår i uafhængige processer, og de mellemliggende resultater og processer i operationen skal transmitteres gennem netværket. Så er det meget sværere at opnå konsistens i dataoperationerne. Zookeeper tilbyder en låsetjeneste, der løser dette problem, så vi kan sikre ensartethed i dataoperationerne, når vi udfører distribuerede dataoperationer.
Scenarie 3: Konfigurationsstyring. I et distribueret system deployerer vi en serviceapplikation til n servere separat, og konfigurationsfilerne for disse servere er de samme (for eksempel i det distribuerede hjemmeside-framework, jeg designede, er der 4 servere på serversiden, programmerne på de 4 servere er de samme, og konfigurationsfilerne er de samme), hvis konfigurationsmulighederne for konfigurationsfilerne ændrer sig, skal vi ændre disse konfigurationsfiler én efter én, hvis vi skal ændre serverne, er disse operationer ikke for besværlige, Hvis vi har et stort antal distribuerede servere, som for eksempel en stor internetvirksomheds Hadoop-klynge med tusindvis af servere, kan det være besværligt og farligt at ændre konfigurationsmuligheder. På nuværende tidspunkt kan zookeeper være nyttigt, vi kan bruge zookeeper som et meget tilgængeligt konfigurationshukommelse, overdrage sådan noget til zookeeper til administration, vi kopierer konfigurationsfilen for klyngen til en node i zookeeperens filsystem, og derefter bruge zookeeper til at overvåge status på konfigurationsfilen i alle distribuerede systemer, når det opdages, at konfigurationsfilen er ændret, Hver server modtager en notifikation fra Zookeeper om at synkronisere konfigurationsfilerne i Zookeeper, og Zookeeper-tjenesten sikrer også, at synkroniseringsoperationen er atomar, så hver servers konfigurationsfil opdateres korrekt.
Scenarie 4: Leverer fejlreparationsfunktioner til distribuerede systemer. Klyngestyring er vanskelig, og at tilføje zookeeper-tjenesten til det distribuerede system gør det nemt for os at administrere klyngen. Det mest problematiske ved klyngestyring er nodefejlhåndtering; zookeeper kan lade klyngen vælge en sund node som master, masternoden kender den aktuelle sundhedsstatus for hver server i klyngen, og når en node fejler, vil masteren underrette de andre servere i klyngen for at omfordele computeropgaverne for forskellige noder. Zookeeper kan ikke kun finde fejl, men også screene den defekte server, se hvilken type fejl fejlserveren er; hvis fejlen kan repareres, kan Zookeeper automatisk rette eller fortælle systemadministratoren årsagen til fejlen, så administratoren hurtigt kan finde problemet og reparere nodens fejl. Du har måske stadig et spørgsmål: Hvad skal jeg gøre, hvis masteren er defekt? Zookeeper tager også højde for dette; Zookeeper har en intern "algoritme til valg af ledere", mastere kan vælges dynamisk, og når masteren fejler, kan Zookeeper straks vælge en ny master til at styre klyngen.
Lad os tale om funktionerne ved zookeeper:
ZooKeeper er et strømlinet filsystem. Dette minder lidt om Hadoop, men ZooKeeper-filsystemet håndterer små filer, mens Hadoop håndterer meget store filer.
Zookeeper leverer et væld af "artefakter", der muliggør mange operationer til at koordinere datastrukturer og protokoller. For eksempel: distribuerede køer, distribuerede låse og "ledervalg"-algoritmen for en gruppe noder på samme niveau.
ZooKeeper er meget tilgængelig, dets egen stabilitet er ganske god, distribuerede klynger kan stole på styringen af Zookeeper-klynger, og ZooKeeper bruges til at undgå problemet med enkeltpunktsfejl i distribuerede systemer.
Zookeeper anvender en løst koblet interaktionstilstand. Dette ses mest tydeligt i, at zookeeper tilbyder distribuerede låse, som kan bruges som en aftalemekanisme, der tillader deltagende processer at opdage og interagere med hinanden uden at kende de andre processer (eller netværket), og de deltagende parter behøver ikke engang at eksistere samtidig, så længe de efterlader en besked i zookeeper, og efter processen slutter, kan en anden proces læse denne besked og dermed adskille forholdet mellem noder.
ZooKeeper leverer et delt repository for klyngen, hvorfra klyngen kan læse og skrive delt information centralt, hvilket undgår programmering af delte operationer for hver node og reducerer udviklingsvanskelighederne for distribuerede systemer.
Zookeeper er hovedsageligt ansvarlig for at lagre og administrere de data, som alle går op i, og derefter acceptere registreringen af observatører; når status på disse data ændres, vil Zookeeper være ansvarlig for at underrette de observatører, der har registreret sig på Zookeeper, om at reagere derefter, så man kan opnå en master/slave-administrationstilstand, der ligner klyngen.
Det kan ses, at zookeeper er meget velegnet til udvikling af distribuerede systemer, hvilket kan gøre distribuerede systemer mere robuste og effektive.
For ikke så længe siden deltog jeg i afdelingens hadoop interessegruppe, og jeg installerede Hadoop, Mapreduce, Hive og Hbase i testmiljøet, og jeg installerede Zookeeper på forhånd, da jeg installerede Hbase. Zookeeper kan levere tjenester, så mere end halvdelen af de 3 er 2, og mere end halvdelen af de 4 er også to, så installation af tre servere kan opnå effekten af 4 servere. I processen med at lære hadoop føler jeg, at Zookeeper er det sværeste delprojekt at forstå, grunden er ikke, at det er teknisk ansvarligt, men at dets applikationsretning er meget forvirrende for mig, så min første artikel om Hadoop-teknologi starter med Zookeeper og taler ikke om specifik teknisk implementering, men ud fra anvendelsesscenarierne for Zookeeper forstår jeg feltet Zookeeper-applikationer, og jeg tror, at det vil være mere effektivt at lære Zookeeper med halvt så meget arbejde.
Grunden til, at jeg vil tale om Zookeeper i dag, er for at supplere det distribuerede hjemmeside-framework i min tidligere artikel. Selvom jeg designede webarkitekturen som en distribueret struktur, lavede jeg også en simpel fejlhåndteringsmekanisme, såsom heartbeat-mekanismen, men der er stadig ingen måde at løse klyngens enkeltfejlspunkt på; hvis en server er ødelagt, vil klienten forsøge at forbinde til denne server, hvilket resulterer i blokering af nogle forespørgsler og også spild af serverressourcer. Men jeg ønsker ikke at ændre mit framework lige nu, fordi jeg altid føler, at tilføjelse af zookeeper-service til eksisterende tjenester vil påvirke hjemmesidens effektivitet. Heldigvis har vores afdeling også fundet et sådant problem; vores afdeling vil udvikle en kraftfuld ramme for fjernopkald, adskille klyngestyring og kommunikationsstyring og levere effektive og tilgængelige tjenester centralt.
Overført fra ttp://www.cnblogs.com/sharpxiajun/archive/2013/06/02/3113923.html |
Opslået på 18/07/2017 14.19.01
|
|
|
