"Hadoop. ZooKeeper" från Mail.Ru Group Technostream-serien "Metoder för distribuerad bearbetning av stora datamängder i Hadoop"

Jag föreslår att du läser utskriften av föreläsningen "Hadoop. ZooKeeper" från serien "Metoder för distribuerad bearbetning av stora datamängder i Hadoop"

Vad är ZooKeeper, dess plats i Hadoops ekosystem. Lögner om distribuerad datoranvändning. Diagram över ett standarddistribuerat system. Komplexiteten i att samordna distribuerade system. Typiska koordinationsproblem. Principerna bakom designen av ZooKeeper. ZooKeeper datamodell. Znode flaggor. Sessioner. Klient-API. Primitiver (konfiguration, gruppmedlemskap, enkla låsningar, ledareval, låsning utan flockeffekt). ZooKeeper-arkitektur. ZooKeeper DB. ZAB. Begär hanterare.

Idag ska vi prata om ZooKeeper. Den här saken är väldigt användbar. Den, som alla Apache Hadoop-produkter, har en logotyp. Den föreställer en man.

Innan detta pratade vi främst om hur data kan behandlas där, hur man lagrar den, dvs hur man använder den på något sätt och arbetar med den på något sätt. Idag skulle jag vilja prata lite om att bygga distribuerade applikationer. Och ZooKeeper är en av de saker som gör detta enklare. Detta är en viss tjänst som är avsedd för viss samordning av interaktion mellan processer i distribuerade system, i distribuerade applikationer.

Behovet av sådana applikationer blir mer och mer för varje dag, det är vad vår kurs handlar om. Å ena sidan tillåter MapReduce och detta färdiga ramverk oss att utjämna denna komplexitet och befria programmeraren från att skriva primitiver som interaktion och processkoordination. Men å andra sidan är det ingen som garanterar att detta inte kommer att behöva göras ändå. MapReduce eller andra färdiga ramverk ersätter inte alltid helt vissa fall som inte kan implementeras på denna. Inklusive MapReduce sig själv och ett gäng andra Apache-projekt, de är i själva verket också distribuerade applikationer. Och för att göra skrivandet lättare skrev vi ZooKeeper.

Liksom alla Hadoop-relaterade applikationer utvecklades den på Yahoo! Det är nu också en officiell Apache-applikation. Den är inte lika aktivt utvecklad som HBase. Om du går till JIRA HBase, så finns det varje dag ett gäng uppgifter för buggar, en massa förslag på att optimera något, d.v.s. livet pågår ständigt i projektet. Och ZooKeeper, å ena sidan, är en relativt enkel produkt, och å andra sidan säkerställer detta dess tillförlitlighet. Och det är ganska lätt att använda, så det har blivit en standard i applikationer inom Hadoop-ekosystemet. Så jag tänkte att det kunde vara användbart att ta en titt på det för att förstå hur det fungerar och hur man använder det.

Det här är en bild från någon föreläsning vi hade. Vi kan säga att det är ortogonalt mot allt som vi har övervägt hittills. Och allt som listas här fungerar i en eller annan grad med ZooKeeper, det vill säga det är en tjänst som använder alla dessa produkter. Varken HDFS eller MapReduce skriver sina egna liknande tjänster som skulle fungera specifikt för dem. Därför används ZooKeeper. Och detta förenklar utvecklingen och vissa saker relaterade till fel.

Var kommer allt detta ifrån? Det verkar som att du startade två applikationer parallellt på olika datorer, kopplade dem med en kabel eller ett nätverk, och allt fungerar. Men problemet är att nätverket är opålitligt, och om du sniffade trafiken eller tittade på vad som hände på en låg nivå, hur klienter interagerade på nätverket, kunde du ofta se att vissa paket gick förlorade, och att du illa upp. Det är inte för inte som TCP-protokoll uppfanns, som låter dig upprätta en viss session och garantera leverans av meddelanden. Men i alla fall kan inte ens TCP alltid rädda dagen. Allt har en timeout. Nätverket kan helt enkelt gå ner ett tag. Det kanske bara blinkar. Och allt detta leder till det faktum att du inte kan lita på att nätverket är pålitligt. Detta är den största skillnaden från att skriva parallella applikationer som körs på en enda dator eller på en enda superdator, där det inte finns något nätverk, där det finns en mer tillförlitlig datautbytesbuss i minnet. Och detta är en grundläggande skillnad.

