"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. Osanningar om distribuerad datoranvändning. Diagram över ett standarddistribuerat system. Svårigheter 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 det, det vill säga hur man använder det på något sätt och arbetar med det på något sätt. Och idag skulle jag vilja prata lite om att bygga distribuerade applikationer. Och ZooKeeper är en av de saker som gör att du kan förenkla den här saken. Detta är en sorts tjänst som är avsedd för någon form av koordinering av samspelet mellan processer i distribuerade system, i distribuerade applikationer.

Behovet av sådana applikationer blir mer och mer för varje dag som går, det är vad vår kurs handlar om. Å ena sidan tillåter MapReduce och detta färdiga ramverk dig att utjämna denna komplexitet och befria programmeraren från att skriva primitiver som interaktion och koordinering av processer. 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 med detta. Inklusive MapReduce sig själv och en massa andra Apache-projekt, de är faktiskt också distribuerade applikationer. Och för att göra skrivandet lättare skrev de ZooKeeper.

Liksom alla Hadoop-relaterade applikationer utvecklades den av 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å kommer det varje dag ett gäng buggrapporter, ett gäng förslag för att optimera något, d.v.s. livet i projektet pågår ständigt. 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, varför det har blivit en standard i applikationer inom Hadoop-ekosystemet. Så jag tänkte att det skulle vara användbart att granska 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 anges här, i en eller annan grad, fungerar 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 specifikt skulle fungera 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 vi lanserade två applikationer parallellt på olika datorer, kopplade ihop dem med en sträng eller i ett nät, och allt fungerar. Men problemet är att nätverket är opålitligt, och om du sniffade trafiken eller tittade på vad som händer där på en låg nivå, hur klienter interagerar på nätverket, kan du ofta se att vissa paket går förlorade eller skickas på nytt. 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 dig. Allt har en timeout. Nätverket kan helt enkelt falla av ett tag. Det kanske bara blinkar. Och allt detta leder till att du inte kan lita på att nätverket är tillförlitligt. Detta är den största skillnaden från att skriva parallella applikationer som körs på en dator eller på en 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.

Bland annat vid användning av Nätverket finns det alltid en viss latens. Disken har det också, men nätverket har mer av det. Latens är en viss fördröjningstid, som kan vara antingen liten eller ganska betydande.

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

Nätverket kan också förändras vad gäller utrustning. Från praktiken kan jag säga att våra nätverksingenjörer verkligen gillar att periodvis uppdatera något på ljusen. Plötsligt kom en ny firmware ut och de var inte särskilt intresserade av något Hadoop-kluster. De har ett eget jobb. För dem är huvudsaken att nätverket fungerar. Följaktligen vill de ladda upp något där igen, göra en blinkning på sin hårdvara, och hårdvaran ändras också med jämna mellanrum. Allt detta måste på något sätt tas i beaktande. Allt detta påverkar vår distribuerade applikation.

Vanligtvis tror människor som av någon anledning börjar arbeta med stora datamängder att internet är gränslöst. 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 fel är inne vim titta på loggarna. Gör aldrig det här 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 här är saker som glöms bort, men värda att tänka på.

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 det hela och parallellisera det inte bara på en dator utan också på ett kluster. Frågan uppstår: hur ska man samordna denna fråga? Våra applikationer kanske inte ens interagerar med varandra, men vi körde flera processer 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 om sitt tillstånd någonstans, till exempel i någon slags databas eller logg, sedan aggregera denna logg och sedan analysera den någonstans. Dessutom måste vi ta hänsyn till att processen fungerade och fungerade, plötsligt dök något fel upp i den eller kraschade, 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 för att skicka lite 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 uppgifterna 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 sak. Och det tvingar utvecklaren att gå ner till en ännu lägre nivå, och skriva system antingen från grunden, eller inte riktigt från början, men detta är inte så enkelt.

Om du kommer på en kryptografisk algoritm eller till och med implementerar den, släng 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 sörja för. Använd den aldrig till något allvarligt eftersom den med största sannolikhet kommer att vara instabil. Eftersom alla algoritmer som finns har testats av tiden under väldigt lång tid. Det är avlyssnat av samhället. Detta är ett separat ämne. Och det är samma sak här. Om det är möjligt att inte implementera någon form av processsynkronisering själv, är det bättre att inte göra detta, eftersom det är ganska komplicerat och leder dig ner på den skakiga vägen att ständigt söka 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 förenklar implementeringen av logik och samordning av våra processer så mycket som möjligt.

