Ez ji we re pêşniyar dikim ku hûn transkripta dersa "Hadoop. ZooKeeper" ji rêzenivîsa "Rêbazên ji bo hilberandina cildên mezin ên daneyan li Hadoop" bixwînin.
ZooKeeper çi ye, cihê wê di ekosîstema Hadoop de ye. Nerastiyên di derbarê komputera belavkirî de. Diagrama pergala belavbûyî ya standard. Zehmetî di hevrêzkirina pergalên belavkirî de. Pirsgirêkên hevrêziya tîpîk. Prensîbên li pişt sêwirana ZooKeeper. Modela daneya ZooKeeper. alên znode. Sessions. Client API. Primitives (veavakirin, endametiya komê, kilîdên sade, hilbijartina serokatî, girtina bêyî bandora keriyê). mîmariya ZooKeeper. ZooKeeper DB. ZAB. Rêvebirê daxwazê.
Îro em ê li ser ZooKeeper biaxivin. Ev tişt pir bikêr e. Ew, mîna her hilberek Apache Hadoop, logoyek heye. Ew zilamek nîşan dide.
Berî vê yekê, me bi giranî li ser axaftinê kir ku meriv çawa dikare li wir dane were hilanîn, meriv wê çawa hilîne, ango meriv wê çawa bi rengek bikar bîne û bi rengekî bi wê re bixebite. Û îro ez dixwazim hinekî li ser avakirina serlêdanên belavkirî biaxivim. ZooKeeper yek ji wan tiştan e ku dihêle hûn vê mijarê hêsan bikin. Ev celebek karûbar e ku ji bo cûreyek hevrêziya danûstendina pêvajoyên di pergalên belavkirî de, di serîlêdanên belavkirî de tête armanc kirin.
Pêdiviya serlêdanên bi vî rengî her roj zêdetir dibe, qursa me jî ev e. Ji aliyek ve, MapReduce û vê çarçoweya amadekirî dihêle hûn vê tevliheviyê ast bikin û bernamenûs ji nivîsandina primitives ên wekî têkilî û hevrêziya pêvajoyan azad bikin. Lê ji aliyê din ve, kes garantî nake ku bi her awayî ev ê neyê kirin. MapReduce an çarçoveyên din ên amade ne her gav bi tevahî li şûna hin dozên ku nekarin bi karanîna vê yekê werin bicîh kirin vedigirin. Di nav wan de MapReduce û komek projeyên din ên Apache, ew jî serîlêdanên belavkirî ne. Û ji bo nivîsandinê hêsantir bikin, wan ZooKeeper nivîsand.
Mîna hemî serîlêdanên têkildarî Hadoop, ew ji hêla Yahoo ve hatî pêşve xistin! Naha ew jî serîlêdanek fermî ya Apache ye. Ew wekî HBase ne bi rengek çalak pêşkeftî ye. Ger hûn biçin JIRA HBase, wê hingê her roj komek raporên xeletiyê hene, komek pêşniyar hene ku tiştek xweşbîn bikin, ango jiyana di projeyê de bi domdarî berdewam dike. ZooKeeper, ji aliyekî ve, hilberek bi hêsanî hêsan e, û ji hêla din ve, ev pêbaweriya wê piştrast dike. Û karanîna wê pir hêsan e, ji ber vê yekê ew di serîlêdanên di nav ekosîstema Hadoop de bûye standard. Ji ber vê yekê min fikirîn ku ew ê kêrhatî be ku meriv wê binirxîne da ku fêm bike ka ew çawa dixebite û meriv wê çawa bikar tîne.
Ev wêneyek ji hin dersa me ye. Em dikarin bibêjin ku ew ji her tiştê ku me heya nuha nirxandiye ortogonal e. Û her tiştê ku li vir tê destnîşan kirin, heya dereceyek an din, bi ZooKeeper re dixebite, ango, ew karûbarek e ku van hemî hilberan bikar tîne. Ne HDFS û ne jî MapReduce karûbarên xwe yên wekhev ên ku dê bi taybetî ji wan re bixebitin nanivîsin. Li gorî vê yekê, ZooKeeper tê bikar anîn. Û ev pêşveçûn û hin tiştên ku bi xeletiyan ve girêdayî ne hêsan dike.
Ev hemû ji ku tên? Wusa dixuye ku me du serîlêdan bi paralelî li ser komputerên cihêreng dan destpêkirin, wan bi xêzek an di mesh ve girêda, û her tişt dixebite. Lê pirsgirêk ev e ku Tor ne pêbawer e, û heke we seyrûseferê dikişîne an li tiştê ku li wir di astek nizm de diqewime mêze kir, ka xerîdar çawa li ser Torê têkilî dikin, hûn pir caran dikarin bibînin ku hin pakêt winda dibin an ji nû ve têne şandin. Ne ji bo tiştek e ku protokolên TCP-ê hatine vedîtin, ku dihêle hûn rûniştinek diyar saz bikin û gihandina peyaman garantî bikin. Lê di her rewşê de, tewra TCP jî her gav nikare we xilas bike. Demek her tiştî heye. Dibe ku tor tenê ji bo demekê têk bibe. Dibe ku ew tenê bibiriqîne. Û ev hemî rê dide vê yekê ku hûn nekarin xwe bispêrin pêbaweriya Torê. Cûdahiya sereke ev e ji nivîsandina serîlêdanên paralel ên ku li ser yek komputerê an li ser yek superkomputerê dixebitin, li cihê ku Tor tune ye, ku di bîranînê de otobusek pevguhertina daneyê pêbawertir heye. Û ev cûdahiyek bingehîn e.
Di nav tiştên din de, dema ku Torê bikar tînin, her dem derengiyek heye. Di dîskê de jî ew heye, lê Tora wê bêtir heye. Dereng wextek derengmayînê ye, ku dikare piçûk an pir girîng be.
Topolojiya torê diguhere. Topolojî çi ye - ev cîhkirina alavên torê me ye. Navendên daneyan hene, rafikên ku li wir radiwestin hene, mûm hene. Ev hemû dikarin ji nû ve bên girêdan, barkirin, hwd. Ev hemû jî divê li ber çavan bê girtin. Navên IP-ê diguhezin, rêça ku tê de seyrûsefera me tê guheztin. Ev jî divê li ber çavan bê girtin.
Dibe ku tor di warê alavan de jî biguhere. Ji pratîkê, ez dikarim bibêjim ku endezyarên torê yên me bi rastî hez dikin ku bi demkî tiştek li ser mûman nûve bikin. Ji nişkê ve firmwareyek nû derket û ew bi taybetî bi komek Hadoop re eleqedar nebûn. Karê wan heye. Ji bo wan, ya sereke ev e ku Tora kar dike. Li gorî vê yekê, ew dixwazin li wir tiştek ji nû ve bar bikin, li ser hardware xwe fîşekek bikin, û hardware jî dem bi dem diguhere. Pêdivî ye ku ev hemî bi rengekî were hesibandin. Hemî ev bandor li ser sepana meya belavkirî dike.
Bi gelemperî kesên ku ji ber hin sedeman dest bi xebata bi mîqdarên mezin ên daneyê dikin bawer dikin ku Înternet bêsînor e. Ger pelek çend terabyte li wir hebe, wê hingê hûn dikarin wê bibin ser server an komputera xwe û bi karanîna wê vekin pisîk û temaşe bikin. Çewtiyek din tê de ye Vim li qeydan binêre. Tu carî vê yekê nekin ji ber ku xirab e. Ji ber ku Vim hewl dide ku her tiştî tampon bike, her tiştî di bîranînê de bar bike, nemaze dema ku em dest bi vê têketinê dikin û li tiştek digerin. Ev tiştên ku têne jibîr kirin, lê hêjayî nirxandinê ne.
Ew hêsantir e ku meriv bernameyek ku li ser yek komputerê bi yek pêvajoyê re dixebite binivîse.
Dema ku pergala me mezin dibe, em dixwazin ku wê hemî paralel bikin, û ne tenê li ser komputerê, lê di heman demê de li ser komekê jî paralel bikin. Pirs çêdibe: meriv çawa vê mijarê hevrêz dike? Dibe ku serîlêdanên me jî bi hevûdu re têkilî nekin, lê me li ser gelek serveran çend pêvajo bi paralel meşandin. Û çawa çavdêriya ku her tişt ji bo wan baş e? Mînakî, ew li ser Înternetê tiştek dişînin. Pêdivî ye ku ew li cîhek li ser dewleta xwe binivîsin, mînakî, di celebek databas an têketinê de, paşê vê têketinê berhev bikin û dûv re li cîhek analîz bikin. Zêdeyî, pêdivî ye ku em bihesibînin ku pêvajo dixebitî û dixebitî, ji nişkê ve hin xeletiyek tê de xuya bû an jî têk çû, wê hingê em ê çiqas zû pê zanibin?
Eşkere ye ku ev hemû zû dikarin werin şopandin. Ev jî baş e, lê çavdêrî tiştek sînorkirî ye ku dihêle hûn hin tiştan di asta herî bilind de bişopînin.
Dema ku em dixwazin pêvajoyên me bi hevûdu re dest pê bikin, mînakî, hin daneyan ji hev re bişînin, wê hingê pirs jî derdikeve holê - ev ê çawa bibe? Ma dê celebek rewşek nijadê hebe, gelo ew ê hevûdu binivîsînin, dê dane rast bigihîjin, dê di rê de tiştek winda bibe? Pêdivî ye ku em celebek protokolek pêşve bibin û hwd.
Koordînasyona van hemû pêvajoyan ne tiştekî biçûk e. Û ew pêşdebir neçar dike ku dakeve astek hîn kêmtir, û pergalên ji sifirê, an jî ne tam ji sifrê binivîsîne, lê ev ne ew çend hêsan e.
Ger hûn algorîtmayek krîptografîk derxînin an jî wê bicîh bikin, wê gavê wê bavêjin, ji ber ku bi îhtîmalek mezin ew ê ji we re nexebite. Ew ê bi îhtîmalek mezin komek xeletiyên ku we ji bîr kiriye ku ji wan re peyda bikin vehewîne. Tu carî wê ji bo tiştek cidî bikar neynin ji ber ku bi îhtîmalek mezin ew ê bêhêz be. Ji ber ku hemî algorîtmayên ku hene ji bo demek pir dirêj ji hêla demê ve hatine ceribandin. Ew ji hêla civakê ve tê şermezar kirin. Ev mijareke cuda ye. Û li vir jî wisa ye. Heke ne gengaz e ku hûn bi xwe cûreyek hevrêzkirina pêvajoyê bicîh bînin, wê hingê çêtir e ku hûn wiya nekin, ji ber ku ew pir tevlihev e û we di rêça şikestî ya lêgerîna domdar a xeletiyan de dihêle.
Îro em li ser ZooKeeper dipeyivin. Ji aliyekî ve, ew çarçoveyek e, ji hêla din ve, ew karûbarek e ku jiyanê ji pêşdebiran re hêsantir dike û pêkanîna mantiq û hevrêziya pêvajoyên me bi qasî ku gengaz hêsan dike.
Werin em bînin bîra xwe ku dibe ku pergalek belavbûyî ya standard çawa xuya bike. Ya ku me li ser axivî ev e - HDFS, HBase. Pêvajoyek Master heye ku pêvajoyên karker û koleyan birêve dibe. Ew ji hevrêzkirin û belavkirina karan, ji nû ve destpêkirina karkeran, destpêkirina yên nû, û belavkirina bargiraniyê berpirsiyar e.
Tiştek pêşkeftî Karûbarê Koordînasyonê ye, ango, peywira hevrêziyê bi xwe veguhezîne pêvajoyek cihê, û bi hev re hin celebek Mastera paşvegirtinê an stanby bimeşîne, ji ber ku dibe ku Master têk biçe. Û heke Mamoste bikeve, wê hingê pergala me dê nexebite. Em paşvekişandinê dimeşînin. Hin diyar dikin ku pêdivî ye ku Master ji bo hilanînê were dubare kirin. Ev jî dikare bê spartin Servîsa Koordînasyonê. Lê di vê diagramê de, Mamoste bi xwe ji bo koordînasyona karkeran li vir karûbar çalakiyên dubarekirina daneyan hevrêz dike.
Vebijarkek pêşkeftî ev e ku gava ku hemî hevrêzî ji hêla karûbarê me ve tê rêve kirin, wekî ku bi gelemperî tête kirin. Ew berpirsiyariyê digire ku pê ewle bibe ku her tişt dixebite. Û heke tiştek nexebite, em li ser wê fêr dibin û hewl didin ku li dora vê rewşê bisekinin. Di her rewşê de, em bi Masterek re dimînin ku bi rengek bi koleyan re têkilî dike û dikare bi hin karûbaran dane, agahdarî, peyam û hwd bişîne.
Planek hîn pêşkeftîtir heye, dema ku me Masterek tune be, hemî girêk xulamên master in, di tevgera xwe de cûda ne. Lê ew hîn jî hewce ne ku bi hevûdu re têkilî daynin, ji ber vê yekê hîn jî hin karûbar maye ku van çalakiyan hevrêz bike. Dibe ku, Cassandra, ku li ser vê prensîbê dixebite, bi vê planê ve girêdayî ye.
Zehmet e ku meriv bêje kîjan ji van planan çêtir dixebite. Her yek baş û nebaşiyên xwe hene.
Û ne hewce ye ku meriv ji hin tiştan bi Mamoste re bitirse, ji ber ku, wekî pratîkê nîşan dide, ew ew qas ne mumkun e ku bi domdarî xizmet bike. Ya sereke li vir ev e ku meriv çareseriya rast ji bo mazûvaniya vê karûbarê li ser girêkek hêzdar a cihêreng hilbijêrin, da ku ew xwedan çavkaniyên têr be, da ku heke gengaz be, bikarhêner negihîjin wir, da ku ew bi xeletî vê pêvajoyê nekujin. Lê di heman demê de, di nexşeyek weha de birêvebirina xebatkarên ji pêvajoya Master pir hêsantir e, ango ev plan ji hêla bicîhkirinê ve hêsan e.
Û ev plana (li jor) belkî tevlihevtir e, lê pêbawertir e.
Pirsgirêka sereke têkçûna qismî ye. Mînakî, dema ku em li ser Torê peyamek dişînin, qezayek çêdibe, û yê ku peyam şandiye nizane ka peyama wî hatiye wergirtin û çi ji aliyê wergir ve bûye, dê nizanibe ka peyam rast hatiye pêvajo kirin. , yanî ew ê tu tesdîqekê wernegire.
Li gorî vê divê em vê rewşê bişopînin. Û ya herî hêsan ev e ku em vê peyamê ji nû ve bişînin û li bendê bimînin heya ku em bersivek bistînin. Di vê rewşê de, nayê hesibandin ka rewşa wergirê guherî an na. Dibe ku em peyamek bişînin û heman daneyê du caran lê zêde bikin.
ZooKeeper awayên mijûlbûna bi redkirina weha re pêşkêş dike, ku ev jî jiyana me hêsantir dike.
Wekî ku hinekî berê hate behs kirin, ev dişibihe nivîsandina bernameyên pir-mijarî, lê ciyawaziya sereke ev e ku di serîlêdanên belavkirî yên ku em li ser makîneyên cihêreng ava dikin de, yekane awayê ragihandinê Tora ye. Di bingeh de, ev mîmariyek hevpar-tiştek e. Her pêvajo an karûbarek ku li ser yek makîneyê dimeşîne bîranîna xwe, dîska xwe, pêvajoya xwe heye, ku ew bi kesî re parve nake.
Ger em li ser yek kompîturê bernameyek pir-têl binivîsin, wê hingê em dikarin bîranîna hevpar bikar bînin da ku daneyan biguhezînin. Li wir guheztinek me heye, pêvajo dikare biguhere. Ev bandorê li performansê dike. Ji aliyekî ve, di bernameyê de li ser komekê tiştek wusa tune, lê bi Torê re pirsgirêk hene.
Li gorî vê yekê, pirsgirêkên sereke yên ku di dema nivîsandina pergalên belavkirî de derdikevin holê, veavakirin in. Em cûreyek serîlêdanê dinivîsin. Ger ew hêsan be, wê hingê em her cûre hejmaran di kodê de kod dikin, lê ev nerehet e, ji ber ku heke em biryar bidin ku li şûna demajoya nîv saniyeyê em demeka yek saniyeyê dixwazin, wê hingê pêdivî ye ku em serîlêdanê ji nû ve berhev bikin û dîsa her tiştî derxe. Gava ku ew li ser yek makîneyê ye, gava ku hûn dikarin wê ji nû ve bidin destpêkirin yek tişt e, lê gava ku gelek makîneyên me hene, divê em bi domdarî her tiştî kopî bikin. Divê em hewl bidin ku serîlêdanê mîhengbar bikin.
Li vir em li ser veavakirina statîk ji bo pêvajoyên pergalê diaxivin. Ev ne bi tevahî ye, dibe ku ji hêla pergala xebitandinê ve, dibe ku ew ji bo pêvajoyên me veavakirinek statîk be, ango ev veavakirinek e ku bi tenê nayê girtin û nûvekirin.
Di heman demê de veavakirinek dînamîkî jî heye. Vana parametreyên ku em dixwazin di firînê de biguhezînin da ku ew li wir werin hilanîn.
Pirsgirêka li vir çi ye? Me konfigurasyon nûve kir, ew derxist, lewra çi? Dibe ku pirsgirêk ev be ku ji aliyekî ve me konfigurasyon derxist, lê tiştê nû ji bîr kir, konfigurasyon li wir ma. Ya duyemîn, dema ku me derdixist, veavakirin li hin deveran hate nûve kirin, lê ne li yên din. Û hin pêvajoyên serîlêdana me yên ku li ser yek makîneyê têne xebitandin bi konfigurasyonek nû, û li cîhek bi yekî kevn ji nû ve hatin destpêkirin. Ev dikare bibe sedem ku serîlêdana meya belavkirî ji perspektîfa veavakirinê de nehevgirtî be. Ev pirsgirêk hevpar e. Ji bo veavakirinek dînamîkî, ew bêtir têkildar e ji ber ku ew tê vê wateyê ku ew di firînê de dikare were guheztin.
Pirsgirêkek din jî endamtiya komê ye. Her tim hin xebatkarên me hene, em her gav dixwazin bizanibin ka kîjan ji wan sax e, kî ji wan mirî ye. Ger Masterek hebe, wê hingê divê ew fêm bike ka kîjan karker dikarin ji xerîdaran re werin veguheztin da ku ew hesaban bimeşînin an bi daneyan re bixebitin, û kîjan nekare. Pirsgirêkek ku bi berdewamî derdikeve ev e ku divê em zanibin ka kî di koma me de dixebite.
Pirsgirêkek din a tîpîk hilbijartinên serokan e, dema ku em dixwazin bizanibin kî berpirsiyar e. Mînakek dubarekirin e, dema ku me pêvajoyek heye ku operasyonên nivîsandinê distîne û dûv re wan di nav pêvajoyên din de dubare dike. Ew ê bibe rêber, yên din dê guh bidin wî, dê li pey wî bin. Pêdivî ye ku pêvajoyek were hilbijartin ku ew ji bo herkesî nezelal be, da ku nehêle ku du serok werin hilbijartin.
Di heman demê de gihîştina hevûdu jî heye. Pirsgirêk li vir tevlihevtir e. Tiştek wekî mutex heye, dema ku hûn bernameyên pir-mijal dinivîsin û dixwazin bigihîjin hin çavkaniyek, wek mînak, şaneyek bîranînê, ku tenê ji hêla yek têlan ve were sînorkirin û bicîh kirin. Li vir çavkanî dikare tiştek bêtir razber be. Û serîlêdanên cihêreng ên ji girêkên cihêreng ên Tora me divê tenê bigihîjin çavkaniyek diyarkirî, û ne ku her kes bikaribe wê biguhezîne an li wir tiştek binivîse. Ev bi navê kilît in.
ZooKeeper destûrê dide te ku hûn van pirsgirêkan bi yek dereceyek an din çareser bikin. Û ez ê bi mînakan nîşan bidim ka ew çawa dihêle hûn vê yekê bikin.
primitives astengker tune. Dema ku em dest bi karanîna tiştek dikin, ev primitive dê li benda rûdana bûyerek nemîne. Bi îhtîmalek mezin, ev tişt dê bi asynkronî bixebite, bi vî rengî rê dide pêvajoyên ku dema ku ew li benda tiştekê ne rawestin. Ev tiştek pir bikêr e.
Hemî daxwazên xerîdar di rêza rêza giştî de têne kirin.
Û xerîdar fersenda wan heye ku di derheqê guhertinên di hin dewletan de, di derheqê guheztinên daneyan de, agahdarî bistînin, berî ku xerîdar daneyên guhertî bixwe bibîne.
ZooKeeper dikare bi du awayan bixebite. Ya yekem serbixwe ye, li ser yek girêkê. Ev ji bo ceribandinê guncan e. Ew dikare di moda klusterê de jî, li ser her hejmarek girêkan bixebite. pêşkêşkerênEger komeke me ya 100 makîneyan hebe, ne hewce ye ku ew li ser 100 makîneyan bixebite. Têra xwe ye ku çend makîneyan li cihê ku ZooKeeper dikare bixebite werin veqetandin. Û ew bi prensîba berdestbûna bilind ve girêdayî ye. ZooKeeper li ser her mînaka xebitandinê kopiyek tevahî ya daneyan hilîne. Ez ê paşê rave bikim ka ew çawa vê yekê dike. Ew daneyan parçe nake an jî parve nake. Ji aliyekî ve, ev dezavantajek e ji ber ku em nikarin pir tiştî hilînin, lê ji aliyê din ve, ne hewce ye. Ew ji bo wê nehatiye sêwirandin; ew ne databasek e.
Daneyên dikarin li aliyê muwekîlê cache. Ev prensîbek standard e da ku em karûbarê qut nekin û wê bi heman daxwazan bar nekin. Xerîdarek jîr bi gelemperî bi vê yekê dizane û wê vedigire.
Ji bo nimûne, tiştek li vir guhertin. Cûreyek serîlêdanê heye. Serkirdeyekî nû hat hilbijartin, ku ji bo nimûne, ji bo pêkanîna operasyonên nivîsandinê berpirsiyar e. Û em dixwazin daneyan dubare bikin. Yek çareserî ew e ku meriv wê bikeve nav pêlekê. Û em bi berdewamî xizmeta xwe dipirsin - ma tiştek guherî? Vebijarka duyemîn çêtir e. Ev mekanîzmayek temaşe ye ku dihêle hûn xerîdaran agahdar bikin ku tiştek guherî ye. Ev di warê çavkaniyan de rêbazek kêmtir biha ye û ji bo xerîdaran rehettir e.
Xerîdar ew bikarhêner e ku ZooKeeper bikar tîne.
Server pêvajoya ZooKeeper bixwe ye.
Znode di ZooKeeper de tiştê sereke ye. Hemî znode ji hêla ZooKeeper ve di bîranînê de têne hilanîn û di forma diyagramek hiyerarşîk, di forma darekê de têne organîze kirin.
Du cureyên operasyonê hene. Ya yekem nûvekirin/nivîsandin e, dema ku hin operasyon rewşa dara me diguhezîne. Dara hevpar e.
Û mimkun e ku xerîdar yek daxwazek temam neke û jê qut bibe, lê dikare danişînek saz bike ku tê de bi ZooKeeper re têkilî daynin.
Modela daneya ZooKeeper dişibe pergala pelan. Rokek standard heye û dûv re em mîna pelrêçiyên ku ji kokê diçin derbas bûn. Û paşê kataloga asta yekem, asta duyemîn. Ev hemû znodes e.
Her znode dikare hin daneyan hilîne, bi gelemperî ne pir mezin, mînakî 10 kilobytes. Û her znode dikare hejmarek zarokan hebe.
Znodes di çend celeban de têne. Ew dikarin bêne afirandin. Û dema ku znode diafirînin, em celebê ku divê jê re be diyar dikin.
Du cure hene. Yekem ala efemeral e. Znode di nav danişînê de dijî. Mînakî, xerîdar rûniştinek ava kiriye. Û heta ku ev danişîn sax be, wê hebe. Ji bo ku tiştek nehewce neyê hilberandin ev pêdivî ye. Ev di heman demê de ji bo demên ku ji me re girîng e ku em primitives daneyan di nav danişînê de hilînin jî maqûl e.
Cureya duyemîn ala rêzdar e. Ew li ser riya znodê jimarvan zêde dike. Mînakî, me pelrêçek bi serîlêdana 1_5 re hebû. Û gava ku me girêka yekem çêkir, wê p_1, ya duyemîn - p_2 wergirt. Û gava ku em her carê bangî vê rêbazê dikin, em riya tevahî derbas dikin, ku tenê beşek rê nîşan dide, û ev hejmar bixweber zêde dibe ji ber ku em celebê girêk - rêzdar destnîşan dikin.
Znode bi rêkûpêk. Ew ê her dem bijî û navê ku em jê re dibêjin hebe.
Tiştek din a kêrhatî ala demjimêrê ye. Ger em wê saz bikin, wê hingê xerîdar dikare ji bo girêkek taybetî beşdarî hin bûyeran bibe. Ez ê paşê bi mînakek nîşanî we bidim ka ev çawa tê kirin. ZooKeeper bixwe xerîdar agahdar dike ku daneyên li ser girêk guherî. Lêbelê, agahdarî garantî nakin ku hin daneyên nû hatine. Ew tenê dibêjin ku tiştek guherî ye, ji ber vê yekê hûn hîn jî pêdivî ye ku daneyan paşê bi bangên cihêreng bidin ber hev.
Û wek ku min berê jî got, rêza daneyan bi kilobytes tê destnîşankirin. Ne hewce ye ku daneyên nivîsê yên mezin li wir hilînin, ji ber ku ew ne databasek e, ew serverek hevrêziya çalakiyê ye.
Bila ez hinekî li ser danişînan ji we re vebêjim. Ger çend serverên me hebin, em dikarin bi awayekî zelal ji serverekê derbasî yekî din bibin. server, bi karanîna ID-ya danişînê. Ev pir hêsan e.
Di her danişînê de cûreyek demek heye. Rûniştinek ji hêla ku xerîdar di wê danişînê de tiştek ji serverê re dişîne tê destnîşankirin. Ger wî di dema wextê de tiştek negotibe, danişîn têk diçe, an jî xerîdar dikare wê bixwe bigire.
Ew çend taybetmendiyên wê tune, lê hûn dikarin bi vê API-ê re tiştên cûda bikin. Ew banga ku me dît ku çêkir znode diafirîne û sê parameteran digire. Ev riya znodê ye, û divê ew bi tevahî ji kokê ve were diyar kirin. Û her weha ev hin daneyên ku em dixwazin li wir veguhezînin. Û cureyê alê. Û piştî afirandinê rê li znodê vedigerîne.
Ya duyemîn, hûn dikarin wê jêbirin. Li vir hîle ev e ku pîvana duyemîn, ji bilî riya znode, dikare guhertoyê diyar bike. Li gorî vê yekê, ew znode dê were jêbirin heke guhertoya wê ya ku me veguhezandiye bi ya ku bi rastî heye wekhev be.
Ger em naxwazin vê guhertoyê kontrol bikin, wê hingê em bi tenê argumana "-1" derbas dikin.
Ya sêyemîn, ew hebûna znode kontrol dike. Ger girêk hebe rast vedigere, wekî din xelet.
Û dûv re demjimêra ala xuya dike, ku dihêle hûn çavdêriya vê nodê bikin.
Hûn dikarin vê alê jî li ser girêkek neheyî destnîşan bikin û gava ku ew xuya bibe agahdariyek bistînin. Ev jî dikare bikêr be.
Çend zehmetiyên din jî hene getData. Eşkere ye ku em dikarin daneyan bi rêya znode bistînin. Her weha hûn dikarin demjimêra ala bikar bînin. Di vê rewşê de, heke girêk tune be, ew ê saz neke. Ji ber vê yekê, hûn hewce ne ku hûn fêm bikin ku ew heye, û paşê daneyê bistînin.
Her weha heye SetData. Li vir em versiyonê derbas dikin. Û heke em vê yekê derbas bikin, dê daneyên li ser znode ya guhertoyek diyar were nûve kirin.
Her weha hûn dikarin "-1" destnîşan bikin ku vê kontrolê derxînin.
Rêbazek din a kêrhatî ye getChildren. Di heman demê de em dikarin navnîşek hemî znodên ku girêdayî wê ne jî bistînin. Em dikarin vê yekê bi danîna demjimêra alê bişopînin.
Û rêbaz senkronîze dihêle ku hemî guhertin bi yekcarî werin şandin, bi vî rengî piştrast dike ku ew têne tomar kirin û hemî dane bi tevahî hatine guhertin.
Ger em bi bernamesaziya kevneşopî re analojiyan xêz bikin, wê hingê gava ku hûn rêbazên wekî nivîsandinê bikar tînin, yên ku tiştek li ser dîskê dinivîsin, û piştî ku ew bersivek ji we re vedigerîne, garantiyek tune ku we dane li ser dîskê nivîsandiye. Û tewra gava ku pergala xebitandinê pê bawer e ku her tişt hatiye nivîsandin, di dîskê de mekanîzmayên ku pêvajo di nav qatên tamponan de derbas dibe hene, û tenê piştî wê daneyê li ser dîskê tê danîn.
Bi piranî bangên asynkron têne bikar anîn. Ev dihêle ku xerîdar bi daxwazên cûda re paralel bixebite. Hûn dikarin nêzîkatiya hevdemî bikar bînin, lê ew kêm berhemdar e.
Du operasyonên ku me behsa wan kir nûvekirin/nivîsandin in, ku daneyan diguherînin. Ev têne çêkirin, danînData, hevdengkirin, jêbirin. Û xwendin heye, getData, getChildren.
Naha çend mînakên ku hûn çawa dikarin ji bo xebata di pergalek belavkirî de primitives çêbikin. Mînakî, bi veavakirina tiştekî ve girêdayî ye. Karkerek nû derketiye holê. Me makîneyê lê zêde kir û dest bi pêvajoyê kir. Û sê pirsên jêrîn hene. Meriv çawa li ZooKeeper ji bo veavakirinê dipirse? Û eger em bixwazin veavakirinê biguherînin, emê çawa wê biguherînin? Û piştî ku me ew guherand, ew karkerên ku me hebûn wê çawa digirin?
ZooKeeper vê yekê bi hêsanî hêsan dike. Mînak dara me ya znodê heye. Li vir ji bo serîlêdana me girêkek heye, em tê de girêkek din ava dikin, ku daneyên ji veavakirinê vedihewîne. Dibe ku ev parametreyên cuda bin an nebin. Ji ber ku mezinahî piçûk e, mezinahiya veavakirinê bi gelemperî piçûk e jî, ji ber vê yekê pir gengaz e ku ew li vir were hilanîn.
Hûn rêbazê bikar tînin getData ji bo ku veavakirina ji bo karker ji girêbide. Li ser rastîn danîn. Ger ji ber hin sedeman ev girêk tunebe, dema xuya bibe, an jî dema ku were guhertin em ê jê agahdar bibin. Ger em dixwazin zanibin ku tiştek guheriye, wê hingê em wê rast bikin. Û heger daneyên di vê nodê de biguherînin, em ê li ser wê bizanibin.
SetData. Em daneyan destnîşan dikin, "-1" danîne, ango em guhertoyê kontrol nakin, em texmîn dikin ku me her gav yek veavakirinê heye, ne hewce ye ku em gelek mîhengan hilînin. Heke hûn hewce ne ku pir hilînin, hûn ê hewce bikin ku astek din lê zêde bikin. Li vir em bawer dikin ku tenê yek heye, ji ber vê yekê em tenê ya herî paşîn nûve dikin, ji ber vê yekê em guhertoyê kontrol nakin. Di vê gavê de, hemî xerîdarên ku berê bûne abone agahiyek werdigirin ku tiştek di vê nodê de guheriye. Û piştî ku wan ew stand, divê ew jî dîsa daneyan daxwaz bikin. Agahdarî ev e ku ew daneyan bi xwe nagirin, lê tenê agahdariya guhertinan digirin. Piştî vê yekê divê ew daneyên nû bipirsin.
Vebijarka duyemîn ji bo karanîna primitive e endametiya komê. Serlêdanek me ya belavkirî heye, komek karker hene û em dixwazin fam bikin ku ew hemî di cîh de ne. Ji ber vê yekê, divê ew xwe qeyd bikin ku ew di serlêdana me de dixebitin. Û em jî dixwazin, an ji pêvajoya Masterê an jî cîhek din, li ser hemî xebatkarên çalak ên ku em niha hene fêr bibin.
Em çawa vê yekê bikin? Ji bo serîlêdanê, em girêkek karkeran diafirînin û bi karanîna rêbaza afirandinê li wir bineastek zêde dikin. Li ser slaytê xeletiyek min heye. Li vir hûn hewce ne rêzikî diyar bike, wê demê dê hemû karker yek bi yek werin afirandin. Û serîlêdan, ku hemî daneyên li ser zarokên vê nodê daxwaz dike, hemî xebatkarên çalak ên ku hene distîne.
Ev pêkanînek wusa tirsnak e ku meriv çawa dikare di koda Java-yê de were kirin. Ka em ji dawiyê, bi rêbaza sereke dest pê bikin. Ev çîna me ye, em rêbaza wê biafirînin. Wekî argumana yekem em mêvandar bikar tînin, cihê ku em lê girêdidin, ango em wê wekî arguman destnîşan dikin. Û argumana duyemîn navê komê ye.
Têkilî çawa dibe? Ev mînakek hêsan a API-ya ku tê bikar anîn e. Li vir her tişt bi hêsanî hêsan e. Çîna standard ZooKeeper heye. Em hosteyan jê re derbas dikin. Û ji bo nimûne, dema wextê 5 çirkeyan destnîşan bikin. Û me endamek bi navê connectSignal heye. Di bingeh de, em li ser riya veguheztinê komekê diafirînin. Em li wir daneyan nanivîsin, her çend tiştek dikaribû bihata nivîsandin. Û girêka li vir ji celebê domdar e. Di bingeh de, ev girêkek asayî ya asayî ye ku dê her dem hebe. Li vir rûniştin tê çêkirin. Ev pêkanîna muwekîlê bi xwe ye. Muwekîlê me dê dem bi dem rapor bike ku danişîn zindî ye. Û gava ku em danişînê bi dawî dikin, em bang dikin û ew e, danişîn têk diçe. Ev di rewşek e ku tiştek ji me re têk diçe, da ku ZooKeeper li ser wê zanibe û danişînê qut bike.
Meriv çawa çavkaniyek kilît dike? Li vir her tişt hinekî tevlihevtir e. Komek karkerên me hene, hin çavkaniyek ku em dixwazin kilît bikin heye. Ji bo vê yekê, em girêkek veqetandî ava dikin, mînakî, bi navê lock1. Ger me karibûya wê biafiranda, wê demê me li vir qeflek girt. Û heke me nikarîbû wê biafiranda, wê gavê xebatkar hewl dide ku getData ji vir bistîne, û ji ber ku girêk jixwe hatî afirandin, wê hingê em çavdêrek li vir datînin û gava ku rewşa vê girêk biguhere, em ê pê zanibin. Û em dikarin hewl bidin ku dem hebe ku wê ji nû ve biafirînin. Ger me ev girêk hilda, ev qefle girt, wê hingê piştî ku êdî hewcedariya me bi qeflê nema, em ê dev jê berdin, ji ber ku girêk tenê di nav danişînê de heye. Li gorî vê, wê winda bibe. Û xerîdarek din, di çarçoweya danişînek din de, dê bikaribe qefilê li ser vê girêkê bigire, an bêtir, ew ê agahdariyek werbigire ku tiştek guherî ye û ew dikare hewl bide ku wê di wextê de bike.
Mînakek din ku hûn çawa dikarin rêberê sereke hilbijêrin. Ev hinekî tevlihevtir e, lê di heman demê de bi hêsanî hêsan e. Li vir çi diqewime? Nodek sereke heye ku hemî karkeran kom dike. Em hewl didin ku daneyên li ser rêber bigirin. Ger ev yek bi serketî bû, ango me hin dane wergirtin, wê hingê xebatkarê me dest bi şopandina vî rêberî dike. Ew bawer dike ku jixwe serokek heye.
Ger rêber ji ber hin sedeman mir, mînakî ji holê rabû, wê hingê em hewl didin ku rêberek nû biafirînin. Û eger em bi ser bikevin, wê demê karkerê me dibe rêber. Û heger kesek di vê gavê de karî rêberek nû biafirîne, wê hingê em hewl didin ku fêm bikin ka ew kî ye û dûv re wî bişopînin.
Li vir bandora keriyê ku jê re tê gotin bandora keriyê derdikeve holê, ji ber ku dema rêberek bimire, yê ku di wextê de yekem be dê bibe rêber.
Dema ku çavkaniyek digirin, hûn dikarin hewl bidin ku nêzîkatiyek piçûktir bikar bînin, ku li jêr e. Mînakî, em dixwazin kilîtekê bistînin, lê bêyî bandora hert. Ew ê di rastiyê de pêk were ku serîlêdana me navnîşên hemî nasnameyên girêk ji bo girêkek heyî ya bi kilît daxwaz dike. Û heke berî wê girêka ku me jê re kilît çêkiriye ji koma ku me wergirtiye ya herî piçûk be, wê hingê ev tê vê wateyê ku me kilît girtiye. Em kontrol dikin ku me qeflek wergirtiye. Wekî kontrol, dê şertek hebe ku nasnameya ku me di dema çêkirina qeflek nû de wergirtiye hindik be. Û heke me ew wergirt, wê hingê em bêtir dixebitin.
Ger nasnameyek ku ji qefleya me piçûktir e hebe, wê hingê em çavdêrek li ser vê bûyerê dihêlin û li benda agahdarkirinê ne heya ku tiştek biguheze. Yanî me ev qefle stand. Û heta ku ew nekeve, em ê nebin nasnameya herî kêm û qefila herî kêm nestînin, û bi vî rengî em ê karibin têkevinê. Û eger ev merc pêk neyê, wê demê em tavilê diçin vir û hewl didin ku vê qeflê dîsa bi dest bixin, ji ber ku di vê demê de dibe ku tiştek guherî.
ZooKeeper ji çi pêk tê? 4 tiştên sereke hene. Ev pêvajoyên pêvajoyê ye - Daxwaz. Û her weha Weşana Atomî ya ZooKeeper. Têketinek Commit heye ku li wir hemî operasyon têne tomar kirin. Û DB-ya Di-memory Replicated bixwe, ango databasa xwe ya ku ev dara tevahî tê hilanîn.
Hêjayî gotinê ye ku hemî operasyonên nivîsandinê di Pêvajoya Daxwazkirinê re derbas dibin. Û operasyonên xwendinê rasterast diçin databasa nav-bîrê.
Database bixwe bi tevahî tê dubare kirin. Hemî mînakên ZooKeeper kopiyek bêkêmasî ya daneyan hilînin.
Ji bo ku piştî têkçûnek databasê were sererast kirin, têketinek Commit heye. Pratîka standard ev e ku berî ku dane bikeve nav bîrê, li wir tê nivîsandin da ku heke têk bibe, ev têketin were lîstin û rewşa pergalê were vegerandin. Û dîmenên demkî yên databasê jî têne bikar anîn.
ZooKeeper Atomic Broadcast tiştek e ku ji bo domandina daneyên dubarekirî tê bikar anîn.
ZAB di hundurê xwe de rêberek ji nihêrîna girêka ZooKeeper hildibijêre. Girtiyên din dibin şopdarên wê û ji wê hin çalakiyan hêvî dikin. Ger navnîşan werbigirin, ew hemî ji rêber re dişînin. Ew pêşî operasyonek nivîsandinê dike û dûv re li ser tiştê ku guherî ji şagirtên xwe re peyamek dişîne. Ev, bi rastî, pêdivî ye ku atomî were kirin, ango operasyona tomarkirin û weşana tevahiyê divê bi atomî were kirin, bi vî rengî hevgirtina daneyê garantî bike.
Ew tenê daxwazên nivîsandinê pêvajoyê dike. Karê wê yê sereke ev e ku ew operasyonê di nûvekirinek danûstendinê de vediguherîne. Ev daxwazek taybetî ye ku hatî çêkirin.
Û li vir hêjayî gotinê ye ku bêhêziya nûvekirinên ji bo heman operasyonê tê garantî kirin. Ew çi ye? Ev tişt, ger du caran were îdamkirin, wê heman rewş hebe, yanî daxwaz bi xwe naguhere. Û ev pêdivî ye ku were kirin da ku di rewşek qezayê de, hûn dikarin operasyonê ji nû ve bidin destpêkirin, bi vî rengî guheztinên ku di vê gavê de derketine paşde vegerînin. Di vê rewşê de, rewşa pergalê dê bibe heman, ango divê ne wusa be ku rêzek heman tiştan, mînakî, pêvajoyên nûvekirinê, rê li ber rewşên dawî yên pergalê yên cihêreng bigire.
Source: www.habr.com