Dessutom, när du använder Internet, finns det alltid en viss latens. Disken har det också, men nätverket har mer. Latens är en viss fördröjningstid, som kan vara antingen liten eller ganska betydande.

Nätverkstopologin förändras. Vad är topologi - det är placeringen av vår nätverksutrustning. Det finns datacenter, det finns ställ som finns där, det finns ljus. Allt detta kan återanslutas, flyttas etc. Allt detta måste också tas med i beräkningen. IP-adresser förändras, routingen genom vilken vår trafik strömmar förändras. Detta måste också beaktas.

Nätverket kan också förändras vad gäller utrustning. Av min erfarenhet kan jag säga att våra nätverksingenjörer verkligen gillar att med jämna mellanrum uppdatera något på ljusen. Plötsligt kommer en ny firmware ut och de bryr sig inte riktigt om något Hadoop-kluster. De har ett eget jobb. Huvudsaken för dem är att nätverket fungerar. Följaktligen vill de ladda upp något där igen, ladda upp det på sin hårdvara, medan hårdvaran också ändras med jämna mellanrum. Allt detta måste tas i beaktande på något sätt. Allt detta påverkar vår distribuerade applikation.

Vanligtvis tror människor som börjar arbeta med stora mängder data, av någon anledning, att nätverket är obegränsat. Om det finns en fil på flera terabyte där kan du ta den till din server eller dator och öppna den med hjälp av hur och titta. Ett annat misstag är inne vim visa loggar. Gör aldrig detta för det är dåligt. Eftersom Vim försöker buffra allt, ladda allt i minnet, speciellt när vi börjar gå igenom den här loggen och leta efter något. Det är sådana saker som glöms bort, men värda att överväga.

Det är lättare att skriva ett program som körs på en dator med en processor.

När vårt system växer vill vi parallellisera allt detta och parallellisera det inte bara på datorn utan också på klustret. Frågan uppstår: hur ska man samordna denna fråga? Våra applikationer kanske inte ens interagerar med varandra, men vi har flera processer som körs parallellt på flera servrar. Och hur övervakar man att allt går bra för dem? Till exempel skickar de något över internet. De måste skriva någonstans om sin status, till exempel i någon databas eller i en logg, sedan aggregera denna logg och sedan analysera den någonstans. Dessutom måste vi ta hänsyn till att processen fungerade och fungerade, och plötsligt dök det upp något fel i den eller kraschade, så hur snabbt kommer vi att få reda på det?

Det är klart att allt detta snabbt kan övervakas. Detta är också bra, men övervakning är en begränsad sak som gör att du kan övervaka vissa saker på högsta nivå.

När vi vill att våra processer ska börja interagera med varandra, till exempel skicka en del data till varandra, då uppstår också frågan – hur kommer detta att hända? Kommer det att finnas någon form av tävlingstillstånd, kommer de att skriva över varandra, kommer data fram korrekt, kommer något att gå förlorat på vägen? Vi måste ta fram något slags protokoll osv.

Samordning av alla dessa processer är inte en trivial fråga. Och det tvingar utvecklaren att gå ner till en ännu lägre nivå och skriva system antingen från grunden eller inte helt från början, men det är inte så enkelt.

