Predlažem da pročitate transkript predavanja "Hadoop. ZooKeeper" iz serije "Metode za distribuiranu obradu velikih količina podataka u Hadoop-u"
Šta je ZooKeeper, njegovo mjesto u Hadoop ekosistemu. Neistine o distribuiranom računarstvu. Dijagram standardnog distribuiranog sistema. Poteškoće u koordinaciji distribuiranih sistema. Tipični problemi s koordinacijom. Principi koji stoje iza dizajna ZooKeeper-a. ZooKeeper model podataka. znode flags. Sesije. Client API. Primitive (konfiguracija, članstvo u grupi, jednostavne brave, izbor vođe, zaključavanje bez efekta stada). ZooKeeper arhitektura. ZooKeeper DB. ZAB. Obrađivač zahtjeva.
Danas ćemo pričati o ZooKeeperu. Ova stvar je veoma korisna. Kao i svaki Apache Hadoop proizvod, ima logo. Prikazuje čovjeka.
Prije ovoga smo uglavnom pričali o tome kako se podaci mogu tamo obraditi, kako ih pohraniti, odnosno kako ih nekako koristiti i nekako raditi s njima. A danas bih želio malo govoriti o izgradnji distribuiranih aplikacija. A ZooKeeper je jedna od onih stvari koje vam omogućavaju da pojednostavite ovu stvar. Ovo je vrsta usluge koja je namijenjena nekoj vrsti koordinacije interakcije procesa u distribuiranim sistemima, u distribuiranim aplikacijama.
Potreba za ovakvim aplikacijama je svakim danom sve veća, to je ono o čemu se radi naš kurs. S jedne strane, MapReduce i ovaj gotov okvir vam omogućavaju da izravnate ovu složenost i oslobodite programera od primitivnih pisanja kao što su interakcija i koordinacija procesa. Ali, s druge strane, niko ne garantuje da to ionako neće morati da se uradi. MapReduce ili drugi gotovi okviri ne zamjenjuju uvijek u potpunosti neke slučajeve koji se ne mogu implementirati pomoću ovoga. Uključujući sam MapReduce i gomilu drugih Apache projekata; oni su, u stvari, takođe distribuirane aplikacije. A da bi olakšali pisanje, napisali su ZooKeeper.
Kao i sve aplikacije vezane za Hadoop, razvio ga je Yahoo! To je sada i zvanična Apache aplikacija. Nije tako aktivno razvijen kao HBase. Ako odete na JIRA HBase, onda svaki dan postoji gomila izvještaja o greškama, gomila prijedloga da se nešto optimizira, tj. život u projektu se stalno odvija. A ZooKeeper je, s jedne strane, relativno jednostavan proizvod, a s druge strane, to osigurava njegovu pouzdanost. I prilično je jednostavan za korištenje, zbog čega je postao standard u aplikacijama unutar Hadoop ekosistema. Zato sam mislio da bi bilo korisno pregledati ga kako bih shvatio kako funkcionira i kako ga koristiti.
Ovo je slika sa nekog predavanja koje smo imali. Možemo reći da je ortogonalna svemu što smo do sada razmatrali. A sve što je ovdje naznačeno, u ovoj ili drugoj mjeri, radi sa ZooKeeperom, odnosno servis je koji koristi sve te proizvode. Ni HDFS ni MapReduce ne pišu svoje slične servise koji bi posebno radili za njih. U skladu s tim se koristi ZooKeeper. A to pojednostavljuje razvoj i neke stvari vezane za greške.
Odakle sve ovo? Čini se da smo pokrenuli dvije aplikacije paralelno na različitim računarima, povezali ih nizom ili u mreži i sve radi. Ali problem je u tome što je mreža nepouzdana, i ako ste nanjušili promet ili pogledali šta se tamo događa na niskom nivou, kako klijenti komuniciraju na mreži, često možete vidjeti da su neki paketi izgubljeni ili ponovo poslati. Nije uzalud izmišljeni TCP protokoli koji vam omogućavaju da uspostavite određenu sesiju i jamčite isporuku poruka. Ali u svakom slučaju, čak ni TCP vas ne može uvijek spasiti. Sve ima tajm-aut. Mreža može jednostavno pasti na neko vrijeme. Možda samo trepće. A to sve dovodi do činjenice da se ne možete osloniti na pouzdanost mreže. To je glavna razlika u odnosu na pisanje paralelnih aplikacija koje rade na jednom računaru ili na jednom superkompjuteru, gdje nema mreže, gdje postoji pouzdanija magistrala za razmjenu podataka u memoriji. A ovo je fundamentalna razlika.
Između ostalog, kada se koristi mreža, uvijek postoji određeno kašnjenje. Disk ga također ima, ali Mreža ga ima više. Latencija je neko vrijeme kašnjenja, koje može biti ili malo ili prilično značajno.
Topologija mreže se mijenja. Što je topologija - to je smještaj naše mrežne opreme. Postoje data centri, postoje stalci koji stoje tamo, postoje svijeće. Sve se to može ponovo spojiti, premjestiti itd. O svemu tome također treba voditi računa. Mijenjaju se IP imena, mijenja se rutiranje kroz koje putuje naš promet. Ovo također treba uzeti u obzir.
Mreža se također može promijeniti u pogledu opreme. Iz prakse mogu reći da naši mrežni inženjeri jako vole povremeno nešto ažurirati na svijećama. Odjednom je izašao novi firmware i nisu bili posebno zainteresirani za neki Hadoop klaster. Oni imaju svoj posao. Za njih je najvažnije da Mreža radi. U skladu s tim, oni žele da ponovo uploaduju nešto tamo, naprave flešovanje na svom hardveru, a hardver se takođe periodično menja. Sve ovo nekako treba uzeti u obzir. Sve ovo utiče na našu distribuiranu aplikaciju.
Obično ljudi koji počnu raditi s velikom količinom podataka iz nekog razloga vjeruju da je Mreža neograničena. Ako se tamo nalazi datoteka od nekoliko terabajta, onda je možete odnijeti na svoj server ili računar i otvoriti pomoću mačka i gledaj. Još jedna greška je unutra energija pogledajte dnevnike. Nikad to ne radite jer je loše. Zato što Vim pokušava sve baferovati, sve učitati u memoriju, posebno kada počnemo da se krećemo kroz ovaj dnevnik i tražimo nešto. To su stvari koje su zaboravljene, ali vredne razmatranja.
Lakše je napisati jedan program koji radi na jednom računaru sa jednim procesorom.
Kada naš sistem raste, želimo sve to paralelizirati, i to ne samo na kompjuteru, već i na klasteru. Postavlja se pitanje: kako koordinirati ovu stvar? Naše aplikacije možda čak i ne komuniciraju jedna s drugom, ali smo pokrenuli nekoliko procesa paralelno na nekoliko servera. I kako pratiti da im sve ide dobro? Na primjer, pošalju nešto preko interneta. Moraju negdje pisati o svom stanju, na primjer, u nekoj vrsti baze podataka ili dnevnika, zatim agregirati ovaj dnevnik i onda ga negdje analizirati. Plus, moramo uzeti u obzir da je proces radio i radio, iznenada se pojavila neka greška u njemu ili se srušio, koliko brzo ćemo to saznati?
Jasno je da se sve to može brzo pratiti. Ovo je također dobro, ali praćenje je ograničena stvar koja vam omogućava da nadgledate neke stvari na najvišem nivou.
Kada želimo da naši procesi počnu da komuniciraju jedni s drugima, na primjer, da jedni drugima šalju neke podatke, onda se postavlja i pitanje - kako će se to dogoditi? Hoće li postojati neka vrsta trkaćeg stanja, hoće li se međusobno prepisivati, hoće li podaci stići ispravno, hoće li se usput nešto izgubiti? Moramo razviti nekakav protokol itd.
Koordinacija svih ovih procesa nije trivijalna stvar. I prisiljava programera da se spusti na još niži nivo, i piše sisteme ili od nule, ili ne baš od nule, ali to nije tako jednostavno.
Ako smislite kriptografski algoritam ili ga čak implementirate, odmah ga bacite, jer vam najvjerovatnije neće raditi. Najvjerovatnije će sadržavati gomilu grešaka koje ste zaboravili navesti. Nikada ga nemojte koristiti za bilo šta ozbiljno jer će najvjerovatnije biti nestabilan. Zato što su svi postojeći algoritmi testirani vremenom već jako dugo. Zajednica ga prisluškuje. Ovo je posebna tema. I ovdje je isto. Ako je moguće da sami ne implementirate neku vrstu sinkronizacije procesa, onda je bolje da to ne radite, jer je prilično komplikovano i vodi vas klimavim putem neprestanog traženja grešaka.
Danas govorimo o ZooKeeperu. S jedne strane, to je okvir, s druge je servis koji programeru olakšava život i maksimalno pojednostavljuje implementaciju logike i koordinacije naših procesa.
Prisjetimo se kako može izgledati standardni distribuirani sistem. Ovo je ono o čemu smo pričali - HDFS, HBase. Postoji Master proces koji upravlja radničkim i podređenim procesima. On je odgovoran za koordinaciju i distribuciju zadataka, ponovno pokretanje radnika, pokretanje novih i raspodjelu opterećenja.
Naprednija stvar je Služba za koordinaciju, odnosno prebaciti sam zadatak koordinacije u poseban proces, plus paralelno pokrenuti neku vrstu backup ili standby Master, jer Master može propasti. A ako Gospodar padne, onda naš sistem neće raditi. Radimo rezervnu kopiju. Neki navode da se Master mora replicirati na sigurnosnu kopiju. Ovo se može povjeriti i Službi za koordinaciju. Ali u ovom dijagramu, sam Master je odgovoran za koordinaciju radnika; ovdje služba koordinira aktivnosti replikacije podataka.
Naprednija opcija je kada svu koordinaciju obavlja naša služba, kao što se obično radi. On preuzima odgovornost da sve funkcioniše. A ako nešto ne uspije, saznamo za to i pokušamo zaobići ovu situaciju. U svakom slučaju, ostaje nam Gospodar koji na neki način komunicira sa robovima i može slati podatke, informacije, poruke itd. preko neke usluge.
Postoji još naprednija šema, kada nemamo Master, svi čvorovi su master slave, različiti po svom ponašanju. Ali oni i dalje moraju međusobno komunicirati, tako da je još preostala neka služba da koordinira ove akcije. Vjerovatno se Cassandra, koja radi na ovom principu, uklapa u ovu shemu.
Teško je reći koja od ovih šema radi bolje. Svaki ima svoje prednosti i mane.
I ne treba se bojati nekih stvari kod Učitelja, jer, kako praksa pokazuje, on nije toliko podložan stalnom služenju. Ovdje je glavna stvar odabrati pravo rješenje za hostovanje ove usluge na zasebnom moćnom čvoru, tako da ima dovoljno resursa, tako da korisnici, ako je moguće, nemaju pristup tamo, kako slučajno ne bi ubili ovaj proces. Ali u isto vrijeme, u takvoj shemi je mnogo lakše upravljati radnicima iz Master procesa, odnosno ova shema je jednostavnija sa stanovišta implementacije.
A ova shema (gore) je vjerojatno složenija, ali pouzdanija.
Glavni problem su delimični kvarovi. Na primjer, kada pošaljemo poruku preko mreže, dogodi se neka vrsta nezgode, a onaj koji je poslao poruku neće znati da li je njegova poruka primljena i šta se dogodilo na strani primaoca, neće znati da li je poruka ispravno obrađena. , tj. neće dobiti nikakvu potvrdu.
Shodno tome, moramo obraditi ovu situaciju. A najjednostavnije je ponovo poslati ovu poruku i sačekati dok ne dobijemo odgovor. U ovom slučaju se ne uzima u obzir da li se stanje prijemnika promijenilo. Možemo poslati poruku i dodati iste podatke dvaput.
ZooKeeper nudi načine za rješavanje takvih odbijanja, što nam također olakšava život.
Kao što je malo ranije spomenuto, ovo je slično pisanju programa s više niti, ali glavna razlika je u tome što u distribuiranim aplikacijama koje gradimo na različitim strojevima, jedini način komunikacije je mreža. U suštini, ovo je arhitektura koja se ne dijeli. Svaki proces ili usluga koja radi na jednoj mašini ima svoju memoriju, svoj disk, sopstveni procesor, koji ne deli ni sa kim.
Ako na jednom računaru napišemo program s više niti, tada možemo koristiti zajedničku memoriju za razmjenu podataka. Tamo imamo promjenu konteksta, procesi se mogu mijenjati. Ovo utiče na performanse. S jedne strane, toga nema u programu na klasteru, ali postoje problemi sa mrežom.
Shodno tome, glavni problemi koji se javljaju prilikom pisanja distribuiranih sistema su konfiguracija. Pišemo neku vrstu aplikacije. Ako je jednostavno, onda hardkodiramo sve vrste brojeva u kodu, ali to je nezgodno, jer ako odlučimo da umjesto tajmauta od pola sekunde želimo tajmaut od jedne sekunde, onda moramo ponovo kompajlirati aplikaciju i ponovo sve izrolati. Jedna je stvar kada je na jednoj mašini, kada možete samo da je ponovo pokrenete, ali kada imamo mnogo mašina, moramo stalno sve da kopiramo. Moramo pokušati da aplikaciju učinimo konfigurabilnom.
Ovdje govorimo o statičkoj konfiguraciji za sistemske procese. Ovo nije u potpunosti, možda sa stanovišta operativnog sistema, može biti statična konfiguracija za naše procese, odnosno, ovo je konfiguracija koja se ne može jednostavno uzeti i ažurirati.
Tu je i dinamička konfiguracija. Ovo su parametri koje želimo da promenimo u hodu tako da se tamo pokupe.
U čemu je problem? Ažurirali smo konfiguraciju, izbacili je, pa šta? Problem je možda u tome što smo s jedne strane izbacili konfiguraciju, ali smo zaboravili na novu stvar, konfiguracija je ostala tamo. Drugo, dok smo mi pokretali, konfiguracija je ažurirana na nekim mjestima, ali ne i na drugim. I neki procesi naše aplikacije koji rade na jednoj mašini su ponovo pokrenuti sa novom konfiguracijom, a negde sa starom. To može dovesti do toga da naša distribuirana aplikacija bude nedosljedna iz perspektive konfiguracije. Ovaj problem je uobičajen. Za dinamičku konfiguraciju, to je relevantnije jer implicira da se može mijenjati u hodu.
Drugi problem je članstvo u grupi. Uvek imamo neki skup radnika, uvek želimo da znamo ko je od njih živ, ko mrtav. Ako postoji Master, onda mora razumjeti koji radnici mogu biti preusmjereni na klijente kako bi oni izvršili proračune ili radili s podacima, a koji ne. Problem koji se stalno javlja je da moramo znati ko radi u našem klasteru.
Drugi tipičan problem su izbori lidera, kada želimo da znamo ko je glavni. Jedan primjer je replikacija, kada imamo neki proces koji prima operacije pisanja i zatim ih replicira među ostalim procesima. On će biti vođa, svi ostali će ga poslušati, slijedit će ga. Potrebno je odabrati proces tako da bude nedvosmislen za sve, kako ne bi ispalo da su izabrana dva lidera.
Postoji i međusobno isključivi pristup. Problem je ovdje složeniji. Postoji nešto kao mutex, kada pišete programe s više niti i želite da pristup nekom resursu, na primjer, memorijskoj ćeliji, bude ograničen i da ga obavlja samo jedna nit. Ovdje bi resurs mogao biti nešto apstraktnije. A različite aplikacije sa različitih čvorova naše Mreže trebale bi samo da dobiju ekskluzivni pristup datom resursu, a ne da ga svako može promijeniti ili tamo nešto napisati. To su takozvane brave.
ZooKeeper vam omogućava da riješite sve ove probleme u jednom ili drugom stepenu. I pokazat ću na primjerima kako vam to omogućava.
Ne postoje primitivi za blokiranje. Kada nešto počnemo koristiti, ovaj primitiv neće čekati da se dogodi bilo kakav događaj. Najvjerovatnije će ova stvar raditi asinhrono, dopuštajući tako procesima da ne visi dok nešto čekaju. Ovo je veoma korisna stvar.
Svi zahtjevi klijenata se obrađuju po redoslijedu općeg reda.
I klijenti imaju mogućnost da dobiju obavijest o promjenama u nekom stanju, o promjenama podataka, prije nego što klijent sam vidi promijenjene podatke.
ZooKeeper može raditi u dva načina. Prvi je samostalan, na jednom čvoru. Ovo je zgodno za testiranje. Također može raditi u cluster modu na bilo kojem broju servera. Ako imamo klaster od 100 mašina, onda nije neophodno da radi na 100 mašina. Dovoljno je odabrati nekoliko mašina na kojima možete pokrenuti ZooKeeper. I ispovijeda princip visoke dostupnosti. Na svakoj pokrenutoj instanci, ZooKeeper pohranjuje cijelu kopiju podataka. Kasnije ću vam reći kako to radi. Ne dijeli podatke niti ih particionira. S jedne strane, to je minus što ne možemo puno pohraniti, s druge strane, nema potrebe za tim. To nije ono za šta je dizajniran, nije baza podataka.
Podaci se mogu keširati na strani klijenta. Ovo je standardni princip tako da ne prekidamo uslugu i ne opterećujemo je istim zahtjevima. Pametan klijent obično zna za ovo i sprema ga.
Na primjer, ovdje se nešto promijenilo. Postoji neka vrsta aplikacije. Izabran je novi vođa, koji je odgovoran, na primjer, za obradu operacija pisanja. I želimo da repliciramo podatke. Jedno rješenje je staviti ga u petlju. I stalno dovodimo u pitanje našu uslugu - da li se nešto promijenilo? Druga opcija je optimalnija. Ovo je mehanizam za praćenje koji vam omogućava da obavijestite klijente da se nešto promijenilo. Ovo je jeftinija metoda u smislu resursa i pogodnija za klijente.
Klijent je korisnik koji koristi ZooKeeper.
Server je sam proces ZooKeeper.
Znode je ključna stvar u ZooKeeperu. ZooKeeper sve znode pohranjuje u memoriju i organizirani su u obliku hijerarhijskog dijagrama, u obliku stabla.
Postoje dvije vrste operacija. Prvi je update/write, kada neka operacija promijeni stanje našeg stabla. Drvo je uobičajeno.
I moguće je da klijent ne ispuni jedan zahtjev i bude prekinut, ali može uspostaviti sesiju kroz koju komunicira sa ZooKeeperom.
ZooKeeperov model podataka liči na sistem datoteka. Postoji standardni root i onda smo išli kao da kroz direktorije koji idu od korijena. I onda katalog prvog nivoa, drugog nivoa. Ovo je sve znodes.
Svaki znode može pohraniti neke podatke, obično ne velike, na primjer, 10 kilobajta. I svaki znode može imati određeni broj djece.
Znodes dolazi u nekoliko tipova. Mogu se kreirati. A kada kreiramo znode, specificiramo tip kojem bi trebao pripadati.
Postoje dvije vrste. Prva je efemerna zastava. Znode živi unutar sesije. Na primjer, klijent je uspostavio sesiju. I sve dok je ova sesija živa, postojaće. Ovo je neophodno kako se ne bi proizvelo nešto nepotrebno. Ovo je također pogodno za trenutke kada nam je važno pohraniti primitive podataka unutar sesije.
Drugi tip je sekvencijalna zastavica. Povećava brojač na putu do znodea. Na primjer, imali smo direktorij s aplikacijom 1_5. I kada smo kreirali prvi čvor, primio je p_1, drugi - p_2. I kada svaki put pozovemo ovu metodu, mi proslijeđujemo punu putanju, označavajući samo dio putanje, a ovaj broj se automatski povećava jer označavamo tip čvora - sekvencijalni.
Regular znode. Ona će uvijek živjeti i imati ime koje joj kažemo.
Još jedna korisna stvar je zastavica sata. Ako ga instaliramo, klijent se može pretplatiti na neke događaje za određeni čvor. Kasnije ću vam pokazati na primjeru kako se to radi. ZooKeeper sam obavještava klijenta da su se podaci na čvoru promijenili. Međutim, obavještenja ne jamče da su neki novi podaci stigli. Jednostavno kažu da se nešto promijenilo, tako da i dalje morate porediti podatke kasnije sa zasebnim pozivima.
I kao što sam već rekao, redosled podataka je određen kilobajtima. Nema potrebe da se tamo spremaju veliki tekstualni podaci, jer to nije baza podataka, to je server za koordinaciju akcija.
Reći ću vam malo o seansama. Ako imamo više servera, onda možemo transparentno prelaziti sa servera na server koristeći identifikator sesije. Prilično je zgodno.
Svaka sesija ima neku vrstu timeouta. Sesija je definisana time da li klijent šalje bilo šta serveru tokom te sesije. Ako nije prenio ništa za vrijeme tajmauta, sesija pada, ili je klijent može sam zatvoriti.
Nema toliko mogućnosti, ali možete raditi različite stvari s ovim API-jem. Taj poziv koji smo vidjeli kako kreira kreira znode i uzima tri parametra. Ovo je put do znodea i mora biti specificiran u potpunosti iz korijena. I ovo su neki podaci koje želimo tamo prenijeti. I vrstu zastave. I nakon kreiranja vraća putanju do znodea.
Drugo, možete ga izbrisati. Trik je u tome što drugi parametar, pored putanje do znodea, može odrediti verziju. Shodno tome, taj znode će biti obrisan ako je njegova verzija koju smo prenijeli ekvivalentna onoj koja stvarno postoji.
Ako ne želimo provjeriti ovu verziju, onda jednostavno prosljeđujemo argument "-1".
Treće, provjerava postojanje znodea. Vraća true ako čvor postoji, false u suprotnom.
A onda se pojavljuje sat sa zastavicom, koji vam omogućava da nadgledate ovaj čvor.
Ovu zastavicu možete postaviti čak i na nepostojeći čvor i primiti obavijest kada se pojavi. Ovo također može biti korisno.
Još par izazova je getData. Jasno je da možemo primati podatke preko znodea. Možete koristiti i sat sa zastavom. U ovom slučaju, neće se instalirati ako nema čvora. Stoga morate shvatiti da postoji, a zatim primiti podatke.
Tu je i SetData. Ovdje prenosimo verziju. A ako ovo prenesemo dalje, podaci na znode-u određene verzije će se ažurirati.
Također možete odrediti "-1" da isključite ovu provjeru.
Još jedna korisna metoda je getChildren. Također možemo dobiti listu svih znodeova koji joj pripadaju. Ovo možemo pratiti postavljanjem zastave.
I metoda sinkronizirati omogućava da se sve promjene pošalju odjednom, čime se osigurava da su one sačuvane i da su svi podaci potpuno promijenjeni.
Ako povučemo analogije sa redovnim programiranjem, onda kada koristite metode kao što je pisanje, koje nešto zapisuju na disk, a nakon što vam vrati odgovor, nema garancije da ste podatke zapisali na disk. Čak i kada je operativni sistem siguran da je sve zapisano, na samom disku postoje mehanizmi gdje proces prolazi kroz slojeve bafera, a tek nakon toga podaci se stavljaju na disk.
Uglavnom se koriste asinhroni pozivi. To omogućava klijentu da radi paralelno s različitim zahtjevima. Možete koristiti sinhroni pristup, ali je manje produktivan.
Dvije operacije o kojima smo govorili su ažuriranje/pisanje, koje mijenjaju podatke. To su kreiranje, setData, sinhronizacija, brisanje. I read postoji, getData, getChildren.
Sada nekoliko primjera kako možete napraviti primitive za rad u distribuiranom sistemu. Na primjer, vezano za konfiguraciju nečega. Pojavio se novi radnik. Dodali smo mašinu i pokrenuli proces. I tu su sljedeća tri pitanja. Kako postavlja upit ZooKeeperu za konfiguraciju? A ako želimo da promenimo konfiguraciju, kako da je promenimo? A nakon što smo ga promijenili, kako to dobijaju oni radnici koje smo imali?
ZooKeeper ovo čini relativno lakim. Na primjer, postoji naše znode drvo. Ovdje postoji čvor za našu aplikaciju, u njemu kreiramo dodatni čvor koji sadrži podatke iz konfiguracije. Ovo mogu, ali i ne moraju biti zasebni parametri. Budući da je veličina mala, obično je mala i konfiguracija, tako da je sasvim moguće pohraniti je ovdje.
Vi koristite metodu getData da dobijete konfiguraciju za radnika iz čvora. Postavite na true. Ako iz nekog razloga ovaj čvor ne postoji, bit ćemo obaviješteni o njemu kada se pojavi, odnosno kada se promijeni. Ako želimo da znamo da se nešto promenilo, onda to postavljamo na true. A ako se podaci u ovom čvoru promijene, znat ćemo za to.
SetData. Postavljamo podatke, postavljamo “-1”, tj. ne provjeravamo verziju, pretpostavljamo da uvijek imamo jednu konfiguraciju, ne moramo pohranjivati mnogo konfiguracija. Ako trebate puno pohraniti, morat ćete dodati još jedan nivo. Ovdje vjerujemo da postoji samo jedan, pa ažuriramo samo najnoviju, tako da ne provjeravamo verziju. U ovom trenutku svi klijenti koji su se prethodno pretplatili dobijaju obavijest da se nešto promijenilo u ovom čvoru. A nakon što ga dobiju, moraju ponovo zatražiti podatke. Obavijest je da ne primaju same podatke, već samo obavijest o promjenama. Nakon toga moraju tražiti nove podatke.
Druga opcija za korištenje primitivnog je članstvo u grupi. Imamo distribuiranu aplikaciju, ima gomila radnika i želimo da shvatimo da su svi na svom mjestu. Stoga se moraju prijaviti da rade u našoj aplikaciji. Također želimo saznati, bilo iz Master procesa ili negdje drugdje, o svim aktivnim radnicima koje trenutno imamo.
Kako da ovo uradimo? Za aplikaciju kreiramo čvor radnika i dodajemo podnivo koristeći metodu kreiranja. Imam grešku na slajdu. Evo ti treba sekvencijalni navedite, tada će svi radnici biti kreirani jedan po jedan. A aplikacija, koja traži sve podatke o djeci ovog čvora, prima sve aktivne radnike koji postoje.
Ovo je tako strašna implementacija kako se to može učiniti u Java kodu. Počnimo od kraja, sa glavnom metodom. Ovo je naša klasa, hajde da kreiramo njen metod. Kao prvi argument koristimo host, gdje se povezujemo, odnosno postavljamo ga kao argument. A drugi argument je ime grupe.
Kako dolazi do povezivanja? Ovo je jednostavan primjer API-ja koji se koristi. Ovdje je sve relativno jednostavno. Postoji standardna klasa ZooKeeper. Prebacujemo domaćine na to. I podesite timeout, na primjer, na 5 sekundi. I imamo člana koji se zove connectSignal. U suštini, mi kreiramo grupu duž puta koji se prenosi. Mi tu ne upisujemo podatke, iako se moglo nešto napisati. A čvor je ovdje perzistentnog tipa. U suštini, ovo je običan regularni čvor koji će postojati cijelo vrijeme. Ovdje se kreira sesija. Ovo je implementacija samog klijenta. Naš klijent će slati periodične poruke koje pokazuju da je sesija živa. I kada završimo sesiju, zovemo zatvoreno i to je to, sesija pada. Ovo je u slučaju da nam nešto padne, pa da ZooKeeper sazna za to i prekine sesiju.
Kako zaključati resurs? Ovdje je sve malo komplikovanije. Imamo skup radnika, postoji neki resurs koji želimo da zaključamo. Da bismo to učinili, kreiramo poseban čvor, na primjer, nazvan lock1. Ako smo uspeli da ga kreiramo, onda imamo bravu ovde. A ako nismo bili u mogućnosti da ga kreiramo, onda radnik pokušava da dobije getData odavde, a pošto je čvor već kreiran, onda stavljamo posmatrač ovde i u trenutku kada se stanje ovog čvora promeni, mi ćemo znati za to. I možemo pokušati da imamo vremena da to ponovo stvorimo. Ako smo uzeli ovaj čvor, uzeli ovo zaključavanje, onda ćemo ga napustiti nakon što nam više ne treba zaključavanje, pošto čvor postoji samo unutar sesije. Shodno tome, nestat će. I drugi klijent, u okviru druge sesije, moći će da preuzme zaključavanje na ovom čvoru, odnosno, dobiće obavijest da se nešto promijenilo i može pokušati to učiniti na vrijeme.
Još jedan primjer kako možete izabrati glavnog vođu. Ovo je malo komplikovanije, ali i relativno jednostavno. sta se desava ovde? Postoji glavni čvor koji agregira sve radnike. Pokušavamo dobiti podatke o vođi. Ako se to uspješno dogodilo, odnosno dobili smo neke podatke, onda naš radnik počinje pratiti ovog vođu. On vjeruje da lider već postoji.
Ako je vođa iz nekog razloga umro, na primjer, pao, onda pokušavamo stvoriti novog vođu. A ako uspijemo, onda naš radnik postaje vođa. A ako je neko u ovom trenutku uspeo da stvori novog vođu, onda pokušavamo da shvatimo ko je to i onda ga pratimo.
Ovdje nastaje takozvani efekat stada, odnosno efekat stada, jer kada vođa umre, onaj koji je prvi u vremenu postaje vođa.
Prilikom hvatanja resursa, možete pokušati koristiti malo drugačiji pristup, koji je sljedeći. Na primjer, želimo dobiti bravu, ali bez hert efekta. Ona će se sastojati u činjenici da naša aplikacija traži liste svih ID-ova čvorova za već postojeći čvor sa zaključavanjem. A ako je prije toga čvor za koji smo kreirali bravu najmanji od skupa koji smo primili, onda to znači da smo uhvatili bravu. Provjeravamo da li smo dobili bravu. Kao provjeru, postojat će uvjet da je id koji smo dobili prilikom kreiranja nove brave minimalan. A ako smo to dobili, onda radimo dalje.
Ako postoji određeni id koji je manji od naše brave, tada stavljamo promatrač na ovaj događaj i čekamo obavijest dok se nešto ne promijeni. To jest, dobili smo ovu bravu. I dok ne padne, nećemo postati minimalni id i nećemo primiti minimalno zaključavanje, pa ćemo se moći prijaviti. A ako ovaj uslov nije ispunjen, onda odmah idemo ovamo i pokušavamo ponovo da dobijemo ovu bravu, jer se možda nešto promenilo za to vreme.
Od čega se sastoji ZooKeeper? Postoje 4 glavne stvari. Ovo je proces obrade - Zahtjev. I također ZooKeeper Atomic Broadcast. Postoji dnevnik urezivanja u koji se bilježe sve operacije. I sam replicirani DB u memoriji, tj. sama baza podataka gdje je pohranjeno cijelo ovo stablo.
Vrijedi napomenuti da sve operacije pisanja prolaze kroz Procesor zahtjeva. A operacije čitanja idu direktno u bazu podataka u memoriji.
Sama baza podataka je u potpunosti replicirana. Sve instance ZooKeeper-a pohranjuju potpunu kopiju podataka.
Da biste vratili bazu podataka nakon pada, postoji dnevnik urezivanja. Standardna praksa je da prije nego što podaci dođu u memoriju, tamo se zapisuju tako da ako padne, ovaj dnevnik se može reprodukovati i stanje sistema može biti vraćeno. Koriste se i periodični snimci baze podataka.
ZooKeeper Atomic Broadcast je stvar koja se koristi za održavanje repliciranih podataka.
ZAB interno bira lidera sa stanovišta ZooKeeper čvora. Ostali čvorovi postaju njeni sljedbenici i očekuju neke akcije od nje. Ako prime prijave, sve ih prosljeđuju voditelju. On prvo izvodi operaciju pisanja, a zatim šalje poruku o tome šta se promijenilo svojim sljedbenicima. To se, u stvari, mora izvoditi atomski, tj. operacija snimanja i emitiranja cijele stvari mora biti izvedena atomski, čime se garantuje konzistentnost podataka.
Obrađuje samo zahtjeve za pisanje. Njegov glavni zadatak je da transformiše operaciju u transakcijsko ažuriranje. Ovo je posebno generirani zahtjev.
I ovdje je vrijedno napomenuti da je idempotencija ažuriranja za istu operaciju zagarantovana. Šta je to? Ova stvar, ako se izvrši dva puta, imaće isto stanje, tj. sam zahtjev se neće promijeniti. A to je potrebno učiniti tako da u slučaju pada možete ponovo pokrenuti operaciju, čime se vraćaju promjene koje su trenutno otpale. U tom slučaju će stanje sistema postati isto, odnosno ne bi trebalo biti da niz istih, na primjer, procesa ažuriranja, dovede do različitih konačnih stanja sistema.
izvor: www.habr.com