Jeg foreslår at du leser transkripsjonen av foredraget "Hadoop. ZooKeeper" fra serien "Metoder for distribuert behandling av store datavolumer i Hadoop"
Hva er ZooKeeper, dens plass i Hadoop-økosystemet. Usannheter om distribuert databehandling. Diagram over et standard distribuert system. Vanskeligheter med å koordinere distribuerte systemer. Typiske koordinasjonsproblemer. Prinsippene bak designet av ZooKeeper. ZooKeeper datamodell. znode flagg. Økter. Client API. Primitiver (konfigurasjon, gruppemedlemskap, enkle låser, ledervalg, låsing uten flokkeffekt). ZooKeeper-arkitektur. ZooKeeper DB. ZAB. Be om behandler.
I dag skal vi snakke om ZooKeeper. Denne tingen er veldig nyttig. Det, som alle Apache Hadoop-produkter, har en logo. Den skildrer en mann.
Før dette snakket vi hovedsakelig om hvordan data kan behandles der, hvordan man lagrer det, det vil si hvordan man bruker det på en eller annen måte og jobber med det på en eller annen måte. Og i dag vil jeg snakke litt om å bygge distribuerte applikasjoner. Og ZooKeeper er en av de tingene som lar deg forenkle denne saken. Dette er en slags tjeneste som er ment for en slags koordinering av samspillet mellom prosesser i distribuerte systemer, i distribuerte applikasjoner.
Behovet for slike søknader blir mer og mer for hver dag, det er det kurset vårt handler om. På den ene siden lar MapReduce og dette ferdige rammeverket deg utjevne denne kompleksiteten og frigjøre programmereren fra å skrive primitiver som interaksjon og koordinering av prosesser. Men på den annen side er det ingen som garanterer at dette ikke må gjøres uansett. MapReduce eller andre ferdige rammeverk erstatter ikke alltid noen tilfeller helt som ikke kan implementeres ved hjelp av dette. Inkludert MapReduce seg selv og en haug med andre Apache-prosjekter, de er faktisk også distribuerte applikasjoner. Og for å gjøre skrivingen enklere, skrev de ZooKeeper.
Som alle Hadoop-relaterte applikasjoner ble den utviklet av Yahoo! Det er nå også en offisiell Apache-applikasjon. Den er ikke like aktivt utviklet som HBase. Hvis du går til JIRA HBase, så er det hver dag en haug med feilrapporter, en haug med forslag for å optimalisere noe, det vil si at livet i prosjektet pågår konstant. Og ZooKeeper er på den ene siden et relativt enkelt produkt, og på den andre siden sikrer dette påliteligheten. Og det er ganske enkelt å bruke, og det er derfor det har blitt en standard i applikasjoner innenfor Hadoop-økosystemet. Så jeg tenkte at det ville være nyttig å se gjennom det for å forstå hvordan det fungerer og hvordan du bruker det.
Dette er et bilde fra et foredrag vi hadde. Vi kan si at det er ortogonalt i forhold til alt vi har vurdert så langt. Og alt som er angitt her, til en eller annen grad, fungerer med ZooKeeper, det vil si at det er en tjeneste som bruker alle disse produktene. Verken HDFS eller MapReduce skriver sine egne lignende tjenester som spesifikt vil fungere for dem. Derfor brukes ZooKeeper. Og dette forenkler utvikling og enkelte ting knyttet til feil.
Hvor kommer alt dette fra? Det ser ut til at vi lanserte to applikasjoner parallelt på forskjellige datamaskiner, koblet dem sammen med en streng eller i et nett, og alt fungerer. Men problemet er at nettverket er upålitelig, og hvis du snuste på trafikken eller så på hva som skjer der på et lavt nivå, hvordan klienter samhandler på nettverket, kan du ofte se at noen pakker går tapt eller sendes på nytt. Det er ikke for ingenting at TCP-protokoller ble oppfunnet, som lar deg etablere en viss økt og garantere levering av meldinger. Men i alle fall, selv TCP kan ikke alltid redde deg. Alt har en timeout. Nettverket kan rett og slett falle av en stund. Det kan bare blinke. Og alt dette fører til at du ikke kan stole på at nettverket er pålitelig. Dette er hovedforskjellen fra å skrive parallelle applikasjoner som kjører på én datamaskin eller på én superdatamaskin, der det ikke er nettverk, der det er en mer pålitelig datautvekslingsbuss i minnet. Og dette er en grunnleggende forskjell.
Blant annet ved bruk av Nettverket er det alltid en viss latens. Disken har det også, men nettverket har mer av det. Latens er en viss forsinkelsestid, som enten kan være liten eller ganske betydelig.
Nettverkstopologien er i endring. Hva er topologi - dette er plasseringen av nettverksutstyret vårt. Det er datasentre, det er stativer som står der, det er stearinlys. Alt dette kan kobles til igjen, flyttes osv. Alt dette må også tas i betraktning. IP-navn endres, rutingen som trafikken vår reiser gjennom endres. Dette må også tas i betraktning.
Nettverket kan også endre seg når det gjelder utstyr. Fra praksis kan jeg si at våre nettverksingeniører liker å periodisk oppdatere noe på lysene. Plutselig kom det ut en ny firmware og de var ikke spesielt interessert i en eller annen Hadoop-klynge. De har sin egen jobb. For dem er hovedsaken at nettverket fungerer. Følgelig vil de laste opp noe der på nytt, gjøre en blinking på maskinvaren deres, og maskinvaren endres også med jevne mellomrom. Alt dette må på en eller annen måte tas i betraktning. Alt dette påvirker vår distribuerte applikasjon.
Vanligvis tror folk som begynner å jobbe med store mengder data av en eller annen grunn at Internett er ubegrenset. Hvis det er en fil på flere terabyte der, kan du ta den til serveren eller datamaskinen din og åpne den med hvordan og se. En annen feil er inne Vim se på loggene. Gjør aldri dette fordi det er dårlig. Fordi Vim prøver å buffere alt, last alt inn i minnet, spesielt når vi begynner å bevege oss gjennom denne loggen og lete etter noe. Dette er ting som er glemt, men verdt å vurdere.
Det er lettere å skrive ett program som kjører på én datamaskin med én prosessor.
Når systemet vårt vokser, ønsker vi å parallellisere det hele, og parallellisere det ikke bare på en datamaskin, men også på en klynge. Spørsmålet oppstår: hvordan koordinere denne saken? Applikasjonene våre samhandler kanskje ikke engang med hverandre, men vi kjørte flere prosesser parallelt på flere servere. Og hvordan overvåke at alt går bra for dem? For eksempel sender de noe over Internett. De må skrive om tilstanden deres et sted, for eksempel i en slags database eller logg, deretter aggregere denne loggen og deretter analysere den et sted. I tillegg må vi ta hensyn til at prosessen fungerte og fungerte, plutselig dukket det opp en feil i den eller den krasjet, hvor raskt vil vi finne ut om det?
Det er klart at alt dette raskt kan overvåkes. Dette er også bra, men overvåking er en begrenset ting som lar deg overvåke enkelte ting på høyeste nivå.
Når vi ønsker at prosessene våre skal begynne å samhandle med hverandre, for eksempel for å sende hverandre litt data, så dukker også spørsmålet opp – hvordan vil dette skje? Vil det være en slags løpstilstand, vil de overskrive hverandre, vil dataene komme riktig, vil noe gå tapt underveis? Vi må utvikle en slags protokoll osv.
Koordinering av alle disse prosessene er ikke en triviell ting. Og det tvinger utvikleren til å gå ned på et enda lavere nivå, og skrive systemer enten fra bunnen av, eller ikke helt fra bunnen av, men dette er ikke så enkelt.
Hvis du kommer opp med en kryptografisk algoritme eller til og med implementerer den, så kast den umiddelbart, for mest sannsynlig vil den ikke fungere for deg. Den vil mest sannsynlig inneholde en haug med feil som du har glemt å sørge for. Bruk den aldri til noe alvorlig fordi den vil mest sannsynlig være ustabil. Fordi alle algoritmene som finnes har blitt testet av tid i veldig lang tid. Det er avlyttet av samfunnet. Dette er et eget tema. Og det er det samme her. Hvis det er mulig å ikke implementere en slags prosesssynkronisering selv, er det bedre å ikke gjøre dette, fordi det er ganske komplisert og fører deg ned på den vaklende veien for å konstant søke etter feil.
I dag snakker vi om ZooKeeper. På den ene siden er det et rammeverk, på den andre siden er det en tjeneste som gjør livet enklere for utvikleren og forenkler implementeringen av logikk og koordinering av våre prosesser så mye som mulig.
La oss huske hvordan et standard distribuert system kan se ut. Dette er hva vi snakket om - HDFS, HBase. Det er en mesterprosess som styrer arbeidere og slaveprosesser. Han er ansvarlig for å koordinere og fordele oppgaver, starte arbeidere på nytt, lansere nye og fordele belastningen.
En mer avansert ting er Koordinasjonstjenesten, det vil si å flytte selve koordineringsoppgaven inn i en egen prosess, pluss kjøre en slags backup eller stanby Master parallelt, fordi Masteren kan mislykkes. Og hvis Mesteren faller, vil ikke systemet vårt fungere. Vi kjører backup. Noen sier at masteren må replikeres til backup. Dette kan også overlates til Koordineringstjenesten. Men i dette diagrammet er Mesteren selv ansvarlig for å koordinere arbeiderne her koordinerer tjenesten datareplikeringsaktiviteter.
Et mer avansert alternativ er når all koordinering håndteres av vår tjeneste, slik det vanligvis gjøres. Han tar ansvar for at alt fungerer. Og hvis noe ikke fungerer, finner vi ut av det og prøver å omgå denne situasjonen. Uansett sitter vi igjen med en Mester som på en eller annen måte samhandler med slaver og kan sende data, informasjon, meldinger osv. gjennom en eller annen tjeneste.
Det er et enda mer avansert opplegg, når vi ikke har en Master, er alle noder masterslaver, forskjellige i oppførselen deres. Men de trenger fortsatt å samhandle med hverandre, så det er fortsatt noe tjeneste igjen for å koordinere disse handlingene. Sannsynligvis passer Cassandra, som jobber etter dette prinsippet, denne ordningen.
Det er vanskelig å si hvilken av disse ordningene som fungerer best. Hver har sine egne fordeler og ulemper.
Og det er ingen grunn til å være redd for noen ting med Mesteren, fordi han, som praksis viser, ikke er så mottakelig for å tjene hele tiden. Hovedsaken her er å velge den riktige løsningen for å hoste denne tjenesten på en egen kraftig node, slik at den har nok ressurser, slik at hvis mulig brukere ikke har tilgang der, slik at de ikke ved et uhell dreper denne prosessen. Men samtidig er det i en slik ordning mye lettere å administrere arbeidere fra Master-prosessen, det vil si at denne ordningen er enklere fra implementeringssynspunktet.
Og denne ordningen (over) er sannsynligvis mer kompleks, men mer pålitelig.
Hovedproblemet er delvise feil. For eksempel, når vi sender en melding over nettverket, skjer det en slags ulykke, og den som sendte meldingen vil ikke vite om meldingen hans ble mottatt og hva som skjedde på mottakerens side, vil ikke vite om meldingen ble behandlet riktig , dvs. han vil ikke motta noen bekreftelse.
Derfor må vi behandle denne situasjonen. Og det enkleste er å sende denne meldingen på nytt og vente til vi får svar. I dette tilfellet tas det ikke hensyn til om tilstanden til mottakeren har endret seg. Vi kan sende en melding og legge til de samme dataene to ganger.
ZooKeeper tilbyr måter å håndtere slike avslag på, noe som også gjør livene våre enklere.
Som nevnt litt tidligere ligner dette på å skrive flertrådede programmer, men hovedforskjellen er at i distribuerte applikasjoner som vi bygger på forskjellige maskiner, er den eneste måten å kommunisere på nettverket. I hovedsak er dette en delt-ingenting-arkitektur. Hver prosess eller tjeneste som kjører på én maskin har sitt eget minne, sin egen disk, sin egen prosessor, som den ikke deler med noen.
Hvis vi skriver et flertråds program på én datamaskin, kan vi bruke delt minne til å utveksle data. Vi har en kontekstbytte der, prosesser kan bytte. Dette påvirker ytelsen. På den ene siden er det ikke noe slikt i programmet på en klynge, men det er problemer med nettverket.
Følgelig er hovedproblemene som oppstår når du skriver distribuerte systemer, konfigurasjon. Vi skriver en slags søknad. Hvis det er enkelt, hardkoder vi alle slags tall i koden, men dette er upraktisk, for hvis vi bestemmer oss for at vi i stedet for en timeout på et halvt sekund vil ha en timeout på ett sekund, må vi kompilere applikasjonen på nytt og rull alt ut igjen. Det er én ting når den er på én maskin, når du bare kan starte den på nytt, men når vi har mange maskiner, må vi hele tiden kopiere alt. Vi må prøve å gjøre applikasjonen konfigurerbar.
Her snakker vi om statisk konfigurasjon for systemprosesser. Dette er ikke helt, kanskje fra operativsystemets synspunkt, det kan være en statisk konfigurasjon for prosessene våre, det vil si at dette er en konfigurasjon som ikke bare kan tas og oppdateres.
Det er også en dynamisk konfigurasjon. Dette er parametrene vi ønsker å endre i farten slik at de blir plukket opp der.
Hva er problemet her? Vi oppdaterte konfigurasjonen, rullet den ut, så hva? Problemet kan være at vi på den ene siden rullet ut config, men glemte den nye tingen, config forble der. For det andre, mens vi rullet ut, ble konfigurasjonen oppdatert noen steder, men ikke andre. Og noen prosesser i applikasjonen vår som kjører på én maskin ble startet på nytt med en ny konfigurasjon, og et sted med en gammel. Dette kan føre til at vår distribuerte applikasjon er inkonsekvent fra et konfigurasjonsperspektiv. Dette problemet er vanlig. For en dynamisk konfigurasjon er det mer relevant fordi det innebærer at det kan endres umiddelbart.
Et annet problem er gruppemedlemskap. Vi har alltid et sett med arbeidere, vi vil alltid vite hvem av dem som er i live, hvem av dem som er død. Hvis det er en Master, må han forstå hvilke arbeidere som kan omdirigeres til klienter slik at de kjører beregninger eller jobber med data, og hvilke som ikke kan. Et problem som stadig dukker opp er at vi må vite hvem som jobber i klyngen vår.
Et annet typisk problem er ledervalg, når vi vil vite hvem som har ansvaret. Et eksempel er replikering, når vi har en prosess som mottar skriveoperasjoner og deretter replikerer dem blant andre prosesser. Han vil være lederen, alle andre vil adlyde ham, vil følge ham. Det er nødvendig å velge en prosess slik at den er entydig for alle, slik at det ikke viser seg at to ledere velges ut.
Det er også gjensidig utelukkende tilgang. Problemet her er mer sammensatt. Det er noe slikt som en mutex, når du skriver flertrådede programmer og vil at tilgang til en ressurs, for eksempel en minnecelle, skal begrenses og utføres av bare én tråd. Her kunne ressursen vært noe mer abstrakt. Og forskjellige applikasjoner fra forskjellige noder i nettverket vårt skal bare få eksklusiv tilgang til en gitt ressurs, og ikke slik at alle kan endre den eller skrive noe der. Dette er de såkalte låsene.
ZooKeeper lar deg løse alle disse problemene i en eller annen grad. Og jeg vil vise med eksempler hvordan det lar deg gjøre dette.
Det er ingen blokkerende primitiver. Når vi begynner å bruke noe, vil ikke denne primitive vente på at noen hendelse skal inntreffe. Mest sannsynlig vil denne tingen fungere asynkront, og dermed tillate at prosesser ikke henger mens de venter på noe. Dette er en veldig nyttig ting.
Alle klientforespørsler behandles i rekkefølgen til den generelle køen.
Og klienter har mulighet til å motta varsel om endringer i en eller annen tilstand, om endringer i data, før klienten ser de endrede dataene selv.
ZooKeeper kan operere i to moduser. Den første er frittstående, på én node. Dette er praktisk for testing. Den kan også operere i klyngemodus, på et hvilket som helst antall noder. servereHvis vi har en klynge med 100 maskiner, trenger den ikke nødvendigvis å kjøre på 100 maskiner. Det er nok å allokere noen få maskiner der ZooKeeper kan kjøre. Og den følger prinsippet om høy tilgjengelighet. ZooKeeper lagrer en fullstendig kopi av dataene på hver kjørende instans. Jeg skal forklare hvordan den gjør dette senere. Den verken sharder eller partisjonerer dataene. På den ene siden er dette en ulempe fordi vi ikke kan lagre mye, men på den andre siden er det unødvendig. Den er ikke designet for det; det er ikke en database.
Data kan bufres på klientsiden. Dette er et standardprinsipp slik at vi ikke avbryter tjenesten og ikke laster den med de samme forespørslene. En smart klient vet vanligvis om dette og cacher det.
For eksempel har noe endret seg her. Det er en slags applikasjon. Det ble valgt ny leder som blant annet har ansvar for å behandle skriveoperasjoner. Og vi ønsker å replikere dataene. En løsning er å sette den i en løkke. Og vi stiller stadig spørsmål ved tjenesten vår – har noe endret seg? Det andre alternativet er mer optimalt. Dette er en klokkemekanisme som lar deg varsle klienter om at noe har endret seg. Dette er en rimeligere metode når det gjelder ressurser og mer praktisk for kundene.
Klienten er brukeren som bruker ZooKeeper.
Server er selve ZooKeeper-prosessen.
Znode er nøkkelen i ZooKeeper. Alle znoder lagres i minnet av ZooKeeper og er organisert i form av et hierarkisk diagram, i form av et tre.
Det er to typer operasjoner. Den første er oppdatering/skriving, når en operasjon endrer tilstanden til treet vårt. Treet er vanlig.
Og det er mulig at klienten ikke fullfører én forespørsel og blir koblet fra, men kan etablere en sesjon der den samhandler med ZooKeeper.
ZooKeepers datamodell ligner et filsystem. Det er en standard rot, og så gikk vi som om gjennom katalogene som går fra roten. Og så katalogen på første nivå, andre nivå. Dette er alle znoder.
Hver znode kan lagre noen data, vanligvis ikke veldig store, for eksempel 10 kilobyte. Og hver znode kan ha et visst antall barn.
Znoder kommer i flere typer. De kan lages. Og når vi oppretter en znode, spesifiserer vi typen den skal tilhøre.
Det er to typer. Det første er det flyktige flagget. Znode lever innenfor en økt. For eksempel har klienten etablert en sesjon. Og så lenge denne økten er i live, vil den eksistere. Dette er nødvendig for ikke å produsere noe unødvendig. Dette er også egnet for øyeblikk når det er viktig for oss å lagre dataprimitiver i en økt.
Den andre typen er sekvensielt flagg. Den øker telleren på vei til znoden. For eksempel hadde vi en katalog med applikasjon 1_5. Og da vi opprettet den første noden, mottok den p_1, den andre - p_2. Og når vi kaller denne metoden hver gang, passerer vi hele banen, og indikerer bare en del av banen, og dette tallet økes automatisk fordi vi angir nodetypen - sekvensiell.
Vanlig znode. Hun vil alltid leve og ha det navnet vi forteller henne.
En annen nyttig ting er klokkeflagget. Hvis vi installerer det, kan klienten abonnere på noen hendelser for en bestemt node. Jeg skal vise deg senere med et eksempel hvordan dette gjøres. ZooKeeper varsler selv klienten om at dataene på noden er endret. Varsler garanterer imidlertid ikke at noen nye data har kommet. De sier ganske enkelt at noe har endret seg, så du må fortsatt sammenligne data senere med separate samtaler.
Og som jeg allerede har sagt, er rekkefølgen på dataene bestemt av kilobyte. Det er ikke nødvendig å lagre store tekstdata der, fordi det ikke er en database, det er en handlingskoordineringsserver.
La meg fortelle deg litt om økter. Hvis vi har flere servere, kan vi transparent bytte fra én server til en annen. server, ved hjelp av økt-ID-en. Dette er ganske praktisk.
Hver økt har en slags timeout. En økt er definert av om klienten sender noe til serveren under den økten. Hvis han ikke sendte noe i løpet av timeouten, faller økten av, eller klienten kan lukke den selv.
Den har ikke så mange funksjoner, men du kan gjøre forskjellige ting med denne APIen. Det kallet vi så opprette oppretter en znode og tar tre parametere. Dette er banen til znoden, og den må spesifiseres i sin helhet fra roten. Og også dette er noen data vi ønsker å overføre dit. Og flaggtypen. Og etter opprettelsen returnerer den banen til znoden.
For det andre kan du slette den. Trikset her er at den andre parameteren, i tillegg til banen til znoden, kan spesifisere versjonen. Følgelig vil den znoden bli slettet hvis versjonen som vi overførte tilsvarer den som faktisk eksisterer.
Hvis vi ikke vil sjekke denne versjonen, sender vi bare "-1"-argumentet.
For det tredje sjekker den om det finnes en znode. Returnerer sant hvis noden eksisterer, ellers usant.
Og så vises flaggklokke, som lar deg overvåke denne noden.
Du kan sette dette flagget selv på en ikke-eksisterende node og motta et varsel når det vises. Dette kan også være nyttig.
Et par utfordringer til getData. Det er klart at vi kan motta data via znode. Du kan også bruke flaggklokke. I dette tilfellet vil det ikke installeres hvis det ikke er noen node. Derfor må du forstå at det eksisterer, og deretter motta data.
Det er også SetData. Her passerer vi versjon. Og hvis vi sender dette videre, vil dataene på znoden til en viss versjon bli oppdatert.
Du kan også spesifisere "-1" for å ekskludere denne sjekken.
En annen nyttig metode er fåChildren. Vi kan også få en liste over alle znoder som tilhører den. Vi kan overvåke dette ved å sette flaggvakt.
Og metode synkronisere lar alle endringer sendes på en gang, og sikrer dermed at de lagres og alle data er fullstendig endret.
Hvis vi trekker analogier med vanlig programmering, så når du bruker metoder som å skrive, som skriver noe til disk, og etter at det returnerer et svar til deg, er det ingen garanti for at du har skrevet dataene til disk. Og selv når operativsystemet er trygg på at alt er skrevet, er det mekanismer på selve disken der prosessen går gjennom lag med buffere, og først etter det blir dataene plassert på disken.
For det meste brukes asynkrone anrop. Dette gjør at klienten kan jobbe parallelt med ulike forespørsler. Du kan bruke den synkrone tilnærmingen, men den er mindre produktiv.
De to operasjonene vi snakket om er oppdatering/skriving, som endrer data. Disse er create, setData, sync, delete. Og les er eksisterer, getData, getChildren.
Nå noen eksempler på hvordan du kan lage primitiver for å jobbe i et distribuert system. For eksempel relatert til konfigurasjonen av noe. En ny arbeider har dukket opp. Vi la til maskinen og startet prosessen. Og det er følgende tre spørsmål. Hvordan spør den ZooKeeper for konfigurasjon? Og hvis vi ønsker å endre konfigurasjonen, hvordan endrer vi den? Og etter at vi endret det, hvordan får de arbeiderne vi hadde det?
ZooKeeper gjør dette relativt enkelt. For eksempel er det znode-treet vårt. Det er en node for applikasjonen vår her, vi lager en ekstra node i den, som inneholder data fra konfigurasjonen. Disse kan være separate parametere eller ikke. Siden størrelsen er liten, er konfigurasjonsstørrelsen vanligvis liten også, så det er fullt mulig å lagre den her.
Du bruker metoden getData for å hente konfigurasjonen for arbeideren fra noden. Sett til sann. Hvis denne noden av en eller annen grunn ikke eksisterer, vil vi bli informert om den når den dukker opp, eller når den endres. Hvis vi vil vite at noe har endret seg, så setter vi det til sant. Og hvis dataene i denne noden endres, vil vi vite om det.
SetData. Vi setter dataene, setter "-1", dvs. vi sjekker ikke versjonen, vi antar at vi alltid har en konfigurasjon, vi trenger ikke å lagre mange konfigurasjoner. Hvis du trenger å lagre mye, må du legge til et nytt nivå. Her tror vi at det bare er én, så vi oppdaterer kun den siste, så vi sjekker ikke versjonen. For øyeblikket mottar alle klienter som tidligere har abonnert et varsel om at noe har endret seg i denne noden. Og etter at de har fått det, må de også be om dataene på nytt. Varslingen er at de ikke mottar selve dataene, men kun melding om endringer. Etter dette må de be om nye data.
Det andre alternativet for å bruke det primitive er gruppemedlemskap. Vi har en distribuert applikasjon, det er en haug med arbeidere og vi ønsker å forstå at de alle er på plass. Derfor må de selv registrere at de jobber i vår søknad. Og vi ønsker også å finne ut, enten fra Master-prosessen eller et annet sted, om alle de aktive arbeiderne vi har for øyeblikket.
Hvordan gjør vi dette? For applikasjonen oppretter vi en arbeidernode og legger til et undernivå der ved å bruke opprettemetoden. Jeg har en feil på lysbildet. Her trenger du sekvensiell spesifisere, så vil alle arbeidere bli opprettet én etter én. Og applikasjonen, som ber om alle data om barna til denne noden, mottar alle de aktive arbeiderne som finnes.
Dette er en så forferdelig implementering av hvordan dette kan gjøres i Java-kode. La oss starte fra slutten, med hovedmetoden. Dette er vår klasse, la oss lage metoden. Som det første argumentet bruker vi vert, der vi kobler til, dvs. vi setter det som et argument. Og det andre argumentet er navnet på gruppen.
Hvordan skjer forbindelsen? Dette er et enkelt eksempel på API-en som brukes. Alt er relativt enkelt her. Det er en standardklasse ZooKeeper. Vi sender verter til det. Og sett tidsavbruddet, for eksempel, til 5 sekunder. Og vi har et medlem som heter connectedSignal. I hovedsak oppretter vi en gruppe langs den overførte banen. Vi skriver ikke data der, selv om noe kunne vært skrevet. Og noden her er av den vedvarende typen. I hovedsak er dette en vanlig vanlig node som vil eksistere hele tiden. Det er her økten opprettes. Dette er implementeringen av selve klienten. Vår klient vil sende periodiske meldinger som indikerer at økten er i live. Og når vi avslutter økten, ringer vi tett og det er det, økten faller av. Dette i tilfelle noe faller av for oss, slik at ZooKeeper finner ut av det og avbryter økten.
Hvordan låse en ressurs? Her er alt litt mer komplisert. Vi har et sett med arbeidere, det er en ressurs vi ønsker å låse. For å gjøre dette oppretter vi en egen node, for eksempel kalt lock1. Hvis vi klarte å lage den, så fikk vi en lås her. Og hvis vi ikke var i stand til å lage den, prøver arbeideren å hente data herfra, og siden noden allerede er opprettet, legger vi en overvåker her og i det øyeblikket tilstanden til denne noden endres, vil vi vite om det. Og vi kan prøve å ha tid til å gjenskape det. Hvis vi tok denne noden, tok denne låsen, så etter at vi ikke lenger trenger låsen, vil vi forlate den, siden noden bare eksisterer i økten. Følgelig vil den forsvinne. Og en annen klient, innenfor rammen av en annen økt, vil kunne ta låsen på denne noden, eller rettere sagt, han vil motta et varsel om at noe har endret seg og han kan prøve å gjøre det i tide.
Nok et eksempel på hvordan du kan velge hovedleder. Dette er litt mer komplisert, men også relativt enkelt. Hva foregår her? Det er en hovednode som samler alle arbeiderne. Vi prøver å få data om lederen. Hvis dette skjedde vellykket, det vil si at vi mottok noen data, begynner vår arbeider å følge denne lederen. Han mener at det allerede finnes en leder.
Hvis lederen døde av en eller annen grunn, for eksempel falt av, så prøver vi å skape en ny leder. Og hvis vi lykkes, blir vår arbeider leder. Og hvis noen i dette øyeblikket klarte å skape en ny leder, prøver vi å forstå hvem det er og deretter følge ham.
Her oppstår den såkalte flokkeffekten, altså flokkeffekten, for når en leder dør, vil den som er først i tid bli leder.
Når du fanger en ressurs, kan du prøve å bruke en litt annen tilnærming, som er som følger. For eksempel ønsker vi å få en lås, men uten hert-effekten. Det vil bestå i at vår applikasjon ber om lister over alle node-IDer for en allerede eksisterende node med lås. Og hvis noden som vi opprettet en lås for før det er den minste av settet vi mottok, betyr dette at vi har fanget låsen. Vi sjekker at vi har fått lås. Som en sjekk vil det være en forutsetning at id-en som vi mottok ved opprettelse av ny lås er minimal. Og hvis vi fikk det, så jobber vi videre.
Hvis det er en viss id som er mindre enn låsen vår, setter vi en overvåker på denne hendelsen og venter på varsling til noe endres. Det vil si at vi mottok denne låsen. Og inntil den faller av, vil vi ikke bli minimums-ID og vil ikke motta minimumslås, og dermed vil vi kunne logge inn. Og hvis denne betingelsen ikke er oppfylt, så går vi umiddelbart hit og prøver å få denne låsen igjen, fordi noe kan ha endret seg i løpet av denne tiden.
Hva består ZooKeeper av? Det er 4 hovedting. Dette er behandlingsprosesser - Forespørsel. Og også ZooKeeper Atomic Broadcast. Det er en Commit Log hvor alle operasjoner blir registrert. Og selve In-memory Replicated DB, dvs. selve databasen der hele dette treet er lagret.
Det er verdt å merke seg at alle skriveoperasjoner går gjennom forespørselsprosessoren. Og leseoperasjoner går direkte til In-memory-databasen.
Selve databasen er fullstendig replikert. Alle forekomster av ZooKeeper lagrer en fullstendig kopi av dataene.
For å gjenopprette databasen etter et krasj, er det en Commit-logg. Standard praksis er at før data kommer inn i minnet, skrives de der slik at hvis den krasjer, kan denne loggen spilles av og systemtilstanden kan gjenopprettes. Og periodiske øyeblikksbilder av databasen brukes også.
ZooKeeper Atomic Broadcast er en ting som brukes til å vedlikeholde replikerte data.
ZAB velger internt en leder fra ZooKeeper-nodens synspunkt. Andre noder blir hennes følgere og forventer noen handlinger fra henne. Hvis de mottar bidrag, sender de alle videre til lederen. Han utfører først en skriveoperasjon og sender deretter en melding om hva som har endret seg til følgerne hans. Dette må faktisk utføres atomisk, det vil si at opptaks- og kringkastingsoperasjonen av det hele må utføres atomisk, for derved å garantere datakonsistens.
Den behandler bare skriveforespørsler. Hovedoppgaven er at den forvandler operasjonen til en transaksjonsoppdatering. Dette er en spesielt generert forespørsel.
Og her er det verdt å merke seg at idempotensen til oppdateringer for samme operasjon er garantert. Hva det er? Denne tingen, hvis den utføres to ganger, vil ha samme tilstand, det vil si at selve forespørselen ikke endres. Og dette må gjøres slik at du i tilfelle krasj kan starte operasjonen på nytt, og dermed rulle tilbake endringene som har falt av for øyeblikket. I dette tilfellet vil tilstanden til systemet bli den samme, dvs. det skal ikke være slik at en serie av de samme, for eksempel oppdateringsprosesser, førte til forskjellige slutttilstander i systemet.
Kilde: www.habr.com
