Ninapendekeza usome nakala ya hotuba "Hadoop. ZooKeeper" kutoka kwa mfululizo "Njia za usindikaji wa kusambazwa kwa kiasi kikubwa cha data katika Hadoop"
ZooKeeper ni nini, mahali pake katika mfumo wa ikolojia wa Hadoop. Uongo juu ya kompyuta iliyosambazwa. Mchoro wa mfumo wa kawaida uliosambazwa. Ugumu katika kuratibu mifumo iliyosambazwa. Matatizo ya kawaida ya uratibu. Kanuni nyuma ya muundo wa ZooKeeper. Mfano wa data wa ZooKeeper. bendera za znode. Vikao. API ya Mteja. Primitives (usanidi, ushiriki wa kikundi, kufuli rahisi, uchaguzi wa kiongozi, kufunga bila athari ya kundi). Usanifu wa ZooKeeper. ZooKeeper DB. ZAB. Ombi la kushughulikia.
Leo tutazungumza juu ya ZooKeeper. Jambo hili ni muhimu sana. Ni, kama bidhaa yoyote ya Apache Hadoop, ina nembo. Inaonyesha mtu.
Kabla ya hili, tulizungumzia hasa jinsi data inaweza kusindika huko, jinsi ya kuihifadhi, yaani, jinsi ya kutumia kwa namna fulani na kufanya kazi nayo kwa namna fulani. Na leo ningependa kuzungumza kidogo juu ya ujenzi wa maombi yaliyosambazwa. Na ZooKeeper ni moja wapo ya mambo ambayo hukuruhusu kurahisisha jambo hili. Hii ni aina ya huduma ambayo imekusudiwa kwa aina fulani ya uratibu wa mwingiliano wa michakato katika mifumo iliyosambazwa, katika programu zilizosambazwa.
Haja ya maombi kama haya inazidi kuwa zaidi na zaidi kila siku, ndivyo kozi yetu inavyohusu. Kwa upande mmoja, MapReduce na mfumo huu uliotengenezwa tayari hukuruhusu kusawazisha ugumu huu na kumkomboa mtayarishaji programu kutoka kwa maandishi ya asili kama vile mwingiliano na uratibu wa michakato. Lakini kwa upande mwingine, hakuna mtu anayehakikishia kwamba hii haitalazimika kufanywa hata hivyo. MapReduce au mifumo mingine iliyotengenezwa tayari haibadilishi kabisa baadhi ya matukio ambayo hayawezi kutekelezwa kwa kutumia hii. Ikiwa ni pamoja na MapReduce yenyewe na rundo la miradi mingine ya Apache, wao, kwa kweli, pia ni maombi yaliyosambazwa. Na ili kurahisisha uandishi, waliandika ZooKeeper.
Kama programu zote zinazohusiana na Hadoop, ilitengenezwa na Yahoo! Sasa pia ni programu rasmi ya Apache. Haijaendelezwa kikamilifu kama HBase. Ukienda kwa JIRA HBase, basi kila siku kuna rundo la ripoti za mdudu, rundo la mapendekezo ya kuboresha kitu, i.e. maisha katika mradi yanaendelea kila wakati. Na ZooKeeper, kwa upande mmoja, ni bidhaa rahisi, na kwa upande mwingine, hii inahakikisha kuegemea kwake. Na ni rahisi kutumia, ndiyo sababu imekuwa kiwango katika matumizi ndani ya mfumo wa ikolojia wa Hadoop. Kwa hivyo niliona ingefaa kuipitia ili kuelewa jinsi inavyofanya kazi na jinsi ya kuitumia.
Hii ni picha kutoka kwa baadhi ya mihadhara tuliyokuwa nayo. Tunaweza kusema kwamba ni orthogonal kwa kila kitu ambacho tumezingatia hadi sasa. Na kila kitu kilichoonyeshwa hapa, kwa kiwango kimoja au kingine, kinafanya kazi na ZooKeeper, yaani, ni huduma inayotumia bidhaa hizi zote. HDFS wala MapReduce haziandiki huduma zao zinazofanana ambazo zingewafanyia kazi mahususi. Ipasavyo, ZooKeeper inatumika. Na hii hurahisisha maendeleo na baadhi ya mambo yanayohusiana na makosa.
Haya yote yanatoka wapi? Inaweza kuonekana kuwa tulizindua maombi mawili kwa sambamba kwenye kompyuta tofauti, tukawaunganisha kwa kamba au kwenye mesh, na kila kitu kinafanya kazi. Lakini shida ni kwamba Mtandao hauaminiki, na ikiwa ulivuta trafiki au ukiangalia kile kinachotokea huko kwa kiwango cha chini, jinsi wateja wanavyoingiliana kwenye Mtandao, mara nyingi unaweza kuona kwamba baadhi ya pakiti zimepotea au zinatumwa tena. Sio bure kwamba itifaki za TCP ziligunduliwa, ambayo inakuwezesha kuanzisha kikao fulani na kuhakikisha utoaji wa ujumbe. Lakini kwa hali yoyote, hata TCP haiwezi kukuokoa kila wakati. Kila kitu kina wakati wake. Mtandao unaweza tu kuanguka kwa muda. Inaweza tu blink. Na hii yote inaongoza kwa ukweli kwamba huwezi kutegemea Mtandao kuwa wa kuaminika. Hii ndiyo tofauti kuu kutoka kwa kuandika maombi ya sambamba ambayo yanaendesha kwenye kompyuta moja au kwenye kompyuta moja kubwa, ambapo hakuna Mtandao, ambapo kuna basi ya kubadilishana data ya kuaminika zaidi katika kumbukumbu. Na hii ni tofauti ya kimsingi.
Miongoni mwa mambo mengine, wakati wa kutumia Mtandao, daima kuna latency fulani. Disk pia inayo, lakini Mtandao una zaidi yake. Kuchelewa ni wakati fulani wa kuchelewa, ambao unaweza kuwa mdogo au muhimu kabisa.
Topolojia ya mtandao inabadilika. Topolojia ni nini - hii ni uwekaji wa vifaa vya mtandao wetu. Kuna vituo vya data, kuna racks ambazo zinasimama pale, kuna mishumaa. Yote hii inaweza kuunganishwa tena, kuhamishwa, nk. Hii yote pia inahitaji kuzingatiwa. Majina ya IP yanabadilika, njia ambayo trafiki yetu husafiri inabadilika. Hii pia inahitaji kuzingatiwa.
Mtandao unaweza pia kubadilika katika suala la vifaa. Kutoka kwa mazoezi, naweza kusema kwamba wahandisi wetu wa mtandao wanapenda sana kusasisha mara kwa mara kitu kwenye mishumaa. Ghafla programu mpya ya programu ilitoka na hawakuvutiwa haswa na nguzo fulani ya Hadoop. Wana kazi yao wenyewe. Kwao, jambo kuu ni kwamba Mtandao unafanya kazi. Ipasavyo, wanataka kupakia tena kitu hapo, fanya mwangaza kwenye vifaa vyao, na vifaa pia hubadilika mara kwa mara. Yote hii kwa namna fulani inahitaji kuzingatiwa. Yote haya yanaathiri programu yetu iliyosambazwa.
Kawaida watu wanaoanza kufanya kazi na kiasi kikubwa cha data kwa sababu fulani wanaamini kuwa mtandao hauna kikomo. Ikiwa kuna faili ya terabytes kadhaa huko, basi unaweza kuipeleka kwenye seva yako au kompyuta na kuifungua kwa kutumia paka na kuangalia. Hitilafu nyingine iko ndani Vim angalia magogo. Kamwe usifanye hivi kwa sababu ni mbaya. Kwa sababu Vim inajaribu kubaki kila kitu, pakia kila kitu kwenye kumbukumbu, haswa tunapoanza kupitia logi hii na kutafuta kitu. Haya ni mambo ambayo yamesahaulika, lakini inafaa kuzingatia.
Ni rahisi kuandika programu moja inayoendesha kwenye kompyuta moja na processor moja.
Wakati mfumo wetu unakua, tunataka kusawazisha yote, na kuifanya sio tu kwenye kompyuta, bali pia kwenye nguzo. Swali linatokea: jinsi ya kuratibu jambo hili? Programu zetu zinaweza hata zisiingiliane, lakini tuliendesha michakato kadhaa kwa sambamba kwenye seva kadhaa. Na jinsi ya kufuatilia kwamba kila kitu kinaendelea vizuri kwao? Kwa mfano, wanatuma kitu kupitia mtandao. Lazima waandike kuhusu hali yao mahali fulani, kwa mfano, katika aina fulani ya hifadhidata au logi, kisha wajumlishe logi hii na kisha kuichanganua mahali fulani. Zaidi ya hayo, tunahitaji kuzingatia kwamba mchakato ulikuwa ukifanya kazi na kufanya kazi, ghafla kosa fulani lilionekana ndani yake au lilianguka, basi tutapata harakaje kuhusu hilo?
Ni wazi kwamba yote haya yanaweza kufuatiliwa haraka. Hii pia ni nzuri, lakini ufuatiliaji ni kitu kidogo ambacho kinakuwezesha kufuatilia baadhi ya mambo kwa kiwango cha juu.
Tunapotaka michakato yetu ianze kuingiliana na kila mmoja, kwa mfano, kutuma kila mmoja data fulani, basi swali pia linatokea - hii itatokeaje? Je! kutakuwa na aina fulani ya hali ya mbio, wataandika juu ya kila mmoja, data itafika kwa usahihi, je, chochote kitapotea njiani? Tunahitaji kukuza aina fulani ya itifaki, nk.
Uratibu wa michakato hii yote sio jambo dogo. Na inamlazimisha msanidi programu kwenda chini hadi kiwango cha chini, na kuandika mifumo kutoka mwanzo, au sio kabisa kutoka mwanzo, lakini hii sio rahisi sana.
Ikiwa unakuja na algorithm ya cryptographic au hata kutekeleza, kisha uitupe mara moja, kwa sababu uwezekano mkubwa hautakufanyia kazi. Kuna uwezekano mkubwa kuwa na rundo la makosa ambayo umesahau kutoa. Kamwe usiitumie kwa jambo lolote zito kwa sababu itawezekana kuwa thabiti. Kwa sababu algorithms zote zilizopo zimejaribiwa na wakati kwa muda mrefu sana. Inasumbuliwa na jamii. Hii ni mada tofauti. Na ni sawa hapa. Ikiwa inawezekana si kutekeleza aina fulani ya maingiliano ya mchakato mwenyewe, basi ni bora si kufanya hivyo, kwa sababu ni ngumu sana na inakuongoza chini ya njia ya kutetemeka ya kutafuta mara kwa mara makosa.
Leo tunazungumza juu ya ZooKeeper. Kwa upande mmoja, ni mfumo, kwa upande mwingine, ni huduma ambayo hurahisisha maisha kwa msanidi programu na kurahisisha utekelezaji wa mantiki na uratibu wa michakato yetu iwezekanavyo.
Hebu tukumbuke jinsi mfumo wa kawaida unaosambazwa unavyoweza kuonekana. Hii ndio tuliyozungumza - HDFS, HBase. Kuna mchakato wa Mwalimu ambao unasimamia michakato ya wafanyikazi na watumwa. Ana jukumu la kuratibu na kusambaza kazi, kuanzisha tena wafanyikazi, kuzindua mpya, na kusambaza mzigo.
Jambo la juu zaidi ni Huduma ya Uratibu, yaani, kusogeza kazi ya uratibu yenyewe katika mchakato tofauti, pamoja na kuendesha aina fulani ya chelezo au Stanby Master sambamba, kwa sababu Mwalimu anaweza kushindwa. Na ikiwa Mwalimu ataanguka, basi mfumo wetu hautafanya kazi. Tunaendesha chelezo. Baadhi ya majimbo kwamba Mwalimu anahitaji kuigwa ili kuhifadhi nakala. Hii pia inaweza kukabidhiwa kwa Huduma ya Uratibu. Lakini katika mchoro huu, Mwalimu mwenyewe ndiye mwenye jukumu la kuratibu wafanyakazi.
Chaguo la juu zaidi ni wakati uratibu wote unashughulikiwa na huduma yetu, kama kawaida hufanyika. Anachukua jukumu la kuhakikisha kila kitu kinafanya kazi. Na ikiwa kitu haifanyi kazi, tunapata juu yake na jaribu kuzunguka hali hii. Kwa hali yoyote, tumeachwa na Mwalimu ambaye kwa namna fulani anaingiliana na watumwa na anaweza kutuma data, taarifa, ujumbe, nk kupitia huduma fulani.
Kuna mpango wa hali ya juu zaidi, wakati hatuna Bwana, nodi zote ni watumwa wakuu, tofauti katika tabia zao. Lakini bado wanahitaji kuingiliana na kila mmoja, kwa hivyo bado kuna huduma fulani iliyobaki ili kuratibu vitendo hivi. Pengine, Cassandra, ambayo inafanya kazi kwa kanuni hii, inafaa mpango huu.
Ni vigumu kusema ni ipi kati ya mipango hii inafanya kazi vizuri zaidi. Kila moja ina faida na hasara zake.
Na hakuna haja ya kuogopa baadhi ya mambo na Mwalimu, kwa sababu, kama inavyoonyesha mazoezi, yeye si rahisi kutumikia kila wakati. Jambo kuu hapa ni kuchagua suluhisho sahihi la kuhudumia huduma hii kwenye node tofauti yenye nguvu, ili iwe na rasilimali za kutosha, ili ikiwa inawezekana, watumiaji hawana upatikanaji huko, ili wasiue mchakato huu kwa ajali. Lakini wakati huo huo, katika mpango huo ni rahisi zaidi kusimamia wafanyakazi kutoka kwa mchakato wa Mwalimu, yaani mpango huu ni rahisi kutoka kwa mtazamo wa utekelezaji.
Na mpango huu (hapo juu) labda ni ngumu zaidi, lakini unaaminika zaidi.
Tatizo kuu ni kushindwa kwa sehemu. Kwa mfano, tunapotuma ujumbe kupitia Mtandao, aina fulani ya ajali hutokea, na yule aliyetuma ujumbe huo hatajua kama ujumbe wake umepokelewa na kilichotokea kwa upande wa mpokeaji, hatajua ikiwa ujumbe huo ulichakatwa kwa usahihi. , yaani hatapokea uthibitisho wowote.
Ipasavyo, tunapaswa kushughulikia hali hii. Na jambo rahisi zaidi ni kutuma tena ujumbe huu na kusubiri hadi tupate jibu. Katika kesi hii, haijazingatiwa ikiwa hali ya mpokeaji imebadilika. Tunaweza kutuma ujumbe na kuongeza data sawa mara mbili.
ZooKeeper inatoa njia za kukabiliana na kukataa vile, ambayo pia hurahisisha maisha yetu.
Kama ilivyotajwa hapo awali, hii ni sawa na kuandika programu zenye nyuzi nyingi, lakini tofauti kuu ni kwamba katika programu zilizosambazwa ambazo tunaunda kwenye mashine tofauti, njia pekee ya kuwasiliana ni Mtandao. Kimsingi, huu ni usanifu usioshirikiwa. Kila mchakato au huduma inayoendesha kwenye mashine moja ina kumbukumbu yake mwenyewe, disk yake mwenyewe, processor yake mwenyewe, ambayo haishiriki na mtu yeyote.
Ikiwa tunaandika programu yenye nyuzi nyingi kwenye kompyuta moja, basi tunaweza kutumia kumbukumbu iliyoshirikiwa ili kubadilishana data. Tuna swichi ya muktadha hapo, michakato inaweza kubadili. Hii inathiri utendaji. Kwa upande mmoja, hakuna kitu kama hicho katika programu kwenye nguzo, lakini kuna shida na Mtandao.
Ipasavyo, shida kuu zinazotokea wakati wa kuandika mifumo iliyosambazwa ni usanidi. Tunaandika aina fulani ya maombi. Ikiwa ni rahisi, basi tunaweka nambari za kila aina kwenye nambari, lakini hii sio ngumu, kwa sababu ikiwa tutaamua kuwa badala ya kuisha kwa nusu sekunde tunataka kuisha kwa sekunde moja, basi tunahitaji kurudisha programu na pindua kila kitu tena. Ni jambo moja wakati iko kwenye mashine moja, wakati unaweza kuianzisha tena, lakini tunapokuwa na mashine nyingi, tunapaswa kunakili kila kitu kila wakati. Lazima tujaribu kufanya programu iweze kusanidiwa.
Hapa tunazungumza juu ya usanidi wa tuli kwa michakato ya mfumo. Hii sio kabisa, labda kutoka kwa mtazamo wa mfumo wa uendeshaji, inaweza kuwa usanidi wa tuli kwa michakato yetu, i.e. huu ni usanidi ambao hauwezi kuchukuliwa na kusasishwa tu.
Pia kuna usanidi wa nguvu. Hivi ndivyo vigezo ambavyo tunataka kuvibadilisha kwa kuruka ili vichukuliwe huko.
Tatizo nini hapa? Tulisasisha usanidi, tukaizindua, ili iweje? Shida inaweza kuwa kwamba kwa upande mmoja tulizindua usanidi, lakini tukasahau juu ya kitu kipya, usanidi ulibaki hapo. Pili, tulipokuwa tukizindua, usanidi ulisasishwa katika baadhi ya maeneo, lakini si katika maeneo mengine. Na baadhi ya michakato ya programu yetu inayoendeshwa kwenye mashine moja ilianzishwa upya na usanidi mpya, na mahali pengine na ya zamani. Hii inaweza kusababisha programu yetu iliyosambazwa kutofautiana kutoka kwa mtazamo wa usanidi. Tatizo hili ni la kawaida. Kwa usanidi unaobadilika, inafaa zaidi kwa sababu inamaanisha kuwa inaweza kubadilishwa kwa kuruka.
Tatizo jingine ni uanachama wa kikundi. Daima tuna seti ya wafanyikazi, kila wakati tunataka kujua ni nani kati yao aliye hai, ni yupi kati yao aliyekufa. Ikiwa kuna Mwalimu, basi lazima aelewe ni wafanyakazi gani wanaweza kuelekezwa kwa wateja ili wafanye mahesabu au kufanya kazi na data, na ambayo haiwezi. Shida ambayo inatokea kila wakati ni kwamba tunahitaji kujua ni nani anayefanya kazi katika nguzo yetu.
Tatizo lingine la kawaida ni uchaguzi wa viongozi, tunapotaka kujua nani anaongoza. Mfano mmoja ni urudufishaji, tunapokuwa na mchakato fulani ambao hupokea shughuli za uandishi na kisha kuziiga kati ya michakato mingine. Atakuwa kiongozi, kila mtu atamtii, atamfuata. Ni muhimu kuchagua mchakato ili usiwe na utata kwa kila mtu, ili isije kuwa viongozi wawili wanachaguliwa.
Pia kuna ufikiaji wa kipekee. Tatizo hapa ni ngumu zaidi. Kuna kitu kama bubu, unapoandika programu zenye nyuzi nyingi na unataka ufikiaji wa rasilimali fulani, kwa mfano, seli ya kumbukumbu, kupunguzwa na kufanywa na uzi mmoja tu. Hapa rasilimali inaweza kuwa kitu cha kufikirika zaidi. Na programu tofauti kutoka kwa nodi tofauti za Mtandao wetu zinapaswa kupokea ufikiaji wa kipekee kwa rasilimali fulani, na sio ili kila mtu aweze kuibadilisha au kuandika kitu hapo. Hizi ndizo zinazoitwa kufuli.
ZooKeeper hukuruhusu kutatua shida hizi zote kwa digrii moja au nyingine. Nami nitaonyesha kwa mifano jinsi inakuwezesha kufanya hivyo.
Hakuna kuzuia primitives. Tunapoanza kutumia kitu, hii ya zamani haitasubiri tukio lolote kutokea. Uwezekano mkubwa zaidi, jambo hili litafanya kazi kwa usawa, na hivyo kuruhusu michakato isining'inie wakati wanangojea kitu. Hili ni jambo la manufaa sana.
Maombi yote ya mteja yanashughulikiwa kwa mpangilio wa foleni ya jumla.
Na wateja wana fursa ya kupokea arifa kuhusu mabadiliko katika hali fulani, kuhusu mabadiliko ya data, kabla ya mteja kuona data iliyobadilishwa wenyewe.
ZooKeeper inaweza kufanya kazi katika hali mbili. Ya kwanza ni ya kujitegemea, kwenye nodi moja. Hii ni rahisi kwa majaribio. Inaweza pia kufanya kazi katika hali ya kundi, kwenye idadi yoyote ya nodi. sevaIkiwa tuna kundi la mashine 100, si lazima liendeshe kwenye mashine 100. Inatosha kutenga mashine chache ambapo ZooKeeper inaweza kuendesha. Na inafuata kanuni ya upatikanaji wa juu. ZooKeeper huhifadhi nakala kamili ya data kwenye kila mfano unaoendesha. Nitaelezea jinsi inavyofanya hivi baadaye. Haigawanyi au kugawanya data. Kwa upande mmoja, hii ni hasara kwa sababu hatuwezi kuhifadhi mengi, lakini kwa upande mwingine, sio lazima. Haijaundwa kwa ajili hiyo; si hifadhidata.
Data inaweza kuakibishwa kwa upande wa mteja. Hii ni kanuni ya kawaida ili tusikatiza huduma na tusiipake kwa maombi sawa. Mteja mahiri huwa anajua kuhusu hili na hulihifadhi.
Kwa mfano, kitu kimebadilika hapa. Kuna aina fulani ya maombi. Kiongozi mpya alichaguliwa, ambaye anajibika, kwa mfano, kwa usindikaji wa shughuli za kuandika. Na tunataka kuiga data. Suluhisho mojawapo ni kuiweka kwenye kitanzi. Na tunahoji huduma zetu kila wakati - kuna kitu kimebadilika? Chaguo la pili ni bora zaidi. Huu ni utaratibu wa saa unaokuwezesha kuwafahamisha wateja kuwa kuna kitu kimebadilika. Hii ni njia ya gharama nafuu katika suala la rasilimali na rahisi zaidi kwa wateja.
Mteja ndiye mtumiaji anayetumia ZooKeeper.
Seva ni mchakato wa ZooKeeper yenyewe.
Znode ndio jambo kuu katika ZooKeeper. Znodes zote zimehifadhiwa kwenye kumbukumbu na ZooKeeper na zimepangwa kwa namna ya mchoro wa hierarchical, kwa namna ya mti.
Kuna aina mbili za operesheni. Ya kwanza ni sasisho / andika, wakati operesheni fulani inabadilisha hali ya mti wetu. Mti ni wa kawaida.
Na inawezekana kwamba mteja hajakamilisha ombi moja na amekataliwa, lakini anaweza kuanzisha kikao ambacho kinaingiliana na ZooKeeper.
Mfano wa data wa ZooKeeper unafanana na mfumo wa faili. Kuna mzizi wa kawaida na kisha tulienda kana kwamba kupitia saraka zinazotoka kwenye mzizi. Na kisha orodha ya ngazi ya kwanza, ngazi ya pili. Hii yote ni znodes.
Kila znode inaweza kuhifadhi data fulani, kwa kawaida sio kubwa sana, kwa mfano, kilobytes 10. Na kila znode inaweza kuwa na idadi fulani ya watoto.
Znodi huja katika aina kadhaa. Wanaweza kuundwa. Na wakati wa kuunda znode, tunataja aina ambayo inapaswa kuwa.
Kuna aina mbili. Ya kwanza ni bendera ya ephemeral. Znode anaishi ndani ya kipindi. Kwa mfano, mteja ameanzisha kikao. Na maadamu kikao hiki kiko hai, kitakuwepo. Hii ni muhimu ili kutozalisha kitu kisichohitajika. Hili pia linafaa kwa wakati ambapo ni muhimu kwetu kuhifadhi data ya awali ndani ya kipindi.
Aina ya pili ni bendera inayofuatana. Inaongeza kaunta kwenye njia ya znode. Kwa mfano, tulikuwa na saraka iliyo na programu 1_5. Na tulipounda nodi ya kwanza, ilipokea p_1, ya pili - p_2. Na tunapoita njia hii kila wakati, tunapita njia kamili, ikionyesha sehemu tu ya njia, na nambari hii inaongezwa kiatomati kwa sababu tunaonyesha aina ya nodi - mlolongo.
Znode ya kawaida. Daima ataishi na kuwa na jina ambalo tunamwambia.
Jambo lingine muhimu ni bendera ya saa. Ikiwa tutaiweka, basi mteja anaweza kujiandikisha kwa matukio fulani kwa node maalum. Nitakuonyesha baadaye kwa mfano jinsi hii inafanywa. ZooKeeper yenyewe inamjulisha mteja kwamba data kwenye nodi imebadilika. Hata hivyo, arifa hazihakikishi kuwa baadhi ya data mpya imefika. Wanasema tu kwamba kuna kitu kimebadilika, kwa hivyo bado unapaswa kulinganisha data baadaye na simu tofauti.
Na kama nilivyosema tayari, mpangilio wa data umedhamiriwa na kilobytes. Hakuna haja ya kuhifadhi data kubwa ya maandishi huko, kwa sababu sio hifadhidata, ni seva ya uratibu wa hatua.
Acha nikuambie kidogo kuhusu vipindi. Ikiwa tuna seva kadhaa, tunaweza kubadili kutoka seva moja hadi nyingine kwa uwazi. seva, kwa kutumia Kitambulisho cha kipindi. Hii ni rahisi sana.
Kila kipindi kina aina fulani ya kuisha. Kipindi kinafafanuliwa na ikiwa mteja atatuma chochote kwa seva wakati wa kipindi hicho. Ikiwa hakusambaza chochote wakati wa kuisha, kipindi huanguka, au mteja anaweza kuifunga mwenyewe.
Haina vipengele vingi hivyo, lakini unaweza kufanya mambo tofauti na API hii. Simu hiyo tuliona kuunda inaunda znode na inachukua vigezo vitatu. Hii ndio njia ya znode, na lazima ibainishwe kabisa kutoka kwa mzizi. Na pia hii ni baadhi ya data kwamba tunataka kuhamisha huko. Na aina ya bendera. Na baada ya uumbaji inarudisha njia ya znode.
Pili, unaweza kuifuta. Hila hapa ni kwamba parameter ya pili, pamoja na njia ya znode, inaweza kutaja toleo. Kwa hivyo, znode hiyo itafutwa ikiwa toleo lake ambalo tulihamisha ni sawa na lile ambalo lipo.
Ikiwa hatutaki kuangalia toleo hili, basi tunapitisha hoja ya "-1".
Tatu, inakagua uwepo wa znode. Hurejesha kweli ikiwa nodi ipo, sivyo vinginevyo.
Na kisha saa ya bendera inaonekana, ambayo inakuwezesha kufuatilia node hii.
Unaweza kuweka bendera hii hata kwenye nodi ambayo haipo na kupokea arifa inapoonekana. Hii inaweza pia kuwa na manufaa.
Changamoto kadhaa zaidi ni getData. Ni wazi kwamba tunaweza kupokea data kupitia znode. Unaweza pia kutumia saa ya bendera. Katika kesi hii, haitasakinisha ikiwa hakuna node. Kwa hiyo, unahitaji kuelewa kuwa ipo, na kisha kupokea data.
Kuna pia SetData. Hapa tunapitisha toleo. Na ikiwa tutapitisha hii, data kwenye znode ya toleo fulani itasasishwa.
Unaweza pia kubainisha "-1" ili kuwatenga hundi hii.
Njia nyingine muhimu ni pata Watoto. Tunaweza pia kupata orodha ya znodi zote ambazo ni zake. Tunaweza kufuatilia hili kwa kuweka saa ya bendera.
Na mbinu Sync inaruhusu mabadiliko yote kutumwa mara moja, na hivyo kuhakikisha kuwa yamehifadhiwa na data yote imebadilishwa kabisa.
Ikiwa tunachora mlinganisho na programu ya kawaida, basi unapotumia njia kama vile kuandika, ambayo huandika kitu kwenye diski, na baada ya kurudi jibu kwako, hakuna uhakika kwamba umeandika data kwenye diski. Na hata wakati mfumo wa uendeshaji una hakika kwamba kila kitu kimeandikwa, kuna taratibu katika diski yenyewe ambapo mchakato unapitia safu za buffers, na tu baada ya kuwa data imewekwa kwenye diski.
Mara nyingi simu zisizolingana hutumiwa. Hii inaruhusu mteja kufanya kazi kwa sambamba na maombi tofauti. Unaweza kutumia mbinu ya kusawazisha, lakini haina tija.
Operesheni mbili tulizozungumza ni sasisho / andika, ambazo hubadilisha data. Hizi ni kuunda, kuwekaData, kusawazisha, kufuta. Na kusoma ipo, getData, getChildren.
Sasa mifano michache ya jinsi unaweza kutengeneza primitives kwa kufanya kazi katika mfumo uliosambazwa. Kwa mfano, kuhusiana na usanidi wa kitu. Mfanyikazi mpya ametokea. Tuliongeza mashine na kuanza mchakato. Na kuna maswali matatu yafuatayo. Je, inaulizaje ZooKeeper kwa usanidi? Na ikiwa tunataka kubadilisha usanidi, tunabadilishaje? Na baada ya kuibadilisha, je wale wafanyakazi tuliokuwa nao wanaipataje?
ZooKeeper hurahisisha hii. Kwa mfano, kuna mti wetu wa znode. Kuna node ya maombi yetu hapa, tunaunda node ya ziada ndani yake, ambayo ina data kutoka kwa usanidi. Hizi zinaweza au zisiwe vigezo tofauti. Kwa kuwa saizi ni ndogo, saizi ya usanidi kawaida ni ndogo, kwa hivyo inawezekana kabisa kuihifadhi hapa.
Unatumia mbinu getData kupata usanidi wa mfanyakazi kutoka kwa nodi. Weka kwa kweli. Ikiwa kwa sababu fulani node hii haipo, tutajulishwa kuhusu hilo wakati inaonekana, au inapobadilika. Ikiwa tunataka kujua kwamba kitu kimebadilika, basi tunaiweka kuwa kweli. Na ikiwa data katika nodi hii itabadilika, tutajua kuhusu hilo.
SetData. Tunaweka data, kuweka "-1", i.e. hatuchunguzi toleo, tunadhania kuwa tuna usanidi mmoja kila wakati, hatuitaji kuhifadhi usanidi mwingi. Ikiwa unahitaji kuhifadhi mengi, utahitaji kuongeza kiwango kingine. Hapa tunaamini kuwa kuna moja tu, kwa hivyo tunasasisha toleo jipya zaidi, ili tusikague toleo. Kwa wakati huu, wateja wote ambao wamejiandikisha hapo awali wanapokea arifa kwamba kuna kitu kimebadilika katika nodi hii. Na baada ya kuipokea, lazima pia waombe data tena. Arifa ni kwamba hawapati data yenyewe, lakini taarifa tu ya mabadiliko. Baada ya haya lazima waombe data mpya.
Chaguo la pili kwa kutumia primitive ni uanachama wa kikundi. Tuna maombi yaliyosambazwa, kuna kundi la wafanyikazi na tunataka kuelewa kuwa wote wako mahali. Kwa hivyo, lazima wajiandikishe kuwa wanafanya kazi katika maombi yetu. Na pia tunataka kujua, ama kutoka kwa mchakato wa Mwalimu au mahali pengine, kuhusu wafanyikazi wote wanaofanya kazi ambao tunao kwa sasa.
Je, tunafanyaje hili? Kwa programu, tunaunda nodi ya wafanyikazi na kuongeza kiwango kidogo hapo kwa kutumia njia ya kuunda. Nina hitilafu kwenye slaidi. Hapa unahitaji mfululizo bainisha, basi wafanyakazi wote wataundwa mmoja baada ya mwingine. Na maombi, kuomba data zote kuhusu watoto wa node hii, inapokea wafanyakazi wote wanaofanya kazi waliopo.
Huu ni utekelezaji mbaya sana wa jinsi hii inaweza kufanywa katika nambari ya Java. Wacha tuanze kutoka mwisho, na njia kuu. Hili ni darasa letu, wacha tuunde njia yake. Kama hoja ya kwanza tunatumia mwenyeji, ambapo tunaunganisha, i.e. tunaiweka kama hoja. Na hoja ya pili ni jina la kundi.
Uunganisho unatokeaje? Huu ni mfano rahisi wa API ambayo hutumiwa. Kila kitu ni rahisi hapa. Kuna darasa la kawaida la ZooKeeper. Tunapitisha wenyeji kwake. Na weka muda wa kuisha, kwa mfano, hadi sekunde 5. Na tuna mwanachama anayeitwa kushikamanaSignal. Kimsingi, tunaunda kikundi kwenye njia iliyopitishwa. Hatuandiki data hapo, ingawa kuna kitu kingeweza kuandikwa. Na nodi hapa ni ya aina inayoendelea. Kimsingi, hii ni nodi ya kawaida ya kawaida ambayo itakuwepo wakati wote. Hapa ndipo kikao kinaundwa. Huu ni utekelezaji wa mteja yenyewe. Mteja wetu ataripoti mara kwa mara kuwa kipindi kinaendelea. Na tunapomaliza kikao, tunaita karibu na ndivyo hivyo, kikao kinaanguka. Hii ni ikiwa kuna kitu kitaanguka kwa ajili yetu, ili ZooKeeper ijue kuihusu na kukata kipindi.
Jinsi ya kufunga rasilimali? Hapa kila kitu ni ngumu zaidi. Tuna seti ya wafanyikazi, kuna rasilimali ambayo tunataka kufunga. Ili kufanya hivyo, tunaunda node tofauti, kwa mfano, inayoitwa lock1. Ikiwa tuliweza kuunda, basi tulipata kufuli hapa. Na ikiwa hatukuweza kuunda, basi mfanyakazi anajaribu kupata GetData kutoka hapa, na kwa kuwa node tayari imeundwa, basi tunaweka mlinzi hapa na wakati hali ya node hii inabadilika, tutajua kuhusu hilo. Na tunaweza kujaribu kuwa na wakati wa kuunda upya. Ikiwa tulichukua node hii, tukachukua lock hii, basi baada ya hatuhitaji tena lock, tutaiacha, kwani node ipo tu ndani ya kikao. Ipasavyo, itatoweka. Na mteja mwingine, ndani ya mfumo wa kikao kingine, ataweza kuchukua lock kwenye node hii, au tuseme, atapokea taarifa kwamba kitu kimebadilika na anaweza kujaribu kufanya hivyo kwa wakati.
Mfano mwingine wa jinsi unavyoweza kuchagua kiongozi mkuu. Hii ni ngumu zaidi, lakini pia ni rahisi. Nini kinaendelea hapa? Kuna nodi kuu inayojumuisha wafanyikazi wote. Tunajaribu kupata data kuhusu kiongozi. Ikiwa hii ilifanyika kwa mafanikio, i.e. tulipokea data fulani, basi mfanyakazi wetu anaanza kumfuata kiongozi huyu. Anaamini kuwa tayari kuna kiongozi.
Ikiwa kiongozi alikufa kwa sababu fulani, kwa mfano, akaanguka, basi tunajaribu kuunda kiongozi mpya. Na tukifanikiwa, basi mfanyakazi wetu anakuwa kiongozi. Na ikiwa mtu kwa wakati huu aliweza kuunda kiongozi mpya, basi tunajaribu kuelewa ni nani na kumfuata.
Hapa kinachojulikana athari ya mifugo hutokea, yaani athari ya mifugo, kwa sababu wakati kiongozi akifa, yule ambaye ni wa kwanza kwa wakati atakuwa kiongozi.
Wakati wa kukamata rasilimali, unaweza kujaribu kutumia mbinu tofauti kidogo, ambayo ni kama ifuatavyo. Kwa mfano, tunataka kupata kufuli, lakini bila athari ya hert. Itajumuisha ukweli kwamba maombi yetu yanaomba orodha za vitambulisho vyote vya nodi kwa nodi iliyopo tayari iliyo na kufuli. Na ikiwa kabla ya hapo nodi ambayo tumeunda kufuli ni ndogo zaidi ya seti tuliyopokea, basi hii inamaanisha kuwa tumekamata kufuli. Tunaangalia kuwa tumepokea kufuli. Kama hundi, kutakuwa na sharti kwamba kitambulisho tulichopokea wakati wa kuunda kufuli mpya ni ndogo. Na ikiwa tumeipokea, basi tunafanya kazi zaidi.
Ikiwa kuna kitambulisho fulani ambacho ni kidogo kuliko kufuli yetu, basi tunaweka mlinzi kwenye tukio hili na tungojee arifa hadi kitu kibadilike. Hiyo ni, tulipokea kufuli hii. Na hadi itakapoanguka, hatutakuwa kitambulisho cha chini na hatutapokea kufuli ya chini, na kwa hivyo tutaweza kuingia. Na ikiwa hali hii haijafikiwa, basi tunaenda hapa mara moja na kujaribu kupata kufuli hii tena, kwa sababu kitu kinaweza kuwa kimebadilika wakati huu.
ZooKeeper inajumuisha nini? Kuna mambo 4 kuu. Hii ni michakato ya usindikaji - Ombi. Na pia Matangazo ya Atomiki ya ZooKeeper. Kuna Kumbukumbu ya Ahadi ambapo shughuli zote zimerekodiwa. Na DB Iliyojirudia ya Ndani yenyewe, yaani hifadhidata yenyewe ambapo mti huu mzima umehifadhiwa.
Inafaa kumbuka kuwa shughuli zote za uandishi hupitia Kichakataji cha Ombi. Na shughuli za kusoma huenda moja kwa moja kwenye hifadhidata ya Ndani ya kumbukumbu.
Hifadhidata yenyewe imeigwa kikamilifu. Matukio yote ya ZooKeeper huhifadhi nakala kamili ya data.
Ili kurejesha hifadhidata baada ya ajali, kuna kumbukumbu ya Kujitolea. Mazoezi ya kawaida ni kwamba kabla ya data kuingia kwenye kumbukumbu, imeandikwa hapo ili ikiwa itaanguka, logi hii inaweza kuchezwa na hali ya mfumo inaweza kurejeshwa. Na snapshots mara kwa mara ya hifadhidata pia hutumiwa.
Matangazo ya Atomiki ya ZooKeeper ni kitu ambacho hutumiwa kudumisha data iliyoigwa.
ZAB ndani huchagua kiongozi kutoka kwa mtazamo wa nodi ya ZooKeeper. Nodi zingine huwa wafuasi wake na kutarajia vitendo fulani kutoka kwake. Wakipokea maingizo, wanayapeleka yote kwa kiongozi. Kwanza anafanya operesheni ya kuandika na kisha kutuma ujumbe kuhusu kile ambacho kimebadilika kwa wafuasi wake. Hii, kwa kweli, lazima ifanyike kwa atomi, i.e. kurekodi na kutangaza kwa jambo zima lazima kufanyike kwa atomi, na hivyo kuhakikisha uthabiti wa data.
Inachakata tu maombi ya kuandika. Kazi yake kuu ni kwamba inabadilisha operesheni kuwa sasisho la shughuli. Hili ni ombi lililotolewa maalum.
Na hapa ni muhimu kuzingatia kwamba kutokuwa na uwezo wa sasisho kwa operesheni sawa ni uhakika. Ni nini? Jambo hili, likitekelezwa mara mbili, litakuwa na hali sawa, yaani ombi lenyewe halitabadilika. Na hii inahitaji kufanywa ili katika kesi ya ajali, unaweza kuanzisha upya operesheni, na hivyo kurudisha nyuma mabadiliko ambayo yameanguka kwa sasa. Katika kesi hii, hali ya mfumo itakuwa sawa, i.e. haipaswi kuwa hivyo kwamba safu ya sawa, kwa mfano, michakato ya sasisho, ilisababisha hali tofauti za mwisho za mfumo.
Chanzo: mapenzi.com