Låt oss komma ihåg hur ett distribuerat standardsystem kan se ut. Det här är vad vi pratade om - HDFS, HBase. Det finns en Mästarprocess som hanterar arbetare och slavprocesser. Han ansvarar för att koordinera och fördela uppgifter, starta om arbetare, lansera nya och fördela belastningen.

En mer avancerad sak är koordinationstjänsten, det vill säga flytta själva koordinationsuppgiften till en separat process, plus köra någon form av backup eller stanby Master parallellt, eftersom Mastern kan misslyckas. Och om Mästaren faller, kommer vårt system inte att fungera. Vi kör backup. Vissa anger att mastern måste replikeras till backup. Detta kan även anförtros Samordningstjänsten. Men i det här diagrammet är Mästaren själv ansvarig för att samordna arbetarna; här koordinerar tjänsten datareplikeringsaktiviteter.

Ett mer avancerat alternativ är när all samordning sköts av vår tjänst, 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 kvar en Mästare som på något sätt interagerar med slavar och kan skicka data, information, meddelanden etc. via någon 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 en del service kvar för att samordna dessa åtgärder. Förmodligen passar Cassandra, som arbetar på denna princip, detta schema.

Det är svårt att säga vilket av dessa system som fungerar bäst. 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 praxis visar, inte är så mottaglig för att ständigt tjäna. Huvudsaken här är att välja rätt lösning för att vara värd för den här tjänsten på en separat kraftfull nod, så att den har tillräckligt med resurser, så att om möjligt användare inte har tillgång där, 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. Till exempel, när vi skickar ett meddelande över nätverket inträffar någon form av olycka, och den som skickade meddelandet kommer inte att veta om hans meddelande togs emot och vad som hände på mottagarens sida, kommer inte att veta om meddelandet behandlades korrekt , dvs 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. I det här fallet tas det inte hänsyn till om mottagarens tillstånd har ändrats. Vi kan skicka ett meddelande och lägga till samma data två gånger.

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

Som nämnts lite 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 på Nätverket. I huvudsak är detta 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 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å ett kluster, 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 form av ansökan. Om det är enkelt, så hårdkodar vi alla möjliga siffror i koden, men detta är obekvämt, för om vi bestämmer oss för att istället för en timeout på en halv sekund 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.

Här talar vi om statisk konfiguration för systemprocesser. Detta är inte helt, kanske ur operativsystemets synvinkel, det kan vara en statisk konfiguration för våra processer, det vill säga detta är en konfiguration som inte bara kan tas och uppdateras.

Det finns också en 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, så vad? Problemet kan vara att vi å ena sidan rullade ut config, men glömde bort det nya, config fanns kvar. För det andra, medan vi rullade ut, uppdaterades konfigurationen på vissa ställen, men inte på andra. Och vissa processer i vår applikation som körs på en dator startades om med en ny konfiguration och någonstans med en gammal. Detta kan resultera i att vår distribuerade applikation är inkonsekvent ur ett konfigurationsperspektiv. Detta problem är vanligt. För en dynamisk konfiguration är den mer relevant eftersom den innebär att den 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 mästare måste han förstå vilka arbetare som kan omdirigeras till klienter så att de kör beräkningar eller arbetar med data, och vilka som inte kan. Ett problem som ständigt dyker upp är 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, när vi har någon process som tar emot skrivoperationer och sedan replikerar dem bland andra processer. Han kommer att vara ledaren, alla andra kommer att lyda honom, följa honom. Det är nödvändigt att välja en process så att den ä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 en minnescell, ska begränsas och utföras av endast en tråd. Här kan resursen vara något mer abstrakt. Och olika applikationer från olika noder i vårt nätverk ska bara få exklusiv tillgång till en given resurs, och inte så att alla kan ändra den eller skriva något där. Dessa är de så kallade låsen.

ZooKeeper låter dig lösa alla dessa problem i en eller annan grad. Och jag kommer att visa 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 denna 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 sig medan de väntar 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å meddelande om förändringar i något tillstånd, om ändringar i data, innan klienten själv ser den ändrade informationen.