Om du har kommit på en kryptografisk algoritm eller till och med implementerat den, ta den och kasta den omedelbart, för troligen kommer den inte att fungera för dig. Den kommer med största sannolikhet att innehålla ett gäng fel som du glömt att förutse. Använd det inte för något allvarligt under några omständigheter, eftersom det med största sannolikhet kommer att vara instabilt. Eftersom alla algoritmer som finns testas av tid under väldigt lång tid. Det söks efter fel av gemenskapen. Detta är ett separat ämne. Och samma sak här. Om det finns en möjlighet att inte implementera någon processsynkronisering själv, är det bättre att inte göra detta, eftersom det är ganska komplicerat och leder dig på en skakig väg med konstant sökning efter fel.

Idag pratar vi om ZooKeeper. Å ena sidan är det ett ramverk, å andra sidan är det en tjänst som gör livet enklare för utvecklaren och maximalt förenklar implementeringen av logik och samordning av våra processer.

Låt oss komma ihåg hur ett distribuerat standardsystem kan se ut. Det här är vad vi pratade om – det här är HDFS, HBase. Det finns en Mästarprocess som hanterar arbetare, slavprocesser. Han är engagerad i koordinering och distribution av uppgifter, startar om arbetare, lanserar nya, fördelar belastningen.

En mer avancerad sak är koordinationstjänsten, d.v.s. flytta själva koordinationsuppgiften till en separat process, plus köra någon backup eller standby av befälhavaren parallellt, eftersom befälhavaren kan krascha. Och om Mästaren faller kommer vårt system inte att fungera. Vi startar backup. Vissa anger att mastern måste replikeras till säkerhetskopian. Detta kan även anförtros Samordningstjänsten. Men i detta schema är Mästaren själv ansvarig för att samordna arbetarna; här är tjänsten ansvarig för att koordinera datareplikeringsåtgärder.

Ett mer avancerat alternativ är när vår tjänst sköter all samordning, som man brukar göra. Han tar ansvar för att allt fungerar. Och om något inte fungerar tar vi reda på det och försöker komma runt den här situationen. Vi har i alla fall fortfarande Mästaren, som på något sätt interagerar med slavarna, och kan skicka data, information, meddelanden etc. genom en viss tjänst.

Det finns ett ännu mer avancerat schema, när vi inte har en Mästare är alla noder mästarslavar, olika i sitt beteende. Men de behöver fortfarande interagera med varandra, så det finns fortfarande någon form av service för att samordna dessa åtgärder. Cassandra, som arbetar på denna princip, passar förmodligen in i detta schema.

Det är svårt att säga vilket av dessa system som fungerar bättre. Var och en har sina egna för- och nackdelar.

Och det finns ingen anledning att vara rädd för vissa saker med Mästaren, eftersom han, som praktiken visar, inte är så mottaglig för att ständigt underkasta sig. Det viktigaste här är att välja rätt lösning för att placera den här tjänsten på en separat kraftfull nod, så att den har tillräckligt med resurser så att användare om möjligt inte har tillgång till den, så att de inte av misstag dödar den här processen. Men samtidigt är det i ett sådant system mycket lättare att hantera arbetare från Masterprocessen, det vill säga detta system är enklare ur implementeringssynpunkt.

Och detta schema (ovan) är förmodligen mer komplext, men mer tillförlitligt.

Det största problemet är partiella misslyckanden. När vi till exempel skickar ett meddelande över Internet inträffar någon sorts olycka, och den som skickat meddelandet kommer inte att veta om hans meddelande har kommit fram och vad som hänt på mottagarens sida, kommer inte att veta om meddelandet behandlats korrekt, d.v.s. han kommer inte att få någon bekräftelse.

Därför måste vi bearbeta denna situation. Och det enklaste är att skicka om detta meddelande och vänta tills vi får ett svar. Samtidigt tas ingenstans hänsyn till om mottagarens tillstånd har ändrats. Det är möjligt att vi skickar ett meddelande och lägger till samma data två gånger.

ZooKeeper erbjuder sätt att hantera sådana misslyckanden, vilket också gör vårt liv enklare.

