Us recomano que llegiu la transcripció de la conferència "Hadoop. ZooKeeper" de la sèrie "Mètodes per al processament distribuït de grans volums de dades a Hadoop"
Què és ZooKeeper, el seu lloc a l'ecosistema Hadoop. Falses veritats sobre la informàtica distribuïda. Esquema d'un sistema distribuït estàndard. Dificultat per coordinar sistemes distribuïts. Problemes típics de coordinació. Els principis darrere del disseny de ZooKeeper. Model de dades ZooKeeper. banderes znode. Sessions. API de client. Primitives (configuració, pertinença a grups, bloquejos simples, elecció de líder, bloqueig sense efecte ramat). Arquitectura ZooKeeper. ZooKeeper DB. ZAB. Gestor de sol·licituds.
Avui parlarem de ZooKeeper. Aquesta cosa és molt útil. Com qualsevol producte Apache Hadoop, té un logotip. Representa un home.
Abans d'això, vam parlar principalment de com es poden processar les dades allà, com emmagatzemar-les, és a dir, com utilitzar-les d'alguna manera i treballar-hi d'alguna manera. I avui m'agradaria parlar una mica de la creació d'aplicacions distribuïdes. I ZooKeeper és una d'aquestes coses que us permet simplificar aquesta qüestió. Es tracta d'una mena de servei que està destinat a algun tipus de coordinació de la interacció de processos en sistemes distribuïts, en aplicacions distribuïdes.
La necessitat d'aquest tipus d'aplicacions és cada dia més gran, d'això es tracta el nostre curs. D'una banda, MapReduce i aquest framework ja fet permet anivellar aquesta complexitat i alliberar el programador d'escriure primitives com la interacció i la coordinació de processos. Però, d'altra banda, ningú garanteix que això no s'haurà de fer de totes maneres. MapReduce o altres marcs preparats no sempre substitueixen completament alguns casos que no es poden implementar amb això. Incloent el mateix MapReduce i un munt d'altres projectes Apache, de fet, també són aplicacions distribuïdes. I per facilitar l'escriptura, van escriure ZooKeeper.
Com totes les aplicacions relacionades amb Hadoop, va ser desenvolupat per Yahoo! Ara també és una aplicació oficial d'Apache. No està desenvolupat tan activament com l'HBase. Si aneu a JIRA HBase, cada dia hi ha un munt d'informes d'errors, un munt de propostes per optimitzar alguna cosa, és a dir, la vida al projecte continua constantment. I ZooKeeper, d'una banda, és un producte relativament senzill i, d'altra banda, això garanteix la seva fiabilitat. I és bastant fàcil d'utilitzar, per això s'ha convertit en un estàndard en aplicacions dins de l'ecosistema Hadoop. Així que vaig pensar que seria útil revisar-lo per entendre com funciona i com utilitzar-lo.
Aquesta és una imatge d'una conferència que hem fet. Podem dir que és ortogonal a tot el que hem considerat fins ara. I tot el que aquí s'indica, en un grau o altre, funciona amb ZooKeeper, és a dir, és un servei que utilitza tots aquests productes. Ni HDFS ni MapReduce escriuen els seus propis serveis similars que els funcionin específicament. En conseqüència, s'utilitza ZooKeeper. I això simplifica el desenvolupament i algunes coses relacionades amb errors.
D'on ve tot això? Sembla que hem llançat dues aplicacions en paral·lel en ordinadors diferents, les hem connectat amb una cadena o en una malla, i tot funciona. Però el problema és que la Xarxa no és fiable, i si vau ensumar el trànsit o mireu el que hi passa a un nivell baix, com interactuen els clients a la Xarxa, sovint podeu veure que alguns paquets es perden o es tornen a enviar. No debades es van inventar els protocols TCP, que permeten establir una sessió determinada i garantir el lliurament dels missatges. Però en qualsevol cas, fins i tot TCP no sempre us pot salvar. Tot té un temps mort. La xarxa pot simplement caure durant un temps. Potser només parpelleja. I tot això porta al fet que no podeu confiar que la xarxa sigui fiable. Aquesta és la principal diferència d'escriure aplicacions paral·leles que s'executen en un ordinador o en un superordinador, on no hi ha xarxa, on hi ha un bus d'intercanvi de dades més fiable a la memòria. I aquesta és una diferència fonamental.
Entre altres coses, quan s'utilitza la Xarxa, sempre hi ha una certa latència. El disc també en té, però la xarxa en té més. La latència és un temps de retard, que pot ser petit o bastant significatiu.
La topologia de la xarxa està canviant. Què és la topologia: aquesta és la ubicació del nostre equip de xarxa. Hi ha centres de dades, hi ha bastidors que hi ha, hi ha espelmes. Tot això es pot tornar a connectar, moure, etc. Tot això també s'ha de tenir en compte. Els noms IP canvien, canvia l'encaminament pel qual viatja el nostre trànsit. Això també s'ha de tenir en compte.
La xarxa també pot canviar pel que fa als equips. Des de la pràctica, puc dir que als nostres enginyers de xarxa els agrada molt actualitzar periòdicament alguna cosa a les espelmes. De sobte, va sortir un nou firmware i no els interessava especialment algun clúster Hadoop. Tenen la seva pròpia feina. Per a ells, el més important és que la Xarxa funcioni. En conseqüència, volen tornar a carregar alguna cosa allà, fer un parpelleig al seu maquinari i el maquinari també canvia periòdicament. Tot això d'alguna manera s'ha de tenir en compte. Tot això afecta la nostra aplicació distribuïda.
En general, les persones que comencen a treballar amb grans quantitats de dades per algun motiu creuen que Internet és il·limitat. Si hi ha un fitxer de diversos terabytes, podeu portar-lo al vostre servidor o ordinador i obrir-lo gat i mira. Hi ha un altre error empenta mira els registres. No ho facis mai perquè és dolent. Com que Vim intenta guardar-ho tot, carregar-ho tot a la memòria, sobretot quan comencem a moure's per aquest registre i buscar alguna cosa. Són coses que s'obliden, però val la pena tenir-les en compte.
És més fàcil escriure un programa que s'executi en un ordinador amb un processador.
Quan el nostre sistema creixi, volem paral·lelitzar-ho tot i paral·lelitzar-lo no només en un ordinador, sinó també en un clúster. La pregunta sorgeix: com coordinar aquesta qüestió? És possible que les nostres aplicacions ni tan sols interactuïn entre elles, però vam executar diversos processos en paral·lel en diversos servidors. I com controlar que tot els va bé? Per exemple, envien alguna cosa per Internet. Han d'escriure sobre el seu estat en algun lloc, per exemple, en algun tipus de base de dades o registre, després agregar aquest registre i després analitzar-lo en algun lloc. A més, hem de tenir en compte que el procés funcionava i funcionava, de sobte hi va aparèixer algun error o es va estavellar, aleshores amb quina rapidesa ho sabrem?
Està clar que tot això es pot controlar ràpidament. Això també és bo, però la supervisió és una cosa limitada que us permet controlar algunes coses al més alt nivell.
Quan volem que els nostres processos comencin a interactuar entre ells, per exemple, per enviar-nos algunes dades, també sorgeix la pregunta: com passarà això? Hi haurà algun tipus de condició de carrera, es sobreescriuran, les dades arribaran correctament, es perdrà alguna cosa pel camí? Hem de desenvolupar algun tipus de protocol, etc.
La coordinació de tots aquests processos no és una cosa trivial. I obliga el desenvolupador a baixar a un nivell encara més baix i escriure sistemes des de zero, o no del tot des de zero, però això no és tan senzill.
Si teniu un algorisme criptogràfic o fins i tot l'implementau, llenceu-lo immediatament, perquè el més probable és que no us funcioni. Probablement contindrà un munt d'errors que heu oblidat de proporcionar. No l'utilitzeu mai per a res greu, ja que probablement serà inestable. Perquè tots els algorismes que existeixen han estat provats pel temps durant molt de temps. Està molestat per la comunitat. Aquest és un tema a part. I aquí és el mateix. Si és possible no implementar algun tipus de sincronització de processos, és millor no fer-ho, perquè és bastant complicat i us condueix pel camí inestable de la recerca constant d'errors.
Avui parlem de ZooKeeper. D'una banda, és un framework, de l'altra, és un servei que facilita la vida al desenvolupador i simplifica al màxim la implementació de la lògica i la coordinació dels nostres processos.
Recordem com podria ser un sistema distribuït estàndard. Això és del que hem parlat: HDFS, HBase. Hi ha un procés Mestre que gestiona els processos treballadors i esclaus. S'encarrega de coordinar i distribuir les tasques, reiniciar els treballadors, llançar-ne de nous i distribuir la càrrega.
Una cosa més avançada és el Servei de Coordinació, és a dir, moure la tasca de coordinació en si mateixa a un procés separat, a més d'executar algun tipus de còpia de seguretat o Mestre en espera en paral·lel, perquè el Mestre pot fallar. I si cau el Mestre, el nostre sistema no funcionarà. Estem executant còpies de seguretat. Alguns estats indiquen que el mestre s'ha de replicar a la còpia de seguretat. Això també es pot encarregar al Servei de Coordinació. Però en aquest diagrama, el mateix Mestre s'encarrega de coordinar els treballadors aquí el servei coordina les activitats de replicació de dades.
Una opció més avançada és quan tota la coordinació la gestiona el nostre servei, com es fa habitualment. Ell assumeix la responsabilitat d'assegurar-se que tot funcioni. I si alguna cosa no funciona, ens n'assabentem i intentem evitar aquesta situació. En qualsevol cas, ens queda un Mestre que d'alguna manera interactua amb els esclaus i pot enviar dades, informació, missatges, etc. a través d'algun servei.
Hi ha un esquema encara més avançat, quan no tenim un Mestre, tots els nodes són esclaus mestres, diferents en el seu comportament. Però encara necessiten interactuar entre ells, així que encara queda algun servei per coordinar aquestes accions. Probablement, Cassandra, que treballa en aquest principi, s'ajusta a aquest esquema.
És difícil dir quin d'aquests esquemes funciona millor. Cadascun té els seus pros i contres.
I no cal tenir por d'algunes coses amb el Mestre, perquè, com demostra la pràctica, no és tan susceptible de servir constantment. El més important aquí és triar la solució adequada per allotjar aquest servei en un node potent separat, de manera que tingui prou recursos, de manera que, si és possible, els usuaris no hi tinguin accés, de manera que no materen accidentalment aquest procés. Però al mateix temps, en aquest esquema és molt més fàcil gestionar els treballadors des del procés Màster, és a dir, aquest esquema és més senzill des del punt de vista de la implementació.
I aquest esquema (a dalt) és probablement més complex, però més fiable.
El principal problema són les fallades parcials. Per exemple, quan enviem un missatge a través de la Xarxa, es produeix algun tipus d'accident, i qui ha enviat el missatge no sabrà si el seu missatge s'ha rebut i què ha passat per part del receptor, no sabrà si el missatge s'ha processat correctament. , és a dir, no rebrà cap confirmació.
En conseqüència, hem de processar aquesta situació. I el més senzill és tornar a enviar aquest missatge i esperar fins que rebem una resposta. En aquest cas, no es té en compte si l'estat del receptor ha canviat. És possible que enviem un missatge i afegim les mateixes dades dues vegades.
ZooKeeper ofereix maneres de fer front a aquestes denegacions, la qual cosa també ens facilita la vida.
Com s'ha esmentat una mica abans, això és similar a escriure programes multifils, però la diferència principal és que a les aplicacions distribuïdes que construïm en diferents màquines, l'única manera de comunicar-nos és la xarxa. Essencialment, es tracta d'una arquitectura de res compartit. Cada procés o servei que s'executa en una màquina té la seva pròpia memòria, el seu propi disc, el seu propi processador, que no comparteix amb ningú.
Si escrivim un programa multifils en un ordinador, podem utilitzar la memòria compartida per intercanviar dades. Tenim un canvi de context allà, els processos poden canviar. Això afecta el rendiment. D'una banda, no hi ha tal cosa al programa en un clúster, però hi ha problemes amb la Xarxa.
En conseqüència, els principals problemes que sorgeixen en escriure sistemes distribuïts són la configuració. Estem escrivint algun tipus d'aplicació. Si és senzill, codifiquem tot tipus de números al codi, però això és inconvenient, perquè si decidim que en comptes d'un temps d'espera de mig segon volem un temps d'espera d'un segon, llavors hem de recompilar l'aplicació i torna a desplegar-ho tot. Una cosa és quan està en una màquina, quan només el podeu reiniciar, però quan tenim moltes màquines, ho hem de copiar tot constantment. Hem d'intentar que l'aplicació sigui configurable.
Aquí estem parlant de la configuració estàtica dels processos del sistema. Això no és del tot, potser des del punt de vista del sistema operatiu, pot ser una configuració estàtica dels nostres processos, és a dir, es tracta d'una configuració que no es pot prendre i actualitzar simplement.
També hi ha una configuració dinàmica. Aquests són els paràmetres que volem canviar sobre la marxa perquè es recullin allà.
Quin és el problema aquí? Hem actualitzat la configuració, la vam llançar, i què? El problema pot ser que, d'una banda, vam desplegar la configuració, però ens vam oblidar del nou, la configuració va romandre allà. En segon lloc, mentre estàvem desplegant, la configuració es va actualitzar en alguns llocs, però no en altres. I alguns processos de la nostra aplicació que s'executen en una màquina es van reiniciar amb una configuració nova i en algun lloc amb una d'antiga. Això pot provocar que la nostra aplicació distribuïda sigui inconsistent des d'una perspectiva de configuració. Aquest problema és comú. Per a una configuració dinàmica, és més rellevant perquè implica que es pot canviar sobre la marxa.
Un altre problema és la pertinença al grup. Sempre tenim algun conjunt de treballadors, sempre volem saber quin d'ells és viu, quin d'ells és mort. Si hi ha un mestre, llavors ha d'entendre quins treballadors es poden redirigir als clients perquè facin càlculs o treballin amb dades, i quins no. Un problema que sorgeix constantment és que necessitem saber qui treballa al nostre clúster.
Un altre problema típic són les eleccions de líders, quan volem saber qui està al capdavant. Un exemple és la replicació, quan tenim algun procés que rep operacions d'escriptura i després les replica entre altres processos. Ell serà el líder, tots els altres l'obeiran, el seguiran. Cal escollir un procés perquè sigui inequívoc per a tothom, perquè no resulti que es seleccionen dos líders.
També hi ha un accés mútuament exclusiu. El problema aquí és més complex. Hi ha una cosa com un mutex, quan escriu programes multifils i vols que l'accés a algun recurs, per exemple, una cel·la de memòria, estigui limitat i dut a terme per un sol fil. Aquí el recurs podria ser quelcom més abstracte. I diferents aplicacions de diferents nodes de la nostra Xarxa només haurien de rebre accés exclusiu a un recurs determinat, i no perquè tothom pugui canviar-lo o escriure-hi alguna cosa. Aquests són els anomenats panys.
ZooKeeper us permet resoldre tots aquests problemes en un grau o un altre. I mostraré amb exemples com et permet fer-ho.
No hi ha primitives de bloqueig. Quan comencem a utilitzar alguna cosa, aquest primitiu no esperarà que es produeixi cap esdeveniment. El més probable és que això funcioni de manera asíncrona, permetent així que els processos no es pengin mentre estan esperant alguna cosa. Això és una cosa molt útil.
Totes les sol·licituds dels clients es processen en l'ordre de la cua general.
I els clients tenen l'oportunitat de rebre notificacions sobre canvis en algun estat, sobre canvis en les dades, abans que el client vegi les dades modificades.
ZooKeeper pot funcionar en dos modes. El primer és autònom, en un sol node. Això és convenient per a proves. També pot funcionar en mode clúster, en qualsevol nombre de nodes. servidorsSi tenim un clúster de 100 màquines, no necessàriament ha d'executar-se en 100 màquines. N'hi ha prou amb assignar unes quantes màquines on ZooKeeper pugui executar-se. I s'adhereix al principi d'alta disponibilitat. ZooKeeper emmagatzema una còpia completa de les dades a cada instància en execució. Explicaré com ho fa més endavant. No fragmenta ni particiona les dades. D'una banda, això és un desavantatge perquè no podem emmagatzemar gaire, però de l'altra, és innecessari. No està dissenyat per a això; no és una base de dades.
Les dades es poden emmagatzemar a la memòria cau al costat del client. Aquest és un principi estàndard perquè no interrompem el servei i no el carreguem amb les mateixes peticions. Un client intel·ligent normalment ho sap i ho guarda a la memòria cau.
Per exemple, alguna cosa ha canviat aquí. Hi ha algun tipus d'aplicació. Va ser escollit un nou líder, responsable, per exemple, de processar les operacions d'escriptura. I volem replicar les dades. Una solució és posar-lo en bucle. I qüestionem constantment el nostre servei: ha canviat alguna cosa? La segona opció és més òptima. Aquest és un mecanisme de rellotge que us permet notificar als clients que alguna cosa ha canviat. Aquest és un mètode menys costós en termes de recursos i més convenient per als clients.
El client és l'usuari que utilitza ZooKeeper.
El servidor és el propi procés ZooKeeper.
Znode és la clau de ZooKeeper. Tots els znodes s'emmagatzemen a la memòria per ZooKeeper i s'organitzen en forma de diagrama jeràrquic, en forma d'arbre.
Hi ha dos tipus d'operacions. El primer és l'actualització/escriptura, quan alguna operació canvia l'estat del nostre arbre. L'arbre és comú.
I és possible que el client no completi una sol·licitud i es desconnecti, però pugui establir una sessió mitjançant la qual interactua amb ZooKeeper.
El model de dades de ZooKeeper s'assembla a un sistema de fitxers. Hi ha una arrel estàndard i després vam anar com si fossin pels directoris que van des de l'arrel. I després el catàleg de primer nivell, segon nivell. Això és tot znodes.
Cada znode pot emmagatzemar algunes dades, normalment no molt grans, per exemple, 10 kilobytes. I cada znode pot tenir un nombre determinat de fills.
Els Znodes vénen de diversos tipus. Es poden crear. I en crear un znode, especifiquem el tipus al qual hauria de pertànyer.
N'hi ha de dos tipus. La primera és la bandera efímera. Znode viu dins d'una sessió. Per exemple, el client ha establert una sessió. I mentre aquesta sessió sigui viva, existirà. Això és necessari per no produir alguna cosa innecessària. Això també és adequat per als moments en què és important per a nosaltres emmagatzemar dades primitives dins d'una sessió.
El segon tipus és la bandera seqüencial. Incrementa el comptador en el camí cap al znode. Per exemple, teníem un directori amb l'aplicació 1_5. I quan vam crear el primer node, va rebre p_1, el segon - p_2. I quan anomenem aquest mètode cada vegada, passem el camí complet, indicant només una part del camí, i aquest nombre s'incrementa automàticament perquè indiquem el tipus de node - seqüencial.
Znode regular. Sempre viurà i tindrà el nom que li diem.
Una altra cosa útil és la bandera del rellotge. Si l'instal·lem, el client pot subscriure's a alguns esdeveniments per a un node específic. Més endavant us mostraré amb un exemple de com es fa. El mateix ZooKeeper notifica al client que les dades del node han canviat. Tanmateix, les notificacions no garanteixen que hagin arribat algunes dades noves. Simplement diuen que alguna cosa ha canviat, així que encara haureu de comparar dades més endavant amb trucades separades.
I com ja he dit, l'ordre de les dades ve determinat per kilobytes. No cal emmagatzemar-hi dades de text grans, perquè no és una base de dades, és un servidor de coordinació d'accions.
Deixa'm que t'expliqui una mica sobre les sessions. Si tenim diversos servidors, podem canviar d'un servidor a un altre de manera transparent. servidor, utilitzant l'ID de sessió. Això és força convenient.
Cada sessió té algun tipus de temps d'espera. Una sessió es defineix per si el client envia alguna cosa al servidor durant aquesta sessió. Si no va transmetre res durant el temps mort, la sessió cau o el client pot tancar-la ell mateix.
No té tantes funcions, però podeu fer coses diferents amb aquesta API. Aquesta trucada que vam veure crear crea un znode i pren tres paràmetres. Aquest és el camí cap al znode i s'ha d'especificar completament des de l'arrel. I també aquestes són algunes dades que volem transferir-hi. I el tipus de bandera. I després de la creació, torna el camí cap al znode.
En segon lloc, podeu esborrar-lo. El truc aquí és que el segon paràmetre, a més del camí cap al znode, pot especificar la versió. En conseqüència, aquest znode s'eliminarà si la seva versió que hem transferit és equivalent a la que existeix realment.
Si no volem comprovar aquesta versió, simplement passem l'argument "-1".
En tercer lloc, comprova l'existència d'un znode. Retorna true si el node existeix, false en cas contrari.
I després apareix el rellotge de la bandera, que us permet supervisar aquest node.
Podeu establir aquesta marca fins i tot en un node inexistent i rebre una notificació quan aparegui. Això també pot ser útil.
Hi ha un parell de reptes més getData. Està clar que podem rebre dades a través de znode. També podeu utilitzar el rellotge de bandera. En aquest cas, no s'instal·larà si no hi ha cap node. Per tant, cal entendre que existeix i després rebre dades.
També hi ha SetData. Aquí passem la versió. I si ho transmetem, s'actualitzaran les dades del znode d'una determinada versió.
També podeu especificar "-1" per excloure aquesta comprovació.
Un altre mètode útil és getChildren. També podem obtenir una llista de tots els znodes que hi pertanyen. Podem controlar-ho configurant el control de bandera.
I mètode sync permet que tots els canvis s'enviïn alhora, assegurant així que es guarden i que totes les dades s'han canviat completament.
Si fem analogies amb la programació habitual, quan utilitzeu mètodes com escriure, que escriuen alguna cosa al disc, i després que us retorni una resposta, no hi ha cap garantia que hàgiu escrit les dades al disc. I fins i tot quan el sistema operatiu està segur que tot s'ha escrit, hi ha mecanismes al propi disc on el procés passa per capes de memòria intermèdia, i només després d'això, les dades es col·loquen al disc.
S'utilitzen majoritàriament trucades asíncrones. Això permet al client treballar en paral·lel amb diferents peticions. Podeu utilitzar l'enfocament sincrònic, però és menys productiu.
Les dues operacions de les quals hem parlat són actualització/escriptura, que canvien les dades. Aquests són create, setData, sync, delete. I read is existeix, getData, getChildren.
Ara uns quants exemples de com podeu crear primitives per treballar en un sistema distribuït. Per exemple, relacionat amb la configuració d'alguna cosa. Ha aparegut un nou treballador. Hem afegit la màquina i hem començat el procés. I hi ha les tres preguntes següents. Com consulta ZooKeeper per a la configuració? I si volem canviar la configuració, com la canviem? I després de canviar-lo, com ho aconsegueixen els treballadors que teníem?
ZooKeeper fa que això sigui relativament fàcil. Per exemple, hi ha el nostre arbre znode. Aquí hi ha un node per a la nostra aplicació, hi creem un node addicional, que conté dades de la configuració. Aquests poden ser o no paràmetres separats. Com que la mida és petita, la mida de la configuració també sol ser petita, de manera que és molt possible emmagatzemar-la aquí.
Estàs utilitzant el mètode getData per obtenir la configuració del treballador des del node. Estableix com a vertader. Si per algun motiu aquest node no existeix, se'ns informarà quan aparegui, o quan canviï. Si volem saber que alguna cosa ha canviat, ho posem en veritat. I si les dades d'aquest node canvien, ho sabrem.
SetData. Establem les dades, posem “-1”, és a dir, no comprovem la versió, suposem que sempre tenim una configuració, no necessitem emmagatzemar moltes configuracions. Si necessiteu emmagatzemar molt, haureu d'afegir un altre nivell. Aquí creiem que només n'hi ha un, de manera que només actualitzem l'últim, així que no comprovem la versió. En aquest moment, tots els clients que s'han subscrit prèviament reben una notificació que alguna cosa ha canviat en aquest node. I després d'haver-lo rebut, també han de tornar a sol·licitar les dades. La notificació és que no reben les dades en si, sinó només la notificació dels canvis. Després d'això han de demanar noves dades.
La segona opció per utilitzar el primitiu és pertinença al grup. Tenim una aplicació distribuïda, hi ha un munt de treballadors i volem entendre que tots estan al seu lloc. Per tant, han de registrar-se que treballen a la nostra aplicació. I també volem conèixer, ja sigui des del procés de Màster o en un altre lloc, tots els treballadors actius que tenim actualment.
Com ho fem això? Per a l'aplicació, creem un node de treball i hi afegim un subnivell mitjançant el mètode create. Tinc un error a la diapositiva. Aquí ho necessites seqüencial especifiqueu, llavors tots els treballadors es crearan un per un. I l'aplicació, sol·licitant totes les dades sobre els fills d'aquest node, rep tots els treballadors actius que hi ha.
Aquesta és una implementació tan terrible de com es pot fer això en codi Java. Comencem pel final, amb el mètode principal. Aquesta és la nostra classe, anem a crear el seu mètode. Com a primer argument fem servir host, on ens connectem, és a dir, el posem com a argument. I el segon argument és el nom del grup.
Com es produeix la connexió? Aquest és un exemple senzill de l'API que s'utilitza. Aquí tot és relativament senzill. Hi ha un ZooKeeper de classe estàndard. Li passem hostes. I establiu el temps d'espera, per exemple, a 5 segons. I tenim un membre anomenat ConnectedSignal. Bàsicament, creem un grup al llarg del camí transmès. No hi escrivim dades, tot i que es podria haver escrit alguna cosa. I el node aquí és del tipus persistent. Essencialment, aquest és un node normal normal que existirà tot el temps. Aquí és on es crea la sessió. Aquesta és la implementació del propi client. El nostre client enviarà missatges periòdics indicant que la sessió està viva. I quan acabem la sessió, truquem a tancament i ja està, la sessió cau. Això és per si ens cau alguna cosa, de manera que ZooKeeper se n'assabenta i talli la sessió.
Com bloquejar un recurs? Aquí tot és una mica més complicat. Tenim un conjunt de treballadors, hi ha algun recurs que volem bloquejar. Per fer-ho, creem un node separat, per exemple, anomenat lock1. Si hem pogut crear-lo, aquí tenim un bloqueig. I si no hem pogut crear-lo, aleshores el treballador intenta obtenir getData des d'aquí, i com que el node ja s'ha creat, posem aquí un observador i en el moment que canviï l'estat d'aquest node, ho sabrem. I podem intentar tenir temps per recrear-lo. Si vam treure aquest node, vam treure aquest bloqueig, després que ja no necessitem el bloqueig, l'abandonarem, ja que el node només existeix dins de la sessió. En conseqüència, desapareixerà. I un altre client, en el marc d'una altra sessió, podrà agafar el bloqueig d'aquest node, o millor dit, rebrà una notificació que alguna cosa ha canviat i pot intentar fer-ho a temps.
Un altre exemple de com es pot triar el líder principal. Això és una mica més complicat, però també relativament senzill. Que està passant aquí? Hi ha un node principal que agrupa tots els treballadors. Estem intentant obtenir dades sobre el líder. Si això va passar amb èxit, és a dir, vam rebre algunes dades, el nostre treballador comença a seguir aquest líder. Creu que ja hi ha un líder.
Si el líder va morir per algun motiu, per exemple, es va caure, llavors intentem crear un nou líder. I si ho aconseguim, el nostre treballador esdevé el líder. I si algú en aquest moment va aconseguir crear un nou líder, llavors intentem entendre qui és i després seguir-lo.
Aquí sorgeix l'anomenat efecte ramat, és a dir, l'efecte ramat, perquè quan mor un líder, el que és el primer en el temps es convertirà en líder.
Quan captureu un recurs, podeu provar d'utilitzar un enfocament lleugerament diferent, que és el següent. Per exemple, volem obtenir un bloqueig, però sense l'efecte hert. Consistirà en el fet que la nostra aplicació demana llistes de tots els identificadors de nodes per a un node ja existent amb un bloqueig. I si abans el node per al qual hem creat un bloqueig és el més petit del conjunt que vam rebre, això vol dir que hem capturat el bloqueig. Comprovem que hem rebut un pany. Com a comprovació, hi haurà la condició que l'identificador que vam rebre en crear un nou bloqueig sigui mínim. I si el rebem, treballem més.
Si hi ha un identificador determinat que és més petit que el nostre bloqueig, posem un observador en aquest esdeveniment i esperem la notificació fins que alguna cosa canviï. És a dir, hem rebut aquest bloqueig. I fins que no caigui, no ens convertirem en l'identificador mínim i no rebrem el bloqueig mínim, i així podrem iniciar sessió. I si aquesta condició no es compleix, anem immediatament aquí i intentem tornar a obtenir aquest bloqueig, perquè alguna cosa podria haver canviat durant aquest temps.
En què consisteix ZooKeeper? Hi ha 4 coses principals. Es tracta de processos de processament - Sol·licitud. I també ZooKeeper Atomic Broadcast. Hi ha un registre de confirmació on es registren totes les operacions. I la pròpia base de dades replicada en memòria, és a dir, la pròpia base de dades on s'emmagatzema tot aquest arbre.
Val la pena assenyalar que totes les operacions d'escriptura passen pel processador de sol·licituds. I les operacions de lectura van directament a la base de dades en memòria.
La base de dades en si està totalment replicada. Totes les instàncies de ZooKeeper emmagatzemen una còpia completa de les dades.
Per restaurar la base de dades després d'un error, hi ha un registre de confirmació. La pràctica estàndard és que abans que les dades entrin a la memòria, s'escriuen allà perquè, si es bloqueja, aquest registre es pugui reproduir i es pugui restaurar l'estat del sistema. I també s'utilitzen instantànies periòdiques de la base de dades.
ZooKeeper Atomic Broadcast és una cosa que s'utilitza per mantenir dades replicades.
ZAB selecciona internament un líder des del punt de vista del node ZooKeeper. Altres nodes es converteixen en els seus seguidors i esperen algunes accions d'ella. Si reben inscripcions, les reenvien totes al líder. Primer realitza una operació d'escriptura i després envia un missatge sobre què ha canviat als seus seguidors. Això, de fet, s'ha de fer atòmicament, és a dir, l'operació d'enregistrament i emissió de tot el conjunt s'ha de fer atòmicament, garantint així la coherència de les dades.
Només processa les sol·licituds d'escriptura. La seva tasca principal és transformar l'operació en una actualització transaccional. Aquesta és una sol·licitud generada especialment.
I aquí val la pena assenyalar que la idempotència de les actualitzacions per a la mateixa operació està garantida. Què és això? Aquesta cosa, si s'executa dues vegades, tindrà el mateix estat, és a dir, la sol·licitud en si no canviarà. I això s'ha de fer perquè, en cas d'accident, pugueu reiniciar l'operació i, d'aquesta manera, revertir els canvis que s'han produït en aquest moment. En aquest cas, l'estat del sistema esdevindrà el mateix, és a dir, no hauria de donar-se el cas que una sèrie del mateix, per exemple, processos d'actualització, portés a diferents estats finals del sistema.
Font: www.habr.com
