Ik stel foar dat jo it transkripsje lêze fan 'e lêzing "Hadoop. ZooKeeper" út 'e searje "Metoaden foar ferdielde ferwurking fan grutte folumes fan gegevens yn Hadoop"
Wat is ZooKeeper, syn plak yn it Hadoop-ekosysteem. Unwierheden oer ferspraat komputer. Diagram fan in standert ferdield systeem. Swierrichheid by it koördinearjen fan ferdielde systemen. Typyske koördinaasjeproblemen. De prinsipes efter it ûntwerp fan ZooKeeper. ZooKeeper data model. znode flaggen. Sesjes. Client API. Primitives (konfiguraasje, groepslidmaatskip, ienfâldige slûzen, liederferkiezing, beskoatteljen sûnder keppeleffekt). ZooKeeper arsjitektuer. ZooKeeper DB. ZAB. Fersyk handler.
Hjoed sille wy prate oer ZooKeeper. Dit ding is heul nuttich. It, lykas elk Apache Hadoop-produkt, hat in logo. It ferbyldet in man.
Dêrfoar hawwe wy it benammen oer hoe't gegevens dêr kinne wurde ferwurke, hoe't se se opslaan, dat is, hoe't jo se op ien of oare manier brûke en der op ien of oare manier mei wurkje. En hjoed wol ik in bytsje prate oer it bouwen fan ferdielde applikaasjes. En ZooKeeper is ien fan dy dingen wêrmei jo te ferienfâldigjen dizze saak. Dit is in soarte fan tsjinst dy't bedoeld is foar in soarte fan koördinaasje fan 'e ynteraksje fan prosessen yn ferdielde systemen, yn ferdielde applikaasjes.
It ferlet fan sokke applikaasjes wurdt alle dagen mear en mear, dêr giet ús kursus oer. Oan 'e iene kant kinne MapReduce en dit ready-made ramt jo dizze kompleksiteit nivellerje en de programmeur befrije fan it skriuwen fan primitiven lykas ynteraksje en koördinaasje fan prosessen. Mar oan de oare kant garandeart nimmen dat dat dochs net dien wurde sil. MapReduce of oare ready-made kaders net altyd folslein ferfange guon gefallen dy't net kinne wurde ymplemintearre mei help fan dit. Ynklusyf MapReduce sels en in boskje oare Apache-projekten; se binne feitlik ek ferspraat applikaasjes. En om it skriuwen makliker te meitsjen, skreaunen se ZooKeeper.
Lykas alle Hadoop-relatearre applikaasjes, waard it ûntwikkele troch Yahoo! It is no ek in offisjele Apache-applikaasje. It is net sa aktyf ûntwikkele as HBase. As jo nei JIRA HBase geane, dan binne d'r elke dei in boskje bugrapporten, in boskje útstellen om wat te optimalisearjen, d.w.s. it libben yn it projekt giet konstant troch. En ZooKeeper, oan 'e iene kant, is in relatyf ienfâldich produkt, en oan' e oare kant, dit soarget foar syn betrouberens. En it is frij maklik te brûken, en dêrom is it in standert wurden yn applikaasjes binnen it Hadoop-ekosysteem. Dat ik tocht dat it nuttich wêze soe om it te besjen om te begripen hoe't it wurket en hoe it te brûken.
Dit is in foto fan in lêzing dy't wy hiene. Wy kinne sizze dat it ortogonaal is foar alles dat wy oant no ta hawwe beskôge. En alles dat hjir wurdt oanjûn, yn ien of oare graad, wurket mei ZooKeeper, dat wol sizze, it is in tsjinst dy't al dizze produkten brûkt. Noch HDFS noch MapReduce skriuwe har eigen ferlykbere tsjinsten dy't spesifyk foar har soene wurkje. Dêrtroch wurdt ZooKeeper brûkt. En dit simplifies ûntwikkeling en guon dingen yn ferbân mei flaters.
Wêr komt dit alles wei? It soe lykje dat wy twa applikaasjes parallel lansearre op ferskate kompjûters, ferbûn se mei in tekenrige of yn in gaas, en alles wurket. Mar it probleem is dat it Netwurk ûnbetrouber is, en as jo it ferkear snuffelen of sjoen hawwe wat der op in leech nivo bart, hoe't kliïnten ynteraksje op it Netwurk, kinne jo faaks sjen dat guon pakketten ferlern binne of opnij ferstjoerd wurde. It is net foar neat dat TCP-protokollen waarden útfûn, wêrtroch jo in bepaalde sesje kinne fêstigje en de levering fan berjochten garandearje. Mar yn alle gefallen kin sels TCP jo net altyd rêde. Alles hat in time-out. It netwurk kin gewoan in skoft ôffalle. It kin gewoan knipperje. En dit alles liedt ta it feit dat jo net kinne fertrouwe op it netwurk dat betrouber is. Dit is it wichtichste ferskil út it skriuwen fan parallelle applikaasjes dy't rinne op ien kompjûter of op ien supercomputer, dêr't der gjin Netwurk, dêr't der in mear betroubere gegevens útwikseling bus yn it ûnthâld. En dit is in fûnemintele ferskil.
Under oare dingen, by it brûken fan it Netwurk, is d'r altyd in bepaalde latency. De skiif hat it ek, mar it Netwurk hat der mear fan. Wachttiid is wat fertragingstiid, dy't lyts as frij wichtich kin wêze.
De netwurktopology feroaret. Wat is topology - dit is de pleatsing fan ús netwurkapparatuer. D'r binne datasintra, d'r binne rekken dy't der steane, d'r steane kearsen. Dit alles kin wer ferbûn wurde, ferpleatst wurde, ensfh. Dit moat ek allegear rekken holden wurde. IP-nammen feroarje, de routing wêrtroch ús ferkear reizget feroaret. Dêr moat ek rekken mei hâlden wurde.
It netwurk kin ek feroarje yn termen fan apparatuer. Fan 'e praktyk kin ik sizze dat ús netwurk-yngenieurs echt graach periodyk wat op' e kearsen bywurkje. Ynienen kaam der in nije firmware út en se wiene net spesjaal ynteressearre yn wat Hadoop-kluster. Se hawwe har eigen wurk. Foar harren is it wichtichste dat it netwurk wurket. Dêrnjonken wolle se der wat opnij uploade, in bliksem dwaan op har hardware, en de hardware feroaret ek periodyk. Dit alles moat op ien of oare manier rekken holden wurde. Dit alles hat ynfloed op ús ferspraat applikaasje.
Gewoanlik leauwe minsken dy't om ien of oare reden begjinne te wurkjen mei grutte hoemannichten gegevens dat it ynternet limitless is. As d'r in bestân is fan ferskate terabytes, dan kinne jo it nei jo server of kompjûter nimme en it iepenje mei kat en sjoch. In oare flater is yn Vim sjoch nei de logs. Doch dit noait, om't it min is. Omdat Vim besiket te buffer alles, laden alles yn it ûnthâld, benammen as wy begjinne te bewegen troch dit log en sykje wat. Dit binne dingen dy't fergetten binne, mar it wurdich te beskôgjen.
It is makliker om ien programma te skriuwen dat rint op ien kompjûter mei ien prosessor.
As ús systeem groeit, wolle wy it allegear parallelisearje, en it net allinich op in kompjûter, mar ek op in kluster parallelisearje. De fraach ûntstiet: hoe te koördinearjen dizze saak? Us applikaasjes kinne net iens mei-inoar ynteraksje, mar wy hawwe ferskate prosessen parallel op ferskate servers útfierd. En hoe te kontrolearjen dat alles goed giet foar harren? Se stjoere bygelyks wat oer it ynternet. Se moatte earne oer har steat skriuwe, bygelyks yn in soarte fan databank of log, dan dit log aggregearje en dan earne analysearje. Plus, wy moatte rekken hâlde mei dat it proses wurke en wurke, ynienen ferskynde der in flater yn as it crashte, hoe fluch sille wy it dan witte?
It is dúdlik dat dit alles fluch kontrolearre wurde kin. Dit is ek goed, mar tafersjoch is in beheind ding wêrmei jo guon dingen op it heechste nivo kinne kontrolearje.
As wy wolle dat ús prosessen mei-inoar begjinne te omgean, bygelyks om inoar wat gegevens te stjoeren, dan komt ek de fraach - hoe sil dat barre? Komt der in soarte fan racebetingsten, sille se inoar oerskriuwe, komme de gegevens goed, sil der ûnderweis wat ferlern gean? Wy moatte in soarte fan protokol ûntwikkelje, ensfh.
Koördinaasje fan al dizze prosessen is net in triviale ding. En it twingt de ûntwikkelder om te gean del nei in noch leger nivo, en skriuw systemen itsij fan kratsje, of net hielendal fan kratsje, mar dit is net sa ienfâldich.
As jo mei in kryptografysk algoritme komme of sels implementearje, smyt it dan fuort fuort, om't it wierskynlik net foar jo sil wurkje. It sil nei alle gedachten in boskje flaters befetsje dy't jo fergetten hawwe te foarsjen. Brûk it noait foar wat serieus, om't it nei alle gedachten ynstabyl sil wêze. Omdat alle algoritmen dy't bestean binne hifke troch de tiid foar in hiel lange tiid. It wurdt bedoarn troch de mienskip. Dit is in apart ûnderwerp. En hjir is it itselde. As it mooglik is om sels in soarte fan prosessyngronisaasje net te realisearjen, dan is it better om dit net te dwaan, om't it frij yngewikkeld is en jo it wankele paad liedt fan konstant sykjen nei flaters.
Hjoed hawwe wy it oer ZooKeeper. Oan 'e iene kant is it in ramt, oan' e oare kant is it in tsjinst dy't it libben makliker makket foar de ûntwikkelder en de ymplemintaasje fan logika en koördinaasje fan ús prosessen safolle mooglik makket.
Lit ús ûnthâlde hoe't in standert ferspraat systeem der útsjen kin. Dit is wêr't wy oer praat hawwe - HDFS, HBase. D'r is in Master-proses dat arbeiders en slaveprosessen beheart. Hy is ferantwurdlik foar it koördinearjen en fersprieden fan taken, it werstarten fan arbeiders, it lansearjen fan nije en it fersprieden fan de lading.
In mear avansearre ding is de Koördinaasje Service, dat is, ferpleatse de koördinaasje taak sels yn in apart proses, plus rinne in soarte fan reservekopy of stanby Master parallel, omdat de Master kin mislearje. En as de Master falt, dan sil ús systeem net wurkje. Wy rinne backup. Guon steaten dat de Master moat wurde replikearre nei reservekopy. Dat kin ek opdroegen wurde oan de Koördinaasjetsjinst. Mar yn dit diagram is de Master sels ferantwurdlik foar it koördinearjen fan de arbeiders; hjir koördinearret de tsjinst gegevensreplikaasjeaktiviteiten.
In mear avansearre opsje is as alle koördinaasje wurdt behannele troch ús tsjinst, lykas gewoanlik dien wurdt. Hy nimt ferantwurdlikens om te soargjen dat alles wurket. En as wat net wurket, fine wy it en besykje om dizze situaasje te kommen. Yn alle gefallen binne wy oerbleaun mei in Master dy't op ien of oare manier ynteraksje mei slaven en kin troch guon tsjinst gegevens, ynformaasje, berjochten, ensfh.
D'r is in noch mear avansearre skema, as wy gjin Master hawwe, binne alle knooppunten masterslaven, ferskillend yn har gedrach. Mar se moatte noch mei elkoar omgean, dus der is noch wat tsjinst oer om dizze aksjes te koördinearjen. Wierskynlik, Cassandra, dy't wurket op dit prinsipe, past by dit skema.
It is lestich om te sizzen hokker fan dizze regelingen better wurket. Elk hat syn eigen foar- en neidielen.
En d'r is net nedich om bang te wêzen foar guon dingen mei de Master, om't, lykas de praktyk docht bliken, hy net sa gefoelich is om konstant te tsjinjen. It wichtichste ding hjir is om de juste oplossing te kiezen foar it hostjen fan dizze tsjinst op in aparte krêftige knooppunt, sadat it genôch boarnen hat, sadat as it mooglik is, brûkers dêr gjin tagong hawwe, sadat se dit proses net per ongelok deadzje. Mar tagelyk, yn sa'n skema is it folle makliker om wurknimmers út it Master-proses te behearjen, d.w.s. dit skema is ienfâldiger út it eachpunt fan útfiering.
En dit skema (boppe) is wierskynlik komplekser, mar betrouber.
It wichtichste probleem is foar in part mislearrings. Bygelyks, as wy in berjocht stjoere oer it Netwurk, bart der in soarte fan ûngelok, en dejinge dy't it berjocht stjoerde sil net witte oft syn berjocht ûntfongen is en wat der bard is oan 'e kant fan' e ûntfanger, sil net witte oft it berjocht goed is ferwurke , d.w.s. hy sil gjin befêstiging krije.
Dêrom moatte wy dizze situaasje ferwurkje. En it ienfâldichste is dit berjocht opnij te stjoeren en te wachtsjen oant wy in antwurd krije. Yn dit gefal wurdt net rekken holden oft de steat fan 'e ûntfanger is feroare. Wy kinne in berjocht stjoere en twa kear deselde gegevens tafoegje.
ZooKeeper biedt manieren om te gean mei sokke wegeringen, wat ek ús libben makliker makket.
Lykas in bytsje earder neamd, is dit gelyk oan it skriuwen fan multi-threaded programma's, mar it wichtichste ferskil is dat yn ferdielde applikaasjes dy't wy bouwe op ferskate masines, de ienige manier om te kommunisearjen is it Netwurk. Yn essinsje is dit in dielde-neat-arsjitektuer. Elk proses of tsjinst dat rint op ien masine hat in eigen ûnthâld, in eigen skiif, in eigen prosessor, dy't it mei gjinien dielt.
As wy in multi-threaded programma op ien kompjûter skriuwe, dan kinne wy dielde ûnthâld brûke om gegevens út te wikseljen. Wy hawwe dêr in kontekst switch, prosessen kinne switch. Dit beynfloedet prestaasjes. Oan de iene kant, der is net sa'n ding yn it programma op in kluster, mar der binne problemen mei it Netwurk.
Dêrtroch binne de wichtichste problemen dy't ûntsteane by it skriuwen fan ferspraat systemen konfiguraasje. Wy skriuwe in soarte fan applikaasje. As it ienfâldich is, dan hurdkodearje wy alle soarten nûmers yn 'e koade, mar dit is ûngemaklik, want as wy beslute dat wy ynstee fan in time-out fan in heale sekonde in time-out fan ien sekonde wolle, dan moatte wy de applikaasje opnij kompilearje en rôlje alles wer út. It is ien ding as it op ien masine is, as jo it gewoan opnij starte kinne, mar as wy in protte masines hawwe, moatte wy alles konstant kopiearje. Wy moatte besykje de applikaasje konfigurearber te meitsjen.
Hjir prate wy oer statyske konfiguraasje foar systeemprosessen. Dit is net hielendal, miskien út it eachpunt fan it bestjoeringssysteem, kin it in statyske konfiguraasje wêze foar ús prosessen, dat wol sizze dit is in konfiguraasje dy't net gewoan kin wurde nommen en bywurke.
D'r is ek in dynamyske konfiguraasje. Dit binne de parameters dy't wy op 'e flecht wolle feroarje, sadat se dêr wurde ophelle.
Wat is it probleem hjir? Wy hawwe de konfiguraasje bywurke, it útrôle, wat dan? It probleem kin wêze dat wy oan 'e iene kant de konfiguraasje útrôle, mar it nije ding fergetten, de konfiguraasje bleau dêr. Twads, wylst wy rôlje út, de konfiguraasje waard bywurke op guon plakken, mar net yn oaren. En guon prosessen fan ús applikaasje dy't op ien masine rinne, waarden opnij starte mei in nije konfiguraasje, en earne mei in âlde. Dit kin resultearje yn dat ús ferspraat applikaasje ynkonsistint is út in konfiguraasjeperspektyf. Dit probleem is mienskiplik. Foar in dynamyske konfiguraasje is it relevanter omdat it ymplisearret dat it kin wurde feroare op 'e flecht.
In oar probleem is groepslidmaatskip. Wy hawwe altyd wat set arbeiders, wy wolle altyd witte wa fan har libbet, wa fan har is dea. As der in Master is, dan moat hy begripe hokker arbeiders kinne wurde omlaat nei kliïnten sadat se berekkeningen útfiere of wurkje mei gegevens, en hokker net. In probleem dat hieltyd opkomt is dat wy witte moatte wa't yn ús kluster wurket.
In oar typysk probleem binne liedersferkiezings, as wy witte wolle wa't de baas is. Ien foarbyld is replikaasje, as wy wat proses hawwe dat skriuwoperaasjes ûntfangt en se dan ûnder oare prosessen replikearret. Hy sil de lieder wêze, elkenien sil him folgje, sil him folgje. It is needsaaklik om in proses te kiezen sadat it foar elkenien iendiel is, sadat it net docht dat twa lieders selektearre wurde.
D'r is ek ûnderling eksklusive tagong. It probleem hjir is komplekser. Der is sa'n ding as in mutex, as jo skriuwe multi-threaded programma en wolle tagong ta guon boarne, Bygelyks, in ûnthâld sel, wurde beheind en útfierd troch mar ien tried. Hjir kin de boarne wat abstrakter wêze. En ferskate applikaasjes fan ferskate knooppunten fan ús Netwurk moatte allinich eksklusive tagong krije ta in opjûne boarne, en net sadat elkenien it kin feroarje of dêr wat skriuwe. Dit binne de saneamde slûzen.
ZooKeeper lit jo al dizze problemen yn ien of oare graad oplosse. En ik sil mei foarbylden sjen litte hoe't it jo dit kin dwaan.
D'r binne gjin blokkearjende primitiven. As wy wat begjinne te brûken, sil dizze primitive net wachtsje op elk barren. Meast wierskynlik sil dit ding asynchronysk wurkje, wêrtroch prosessen net hingje kinne wylst se op wat wachtsje. Dit is in heul nuttich ding.
Alle oanfragen fan kliïnten wurde ferwurke yn 'e folchoarder fan' e algemiene wachtrige.
En kliïnten hawwe de kâns om notifikaasje te ûntfangen oer feroaringen yn guon steat, oer feroaringen yn gegevens, foardat de kliïnt de feroare gegevens sels sjocht.
ZooKeeper kin wurkje yn twa modi. De earste is standalone, op ien knooppunt. Dit is handich foar testen. It kin ek operearje yn klustermodus op elk oantal servers. As wy in kluster hawwe fan 100 masines, dan is it net nedich dat it wurket op 100 masines. It is genôch om ferskate masines te selektearjen wêr't jo ZooKeeper kinne útfiere. En it beliedt it prinsipe fan hege beskikberens. Op elke rinnende eksimplaar bewarret ZooKeeper in folsleine kopy fan 'e gegevens. Letter sil ik dy fertelle hoe't er it docht. It net shard gegevens of partition it. Oan 'e iene kant is it in minus dat wy net folle kinne opslaan, oan 'e oare kant is it net nedich om dit te dwaan. Dat is net wêrfoar it is ûntworpen, it is gjin databank.
Gegevens kinne wurde cache op 'e client kant. Dit is in standertprinsipe sadat wy de tsjinst net ûnderbrekke en it net laden mei deselde oanfragen. In tûke klant wit dit meastentiids en cache it.
Hjir is bygelyks wat feroare. Der is in soarte fan applikaasje. In nije lieder waard keazen, dy't bygelyks ferantwurdlik is foar it ferwurkjen fan skriuwoperaasjes. En wy wolle de gegevens replikearje. Ien oplossing is om it yn in loop te setten. En wy freegje ús tsjinst hieltyd ôf - is der wat feroare? De twadde opsje is better. Dit is in horloazjemeganisme wêrmei jo kliïnten kinne ynformearje dat der wat feroare is. Dit is in minder djoere metoade yn termen fan middels en handiger foar kliïnten.
Klant is de brûker dy't ZooKeeper brûkt.
Server is it ZooKeeper-proses sels.
Znode is it wichtichste ding yn ZooKeeper. Alle znodes wurde opslein yn it ûnthâld troch ZooKeeper en wurde organisearre yn 'e foarm fan in hiërargyske diagram, yn' e foarm fan in beam.
Der binne twa soarten operaasjes. De earste is bywurkje / skriuwe, as guon operaasje de steat fan ús beam feroaret. De beam is gewoan.
En it is mooglik dat de kliïnt ien fersyk net foltôget en is loskeppele, mar kin in sesje fêstigje wêrmei't it ynteraksje mei ZooKeeper.
ZooKeeper's gegevensmodel liket op in bestânsysteem. D'r is in standert root en dan gongen wy as troch de mappen dy't fan 'e root gean. En dan de katalogus fan it earste nivo, twadde nivo. Dit is allegear znodes.
Eltse znode kin bewarje guon gegevens, meastal net hiel grut, bygelyks, 10 kilobytes. En elke znode kin in bepaald oantal bern hawwe.
Znodes komme yn ferskate soarten. Se kinne makke wurde. En by it meitsjen fan in znode spesifisearje wy it type dêr't it by hearre moat.
Der binne twa soarten. De earste is de efemere flagge. Znode libbet binnen in sesje. Bygelyks, de kliïnt hat in sesje oprjochte. En salang't dizze sesje libbet, sil it bestean. Dit is nedich om net wat ûnnedich te meitsjen. Dit is ek geskikt foar mominten dat it wichtich is foar ús om gegevensprimitiven binnen in sesje op te slaan.
It twadde type is sekwinsjele flagge. It ferheget de teller op 'e wei nei de znode. Wy hienen bygelyks in map mei applikaasje 1_5. En doe't wy it earste knooppunt makken, krige it p_1, de twadde - p_2. En as wy elke kear dizze metoade neame, passe wy it folsleine paad troch, wat mar in part fan it paad oanjout, en dit nûmer wurdt automatysk ferhege om't wy it knooppunttype oanjaan - sekwinsjele.
Reguliere znode. Se sil altyd libje en de namme hawwe dy't wy har fertelle.
In oar nuttich ding is de horloazjeflagge. As wy it ynstallearje, dan kin de kliïnt abonnearje op guon eveneminten foar in spesifike knooppunt. Ik sil jo letter mei in foarbyld sjen litte hoe't dit dien wurdt. ZooKeeper sels meldt de kliïnt dat de gegevens op it knooppunt binne feroare. Notifikaasjes garandearje lykwols net dat guon nije gegevens binne oankaam. Se sizze gewoan dat der wat feroare is, dus jo moatte letter noch gegevens fergelykje mei aparte oproppen.
En sa't ik al sei, de folchoarder fan de gegevens wurdt bepaald troch kilobytes. Der is gjin needsaak om te bewarjen grutte tekst gegevens dêr, want it is gjin databank, it is in aksje koördinaasje tsjinner.
Ik sil jo in bytsje fertelle oer de sesjes. As wy meardere servers hawwe, dan kinne wy transparant ferpleatse fan server nei server mei de sesje-identifikaasje. It is hiel handich.
Elke sesje hat in soarte fan time-out. In sesje wurdt definiearre troch de fraach oft de kliïnt wat nei de tsjinner stjoert tidens dy sesje. As hy yn 'e time-out neat hat trochstjoerd, falt de sesje ôf, of kin de kliïnt it sels slute.
It hat net safolle funksjes, mar jo kinne ferskate dingen dwaan mei dizze API. Dy oprop we seagen meitsje skept in znode en nimt trije parameters. Dit is it paad nei de znode, en it moat folslein opjûn wurde fan 'e root. En ek dit is wat gegevens dy't wy dêr oerdrage wolle. En it type flagge. En nei skepping jout it it paad werom nei de znode.
Twadder kinne jo it wiskje. De trúk hjir is dat de twadde parameter, neist it paad nei de znode, de ferzje kin oantsjutte. Dêrnjonken sil dy znode wiske wurde as de ferzje dy't wy hawwe oerdroegen lykweardich is oan dejinge dy't eins bestiet.
As wy dizze ferzje net wolle kontrolearje, dan passe wy gewoan it argumint "-1".
Tredde, it kontrolearret foar it bestean fan in znode. Jout wier as it knooppunt bestiet, oars net wier.
En dan ferskynt flaggehorloazje, wêrtroch jo dizze knooppunt kinne kontrolearje.
Jo kinne dizze flagge sels ynstelle op in net-besteand knooppunt en in notifikaasje ûntfange as it ferskynt. Dit kin ek nuttich wêze.
In pear mear útdagings binne GetData. It is dúdlik dat wy gegevens kinne ûntfange fia znode. Jo kinne ek flaggehorloazje brûke. Yn dit gefal sil it net ynstallearje as d'r gjin knooppunt is. Dêrom moatte jo begripe dat it bestiet, en dan gegevens ûntfange.
Dêr is ek SetData. Hjir passe wy ferzje. En as wy dit trochjaan, wurde de gegevens op 'e znode fan in bepaalde ferzje bywurke.
Jo kinne ek "-1" opjaan om dizze kontrôle út te sluten.
In oare nuttige metoade is getChildren. Wy kinne ek in list krije fan alle znodes dy't derby hearre. Wy kinne dit kontrolearje troch it ynstellen fan flaggewacht.
En metoade Sync lit alle wizigingen yn ien kear ferstjoerd wurde, en soarget derfoar dat se bewarre wurde en alle gegevens folslein feroare binne.
As wy analogyen tekenje mei reguliere programmearring, dan as jo metoaden brûke lykas skriuwe, dy't wat op skiif skriuwe, en nei't it jo in antwurd jout, is d'r gjin garânsje dat jo de gegevens op skiif skreaun hawwe. En sels as it bestjoeringssysteem der wis fan is dat alles is skreaun, binne d'r meganismen yn 'e skiif sels wêr't it proses troch lagen fan buffers giet, en pas dêrnei wurde de gegevens op' e skiif pleatst.
Meast asynchrone oproppen wurde brûkt. Dit lit de kliïnt parallel wurkje mei ferskate oanfragen. Jo kinne de syngroane oanpak brûke, mar it is minder produktyf.
De twa operaasjes dêr't wy oer praat binne update / skriuwe, dy't gegevens feroarje. Dizze binne oanmeitsje, setData, syngronisearje, wiskje. En lêzen is bestiet, getData, getChildren.
No in pear foarbylden fan hoe't jo primitiven kinne meitsje foar wurkjen yn in ferspraat systeem. Bygelyks, yn ferbân mei de konfiguraasje fan wat. Der is in nije arbeider ferskynde. Wy tafoege de masine en begûn it proses. En d'r binne de folgjende trije fragen. Hoe freget it ZooKeeper foar konfiguraasje? En as wy de konfiguraasje feroarje wolle, hoe feroarje wy it? En neidat wy it feroare hawwe, hoe krije dy arbeiders dy't wy hiene it?
ZooKeeper makket dit relatyf maklik. Bygelyks is d'r ús znodebeam. D'r is hjir in knooppunt foar ús applikaasje, wy meitsje der in ekstra knooppunt yn, dy't gegevens fan 'e konfiguraasje befettet. Dizze kinne of net aparte parameters wêze. Sûnt de grutte is lyts, de konfiguraasje grutte is meastal ek lyts, dus it is hiel mooglik om te bewarjen it hjir.
Jo brûke de metoade GetData om de konfiguraasje foar de arbeider fan it knooppunt te krijen. Stel op wier. As om ien of oare reden dit knooppunt net bestiet, sille wy deroer wurde ynformearre as it ferskynt, of as it feroaret. As wy witte wolle dat der wat feroare is, dan sette wy it op wier. En as de gegevens yn dizze knooppunt feroarje, sille wy it witte.
SetData. Wy sette de gegevens yn, set "-1", d.w.s. wy kontrolearje de ferzje net, wy geane derfan út dat wy altyd ien konfiguraasje hawwe, wy hoege net in protte konfiguraasjes op te slaan. As jo in protte moatte opslaan, moatte jo in oar nivo tafoegje. Hjir leauwe wy dat d'r mar ien is, dus wy aktualisearje allinich de lêste, sadat wy de ferzje net kontrolearje. Op dit stuit krije alle kliïnten dy't earder ynskreaun hawwe in notifikaasje dat der wat feroare is yn dit knooppunt. En nei't se dy krigen hawwe, moatte se de gegevens ek nochris opfreegje. De notifikaasje is dat se de gegevens sels net ûntfange, mar allinich notifikaasje fan feroaringen. Dêrnei moatte se om nije gegevens freegje.
De twadde opsje foar it brûken fan it primitive is groep lidmaatskip. Wy hawwe in ferspraat applikaasje, d'r binne in stel arbeiders en wy wolle begripe dat se allegear op it plak binne. Dêrom moatte se sels registrearje dat se wurkje yn ús applikaasje. En wy wolle ek witte, itsij út it Master-proses of earne oars, oer alle aktive arbeiders dy't wy no hawwe.
Hoe dogge wy dit? Foar de applikaasje meitsje wy in arbeidersknooppunt en foegje dêr in sublevel ta mei de metoade oanmeitsje. Ik haw in flater op 'e slide. Hjir moatte jo sekwinsjele spesifisearje, dan wurde alle arbeiders ien foar ien oanmakke. En de applikaasje, dy't alle gegevens freget oer de bern fan dizze knooppunt, ûntfangt alle aktive arbeiders dy't bestean.
Dit is sa'n skriklike ymplemintaasje fan hoe't dit kin dien wurde yn Java-koade. Litte wy begjinne fan 'e ein, mei de wichtichste metoade. Dit is ús klasse, litte wy syn metoade oanmeitsje. As it earste argumint brûke wy host, wêr't wy ferbine, dat wol sizze wy sette it as argumint. En it twadde argumint is de namme fan 'e groep.
Hoe komt de ferbining? Dit is in ienfâldich foarbyld fan de API dy't wurdt brûkt. Alles is hjir relatyf ienfâldich. Der is in standert klasse ZooKeeper. Wy passe der hosts oan. En set de timeout, bygelyks, op 5 sekonden. En wy hawwe in lid neamd ferbûnSignal. Yn essinsje meitsje wy in groep lâns it trochstjoerde paad. Wy skriuwe dêr gjin gegevens, al hie der wol wat skreaun wurde kinnen. En it knooppunt hjir is fan it oanhâldende type. Yn essinsje is dit in gewoane reguliere knooppunt dy't de hiele tiid sil bestean. Dit is wêr't de sesje wurdt makke. Dit is de ymplemintaasje fan de klant sels. Us kliïnt sil periodike berjochten stjoere dy't oanjaan dat de sesje libbet. En as wy de sesje einigje, roppe wy ticht en dat is it, de sesje falt ôf. Dit is foar it gefal dat der wat foar ús ôffalt, sadat ZooKeeper it te witten komt en de sesje ôfsnijt.
Hoe kinne jo in boarne beskoattelje? Hjir is alles wat yngewikkelder. Wy hawwe in set fan arbeiders, der is wat boarne dy't wy wolle beskoattelje. Om dit te dwaan, meitsje wy in aparte knooppunt, bygelyks lock1 neamd. As wy it meitsje koenen, dan krigen wy hjir in slot. En as wy it net kinne oanmeitsje, dan besiket de arbeider hjirwei getData te krijen, en om't it knooppunt al oanmakke is, sette wy hjir in watcher en it momint dat de steat fan dizze knooppunt feroaret, sille wy it witte. En wy kinne besykje tiid te hawwen om it opnij te meitsjen. As wy dit knooppunt namen, namen dit slot, dan nei't wy it slot net mear nedich hawwe, sille wy it ferlitte, om't it knooppunt allinich binnen de sesje bestiet. Dêrtroch sil it ferdwine. En in oare kliïnt, yn it ramt fan in oare sesje, sil it slot op dit knooppunt kinne nimme, of leaver, hy sil in notifikaasje krije dat der wat feroare is en hy kin besykje it op 'e tiid te dwaan.
In oar foarbyld fan hoe't jo de haadlieder kinne kieze. Dit is in bytsje yngewikkelder, mar ek relatyf ienfâldich. Wat bart hjir? D'r is in haadknooppunt dy't alle arbeiders aggregearret. Wy besykje gegevens oer de lieder te krijen. As dit mei súkses barde, d.w.s. wy krigen wat gegevens, dan begjint ús arbeider dizze lieder te folgjen. Hy is fan betinken dat der al in lieder is.
As de lieder om ien of oare reden stoar, bygelyks, foel ôf, dan besykje wy in nije lieder te meitsjen. En as wy slagje, dan wurdt ús arbeider de lieder. En as immen op dit stuit slagge om in nije lieder te meitsjen, dan besykje wy te begripen wa't it is en folgje him dan.
Hjir ûntstiet it saneamde keppeleffekt, dus it keppeleffekt, want as in lieder stjert, wurdt dejinge dy't earst yn 'e tiid is de lieder.
By it fêstlizzen fan in boarne kinne jo besykje in wat oare oanpak te brûken, dat is as folget. Bygelyks, wy wolle krije in slot, mar sûnder de hert effekt. It sil bestean út it feit dat ús applikaasje oanfragen listen fan alle node ids foar in al besteande node mei in slot. En as dêrfoar it knooppunt wêrfoar wy in slot makke hawwe de lytste is fan 'e set dy't wy krigen hawwe, dan betsjut dit dat wy it slot hawwe fêstlein. Wy kontrolearje dat wy hawwe krigen in slot. As kontrôle sil d'r in betingst wêze dat de id dy't wy krigen hawwe by it meitsjen fan in nij slot minimaal is. En as wy it krigen hawwe, dan wurkje wy fierder.
As d'r in bepaalde id is dy't lytser is dan ús slot, dan sette wy in watcher op dit evenemint en wachtsje op notifikaasje oant der wat feroaret. Dat is, wy krigen dit slot. En oant it falt, sille wy net de minimale id wurde en it minimale slot net ûntfange, en dus kinne wy ynlogge. En as dizze betingst net foldien wurdt, dan geane wy hjir daliks hinne en besykje dizze slûs wer te krijen, want der kin yn dizze tiid wat feroare wêze.
Wêr bestiet ZooKeeper út? Der binne 4 wichtichste dingen. Dit is ferwurkjen prosessen - Fersyk. En ek ZooKeeper Atomic Broadcast. Der is in Commit Log dêr't alle operaasjes wurde opnomd. En de In-memory Replicated DB sels, dus de databank sels dêr't dizze hiele beam wurdt opslein.
It is de muoite wurdich opskriuwen dat alle skriuw operaasjes geane troch de fersyk Prozessor. En lêzen operaasjes geane direkt nei de In-memory databank.
De databank sels is folslein replikearre. Alle eksimplaren fan ZooKeeper bewarje in folsleine kopy fan 'e gegevens.
Om de databank te herstellen nei in crash, is d'r in Commit-log. Standert praktyk is dat foardat gegevens krije yn it ûnthâld, it wurdt skreaun dêr sadat as it crashes, dit log kin wurde spile werom en de systeem steat kin werombrocht wurde. En periodike snapshots fan 'e databank wurde ek brûkt.
ZooKeeper Atomic Broadcast is in ding dat wurdt brûkt om replikearre gegevens te behâlden.
ZAB selektearret yntern in lieder út it eachpunt fan 'e ZooKeeper-knooppunt. Oare knopen wurde har folgers en ferwachtsje wat aksjes fan har. As se ynstjoerings krije, stjoere se se allegear troch nei de lieder. Hy docht earst in skriuwoperaasje en stjoert dan in berjocht oer wat der feroare is oan syn folgers. Dit moat trouwens atomysk útfierd wurde, d.w.s. de opname- en útstjoeroperaasje fan it gehiel moat atomysk útfierd wurde, en garandearje dêrmei gegevenskonsistinsje.
It ferwurket allinich skriuwfersiken. De wichtichste taak is dat it de operaasje transformeart yn in transaksje-update. Dit is in spesjaal oanmakke fersyk.
En hjir is it de muoite wurdich op te merken dat de idempotens fan updates foar deselde operaasje garandearre is. Wat is it? Dit ding, as twa kear útfierd, sil deselde steat hawwe, d.w.s. it fersyk sels sil net feroarje. En dit moat dien wurde sadat jo yn gefal fan in crash de operaasje opnij starte kinne, sadat de wizigingen dy't op it stuit falle binne weromdraaie. Yn dit gefal sil de steat fan it systeem itselde wurde, d.w.s. it moat net sa wêze dat in rige fan deselde, bygelyks updateprosessen, liede ta ferskate lêste steaten fan it systeem.
Boarne: www.habr.com