Som nämnts tidigare liknar detta att skriva flertrådade program, men den största skillnaden är att i distribuerade applikationer som vi bygger på olika maskiner är det enda sättet att kommunicera via nätverket. I huvudsak är det en delad-ingenting-arkitektur. Varje process eller tjänst som körs på en maskin har sitt eget minne, sin egen disk, sin egen processor, som den inte delar med någon.

Om vi ​​skriver ett flertrådigt program på en enda dator kan vi använda delat minne för att utbyta data. Vi har en kontextväxling där, processer kan växla. Detta påverkar prestandan. Å ena sidan finns det inget sådant i programmet på klustret, men det finns problem med Nätverket.

Följaktligen är de huvudsakliga problemen som uppstår när man skriver distribuerade system konfiguration. Vi skriver någon ansökan. Om det är enkelt så hårdkodar vi in ​​alla möjliga siffror i koden, men det här är obekvämt, för om vi bestämmer oss för att istället för en halv sekunds timeout vill vi ha en timeout på en sekund, då måste vi kompilera om applikationen och rulla ut allt igen. Det är en sak när den är på en maskin, när du bara kan starta om den, men när vi har många maskiner måste vi hela tiden kopiera allt. Vi måste försöka göra applikationen konfigurerbar.

Det här handlar om statisk konfiguration för systemprocesser. Det är egentligen inte, kanske ur ett operativsystems perspektiv, det kan vara en statisk konfiguration för våra processer, det vill säga det är en konfiguration som du inte bara kan ta och uppdatera.

Det finns också dynamisk konfiguration. Det är dessa parametrar som vi vill ändra i farten så att de plockas upp där.

Vad är problemet här? Vi uppdaterade konfigurationen, rullade ut den och vad? Problemet kan vara att vi å ena sidan rullade ut config, men glömde uppdateringen, config låg kvar. För det andra, medan vi rullade ut det, uppdaterades vissa konfigurationer, men vissa inte. Och vissa processer i vår applikation som fungerar på en dator startades om med en ny konfiguration och någonstans med den gamla. Detta kan leda till att vår distribuerade applikation är inkonsekvent vad gäller konfiguration. Detta är ett vanligt problem. För dynamisk konfiguration är det mer relevant eftersom det antas att det kan ändras direkt.

Ett annat problem är gruppmedlemskap. Vi har alltid någon uppsättning arbetare, vi vill alltid veta vem av dem som är vid liv, vem av dem som är död. Om det finns en Master måste den förstå vilka arbetare som klienter kan omdirigeras till så att de kör beräkningar eller arbetar med data, och vilka som inte kan. Problemet uppstår hela tiden att vi behöver veta vilka som arbetar i vårt kluster.

Ett annat typiskt problem är ledarval, då vi vill veta vem som är ansvarig. Ett exempel är replikering, där vi har någon process som accepterar skrivoperationer och sedan replikerar dem till andra processer. Han kommer att vara ledaren, alla andra kommer att lyda honom och följa honom. Det är nödvändigt att välja en process som är entydig för alla, så att det inte visar sig att två ledare väljs ut.

Det finns också ömsesidigt uteslutande tillgång. Problemet här är mer komplext. Det finns en sådan sak som en mutex, när du skriver flertrådade program och vill att tillgång till någon resurs, till exempel till en minnescell, ska begränsas och endast utföras av en tråd. Här kan resursen vara något mer abstrakt. Och olika applikationer från olika noder i vårt nätverk bör endast få exklusiv åtkomst till denna resurs, och inte så att alla kan ändra den eller skriva något där. Dessa är de så kallade låsen.

ZooKeeper kan lösa alla dessa problem i en eller annan grad. Och jag kommer att visa dig med exempel hur det låter dig göra detta.

Det finns inga blockerande primitiver. När vi börjar använda något kommer den primitiva inte att vänta på att någon händelse inträffar. Troligtvis kommer den här saken att fungera asynkront, vilket gör att processer inte hänger i ett tillstånd av att vänta på något. Detta är en mycket användbar sak.

