Predlažem da pročitate transkript predavanja "Hadoop. ZooKeeper" iz serije "Metode za distribuiranu obradu velikih količina podataka u Hadoopu"
Što je ZooKeeper, njegovo mjesto u Hadoop ekosustavu. Neistine o distribuiranom računalstvu. Dijagram standardnog distribuiranog sustava. Poteškoće u koordinaciji distribuiranih sustava. Tipični problemi koordinacije. Načela koja stoje iza dizajna ZooKeepera. ZooKeeper model podataka. zastave znode. Sjednice. API klijenta. Primitivni (konfiguracija, članstvo u grupi, jednostavna zaključavanja, izbor vođe, zaključavanje bez efekta krda). ZooKeeper arhitektura. ZooKeeper DB. ZAB. Rukovatelj zahtjevima.
Danas ćemo govoriti o ZooKeeperu. Ova stvar je vrlo korisna. On, kao i svaki Apache Hadoop proizvod, ima logo. Prikazuje čovjeka.
Prije ovoga smo uglavnom pričali o tome kako se podaci tamo mogu obrađivati, kako ih pohraniti, odnosno kako ih nekako koristiti i raditi s njima. A danas bih želio govoriti malo o izgradnji distribuiranih aplikacija. A ZooKeeper je jedna od onih stvari koje vam omogućuju da pojednostavite ovu stvar. Riječ je o vrsti usluge koja je namijenjena nekoj vrsti koordinacije interakcije procesa u distribuiranim sustavima, u distribuiranim aplikacijama.
Potreba za ovakvim aplikacijama je svakim danom sve veća, to je ono o čemu se radi u našem tečaju. S jedne strane, MapReduce i ovaj gotovi okvir omogućuje vam da izjednačite ovu složenost i oslobodite programera pisanja primitiva kao što su interakcija i koordinacija procesa. No, s druge strane, nitko ne jamči da se to ipak neće morati učiniti. 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 hrpu drugih Apache projekata; oni su zapravo također distribuirane aplikacije. A kako bi olakšali pisanje, napisali su ZooKeeper.
Kao i sve aplikacije povezane s Hadoopom, razvio ju je Yahoo! Sada je i službena aplikacija Apache. Nije tako aktivno razvijen kao HBase. Ako odete na JIRA HBase, onda svaki dan postoji hrpa izvješća o greškama, hrpa prijedloga za optimizaciju nečega, tj. život u projektu stalno traje. A ZooKeeper je s jedne strane relativno jednostavan proizvod, a s druge strane to mu osigurava pouzdanost. I prilično je jednostavan za korištenje, zbog čega je postao standard u aplikacijama unutar Hadoop ekosustava. Stoga sam mislio da bi bilo korisno pregledati ga kako bih razumio kako radi i kako ga koristiti.
Ovo je slika s nekog našeg predavanja. Možemo reći da je ortogonalna na sve što smo do sada razmatrali. I sve što je ovdje naznačeno, u jednoj ili drugoj mjeri, radi sa ZooKeeperom, tj. to je usluga koja koristi sve te proizvode. Ni HDFS ni MapReduce ne pišu vlastite slične usluge koje bi radile za njih. Sukladno tome koristi se ZooKeeper. A to pojednostavljuje razvoj i neke stvari vezane uz pogreške.
Odakle sve to? Reklo bi se da smo pokrenuli dvije aplikacije paralelno na različitim računalima, povezali ih stringom ili u mrežu i sve radi. Ali problem je što je Mreža nepouzdana, a ako ste pronjuškali promet ili pogledali što se tamo događa na niskoj razini, kako klijenti komuniciraju na Mreži, često možete vidjeti da se neki paketi izgube ili ponovno pošalju. Nisu uzalud izmišljeni TCP protokoli koji vam omogućuju uspostavljanje određene sesije i jamče isporuku poruka. Ali u svakom slučaju, ni TCP vas ne može uvijek spasiti. Sve ima vremensko ograničenje. Mreža može jednostavno pasti na neko vrijeme. Moglo bi samo treptati. A to sve dovodi do činjenice da se ne možete pouzdati u pouzdanost mreže. To je glavna razlika od pisanja paralelnih aplikacija koje se izvode na jednom računalu ili na jednom superračunalu, gdje nema mreže, gdje postoji pouzdanija sabirnica za razmjenu podataka u memoriji. I ovo je temeljna razlika.
Između ostalog, prilikom korištenja Mreže uvijek postoji određena latencija. Ima ga i disk, ali Mreža ga ima više. Latencija je neko vrijeme kašnjenja, koje može biti malo ili prilično značajno.
Mrežna topologija se mijenja. Što je topologija - to je smještaj naše mrežne opreme. Postoje podatkovni centri, postoje regali koji tamo stoje, postoje svijeće. Sve se to može prespajati, premještati itd. O svemu tome također treba voditi računa. IP imena se mijenjaju, usmjeravanje kroz koje putuje naš promet se mijenja. 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 ažurirati nešto na svijećama. Odjednom je izašao novi firmware i nije ih posebno zanimao neki Hadoop klaster. Imaju svoj posao. Za njih je glavno da Mreža radi. Sukladno tome, žele tamo nešto ponovno uploadati, napraviti flashanje na svom hardveru, a i hardver se povremeno mijenja. Sve to nekako treba uzeti u obzir. Sve ovo utječe na našu distribuiranu aplikaciju.
Obično ljudi koji počnu raditi s velikim količinama podataka iz nekog razloga vjeruju da je internet neograničen. Ako tamo postoji datoteka od nekoliko terabajta, možete je odnijeti na svoj poslužitelj ili računalo i otvoriti pomoću kako i gledati. Postoji još jedna greška energija pogledaj trupce. Nikad to ne radi jer je loše. Zato što Vim pokušava sve spremiti u međuspremnik, sve učitati u memoriju, pogotovo kada se počnemo kretati kroz ovaj dnevnik i tražiti nešto. To su stvari koje su zaboravljene, ali vrijedne razmatranja.
Lakše je napisati jedan program koji radi na jednom računalu s jednim procesorom.
Kada naš sustav raste, želimo ga sve paralelizirati, i to ne samo na računalu, već i na klasteru. Postavlja se pitanje: kako koordinirati tu stvar? Naše aplikacije možda čak i ne komuniciraju jedna s drugom, ali pokrenuli smo nekoliko procesa paralelno na nekoliko poslužitelja. I kako pratiti da im sve ide dobro? Na primjer, pošalju nešto preko interneta. Moraju pisati o svom stanju negdje, na primjer, u nekoj vrsti baze podataka ili dnevnika, zatim agregirati taj dnevnik i onda ga negdje analizirati. Osim toga, 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 saznati za to?
Jasno je da se sve to može brzo pratiti. I ovo je dobro, ali praćenje je ograničena stvar koja vam omogućuje praćenje nekih stvari na najvišoj razini.
Kada želimo da naši procesi počnu djelovati jedni s drugima, na primjer, da jedni drugima šalju neke podatke, onda se također postavlja pitanje - kako će se to dogoditi? Hoće li biti nekakvog race uvjeta, hoće li se međusobno prepisivati, hoće li podaci stizati ispravno, hoće li se nešto izgubiti putem? Moramo razviti nekakav protokol, itd.
Koordinacija svih tih procesa nije trivijalna stvar. I to tjera programere da se spuste na još nižu razinu i pišu sustave ili od nule, ili ne sasvim od nule, ali to nije tako jednostavno.
Ako smislite kriptografski algoritam ili ga čak implementirate, odmah ga bacite jer vam najvjerojatnije neće raditi. U njemu će najvjerojatnije biti hrpa grešaka koje ste zaboravili navesti. Nikad ga nemojte koristiti za nešto ozbiljno jer će najvjerojatnije biti nestabilan. Zato što su svi algoritmi koji postoje testirani vremenom jako dugo. Prisluškuje ga zajednica. Ovo je posebna tema. I ovdje je tako. Ako je moguće da sami ne implementirate neku vrstu sinkronizacije procesa, onda je bolje da to ne radite, jer je prilično komplicirano i vodi vas na nesigurni put stalnog traženja grešaka.
Danas govorimo o ZooKeeperu. S jedne strane, to je framework, s druge strane, to je usluga koja programeru olakšava život i maksimalno pojednostavljuje implementaciju logike i koordinaciju naših procesa.
Prisjetimo se kako bi standardni distribuirani sustav mogao izgledati. Ovo je ono o čemu smo pričali - HDFS, HBase. Postoji glavni proces koji upravlja radnim i podređenim procesima. On je odgovoran za koordinaciju i raspodjelu zadataka, ponovno pokretanje radnika, pokretanje novih i raspodjelu opterećenja.
Naprednija stvar je Coordination Service, odnosno sam zadatak koordinacije premjestiti u zaseban proces, plus paralelno pokrenuti nekakav backup ili standby Master, jer Master može zakazati. A ako Gospodar padne, onda naš sustav neće funkcionirati. Pokrećemo sigurnosnu kopiju. Neke navode da se Master mora replicirati na rezervnu kopiju. To se može povjeriti i Službi za koordinaciju. Ali u ovom dijagramu, sam Master je odgovoran za koordinaciju radnika; ovdje usluga koordinira aktivnosti replikacije podataka.
Naprednija opcija je kada svu koordinaciju obavlja naš servis, kao što se inače radi. Preuzima odgovornost da sve funkcionira. A ako nešto ne funkcionira, saznamo za to i pokušamo riješiti 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 nekog servisa.
Postoji još naprednija shema, kada nemamo Mastera, svi čvorovi su master slaves, različiti u svom ponašanju. Ali oni i dalje moraju međusobno komunicirati, tako da još uvijek postoji neka služba koja će koordinirati te akcije. Vjerojatno Cassandra, koja radi na ovom principu, odgovara ovoj shemi.
Teško je reći koja od ovih shema bolje funkcionira. Svaki ima svoje prednosti i nedostatke.
A kod Učitelja se nekih stvari ne treba bojati, jer, kako praksa pokazuje, on nije toliko podložan stalnom služenju. Ovdje je glavna stvar odabrati pravo rješenje za smještaj ove usluge na zasebnom moćnom čvoru, tako da ima dovoljno resursa, tako da, ako je moguće, korisnici tamo nemaju pristup, tako da slučajno ne ubiju ovaj proces. No, u isto vrijeme, u takvoj shemi puno je lakše upravljati radnicima iz Master procesa, odnosno ova je shema jednostavnija sa stajališta implementacije.
A ova shema (iznad) vjerojatno je složenija, ali pouzdanija.
Glavni problem su djelomični kvarovi. Na primjer, kada pošaljemo poruku preko Mreže, dogodi se neka nezgoda, a onaj tko je poslao poruku neće znati je li njegova poruka primljena i što se dogodilo na strani primatelja, neće znati je li poruka ispravno obrađena. , tj. neće dobiti nikakvu potvrdu.
Sukladno tome, moramo obraditi ovu situaciju. A najjednostavnije je ponovno poslati ovu poruku i pričekati da dobijemo odgovor. U ovom slučaju ne uzima se u obzir je li se stanje prijemnika promijenilo. Možemo poslati poruku i dodati iste podatke dva puta.
ZooKeeper nudi načine kako se nositi s takvim odbijanjima, š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 je razlika u tome što je u distribuiranim aplikacijama koje gradimo na različitim strojevima jedini način komunikacije mreža. U biti, ovo je arhitektura bez dijeljenja. Svaki proces ili servis koji radi na jednom stroju ima svoju memoriju, svoj disk, svoj procesor, koji ne dijeli ni s kim.
Ako napišemo višenitni program na jednom računalu, tada možemo koristiti zajedničku memoriju za razmjenu podataka. Tu imamo promjenu konteksta, procesi se mogu mijenjati. To utječe na performanse. S jedne strane, toga nema u programu na klasteru, ali postoje problemi s mrežom.
Sukladno tome, glavni problemi koji se javljaju pri pisanju distribuiranih sustava su konfiguracija. Pišemo neku vrstu prijave. Ako je jednostavno, tada tvrdo kodiramo sve vrste brojeva u kodu, ali to je nezgodno, jer ako odlučimo da umjesto vremenskog ograničenja od pola sekunde želimo vremensko ograničenje od jedne sekunde, tada moramo ponovno kompajlirati aplikaciju i sve ponovno razvaljajte. Jedna je stvar kada je na jednom stroju, kada ga možete jednostavno ponovno pokrenuti, ali kada imamo mnogo strojeva, moramo stalno sve kopirati. Moramo pokušati učiniti aplikaciju konfigurabilnom.
Ovdje govorimo o statičkoj konfiguraciji za procese sustava. Ovo nije u potpunosti, možda sa stanovišta operativnog sustava, možda je to 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 mijenjati u hodu tako da se tamo pokupe.
Što je ovdje problem? Ažurirali smo konfiguraciju, pokrenuli je, pa što? Problem može biti u tome što smo s jedne strane izbacili konfiguraciju, ali smo zaboravili na novu stvar, konfiguracija je ostala tamo. Drugo, dok smo izlazili, konfiguracija je ažurirana na nekim mjestima, ali ne i na drugim. I neki procesi naše aplikacije koji se izvode na jednom stroju ponovno su pokrenuti s novom konfiguracijom, a negdje i sa starom. To može dovesti do nedosljednosti naše distribuirane aplikacije iz perspektive konfiguracije. Ovaj problem je čest. Za dinamičku konfiguraciju to je relevantnije jer implicira da se može mijenjati u hodu.
Drugi problem je članstvo u grupi. Uvijek imamo neki skup radnika, uvijek želimo znati tko je od njih živ, tko je mrtav. Ako postoji Master, onda on mora razumjeti koji se radnici mogu preusmjeriti na klijente kako bi oni izvodili izračune ili radili s podacima, a koji ne. Problem koji se stalno nameće je da moramo znati tko radi u našem klasteru.
Još jedan tipičan problem su izbori lidera, kada želimo znati tko je glavni. Jedan primjer je replikacija, kada imamo neki proces koji prima operacije pisanja i zatim ih replicira među drugim procesima. On će biti vođa, svi drugi će ga slušati, slijedit će ga. Potrebno je odabrati proces tako da bude nedvosmislen za sve, da ne ispadne da se biraju dva voditelja.
Postoji i međusobno isključiv pristup. Problem je ovdje složeniji. Postoji takva stvar kao što je 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 izvor mogao biti nešto apstraktniji. A različite aplikacije iz različitih čvorova naše Mreže trebale bi dobiti samo ekskluzivni pristup određenom resursu, a ne tako da ga svatko može promijeniti ili tamo nešto napisati. To su brave tzv.
ZooKeeper vam omogućuje rješavanje svih ovih problema u jednoj ili drugoj mjeri. I pokazat ću na primjerima kako vam to omogućuje.
Nema primitiva za blokiranje. Kada nešto počnemo koristiti, ta primitiva neće čekati da se dogodi bilo kakav događaj. Najvjerojatnije će ova stvar raditi asinkrono, dopuštajući procesima da ne vise dok nešto čekaju. Ovo je vrlo korisna stvar.
Svi zahtjevi klijenata obrađuju se prema redoslijedu općeg reda.
I klijenti imaju mogućnost dobiti 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 načinu klastera na bilo kojem broju poslužitelja. Ako imamo klaster od 100 strojeva, onda nije nužno da on radi na 100 strojeva. Dovoljno je odabrati nekoliko strojeva na kojima možete pokrenuti ZooKeeper. I ispovijeda princip visoke dostupnosti. Na svakoj pokrenutoj instanci ZooKeeper pohranjuje cijelu kopiju podataka. Kasnije ću ti reći kako on to radi. Ne dijeli podatke niti ih particionira. S jedne strane, minus je što ne možemo puno skladištiti, s druge strane nema potrebe za tim. To nije ono za što je dizajniran, to nije baza podataka.
Podaci se mogu keširati na strani klijenta. Ovo je standardno načelo kako ne bismo prekidali uslugu i ne opterećivali je istim zahtjevima. Pametan klijent obično zna za ovo i spremi to u predmemoriju.
Na primjer, ovdje se nešto promijenilo. Postoji neka vrsta primjene. Izabran je novi voditelj koji je odgovoran, primjerice, za obradu operacija pisanja. I želimo replicirati podatke. Jedno od rješenja je staviti ga u petlju. I stalno propitujemo našu uslugu - je li se što promijenilo? Druga opcija je optimalnija. Ovo je mehanizam za gledanje koji vam omogućuje da obavijestite klijente da se nešto promijenilo. Ovo je jeftinija metoda u smislu resursa i prikladnija za klijente.
Klijent je korisnik koji koristi ZooKeeper.
Poslužitelj je sam ZooKeeper proces.
Znode je ključna stvar u ZooKeeperu. Sve znode ZooKeeper pohranjuje u memoriju i organizirane su u obliku hijerarhijskog dijagrama, u obliku stabla.
Postoje dvije vrste operacija. Prvi je update/write, kada neka operacija mijenja stanje našeg stabla. Stablo je uobičajeno.
I moguće je da klijent ne ispuni jedan zahtjev i bude isključen, ali može uspostaviti sesiju kroz koju komunicira sa ZooKeeperom.
ZooKeeperov podatkovni model nalikuje datotečnom sustavu. Postoji standardni root i onda smo išli kao kroz direktorije koji idu iz roota. I onda katalog prve razine, druge razine. Ovo su sve znode.
Svaki znode može pohraniti neke podatke, obično ne baš velike, na primjer, 10 kilobajta. I svaki znode može imati određeni broj djece.
Znode postoje u nekoliko vrsta. Mogu se stvoriti. A kada stvaramo znode, specificiramo tip kojem treba pripadati.
Postoje dvije vrste. Prva je efemerna zastava. Znode živi unutar sesije. Na primjer, klijent je uspostavio sesiju. I dok je ova sesija živa, postojat će. Ovo je neophodno kako se ne bi proizvodilo nešto nepotrebno. Ovo je također prikladno za trenutke kada nam je važno pohraniti primitivne podatke unutar sesije.
Drugi tip je sekvencijalna zastavica. Povećava brojač na putu do čvora. Na primjer, imali smo imenik s aplikacijom 1_5. I kada smo stvorili prvi čvor, dobio je p_1, drugi - p_2. I kada svaki put pozivamo ovu metodu, prosljeđujemo cijeli put, označavajući samo dio puta, a taj se broj automatski povećava jer označavamo tip čvora - sekvencijalni.
Redoviti znode. Uvijek će živjeti i nositi ime koje joj mi kažemo.
Još jedna korisna stvar je zastavica sata. Ako ga instaliramo, tada se klijent može pretplatiti na neke događaje za određeni čvor. Kasnije ću vam pokazati na primjeru kako se to radi. Sam ZooKeeper obavještava klijenta da su se podaci na čvoru promijenili. Međutim, obavijesti ne jamče da su neki novi podaci stigli. Jednostavno kažu da se nešto promijenilo, pa ipak morate kasnije uspoređivati podatke posebnim pozivima.
I kao što sam već rekao, redoslijed podataka je određen u kilobajtima. Tu nema potrebe pohranjivati velike tekstualne podatke, jer to nije baza podataka, to je poslužitelj za koordinaciju akcija.
Reći ću vam nešto o sesijama. Ako imamo više poslužitelja, tada se možemo transparentno kretati s poslužitelja na poslužitelj pomoću identifikatora sesije. Prilično je zgodno.
Svaka sesija ima neku vrstu vremenskog ograničenja. Sesija je definirana time šalje li klijent bilo što poslužitelju tijekom te sesije. Ako nije ništa poslao tijekom timeouta, sesija pada, ili ju klijent sam može zatvoriti.
Nema toliko značajki, ali s ovim API-jem možete raditi različite stvari. Taj poziv koji smo vidjeli stvara stvara znode i uzima tri parametra. Ovo je put do znodea, i mora biti specificiran u cijelosti od korijena. A ovo su i neki podaci koje želimo tamo prenijeti. I vrsta zastave. I nakon stvaranja vraća put do znodea.
Drugo, možete ga izbrisati. Trik je u tome što drugi parametar, osim staze do znodea, može odrediti verziju. Sukladno tome, taj znode bit će izbrisan ako je njegova verzija koju smo prenijeli ekvivalentna onoj koja stvarno postoji.
Ako ne želimo provjeriti ovu verziju, jednostavno proslijeđujemo argument "-1".
Treće, provjerava postojanje znoda. Vraća true ako čvor postoji, false u suprotnom.
Zatim se pojavljuje praćenje zastavice, što vam omogućuje praćenje ovog čvora.
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 getData. Jasno je da podatke možemo primati putem znodea. Također možete koristiti sat sa zastavom. U ovom slučaju, neće se instalirati ako nema čvora. Stoga morate shvatiti da postoji, a zatim primiti podatke.
Postoji također SetData. Ovdje prenosimo verziju. A ako ovo proslijedimo, ažurirat će se podaci o znodeu određene verzije.
Također možete navesti "-1" da biste isključili ovu provjeru.
Još jedna korisna metoda je getChildren. Također možemo dobiti popis svih znoda koji mu pripadaju. To možemo pratiti postavljanjem nadzora zastavice.
I metoda sinkronizirati omogućuje slanje svih promjena odjednom, čime se osigurava da su spremljene i da su svi podaci potpuno promijenjeni.
Ako povučemo analogije s uobičajenim programiranjem, onda kada koristite metode kao što je write, koja nešto zapisuje na disk, a nakon što vam vrati odgovor, nema jamstva da ste zapisali podatke na disk. Pa čak i kada je operativni sustav siguran da je sve zapisano, postoje mehanizmi u samom disku gdje proces prolazi kroz slojeve međuspremnika, a tek nakon toga podaci se smještaju na disk.
Uglavnom se koriste asinkroni pozivi. To omogućuje klijentu da radi paralelno s različitim zahtjevima. Možete koristiti sinkroni pristup, ali je manje produktivan.
Dvije operacije o kojima smo govorili su ažuriranje/pisanje, koje mijenjaju podatke. To su create, setData, sync, delete. I čitanje postoji, getData, getChildren.
Sada nekoliko primjera kako možete napraviti primitive za rad u distribuiranom sustavu. Na primjer, u vezi s konfiguracijom nečega. Pojavio se novi radnik. Dodali smo stroj i započeli proces. A tu su i sljedeća tri pitanja. Kako ZooKeeperu postavlja upit za konfiguraciju? A ako želimo promijeniti konfiguraciju, kako to promijeniti? A nakon što smo ga promijenili, kako ga oni radnici koje smo imali dobili?
ZooKeeper to čini relativno lakim. Na primjer, tu je naše znode stablo. Ovdje postoji čvor za našu aplikaciju, u njemu kreiramo dodatni čvor koji sadrži podatke iz konfiguracije. To mogu, ali i ne moraju biti zasebni parametri. Budući da je veličina mala, veličina konfiguracije također je obično mala, tako da je sasvim moguće pohraniti ga ovdje.
Vi koristite metodu getData da biste dobili konfiguraciju za radnika iz čvora. Postavite na istinito. Ako iz nekog razloga ovaj čvor ne postoji, o tome ćemo biti obaviješteni kada se pojavi, odnosno kada se promijeni. Ako želimo znati da se nešto promijenilo, onda to postavimo 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 trebamo pohranjivati mnogo konfiguracija. Ako trebate puno pohraniti, morat ćete dodati još jednu razinu. Ovdje vjerujemo da postoji samo jedan, pa ažuriramo samo najnoviji, tako da ne provjeravamo verziju. U ovom trenutku svi klijenti koji su se prethodno pretplatili dobivaju obavijest da se nešto promijenilo u ovom čvoru. A nakon što ih dobiju, moraju ponovno zatražiti podatke. Obavijest je da ne dobivaju same podatke, već samo obavijest o promjenama. Nakon toga moraju zatražiti nove podatke.
Druga opcija za korištenje primitive je članstvo u grupi. Imamo distribuiranu aplikaciju, ima hrpa radnika i želimo shvatiti da su svi na mjestu. Stoga se moraju sami 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 ćemo to učiniti? Za aplikaciju stvaramo radni čvor i dodajemo podrazinu pomoću metode create. Imam grešku na slajdu. Ovdje trebate dosljedan navedite, tada će svi radnici biti kreirani jedan po jedan. A aplikacija, tražeći sve podatke o djeci ovog čvora, prima sve aktivne radnike koji postoje.
Ovo je tako užasna implementacija toga kako se to može učiniti u Java kodu. Krenimo od kraja, s glavnom metodom. Ovo je naša klasa, kreirajmo njenu metodu. Kao prvi argument koristimo host, gdje se povezujemo, tj. postavljamo ga kao argument. A drugi argument je naziv grupe.
Kako dolazi do povezivanja? Ovo je jednostavan primjer API-ja koji se koristi. Ovdje je sve relativno jednostavno. Postoji standardna klasa ZooKeeper. Prenosimo domaćine na to. I postavite timeout, na primjer, na 5 sekundi. I imamo člana koji se zove ConnectedSignal. U biti, mi stvaramo grupu duž odaslanog puta. Tu ne upisujemo podatke, iako se moglo nešto napisati. A čvor je ovdje postojanog tipa. U biti, ovo je običan regularni čvor koji će postojati cijelo vrijeme. Ovdje se kreira sesija. Ovo je implementacija samog klijenta. Naš klijent će povremeno javljati da je sesija živa. I kad završimo session, zovemo close i to je to, session 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 kompliciranije. Imamo skup radnika, postoji neki resurs koji želimo zaključati. Da bismo to učinili, stvaramo zasebni čvor, na primjer, pod nazivom lock1. Ako smo ga uspjeli stvoriti, onda imamo bravu ovdje. A ako ga nismo uspjeli kreirati, tada radnik pokušava dobiti getData odavde, a budući da je čvor već kreiran, tada stavljamo promatrača ovdje i onog trenutka kada se stanje ovog čvora promijeni, znat ćemo za to. I možemo pokušati imati vremena da ga ponovno stvorimo. Ako smo uzeli ovaj čvor, uzeli ovo zaključavanje, nakon što nam zaključavanje više ne treba, napustit ćemo ga, budući da čvor postoji samo unutar sesije. Sukladno tome, nestat će. I drugi klijent, u okviru druge sesije, moći će zaključati ovaj čvor, odnosno dobit će obavijest da se nešto promijenilo i može to pokušati učiniti na vrijeme.
Još jedan primjer kako možete izabrati glavnog vođu. Ovo je malo kompliciranije, ali i relativno jednostavno. Što se ovdje događa? Postoji glavni čvor koji okuplja sve radnike. Pokušavamo doći do podataka o vođi. Ako se to uspješno dogodilo, tj. primili smo neke podatke, tada naš radnik počinje slijediti ovog vođu. Vjeruje da vođa već postoji.
Ako je vođa iz nekog razloga umro, na primjer, otpao, tada pokušavamo stvoriti novog vođu. A ako uspijemo, onda naš radnik postaje vođa. A ako je netko u ovom trenutku uspio stvoriti novog vođu, onda pokušavamo shvatiti tko je to i onda ga slijediti.
Tu nastaje tzv. efekt krda, odnosno efekt krda, jer kada vođa umre, onaj koji je prvi po vremenu postaje vođa.
Kada hvatate resurs, možete pokušati koristiti nešto drugačiji pristup, koji je sljedeći. Na primjer, želimo dobiti bravu, ali bez hert efekta. Sastojat će se u činjenici da naša aplikacija traži popise svih ID-ova čvorova za već postojeći čvor s zaključavanjem. A ako je prije toga čvor za koji smo kreirali bravu najmanji u skupu koji smo primili, to znači da smo uhvatili bravu. Provjeravamo da li smo primili 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šeg zaključavanja, tada stavljamo promatrača na ovaj događaj i čekamo obavijest dok se nešto ne promijeni. To jest, dobili smo ovu bravu. I dok ne otpadne, nećemo postati minimalni id i nećemo dobiti minimalni lock, a time ćemo se moći ulogirati. A ako ovaj uvjet nije ispunjen, odmah idemo ovamo i pokušavamo ponovo dobiti ovu bravu, jer se možda nešto promijenilo za to vrijeme.
Od čega se sastoji ZooKeeper? Postoje 4 glavne stvari. Ovo su procesi obrade - Zahtjev. I također ZooKeeper Atomic Broadcast. Postoji Commit Log gdje se bilježe sve operacije. I sama In-memory Replicated DB, tj. sama baza podataka gdje je pohranjeno cijelo ovo stablo.
Važno je napomenuti da sve operacije pisanja prolaze kroz procesor zahtjeva. A operacije čitanja idu izravno u In-memory bazu podataka.
Sama baza podataka je u potpunosti replicirana. Sve instance ZooKeepera pohranjuju potpunu kopiju podataka.
Kako bi se baza podataka vratila nakon pada, postoji Commit log. Standardna praksa je da se prije nego što podaci uđu u memoriju tamo zapišu tako da se, ako se sruše, ovaj zapisnik može reproducirati i vratiti u stanje sustava. Koriste se i periodične snimke baze podataka.
ZooKeeper Atomic Broadcast je stvar koja se koristi za održavanje repliciranih podataka.
ZAB interno odabire voditelja sa stajališta čvora ZooKeeper. Ostali čvorovi postaju njezini sljedbenici i očekuju neke akcije od nje. Ako prime prijave, sve ih prosljeđuju voditelju. Prvo izvodi operaciju pisanja, a zatim šalje poruku o tome što se promijenilo svojim sljedbenicima. To se, zapravo, mora izvesti atomski, tj. operacija snimanja i emitiranja cijele stvari mora biti izvedena atomski, čime se jamči dosljednost podataka.
Obrađuje samo zahtjeve za pisanje. Njegova glavna zadaća je da transformira operaciju u transakcijsko ažuriranje. Ovo je posebno generirani zahtjev.
I ovdje je vrijedno napomenuti da je idempotencija ažuriranja za istu operaciju zajamčena. Što je? Ova stvar, ako se izvrši dva puta, imat će isto stanje, tj. sam zahtjev se neće promijeniti. I to je potrebno učiniti kako biste u slučaju pada mogli ponovno pokrenuti operaciju i time vratiti promjene koje su trenutno pale. U tom će slučaju stanje sustava postati isto, odnosno ne bi se smjelo dogoditi da niz istih, npr. procesa ažuriranja, dovodi do različitih konačnih stanja sustava.
Izvor: www.habr.com