ZooKeeper kan arbeta i två lägen. Den första är fristående, på en nod. Detta är bekvämt för att testa. Den kan också fungera i klusterläge på valfritt antal servrar. Om vi ​​har ett kluster på 100 maskiner så är det inte nödvändigt att det fungerar på 100 maskiner. Det räcker med att välja flera maskiner där du kan köra ZooKeeper. Och den bekänner sig till principen om hög tillgänglighet. På varje körande instans lagrar ZooKeeper en hel kopia av data. Senare ska jag berätta hur han gör. Den delar inte data eller partitionerar den. Å ena sidan är det ett minus att vi inte kan lagra mycket, å andra sidan behöver man inte göra detta. Det är inte vad den är designad för, det är inte en databas.

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

Till exempel har något förändrats här. Det finns någon form av applikation. En ny ledare valdes, som bland annat ansvarar för handläggning av skrivoperationer. Och vi vill replikera data. En lösning är att lägga den i en slinga. Och vi ifrågasätter hela tiden vår service – har något förändrats? Det andra alternativet är mer optimalt. Detta är en bevakningsmekanism som låter dig meddela kunder att något har förändrats. Detta är en billigare metod när det gäller resurser och bekvämare för kunderna.

Klienten är den användare som använder ZooKeeper.

Server är själva ZooKeeper-processen.

Znode är nyckeln i ZooKeeper. Alla znoder lagras i minnet av ZooKeeper och är organiserade i form av ett hierarkiskt diagram, 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 slutför en förfrågan och kopplas bort, 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 katalogen på första nivån, andra nivån. Detta ä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 session. Kunden har till exempel etablerat en session. Och så länge den här sessionen lever kommer den att existera. Detta är nödvändigt för att inte producera något onödigt. Detta är också lämpligt för stunder då det är viktigt för oss att lagra dataprimitiver inom en session.

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

Vanlig znode. Hon kommer alltid att leva och ha det namn som 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 vissa nya uppgifter har kommit. De säger 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 åtgärdskoordinationsserver.

Jag ska berätta lite om sessionerna. Om vi ​​har flera servrar kan vi på ett transparent sätt flytta från server till server med hjälp av sessionsidentifieraren. Det är ganska bekvämt.

Varje session har någon form av timeout. En session definieras av om klienten skickar något till servern under den sessionen. Om han inte skickade 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 olika saker med detta API. Det 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.

För det andra kan du ta bort den. Tricket här är att den andra parametern, förutom sökvägen till znoden, kan specificera versionen. Följaktligen kommer den znoden att raderas om dess version som vi överförde är likvärdig med den som faktiskt existerar.

Om vi ​​inte vill kontrollera den här versionen, skickar vi helt enkelt argumentet "-1".

För det tredje kontrollerar den om det finns en znod. Returnerar sant om noden finns, annars falskt.

Och sedan visas flaggklocka, vilket gör att du kan övervaka 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 hämta data. Det är klart att vi kan ta emot data via znode. Du kan också använda flaggklocka. I det här fallet kommer det inte att installeras om det inte finns någon nod. Därför måste du förstå att det finns och sedan ta emot data.

Det finns också SetData. Här skickar vi version. Och om vi skickar detta vidare 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 övervaka detta genom att ställa in flaggvakt.

Och metod synkronisera gör att alla ändringar kan skickas på en gång, vilket säkerställer att de sparas och att all data har ändrats 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 returnerar ett svar till dig, finns det ingen garanti för att du har skrivit data till disk. Och även när operativsystemet är övertygat om att allt har skrivits, finns det mekanismer i själva disken där processen går igenom lager av buffertar, och först efter det placeras data på disken.

Oftast används asynkrona samtal. Detta gör att klienten kan arbeta parallellt med olika önskemål. Du kan använda den synkrona metoden, men den är mindre produktiv.

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 för att arbeta i ett distribuerat system. Till exempel relaterat till konfigurationen av något. En ny arbetare har dykt upp. Vi lade till maskinen och startade processen. Och det är följande tre frågor. Hur frågar den ZooKeeper för konfiguration? Och om vi vill ändra konfigurationen, hur ändrar vi den? Och efter att vi ändrat det, hur får de arbetare som vi hade det?

