Zookeeper er et underprosjekt av Hadoop, og selv om det er avledet fra Hadoop, har jeg erfart at Zookeeper i økende grad bruker distribuerte rammeverk utenfor Hadoop. I dag vil jeg snakke om Zookeeper, denne artikkelen vil ikke snakke om hvordan man bruker Zookeeper, men hva de praktiske anvendelsene av Zookeeper er, hvilke typer applikasjoner som kan utnytte fordelene med Zookeeper, og til slutt snakke om hvilken rolle Zookeeper kan spille i distribuert nettsidearkitektur.
Zookeeper er et svært pålitelig koordineringssystem for store distribuerte systemer. Fra denne definisjonen vet vi at zookeeper er et koordinert system som virker på distribuerte systemer. Hvorfor trenger distribuerte systemer et koordineringssystem? Årsakene er som følger:
Å utvikle et distribuert system er en svært vanskelig oppgave, og vanskeligheten gjenspeiles hovedsakelig i «delvis feil» i det distribuerte systemet. "Delvis feil" refererer til overføring av informasjon mellom to noder i nettverket; hvis nettverket feiler, kan ikke avsenderen vite om mottakeren har mottatt meldingen, og årsaken til feilen er kompleks, mottakeren kan ha mottatt meldingen før nettverksfeilen, eller mottakerens prosess er død. Den eneste måten avsenderen kan få det virkelige bildet på, er å koble seg til mottakeren igjen og spørre mottakeren hvorfor feilen oppstod, noe som er «delvis feil»-problemet i utvikling av distribuerte systemer.
Zookeeper er rammeverket for å løse "delvis feil" i distribuerte systemer. Zookeeper tillater ikke at distribuerte systemer unngår "delvis feil"-problemer, men lar distribuerte systemer håndtere slike problemer korrekt ved delvise feil, slik at distribuerte systemer kan fungere normalt.
La oss snakke om den praktiske bruken av dyrepasser:
Scenario 1: Det finnes en gruppe servere som leverer en bestemt tjeneste til klienten (for eksempel er serversiden av det distribuerte nettstedet jeg laget tidligere en klynge bestående av fire servere for å levere tjenester til front-end-klyngen), og vi håper at klienten kan finne en server i serverklyngen hver gang klienten ber om det, slik at serveren kan gi klienten de tjenestene klienten trenger. For dette scenariet må vi ha en liste over servere i programmet vårt, hvor vi leser listen over servere hver gang klienten ber om det. Da kan denne underlisten åpenbart ikke lagres på en enkelt nodeserver, ellers vil noden henge seg opp og hele klyngen vil feile, og vi håper at denne listen vil være svært tilgjengelig da. Hvis en server i lagringslisten er ødelagt, kan andre servere umiddelbart erstatte den ødelagte serveren, og den ødelagte serveren kan fjernes fra listen, slik at den feilede serveren kan trekke seg ut av driften av hele klyngen, og alle disse operasjonene ikke vil bli drevet av den feilede serveren, men av den vanlige serveren i klyngen. Dette er en aktiv distribuert datastruktur som aktivt kan endre tilstanden til dataelementer når eksterne forhold endres. Zookeeper-rammeverket tilbyr denne tjenesten. Navnet på denne tjenesten er: Unified Naming Service, som er svært lik JNDI-tjenesten i javaEE.
Scenario 2: Distribuert låsetjeneste. Når et distribuert system manipulerer data, som å lese data, analysere data og til slutt endre data. I det distribuerte systemet kan disse operasjonene være spredt til forskjellige noder i klyngen, da oppstår det et problem med konsistens i dataoperasjonsprosessen; hvis det er inkonsistent, får vi feil operasjonsresultat, i et enkelt prosessprogram er konsistensproblemet lett å løse, men det er vanskeligere å nå det distribuerte systemet, fordi operasjonene til ulike servere i det distribuerte systemet foregår i uavhengige prosesser, og de mellomliggende resultatene og prosessene i operasjonen må overføres gjennom nettverket. Da er det mye vanskeligere å oppnå konsistens i dataoperasjoner. Zookeeper tilbyr en låsetjeneste som løser dette problemet, slik at vi kan sikre konsistens i dataoperasjonene når vi utfører distribuerte dataoperasjoner.
Scenario 3: Konfigurasjonsstyring. I et distribuert system distribuerer vi en tjenesteapplikasjon til n servere separat, og konfigurasjonsfilene til disse serverne er de samme (for eksempel, i det distribuerte nettsiderammeverket jeg har designet, er det 4 servere på serversiden, programmene på de 4 serverne er de samme, og konfigurasjonsfilene er de samme), hvis konfigurasjonsalternativene for konfigurasjonsfilene endres, må vi endre disse konfigurasjonsfilene én etter én, hvis vi må endre serverne er relativt små, disse operasjonene er ikke så plagsomme, Hvis vi har et stort antall distribuerte servere, som for eksempel et stort internettselskaps Hadoop-klynge med tusenvis av servere, kan det være vanskelig og farlig å endre konfigurasjonsvalg. På dette tidspunktet kan Zookeeper være nyttig, vi kan bruke Zookeeper som et høyt tilgjengelig konfigurasjonsminne, overlevere noe slikt til Zookeeper for administrasjon, vi kopierer konfigurasjonsfilen til klyngen til en node i Zookeepers filsystem, og bruker deretter Zookeeper til å overvåke statusen til konfigurasjonsfilen i alle distribuerte systemer, når det oppdages at konfigurasjonsfilen har endret seg, Hver server vil motta et varsel fra Zookeeper om å synkronisere konfigurasjonsfilene i Zookeeper, og Zookeeper-tjenesten vil også sørge for at synkroniseringsoperasjonen er atomisk for å sikre at hver servers konfigurasjonsfil oppdateres korrekt.
Scenario 4: Tilby feilreparasjonsfunksjoner for distribuerte systemer. Klyngehåndtering er vanskelig, og å legge til Zookeeper-tjenesten i det distribuerte systemet gjør det enkelt for oss å administrere klyngen. Det mest problematiske i klyngehåndtering er nodefeilhåndtering; Zookeeper kan la klyngen velge en frisk node som master, masternoden vil vite den nåværende helsestatusen til hver server i klyngen, og når en node feiler, vil masteren varsle de andre serverne i klyngen for å omfordele dataoppgavene til forskjellige noder. Zookeeper kan ikke bare finne feil, men også screene den defekte serveren, se hva slags feil serveren er, hvis feilen kan repareres, kan Zookeeper automatisk fikse eller fortelle systemadministratoren årsaken til feilen, slik at administratoren raskt kan finne problemet og reparere feilen i noden. Du har kanskje fortsatt et spørsmål, hva bør jeg gjøre hvis masteren er defekt? Zookeeper tar også hensyn til dette, Zookeeper har en intern "algoritme for å velge ledere", mastere kan velges dynamisk, og når masteren feiler, kan Zookeeper umiddelbart velge en ny master til å administrere klyngen.
La oss snakke om egenskapene til Zookeeper:
ZooKeeper er et strømlinjeformet filsystem. Dette ligner litt på Hadoop, men ZooKeeper-filsystemet håndterer små filer, mens Hadoop håndterer svært store filer.
Zookeeper tilbyr et vell av «artefakter» som gjør det mulig for mange operasjoner å koordinere datastrukturer og protokoller. For eksempel: distribuerte køer, distribuerte låser og "ledervalg"-algoritmen for en gruppe noder på samme nivå.
ZooKeeper er svært tilgjengelig, dens egen stabilitet er ganske god, distribuerte klynger kan stole på administrasjon av Zookeeper-klynger, og ZooKeeper brukes for å unngå problemet med enkeltpunktsfeil i distribuerte systemer.
Zookeeper benytter en løst koblet interaksjonsmodus. Dette er mest tydelig i det faktum at Zookeeper tilbyr distribuerte låser, som kan brukes som en avtalemekanisme for å la deltakende prosesser oppdage og samhandle med hverandre uten å kjenne de andre prosessene (eller nettverket), og de deltakende partene trenger ikke engang å eksistere samtidig, så lenge de legger igjen en melding i Zookeeper, og etter at prosessen er avsluttet, kan en annen prosess lese denne meldingen, og dermed frikoble forholdet mellom nodene.
ZooKeeper tilbyr et delt arkiv for klyngen, hvorfra klyngen kan lese og skrive delt informasjon sentralt, noe som unngår programmering av delte operasjoner for hver node og reduserer utviklingsvanskelighetene for distribuerte systemer.
Zookeeper har hovedansvaret for å lagre og administrere dataene som alle bryr seg om, og deretter akseptere registreringen av observatører. Når statusen på disse dataene endres, vil Zookeeper være ansvarlig for å varsle observatørene som har registrert seg på Zookeeper om å reagere deretter, for å oppnå en master/slave-administrasjonsmodus lik klyngen.
Det kan sees at Zookeeper er svært gunstig for utvikling av distribuerte systemer, noe som kan gjøre distribuerte systemer mer robuste og effektive.
For ikke lenge siden deltok jeg i avdelingens hadoop interessegruppe, og jeg installerte hadoop, mapreduce, Hive og Hbase i testmiljøet, og jeg installerte Zookeeper på forhånd da jeg installerte hbase. Zookeeper kan tilby tjenester, så mer enn halvparten av de tre er 2, og mer enn halvparten av de 4 er også to, så installasjon av tre servere kan oppnå effekten av 4 servere. I prosessen med å lære Hadoop føler jeg at Zookeeper er det vanskeligste delprosjektet å forstå, grunnen er ikke at det er teknisk ansvarlig, men at applikasjonsretningen er veldig forvirrende for meg, så min første artikkel om Hadoop-teknologi starter med Zookeeper, og snakker ikke om spesifikk teknisk implementering, men ut fra bruksområdene for Zookeeper forstår jeg feltet Zookeeper-applikasjoner, og jeg tror det å lære Zookeeper vil være mer effektivt med halvparten av innsatsen.
Grunnen til at jeg vil snakke om Zookeeper i dag, er for å supplere rammeverket for distribuerte nettsider i min forrige artikkel. Selv om jeg designet nettsidearkitekturen som en distribuert struktur, laget jeg også en enkel feilhåndteringsmekanisme, som heartbeat-mekanismen, men det finnes fortsatt ingen måte å løse enkeltpunktet for feil i klyngen; hvis en server er ødelagt, vil klienten prøve å koble seg til denne serveren, noe som fører til blokkering av noen forespørsler, og også sløsing med serverressurser. Men jeg ønsker ikke å endre rammeverket mitt akkurat nå, fordi jeg alltid føler at det å legge til Zookeeper-tjenesten til eksisterende tjenester vil påvirke effektiviteten til nettsiden. Heldigvis har avdelingen vår også funnet et slikt problem; avdelingen vår vil utvikle et kraftig rammeverk for fjernsamtaler, skille klyngehåndtering og kommunikasjonsstyring, og tilby effektive og tilgjengelige tjenester sentralt.
Overført fra ttp://www.cnblogs.com/sharpxiajun/archive/2013/06/02/3113923.html |
Publisert på 18.07.2017 14:19:01
|
|
|