Alla kundförfrågningar behandlas i den allmänna köns ordning.

Och klienter har möjlighet att få meddelanden om ändringar i något tillstånd, om ändringar i data, innan klienten ser den ändrade informationen själv.

ZooKeeper kan fungera i två lägen. Det första är fristående, på en enda nod. Detta är praktiskt för testning. Det kan också fungera i klusterläge, på valfritt antal noder. servrarOm vi ​​har ett kluster med 100 maskiner behöver det inte nödvändigtvis köras på 100 maskiner. Det räcker att allokera några maskiner där ZooKeeper kan köras. Och det följer principen om hög tillgänglighet. ZooKeeper lagrar en komplett kopia av data på varje körande instans. Jag kommer att förklara hur det gör detta senare. Det varken skär eller partitionerar data. Å ena sidan är detta en nackdel eftersom vi inte kan lagra mycket, men å andra sidan är det onödigt. Det är inte utformat för det; det är inte en databas.

Data kan cachelagras på klientsidan. Detta är en standardprincip så att vi inte stör tjänsten och inte överbelasta den med identiska förfrågningar. En smart klient vet vanligtvis om detta och cachar det.

Till exempel har något förändrats för oss. Det finns en del tillämpning. En ny ledare valdes som ansvarar för exempelvis handläggning av skrivverksamheten. Och vi vill replikera data. En av lösningarna är att installera en slinga. Och vi frågar hela tiden vår tjänst – har något förändrats? Det andra alternativet är mer optimalt. Det är en klockmekanism som låter dig meddela kunder när något har förändrats. Detta är en mindre resurskrävande metod och bekvämare för kunderna.

Klient – ​​är användaren som använder ZooKeeper.

Server är själva ZooKeeper-processen.

Znode är nyckeln i ZooKeeper. Alla znoder lagras i ZooKeepers minne och är organiserade i ett hierarkiskt schema, i form av ett träd.

Det finns två typer av operationer. Den första är uppdatering/skriv, när någon operation ändrar tillståndet för vårt träd. Trädet är vanligt.

Och det är möjligt att klienten inte utför en begäran och kopplar från, utan kan upprätta en session genom vilken den interagerar med ZooKeeper.

ZooKeepers datamodell liknar ett filsystem. Det finns en standardrot och sedan gick vi som om vi genom katalogerna som går från roten. Och sedan den första nivån katalogen, den andra nivån. Dessa är alla znoder.

Varje znod kan lagra vissa data, vanligtvis inte särskilt stora, till exempel 10 kilobyte. Och varje znod kan ha ett visst antal barn.

Znoder finns i flera typer. De kan skapas. Och när vi skapar en znod anger vi vilken typ den ska tillhöra.

Det finns två typer. Den första är den tillfälliga flaggan. Znode lever inom en viss session. Till exempel har en klient etablerat en session. Och så länge den här sessionen lever kommer den att existera. Detta är nödvändigt för att undvika att skapa något onödigt. Detta är också lämpligt för situationer där det är viktigt för oss att lagra dataprimitiver inom en session.

Den andra typen är en sekventiell flagga. Den ökar räknaren på vägen till znoden. Till exempel hade vi en katalog med applikationen 1_5. Och när vi skapade den första noden fick den p_1, den andra - p_2. Och varje gång vi anropar den här metoden passerar vi den fullständiga sökvägen, och specificerar endast en del av vägen, och detta nummer ökas automatiskt, eftersom vi anger nodtypen - sekventiell.

Vanlig znode. Hon kommer att leva för evigt och ha det namn vi säger till henne.

En annan användbar sak är klockflaggan. Om vi ​​installerar det kan klienten prenumerera på vissa händelser för en specifik nod. Jag ska visa dig senare med ett exempel hur detta går till. ZooKeeper meddelar själv klienten att data på noden har ändrats. Meddelanden garanterar dock inte att några nya uppgifter har kommit in. De indikerar helt enkelt att något har förändrats, så du måste fortfarande jämföra data senare med separata samtal.