ZooKeeper gör detta 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 inte existerar 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 "-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 tror vi att det bara finns en, så vi uppdaterar bara den senaste, så vi kontrollerar inte versionen. I detta ögonblick får alla kunder som tidigare prenumererat 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. Aviseringen är att de inte får själva uppgifterna utan endast meddelande om ändringar. Efter detta måste 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 fungerar i vår ansökan. Och vi vill också ta reda på, antingen från Mästarprocessen 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å där med metoden skapa. Jag har ett fel på bilden. Här behöver du sekventiell specificera, då skapas alla arbetare en efter en. Och applikationen, som begär all data om barnen i denna nod, tar emot alla aktiva arbetare som finns.

Detta är en så fruktansvärd 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 host, där vi ansluter, dvs vi sätter det som ett argument. Och det andra argumentet är namnet på gruppen.

Hur uppstår kopplingen? Detta är ett enkelt exempel på API som används. Allt är relativt enkelt här. Det finns en ZooKeeper i standardklass. Vi skickar värdar till det. Och ställ in timeout på 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 något kunde ha skrivits. Och noden här är av den ihärdiga typen. I huvudsak är detta en vanlig vanlig nod som kommer att existera hela tiden. Det är här sessionen skapas. Detta är implementeringen av själva klienten. Vår klient kommer att skicka periodiska meddelanden som indikerar att sessionen är vid liv. Och när vi avslutar sessionen ringer vi nära och det är allt, sessionen faller av. Detta ifall något faller av för oss, så att ZooKeeper får reda på det och stänger av 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 att göra 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 den, 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 samma ögonblick som 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 överge 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 ramen för 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 förä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 också 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 arbetare följa denna ledare. Han tror att det redan finns en ledare.

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

Här uppstår den så kallade flockeffekten, det vill säga flockeffekten, för när en ledare dör blir den som är först i tiden ledare.

När du fångar en resurs kan du försöka använda ett lite annorlunda tillvägagångssätt, vilket är följande. Vi vill till exempel få ett lås, men utan herteffekten. Det kommer att bestå i att vår applikation begär listor över alla nod-ID för en redan existerande nod med lås. Och om innan dess noden som vi skapade ett lås för är den minsta av uppsättningen som vi fick, betyder det att vi har fångat låset. Vi kontrollerar att vi har fått ett 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å jobbar vi vidare.

Om det finns ett visst id som är mindre än vårt lås, så sätter vi en watcher på denna händelse och väntar på meddelande tills något ändras. Det vill säga vi fick detta lås. Och tills det faller av kommer vi inte att bli minimi-id och kommer inte att få minimilåset, och därmed kommer vi att kunna logga in. Och om detta villkor inte är uppfyllt, så går vi omedelbart hit och försöker få det här låset igen, eftersom något kan ha förändrats under den här tiden.

Vad består ZooKeeper av? Det finns 4 huvudsakliga saker. Detta är bearbetningsprocesser - Begäran. Och även ZooKeeper Atomic Broadcast. Det finns en Commit Log där alla operationer registreras. Och själva in-memory Replicated DB, dvs 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 instanser av ZooKeeper lagrar en fullständig kopia av data.

För att återställa databasen efter en krasch finns det en Commit-logg. Standardpraxis är att innan data hamnar i minnet skrivs den där så att om den kraschar kan den här loggen spelas upp och systemtillståndet kan återställas. Och 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 förväntar sig några handlingar från henne. Om de får bidrag skickar de dem alla till ledaren. Han utför först en skrivoperation och skickar sedan ett meddelande om vad som har förändrats till hans följare. Detta måste i själva verket utföras atomärt, d.v.s. inspelningen och sändningen av det hela måste utföras atomiskt, vilket garanterar datakonsistens.

Den behandlar bara skrivförfrågningar. Dess huvudsakliga uppgift är att omvandla operationen till en transaktionsuppdatering. Detta är en speciellt genererad begäran.

Och här är det värt att notera att idempotensen av uppdateringar för samma operation är garanterad. Vad det ä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 du i händelse av en krasch kan starta om operationen och därmed rulla tillbaka de ändringar som har fallit av för tillfället. I detta fall kommer systemets tillstånd att bli detsamma, d.v.s. det bör inte vara så att en serie av samma, till exempel uppdateringsprocesser, ledde till olika sluttillstånd av systemet.

Källa: will.com