Ég mæli með að þú lesir afrit af fyrirlestrinum "Hadoop. ZooKeeper" úr röðinni "Aðferðir við dreifða vinnslu á miklu magni gagna í Hadoop"
Hvað er ZooKeeper, staður hans í Hadoop vistkerfinu. Ósannindi um dreifða tölvuvinnslu. Skýringarmynd af venjulegu dreifðu kerfi. Erfiðleikar við að samræma dreifð kerfi. Dæmigert samhæfingarvandamál. Meginreglurnar á bak við hönnun ZooKeeper. ZooKeeper gagnalíkan. znode fánar. Fundir. Viðskiptavinur API. Frumstæður (stillingar, hópaðild, einfaldir læsingar, leiðtogakjör, læsing án hjarðáhrifa). ZooKeeper arkitektúr. ZooKeeper DB. ZAB. Beiðni um stjórnanda.
Í dag munum við tala um ZooKeeper. Þessi hlutur er mjög gagnlegur. Það, eins og allar Apache Hadoop vörur, er með lógó. Það sýnir mann.
Áður en þetta var ræddum við aðallega um hvernig hægt er að vinna úr gögnum þar, hvernig á að geyma þau, það er að segja hvernig á að nota þau einhvern veginn og vinna með þau einhvern veginn. Og í dag langar mig að tala aðeins um byggingu dreifðra forrita. Og ZooKeeper er eitt af því sem gerir þér kleift að einfalda þetta mál. Þetta er eins konar þjónusta sem er ætluð til einhvers konar samhæfingar á samspili ferla í dreifðum kerfum, í dreifðum forritum.
Þörfin fyrir slíkar umsóknir verður meiri og meiri með hverjum deginum, það er það sem námskeiðið okkar snýst um. Annars vegar, MapReduce og þessi tilbúna rammi gerir þér kleift að jafna út þetta flókið og losa forritarann við að skrifa frumstæður eins og samspil og samhæfingu ferla. En á hinn bóginn ábyrgist enginn að þetta þurfi ekki að gera hvort sem er. MapReduce eða önnur tilbúin ramma koma ekki alltaf alveg í stað sumra tilvika sem ekki er hægt að útfæra með þessu. Þar á meðal MapReduce sjálft og fullt af öðrum Apache verkefnum; þau eru reyndar líka dreifð forrit. Og til að auðvelda ritun skrifuðu þeir ZooKeeper.
Eins og öll Hadoop-tengd forrit var það þróað af Yahoo! Það er nú einnig opinbert Apache forrit. Það er ekki eins virkt þróað og HBase. Ef þú ferð á JIRA HBase, þá eru á hverjum degi fullt af villutilkynningum, fullt af tillögum til að hagræða einhverju, þ.e.a.s. lífið í verkefninu er stöðugt í gangi. Og ZooKeeper er annars vegar tiltölulega einföld vara og hins vegar tryggir þetta áreiðanleika hennar. Og það er frekar auðvelt í notkun, þess vegna er það orðið staðall í forritum innan Hadoop vistkerfisins. Svo ég hélt að það væri gagnlegt að rifja það upp til að skilja hvernig það virkar og hvernig á að nota það.
Þetta er mynd frá einhverjum fyrirlestri sem við vorum með. Við getum sagt að það sé hornrétt á allt sem við höfum talið hingað til. Og allt sem tilgreint er hér, að einhverju leyti, virkar með ZooKeeper, þ.e.a.s. það er þjónusta sem notar allar þessar vörur. Hvorki HDFS né MapReduce skrifa sína eigin svipaða þjónustu sem myndi virka sérstaklega fyrir þau. Í samræmi við það er ZooKeeper notað. Og þetta einfaldar þróun og sumt sem tengist villum.
Hvaðan kemur allt þetta? Það virðist sem við höfum sett tvö forrit samhliða á mismunandi tölvur, tengd þeim með streng eða í möskva og allt virkar. En vandamálið er að netið er óáreiðanlegt og ef þú þefaðir af umferðinni eða skoðaðir hvað er að gerast þar á lágu stigi, hvernig viðskiptavinir hafa samskipti á netinu, geturðu oft séð að sumir pakkar glatast eða endursendur. Það er ekki fyrir neitt sem TCP samskiptareglur voru fundnar upp, sem gera þér kleift að koma á ákveðnu fundi og tryggja afhendingu skilaboða. En í öllum tilvikum, jafnvel TCP getur ekki alltaf bjargað þér. Allt hefur tímamörk. Netið gæti einfaldlega dottið af um stund. Það gæti bara blikka. Og þetta leiðir allt til þess að þú getur ekki treyst á að netið sé áreiðanlegt. Þetta er aðalmunurinn á því að skrifa samhliða forrit sem keyra á einni tölvu eða á einni ofurtölvu, þar sem ekkert net er til staðar, þar sem er áreiðanlegri gagnaskiptarúta í minni. Og þetta er grundvallarmunur.
Meðal annars þegar Netið er notað er alltaf ákveðin leynd. Diskurinn hefur það líka, en Netið hefur meira af því. Töf er nokkur seinkun, sem getur verið annaðhvort lítill eða frekar verulegur.
Staðfræði netkerfisins er að breytast. Hvað er staðfræði - þetta er staðsetning netbúnaðarins okkar. Það eru gagnaver, það eru rekki sem standa þarna, það eru kerti. Allt þetta er hægt að tengja aftur, færa, osfrv. Þetta þarf líka að taka með í reikninginn. IP nöfn breytast, leiðin sem umferð okkar ferðast um breytist. Þetta þarf líka að taka með í reikninginn.
Netið getur einnig breyst hvað varðar búnað. Frá æfingu get ég sagt að netverkfræðingum okkar finnst mjög gaman að uppfæra eitthvað á kertunum reglulega. Allt í einu kom nýr fastbúnaður og þeir höfðu engan sérstakan áhuga á einhverjum Hadoop þyrpingum. Þeir hafa sína eigin vinnu. Fyrir þá er aðalatriðið að netið virki. Í samræmi við það vilja þeir endurhlaða einhverju þangað, gera blikka á vélbúnaðinum sínum og vélbúnaðurinn breytist líka reglulega. Allt þetta þarf einhvern veginn að taka með í reikninginn. Allt þetta hefur áhrif á dreifða forritið okkar.
Venjulega telur fólk sem byrjar að vinna með mikið magn gagna af einhverjum ástæðum að internetið sé takmarkalaust. Ef það er nokkur terabæta skrá þar, þá geturðu farið með hana á netþjóninn þinn eða tölvuna og opnað hana með því að nota köttur og fylgjast með. Önnur villa er í Vim kíktu á logana. Aldrei gera þetta því það er slæmt. Vegna þess að Vim reynir að biðja allt, hlaðið öllu inn í minnið, sérstaklega þegar við byrjum að fara í gegnum þennan log og leita að einhverju. Þetta eru hlutir sem gleymast, en þess virði að íhuga.
Það er auðveldara að skrifa eitt forrit sem keyrir á einni tölvu með einum örgjörva.
Þegar kerfið okkar stækkar viljum við samhliða því öllu og samhliða því ekki aðeins í tölvu, heldur líka á klasa. Spurningin vaknar: hvernig á að samræma þetta mál? Forritin okkar hafa kannski ekki einu sinni samskipti sín á milli, en við keyrðum nokkur ferli samhliða á nokkrum netþjónum. Og hvernig á að fylgjast með því að allt gangi vel hjá þeim? Til dæmis senda þeir eitthvað í gegnum netið. Þeir verða að skrifa um ástand sitt einhvers staðar, td í einhvers konar gagnagrunni eða log, safna síðan saman þennan log og síðan greina hann einhvers staðar. Auk þess þurfum við að taka með í reikninginn að ferlið virkaði og virkaði, skyndilega birtist einhver villa í því eða það hrundi, hversu fljótt munum við komast að því?
Það er ljóst að hægt er að fylgjast fljótt með þessu öllu. Þetta er líka gott, en eftirlit er takmarkaður hlutur sem gerir þér kleift að fylgjast með sumum hlutum á hæsta stigi.
Þegar við viljum að ferli okkar fari að hafa samskipti sín á milli, til dæmis til að senda hvert öðru einhver gögn, þá vaknar líka spurningin - hvernig mun þetta gerast? Verður einhvers konar keppnisástand, munu þeir skrifa yfir hvort annað, munu gögnin berast rétt, mun eitthvað tapast á leiðinni? Við þurfum að þróa einhvers konar siðareglur o.s.frv.
Samhæfing allra þessara ferla er ekki léttvægur hlutur. Og það neyðir verktaki til að fara niður á enn lægra stig og skrifa kerfi annað hvort frá grunni, eða ekki alveg frá grunni, en þetta er ekki svo einfalt.
Ef þú kemur með dulmálsreiknirit eða jafnvel útfærir það skaltu henda því strax, því líklegast mun það ekki virka fyrir þig. Það mun líklega innihalda fullt af villum sem þú gleymdir að gera ráð fyrir. Notaðu það aldrei fyrir neitt alvarlegt vegna þess að það mun líklegast vera óstöðugt. Vegna þess að öll reiknirit sem eru til hafa verið prófuð með tíma í mjög langan tíma. Það er ruglað af samfélaginu. Þetta er sérstakt umræðuefni. Og það er eins hér. Ef það er mögulegt að innleiða ekki einhvers konar ferlisamstillingu sjálfur, þá er betra að gera þetta ekki, því það er frekar flókið og leiðir þig niður á skjálfta brautina í stöðugri leit að villum.
Í dag erum við að tala um ZooKeeper. Annars vegar er það umgjörð, hins vegar er þetta þjónusta sem auðveldar framkvæmdaraðila lífið og einfaldar innleiðingu rökfræði og samhæfingu ferla okkar eins og hægt er.
Við skulum muna hvernig staðlað dreifð kerfi gæti litið út. Þetta er það sem við töluðum um - HDFS, HBase. Það er til meistaraferli sem stjórnar verkamönnum og þrælaferlum. Hann er ábyrgur fyrir því að samræma og dreifa verkefnum, endurræsa starfsmenn, setja nýja í notkun og dreifa álaginu.
Fullkomnari hlutur er samhæfingarþjónustan, það er að færa sjálft samræmingarverkefnið í sérstakt ferli, auk þess að keyra einhvers konar öryggisafrit eða biðstjóra samhliða því að meistarinn gæti mistekist. Og ef meistarinn fellur, þá mun kerfið okkar ekki virka. Við erum að keyra öryggisafrit. Sumt segir að það þurfi að endurtaka meistarann til öryggisafrits. Þetta er einnig hægt að fela Samhæfingarþjónustunni. En á þessari skýringarmynd er meistarinn sjálfur ábyrgur fyrir því að samræma starfsmennina; hér er þjónustan að samræma gagnaafritunaraðgerðir.
Fullkomnari valkostur er þegar öll samhæfing er í höndum þjónustu okkar, eins og venjulega er gert. Hann ber ábyrgð á því að allt virki. Og ef eitthvað virkar ekki, komumst við að því og reynum að komast í kringum þessar aðstæður. Hvað sem því líður þá sitjum við eftir með meistara sem á einhvern hátt samskipti við þræla og getur sent gögn, upplýsingar, skilaboð o.s.frv. í gegnum einhverja þjónustu.
Það er enn háþróaðra kerfi, þegar við höfum ekki meistara, eru allir hnútar herraþrælar, mismunandi í hegðun sinni. En þeir þurfa samt að hafa samskipti sín á milli, svo það er enn einhver þjónusta eftir til að samræma þessar aðgerðir. Sennilega passar Cassandra, sem vinnur eftir þessari reglu, við þetta kerfi.
Það er erfitt að segja til um hver þessara kerfa virkar betur. Hver hefur sína kosti og galla.
Og það er óþarfi að vera hræddur við suma hluti með meistaranum, því eins og æfingin sýnir er hann ekki svo næmur fyrir stöðugri þjónustu. Aðalatriðið hér er að velja réttu lausnina til að hýsa þessa þjónustu á sérstökum öflugum hnút, þannig að hún hafi nægt fjármagn, þannig að ef mögulegt er, hafi notendur ekki aðgang þar, svo að þeir drepi ekki óvart þetta ferli. En á sama tíma, í slíku kerfi er miklu auðveldara að stjórna starfsmönnum frá Master ferli, þ.e. þetta kerfi er einfaldara frá sjónarhóli framkvæmdar.
Og þetta kerfi (hér að ofan) er líklega flóknara, en áreiðanlegra.
Helsta vandamálið er bilun að hluta. Til dæmis, þegar við sendum skilaboð í gegnum netið, verða einhvers konar slys og sá sem sendi skilaboðin mun ekki vita hvort skilaboðin hans hafi verið móttekin og hvað gerðist á hlið viðtakandans, veit ekki hvort skilaboðin hafi verið rétt unnin , þ.e.a.s. hann mun ekki fá neina staðfestingu.
Í samræmi við það verðum við að vinna úr þessari stöðu. Og einfaldast er að senda þessi skilaboð aftur og bíða þar til við fáum svar. Í þessu tilviki er ekki tekið tillit til þess hvort ástand viðtækisins hafi breyst. Við gætum sent skilaboð og bætt við sömu gögnunum tvisvar.
ZooKeeper býður upp á leiðir til að takast á við slíkar neitanir, sem einnig gerir líf okkar auðveldara.
Eins og áður hefur komið fram er þetta svipað og að skrifa fjölþráða forrit, en helsti munurinn er sá að í dreifðum forritum sem við byggjum á mismunandi vélum er eina leiðin til samskipta netið. Í meginatriðum er þetta sameiginlegt-ekkert arkitektúr. Hvert ferli eða þjónusta sem keyrir á einni vél hefur sitt eigið minni, sinn disk, sinn eigin örgjörva, sem það deilir ekki með neinum.
Ef við skrifum fjölþráða forrit á eina tölvu, þá getum við notað sameiginlegt minni til að skiptast á gögnum. Við erum með samhengisrofa þar, ferli geta skipt um. Þetta hefur áhrif á frammistöðu. Annars vegar er ekkert slíkt í forritinu á klasa, en það eru vandamál með Netið.
Í samræmi við það eru helstu vandamálin sem koma upp við að skrifa dreifð kerfi stillingar. Við erum að skrifa einhvers konar umsókn. Ef það er einfalt, þá harðkóðuðum við alls kyns tölur í kóðanum, en þetta er óþægilegt, því ef við ákveðum að í stað hálfrar sekúndu viljum við tímamörk upp á eina sekúndu, þá þurfum við að setja saman forritið aftur og rúlla öllu út aftur. Það er eitt þegar það er á einni vél, þegar þú getur bara endurræst hana, en þegar við erum með margar vélar verðum við stöðugt að afrita allt. Við verðum að reyna að gera forritið stillanlegt.
Hér erum við að tala um truflanir stillingar fyrir kerfisferla. Þetta er ekki alveg, kannski frá stýrikerfissjónarmiði, það gæti verið kyrrstæð stilling fyrir ferla okkar, það er að segja þetta er stilling sem ekki er einfaldlega hægt að taka og uppfæra.
Það er líka kraftmikil uppsetning. Þetta eru breytur sem við viljum breyta á flugu þannig að þær séu teknar upp þar.
Hvað er vandamálið hér? Við uppfærðum stillinguna, settum hana út, hvað svo? Vandamálið getur verið að annars vegar rúlluðum við configinu út, en gleymdum því nýja, configið var þar áfram. Í öðru lagi, meðan við vorum að rúlla út, var uppsetningin uppfærð á sumum stöðum, en ekki á öðrum. Og sum ferli forritsins okkar sem keyra á einni vél voru endurræst með nýrri stillingu og einhvers staðar með gamalli. Þetta getur leitt til þess að dreifða forritið okkar sé ósamræmi frá sjónarhóli stillingar. Þetta vandamál er algengt. Fyrir kraftmikla uppsetningu er það meira viðeigandi vegna þess að það gefur til kynna að hægt sé að breyta henni á flugu.
Annað vandamál er hópaðild. Við erum alltaf með einhverja starfsmenn, við viljum alltaf vita hver þeirra er á lífi, hver þeirra er dáinn. Ef það er meistari, þá verður hann að skilja hvaða starfsmenn er hægt að vísa til viðskiptavina svo þeir keyri útreikninga eða vinni með gögn, og hverjir ekki. Vandamál sem stöðugt kemur upp er að við þurfum að vita hverjir eru að vinna í klasanum okkar.
Annað dæmigert vandamál eru leiðtogakjör, þegar við viljum vita hver er við stjórnvölinn. Eitt dæmi er afritun, þegar við höfum eitthvert ferli sem tekur á móti skrifaðgerðum og endurtekur þær síðan meðal annarra ferla. Hann verður leiðtogi, allir aðrir munu hlýða honum, fylgja honum. Nauðsynlegt er að velja ferli þannig að það sé ótvírætt fyrir alla, svo ekki komi í ljós að tveir leiðtogar séu valdir.
Það er einnig gagnkvæmur aðgangur. Vandamálið hér er flóknara. Það er til eitthvað sem heitir mutex, þegar þú skrifar fjölþráða forrit og vilt að aðgangur að einhverri auðlind, til dæmis minnishólfi, sé takmarkaður og framkvæmdur af aðeins einum þræði. Hér gæti auðlindin verið eitthvað meira abstrakt. Og mismunandi forrit frá mismunandi hnútum netsins okkar ættu aðeins að fá einkaaðgang að tiltekinni auðlind, en ekki þannig að allir geti breytt því eða skrifað eitthvað þar. Þetta eru svokallaðir læsingar.
ZooKeeper gerir þér kleift að leysa öll þessi vandamál að einu eða öðru marki. Og ég mun sýna með dæmum hvernig það gerir þér kleift að gera þetta.
Það eru engir hindrandi frumstæður. Þegar við byrjum að nota eitthvað mun þetta frumstæða ekki bíða eftir að einhver atburður eigi sér stað. Líklegast mun þessi hlutur virka ósamstilltur og leyfa þannig ferlum að hanga ekki á meðan þeir bíða eftir einhverju. Þetta er mjög gagnlegur hlutur.
Allar beiðnir viðskiptavina eru unnar í röð almennrar biðraðar.
Og viðskiptavinir hafa tækifæri til að fá tilkynningu um breytingar í einhverju ástandi, um breytingar á gögnum, áður en viðskiptavinurinn sér breytt gögn sjálfur.
ZooKeeper getur unnið í tveimur stillingum. Sá fyrsti er sjálfstæður, á einum hnút. Þetta er þægilegt til að prófa. Það getur líka starfað í klasaham á hvaða fjölda netþjóna sem er. Ef við erum með 100 vélaþyrping, þá er ekki nauðsynlegt að það virki á 100 vélum. Það er nóg að velja nokkrar vélar þar sem þú getur keyrt ZooKeeper. Og það lýsir meginreglunni um mikið framboð. Í hverju tilviki sem er í gangi geymir ZooKeeper heilt eintak af gögnunum. Seinna skal ég segja þér hvernig hann gerir það. Það sundrar ekki gögnum eða skiptar þeim. Annars vegar er það mínus að við getum ekki geymt mikið, hins vegar er óþarfi að gera þetta. Það er ekki það sem það er hannað fyrir, það er ekki gagnagrunnur.
Hægt er að vista gögn í skyndiminni á biðlarahlið. Þetta er staðlað regla þannig að við trufum ekki þjónustuna og hleðjum hana ekki með sömu beiðnum. Snjall viðskiptavinur veit venjulega um þetta og geymir það í skyndiminni.
Hér hefur til dæmis eitthvað breyst. Það er einhvers konar umsókn. Nýr oddviti var kjörinn sem ber td ábyrgð á afgreiðslu ritgerða. Og við viljum endurtaka gögnin. Ein lausn er að setja það í lykkju. Og við efumst stöðugt um þjónustu okkar - hefur eitthvað breyst? Annar valkosturinn er ákjósanlegri. Þetta er úrunarkerfi sem gerir þér kleift að tilkynna viðskiptavinum að eitthvað hafi breyst. Þetta er ódýrari aðferð hvað varðar fjármagn og þægilegri fyrir viðskiptavini.
Viðskiptavinur er notandinn sem notar ZooKeeper.
Server er ZooKeeper ferlið sjálft.
Znode er lykilatriðið í ZooKeeper. Allir znodes eru geymdir í minni af ZooKeeper og eru skipulagðir í formi stigveldisskýringar, í formi trés.
Það eru tvenns konar aðgerðir. Sú fyrsta er uppfærsla/skrif, þegar einhver aðgerð breytir stöðu trésins okkar. Tréð er algengt.
Og það er mögulegt að viðskiptavinurinn lýkur ekki einni beiðni og sé aftengdur, en getur komið á fundi þar sem hann hefur samskipti við ZooKeeper.
Gagnalíkan ZooKeeper líkist skráarkerfi. Það er staðlað rót og síðan fórum við eins og í gegnum möppurnar sem fara frá rótinni. Og svo verslun fyrsta stigs, annars stigs. Þetta eru allt znodes.
Hver znode getur geymt nokkur gögn, venjulega ekki mjög stór, til dæmis 10 kílóbæti. Og hver znode getur haft ákveðinn fjölda barna.
Znodes koma í nokkrum gerðum. Þau geta verið búin til. Og þegar þú býrð til znode, tilgreinum við tegundina sem hann ætti að tilheyra.
Það eru tvær tegundir. Hið fyrra er skammlífi fáninn. Znode lifir innan setu. Til dæmis hefur viðskiptavinurinn stofnað fund. Og svo lengi sem þessi fundur er á lífi, mun hann vera til. Þetta er nauðsynlegt til að framleiða ekki eitthvað óþarft. Þetta er líka hentugur fyrir augnablik þegar það er mikilvægt fyrir okkur að geyma frumefni gagna innan lotu.
Önnur tegundin er raðfáni. Það hækkar teljarann á leiðinni að znode. Til dæmis vorum við með möppu með forritinu 1_5. Og þegar við bjuggum til fyrsta hnútinn fékk hann p_1, sá seinni - p_2. Og þegar við köllum þessa aðferð í hvert sinn, förum við yfir alla leiðina, sem gefur til kynna aðeins hluta af leiðinni, og þessi tala er sjálfkrafa hækkuð vegna þess að við tilgreinum hnúttegundina - raðnúmer.
Venjulegur znode. Hún mun alltaf lifa og bera nafnið sem við segjum henni.
Annað gagnlegt er úrafáninn. Ef við setjum það upp, þá getur viðskiptavinurinn gerst áskrifandi að sumum viðburðum fyrir ákveðinn hnút. Ég mun sýna þér síðar með dæmi hvernig þetta er gert. ZooKeeper sjálft lætur viðskiptavininn vita að gögnin á hnútnum hafi breyst. Hins vegar tryggja tilkynningar ekki að einhver ný gögn hafi borist. Þeir segja einfaldlega að eitthvað hafi breyst, svo þú verður samt að bera saman gögn síðar með aðskildum símtölum.
Og eins og ég sagði þegar, þá er röð gagnanna ákvörðuð af kílóbætum. Það er engin þörf á að geyma stór textagögn þar, því það er ekki gagnagrunnur, það er aðgerðasamhæfingarþjónn.
Ég skal segja þér aðeins frá fundunum. Ef við erum með marga netþjóna, þá getum við flutt á gagnsæjan hátt frá netþjóni til netþjóns með því að nota lotuauðkenni. Það er frekar þægilegt.
Hver lota hefur einhvers konar timeout. Setur er skilgreindur af því hvort viðskiptavinurinn sendir eitthvað til netþjónsins meðan á þeirri lotu stendur. Ef hann sendi ekkert á tímabilinu fellur lotan niður eða viðskiptavinurinn getur lokað henni sjálfur.
Það hefur ekki svo marga eiginleika, en þú getur gert mismunandi hluti með þessu API. Þetta kall sem við sáum búa til býr til znode og tekur þrjár breytur. Þetta er slóðin að znode og hún verður að vera tilgreind að fullu frá rótinni. Og líka þetta eru nokkur gögn sem við viljum flytja þangað. Og tegund fána. Og eftir sköpun skilar það slóðinni til znode.
Í öðru lagi geturðu eytt því. Bragðið hér er að önnur færibreytan, auk slóðarinnar að znode, getur tilgreint útgáfuna. Samkvæmt því verður þeim hnút eytt ef útgáfa hans sem við fluttum er jafngild þeirri sem er til í raun og veru.
Ef við viljum ekki athuga þessa útgáfu, þá sendum við einfaldlega "-1" rökin.
Í þriðja lagi athugar það hvort hnúður sé til. Skilar satt ef hnúturinn er til, annars ósatt.
Og þá birtist fánavakt, sem gerir þér kleift að fylgjast með þessum hnút.
Þú getur stillt þennan fána jafnvel á hnút sem ekki er til og fengið tilkynningu þegar hann birtist. Þetta getur líka verið gagnlegt.
Nokkrar áskoranir í viðbót eru getData. Það er ljóst að við getum tekið á móti gögnum í gegnum znode. Þú getur líka notað fánaúr. Í þessu tilviki mun það ekki setja upp ef það er enginn hnútur. Þess vegna þarftu að skilja að það er til og fá síðan gögn.
Það er einnig SetData. Hér sendum við útgáfu. Og ef við sendum þetta áfram verða gögnin um znode ákveðinnar útgáfu uppfærð.
Þú getur líka tilgreint „-1“ til að útiloka þessa ávísun.
Önnur gagnleg aðferð er fáBörn. Við getum líka fengið lista yfir alla znodes sem tilheyra því. Við getum fylgst með þessu með því að stilla fánavakt.
Og aðferð sync gerir kleift að senda allar breytingar í einu, þannig að tryggt sé að þær séu vistaðar og öllum gögnum hafi verið algjörlega breytt.
Ef við drögum hliðstæður við venjulega forritun, þá er engin trygging fyrir því að þú hafir skrifað gögnin á diskinn þegar þú notar aðferðir eins og að skrifa, sem skrifar eitthvað á diskinn, og eftir að það skilar svari til þín. Og jafnvel þegar stýrikerfið er fullviss um að allt hafi verið skrifað, þá eru kerfi á disknum sjálfum þar sem ferlið fer í gegnum lag af biðmunum og aðeins eftir það eru gögnin sett á diskinn.
Aðallega eru notuð ósamstillt símtöl. Þetta gerir viðskiptavininum kleift að vinna samhliða mismunandi beiðnum. Þú getur notað samstilltu nálgunina, en hún er minna afkastamikil.
Aðgerðirnar tvær sem við töluðum um eru uppfærsla/skrif, sem breyta gögnum. Þetta eru create, setData, sync, delete. Og lesið er til, getData, getChildren.
Nú eru nokkur dæmi um hvernig þú getur búið til frumstæður til að vinna í dreifðu kerfi. Til dæmis, sem tengist uppsetningu á einhverju. Nýr starfsmaður hefur birst. Við bættum vélinni við og hófum ferlið. Og það eru eftirfarandi þrjár spurningar. Hvernig biður það ZooKeeper um uppsetningu? Og ef við viljum breyta uppsetningunni, hvernig breytum við henni? Og eftir að við breyttum því, hvernig fá þessir starfsmenn sem við höfðum það?
ZooKeeper gerir þetta tiltölulega auðvelt. Til dæmis er það znode tréið okkar. Það er hnút fyrir forritið okkar hér, við búum til viðbótarhnút í honum sem inniheldur gögn úr uppsetningunni. Þetta geta verið aðskildar breytur eða ekki. Þar sem stærðin er lítil er stillingarstærðin yfirleitt lítil líka, svo það er alveg hægt að geyma hana hér.
Þú ert að nota aðferðina getData til að fá stillingar fyrir starfsmanninn frá hnútnum. Stillt á satt. Ef af einhverjum ástæðum er þessi hnútur ekki til, munum við fá upplýsingar um hann þegar hann birtist, eða þegar hann breytist. Ef við viljum vita að eitthvað hafi breyst, þá setjum við það á satt. Og ef gögnin í þessum hnút breytast munum við vita um það.
SetData. Við stillum gögnin, setjum "-1", þ.e.a.s. við athugum ekki útgáfuna, við gerum ráð fyrir að við höfum alltaf eina uppsetningu, við þurfum ekki að geyma margar stillingar. Ef þú þarft að geyma mikið þarftu að bæta við öðru stigi. Hér teljum við að það sé aðeins einn, svo við uppfærum aðeins þá nýjustu, svo við athugum ekki útgáfuna. Á þessari stundu fá allir viðskiptavinir sem hafa áður gerst áskrifandi tilkynningu um að eitthvað hafi breyst í þessum hnút. Og eftir að þeir hafa fengið þau verða þeir líka að biðja um gögnin aftur. Tilkynningin er sú að þeir fá ekki gögnin sjálf, heldur aðeins tilkynningu um breytingar. Eftir þetta verða þeir að biðja um ný gögn.
Annar valkosturinn til að nota frumstæðuna er hópaðild. Við erum með dreifða umsókn, það er fullt af starfsmönnum og við viljum skilja að þeir eru allir á sínum stað. Þess vegna verða þeir að skrá sjálfir að þeir starfi í umsókn okkar. Og við viljum líka komast að því, annað hvort úr meistaraferlinu eða einhvers staðar annars staðar, um alla virku starfsmennina sem við höfum núna.
Hvernig gerum við þetta? Fyrir forritið búum við til starfsmannahnút og bætum við undirstigi þar með því að nota stofnaðferðina. Ég er með villu á glærunni. Hér þarf raðröð tilgreina, þá verða allir starfsmenn búnir til einn í einu. Og forritið, sem biður um öll gögn um börn þessa hnút, tekur á móti öllum virku starfsmönnum sem eru til.
Þetta er svo hræðileg útfærsla á því hvernig þetta er hægt að gera í Java kóða. Byrjum á endanum, með aðalaðferðinni. Þetta er bekkurinn okkar, við skulum búa til aðferðina hans. Sem fyrstu rökin notum við host, þar sem við erum að tengja, þ.e.a.s. við setjum það sem rök. Og önnur rökin eru nafn hópsins.
Hvernig gerist tengingin? Þetta er einfalt dæmi um API sem er notað. Hér er allt tiltölulega einfalt. Það er til venjulegur flokkur ZooKeeper. Við sendum gestgjafa í það. Og stilltu tímamörkin, til dæmis, á 5 sekúndur. Og við erum með meðlim sem heitir connectedSignal. Í meginatriðum búum við til hóp meðfram sendu leiðinni. Við skrifum ekki gögn þar, þó eitthvað hefði getað verið skrifað. Og hnúturinn hér er af viðvarandi gerðinni. Í meginatriðum er þetta venjulegur venjulegur hnút sem mun vera til allan tímann. Þetta er þar sem lotan er búin til. Þetta er útfærsla viðskiptavinarins sjálfs. Viðskiptavinur okkar mun senda reglulega skilaboð sem gefa til kynna að lotan sé á lífi. Og þegar við ljúkum fundinum köllum við loka og það er það, fundurinn fellur niður. Þetta er ef eitthvað dettur út fyrir okkur, þannig að ZooKeeper kemst að því og slítur fundinum.
Hvernig á að læsa auðlind? Hér er allt aðeins flóknara. Við erum með hóp starfsmanna, það er einhver auðlind sem við viljum læsa. Til að gera þetta búum við til sérstakan hnút, til dæmis sem kallast lock1. Ef við gátum búið það til, þá fengum við lás hér. Og ef við gátum ekki búið það til, þá reynir starfsmaðurinn að fá getData héðan, og þar sem hnúturinn hefur þegar verið búinn til, þá setjum við áhorfanda hér og um leið og ástand þessa hnút breytist, munum við vita um það. Og við getum reynt að hafa tíma til að endurskapa það. Ef við tókum þennan hnút, tókum þennan lás, þá eftir að við þurfum ekki lengur lásinn, munum við yfirgefa hann, þar sem hnúturinn er aðeins til innan lotunnar. Í samræmi við það mun það hverfa. Og annar viðskiptavinur, innan ramma annarrar lotu, mun geta tekið læsinguna á þessum hnút, eða réttara sagt, hann mun fá tilkynningu um að eitthvað hafi breyst og hann getur reynt að gera það í tíma.
Annað dæmi um hvernig þú getur valið aðalleiðtogann. Þetta er aðeins flóknara, en líka tiltölulega einfalt. Hvað er í gangi hér? Það er aðalhnút sem safnar saman öllum starfsmönnum. Við erum að reyna að fá gögn um leiðtogann. Ef þetta gekk vel, þ.e.a.s. við fengum einhver gögn, þá byrjar starfsmaður okkar að fylgja þessum leiðtoga. Hann telur að það sé nú þegar leiðtogi.
Ef leiðtoginn dó af einhverjum ástæðum, til dæmis féll frá, þá reynum við að búa til nýjan leiðtoga. Og ef okkur tekst það, þá verður starfsmaður okkar leiðtogi. Og ef einhver á þessari stundu tókst að búa til nýjan leiðtoga, þá reynum við að skilja hver það er og fylgjum honum síðan.
Hér myndast svokölluð hjarðáhrif, þ.e. hjarðáhrifin, því þegar leiðtogi deyr verður sá sem er fyrstur í tíma leiðtogi.
Þegar þú tekur auðlind geturðu reynt að nota aðeins aðra nálgun, sem er sem hér segir. Til dæmis viljum við fá læsingu, en án hert áhrifa. Það mun felast í því að forritið okkar biður um lista yfir öll hnútauðkenni fyrir hnút sem þegar er til með lás. Og ef áður en hnúturinn sem við bjuggum til lás fyrir er minnsti af settinu sem við fengum, þá þýðir þetta að við höfum fangað lásinn. Við athugum hvort við höfum fengið lás. Til athugunar verður það skilyrði að auðkennið sem við fengum við gerð nýs læsingar sé í lágmarki. Og ef við fengum það, þá vinnum við lengra.
Ef það er ákveðið auðkenni sem er minna en læsingin okkar, þá setjum við áhorfanda á þennan atburð og bíðum eftir tilkynningu þar til eitthvað breytist. Það er að segja, við fengum þennan lás. Og þangað til það dettur af, verðum við ekki lágmarks auðkenni og fáum ekki lágmarkslás og þar með getum við skráð okkur inn. Og ef þetta skilyrði er ekki uppfyllt, þá förum við strax hingað og reynum að fá þennan lás aftur, því eitthvað gæti hafa breyst á þessum tíma.
Í hverju samanstendur ZooKeeper? Það eru 4 aðalatriði. Þetta er vinnsluferli - Beiðni. Og líka ZooKeeper Atomic Broadcast. Það er Commit Log þar sem allar aðgerðir eru skráðar. Og In-memory Replicated DB sjálft, þ.e.a.s. gagnagrunnurinn sjálfur þar sem allt þetta tré er geymt.
Þess má geta að allar skrifaðgerðir fara í gegnum beiðni vinnsluaðila. Og lestraraðgerðir fara beint í gagnagrunninn í minni.
Gagnagrunnurinn sjálfur er að fullu endurtekinn. Öll tilvik af ZooKeeper geyma fullkomið afrit af gögnunum.
Til þess að endurheimta gagnagrunninn eftir hrun er Commit log. Hefðbundin venja er að áður en gögn komast inn í minnið eru þau skrifuð þar þannig að ef þau hrynja er hægt að spila þennan log og endurheimta kerfisstöðuna. Og reglubundnar skyndimyndir af gagnagrunninum eru einnig notaðar.
ZooKeeper Atomic Broadcast er hlutur sem er notaður til að viðhalda endurteknum gögnum.
ZAB velur leiðtoga innbyrðis frá sjónarhóli ZooKeeper hnútsins. Aðrir hnútar verða fylgjendur hennar og búast við einhverjum aðgerðum frá henni. Ef þeir fá færslur senda þeir þær allar áfram til leiðtogans. Hann framkvæmir fyrst skrifaðgerð og sendir síðan skilaboð um hvað hefur breyst til fylgjenda sinna. Þetta verður í raun að fara fram í frumeindatækni, þ.e.a.s. upptöku- og útsendingaraðgerðir alls hlutarins verða að fara fram í frumeindaformi og tryggja þannig samkvæmni gagna.
Það vinnur aðeins ritbeiðnir. Meginverkefni þess er að það umbreytir aðgerðinni í viðskiptauppfærslu. Þetta er sérstaklega útbúin beiðni.
Og hér er rétt að hafa í huga að óvirkni uppfærslur fyrir sömu aðgerð er tryggð. Hvað það er? Þessi hlutur, ef hann er framkvæmdur tvisvar, mun hafa sama ástand, þ.e.a.s. beiðnin sjálf mun ekki breytast. Og þetta þarf að gera þannig að ef um hrun er að ræða geturðu endurræst aðgerðina og þannig afturkallað þær breytingar sem hafa fallið af í augnablikinu. Í þessu tilviki verður ástand kerfisins það sama, þ.e. það ætti ekki að vera þannig að röð af sömu, til dæmis uppfærsluferlum, hafi leitt til mismunandi lokaástands kerfisins.
Heimild: www.habr.com