Ik stel voor dat je het transcript leest van de lezing "Hadoop. ZooKeeper" uit de serie "Methoden voor gedistribueerde verwerking van grote hoeveelheden gegevens in Hadoop"
Wat is ZooKeeper, zijn plaats in het Hadoop-ecosysteem. Onwaarheden over gedistribueerd computergebruik. Diagram van een standaard gedistribueerd systeem. Moeilijkheden bij het coördineren van gedistribueerde systemen. Typische coördinatieproblemen. De principes achter het ontwerp van ZooKeeper. ZooKeeper-gegevensmodel. znode-vlaggen. Sessies. Client-API. Primitieven (configuratie, groepslidmaatschap, eenvoudige vergrendelingen, verkiezing van leiders, vergrendeling zonder kudde-effect). ZooKeeper-architectuur. ZooKeeper DB. ZAB. Verzoek behandelaar.
Vandaag zullen we het hebben over ZooKeeper. Dit ding is erg handig. Het heeft, zoals elk Apache Hadoop-product, een logo. Het stelt een man voor.
Voordien hebben we vooral gesproken over hoe gegevens daar kunnen worden verwerkt, hoe ze kunnen worden opgeslagen, dat wil zeggen, hoe ze op de een of andere manier kunnen worden gebruikt en hoe ermee kan worden gewerkt. En vandaag wil ik het graag hebben over het bouwen van gedistribueerde applicaties. En ZooKeeper is een van die dingen waarmee u deze kwestie kunt vereenvoudigen. Dit is een soort dienst die bedoeld is voor een soort coördinatie van de interactie van processen in gedistribueerde systemen, in gedistribueerde applicaties.
De behoefte aan dergelijke toepassingen wordt elke dag groter, daar gaat onze cursus over. Aan de ene kant kun je met MapReduce en dit kant-en-klare raamwerk deze complexiteit nivelleren en de programmeur bevrijden van het schrijven van primitieven zoals interactie en coördinatie van processen. Maar aan de andere kant garandeert niemand dat dit toch niet hoeft te gebeuren. MapReduce of andere kant-en-klare raamwerken vervangen niet altijd volledig sommige gevallen die hiermee niet kunnen worden geïmplementeerd. Inclusief MapReduce zelf en een aantal andere Apache-projecten; het zijn in feite ook gedistribueerde applicaties. En om het schrijven gemakkelijker te maken, schreven ze ZooKeeper.
Zoals alle Hadoop-gerelateerde applicaties is het ontwikkeld door Yahoo! Het is nu ook een officiële Apache-applicatie. Het is niet zo actief ontwikkeld als HBase. Als je naar JIRA HBase gaat, zijn er elke dag een aantal bugrapporten, een aantal voorstellen om iets te optimaliseren, d.w.z. het leven in het project gaat voortdurend door. En ZooKeeper is enerzijds een relatief eenvoudig product, en anderzijds garandeert dit de betrouwbaarheid ervan. En het is vrij eenvoudig te gebruiken, daarom is het een standaard geworden in toepassingen binnen het Hadoop-ecosysteem. Daarom dacht ik dat het nuttig zou zijn om het te herzien om te begrijpen hoe het werkt en hoe het te gebruiken.
Dit is een foto van een lezing die we hadden. We kunnen zeggen dat het orthogonaal is voor alles wat we tot nu toe hebben overwogen. En alles wat hier wordt aangegeven, werkt tot op zekere hoogte met ZooKeeper, dat wil zeggen, het is een dienst die al deze producten gebruikt. Noch HDFS, noch MapReduce schrijven hun eigen soortgelijke services die specifiek voor hen zouden werken. Dienovereenkomstig wordt ZooKeeper gebruikt. En dit vereenvoudigt de ontwikkeling en sommige dingen die verband houden met fouten.
Waar komt dit allemaal vandaan? Het lijkt erop dat we twee applicaties parallel op verschillende computers hebben gelanceerd, ze met een string of in een mesh hebben verbonden, en alles werkt. Maar het probleem is dat het netwerk onbetrouwbaar is, en als je het verkeer bespeurt of kijkt naar wat daar op een laag niveau gebeurt, hoe clients met elkaar omgaan op het netwerk, kun je vaak zien dat sommige pakketten verloren gaan of opnieuw worden verzonden. Er zijn niet voor niets TCP-protocollen uitgevonden, waarmee je een bepaalde sessie tot stand kunt brengen en de bezorging van berichten kunt garanderen. Maar hoe dan ook, zelfs TCP kan je niet altijd redden. Alles heeft een time-out. Het netwerk kan gewoon een tijdje uitvallen. Het kan zomaar zijn dat het knippert. En dit alles leidt ertoe dat u er niet op kunt vertrouwen dat het netwerk betrouwbaar is. Dit is het belangrijkste verschil met het schrijven van parallelle applicaties die op één computer of op één supercomputer draaien, waar er geen netwerk is, waar er een betrouwbaardere data-uitwisselingsbus in het geheugen is. En dit is een fundamenteel verschil.
Bij gebruik van het netwerk is er onder andere altijd een bepaalde latentie. De schijf heeft het ook, maar het netwerk heeft er meer van. Latency is een bepaalde vertragingstijd, die klein of behoorlijk aanzienlijk kan zijn.
De netwerktopologie verandert. Wat is topologie - dit is de plaatsing van onze netwerkapparatuur. Er zijn datacenters, er staan racks die daar staan, er staan kaarsen. Dit alles kan opnieuw worden aangesloten, verplaatst, etc. Ook hier moet rekening mee worden gehouden. IP-namen veranderen, de routing waar ons verkeer doorheen reist, verandert. Ook hiermee moet rekening worden gehouden.
Ook qua apparatuur kan het netwerk veranderen. Uit de praktijk kan ik zeggen dat onze netwerkingenieurs het erg leuk vinden om periodiek iets over de kaarsen te updaten. Plotseling kwam er nieuwe firmware uit en ze waren niet bijzonder geïnteresseerd in een Hadoop-cluster. Ze hebben hun eigen baan. Voor hen is het belangrijkste dat het netwerk werkt. Dienovereenkomstig willen ze daar iets opnieuw uploaden, hun hardware laten knipperen, en de hardware verandert ook periodiek. Met dit alles moet op de een of andere manier rekening worden gehouden. Dit alles heeft invloed op onze gedistribueerde applicatie.
Meestal denken mensen die om de een of andere reden met grote hoeveelheden gegevens gaan werken dat het internet grenzeloos is. Als er een bestand van meerdere terabytes aanwezig is, kunt u dit naar uw server of computer brengen en openen met hoe en kijk. Er is weer een fout binnen Vim kijk naar de logboeken. Doe dit nooit omdat het slecht is. Omdat Vim alles probeert te bufferen, alles in het geheugen laadt, vooral wanneer we door dit logboek gaan bladeren en naar iets zoeken. Dit zijn dingen die vergeten worden, maar die het overwegen waard zijn.
Het is gemakkelijker om één programma te schrijven dat op één computer met één processor draait.
Als ons systeem groeit, willen we alles parallelliseren, en niet alleen op een computer, maar ook op een cluster. De vraag rijst: hoe moet deze kwestie worden gecoördineerd? Onze applicaties communiceren misschien niet eens met elkaar, maar we hebben verschillende processen parallel op verschillende servers uitgevoerd. En hoe kun je controleren of alles goed met ze gaat? Ze sturen bijvoorbeeld iets via internet. Ze moeten ergens over hun toestand schrijven, bijvoorbeeld in een soort database of logboek, dit logboek vervolgens samenvoegen en het vervolgens ergens analyseren. Bovendien moeten we er rekening mee houden dat het proces werkte en werkte, dat er plotseling een fout in zat of dat het crashte, hoe snel zullen we er dan achter komen?
Het is duidelijk dat dit alles snel kan worden gemonitord. Dit is ook goed, maar monitoring is een beperkt iets waarmee je sommige dingen op het hoogste niveau kunt monitoren.
Als we willen dat onze processen met elkaar gaan interageren, bijvoorbeeld om elkaar wat gegevens te sturen, dan rijst ook de vraag: hoe zal dit gebeuren? Zal er sprake zijn van een soort race condition, zullen ze elkaar overschrijven, zullen de gegevens correct aankomen, zal er onderweg iets verloren gaan? We moeten een soort protocol ontwikkelen, enz.
Coördinatie van al deze processen is geen triviale zaak. En het dwingt de ontwikkelaar om naar een nog lager niveau te gaan en systemen helemaal opnieuw te schrijven, of niet helemaal opnieuw, maar dit is niet zo eenvoudig.
Als je een cryptografisch algoritme bedenkt of zelfs implementeert, gooi het dan onmiddellijk weg, want hoogstwaarschijnlijk zal het niet voor jou werken. Het zal hoogstwaarschijnlijk een aantal fouten bevatten die u bent vergeten op te geven. Gebruik het nooit voor iets ernstigs, omdat het hoogstwaarschijnlijk onstabiel zal zijn. Omdat alle bestaande algoritmen al heel lang door de tijd zijn getest. Het wordt afgeluisterd door de gemeenschap. Dit is een apart onderwerp. En hier is het hetzelfde. Als het mogelijk is om zelf geen enkele vorm van processynchronisatie te implementeren, dan is het beter om dit niet te doen, omdat het behoorlijk ingewikkeld is en je op het wankele pad brengt van voortdurend zoeken naar fouten.
Vandaag hebben we het over ZooKeeper. Enerzijds is het een raamwerk, anderzijds is het een dienst die het leven van de ontwikkelaar gemakkelijker maakt en de implementatie van logica en coördinatie van onze processen zoveel mogelijk vereenvoudigt.
Laten we onthouden hoe een standaard gedistribueerd systeem eruit zou kunnen zien. Dit is waar we het over hadden: HDFS, HBase. Er is een masterproces dat werknemers- en slaafprocessen beheert. Hij is verantwoordelijk voor het coördineren en verdelen van taken, het opnieuw opstarten van werknemers, het lanceren van nieuwe werknemers en het verdelen van de lasten.
Een geavanceerder ding is de Coördinatiedienst, dat wil zeggen het verplaatsen van de coördinatietaak zelf naar een apart proces, plus het parallel draaien van een soort back-up- of standby-master, omdat de master mogelijk faalt. En als de Meester valt, zal ons systeem niet werken. We voeren een back-up uit. Sommigen stellen dat de Master moet worden gerepliceerd naar een back-up. Dit kan ook aan de Coördinatiedienst worden toevertrouwd. Maar in dit diagram is de Master zelf verantwoordelijk voor het coördineren van de werknemers; hier coördineert de dienst de gegevensreplicatieactiviteiten.
Een meer geavanceerde optie is wanneer alle coördinatie door onze dienst wordt afgehandeld, zoals gewoonlijk gebeurt. Hij neemt de verantwoordelijkheid om ervoor te zorgen dat alles werkt. En als iets niet werkt, komen we erachter en proberen we deze situatie te omzeilen. In ieder geval blijven we achter met een Meester die op de een of andere manier met slaven communiceert en via een of andere dienst gegevens, informatie, berichten, enz. kan verzenden.
Er is een nog geavanceerder schema: als we geen master hebben, zijn alle knooppunten master-slaven, verschillend in hun gedrag. Maar ze moeten nog steeds met elkaar communiceren, dus er is nog steeds een dienst over om deze acties te coördineren. Waarschijnlijk past Cassandra, die volgens dit principe werkt, in dit schema.
Het is moeilijk te zeggen welke van deze regelingen beter werkt. Elk heeft zijn eigen voor- en nadelen.
En bij de Meester hoef je voor sommige dingen niet bang te zijn, omdat hij, zoals de praktijk laat zien, niet zo vatbaar is voor voortdurend dienen. Het belangrijkste hier is om de juiste oplossing te kiezen voor het hosten van deze service op een afzonderlijk krachtig knooppunt, zodat deze over voldoende middelen beschikt, zodat gebruikers daar indien mogelijk geen toegang hebben, zodat ze dit proces niet per ongeluk beëindigen. Maar tegelijkertijd is het in een dergelijk schema veel eenvoudiger om werknemers vanuit het masterproces te beheren, d.w.z. dit schema is eenvoudiger vanuit het oogpunt van implementatie.
En dit schema (hierboven) is waarschijnlijk complexer, maar betrouwbaarder.
Het grootste probleem zijn gedeeltelijke mislukkingen. Wanneer we bijvoorbeeld een bericht via het netwerk verzenden, gebeurt er een ongeluk en degene die het bericht heeft verzonden, weet niet of zijn bericht is ontvangen en wat er aan de kant van de ontvanger is gebeurd, weet niet of het bericht correct is verwerkt. , dat wil zeggen dat hij geen bevestiging ontvangt.
Daarom moeten we deze situatie verwerken. En het eenvoudigste is om dit bericht opnieuw te verzenden en te wachten tot we een reactie ontvangen. In dit geval wordt er geen rekening mee gehouden of de toestand van de ontvanger is veranderd. Het kan zijn dat wij een bericht sturen en twee keer dezelfde gegevens toevoegen.
ZooKeeper biedt manieren om met dergelijke weigeringen om te gaan, wat ons leven ook gemakkelijker maakt.
Zoals iets eerder vermeld, is dit vergelijkbaar met het schrijven van programma's met meerdere threads, maar het belangrijkste verschil is dat in gedistribueerde applicaties die we op verschillende machines bouwen, de enige manier om te communiceren het netwerk is. In wezen is dit een architectuur die niets deelt. Elk proces of elke dienst die op één machine draait, heeft zijn eigen geheugen, zijn eigen schijf, zijn eigen processor, die hij met niemand deelt.
Als we een programma met meerdere threads op één computer schrijven, kunnen we gedeeld geheugen gebruiken om gegevens uit te wisselen. We hebben daar een contextschakelaar, processen kunnen schakelen. Dit heeft invloed op de prestaties. Aan de ene kant bestaat er niet zoiets in het programma op een cluster, maar er zijn problemen met het netwerk.
Dienovereenkomstig zijn de belangrijkste problemen die zich voordoen bij het schrijven van gedistribueerde systemen configuratie. We schrijven een soort applicatie. Als het eenvoudig is, dan coderen we allerlei getallen in de code, maar dit is lastig, want als we besluiten dat we in plaats van een time-out van een halve seconde een time-out van een seconde willen, dan moeten we de applicatie opnieuw compileren en rol alles weer uit. Het is één ding als het op één machine staat, als je het gewoon opnieuw kunt opstarten, maar als we veel machines hebben, moeten we voortdurend alles kopiëren. We moeten proberen de applicatie configureerbaar te maken.
Hier hebben we het over statische configuratie voor systeemprocessen. Dit is niet helemaal, misschien vanuit het oogpunt van het besturingssysteem, het kan een statische configuratie zijn voor onze processen, dat wil zeggen, dit is een configuratie die niet zomaar kan worden overgenomen en bijgewerkt.
Er is ook een dynamische configuratie. Dit zijn de parameters die we meteen willen veranderen, zodat ze daar worden opgepikt.
Wat is hier het probleem? We hebben de configuratie bijgewerkt en uitgerold, dus wat? Het probleem kan zijn dat we aan de ene kant de configuratie hebben uitgerold, maar het nieuwe zijn vergeten, de configuratie is daar gebleven. Ten tweede is de configuratie tijdens de uitrol op sommige plaatsen bijgewerkt, maar op andere niet. En sommige processen van onze applicatie die op één machine draaien, zijn opnieuw opgestart met een nieuwe configuratie, en ergens met een oude. Dit kan ertoe leiden dat onze gedistribueerde applicatie inconsistent is vanuit een configuratieperspectief. Dit probleem komt vaak voor. Voor een dynamische configuratie is dit relevanter omdat het impliceert dat deze in een mum van tijd kan worden gewijzigd.
Een ander probleem is het groepslidmaatschap. We hebben altijd een aantal werkers, we willen altijd weten wie van hen nog leeft, wie van hen dood is. Als er een meester is, moet hij begrijpen welke werknemers naar klanten kunnen worden doorverwezen, zodat ze berekeningen kunnen uitvoeren of met gegevens kunnen werken, en welke niet. Een probleem dat zich voortdurend voordoet, is dat we moeten weten wie er in ons cluster werkt.
Een ander typisch probleem zijn de leidersverkiezingen, waarbij we willen weten wie de leiding heeft. Een voorbeeld is replicatie, wanneer we een proces hebben dat schrijfbewerkingen ontvangt en deze vervolgens repliceert tussen andere processen. Hij zal de leider zijn, alle anderen zullen hem gehoorzamen, hem volgen. Het is noodzakelijk om een proces zo te kiezen dat het voor iedereen eenduidig is, zodat niet blijkt dat er twee leiders worden geselecteerd.
Er is ook sprake van wederzijds uitsluitende toegang. Het probleem hier is complexer. Er bestaat zoiets als een mutex, wanneer u programma's met meerdere threads schrijft en wilt dat de toegang tot een bepaalde bron, bijvoorbeeld een geheugencel, wordt beperkt en wordt uitgevoerd door slechts één thread. Hier zou de bron iets abstracters kunnen zijn. En verschillende applicaties van verschillende knooppunten van ons netwerk mogen alleen exclusieve toegang krijgen tot een bepaalde bron, en niet zodat iedereen deze kan wijzigen of er iets kan schrijven. Dit zijn de zogenaamde sloten.
Met ZooKeeper kunt u al deze problemen tot op zekere hoogte oplossen. En ik zal met voorbeelden laten zien hoe je dit kunt doen.
Er zijn geen blokkerende primitieven. Wanneer we iets gaan gebruiken, wacht deze primitief niet tot er iets gebeurt. Hoogstwaarschijnlijk zal dit ding asynchroon werken, waardoor processen niet blijven hangen terwijl ze ergens op wachten. Dit is een heel nuttig ding.
Alle klantverzoeken worden verwerkt in de volgorde van de algemene wachtrij.
En klanten hebben de mogelijkheid om notificaties te ontvangen over veranderingen in een bepaalde staat, over veranderingen in gegevens, voordat de klant de gewijzigde gegevens zelf ziet.
ZooKeeper kan in twee modi werken. De eerste is standalone, op één knooppunt. Dit is handig bij het testen. Het kan ook in clustermodus op een willekeurig aantal servers werken. Als we een cluster van 100 machines hebben, is het niet nodig dat deze op 100 machines werkt. Het volstaat om meerdere machines te selecteren waarop u ZooKeeper kunt uitvoeren. En het belijdt het principe van hoge beschikbaarheid. Op elk actief exemplaar slaat ZooKeeper een volledige kopie van de gegevens op. Hoe hij dat doet, vertel ik later. Het scheidt geen gegevens en verdeelt deze niet. Aan de ene kant is het een minpuntje dat we niet veel kunnen opslaan, aan de andere kant is het niet nodig om dit te doen. Daar is het niet voor ontworpen, het is geen database.
Gegevens kunnen aan de clientzijde in de cache worden opgeslagen. Dit is een standaardprincipe, zodat we de service niet onderbreken en niet met dezelfde verzoeken laden. Een slimme client weet dit meestal en slaat dit op in de cache.
Hier is bijvoorbeeld iets veranderd. Er is een soort toepassing. Er werd een nieuwe leider gekozen, die bijvoorbeeld verantwoordelijk is voor het verwerken van schrijfbewerkingen. En we willen de gegevens repliceren. Eén oplossing is om het in een lus te plaatsen. En we stellen onze service voortdurend in vraag: is er iets veranderd? De tweede optie is optimaaler. Dit is een bewakingsmechanisme waarmee u klanten kunt informeren dat er iets is veranderd. Dit is een goedkopere methode in termen van middelen en handiger voor klanten.
Klant is de gebruiker die ZooKeeper gebruikt.
Server is het ZooKeeper-proces zelf.
Znode is het belangrijkste in ZooKeeper. Alle znodes worden door ZooKeeper in het geheugen opgeslagen en zijn georganiseerd in de vorm van een hiërarchisch diagram, in de vorm van een boom.
Er zijn twee soorten operaties. De eerste is bijwerken/schrijven, wanneer een bewerking de status van onze boom verandert. De boom is gebruikelijk.
En het is mogelijk dat de klant één verzoek niet voltooit en de verbinding wordt verbroken, maar een sessie tot stand kan brengen waarmee hij communiceert met ZooKeeper.
Het datamodel van ZooKeeper lijkt op een bestandssysteem. Er is een standaardroot en daarna gingen we alsof we door de mappen gingen die vanaf de root gaan. En dan de catalogus van het eerste niveau, tweede niveau. Dit zijn allemaal znodes.
Elke znode kan bepaalde gegevens opslaan, meestal niet erg groot, bijvoorbeeld 10 kilobytes. En elke znode kan een bepaald aantal kinderen hebben.
Znodes zijn er in verschillende typen. Ze kunnen worden gemaakt. En bij het maken van een znode specificeren we het type waartoe deze zou moeten behoren.
Er zijn twee soorten. De eerste is de kortstondige vlag. Znode leeft binnen een sessie. De cliënt heeft bijvoorbeeld een sessie tot stand gebracht. En zolang deze sessie leeft, zal deze bestaan. Dit is nodig om niet iets onnodigs te produceren. Dit is ook geschikt voor momenten waarop het voor ons belangrijk is om dataprimitieven binnen een sessie op te slaan.
Het tweede type is een sequentiële vlag. Het verhoogt de teller op weg naar de znode. We hadden bijvoorbeeld een directory met applicatie 1_5. En toen we het eerste knooppunt creëerden, ontving het p_1, het tweede - p_2. En wanneer we deze methode elke keer aanroepen, passeren we het volledige pad, waarbij slechts een deel van het pad wordt aangegeven, en dit aantal wordt automatisch verhoogd omdat we het knooppunttype aangeven: sequentieel.
Reguliere znode. Ze zal altijd blijven leven en de naam dragen die we haar vertellen.
Een ander handig ding is de wachtvlag. Als we het installeren, kan de klant zich abonneren op bepaalde evenementen voor een specifiek knooppunt. Ik zal je later met een voorbeeld laten zien hoe dit wordt gedaan. ZooKeeper informeert de klant zelf dat de gegevens op het knooppunt zijn gewijzigd. Meldingen garanderen echter niet dat er nieuwe gegevens zijn binnengekomen. Ze zeggen simpelweg dat er iets is veranderd, dus je moet de gegevens later nog met afzonderlijke oproepen vergelijken.
En zoals ik al zei, de volgorde van de gegevens wordt bepaald door kilobytes. Het is niet nodig om daar grote tekstgegevens op te slaan, omdat het geen database is, maar een actiecoördinatieserver.
Ik zal je wat vertellen over de sessies. Als we meerdere servers hebben, kunnen we transparant van server naar server gaan met behulp van de sessie-ID. Het is best handig.
Elke sessie heeft een soort time-out. Een sessie wordt gedefinieerd door de vraag of de client tijdens die sessie iets naar de server verzendt. Als hij tijdens de time-out niets heeft verzonden, valt de sessie af of kan de cliënt deze zelf afsluiten.
Het heeft niet zoveel functies, maar je kunt verschillende dingen doen met deze API. Die oproep die we zagen creëren, creëert een znode en heeft drie parameters nodig. Dit is het pad naar de znode, en het moet volledig gespecificeerd worden vanuit de root. En dit zijn ook enkele gegevens die we daarheen willen overbrengen. En het type vlag. En na creatie retourneert het het pad naar de znode.
Ten tweede kunt u het verwijderen. De truc hier is dat de tweede parameter, naast het pad naar de znode, de versie kan specificeren. Dienovereenkomstig zal die znode worden verwijderd als de versie die we hebben overgedragen gelijk is aan de versie die feitelijk bestaat.
Als we deze versie niet willen controleren, geven we eenvoudigweg het argument "-1" door.
Ten derde controleert het op het bestaan van een znode. Retourneert true als het knooppunt bestaat, anders false.
En dan verschijnt Flag Watch, waarmee u dit knooppunt kunt monitoren.
U kunt deze vlag zelfs op een niet-bestaand knooppunt instellen en een melding ontvangen wanneer deze verschijnt. Dit kan ook nuttig zijn.
Er zijn nog een paar uitdagingen gegevens verkrijgen. Het is duidelijk dat we gegevens kunnen ontvangen via znode. Je kunt ook gebruik maken van vlaggenwacht. In dit geval wordt het niet geïnstalleerd als er geen knooppunt is. Daarom moet u begrijpen dat het bestaat en vervolgens gegevens ontvangen.
Er is ook Gegevens instellen. Hier passeren we de versie. En als we dit doorgeven, worden de gegevens op de znode van een bepaalde versie bijgewerkt.
U kunt ook "-1" opgeven om deze controle uit te sluiten.
Een andere handige methode is krijgKinderen. We kunnen ook een lijst krijgen van alle znodes die erbij horen. We kunnen dit in de gaten houden door de vlagwacht in te stellen.
En methode sync maakt het mogelijk dat alle wijzigingen in één keer worden verzonden, zodat ze worden opgeslagen en alle gegevens volledig zijn gewijzigd.
Als we analogieën trekken met conventioneel programmeren, dan is er geen garantie dat je de gegevens naar schijf hebt geschreven als je methoden als schrijven gebruikt, waarbij iets naar schijf wordt geschreven en nadat het een antwoord naar je terugstuurt. En zelfs als het besturingssysteem er zeker van is dat alles is geschreven, zijn er mechanismen op de schijf zelf waarbij het proces door bufferlagen gaat, en pas daarna worden de gegevens op de schijf geplaatst.
Meestal worden asynchrone oproepen gebruikt. Hierdoor kan de klant parallel aan verschillende verzoeken werken. Je kunt de synchrone aanpak gebruiken, maar deze is minder productief.
De twee bewerkingen waar we het over hadden zijn update/write, waarbij gegevens worden gewijzigd. Dit zijn creëren, setData, synchroniseren, verwijderen. En lees dat het bestaat, getData, getChildren.
Nu een paar voorbeelden van hoe u primitieven kunt maken voor het werken in een gedistribueerd systeem. Bijvoorbeeld gerelateerd aan de configuratie van iets. Er is een nieuwe medewerker verschenen. We hebben de machine toegevoegd en het proces gestart. En er zijn de volgende drie vragen. Hoe vraagt het ZooKeeper om configuratie? En als we de configuratie willen veranderen, hoe veranderen we die dan? En hoe krijgen de werknemers die we hadden het, nadat we het veranderd hebben?
ZooKeeper maakt dit relatief eenvoudig. Er is bijvoorbeeld onze znodeboom. Er is hier een knooppunt voor onze applicatie, we creëren er een extra knooppunt in, dat gegevens uit de configuratie bevat. Dit kunnen al dan niet afzonderlijke parameters zijn. Omdat het formaat klein is, is de configuratiegrootte meestal ook klein, dus het is heel goed mogelijk om het hier op te slaan.
Je gebruikt de methode gegevens verkrijgen om de configuratie voor de werker van het knooppunt op te halen. Ingesteld op waar. Als dit knooppunt om de een of andere reden niet bestaat, worden we hierover geïnformeerd wanneer het verschijnt of wanneer het verandert. Als we willen weten dat er iets is veranderd, zetten we het op waar. En als de gegevens in dit knooppunt veranderen, zullen we hiervan op de hoogte zijn.
Gegevens instellen. We stellen de gegevens in, stellen “-1” in, d.w.z. we controleren de versie niet, we gaan ervan uit dat we altijd één configuratie hebben, we hoeven niet veel configuraties op te slaan. Als je veel moet opslaan, moet je nog een niveau toevoegen. Hier zijn we van mening dat er maar één is, dus werken we alleen de nieuwste versie bij, dus we controleren de versie niet. Op dit moment ontvangen alle klanten die zich eerder hebben geabonneerd een melding dat er iets is gewijzigd in dit knooppunt. En nadat ze die hebben ontvangen, moeten ze de gegevens ook opnieuw opvragen. De melding is dat zij niet de gegevens zelf ontvangen, maar alleen melding van wijzigingen. Hierna moeten ze nieuwe gegevens opvragen.
De tweede optie voor het gebruik van de primitief is groepslidmaatschap. We hebben een gedistribueerde applicatie, er zijn een aantal werknemers en we willen begrijpen dat ze allemaal op hun plaats zijn. Daarom moeten ze zelf registreren dat ze in onze applicatie werken. En we willen ook meer te weten komen, hetzij vanuit het masterproces, hetzij ergens anders, over alle actieve werknemers die we momenteel hebben.
Hoe doen we dit? Voor de toepassing maken we een worker-knooppunt en voegen daar een subniveau toe met behulp van de create-methode. Ik heb een fout op de dia. Hier heb je nodig sequentiële opgeven, dan worden alle werknemers één voor één gemaakt. En de applicatie, die alle gegevens over de kinderen van dit knooppunt opvraagt, ontvangt alle bestaande actieve werkers.
Dit is zo'n vreselijke implementatie van hoe dit in Java-code kan worden gedaan. Laten we vanaf het einde beginnen, met de hoofdmethode. Dit is onze klasse, laten we de methode ervan maken. Als eerste argument gebruiken we host, waar we verbinding maken, dat wil zeggen dat we het als argument instellen. En het tweede argument is de naam van de groep.
Hoe komt de verbinding tot stand? Dit is een eenvoudig voorbeeld van de API die wordt gebruikt. Alles is hier relatief eenvoudig. Er is een standaardklasse ZooKeeper. We geven er gastheren aan door. En stel de time-out bijvoorbeeld in op 5 seconden. En we hebben een lid genaamd connectedSignal. In wezen creëren we een groep langs het verzonden pad. We schrijven daar geen gegevens, ook al had er iets geschreven kunnen worden. En het knooppunt hier is van het persistente type. In wezen is dit een gewoon regulier knooppunt dat altijd zal bestaan. Hier wordt de sessie aangemaakt. Dit is de implementatie van de klant zelf. Onze klant zal periodieke berichten sturen om aan te geven dat de sessie leeft. En als we de sessie beëindigen, bellen we close en dat is alles, de sessie mislukt. Dit is voor het geval er voor ons iets misgaat, zodat ZooKeeper erachter komt en de sessie beëindigt.
Hoe een bron vergrendelen? Hier is alles een beetje ingewikkelder. We hebben een aantal werkers, er is een bron die we willen vergrendelen. Om dit te doen, maken we een apart knooppunt, bijvoorbeeld lock1. Als we het konden maken, dan hebben we hier een slot. En als we het niet kunnen maken, probeert de werker getData hier vandaan te halen, en aangezien het knooppunt al is gemaakt, plaatsen we hier een watcher en op het moment dat de status van dit knooppunt verandert, zullen we hiervan op de hoogte zijn. En we kunnen proberen tijd te hebben om het opnieuw te creëren. Als we dit knooppunt hebben genomen, dit slot hebben genomen, zullen we het verlaten nadat we het slot niet langer nodig hebben, omdat het knooppunt alleen binnen de sessie bestaat. Dienovereenkomstig zal het verdwijnen. En een andere klant zal, in het kader van een andere sessie, het slot op dit knooppunt kunnen overnemen, of beter gezegd, hij zal een melding ontvangen dat er iets is veranderd en hij kan proberen dit op tijd te doen.
Nog een voorbeeld van hoe je de hoofdleider kunt kiezen. Dit is iets ingewikkelder, maar ook relatief eenvoudig. Wat is hier aan de hand? Er is een hoofdknooppunt dat alle werknemers verzamelt. We proberen gegevens over de leider te krijgen. Als dit met succes is gebeurd, d.w.z. we hebben enkele gegevens ontvangen, dan begint onze medewerker deze leider te volgen. Hij gelooft dat er al een leider is.
Als de leider om de een of andere reden stierf, bijvoorbeeld viel, proberen we een nieuwe leider te creëren. En als we daarin slagen, wordt onze werker de leider. En als iemand er op dit moment in slaagt een nieuwe leider te creëren, dan proberen we te begrijpen wie het is en hem dan te volgen.
Hier ontstaat het zogenaamde kudde-effect, d.w.z. het kudde-effect, want wanneer een leider sterft, zal degene die als eerste op tijd is de leider worden.
Bij het vastleggen van een hulpbron kunt u proberen een iets andere aanpak te gebruiken, namelijk als volgt. We willen bijvoorbeeld een slot krijgen, maar zonder het hert-effect. Het zal bestaan uit het feit dat onze applicatie lijsten opvraagt van alle knooppunt-ID's voor een reeds bestaand knooppunt met een slot. En als daarvoor het knooppunt waarvoor we een slot hebben gemaakt de kleinste is van de set die we hebben ontvangen, dan betekent dit dat we het slot hebben vastgelegd. We controleren of we een slot hebben ontvangen. Ter controle zal er als voorwaarde gesteld worden dat de id die wij ontvangen hebben bij het aanmaken van een nieuw slot minimaal is. En als we het hebben ontvangen, werken we verder.
Als er een bepaalde id is die kleiner is dan ons slot, dan zetten we een watcher op deze gebeurtenis en wachten we op melding totdat er iets verandert. Dat wil zeggen, we hebben dit slot ontvangen. En totdat het eraf valt, zullen we niet de minimale ID worden en niet de minimale vergrendeling ontvangen, en dus kunnen we inloggen. En als aan deze voorwaarde niet wordt voldaan, gaan we meteen hierheen en proberen dit slot opnieuw te bemachtigen, omdat er in deze tijd mogelijk iets is veranderd.
Waaruit bestaat ZooKeeper? Er zijn 4 belangrijke dingen. Dit zijn verwerkingsprocessen - Verzoek. En ook ZooKeeper Atomic Broadcast. Er is een Commit Log waarin alle handelingen worden vastgelegd. En de In-memory Replicated DB zelf, dat wil zeggen de database zelf waarin deze hele boom is opgeslagen.
Het is vermeldenswaard dat alle schrijfbewerkingen via de Request Processor verlopen. En leesbewerkingen gaan rechtstreeks naar de In-memory database.
De database zelf is volledig gerepliceerd. Alle exemplaren van ZooKeeper slaan een volledige kopie van de gegevens op.
Om de database na een crash te herstellen, is er een Commit-log. De standaardpraktijk is dat voordat gegevens in het geheugen terechtkomen, deze daar worden geschreven, zodat dit logboek kan worden afgespeeld als de gegevens vastlopen en de systeemstatus kan worden hersteld. En er wordt ook gebruik gemaakt van periodieke snapshots van de database.
ZooKeeper Atomic Broadcast is iets dat wordt gebruikt om gerepliceerde gegevens te behouden.
ZAB selecteert intern een leider vanuit het oogpunt van het ZooKeeper-knooppunt. Andere knooppunten worden haar volgers en verwachten bepaalde acties van haar. Als ze inzendingen ontvangen, sturen ze deze allemaal door naar de leider. Hij voert eerst een schrijfoperatie uit en stuurt vervolgens een bericht naar zijn volgers over wat er is veranderd. Dit moet in feite atomair worden uitgevoerd, d.w.z. de opname- en uitzendoperatie van het geheel moet atomair worden uitgevoerd, waardoor de consistentie van de gegevens wordt gegarandeerd.
Het verwerkt alleen schrijfverzoeken. De belangrijkste taak is dat het de operatie omzet in een transactionele update. Dit is een speciaal gegenereerd verzoek.
En hier is het vermeldenswaard dat de idempotentie van updates voor dezelfde bewerking gegarandeerd is. Wat het is? Als dit ding twee keer wordt uitgevoerd, zal het dezelfde status hebben, dat wil zeggen dat het verzoek zelf niet zal veranderen. En dit moet worden gedaan zodat u in geval van een crash de bewerking opnieuw kunt starten en daarmee de wijzigingen kunt terugdraaien die op dat moment zijn mislukt. In dit geval zal de toestand van het systeem hetzelfde worden, dat wil zeggen dat het niet zo mag zijn dat een reeks van dezelfde, bijvoorbeeld updateprocessen, tot verschillende eindtoestanden van het systeem heeft geleid.
Bron: www.habr.com