Och som jag redan sa, ordningen på data bestäms av kilobyte. Det finns inget behov av att lagra stora textdata där, eftersom det inte är en databas, det är en server för att koordinera åtgärder.

Låt mig berätta lite om sessioner. Om vi ​​har flera servrar kan vi transparent växla mellan servers. server, med hjälp av sessions-ID:t. Detta är ganska bekvämt.

Varje session har en timeout. En session definieras av om klienten sänder något till servern under den sessionen. Om den inte har sänt något under timeouten avbryts sessionen eller så kan klienten stänga den själv.

Den har inte så många funktioner, men du kan göra många saker med detta API. Anropet vi såg, skapa skapar en znod och tar tre parametrar. Detta är sökvägen till znoden, och den måste anges i sin helhet från roten. Och även detta är en del data som vi vill överföra dit. Och typen av flagga. Och efter skapandet returnerar den vägen till znoden.

Den andra kan tas bort. Tricket här är att den andra parametern, förutom sökvägen till znoden, kan användas för att specificera versionen. Följaktligen kommer znoden att raderas om versionen vi skickade är likvärdig med den som faktiskt existerar.

Om vi ​​inte vill kontrollera denna version skickar vi helt enkelt argumentet "-1".

För det tredje kontrollerar den förekomsten av znoden. Returnerar sant om noden finns, annars falskt.

Och här kommer flaggklocka, som låter dig ställa in övervakning av denna nod.

Du kan ställa in denna flagga även på en icke-existerande nod och få ett meddelande när den dyker upp. Detta kan också vara användbart.

Ett par utmaningar till är: hämta data. Det är klart att vi kan få data via znode. Du kan också använda flaggklocka. I det här fallet kommer den inte att installeras om det inte finns någon nod. Därför måste du förstå att det finns och sedan få data.

Det finns också SetData. Här skickar vi version. Och om vi passerar detta kommer data på znoden för en viss version att uppdateras.

Du kan också ange "-1" för att utesluta denna kontroll.

En annan användbar metod är skaffaBarn. Vi kan också få en lista över alla znoder som hör till den. Vi kan observera detta genom att ställa in flaggvakt.

Och metoden synkronisera låter dig skicka alla ändringar på en gång, vilket säkerställer att de sparas och all data ändras helt.

Om vi ​​drar analogier med vanlig programmering, då när du använder metoder som att skriva, som skriver något till disk, och efter att det har returnerat ett svar till dig, finns det ingen garanti för att din data har skrivits till disk. Och även när operativsystemet är säkert på att allt har skrivits har själva disken mekanismer där processen går igenom nivåer av buffertar, och först efter det placeras data på disken.

Asynkrona samtal används oftast. Detta gör att klienten kan arbeta parallellt med olika önskemål. Ett synkront tillvägagångssätt kan användas, men det är mindre effektivt.

De två operationerna vi pratade om är update/write, som ändrar data. Dessa är create, setData, sync, delete. Och läs finns, getData, getChildren.

Nu några exempel på hur du kan göra primitiver av arbete i ett distribuerat system. Till exempel relaterat till konfigurationen av något. En ny arbetare har dykt upp. Vi lade till bilen och startade processen. Och det är följande tre frågor. Hur begär den konfiguration från ZooKeeper? Och om vi vill ändra konfigurationen, hur ändrar vi den? Och efter att vi ändrat det, hur får de arbetare vi hade det?

I ZooKeeper kan detta göras relativt enkelt. Till exempel finns vårt znode-träd. Det finns en nod för vår applikation här, vi skapar en extra nod i den, som innehåller data från konfigurationen. Dessa kan vara separata parametrar eller inte. Eftersom storleken är liten är konfigurationsstorleken vanligtvis liten också, så det är fullt möjligt att lagra den här.

