Jeg foreslår, at du læser udskriften af foredraget "Hadoop. ZooKeeper" fra serien "Metoder til distribueret behandling af store datamængder i Hadoop"
Hvad er ZooKeeper, dens plads i Hadoop-økosystemet. Usandheder om distribueret databehandling. Diagram over et standarddistribueret system. Svært ved at koordinere distribuerede systemer. Typiske koordinationsproblemer. Principperne bag designet af ZooKeeper. ZooKeeper datamodel. znode flag. Sessioner. Client API. Primitiver (konfiguration, gruppemedlemskab, simple låse, ledervalg, låsning uden flokeffekt). ZooKeeper arkitektur. ZooKeeper DB. ZAB. Request handler.
I dag vil vi tale om ZooKeeper. Denne ting er meget nyttig. Det har, som ethvert Apache Hadoop-produkt, et logo. Den forestiller en mand.
Før dette talte vi hovedsageligt om, hvordan data kan behandles der, hvordan man gemmer det, det vil sige hvordan man bruger det på en eller anden måde og arbejder med det på en eller anden måde. Og i dag vil jeg gerne tale lidt om at bygge distribuerede applikationer. Og ZooKeeper er en af de ting, der giver dig mulighed for at forenkle denne sag. Dette er en slags service, der er beregnet til en form for koordinering af samspillet mellem processer i distribuerede systemer, i distribuerede applikationer.
Behovet for sådanne applikationer bliver mere og mere hver dag, det er det, vores kursus handler om. På den ene side giver MapReduce og dette færdige framework dig mulighed for at udjævne denne kompleksitet og frigøre programmøren fra at skrive primitiver såsom interaktion og koordinering af processer. Men på den anden side er der ingen, der garanterer, at det alligevel ikke skal gøres. MapReduce eller andre færdige rammer erstatter ikke altid helt nogle sager, som ikke kan implementeres ved hjælp af dette. Herunder MapReduce sig selv og en masse andre Apache-projekter; de er faktisk også distribuerede applikationer. Og for at gøre det lettere at skrive, skrev de ZooKeeper.
Som alle Hadoop-relaterede applikationer blev den udviklet af Yahoo! Det er nu også en officiel Apache-applikation. Det er ikke så aktivt udviklet som HBase. Hvis du går til JIRA HBase, så er der hver dag en masse fejlrapporter, en masse forslag til at optimere noget, altså livet i projektet er konstant i gang. Og ZooKeeper er på den ene side et relativt simpelt produkt, og på den anden side sikrer det pålideligheden. Og det er ret nemt at bruge, hvorfor det er blevet en standard i applikationer inden for Hadoop-økosystemet. Så jeg tænkte, at det ville være nyttigt at gennemgå det for at forstå, hvordan det virker, og hvordan man bruger det.
Dette er et billede fra et foredrag, vi havde. Vi kan sige, at det er ortogonalt i forhold til alt, hvad vi har overvejet indtil nu. Og alt, hvad der er angivet her, fungerer i en eller anden grad med ZooKeeper, dvs. det er en tjeneste, der bruger alle disse produkter. Hverken HDFS eller MapReduce skriver deres egne lignende tjenester, der specifikt ville fungere for dem. Derfor bruges ZooKeeper. Og dette forenkler udvikling og nogle ting relateret til fejl.
Hvor kommer alt dette fra? Det ser ud til, at vi lancerede to applikationer parallelt på forskellige computere, forbundet dem med en streng eller i et mesh, og alt fungerer. Men problemet er, at netværket er upålideligt, og hvis du snusede til trafikken eller kiggede på, hvad der sker der på et lavt niveau, hvordan klienter interagerer på netværket, kan du ofte se, at nogle pakker går tabt eller sendes igen. Det er ikke for ingenting, at TCP-protokoller blev opfundet, som giver dig mulighed for at etablere en bestemt session og garantere levering af meddelelser. Men under alle omstændigheder kan selv TCP ikke altid redde dig. Alt har en timeout. Netværket kan simpelthen falde af i et stykke tid. Den blinker måske bare. Og alt dette fører til, at du ikke kan stole på, at netværket er pålideligt. Dette er den største forskel fra at skrive parallelle applikationer, der kører på én computer eller på én supercomputer, hvor der ikke er noget netværk, hvor der er en mere pålidelig dataudvekslingsbus i hukommelsen. Og dette er en grundlæggende forskel.
Blandt andet ved brug af Netværket er der altid en vis latency. Disken har det også, men netværket har mere af det. Latency er en vis forsinkelsestid, som enten kan være lille eller ret betydelig.
Netværkstopologien ændrer sig. Hvad er topologi - dette er placeringen af vores netværksudstyr. Der er datacentre, der er stativer, der står der, der er stearinlys. Alt dette kan genkobles, flyttes osv. Alt dette skal også tages i betragtning. IP-navne ændres, den routing, som vores trafik rejser igennem, ændres. Dette skal også tages i betragtning.
Netværket kan også ændre sig med hensyn til udstyr. Fra praksis kan jeg sige, at vores netværksingeniører virkelig godt kan lide at opdatere noget på stearinlysene med jævne mellemrum. Pludselig kom der en ny firmware ud, og de var ikke specielt interesserede i en eller anden Hadoop-klynge. De har deres eget arbejde. For dem er det vigtigste, at netværket fungerer. Derfor vil de gen-uploade noget der, lave et blink på deres hardware, og hardwaren ændres også med jævne mellemrum. Alt dette skal på en eller anden måde tages i betragtning. Alt dette påvirker vores distribuerede applikation.
Normalt tror folk, der begynder at arbejde med store mængder data af en eller anden grund, at internettet er ubegrænset. Hvis der er en fil på flere terabyte der, så kan du tage den til din server eller computer og åbne den vha hvordan og se. Endnu en fejl er inde vim se på loggene. Gør aldrig dette, fordi det er dårligt. Fordi Vim forsøger at buffere alt, skal du indlæse alt i hukommelsen, især når vi begynder at bevæge os gennem denne log og lede efter noget. Det er ting, der er glemt, men værd at overveje.
Det er nemmere at skrive ét program, der kører på én computer med én processor.
Når vores system vokser, ønsker vi at parallelisere det hele og parallelisere det ikke kun på en computer, men også på en klynge. Spørgsmålet opstår: hvordan koordinerer man denne sag? Vores applikationer interagerer måske ikke engang med hinanden, men vi kørte flere processer parallelt på flere servere. Og hvordan overvåger man, at alt går godt for dem? For eksempel sender de noget over internettet. De skal skrive om deres tilstand et eller andet sted, for eksempel i en form for database eller log, derefter aggregere denne log og derefter analysere den et sted. Plus, vi skal tage højde for, at processen fungerede og fungerede, pludselig dukkede en fejl op i den, eller den styrtede ned, hvor hurtigt vil vi så finde ud af det?
Det er klart, at alt dette hurtigt kan overvåges. Dette er også godt, men overvågning er en begrænset ting, der giver dig mulighed for at overvåge nogle ting på højeste niveau.
Når vi ønsker, at vores processer begynder at interagere med hinanden, for eksempel for at sende hinanden nogle data, så melder spørgsmålet sig også – hvordan vil det ske? Vil der være en form for racetilstand, vil de overskrive hinanden, kommer dataene korrekt, vil der gå noget tabt undervejs? Vi skal udvikle en form for protokol osv.
Koordinering af alle disse processer er ikke en triviel ting. Og det tvinger udvikleren til at gå ned på et endnu lavere niveau, og skrive systemer enten fra bunden, eller ikke helt fra bunden, men det er ikke så enkelt.
Hvis du kommer med en kryptografisk algoritme eller endda implementerer den, så smid den væk med det samme, for højst sandsynligt vil den ikke fungere for dig. Det vil højst sandsynligt indeholde en masse fejl, som du har glemt at sørge for. Brug det aldrig til noget alvorligt, da det højst sandsynligt vil være ustabilt. Fordi alle de algoritmer, der findes, er blevet testet af tiden i meget lang tid. Det er aflyttet af samfundet. Dette er et særskilt emne. Og det er det samme her. Hvis det er muligt ikke at implementere en form for processynkronisering selv, så er det bedre ikke at gøre dette, fordi det er ret kompliceret og fører dig ned ad den vaklende vej med konstant at søge efter fejl.
I dag taler vi om ZooKeeper. På den ene side er det en ramme, på den anden side er det en service, der gør livet lettere for udvikleren og forenkler implementeringen af logik og koordinering af vores processer mest muligt.
Lad os huske, hvordan et standarddistribueret system kan se ud. Dette er, hvad vi talte om - HDFS, HBase. Der er en Master-proces, der styrer arbejdere og slaveprocesser. Han er ansvarlig for at koordinere og fordele opgaver, genstarte arbejdere, lancere nye og fordele belastningen.
En mere avanceret ting er Koordinationstjenesten, det vil sige flytte selve koordinationsopgaven ind i en separat proces, plus køre en form for backup eller standby Master parallelt, fordi Masteren kan fejle. Og hvis Mesteren falder, så vil vores system ikke fungere. Vi kører backup. Nogle angiver, at masteren skal replikeres til backup. Dette kan også overlades til Koordinationstjenesten. Men i dette diagram er Mesteren selv ansvarlig for at koordinere arbejderne; her koordinerer tjenesten datareplikeringsaktiviteter.
En mere avanceret mulighed er, når al koordinering varetages af vores service, som man normalt gør. Han tager ansvar for, at alt fungerer. Og hvis noget ikke virker, finder vi ud af det og forsøger at omgå denne situation. Under alle omstændigheder står vi tilbage med en Mester, som på en eller anden måde interagerer med slaver og kan sende data, information, beskeder osv. gennem en eller anden tjeneste.
Der er en endnu mere avanceret ordning, når vi ikke har en Master, er alle noder masterslaver, forskellige i deres adfærd. Men de mangler stadig at interagere med hinanden, så der er stadig noget service tilbage til at koordinere disse handlinger. Sandsynligvis passer Cassandra, som arbejder efter dette princip, denne ordning.
Det er svært at sige, hvilken af disse ordninger der fungerer bedst. Hver har sine egne fordele og ulemper.
Og der er ingen grund til at være bange for nogle ting med Mesteren, for som praksis viser, er han ikke så modtagelig for konstant at tjene. Det vigtigste her er at vælge den rigtige løsning til at hoste denne tjeneste på en separat kraftfuld node, så den har nok ressourcer, så brugerne om muligt ikke har adgang der, så de ikke ved et uheld dræber denne proces. Men samtidig er det i en sådan ordning meget lettere at styre arbejdere fra Master-processen, det vil sige, at denne ordning er enklere ud fra et implementeringssynspunkt.
Og denne ordning (ovenfor) er sandsynligvis mere kompleks, men mere pålidelig.
Hovedproblemet er delvise fejl. For eksempel, når vi sender en besked over netværket, sker der en slags ulykke, og den, der har sendt beskeden, vil ikke vide, om hans besked blev modtaget, og hvad der skete på modtagerens side, vil ikke vide, om beskeden blev behandlet korrekt , dvs. han vil ikke modtage nogen bekræftelse.
Derfor skal vi behandle denne situation. Og det enkleste er at sende denne besked igen og vente, indtil vi modtager et svar. I dette tilfælde tages der ikke højde for, om modtagerens tilstand er ændret. Vi kan sende en besked og tilføje de samme data to gange.
ZooKeeper tilbyder måder at håndtere sådanne afslag på, hvilket også gør vores liv lettere.
Som nævnt lidt tidligere, ligner dette at skrive multi-threaded programmer, men den største forskel er, at i distribuerede applikationer, som vi bygger på forskellige maskiner, er den eneste måde at kommunikere på netværket. I det væsentlige er dette en delt-intet-arkitektur. Hver proces eller tjeneste, der kører på én maskine, har sin egen hukommelse, sin egen disk, sin egen processor, som den ikke deler med nogen.
Hvis vi skriver et multi-threaded program på én computer, så kan vi bruge delt hukommelse til at udveksle data. Vi har et kontekstskifte der, processer kan skifte. Dette påvirker ydeevnen. På den ene side er der ikke sådan noget i programmet på en klynge, men der er problemer med Netværket.
Følgelig er de vigtigste problemer, der opstår, når man skriver distribuerede systemer, konfiguration. Vi skriver en form for ansøgning. Hvis det er simpelt, så hardkoder vi alle mulige tal i koden, men det er ubelejligt, for hvis vi beslutter, at vi i stedet for en timeout på et halvt sekund vil have en timeout på et sekund, så skal vi omkompilere applikationen og rulle alt ud igen. Det er én ting, når det er på én maskine, når du bare kan genstarte det, men når vi har mange maskiner, skal vi hele tiden kopiere alt. Vi skal forsøge at gøre applikationen konfigurerbar.
Her taler vi om statisk konfiguration for systemprocesser. Dette er ikke helt, måske set fra operativsystemets synspunkt, det kan være en statisk konfiguration for vores processer, det vil sige, dette er en konfiguration, der ikke bare kan tages og opdateres.
Der er også en dynamisk konfiguration. Det er de parametre, som vi vil ændre i farten, så de bliver samlet op der.
Hvad er problemet her? Vi opdaterede konfigurationen, rullede den ud, hvad så? Problemet kan være, at vi på den ene side rullede konfigurationen ud, men glemte den nye ting, konfigurationen forblev der. For det andet, mens vi rullede ud, blev konfigurationen opdateret nogle steder, men ikke andre. Og nogle processer i vores applikation, der kører på én maskine, blev genstartet med en ny konfiguration og et eller andet sted med en gammel. Dette kan resultere i, at vores distribuerede applikation er inkonsekvent fra et konfigurationsperspektiv. Dette problem er almindeligt. For en dynamisk konfiguration er det mere relevant, fordi det indebærer, at det kan ændres med det samme.
Et andet problem er gruppemedlemskab. Vi har altid et sæt arbejdere, vi vil altid gerne vide, hvem af dem der er i live, hvem af dem der er død. Hvis der er en Master, så skal han forstå, hvilke arbejdere der kan omdirigeres til klienter, så de kører beregninger eller arbejder med data, og hvilke der ikke kan. Et problem, der hele tiden opstår, er, at vi skal vide, hvem der arbejder i vores klynge.
Et andet typisk problem er ledervalg, når vi gerne vil vide, hvem der har ansvaret. Et eksempel er replikering, når vi har en proces, der modtager skriveoperationer og derefter replikerer dem blandt andre processer. Han vil være lederen, alle andre vil adlyde ham, vil følge ham. Det er nødvendigt at vælge en proces, så den er entydig for alle, så det ikke viser sig, at der udvælges to ledere.
Der er også gensidigt udelukkende adgang. Problemet her er mere komplekst. Der er sådan noget som en mutex, når du skriver flertrådede programmer og ønsker, at adgang til en eller anden ressource, for eksempel en hukommelsescelle, skal begrænses og udføres af kun én tråd. Her kunne ressourcen være noget mere abstrakt. Og forskellige applikationer fra forskellige noder i vores netværk bør kun få eksklusiv adgang til en given ressource, og ikke så alle kan ændre den eller skrive noget der. Det er de såkaldte låse.
ZooKeeper giver dig mulighed for at løse alle disse problemer i en eller anden grad. Og jeg vil vise med eksempler, hvordan det giver dig mulighed for at gøre dette.
Der er ingen blokerende primitiver. Når vi begynder at bruge noget, vil denne primitive ikke vente på, at nogen begivenhed indtræffer. Mest sandsynligt vil denne ting fungere asynkront, og derved tillade processer ikke at hænge, mens de venter på noget. Dette er en meget nyttig ting.
Alle klientanmodninger behandles i rækkefølgen af den generelle kø.
Og klienter har mulighed for at modtage besked om ændringer i en eller anden tilstand, om ændringer i data, før klienten selv ser de ændrede data.
ZooKeeper kan arbejde i to tilstande. Den første er selvstændig på én node. Dette er praktisk til test. Den kan også fungere i klyngetilstand på et vilkårligt antal servere. Hvis vi har en klynge på 100 maskiner, så er det ikke nødvendigt, at det fungerer på 100 maskiner. Det er nok at vælge flere maskiner, hvor du kan køre ZooKeeper. Og den bekender sig til princippet om høj tilgængelighed. På hver kørende forekomst gemmer ZooKeeper en hel kopi af dataene. Senere vil jeg fortælle dig, hvordan han gør det. Det sønderdeler eller partitionerer ikke data. På den ene side er det et minus, at vi ikke kan opbevare meget, på den anden side er der ingen grund til at gøre dette. Det er ikke det, det er designet til, det er ikke en database.
Data kan cachelagres på klientsiden. Dette er et standardprincip, så vi ikke afbryder tjenesten og ikke indlæser den med de samme anmodninger. En smart klient ved normalt om dette og cacher det.
For eksempel har noget ændret sig her. Der er en form for ansøgning. Der blev valgt en ny leder, som blandt andet er ansvarlig for at behandle skriveoperationer. Og vi ønsker at replikere dataene. En løsning er at sætte det i en løkke. Og vi sætter hele tiden spørgsmålstegn ved vores service – har noget ændret sig? Den anden mulighed er mere optimal. Dette er en urmekanisme, der giver dig mulighed for at underrette klienter om, at noget har ændret sig. Dette er en billigere metode med hensyn til ressourcer og mere bekvem for kunderne.
Klienten er den bruger, der bruger ZooKeeper.
Server er selve ZooKeeper-processen.
Znode er nøglen i ZooKeeper. Alle znoder gemmes i hukommelsen af ZooKeeper og er organiseret i form af et hierarkisk diagram i form af et træ.
Der er to typer operationer. Den første er opdatering/skriv, når en eller anden handling ændrer tilstanden af vores træ. Træet er almindeligt.
Og det er muligt, at klienten ikke fuldfører én anmodning og bliver afbrudt, men kan etablere en session, hvorigennem den interagerer med ZooKeeper.
ZooKeepers datamodel ligner et filsystem. Der er en standardrod, og så gik vi som om gennem de mapper, der går fra roden. Og så kataloget på første niveau, andet niveau. Dette er alle znodes.
Hver znode kan gemme nogle data, normalt ikke særlig store, for eksempel 10 kilobyte. Og hver znode kan have et vist antal børn.
Znoder findes i flere typer. De kan skabes. Og når vi opretter en znode, angiver vi typen, som den skal tilhøre.
Der er to typer. Den første er det flygtige flag. Znode lever inden for en session. For eksempel har klienten etableret en session. Og så længe denne session er i live, vil den eksistere. Dette er nødvendigt for ikke at producere noget unødvendigt. Dette er også velegnet til øjeblikke, hvor det er vigtigt for os at gemme dataprimitiver i en session.
Den anden type er sekventielt flag. Den øger tælleren på vej til znoden. For eksempel havde vi en mappe med applikation 1_5. Og da vi oprettede den første node, modtog den p_1, den anden - p_2. Og når vi kalder denne metode hver gang, passerer vi den fulde sti, hvilket kun angiver en del af stien, og dette tal øges automatisk, fordi vi angiver nodetypen - sekventiel.
Almindelig znode. Hun vil altid leve og have det navn, som vi fortæller hende.
En anden nyttig ting er urflaget. Hvis vi installerer det, så kan klienten abonnere på nogle begivenheder for en specifik node. Jeg viser dig senere med et eksempel, hvordan dette gøres. ZooKeeper giver selv besked til klienten om, at dataene på noden er ændret. Notifikationer garanterer dog ikke, at nogle nye data er ankommet. De siger blot, at noget har ændret sig, så du skal stadig sammenligne data senere med separate opkald.
Og som jeg allerede har sagt, er rækkefølgen af data bestemt af kilobytes. Der er ingen grund til at gemme store tekstdata der, fordi det ikke er en database, det er en handlingskoordinationsserver.
Jeg vil fortælle dig lidt om sessionerne. Hvis vi har flere servere, kan vi gennemsigtigt flytte fra server til server ved hjælp af sessionsidentifikatoren. Det er ret praktisk.
Hver session har en form for timeout. En session er defineret ved, om klienten sender noget til serveren under den pågældende session. Hvis han ikke sendte noget under timeoutet, falder sessionen af, eller klienten kan selv lukke den.
Den har ikke så mange funktioner, men du kan gøre forskellige ting med denne API. Det opkald, vi så oprette, skaber en znode og tager tre parametre. Dette er stien til znoden, og den skal angives fuldt ud fra roden. Og det er også nogle data, som vi vil overføre dertil. Og flagtypen. Og efter oprettelsen returnerer den stien til znoden.
For det andet kan du slette det. Tricket her er, at den anden parameter, udover stien til znoden, kan angive versionen. Følgelig vil denne znode blive slettet, hvis dens version, som vi har overført, svarer til den, der faktisk eksisterer.
Hvis vi ikke ønsker at kontrollere denne version, så sender vi simpelthen "-1"-argumentet.
For det tredje kontrollerer den for eksistensen af en znode. Returnerer sand, hvis noden eksisterer, ellers falsk.
Og så vises flag watch, som giver dig mulighed for at overvåge denne node.
Du kan indstille dette flag selv på en ikke-eksisterende node og modtage en meddelelse, når den vises. Dette kan også være nyttigt.
Der er et par udfordringer mere getData. Det er klart, at vi kan modtage data via znode. Du kan også bruge flagur. I dette tilfælde vil den ikke installere, hvis der ikke er nogen node. Derfor skal du forstå, at det eksisterer, og derefter modtage data.
Der er også Indstil Data. Her sender vi version. Og hvis vi overfører dette, vil dataene på znoden af en bestemt version blive opdateret.
Du kan også angive "-1" for at udelukke denne kontrol.
En anden nyttig metode er fåBørn. Vi kan også få en liste over alle znoder, der hører til den. Vi kan overvåge dette ved at indstille flagvagt.
Og metode synkronisere tillader, at alle ændringer sendes på én gang, og derved sikres, at de gemmes, og alle data er blevet fuldstændig ændret.
Hvis vi tegner analogier med almindelig programmering, så er der ingen garanti for, at du har skrevet data til disk, når du bruger metoder som at skrive, som skriver noget til disken, og efter at det returnerer et svar til dig. Og selv når styresystemet er overbevist om, at alt er blevet skrevet, er der mekanismer i selve disken, hvor processen går gennem lag af buffere, og først derefter placeres dataene på disken.
For det meste bruges asynkrone opkald. Dette giver klienten mulighed for at arbejde parallelt med forskellige ønsker. Du kan bruge den synkrone tilgang, men den er mindre produktiv.
De to operationer vi talte om er update/write, som ændrer data. Disse er create, setData, sync, delete. Og læs er eksisterer, getData, getChildren.
Nu et par eksempler på, hvordan du kan lave primitiver til at arbejde i et distribueret system. For eksempel relateret til konfigurationen af noget. En ny arbejder er dukket op. Vi tilføjede maskinen og startede processen. Og der er følgende tre spørgsmål. Hvordan forespørger det ZooKeeper om konfiguration? Og hvis vi vil ændre konfigurationen, hvordan ændrer vi den så? Og efter at vi har ændret det, hvordan får de arbejdere, vi havde, det?
ZooKeeper gør dette relativt nemt. For eksempel er der vores znode træ. Der er en node til vores applikation her, vi opretter en ekstra node i den, som indeholder data fra konfigurationen. Disse kan være separate parametre eller ikke. Da størrelsen er lille, er konfigurationsstørrelsen normalt også lille, så det er meget muligt at gemme det her.
Du bruger metoden getData for at hente konfigurationen for arbejderen fra noden. Indstil til sand. Hvis denne node af en eller anden grund ikke eksisterer, vil vi blive informeret om den, når den dukker op, eller når den ændres. Hvis vi vil vide, at noget har ændret sig, så sætter vi det til sandt. Og hvis dataene i denne node ændres, vil vi vide om det.
Indstil Data. Vi sætter dataene, sætter "-1", dvs. vi tjekker ikke versionen, vi antager, at vi altid har en konfiguration, vi behøver ikke at gemme mange konfigurationer. Hvis du skal gemme meget, skal du tilføje et andet niveau. Her mener vi, at der kun er én, så vi opdaterer kun den seneste, så vi tjekker ikke versionen. I øjeblikket modtager alle kunder, der tidligere har abonneret, en meddelelse om, at noget er ændret i denne node. Og efter de har modtaget dem, skal de også efterspørge dataene igen. Meddelelsen er, at de ikke modtager selve data, men kun besked om ændringer. Herefter skal de bede om nye data.
Den anden mulighed for at bruge det primitive er gruppemedlemskab. Vi har en distribueret applikation, der er en flok arbejdere, og vi vil gerne forstå, at de alle er på plads. Derfor skal de selv registrere, at de arbejder i vores ansøgning. Og vi ønsker også at finde ud af, enten fra Master-processen eller et andet sted, om alle de aktive arbejdere, som vi har i øjeblikket.
Hvordan gør vi dette? Til applikationen opretter vi en arbejderknude og tilføjer et underniveau der ved hjælp af oprettelsesmetoden. Jeg har en fejl på sliden. Her har du brug for sekventiel specificer, så bliver alle arbejdere oprettet én efter én. Og applikationen, der anmoder om alle data om børnene i denne node, modtager alle de aktive arbejdere, der findes.
Dette er sådan en forfærdelig implementering af, hvordan dette kan gøres i Java-kode. Lad os starte fra slutningen med hovedmetoden. Dette er vores klasse, lad os skabe dens metode. Som det første argument bruger vi vært, hvor vi forbinder, dvs. vi sætter det som et argument. Og det andet argument er navnet på gruppen.
Hvordan sker forbindelsen? Dette er et simpelt eksempel på den API, der bruges. Alt er relativt enkelt her. Der er en standardklasse ZooKeeper. Vi sender værter til det. Og indstil fx timeout til 5 sekunder. Og vi har et medlem, der hedder connectedSignal. I det væsentlige opretter vi en gruppe langs den overførte vej. Vi skriver ikke data der, selvom der kunne være skrevet noget. Og noden her er af den vedvarende type. I det væsentlige er dette en almindelig regulær node, der vil eksistere hele tiden. Det er her sessionen oprettes. Dette er implementeringen af klienten selv. Vores klient sender periodiske beskeder, der indikerer, at sessionen er i live. Og når vi afslutter sessionen, ringer vi tæt, og det er det, sessionen falder af. Dette er i tilfælde af, at noget falder af for os, så ZooKeeper finder ud af det og afbryder sessionen.
Hvordan låser man en ressource? Her er alt lidt mere kompliceret. Vi har et sæt arbejdere, der er en eller anden ressource, som vi vil låse. For at gøre dette opretter vi en separat node, for eksempel kaldet lock1. Hvis vi var i stand til at skabe det, så fik vi en lås her. Og hvis vi ikke var i stand til at oprette det, så forsøger arbejderen at hente data herfra, og da noden allerede er blevet oprettet, sætter vi en overvåger her, og i det øjeblik denne nodes tilstand ændres, vil vi vide om det. Og vi kan prøve at få tid til at genskabe det. Hvis vi tog denne node, tog denne lås, så efter vi ikke længere har brug for låsen, vil vi opgive den, da noden kun eksisterer i sessionen. Derfor vil den forsvinde. Og en anden klient, inden for rammerne af en anden session, vil være i stand til at tage låsen på denne node, eller rettere, han vil modtage en meddelelse om, at noget er ændret, og han kan prøve at gøre det i tide.
Endnu et eksempel på, hvordan du kan vælge hovedlederen. Dette er lidt mere kompliceret, men også relativt enkelt. Hvad sker der her? Der er en hovedknude, der samler alle arbejderne. Vi forsøger at få data om lederen. Hvis dette skete med succes, dvs. vi modtog nogle data, så begynder vores medarbejder at følge denne leder. Han mener, at der allerede er en leder.
Hvis lederen døde af en eller anden grund, for eksempel faldt fra, så forsøger vi at skabe en ny leder. Og hvis det lykkes, så bliver vores arbejder lederen. Og hvis nogen i dette øjeblik formåede at skabe en ny leder, så forsøger vi at forstå, hvem det er og derefter følge ham.
Her opstår den såkaldte flokeffekt, altså flokeffekten, for når en leder dør, bliver den, der er først i tiden, lederen.
Når du fanger en ressource, kan du prøve at bruge en lidt anden tilgang, som er som følger. For eksempel ønsker vi at få en lås, men uden hert-effekten. Det vil bestå i, at vores applikation anmoder om lister over alle node-id'er for en allerede eksisterende node med lås. Og hvis før det noden, som vi oprettede en lås til, er den mindste af det sæt, vi modtog, betyder det, at vi har fanget låsen. Vi tjekker, at vi har modtaget en lås. Som en kontrol vil der være en betingelse om, at det id, som vi modtog ved oprettelse af en ny lås, er minimal. Og hvis vi modtog det, så arbejder vi videre.
Hvis der er et bestemt id, der er mindre end vores lås, så sætter vi en watcher på denne begivenhed og venter på besked, indtil noget ændrer sig. Det vil sige, at vi modtog denne lås. Og indtil den falder af, bliver vi ikke minimums-id og modtager ikke minimumslåsen, og dermed vil vi kunne logge ind. Og hvis denne betingelse ikke er opfyldt, så går vi med det samme her og forsøger at få denne lås igen, for noget kan have ændret sig i løbet af denne tid.
Hvad består ZooKeeper af? Der er 4 hovedting. Dette er behandlingsprocesser - Anmodning. Og også ZooKeeper Atomic Broadcast. Der er en Commit Log, hvor alle operationer registreres. Og selve In-memory Replicated DB, dvs. selve databasen, hvor hele dette træ er gemt.
Det er værd at bemærke, at alle skriveoperationer går gennem Request Processor. Og læseoperationer går direkte til In-memory-databasen.
Selve databasen er fuldt replikeret. Alle forekomster af ZooKeeper gemmer en komplet kopi af dataene.
For at gendanne databasen efter et nedbrud er der en Commit-log. Standardpraksis er, at før data kommer ind i hukommelsen, bliver de skrevet der, så hvis den går ned, kan denne log afspilles, og systemtilstanden kan gendannes. Og der bruges også periodiske snapshots af databasen.
ZooKeeper Atomic Broadcast er en ting, der bruges til at vedligeholde replikerede data.
ZAB vælger internt en leder fra ZooKeeper-knudepunktets synspunkt. Andre noder bliver hendes følgere og forventer nogle handlinger fra hende. Hvis de modtager bidrag, sender de dem alle videre til lederen. Han udfører først en skriveoperation og sender derefter en besked om, hvad der er ændret, til hans følgere. Dette skal faktisk udføres atomisk, dvs. optagelsen og udsendelsen af det hele skal udføres atomisk, og derved garantere datakonsistens.
Den behandler kun skriveanmodninger. Dens hovedopgave er, at den omdanner operationen til en transaktionsopdatering. Dette er en specielt genereret anmodning.
Og her er det værd at bemærke, at idempotensen af opdateringer til den samme operation er garanteret. Hvad er det? Denne ting, hvis den udføres to gange, vil have den samme tilstand, dvs. selve anmodningen ændres ikke. Og dette skal gøres, så du i tilfælde af et nedbrud kan genstarte operationen og derved rulle de ændringer tilbage, der er faldet af i øjeblikket. I dette tilfælde vil systemets tilstand blive den samme, dvs. det bør ikke være sådan, at en række af de samme, for eksempel opdateringsprocesser, førte til forskellige sluttilstande af systemet.
Kilde: www.habr.com