Mi sugestas vin legi la transskribon de la prelego "Hadoop. ZooKeeper" el la serio "Metodoj por distribuita prilaborado de grandaj volumoj de datumoj en Hadoop"
Kio estas ZooKeeper, ĝia loko en la Hadoop-ekosistemo. Malveroj pri distribuita komputado. Diagramo de norma distribuita sistemo. Malfacilo kunordigi distribuitajn sistemojn. Tipaj kunordigaj problemoj. La principoj malantaŭ la dezajno de ZooKeeper. datummodelo de ZooKeeper. znode flagoj. Sesioj. Kliento API. Primitivoj (agordo, grupa membreco, simplaj seruroj, gvidanto-elekto, ŝlosado sen grega efiko). ZooKeeper-arkitekturo. ZooKeeper DB. ZAB. Peto-traktilo.
Hodiaŭ ni parolos pri ZooKeeper. Ĉi tiu afero estas tre utila. Ĝi, kiel ĉiu produkto Apache Hadoop, havas emblemon. Ĝi prezentas viron.
Antaŭ ĉi tio, ni ĉefe parolis pri kiel datumoj povas esti procesitaj tie, kiel konservi ĝin, tio estas, kiel uzi ĝin iel kaj labori kun ĝi iel. Kaj hodiaŭ mi ŝatus paroli iomete pri konstruado de distribuitaj aplikaĵoj. Kaj ZooKeeper estas unu el tiuj aferoj, kiuj permesas vin simpligi ĉi tiun aferon. Ĉi tio estas speco de servo, kiu estas destinita por ia kunordigo de la interago de procezoj en distribuitaj sistemoj, en distribuitaj aplikoj.
La bezono de tiaj aplikaĵoj pli kaj pli fariĝas ĉiutage, pri tio temas nia kurso. Unuflanke, MapReduce kaj ĉi tiu preta kadro permesas vin ebenigi ĉi tiun kompleksecon kaj liberigi la programiston de skribado de primitivaĵoj kiel interagado kaj kunordigo de procezoj. Sed aliflanke, neniu garantias, ke ĉi tio ne devos esti farita ĉiuokaze. MapReduce aŭ aliaj pretaj kadroj ne ĉiam tute anstataŭigas iujn kazojn, kiuj ne povas esti efektivigitaj uzante ĉi tion. Inkluzive de MapReduce mem kaj amaso da aliaj Apache-projektoj; ili, fakte, ankaŭ estas distribuitaj aplikaĵoj. Kaj por faciligi la skribadon, ili skribis ZooKeeper.
Kiel ĉiuj Hadoop-rilataj aplikoj, ĝi estis evoluigita fare de Yahoo! Ĝi nun estas ankaŭ oficiala Apache-aplikaĵo. Ĝi ne estas tiel aktive evoluinta kiel HBase. Se vi iras al JIRA HBase, tiam ĉiutage estas amaso da cimraportoj, amaso da proponoj por optimumigi ion, t.e. la vivo en la projekto konstante okazas. Kaj ZooKeeper, unuflanke, estas relative simpla produkto, kaj aliflanke tio certigas ĝian fidindecon. Kaj ĝi estas sufiĉe facile uzebla, tial ĝi fariĝis normo en aplikoj ene de la ekosistemo Hadoop. Do mi pensis, ke estus utile revizii ĝin por kompreni kiel ĝi funkcias kaj kiel uzi ĝin.
Jen bildo de iu prelego, kiun ni havis. Ni povas diri, ke ĝi estas orta al ĉio, kion ni konsideris ĝis nun. Kaj ĉio, kio estas indikita ĉi tie, unugrade aŭ alia, funkcias kun ZooKeeper, t.e., ĝi estas servo, kiu uzas ĉiujn ĉi tiujn produktojn. Nek HDFS nek MapReduce verkas siajn proprajn similajn servojn, kiuj specife funkcius por ili. Sekve, ZooKeeper estas uzata. Kaj ĉi tio simpligas disvolviĝon kaj iujn aferojn rilatajn al eraroj.
De kie ĉio ĉi venas? Ŝajnus, ke ni paralele lanĉis du aplikaĵojn en malsamaj komputiloj, kunligis ilin per ŝnuro aŭ en maŝo, kaj ĉio funkcias. Sed la problemo estas, ke la Reto estas nefidinda, kaj se vi flaris la trafikon aŭ rigardis tion, kio okazas tie je malalta nivelo, kiel klientoj interagas en la Reto, vi ofte povas vidi, ke iuj pakoj estas perditaj aŭ resenditaj. Ne vane estis inventitaj TCP-protokoloj, kiuj permesas vin establi certan sesion kaj garantii la liveron de mesaĝoj. Sed ĉiukaze eĉ TCP ne ĉiam povas savi vin. Ĉio havas tempon. La reto povas simple defali por iom da tempo. Ĝi povus simple palpebrumi. Kaj ĉi tio ĉio kondukas al la fakto, ke vi ne povas fidi, ke la Reto estas fidinda. Ĉi tio estas la ĉefa diferenco de skribado de paralelaj aplikaĵoj, kiuj funkcias per unu komputilo aŭ sur unu superkomputilo, kie ne ekzistas Reto, kie estas pli fidinda datum-interŝanĝa buso en memoro. Kaj ĉi tio estas fundamenta diferenco.
Interalie, kiam oni uzas la Reton, ĉiam estas certa latenteco. Ankaŭ la disko havas ĝin, sed la Reto havas pli da ĝi. Latenteco estas iom da prokrasto, kiu povas esti aŭ malgranda aŭ sufiĉe signifa.
La retotopologio ŝanĝiĝas. Kio estas topologio - ĉi tio estas la lokigo de nia reto-ekipaĵo. Estas datumcentroj, estas rakoj, kiuj staras tie, estas kandeloj. Ĉio ĉi povas esti rekonektita, movita, ktp. Ĉio ankaŭ devas esti konsiderata. IP-nomoj ŝanĝiĝas, ŝanĝiĝas la vojigo tra kiu nia trafiko vojaĝas. Ĉi tio ankaŭ devas esti konsiderata.
La reto ankaŭ povas ŝanĝiĝi laŭ ekipaĵo. De praktiko, mi povas diri, ke niaj retaj inĝenieroj tre ŝatas periode ĝisdatigi ion pri la kandeloj. Subite aperis nova firmvaro kaj ili ne aparte interesiĝis pri iu Hadoop-areto. Ili havas sian propran laboron. Por ili, la ĉefa afero estas, ke la Reto funkcias. Sekve, ili volas re-alŝuti ion tie, fari ekbrilon sur sia aparataro, kaj la aparataro ankaŭ periode ŝanĝiĝas. Ĉio ĉi iel devas esti konsiderata. Ĉio ĉi influas nian distribuitan aplikaĵon.
Kutime homoj, kiuj komencas labori kun grandaj kvantoj de datumoj ial, kredas, ke Interreto estas senlima. Se tie estas dosiero de pluraj terabajtoj, tiam vi povas preni ĝin al via servilo aŭ komputilo kaj malfermi ĝin uzante kato kaj rigardu. Alia eraro estas en mi venis rigardu la ŝtipojn. Neniam faru ĉi tion ĉar ĝi estas malbona. Ĉar Vim provas ŝargi ĉion, ŝargi ĉion en memoron, precipe kiam ni komencas movi ĉi tiun protokolon kaj serĉi ion. Ĉi tiuj estas aferoj forgesitaj, sed konsiderindaj.
Estas pli facile verki unu programon, kiu funkcias en unu komputilo kun unu procesoro.
Kiam nia sistemo kreskas, ni volas paraleligi ĉion, kaj paraleligi ĝin ne nur en komputilo, sed ankaŭ en areto. Estiĝas la demando: kiel kunordigi ĉi tiun aferon? Niaj aplikaĵoj eble eĉ ne interagas unu kun la alia, sed ni kuris plurajn procezojn paralele sur pluraj serviloj. Kaj kiel kontroli, ke ĉio iras bone por ili? Ekzemple, ili sendas ion tra la Interreto. Ili devas skribi pri sia stato ie, ekzemple, en ia datumbazo aŭ protokolo, tiam kunigi ĉi tiun protokolon kaj poste analizi ĝin ie. Krome, ni devas konsideri, ke la procezo funkciis kaj funkciis, subite iu eraro aperis en ĝi aŭ ĝi kraŝis, tiam kiom rapide ni ekscios pri ĝi?
Estas klare, ke ĉio ĉi povas esti rapide kontrolita. Ĉi tio ankaŭ estas bona, sed monitorado estas limigita afero, kiu permesas vin kontroli iujn aferojn ĉe la plej alta nivelo.
Kiam ni volas, ke niaj procezoj komencu interagi unu kun la alia, ekzemple, sendi al unu la alian iujn datumojn, tiam ankaŭ aperas la demando - kiel tio okazos? Ĉu estos ia raskondiĉo, ĉu ili anstataŭigos unu la alian, ĉu la datumoj alvenos ĝuste, ĉu io perdiĝos survoje? Ni devas evoluigi ian protokolon ktp.
Kunordigo de ĉiuj ĉi tiuj procezoj ne estas bagatela afero. Kaj ĝi devigas la programiston malsupreniri al eĉ pli malalta nivelo, kaj skribi sistemojn aŭ de nulo, aŭ ne tute de nulo, sed ĉi tio ne estas tiel simpla.
Se vi elpensas kriptografian algoritmon aŭ eĉ efektivigas ĝin, tiam forĵetu ĝin tuj, ĉar plej verŝajne ĝi ne funkcios por vi. Ĝi plej verŝajne enhavos amason da eraroj, kiujn vi forgesis provizi. Neniam uzu ĝin por io serioza ĉar ĝi plej verŝajne estos malstabila. Ĉar ĉiuj ekzistantaj algoritmoj estis testitaj de tempo dum tre longa tempo. Ĝi estas cimigita de la komunumo. Ĉi tio estas aparta temo. Kaj ĉi tie estas same. Se eblas mem ne efektivigi ian procezan sinkronigon, tiam estas pli bone ne fari tion, ĉar ĝi estas sufiĉe komplika kaj kondukas vin laŭ la malfirma vojo de konstante serĉado de eraroj.
Hodiaŭ ni parolas pri ZooKeeper. Unuflanke, ĝi estas kadro, aliflanke, ĝi estas servo kiu faciligas la vivon al la programisto kaj simpligas la efektivigon de logiko kaj kunordigo de niaj procezoj kiel eble plej multe.
Ni memoru kiel povus aspekti norma distribuita sistemo. Jen pri kio ni parolis - HDFS, HBase. Estas Majstra procezo, kiu administras laboristojn kaj sklavajn procezojn. Li respondecas pri kunordigado kaj distribuado de taskoj, rekomencado de laboristoj, lanĉo de novaj kaj distribuado de la ŝarĝo.
Pli progresinta afero estas la Kunordiga Servo, tio estas, movi la kunordigan taskon mem en apartan procezon, krome ruli ian sekurkopion aŭ stanby Master paralele, ĉar la Majstro povas malsukcesi. Kaj se la Majstro falos, tiam nia sistemo ne funkcios. Ni funkcias sekurkopion. Iuj deklaras, ke la Majstro devas esti reproduktita al sekurkopio. Ĉi tio ankaŭ povas esti konfidita al la Kunordiga Servo. Sed en ĉi tiu diagramo, la Majstro mem respondecas pri kunordigado de la laboristoj; ĉi tie la servo kunordigas datumajn reproduktajn agadojn.
Pli altnivela opcio estas kiam la tuta kunordigo estas pritraktata de nia servo, kiel oni kutime faras. Li prenas respondecon por certigi, ke ĉio funkcias. Kaj se io ne funkcias, ni ekscias pri ĝi kaj provas ĉirkaŭiri ĉi tiun situacion. Ĉiukaze, ni restas kun Majstro, kiu iel interagas kun sklavoj kaj povas sendi datumojn, informojn, mesaĝojn ktp per iu servo.
Estas eĉ pli progresinta skemo, kiam ni ne havas Majstron, ĉiuj nodoj estas majstraj sklavoj, malsamaj en sia konduto. Sed ili ankoraŭ bezonas interagi unu kun la alia, do ankoraŭ restas iom da servo por kunordigi ĉi tiujn agojn. Verŝajne, Kasandra, kiu funkcias laŭ ĉi tiu principo, konvenas ĉi tiun skemon.
Estas malfacile diri, kiu el ĉi tiuj skemoj funkcias pli bone. Ĉiu havas siajn proprajn avantaĝojn kaj malavantaĝojn.
Kaj ne necesas timi iujn aferojn kun la Majstro, ĉar, kiel la praktiko montras, li ne estas tiel kapabla al konstante servado. La ĉefa afero ĉi tie estas elekti la ĝustan solvon por gastigi ĉi tiun servon sur aparta potenca nodo, por ke ĝi havu sufiĉe da rimedoj, por ke se eble, uzantoj ne havu aliron tie, por ke ili ne hazarde mortigas ĉi tiun procezon. Sed samtempe, en tia skemo estas multe pli facile administri laboristojn de la majstra procezo, t.e. ĉi tiu skemo estas pli simpla el la vidpunkto de efektivigo.
Kaj ĉi tiu skemo (supre) verŝajne estas pli kompleksa, sed pli fidinda.
La ĉefa problemo estas partaj malsukcesoj. Ekzemple, kiam ni sendas mesaĝon tra la Reto, okazas ia akcidento, kaj tiu, kiu sendis la mesaĝon, ne scios, ĉu lia mesaĝo estis ricevita kaj kio okazis flanke de la ricevilo, ne scios ĉu la mesaĝo estis ĝuste prilaborita. , t.e. li ne ricevos konfirmon.
Sekve, ni devas prilabori ĉi tiun situacion. Kaj la plej simpla afero estas resendi ĉi tiun mesaĝon kaj atendi ĝis ni ricevos respondon. En ĉi tiu kazo, oni ne konsideras ĉu la stato de la ricevilo ŝanĝiĝis. Ni povas sendi mesaĝon kaj aldoni la samajn datumojn dufoje.
ZooKeeper ofertas manierojn trakti tiajn rifuzojn, kio ankaŭ faciligas nian vivon.
Kiel menciite iom pli frue, ĉi tio similas al verkado de plurfadenaj programoj, sed la ĉefa diferenco estas, ke en distribuitaj aplikaĵoj, kiujn ni konstruas sur malsamaj maŝinoj, la sola maniero komuniki estas la Reto. Esence, ĉi tio estas komuna-nenio-arkitekturo. Ĉiu procezo aŭ servo, kiu funkcias per unu maŝino, havas sian propran memoron, sian propran diskon, sian propran procesoron, kiujn ĝi ne kundividas kun neniu.
Se ni skribas plurfadenan programon en unu komputilo, tiam ni povas uzi komunan memoron por interŝanĝi datumojn. Ni havas kuntekstan ŝaltilon tie, procezoj povas ŝanĝi. Ĉi tio influas rendimenton. Unuflanke, ne ekzistas tia afero en la programo sur grapolo, sed estas problemoj kun la Reto.
Sekve, la ĉefaj problemoj, kiuj aperas dum verkado de distribuitaj sistemoj, estas agordo. Ni skribas ian aplikaĵon. Se ĝi estas simpla, tiam ni malmola kodigo de ĉiaj nombroj en la kodo, sed ĉi tio estas maloportuna, ĉar se ni decidas, ke anstataŭ tempodaŭro de duona sekundo ni volas tempodaŭro de unu sekundo, tiam ni devas rekompili la aplikaĵon kaj denove elrulu ĉion. Estas unu afero kiam ĝi estas sur unu maŝino, kiam vi povas simple rekomenci ĝin, sed kiam ni havas multajn maŝinojn, ni devas konstante kopii ĉion. Ni devas provi fari la aplikaĵon agordebla.
Ĉi tie ni parolas pri statika agordo por sistemaj procezoj. Ĉi tio ne estas tute, eble de la mastruma vidpunkto, ĝi povas esti statika agordo por niaj procezoj, tio estas, ĉi tio estas agordo kiu ne povas simple esti prenita kaj ĝisdatigita.
Estas ankaŭ dinamika agordo. Ĉi tiuj estas la parametroj, kiujn ni volas ŝanĝi sur la flugo por ke ili estu prenitaj tie.
Kio estas la problemo ĉi tie? Ni ĝisdatigis la agordon, lanĉis ĝin, do kio? La problemo povas esti, ke unuflanke ni ruliĝis la agordon, sed forgesis pri la nova afero, la agordo restis tie. Due, dum ni ruliĝis, la agordo estis ĝisdatigita en iuj lokoj, sed ne en aliaj. Kaj iuj procezoj de nia aplikaĵo, kiuj funkcias en unu maŝino, estis rekomencitaj kun nova agordo, kaj ie kun malnova. Ĉi tio povas rezultigi, ke nia distribuita aplikaĵo estas malkonsekvenca de agorda perspektivo. Ĉi tiu problemo estas ofta. Por dinamika agordo, ĝi estas pli grava ĉar ĝi implicas ke ĝi povas esti ŝanĝita sur la flugo.
Alia problemo estas grupa membreco. Ni ĉiam havas ian aron da laboristoj, ni ĉiam volas scii, kiu el ili vivas, kiu el ili estas morta. Se estas Majstro, tiam li devas kompreni kiuj laboristoj povas esti redirektitaj al klientoj por ke ili rulu kalkulojn aŭ laboru kun datumoj, kaj kiuj ne povas. Problemo kiu konstante ekestas estas ke ni devas scii kiu laboras en nia areto.
Alia tipa problemo estas gvidanto-elektoj, kiam ni volas scii kiu respondecas. Unu ekzemplo estas reproduktado, kiam ni havas iun procezon, kiu ricevas skribajn operaciojn kaj poste reproduktas ilin inter aliaj procezoj. Li estos la gvidanto, ĉiuj aliaj lin obeos, sekvos lin. Necesas elekti procezon, por ke ĝi estu malambigua por ĉiuj, por ke ne rezultu, ke du gvidantoj estas elektitaj.
Ekzistas ankaŭ reciproke ekskluziva aliro. La problemo ĉi tie estas pli kompleksa. Ekzistas tia afero kiel mutex, kiam vi skribas plurfadenajn programojn kaj volas aliron al iu rimedo, ekzemple, memorĉelo, esti limigita kaj efektivigita per nur unu fadeno. Ĉi tie la rimedo povus esti io pli abstrakta. Kaj malsamaj aplikoj de malsamaj nodoj de nia Reto devus nur ricevi ekskluzivan aliron al difinita rimedo, kaj ne por ke ĉiuj povu ŝanĝi ĝin aŭ skribi ion tie. Ĉi tiuj estas la tiel nomataj seruroj.
ZooKeeper permesas vin solvi ĉiujn ĉi tiujn problemojn unugrade aŭ alian. Kaj mi montros per ekzemploj kiel ĝi permesas al vi fari ĉi tion.
Ne estas blokantaj primitivuloj. Kiam ni ekuzas ion, ĉi tiu primitivulo ne atendos, ke okazos iu ajn evento. Plej verŝajne, ĉi tiu afero funkcios nesinkrone, tiel permesante al procezoj ne pendi dum ili atendas ion. Ĉi tio estas tre utila afero.
Ĉiuj klientpetoj estas procesitaj en la ordo de la ĝenerala vico.
Kaj klientoj havas la ŝancon ricevi sciigon pri ŝanĝoj en iu stato, pri ŝanĝoj en datumoj, antaŭ ol la kliento mem vidas la ŝanĝitajn datumojn.
ZooKeeper povas funkcii en du reĝimoj. La unua estas memstara, sur unu nodo. Ĉi tio estas oportuna por testi. Ĝi ankaŭ povas funkcii en clusterreĝimo sur ajna nombro da serviloj. Se ni havas areton de 100 maŝinoj, tiam ne necesas ke ĝi funkciu sur 100 maŝinoj. Sufiĉas elekti plurajn maŝinojn, kie vi povas ruli ZooKeeper. Kaj ĝi konfesas la principon de alta havebleco. En ĉiu kuranta okazo, ZooKeeper stokas tutan kopion de la datumoj. Poste mi rakontos al vi kiel li faras tion. Ĝi ne dividas datumojn aŭ dividas ĝin. Unuflanke, estas minusaĵo, ke ni ne povas stoki multon, aliflanke, ne necesas fari ĉi tion. Ĝi ne estas por tio desegnita, ĝi ne estas datumbazo.
Datumoj povas esti konservitaj ĉe la klientflanko. Ĉi tio estas norma principo, por ke ni ne interrompu la servon kaj ne ŝarĝu ĝin per la samaj petoj. Saĝa kliento kutime scias pri tio kaj konservas ĝin.
Ekzemple, io ŝanĝiĝis ĉi tie. Estas ia aplikaĵo. Estis elektita nova gvidanto, kiu respondecas, ekzemple, pri prilaborado de skribaj operacioj. Kaj ni volas reprodukti la datumojn. Unu solvo estas meti ĝin en buklon. Kaj ni konstante pridubas nian servon - ĉu io ŝanĝiĝis? La dua opcio estas pli optimuma. Ĉi tio estas horloĝa mekanismo, kiu ebligas al vi sciigi klientojn, ke io ŝanĝiĝis. Ĉi tio estas malpli multekosta metodo laŭ rimedoj kaj pli oportuna por klientoj.
Kliento estas la uzanto kiu uzas ZooKeeper.
Servilo estas la ZooKeeper-procezo mem.
Znode estas la ŝlosila afero en ZooKeeper. Ĉiuj znodoj estas konservitaj en memoro fare de ZooKeeper kaj estas organizitaj en la formo de hierarkia diagramo, en la formo de arbo.
Estas du specoj de operacioj. La unua estas ĝisdatigi/skribi, kiam iu operacio ŝanĝas la staton de nia arbo. La arbo estas ofta.
Kaj eblas, ke la kliento ne plenumas unu peton kaj estas malkonektita, sed povas establi sesion per kiu ĝi interagas kun ZooKeeper.
La datummodelo de ZooKeeper similas al dosiersistemo. Estas norma radiko kaj tiam ni iris kvazaŭ tra la dosierujoj kiuj iras de la radiko. Kaj poste la katalogo de la unua nivelo, dua nivelo. Ĉi tio estas ĉio znodes.
Ĉiu znodo povas stoki iujn datumojn, kutime ne tre grandajn, ekzemple 10 kilobajtojn. Kaj ĉiu znodo povas havi certan nombron da infanoj.
Znodes venas en pluraj tipoj. Ili povas esti kreitaj. Kaj kiam oni kreas znodon, ni specifas la tipon, al kiu ĝi devas aparteni.
Estas du tipoj. La unua estas la efemera flago. Znode vivas ene de sesio. Ekzemple, la kliento establis sesion. Kaj tiel longe kiel ĉi tiu sesio estos viva, ĝi ekzistos. Ĉi tio estas necesa por ne produkti ion nenecesan. Ĉi tio ankaŭ taŭgas por momentoj, kiam gravas por ni stoki datumajn primitivaĵojn ene de sesio.
La dua tipo estas sinsekva flago. Ĝi pliigas la nombrilon survoje al la znodo. Ekzemple, ni havis dosierujon kun aplikaĵo 1_5. Kaj kiam ni kreis la unuan nodon, ĝi ricevis p_1, la duan - p_2. Kaj kiam ni nomas ĉi tiun metodon ĉiufoje, ni pasas la plenan vojon, indikante nur parton de la vojo, kaj ĉi tiu nombro aŭtomate pliigas ĉar ni indikas la nodo-tipo - sinsekva.
Regula znodo. Ŝi ĉiam vivos kaj havos la nomon, kiun ni diras al ŝi.
Alia utila afero estas la horloĝa flago. Se ni instalas ĝin, tiam la kliento povas aboni iujn eventojn por specifa nodo. Mi montros al vi poste per ekzemplo kiel tio estas farita. ZooKeeper mem sciigas al la kliento, ke la datumoj sur la nodo ŝanĝiĝis. Tamen sciigoj ne garantias, ke iuj novaj datumoj alvenis. Ili simple diras, ke io ŝanĝiĝis, do vi ankoraŭ devas kompari datumojn poste kun apartaj vokoj.
Kaj kiel mi jam diris, la ordo de la datumoj estas determinita per kilobajtoj. Ne necesas konservi grandajn tekstajn datumojn tie, ĉar ĝi ne estas datumbazo, ĝi estas servilo de agado-kunordigo.
Mi rakontos al vi iomete pri la kunsidoj. Se ni havas plurajn servilojn, tiam ni povas travideble moviĝi de servilo al servilo uzante la sean identigilon. Ĝi estas sufiĉe oportuna.
Ĉiu sesio havas ian tempon. Sesio estas difinita per ĉu la kliento sendas ion al la servilo dum tiu sesio. Se li nenion transdonis dum la tempodaŭro, la sesio falas, aŭ la kliento povas fermi ĝin mem.
Ĝi ne havas tiom da funkcioj, sed vi povas fari malsamajn aferojn per ĉi tiu API. Tiu voko, kiun ni vidis krei, kreas znodon kaj prenas tri parametrojn. Ĉi tiu estas la vojo al la znodo, kaj ĝi devas esti specifita plene de la radiko. Kaj ankaŭ ĉi tio estas iuj datumoj, kiujn ni volas translokigi tien. Kaj la tipo de flago. Kaj post kreado ĝi resendas la vojon al la znodo.
Due, vi povas forigi ĝin. La lertaĵo ĉi tie estas, ke la dua parametro, krom la vojo al la znodo, povas specifi la version. Sekve, tiu znodo estos forigita se ĝia versio, kiun ni transdonis, estas ekvivalenta al tiu, kiu efektive ekzistas.
Se ni ne volas kontroli ĉi tiun version, tiam ni simple pasas la argumenton "-1".
Trie, ĝi kontrolas la ekziston de znodo. Liveras vera se la nodo ekzistas, malvera alie.
Kaj tiam aperas flaghorloĝo, kiu permesas vin kontroli ĉi tiun nodon.
Vi povas agordi ĉi tiun flagon eĉ sur neekzistanta nodo kaj ricevi sciigon kiam ĝi aperas. Ĉi tio ankaŭ povas esti utila.
Kelkaj pliaj defioj estas getData. Estas klare, ke ni povas ricevi datumojn per znode. Vi ankaŭ povas uzi flaghorloĝon. En ĉi tiu kazo, ĝi ne instalos se ne ekzistas nodo. Tial vi devas kompreni, ke ĝi ekzistas, kaj poste ricevi datumojn.
Estas ankaŭ SetData. Ĉi tie ni pasas version. Kaj se ni transdonas ĉi tion, la datumoj pri la znodo de certa versio estos ĝisdatigitaj.
Vi ankaŭ povas specifi "-1" por ekskludi ĉi tiun kontrolon.
Alia utila metodo estas akiri Infanojn. Ni ankaŭ povas ricevi liston de ĉiuj znodoj kiuj apartenas al ĝi. Ni povas kontroli ĉi tion fiksante flaghorloĝon.
Kaj metodo sinkronigi permesas ĉiujn ŝanĝojn esti senditaj samtempe, tiel certigante ke ili estas konservitaj kaj ĉiuj datumoj estas tute ŝanĝitaj.
Se ni desegnas analogojn kun regula programado, tiam kiam vi uzas metodojn kiel skribi, kiuj skribas ion al disko, kaj post kiam ĝi resendas respondon al vi, ne estas garantio, ke vi skribis la datumojn al disko. Kaj eĉ kiam la operaciumo certas, ke ĉio estas skribita, ekzistas mekanismoj en la disko mem, kie la procezo trairas tavolojn de bufroj, kaj nur post tio la datumoj estas metitaj sur la diskon.
Plejparte nesinkronaj vokoj estas uzataj. Ĉi tio permesas al la kliento labori paralele kun malsamaj petoj. Vi povas uzi la sinkronan aliron, sed ĝi estas malpli produktiva.
La du operacioj, pri kiuj ni parolis, estas ĝisdatigi/skribi, kiuj ŝanĝas datumojn. Ĉi tiuj estas krei, setData, sinkronigi, forigi. Kaj legi ekzistas, getData, getChildren.
Nun kelkaj ekzemploj pri kiel vi povas fari primitivaĵojn por labori en distribuita sistemo. Ekzemple, rilata al la agordo de io. Nova laboristo aperis. Ni aldonis la maŝinon kaj komencis la procezon. Kaj estas la sekvaj tri demandoj. Kiel ĝi demandas ZooKeeper por agordo? Kaj se ni volas ŝanĝi la agordon, kiel ni ŝanĝu ĝin? Kaj post kiam ni ŝanĝis ĝin, kiel tiuj laboristoj, kiujn ni havis, ricevas ĝin?
ZooKeeper faras tion relative facila. Ekzemple, estas nia znode-arbo. Estas nodo por nia aplikaĵo ĉi tie, ni kreas aldonan nodon en ĝi, kiu enhavas datumojn de la agordo. Ĉi tiuj povas aŭ ne esti apartaj parametroj. Ĉar la grandeco estas malgranda, la agorda grandeco estas kutime malgranda ankaŭ, do estas tute eble konservi ĝin ĉi tie.
Vi uzas la metodon getData por ricevi la agordon por la laboristo de la nodo. Agordu al vera. Se ial ĉi tiu nodo ne ekzistas, ni estos informitaj pri ĝi kiam ĝi aperos, aŭ kiam ĝi ŝanĝiĝos. Se ni volas scii, ke io ŝanĝiĝis, tiam ni agordas ĝin al vera. Kaj se la datumoj en ĉi tiu nodo ŝanĝiĝas, ni scios pri ĝi.
SetData. Ni fiksas la datumojn, starigas "-1", t.e. ni ne kontrolas la version, ni supozas, ke ni ĉiam havas unu agordon, ni ne bezonas stoki multajn agordojn. Se vi bezonas stoki multon, vi devos aldoni alian nivelon. Ĉi tie ni kredas, ke ekzistas nur unu, do ni ĝisdatigas nur la plej novan, do ni ne kontrolas la version. En ĉi tiu momento, ĉiuj klientoj, kiuj antaŭe abonis, ricevas sciigon, ke io ŝanĝiĝis en ĉi tiu nodo. Kaj post kiam ili ricevis ĝin, ili ankaŭ devas peti la datumojn denove. La sciigo estas, ke ili ne ricevas la datumojn mem, sed nur sciigon pri ŝanĝoj. Post tio ili devas peti novajn datumojn.
La dua opcio por uzi la primitivon estas grupa membreco. Ni havas distribuitan aplikaĵon, estas amaso da laboristoj kaj ni volas kompreni, ke ili ĉiuj estas en loko. Tial ili devas registri sin, ke ili funkcias en nia aplikaĵo. Kaj ni ankaŭ volas ekscii, ĉu el la majstra procezo aŭ aliloke, pri ĉiuj aktivaj laboristoj, kiujn ni nuntempe havas.
Kiel ni faras ĉi tion? Por la aplikaĵo, ni kreas labornodon kaj aldonas subnivelon tie uzante la krei metodon. Mi havas eraron sur la glito. Ĉi tie vi bezonas sinsekva specifi, tiam ĉiuj laboristoj estos kreitaj unu post la alia. Kaj la aplikaĵo, petante ĉiujn datumojn pri la filoj de ĉi tiu nodo, ricevas ĉiujn aktivajn laboristojn, kiuj ekzistas.
Ĉi tio estas tiel terura efektivigo de kiel tio povas esti farita en Java-kodo. Ni komencu de la fino, per la ĉefa metodo. Ĉi tiu estas nia klaso, ni kreu ĝian metodon. Kiel la unuan argumenton ni uzas gastiganton, kie ni konektas, t.e. ni starigas ĝin kiel argumenton. Kaj la dua argumento estas la nomo de la grupo.
Kiel okazas la konekto? Ĉi tio estas simpla ekzemplo de la API uzata. Ĉio estas relative simpla ĉi tie. Estas norma klaso ZooKeeper. Ni pasas gastigantojn al ĝi. Kaj agordu la tempon, ekzemple, al 5 sekundoj. Kaj ni havas membron nomatan connectSignal. Esence, ni kreas grupon laŭ la elsendita vojo. Ni ne skribas datumojn tie, kvankam io povus esti skribita. Kaj la nodo ĉi tie estas de la persista tipo. Esence, ĉi tio estas ordinara regula nodo, kiu ekzistos la tutan tempon. Jen kie la sesio estas kreita. Ĉi tio estas la efektivigo de la kliento mem. Nia kliento sendos periodajn mesaĝojn indikante, ke la sesio vivas. Kaj kiam ni finas la sesion, ni vokas fermi kaj jen, la sesio falas. Ĉi tio okazas, se io falos por ni, tiel ke ZooKeeper eksciu pri tio kaj ĉesigas la sesion.
Kiel ŝlosi rimedon? Ĉi tie ĉio estas iom pli komplika. Ni havas aron da laboristoj, estas iu rimedo, kiun ni volas ŝlosi. Por fari tion, ni kreas apartan nodon, ekzemple, nomatan lock1. Se ni povis krei ĝin, tiam ni ricevis ŝlosilon ĉi tie. Kaj se ni ne povis krei ĝin, tiam la laboristo provas akiri getData de ĉi tie, kaj ĉar la nodo jam estis kreita, tiam ni metas observanton ĉi tie kaj kiam la stato de ĉi tiu nodo ŝanĝiĝos, ni scios pri ĝi. Kaj ni povas provi havi tempon por rekrei ĝin. Se ni prenis ĉi tiun nodon, prenis ĉi tiun seruron, tiam post kiam ni ne plu bezonos la seruron, ni forlasos ĝin, ĉar la nodo ekzistas nur ene de la sesio. Sekve, ĝi malaperos. Kaj alia kliento, kadre de alia sesio, povos preni la seruron sur ĉi tiu nodo, aŭ pli ĝuste, li ricevos sciigon, ke io ŝanĝiĝis kaj li povas provi fari ĝin ĝustatempe.
Alia ekzemplo de kiel vi povas elekti la ĉefan gvidanton. Ĉi tio estas iom pli komplika, sed ankaŭ relative simpla. Kio okazas ĉi tie? Estas ĉefa nodo, kiu kunigas ĉiujn laboristojn. Ni provas akiri datumojn pri la gvidanto. Se ĉi tio okazis sukcese, t.e. ni ricevis iujn datumojn, tiam nia laboristo komencas sekvi ĉi tiun gvidanton. Li kredas, ke jam estas gvidanto.
Se la gvidanto mortis ial, ekzemple, defalis, tiam ni provas krei novan gvidanton. Kaj se ni sukcesas, tiam nia laboristo fariĝas la gvidanto. Kaj se iu en ĉi tiu momento sukcesis krei novan gvidanton, tiam ni provas kompreni kiu ĝi estas kaj poste sekvi lin.
Ĉi tie ekestas la tiel nomata grega efiko, t.e. la grega efiko, ĉar kiam gvidanto mortos, tiu, kiu estas la unua en la tempo, fariĝos la gvidanto.
Kiam vi kaptas rimedon, vi povas provi uzi iomete malsaman aliron, kio estas kiel sekvas. Ekzemple, ni volas ricevi seruron, sed sen la herta efiko. Ĝi konsistos en tio, ke nia aplikaĵo petas listojn de ĉiuj nodaj identigiloj por jam ekzistanta nodo kun seruro. Kaj se antaŭ tio la nodo por kiu ni kreis seruron estas la plej malgranda el la aro, kiun ni ricevis, tiam tio signifas, ke ni kaptis la seruron. Ni kontrolas, ke ni ricevis seruron. Kiel kontrolo, estos kondiĉo, ke la id, kiun ni ricevis dum kreado de nova seruro, estas minimuma. Kaj se ni ricevis ĝin, tiam ni laboras plu.
Se ekzistas certa identigilo, kiu estas pli malgranda ol nia seruro, tiam ni metas observanton pri ĉi tiu evento kaj atendas sciigon ĝis io ŝanĝiĝos. Tio estas, ni ricevis ĉi tiun seruron. Kaj ĝis ĝi defalos, ni ne fariĝos la minimuma identigilo kaj ne ricevos la minimuman seruron, kaj tiel ni povos ensaluti. Kaj se ĉi tiu kondiĉo ne estas plenumita, tiam ni tuj iras ĉi tien kaj provas akiri ĉi tiun seruron denove, ĉar io eble ŝanĝiĝis dum ĉi tiu tempo.
El kio konsistas ZooKeeper? Estas 4 ĉefaj aferoj. Ĉi tio estas prilaborado de procezoj - Peto. Kaj ankaŭ ZooKeeper Atomic Broadcast. Estas Commit Log, kie ĉiuj operacioj estas registritaj. Kaj la En-memora Replikita DB mem, t.e. la datumbazo mem kie ĉi tiu tuta arbo estas konservita.
Indas noti, ke ĉiuj skribaj operacioj pasas tra la Petoprocesoro. Kaj legaj operacioj iras rekte al la En-memora datumbazo.
La datumbazo mem estas plene reproduktita. Ĉiuj okazoj de ZooKeeper stokas kompletan kopion de la datumoj.
Por restarigi la datumbazon post kraŝo, ekzistas Commit-protokolo. Norma praktiko estas ke antaŭ ol datumoj eniras memoron, ĝi estas skribita tie tiel ke se ĝi kraŝas, ĉi tiu protokolo povas esti reludita kaj la sistema stato povas esti restarigita. Kaj periodaj momentfotoj de la datumbazo ankaŭ estas uzataj.
ZooKeeper Atomic Broadcast estas afero, kiu estas uzata por konservi reproduktitajn datumojn.
ZAB interne elektas gvidanton el la vidpunkto de la nodo ZooKeeper. Aliaj nodoj fariĝas ŝiaj sekvantoj kaj atendas kelkajn agojn de ŝi. Se ili ricevas enskribojn, ili plusendas ilin ĉiujn al la gvidanto. Li unue faras skriban operacion kaj poste sendas mesaĝon pri tio, kio ŝanĝiĝis al siaj sekvantoj. Ĉi tio, fakte, devas esti farita atome, t.e. la registrado kaj dissenda operacio de la tuta afero devas esti farita atome, tiel garantiante datuman konsistencon.
Ĝi nur prilaboras skribpetojn. Ĝia ĉefa tasko estas, ke ĝi transformas la operacion en transakcian ĝisdatigon. Ĉi tio estas speciale kreita peto.
Kaj ĉi tie indas noti, ke la identeco de ĝisdatigoj por la sama operacio estas garantiita. Kio ĝi estas? Ĉi tiu afero, se efektivigita dufoje, havos la saman staton, t.e. la peto mem ne ŝanĝiĝos. Kaj ĉi tio devas esti farita por ke, en kazo de kraŝo, vi povu rekomenci la operacion, tiel retroigante la ŝanĝojn, kiuj defalis nuntempe. En ĉi tiu kazo, la stato de la sistemo fariĝos sama, t.e. ne devus esti la kazo, ke serio de la samaj, ekzemple, ĝisdatigaj procezoj, kondukis al malsamaj finaj statoj de la sistemo.
fonto: www.habr.com