Du använder metoden hämta data för att hämta konfigurationen för arbetaren från noden. Ställ in på sant. Om denna nod av någon anledning saknas kommer vi att informeras om den när den dyker upp eller när den ändras. Om vi ​​vill veta att något har förändrats, ställer vi in ​​det på sant. Och om data i denna nod ändras kommer vi att veta om det.

SetData. Vi ställer in data, ställer in den på "-1", det vill säga vi kontrollerar inte versionen, vi antar att vi alltid har en konfiguration, vi behöver inte lagra många konfigurationer. Om du behöver lagra mycket måste du lägga till ytterligare en nivå. Här anser vi att det bara finns en, därför uppdaterar vi endast den senaste, därför kontrollerar vi inte versionen. Vid det här laget får alla kunder som har prenumererat tidigare ett meddelande om att något har ändrats i denna nod. Och efter att de har fått det måste de också begära uppgifterna igen. Meddelandet är att de inte får själva uppgifterna, utan endast ett meddelande om ändringar. Efter det bör de be om nya uppgifter.

Det andra alternativet för att använda det primitiva är gruppmedlemskap. Vi har en distribuerad applikation, det finns ett gäng arbetare och vi vill förstå att de alla är på plats. Därför måste de själva registrera att de arbetar i vår ansökan. Och vi vill också ta reda på antingen Masterprocessen eller någon annanstans om alla aktiva arbetare som vi har för närvarande.

Hur gör vi detta? För applikationen skapar vi en arbetarnod och lägger till en undernivå till den med metoden skapa. Jag har ett fel på bilden. Det är här det behövs sekventiell specificera, då skapas alla arbetare en efter en. Och applikationen, genom att begära all information om barnen i denna nod, tar emot alla aktiva arbetare som finns.

Här är en skrämmande implementering av hur detta kan göras i Java-kod. Låt oss börja från slutet, med huvudmetoden. Det här är vår klass, låt oss skapa dess metod. Som det första argumentet använder vi värden där vi ansluter, det vill säga vi sätter det som ett argument. Och det andra argumentet är gruppnamnet.

Hur uppstår kopplingen? Detta är ett enkelt exempel på API som används. Allt är relativt enkelt här. Det finns en standard ZooKeeper-klass. Vi passerar honom värdarna. Och vi sätter en timeout, till exempel 5 sekunder. Och vi har en medlem som heter connectedSignal. I huvudsak skapar vi en grupp längs den överförda vägen. Vi skriver inte data där, även om vi kunde ha skrivit något. Och noden här har den beständiga typen. I huvudsak är detta en vanlig nod som kommer att finnas hela tiden. Det är här sessionen skapas. Detta är kundens egen implementering. Vår klient kommer med jämna mellanrum att skicka meddelanden som indikerar att sessionen är vid liv. Och när vi avslutar sessionen ringer vi nära och det är allt, sessionen avbryts. Detta är i fall något går fel, så att ZooKeeper vet om det och avbryter sessionen.

Hur låser man en resurs? Här är allt lite mer komplicerat. Vi har en uppsättning arbetare, det finns någon resurs som vi vill låsa. För detta skapar vi en separat nod, till exempel, kallad lock1. Om vi ​​kunde skapa det, då fick vi ett lås här. Och om vi inte kunde skapa det, så försöker arbetaren hämta data härifrån, och eftersom noden redan har skapats, lägger vi en bevakare här och i det ögonblick när tillståndet för denna nod ändras, kommer vi att veta om det. Och vi kan försöka få tid att återskapa det. Om vi ​​tog den här noden, tog det här låset, kommer vi att vägra det, efter att vi inte längre behöver låset, eftersom noden endast existerar inom sessionen. Följaktligen kommer den att försvinna. Och en annan klient inom en annan session kommer att kunna ta låset på denna nod, eller snarare, han kommer att få ett meddelande om att något har ändrats och han kan försöka göra det i tid.

