"Hadoop. ZooKeeper" hitzaldiaren transkripzioa irakurtzea gomendatzen dizut "Hadoop-en datu-bolumen handien prozesatzeko metodoak" saileko
Zer da ZooKeeper, bere lekua Hadoop ekosisteman. Banatutako konputazioaren inguruko egiak. Banatutako sistema estandar baten diagrama. Banatutako sistemak koordinatzeko zailtasuna. Koordinazio-arazo tipikoak. ZooKeeper-en diseinuaren atzean dauden printzipioak. ZooKeeper datu-eredua. znode banderak. Saioak. Bezeroaren APIa. Primitiboak (konfigurazioa, taldekidetasuna, blokeo soilak, buruzagi-hautespena, artalde efekturik gabeko blokeoa). ZooKeeper arkitektura. ZooKeeper DB. ZAB. Eskaera kudeatzailea.
Gaur ZooKeeper-i buruz hitz egingo dugu. Gauza hau oso erabilgarria da. Apache Hadoop produktuak bezala, logotipoa du. Gizon bat irudikatzen du.
Honen aurretik, batez ere, han datuak nola prozesatu daitezkeen hitz egin dugu, nola gorde, hau da, nolabait erabili eta nolabait lan egin. Eta gaur apur bat hitz egin nahiko nuke banatutako aplikazioak eraikitzeari buruz. Eta ZooKeeper gai hau sinplifikatzeko aukera ematen duen gauza horietako bat da. Sistema banatuetan, aplikazio banatuetan, prozesuen elkarrekintzaren nolabaiteko koordinaziorako pentsatutako zerbitzu moduko bat da.
Horrelako aplikazioen beharra egunero gero eta handiagoa da, horixe da gure ikastaroa. Alde batetik, MapReducek eta prest egindako marko honek konplexutasun hori berdindu eta programatzailea prozesuen interakzioa eta koordinazioa bezalako primitiboak idaztetik askatzeko aukera ematen du. Baina, bestalde, inork ez du ziurtatzen hori hala ere egin beharko ez denik. MapReduce edo prest dauden beste esparru batzuek ez dituzte beti guztiz ordezkatzen hau erabiliz inplementatu ezin diren kasu batzuk. MapReduce bera eta beste Apache proiektu mordoa barne; izan ere, banatutako aplikazioak dira. Eta idaztea errazteko, ZooKeeper idatzi zuten.
Hadoop-ekin lotutako aplikazio guztiak bezala, Yahoo!-k garatu zuen. Orain Apache aplikazio ofiziala ere bada. Ez da HBase bezain aktiboki garatu. JIRA HBasera joaten bazara, egunero akatsen txosten mordoa dago, zerbait optimizatzeko proposamen mordoa, hau da, proiektuan bizitza etengabe gertatzen da. Eta ZooKeeper, alde batetik, nahiko produktu sinplea da, eta, bestetik, horrek bere fidagarritasuna bermatzen du. Eta erabiltzeko nahiko erraza da, eta horregatik estandar bihurtu da Hadoop ekosistemaren aplikazioetan. Beraz, pentsatu nuen komenigarria izango zela errepasatzea nola funtzionatzen duen eta nola erabili ulertzeko.
Hau izan genuen hitzaldi bateko argazkia da. Orain arte kontuan hartu dugun guztiarekin ortogonala dela esan dezakegu. Eta hemen adierazten den guztia, neurri batean edo bestean, ZooKeeper-ekin funtzionatzen du, hau da, produktu horiek guztiak erabiltzen dituen zerbitzu bat da. Ez HDFSek ez MapReducek ez dute berariaz lan egingo luketen antzeko zerbitzurik idazten. Horren arabera, ZooKeeper erabiltzen da. Eta horrek garapena eta akatsekin lotutako gauza batzuk errazten ditu.
Nondik dator hori guztia? Badirudi ordenagailu ezberdinetan paraleloan bi aplikazio martxan jarri genituela, kate batekin edo sare batean konektatu, eta dena funtzionatzen du. Baina arazoa da Sarea ez dela fidagarria, eta trafikoa usaintzen baduzu edo han gertatzen dena maila baxuan begiratuz gero, bezeroek Sarean nola elkarreragiten duten, askotan ikus dezakezu pakete batzuk galtzen edo berriro bidaltzen direla. Ez da ezertarako asmatu TCP protokoloak, saio jakin bat ezartzeko eta mezuen bidalketa bermatzeko aukera ematen dutenak. Baina, nolanahi ere, TCPk ere ezin zaitu beti salbatu. Denak dauka denbora-muga. Baliteke sarea denbora batez erortzea. Baliteke keinu egitea. Eta horrek guztiak Sarea fidagarria izatean ezin duzula fidatu dakar. Hau da ordenagailu batean edo superordenagailu batean exekutatzen diren aplikazio paraleloak idaztetik dagoen desberdintasun nagusia, non Sarerik ez dagoenean, non memorian datu truke-bus fidagarriagoa dagoen. Eta hau funtsezko aldea da.
Besteak beste, Sarea erabiltzean beti dago nolabaiteko latentzia bat. Diskoak ere badu, baina Sareak gehiago dauka. Latentzia atzerapen-denbora bat da, txikia edo nahiko esanguratsua izan daitekeena.
Sarearen topologia aldatzen ari da. Zer da topologia - hau da gure sareko ekipoen kokapena. Datu zentroak daude, hor zutik dauden rackak daude, kandelak daude. Hori guztia berriro konektatu, mugitu, etab. Hori guztia ere kontuan hartu behar da. IP izenak aldatzen dira, gure trafikoa ibiltzen den bideratzea aldatzen da. Hau ere kontuan hartu behar da.
Ekipamendu aldetik ere alda daiteke sarea. Praktikaren arabera, esan dezaket gure sareko ingeniariei asko gustatzen zaiela noizean behin kandelei buruzko zerbait eguneratzea. Bat-batean firmware berri bat atera zen eta ez ziren bereziki interesatzen Hadoop kluster batzuk. Beren lana dute. Haientzat, nagusia da Sareak funtzionatzea. Horren arabera, han zerbait berriro kargatu nahi dute, beren hardwarean keinuka egin eta hardwarea ere aldatzen da aldian-aldian. Hori guztia nolabait kontuan hartu behar da. Horrek guztiak gure aplikazio banatuan eragiten du.
Normalean arrazoiren bategatik datu kopuru handiekin lanean hasten diren pertsonek Internet mugagabea dela uste dute. Bertan hainbat terabyteko fitxategi bat badago, zure zerbitzari edo ordenagailura eraman dezakezu eta erabiliz ireki cat eta ikusi. Beste akats bat dago Vim begiratu erregistroak. Inoiz ez egin hau txarra delako. Vim dena bufferatzen saiatzen delako, dena memorian kargatzen, batez ere erregistro honetan mugitzen eta zerbait bilatzen hasten garenean. Horiek ahaztu egiten diren gauzak dira, baina kontuan hartzekoak.
Errazagoa da prozesadore batekin ordenagailu batean exekutatzen den programa bat idaztea.
Gure sistema hazten denean, dena paralelizatu nahi dugu, eta ordenagailu batean ez ezik, cluster batean ere paralelizatu nahi dugu. Galdera sortzen da: nola koordinatu gai hau? Baliteke gure aplikazioak elkarren artean elkarreragina ere ez egitea, baina hainbat prozesu paraleloan exekutatu ditugu hainbat zerbitzaritan. Eta nola kontrolatu dena ondo doala? Adibidez, Internet bidez zerbait bidaltzen dute. Beren egoerari buruz idatzi behar dute nonbait, adibidez, datu-base edo erregistro mota batean, gero erregistro hau batu eta gero nonbait aztertu. Gainera, kontuan izan behar dugu prozesua funtzionatzen eta funtzionatzen ari zela, bat-batean akatsen bat agertu zela edo huts egin zela, orduan zein azkar jakingo dugu horren berri?
Argi dago hori guztia azkar kontrolatu daitekeela. Hau ere ona da, baina monitorizazioa gauza mugatua da, gauza batzuk maila gorenean kontrolatzeko aukera ematen duena.
Gure prozesuak elkarren artean elkarreragin hastea nahi dugunean, adibidez, elkarri datu batzuk bidaltzea, orduan ere galdera sortzen da: nola gertatuko da hori? Lasterketa-baldintzaren bat egongo al da, batak besteari gainidatziko al dira, datuak behar bezala iritsiko dira, bidean ezer galduko al da? Nolabaiteko protokolo bat garatu behar dugu, etab.
Prozesu horien guztien koordinazioa ez da gauza hutsala. Eta garatzailea behartzen du maila baxuago batera jeitstera, eta sistemak hutsetik idaztera, edo hutsetik guztiz, baina hau ez da hain erraza.
Algoritmo kriptografiko bat sortzen baduzu edo inplementatzen baduzu, berehala bota ezazu, ziurrenik ez duzulako balioko. Seguruenik, ematea ahaztu zaizun akats mordoa edukiko du. Inoiz ez erabili ezer larrietarako, ziurrenik ezegonkorra izango delako. Dauden algoritmo guztiak denborak oso denbora luzez probatu baititu. Komunitateak akatsa du. Hau aparteko gaia da. Eta hemen ere berdin. Prozesuaren sinkronizazio motaren bat zuk zeuk ez ezartzea posible bada, hobe da hori ez egitea, nahiko konplikatua delako eta etengabe akatsak bilatzeko bide astindutik eramaten zaituelako.
Gaur ZooKeeper buruz ari gara. Alde batetik, esparru bat da, bestetik, garatzaileari bizitza errazten dion zerbitzua eta gure prozesuen logika eta koordinazioa ahal den neurrian ezartzea errazten duen zerbitzua da.
Gogora dezagun nolakoa izan daitekeen banatutako sistema estandar bat. Honetaz hitz egin genuen - HDFS, HBase. Langileak eta esklabo prozesuak kudeatzen dituen Master prozesu bat dago. Zereginak koordinatzea eta banatzeaz, langileak berrabiarazteaz, berriak abiarazteaz eta zama banatzeaz arduratzen da.
Gauza aurreratuago bat Koordinazio Zerbitzua da, hau da, koordinazio-zerbitzua bera prozesu bereizi batera eraman, eta, gainera, segurtasun-kopia edo stanby Master moduko bat exekutatu paraleloan, Masterrak huts egin dezakeelako. Eta Maisua erortzen bada, orduan gure sistemak ez du funtzionatuko. Babeskopia exekutatzen ari gara. Zenbait estatuek maisua babeskopian errepikatu behar dela diote. Hori ere Koordinazio Zerbitzuaren esku utz daiteke. Baina diagrama honetan, Masterra bera arduratzen da langileak koordinatzeaz; hemen zerbitzuak datuak erreplikatzeko jarduerak koordinatzen ditu.
Aukera aurreratuagoa da koordinazio guztia gure zerbitzuak kudeatzen duenean, egin ohi den moduan. Dena funtzionatzen duela ziurtatzeko ardura hartzen du. Eta zerbaitek ez badu funtzionatzen, horren berri jakin eta egoera hau konpontzen saiatzen gara. Nolanahi ere, esklaboekin nolabait elkarreragiten duen eta zerbitzu batzuen bitartez datuak, informazioa, mezuak eta abar bidal ditzakeen Maisu batekin geratzen gara.
Are eskema aurreratuagoa dago, Maisurik ez dugunean, nodo guztiak esklabo nagusiak dira, portaeran desberdinak. Baina oraindik elkarreragin behar dute, beraz, ekintza hauek koordinatzeko zerbitzuren bat geratzen da oraindik. Ziurrenik, Cassandra, printzipio honetan lan egiten duena, eskema honetara egokitzen da.
Zaila da esatea zeinek funtzionatzen duen hobeto. Bakoitzak bere alde onak eta txarrak ditu.
Eta ez dago gauza batzuen beldurrik izan behar Maisuarekin, zeren, praktikak erakusten duen bezala, ez baita etengabe zerbitzatzeko. Hemen gauza nagusia zerbitzu hau nodo indartsu batean ostatatzeko irtenbide egokia aukeratzea da, baliabide nahikoa izan dezan, ahal izanez gero, erabiltzaileek bertan sarbiderik izan ez dezaten, prozesu hau ustekabean hil ez dezaten. Baina, aldi berean, horrelako eskema batean askoz errazagoa da Master prozesutik langileak kudeatzea, hau da, eskema hau sinpleagoa da ezarpenaren ikuspuntutik.
Eta eskema hau (goian) seguruenik konplexuagoa da, baina fidagarriagoa.
Arazo nagusia hutsegite partzialak dira. Adibidez, mezu bat Saretik bidaltzen dugunean, nolabaiteko istripu bat gertatzen da, eta mezua bidali duenak ez du jakingo bere mezua jaso den eta hartzailearen aldetik zer gertatu den, ez du jakingo mezua behar bezala prozesatu den. , hau da, ez du baieztapenik jasoko.
Horren arabera, egoera hau bideratu behar dugu. Eta errazena mezu hau berriro bidaltzea eta erantzuna jaso arte itxarotea da. Kasu honetan, ez da kontuan hartzen hartzailearen egoera aldatu den. Baliteke mezu bat bidali eta datu berdinak bi aldiz gehitzea.
ZooKeeper-ek horrelako ukoei aurre egiteko bideak eskaintzen ditu, eta horrek ere gure bizitza errazten du.
Lehenago esan bezala, hari anitzeko programak idaztearen antzekoa da, baina desberdintasun nagusia da makina ezberdinetan eraikitzen ditugun aplikazio banatuetan, komunikatzeko modu bakarra Sarea dela. Funtsean, partekatutako ezer ez den arkitektura da. Makina batean exekutatzen den prozesu edo zerbitzu bakoitzak bere memoria du, bere diskoa, bere prozesadorea, inorekin partekatzen ez duena.
Hari anitzeko programa bat ordenagailu batean idazten badugu, memoria partekatua erabil dezakegu datuak trukatzeko. Testuinguru aldaketa bat dugu hor, prozesuak alda daitezke. Horrek errendimenduari eragiten dio. Alde batetik, programan ez dago kluster batean, baina arazoak daude Sarearekin.
Horren arabera, sistema banatuak idaztean sortzen diren arazo nagusiak konfigurazioa dira. Aplikazio mota bat idazten ari gara. Sinplea bada, era guztietako zenbakiak gogor kodetzen ditugu kodean, baina hori deserosoa da, segundo erdiko denbora-muga izan ordez segundo bateko denbora-muga nahi dugula erabakitzen badugu, aplikazioa berriro konpilatu behar dugu eta atera dena berriro. Gauza bat da makina batean dagoenean, berrabiarazi besterik ez duzunean, baina makina asko ditugunean, dena kopiatu behar dugu etengabe. Aplikazioa konfiguragarria egiten saiatu behar dugu.
Hemen sistema-prozesuen konfigurazio estatikoaz ari gara. Hau ez da guztiz, agian sistema eragilearen ikuspuntutik, gure prozesuentzako konfigurazio estatiko bat izan daiteke, hau da, besterik gabe hartu eta eguneratu ezin den konfigurazioa da.
Konfigurazio dinamiko bat ere badago. Hauek dira hegan aldatu nahi ditugun parametroak, bertan jaso daitezen.
Zein da hemen arazoa? Konfigurazioa eguneratu dugu, zabaldu dugu, eta zer? Arazoa izan daiteke alde batetik konfigurazioa zabaldu genuela, baina gauza berriaz ahaztuta, konfigurazioa hor geratu zen. Bigarrenik, zabaltzen ari ginen bitartean, konfigurazioa eguneratu zen leku batzuetan, baina ez besteetan. Eta makina batean exekutatzen diren gure aplikazioaren prozesu batzuk konfigurazio berri batekin berrabiarazi ziren, eta nonbait zahar batekin. Honek gure banatutako aplikazioa koherentea izan daiteke konfigurazio ikuspegitik. Arazo hau ohikoa da. Konfigurazio dinamiko baterako, garrantzitsuagoa da hegan alda daitekeela suposatzen duelako.
Beste arazo bat taldekide izatea da. Beti ditugu langile multzoren bat, beti jakin nahi dugu zein den bizirik, zein den hilda. Maisu bat badago, orduan ulertu behar du zein langile birbideratu daitezkeen bezeroetara, kalkuluak egiteko edo datuekin lan egiteko, eta zeintzuk ez. Etengabe sortzen den arazo bat da jakin behar dugula nor ari den lanean gure klusterrean.
Beste arazo tipiko bat buruzagi-hauteskundeak dira, nork agintzen duen jakin nahi dugunean. Adibide bat erreplikazioa da, idazketa-eragiketak jasotzen dituen prozesuren bat dugunean eta, ondoren, beste prozesu batzuen artean errepikatzen duena. Bera izango da buruzagia, beste guztiek obedituko diote, jarraitu egingo diote. Beharrezkoa da prozesu bat aukeratu behar da guztiontzat anbiguoa izan dadin, bi buruzagi hautatzen ez daitezen.
Elkarren arteko sarbidea ere badago. Hemen arazoa konplexuagoa da. Mutex bezalako gauza bat dago, hari anitzeko programak idazten dituzunean eta baliabide batzuetarako sarbidea nahi duzunean, adibidez, memoria-zelula bat, hari bakarrarekin mugatu eta gauzatu dadin. Hemen baliabidea zerbait abstraktuagoa izan daiteke. Eta gure Sareko nodo ezberdinetako aplikazio ezberdinek baliabide jakin baterako sarbide esklusiboa soilik jaso beharko lukete, eta ez denek alda dezaten edo bertan zerbait idazteko. Hauek sarrailak deiturikoak dira.
ZooKeeper-ek arazo horiek guztiak neurri batean edo bestean konpontzeko aukera ematen du. Eta adibideekin erakutsiko dizut hori egiteko aukera ematen dizun.
Ez dago blokeo primitiborik. Zerbait erabiltzen hasten garenean, primitibo honek ez du gertaerarik gertatu arte itxarongo. Seguruenik, gauza honek modu asinkronoan funtzionatuko du, eta horrela prozesuak ez zintzilikatzeko aukera emango du zerbaiten zain dauden bitartean. Hau oso gauza erabilgarria da.
Bezeroen eskaera guztiak ilara orokorraren ordenan prozesatzen dira.
Eta bezeroek egoera batzuetako aldaketei buruzko jakinarazpena jasotzeko aukera dute, datuen aldaketei buruz, bezeroak aldatutako datuak berak ikusi aurretik.
ZooKeeper-ek bi modutan funtziona dezake. Lehenengoa autonomoa da, nodo batean. Hau erosoa da probak egiteko. Kluster moduan ere funtziona dezake edozein zerbitzaritan. 100 makina multzo bat badugu, ez da beharrezkoa 100 makinatan lan egitea. Nahikoa da ZooKeeper exekutatu dezakezun hainbat makina hautatzea. Eta erabilgarritasun handiko printzipioa aldarrikatzen du. Exekutatzen den instantzia bakoitzean, ZooKeeper-ek datuen kopia oso bat gordetzen du. Geroxeago esango dizut nola egiten duen. Ez ditu datuak zatitzen edo zatitzen. Alde batetik, minus bat da asko gorde ezin dugula, bestetik, ez dago hau egin beharrik. Ez da horretarako diseinatuta, ez da datu-base bat.
Datuak bezeroaren aldean gorde daitezke. Printzipio estandar bat da, zerbitzua eten ez dezagun eta eskaera berdinekin kargatu ez dezagun. Bezero adimendun batek normalean badaki honi buruz eta gordetzen du.
Adibidez, hemen zerbait aldatu da. Badago nolabaiteko aplikazioa. Buruzagi berria aukeratu zen, idazketa eragiketak prozesatzeaz arduratzen dena, adibidez. Eta datuak errepikatu nahi ditugu. Irtenbide bat begizta batean jartzea da. Eta etengabe zalantzan jartzen dugu gure zerbitzua - zerbait aldatu al da? Bigarren aukera optimoagoa da. Bezeroei zerbait aldatu dela jakinarazteko aukera ematen duen erloju-mekanismoa da. Baliabideei dagokienez, metodo merkeagoa da eta bezeroentzat erosoagoa.
Bezeroa ZooKeeper erabiltzen duen erabiltzailea da.
Zerbitzaria ZooKeeper prozesua bera da.
Znode da ZooKeeper-en funtsezko gauza. ZooKeeper-ek znodo guztiak memorian gordetzen ditu eta diagrama hierarkiko baten moduan antolatzen dira, zuhaitz moduan.
Bi eragiketa mota daude. Lehenengoa eguneratzea/idaztea da, eragiketa batek gure zuhaitzaren egoera aldatzen duenean. Zuhaitza ohikoa da.
Eta baliteke bezeroak eskaera bat ez betetzea eta deskonektatzea, baina ZooKeeper-ekin elkarreragiten duen saio bat ezar dezake.
ZooKeeper-en datu-ereduak fitxategi-sistema baten antza du. Erro estandar bat dago eta gero errotik doazen direktorioetatik joan ginen. Eta gero lehen mailako katalogoa, bigarren mailakoa. Hau guztia znodes da.
Znode bakoitzak datu batzuk gorde ditzake, normalean ez oso handiak, adibidez, 10 kilobyte. Eta znode bakoitzak haur kopuru jakin bat izan dezake.
Znodeak hainbat motatakoak dira. Sortu daitezke. Eta znode bat sortzean, zein motatakoa izan behar duen zehazten dugu.
Bi mota daude. Lehenengoa bandera iragankorra da. Znode saio baten barruan bizi da. Adibidez, bezeroak saio bat ezarri du. Eta saio hau bizirik dagoen bitartean, existituko da. Hau beharrezkoa da alferrikako zerbait ez sortzeko. Hau ere egokia da saio baten barruan datu primitiboak gordetzea garrantzitsua den momentuetarako.
Bigarren mota bandera sekuentziala da. Kontagailua handitzen du znoderako bidean. Adibidez, direktorio bat genuen 1_5 aplikazioarekin. Eta lehenengo nodoa sortu genuenean, p_1 jaso zuen, bigarrena - p_2. Eta metodo honi aldi bakoitzean deitzen diogunean, bide osoa pasatzen dugu, bidearen zati bat bakarrik adieraziz, eta zenbaki hori automatikoki handitzen da nodo mota - sekuentziala adierazten dugulako.
Znode erregularra. Beti biziko da eta guk esaten diogun izena izango du.
Beste gauza erabilgarria erlojuaren bandera da. Instalatzen badugu, bezeroak nodo jakin baterako gertaera batzuetara harpidetu daiteke. Aurrerago erakutsiko dizut nola egiten den adibide batekin. ZooKeeper-ek berak bezeroari jakinarazten dio nodoko datuak aldatu direla. Hala ere, jakinarazpenek ez dute bermatzen datu berri batzuk iritsi direnik. Zerbait aldatu dela esaten dute, beraz, oraindik datuak alderatu behar dituzu gero dei bereiziekin.
Eta lehen esan bezala, datuen ordena kilobyteka zehazten da. Ez dago testu-datu handiak bertan gordetzeko beharrik, ez baita datu-base bat, ekintzak koordinatzeko zerbitzari bat da.
Saioen berri apur bat kontatuko dizuet. Zerbitzari bat baino gehiago baditugu, zerbitzari batetik bestera modu gardenean mugi gaitezke saio-identifikatzailea erabiliz. Nahiko erosoa da.
Saio bakoitzak denbora-muga bat du. Saio bat bezeroak zerbitzariari ezer bidaltzen duen ala ez definitzen da saio horretan zehar. Denbora-mugan zehar ez badu ezer transmititu, saioa erortzen da, edo bezeroak berak itxi dezake.
Ez ditu hainbeste funtzio, baina gauza desberdinak egin ditzakezu API honekin. Sortzen ikusi genuen dei horrek znode bat sortzen du eta hiru parametro hartzen ditu. Hau da znoderako bidea, eta errotik osorik zehaztu behar da. Eta horra transferitu nahi ditugun datu batzuk ere. Eta bandera mota. Eta sortu ondoren znoderako bidea itzultzen du.
Bigarrenik, ezabatu dezakezu. Hemen trikimailua da bigarren parametroak, znoderako bideaz gain, bertsioa zehaztu dezakeela. Horren arabera, znode hori ezabatu egingo da transferitu dugun bertsioa benetan dagoenaren baliokidea bada.
Bertsio hau egiaztatu nahi ez badugu, "-1" argumentua pasako dugu.
Hirugarrenik, znode bat dagoen egiaztatzen du. Truea ematen du nodoa existitzen bada, false bestela.
Eta gero banderaren zaintza agertzen da, nodo hau kontrolatzeko aukera ematen duena.
Bandera hau existitzen ez den nodo batean ere ezar dezakezu eta agertzean jakinarazpen bat jaso dezakezu. Hau ere erabilgarria izan daiteke.
Erronka pare bat gehiago dira getData. Argi dago znode bidez datuak jaso ditzakegula. Banderaren erlojua ere erabil dezakezu. Kasu honetan, ez da instalatuko nodorik ez badago. Hori dela eta, existitzen dela ulertu behar duzu, eta gero datuak jaso.
Badago ere EzarriData. Hemen bertsioa pasatzen dugu. Eta hau pasatzen badugu, bertsio jakin baten znodeko datuak eguneratuko dira.
"-1" ere zehaztu dezakezu egiaztapen hau baztertzeko.
Beste metodo erabilgarria da getChildren. Berari dagozkion znode guztien zerrenda ere lor dezakegu. Honen jarraipena egin dezakegu banderaren zaintza ezarriz.
Eta metodoa sinkronizatu Aldaketa guztiak aldi berean bidaltzeko aukera ematen du, horrela gordeko direla eta datu guztiak guztiz aldatu direla bermatuz.
Programazio arruntarekin analogiak marrazten baditugu, idazketa bezalako metodoak erabiltzen dituzunean, diskoan zerbait idazten dutenak eta erantzun bat itzultzen dizunean, ez dago bermatzen datuak diskoan idatzi dituzunik. Eta sistema eragilea dena idatzita dagoela ziur dagoenean ere, diskoan bertan prozesuak buffer geruzak igarotzen dituen mekanismoak daude, eta horren ondoren datuak diskoan jartzen dira.
Gehienetan dei asinkronoak erabiltzen dira. Horri esker, bezeroak eskaera ezberdinekin paraleloan lan egin dezake. Ikuspegi sinkronikoa erabil dezakezu, baina ez da hain produktiboa.
Hitz egin ditugun bi eragiketak eguneratzea/idaztea dira, datuak aldatzen dituztenak. Hauek dira sortu, ezarriData, sinkronizatu, ezabatu. Eta irakurtzea existitzen da, getData, getChildren.
Orain sistema banatu batean lan egiteko primitiboak egin ditzakezun adibide batzuk. Adibidez, zerbaiten konfigurazioarekin lotuta. Langile berri bat agertu da. Makina gehitu eta prozesuari ekin genion. Eta hurrengo hiru galderak daude. Nola galdetzen dio ZooKeeper-i konfiguraziorako? Eta konfigurazioa aldatu nahi badugu, nola aldatuko dugu? Eta aldatu ondoren, nola lortzen dute geneukan langile horiek?
ZooKeeper-ek hau nahiko erraza egiten du. Adibidez, gure znode zuhaitza dago. Gure aplikaziorako nodo bat dago hemen, nodo gehigarri bat sortzen dugu bertan, konfigurazioko datuak dituena. Hauek parametro bereiziak izan daitezke edo ez. Tamaina txikia denez, konfigurazioaren tamaina ere txikia izan ohi da, beraz, oso posible da hemen gordetzea.
Metodoa erabiltzen ari zara getData langilearen konfigurazioa nodotik lortzeko. Ezarri egia gisa. Arrazoiren batengatik nodo hori existitzen ez bada, horren berri emango zaigu noiz agertzen den edo noiz aldatzen den. Zerbait aldatu dela jakin nahi badugu, egia ezarriko dugu. Eta nodo honetako datuak aldatzen badira, horren berri izango dugu.
EzarriData. Datuak ezartzen ditugu, "-1" ezartzen dugu, hau da, ez dugu bertsioa egiaztatzen, beti konfigurazio bat dugula suposatzen dugu, ez ditugu konfigurazio asko gorde behar. Asko gorde behar baduzu, beste maila bat gehitu beharko duzu. Hemen uste dugu bakarra dagoela, beraz, azkena bakarrik eguneratzen dugu, beraz, ez dugu bertsioa egiaztatzen. Momentu honetan, aurretik harpidetuta dauden bezero guztiek nodo honetan zerbait aldatu dela dioen jakinarazpena jasotzen dute. Eta jaso ondoren, berriz ere eskatu beharko dituzte datuak. Jakinarazpena da ez dutela datuak berak jasotzen, aldaketen jakinarazpena baizik. Horren ostean datu berriak eskatu behar dituzte.
Primitiboa erabiltzeko bigarren aukera da taldekidetasuna. Banatutako aplikazioa dugu, langile mordoa dago eta denak jarrita daudela ulertu nahi dugu. Hori dela eta, beraiek erregistratu behar dute gure aplikazioan lan egiten dutela. Eta Master prozesutik edo beste nonbaitetik ere ezagutu nahi dugu gaur egun ditugun langile aktibo guztiak.
Nola egiten dugu hau? Aplikaziorako, langileen nodo bat sortzen dugu eta hor azpimaila bat gehitzen dugu sortu metodoa erabiliz. Errore bat daukat diapositiban. Hemen behar duzu sequential zehaztu, orduan langile guztiak banan-banan sortuko dira. Eta aplikazioak, nodo honen seme-alabei buruzko datu guztiak eskatuz, dauden langile aktibo guztiak jasotzen ditu.
Hau Java kodean nola egin daitekeen inplementazio izugarria da. Has gaitezen amaieratik, metodo nagusiarekin. Hau da gure klasea, sortu dezagun bere metodoa. Lehenengo argumentu gisa host erabiltzen dugu, non konektatzen ari garen, hau da, argumentu gisa ezartzen dugu. Eta bigarren argumentua taldearen izena da.
Nola gertatzen da konexioa? Hau erabiltzen den APIaren adibide sinple bat da. Hemen dena nahiko erraza da. ZooKeeper klase estandarra dago. Ostalariak pasatzen dizkiogu. Eta ezarri denbora-muga, adibidez, 5 segundotan. Eta ConnectedSignal izeneko kide bat dugu. Funtsean, transmititutako bidetik talde bat sortzen dugu. Bertan ez dugu daturik idazten, zerbait idatzi zitekeen arren. Eta hemen nodo mota iraunkorra da. Funtsean, denbora guztian egongo den nodo arrunt arrunta da. Hor sortzen da saioa. Hau bezeroaren beraren ezarpena da. Gure bezeroak aldizkako mezuak bidaliko ditu saioa bizirik dagoela adieraziz. Eta saioa amaitzen dugunean, itxi deitzen dugu eta kitto, saioa erortzen da. Hau bada, zerbait erortzen bazaigu, ZooKeeper-ek horren berri izan eta saioa moz dezan.
Nola blokeatu baliabide bat? Hemen dena apur bat konplikatuagoa da. Langile multzo bat dugu, bada blokeatu nahi dugun baliabideren bat. Horretarako, aparteko nodo bat sortuko dugu, adibidez, lock1 izenekoa. Sortzeko gai izan bagara, hemen blokeoa lortu dugu. Eta sortu ezin izan bagenu, orduan langilea hemendik getData lortzen saiatzen da, eta nodoa dagoeneko sortua denez, orduan begirale bat jarriko dugu hemen eta nodo honen egoera aldatzen den momentuan, horren berri izango dugu. Eta birsortzeko denbora izaten saiatu gaitezke. Nodo hau hartu badugu, blokeo hau hartu badugu, blokeoa behar ez badugu, bertan behera utziko dugu, nodoa saioan bakarrik baitago. Horren arabera, desagertu egingo da. Eta beste bezero batek, beste saio baten esparruan, nodo honen blokeoa hartzeko aukera izango du, edo hobeto esanda, zerbait aldatu dela dioen jakinarazpena jasoko du eta garaiz egiten saia daiteke.
Lider nagusia aukera dezakezun beste adibide bat. Hau apur bat konplexuagoa da, baina nahiko sinplea ere bada. Zer gertatzen da hemen? Langile guztiak batzen dituen nodo nagusi bat dago. Liderraren inguruko datuak lortzen saiatzen ari gara. Hau arrakastaz gertatu bada, hau da, datu batzuk jaso baditugu, gure langilea lider honi jarraitzen hasten da. Dagoeneko lider bat badagoela uste du.
Liderra arrazoiren batengatik hiltzen bada, adibidez, erori egiten bada, lider berri bat sortzen saiatzen gara. Eta arrakasta lortzen badugu, orduan gure langilea lider bihurtzen da. Eta une honetan norbaitek buruzagi berri bat sortzea lortzen badu, orduan saiatzen gara ulertzen nor den eta gero jarraitzen diogu.
Hemen artalde efektua deritzona sortzen da, hau da, artalde efektua, buruzagi bat hiltzen denean, denboran lehena dena lider bihurtuko baita.
Baliabide bat harrapatzen duzunean, ikuspegi apur bat desberdina erabiltzen saia zaitezke, hau da. Adibidez, blokeoa lortu nahi dugu, baina hert efekturik gabe. Gure aplikazioak blokeo batekin lehendik dagoen nodo baten ID guztien zerrendak eskatzen dituelako izango da. Eta aurretik blokeoa sortu dugun nodoa jaso dugun multzotik txikiena bada, horrek esan nahi du blokeoa harrapatu dugula. Blokeoa jaso dugula egiaztatzen dugu. Egiaztapen gisa, blokeo berri bat sortzean jaso genuen IDa gutxienekoa izatearen baldintza izango da. Eta jaso badugu, gehiago lan egiten dugu.
Gure blokeoa baino txikiagoa den ID jakin bat badago, gertaera honetan begirale bat jarriko dugu eta jakinarazpenaren zain egongo gara zerbait aldatu arte. Hau da, sarraila hau jaso dugu. Eta erori arte, ez gara gutxieneko ID bihurtuko eta ez dugu gutxieneko blokeoa jasoko, eta horrela saioa hasi ahal izango dugu. Eta baldintza hau betetzen ez bada, berehala joango gara eta blokeo hau berriro lortzen saiatuko gara, denbora horretan zerbait aldatu izana zitekeelako.
Zertan datza ZooKeeper? 4 gauza nagusi daude. Hau prozesatzeko prozesuak da - Eskaera. Baita ZooKeeper Atomic Broadcast ere. Konpromiso-erregistro bat dago non eragiketa guztiak erregistratzen diren. Eta In-memory Replicated DB bera, hau da, zuhaitz hori guztia gordetzen den datu-basea bera.
Azpimarratzekoa da idazketa-eragiketa guztiak Eskaera-prozesadoretik pasatzen direla. Eta irakurketa eragiketak zuzenean doaz Memoria barneko datu-basera.
Datu-basea bera guztiz erreplikatzen da. ZooKeeper-en instantzia guztiek datuen kopia osoa gordetzen dute.
Matxura baten ondoren datu-basea leheneratzeko, Commit erregistroa dago. Praktika arrunta da datuak memorian sartu aurretik, bertan idazten direla, huts egiten badu, erregistro hau erreproduzitu eta sistemaren egoera berreskuratu ahal izateko. Eta datu-basearen aldizkako argazkiak ere erabiltzen dira.
ZooKeeper Atomic Broadcast erreplikatutako datuak mantentzeko erabiltzen den gauza bat da.
ZAB barrutik lider bat hautatzen du ZooKeeper nodoaren ikuspuntutik. Beste nodo batzuk bere jarraitzaile bihurtzen dira eta beregandik ekintza batzuk espero dituzte. Sarrerak jasotzen badituzte, guztiak liderra bidaltzen dituzte. Lehenik idazketa eragiketa bat egiten du eta gero mezu bat bidaltzen die bere jarraitzaileei zer aldatu den. Hau, izan ere, atomikoki egin behar da, hau da, guztiaren grabaketa eta igorpen eragiketa atomikoki egin behar da, eta horrela datuen koherentzia bermatuz.
Idazteko eskaerak soilik prozesatzen ditu. Bere zeregin nagusia da eragiketa transakzio eguneratze bihurtzea. Hau bereziki sortutako eskaera da.
Eta hemen azpimarratzekoa da eragiketa bererako eguneratzeen idempotentzia bermatuta dagoela. Zer da hau? Gauza honek, bi aldiz exekutatzen bada, egoera bera izango du, hau da, eskaera bera ez da aldatuko. Eta hori egin behar da, hutsegite bat gertatuz gero, eragiketa berrabiarazi ahal izateko, eta horrela une honetan eroritako aldaketak atzera botatzeko. Kasu honetan, sistemaren egoera berdina bihurtuko da, hau da, ez luke izan behar berdinen serie batek, adibidez, eguneratze prozesuek, sistemaren azken egoera desberdinak ekarriko dituztenik.
Iturria: www.habr.com