Ytterligare ett exempel på hur du kan välja huvudledare. Detta är lite mer komplicerat, men ändå relativt enkelt. Vad händer här? Det finns en huvudnod som samlar alla arbetare. Vi försöker få information om ledaren. Om detta hände framgångsrikt, det vill säga vi fick lite data, börjar vår medarbetare följa den här ledaren. Han tror att en ledare redan finns.

Om ledaren dör av någon anledning till exempel faller bort, då försöker vi skapa en ny ledare. Och om vi lyckas, då blir vår arbetare ledaren. Och om någon i det här ögonblicket lyckades skapa en ny ledare, försöker vi förstå vem det är och sedan följa honom.

Det är här den så kallade flockeffekten uppstår, för när en ledare dör blir den som kommer först dit ledaren.

När du skaffar en resurs kan du prova att använda ett lite annorlunda tillvägagångssätt, vilket är följande. Vi vill till exempel få ett lås, men utan herteffekten. Den kommer att bestå av att vår applikation begär listor över alla nod-ID för en befintlig nod med lås. Och om noden innan detta, låset som vi skapade, är minimum av uppsättningen som vi fick, betyder det att vi fångade låset. Vi kontrollerar att vi fått lås. Som en kontroll kommer det att finnas ett villkor att det id som vi fick när vi skapade ett nytt lås är minimalt. Och om vi fick det så fortsätter vi att jobba.

Om det finns något id som är mindre än vårt lås, ställer vi in ​​en watcher på denna händelse och väntar på meddelande tills något ändras. Det vill säga, vi har det här låset. Och tills den faller av kommer vi inte att bli minimi-ID och kommer inte att få minimilåset, och därmed kommer vi att kunna låsa oss själva. Och om detta villkor inte är uppfyllt, så går vi omedelbart hit och försöker få det här låset igen, för något kunde ha förändrats under denna tid.

Vad består ZooKeeper av? Det finns 4 huvudsakliga saker. Detta är bearbetningen av processer - Begäran. Och även ZooKeeper Atomic Broadcast. Det finns en Commit Log där alla operationer registreras. Och själva In-memory Replicated DB, d.v.s. själva databasen, där hela detta träd lagras.

Det är värt att notera att alla skrivoperationer går genom Request Processor. Och läsoperationer går direkt till In-memory-databasen.

Själva databasen är helt replikerad. Alla ZooKeeper-instanser lagrar en fullständig kopia av data.

För att återställa databasen efter en krasch finns det en Commit-logg. Standardpraxis är att skriva data i minnet innan det kommer dit, så att denna logg kan spelas upp i händelse av en krasch och systemtillståndet kan återställas. Periodiska ögonblicksbilder av databasen används också.

ZooKeeper Atomic Broadcast är en sak som används för att underhålla replikerad data.

ZAB väljer internt en ledare från ZooKeeper-nodens synvinkel. Andra noder blir hennes följare och väntar på några handlingar från henne. Om de får några poster skickar de dem alla till ledaren. Den utför först skrivoperationen och skickar sedan ett meddelande till sina följare om vad som har förändrats. Detta bör i huvudsak göras atomärt, d.v.s. skrivoperationen och sändningen av det hela bör göras atomärt, vilket garanterar datakonsistens.

Den hanterar bara skrivförfrågningar. Dess huvudsakliga uppgift är att omvandla en operation till en transaktionsuppdatering. Detta är en specialgjord begäran.

Och här är det värt att notera att idempotensen av uppdateringar för samma operation är garanterad. Vad är det här? Denna sak, om den körs två gånger, kommer att ha samma tillstånd, dvs själva begäran kommer inte att ändras. Och detta måste göras så att driften vid en eventuell krasch kan startas om och därigenom rulla ut de förändringar som har fallit av för tillfället. I detta fall kommer systemets tillstånd att bli detsamma, d.v.s. det ska inte vara så att en serie av samma, till exempel uppdateringsprocesser, leder till olika sluttillstånd av systemet.

Källa: will.com