Предлажем да прочитате транскрипт предавања "Хадооп. ЗооКеепер" из серије "Методе за дистрибуирану обраду великих количина података у Хадооп-у"
Шта је ЗооКеепер, његово место у Хадооп екосистему. Неистине о дистрибуираном рачунарству. Дијаграм стандардног дистрибуираног система. Потешкоће у координацији дистрибуираних система. Типични проблеми са координацијом. Принципи који стоје иза дизајна ЗооКеепер-а. ЗооКеепер модел података. зноде флагс. Сесије. Цлиент АПИ. Примитиве (конфигурација, чланство у групи, једноставне браве, избор вође, закључавање без ефекта стада). Архитектура ЗооКеепер. ЗооКеепер ДБ. ЗАБ. Руковалац захтева.
Данас ћемо причати о ЗооКеепер-у. Ова ствар је веома корисна. Он, као и сваки Апацхе Хадооп производ, има лого. Приказује човека.
Пре овога смо углавном причали о томе како се подаци тамо могу обрадити, како их чувати, односно како их некако користити и са њима некако радити. А данас бих желео да причам мало о изградњи дистрибуираних апликација. А ЗооКеепер је једна од оних ствари које вам омогућавају да поједноставите ову ствар. Ово је врста услуге која је намењена некој врсти координације интеракције процеса у дистрибуираним системима, у дистрибуираним апликацијама.
Потреба за оваквим апликацијама је сваким даном све већа, то је оно што је наш курс. С једне стране, МапРедуце и овај готов оквир вам омогућавају да изравнате ову сложеност и ослободите програмера од писања примитивних елемената као што су интеракција и координација процеса. Али, с друге стране, нико не гарантује да то ионако неће морати да се уради. МапРедуце или други готови оквири не замењују увек у потпуности неке случајеве који се не могу применити помоћу овога. Укључујући сам МапРедуце и гомилу других Апацхе пројеката, они су, у ствари, такође дистрибуиране апликације. А да би олакшали писање, написали су ЗооКеепер.
Као и све апликације везане за Хадооп, развио га је Иахоо! Сада је такође званична Апацхе апликација. Није тако активно развијен као ХБасе. Ако одете на ЈИРА ХБасе, онда сваки дан постоји гомила извештаја о грешкама, гомила предлога да се нешто оптимизује, тј. живот у пројекту се стално одвија. А ЗооКеепер је, с једне стране, релативно једноставан производ, а с друге стране, то му осигурава поузданост. И прилично је једноставан за коришћење, због чега је постао стандард у апликацијама у оквиру Хадооп екосистема. Зато сам мислио да би било корисно да га прегледам да бих разумео како функционише и како да га користим.
Ово је слика са неког предавања које смо имали. Можемо рећи да је ортогонална свему што смо до сада разматрали. И све што је овде назначено, у овој или другој мери, ради са ЗооКеепер-ом, односно, то је сервис који користи све ове производе. Ни ХДФС ни МапРедуце не пишу сопствене сличне услуге које би посебно радиле за њих. Сходно томе, користи се ЗооКеепер. А ово поједностављује развој и неке ствари везане за грешке.
Одакле све ово? Чини се да смо покренули две апликације паралелно на различитим рачунарима, повезали их низом или у мрежи и све ради. Али проблем је у томе што је мрежа непоуздана, и ако сте нањушили саобраћај или погледали шта се тамо дешава на ниском нивоу, како клијенти комуницирају на мрежи, често можете видети да су неки пакети изгубљени или поново послати. Није узалуд измишљени ТЦП протоколи који вам омогућавају да успоставите одређену сесију и гарантујете испоруку порука. Али у сваком случају, чак ни ТЦП не може увек да вас спаси. Све има тајм-аут. Мрежа може једноставно пасти на неко време. Можда само трепће. И све ово доводи до чињенице да се не можете ослонити на поузданост мреже. Ово је главна разлика у односу на писање паралелних апликација које раде на једном рачунару или на једном суперкомпјутеру, где не постоји Мрежа, где постоји поузданија магистрала за размену података у меморији. А ово је суштинска разлика.
Између осталог, када се користи Мрежа, увек постоји одређено кашњење. Диск га такође има, али Мрежа га има више. Латенција је неко време кашњења, које може бити или мало или прилично значајно.
Топологија мреже се мења. Шта је топологија - ово је постављање наше мрежне опреме. Постоје центри података, постоје регали који стоје тамо, постоје свеће. Све ово се може поново спојити, померити итд. О свему томе такође треба водити рачуна. ИП имена се мењају, мења се рутирање кроз које путује наш саобраћај. Ово такође треба узети у обзир.
Мрежа се такође може променити у погледу опреме. Из праксе могу рећи да наши мрежни инжењери заиста воле да повремено ажурирају нешто на свећама. Одједном је изашао нови фирмвер и нису били посебно заинтересовани за неки Хадооп кластер. Они имају свој посао. За њих је главно да Мрежа ради. У складу с тим, они желе да поново учитају нешто тамо, ураде флешовање на свом хардверу, а хардвер се такође периодично мења. Све ово некако треба узети у обзир. Све ово утиче на нашу дистрибуирану апликацију.
Обично људи који почну да раде са великим количинама података из неког разлога верују да је Интернет неограничен. Ако се тамо налази датотека од неколико терабајта, онда је можете однети на сервер или рачунар и отворити помоћу како и гледај. Још једна грешка је унутра енергија погледајте дневнике. Никад не ради ово јер је лоше. Зато што Вим покушава све да баферује, све учита у меморију, посебно када почнемо да се крећемо кроз овај дневник и тражимо нешто. То су ствари које су заборављене, али вредне разматрања.
Лакше је написати један програм који ради на једном рачунару са једним процесором.
Када наш систем расте, желимо да све то паралелизујемо, и то не само на рачунару, већ и на кластеру. Поставља се питање: како координирати ову ствар? Наше апликације можда чак и не комуницирају једна са другом, али смо покренули неколико процеса паралелно на неколико сервера. И како пратити да им све иде добро? На пример, пошаљу нешто преко интернета. Морају да пишу о свом стању негде, на пример, у некој врсти базе података или дневника, затим да агрегирају овај дневник и онда га негде анализирају. Плус, морамо узети у обзир да је процес радио и радио, одједном се појавила нека грешка у њему или се срушио, колико брзо ћемо онда сазнати за то?
Јасно је да се све ово може брзо пратити. Ово је такође добро, али праћење је ограничена ствар која вам омогућава да надгледате неке ствари на највишем нивоу.
Када желимо да наши процеси почну да комуницирају једни са другима, на пример, да једни другима шаљу неке податке, онда се поставља и питање – како ће се то догодити? Хоће ли бити неког тркачког стања, да ли ће се међусобно преписивати, да ли ће подаци стићи исправно, да ли ће се успут нешто изгубити? Треба да развијемо некакав протокол итд.
Координација свих ових процеса није тривијална ствар. И то приморава програмера да се спусти на још нижи ниво и пише системе или од нуле, или не баш од нуле, али то није тако једноставно.
Ако смислите криптографски алгоритам или га чак имплементирате, онда га одмах баците, јер највероватније неће радити за вас. Највероватније ће садржати гомилу грешака које сте заборавили да наведете. Никада га немојте користити за било шта озбиљно јер ће највероватније бити нестабилан. Зато што су сви алгоритми који постоје већ дуго тестирани временом. То је прислушкивано од стране заједнице. Ово је посебна тема. И овде је исто. Ако је могуће да сами не имплементирате неку врсту синхронизације процеса, онда је боље да то не радите, јер је прилично компликовано и води вас климавим путем сталног тражења грешака.
Данас говоримо о ЗооКеепер-у. С једне стране, то је оквир, са друге, то је сервис који програмеру олакшава живот и максимално поједностављује имплементацију логике и координацију наших процеса.
Подсетимо се како би могао да изгледа стандардни дистрибуирани систем. Ово је оно о чему смо причали - ХДФС, ХБасе. Постоји Мастер процес који управља радничким и подређеним процесима. Он је одговоран за координацију и расподелу задатака, поновно покретање радника, покретање нових и расподелу оптерећења.
Напреднија ствар је Служба за координацију, односно преместити сам задатак координације у посебан процес, плус паралелно покренути неку врсту резервног или стандби Мастер-а, јер Мастер може да пропадне. А ако Господар падне, онда наш систем неће радити. Радимо резервну копију. Неки наводе да главни мора бити реплициран у резервну копију. Ово се може поверити и Служби за координацију. Али у овом дијаграму, сам Мастер је одговоран за координацију радника, овде служба координира активности репликације података.
Напреднија опција је када сву координацију обавља наша служба, као што се обично ради. Он преузима одговорност да се побрине да све функционише. А ако нешто не функционише, сазнаћемо за то и покушавамо да заобиђемо ову ситуацију. У сваком случају, остаје нам Господар који на неки начин комуницира са робовима и може да шаље податке, информације, поруке итд. преко неке услуге.
Постоји још напреднија шема, када немамо Мастер, сви чворови су мастер робови, различити по свом понашању. Али они и даље морају да комуницирају једни са другима, тако да је још преостала нека служба да координира ове акције. Вероватно се Касандра, која ради на овом принципу, уклапа у ову шему.
Тешко је рећи која од ових шема боље функционише. Сваки има своје предности и мане.
И не треба се плашити неких ствари код Учитеља, јер, како показује пракса, он није толико подложан сталном служењу. Овде је главна ствар одабрати право решење за хостовање ове услуге на посебном моћном чвору, тако да има довољно ресурса, тако да корисници, ако је могуће, немају приступ тамо, како случајно не би убили овај процес. Али у исто време, у таквој шеми је много лакше управљати радницима из Мастер процеса, односно ова шема је једноставнија са становишта имплементације.
А ова шема (горе) је вероватно сложенија, али поузданија.
Главни проблем су делимични кварови. На пример, када пошаљемо поруку преко мреже, деси се нека врста незгоде, а онај ко је послао поруку неће знати да ли је његова порука примљена и шта се десило на страни примаоца, неће знати да ли је порука исправно обрађена. , односно неће добити никакву потврду.
Сходно томе, ову ситуацију морамо обрадити. А најједноставније је да поново пошаљете ову поруку и сачекате док не добијемо одговор. У овом случају се не узима у обзир да ли се стање пријемника променило. Можемо послати поруку и додати исте податке два пута.
ЗооКеепер нуди начине да се изборимо са таквим одбијањима, што нам такође олакшава живот.
Као што је мало раније поменуто, ово је слично писању програма са више нити, али главна разлика је у томе што у дистрибуираним апликацијама које градимо на различитим машинама, једини начин комуникације је мрежа. У суштини, ово је архитектура која се не дели. Сваки процес или услуга која ради на једној машини има своју меморију, свој диск, сопствени процесор, који не дели ни са ким.
Ако на једном рачунару напишемо програм са више нити, онда можемо користити заједничку меморију за размену података. Тамо имамо промену контекста, процеси се могу мењати. Ово утиче на перформансе. С једне стране, то не постоји у програму на кластеру, али постоје проблеми са мрежом.
Сходно томе, главни проблеми који се јављају приликом писања дистрибуираних система су конфигурација. Пишемо неку врсту апликације. Ако је једноставно, онда хардкодирамо све врсте бројева у коду, али то је незгодно, јер ако одлучимо да уместо тајм-аута од пола секунде желимо тајм-аут од једне секунде, онда треба да поново компајлирамо апликацију и поново све изваљати. Једно је када је на једној машини, када можете само да је поново покренете, али када имамо много машина, морамо стално све да копирамо. Морамо покушати да учинимо апликацију конфигурабилном.
Овде говоримо о статичкој конфигурацији за системске процесе. Ово није у потпуности, можда са становишта оперативног система, то може бити статичка конфигурација за наше процесе, односно ово је конфигурација која се не може једноставно узети и ажурирати.
Постоји и динамичка конфигурација. Ово су параметри које желимо да променимо у ходу како би се тамо покупили.
Шта је овде проблем? Ажурирали смо конфигурацију, избацили је, па шта? Проблем је можда у томе што смо с једне стране избацили конфигурацију, али смо заборавили на нову ствар, конфигурација је остала тамо. Друго, док смо покретали, конфигурација је ажурирана на неким местима, али не и на другим. И неки процеси наше апликације који раде на једној машини су поново покренути са новом конфигурацијом, а негде са старом. Ово може довести до тога да наша дистрибуирана апликација буде недоследна из перспективе конфигурације. Овај проблем је уобичајен. За динамичку конфигурацију, то је релевантније јер подразумева да се може мењати у ходу.
Други проблем је чланство у групи. Увек имамо неки скуп радника, увек желимо да знамо ко је од њих жив, ко мртав. Ако постоји Мастер, онда он мора да разуме који радници могу да се преусмере на клијенте како би они водили прорачуне или радили са подацима, а који не. Проблем који се стално јавља је да морамо знати ко ради у нашем кластеру.
Други типичан проблем су избори лидера, када желимо да знамо ко је главни. Један пример је репликација, када имамо неки процес који прима операције писања и затим их реплицира међу другим процесима. Он ће бити вођа, сви остали ће му се покоравати, следиће га. Неопходно је изабрати процес тако да буде недвосмислен за све, да не би испало да се бирају два лидера.
Постоји и приступ који се међусобно искључује. Овде је проблем сложенији. Постоји нешто као мутекс, када пишете програме са више нити и желите да приступ неком ресурсу, на пример, меморијској ћелији, буде ограничен и да га спроводи само једна нит. Овде би ресурс могао бити нешто апстрактније. А различите апликације са различитих чворова наше Мреже треба да добију само ексклузивни приступ датом ресурсу, а не да свако може да га промени или тамо нешто напише. То су такозване браве.
ЗооКеепер вам омогућава да решите све ове проблеме у једном или другом степену. И показаћу на примерима како вам то омогућава.
Нема примитивних блокова. Када почнемо да користимо нешто, овај примитив неће чекати да се деси било какав догађај. Највероватније ће ова ствар радити асинхроно, омогућавајући тако процесима да не закаче док нешто чекају. Ово је веома корисна ствар.
Сви захтеви клијената се обрађују по редоследу општег реда.
И клијенти имају могућност да добију обавештење о променама у неком стању, о променама података, пре него што клијент сам види измењене податке.
ZooKeeper може да ради у два режима. Први је самостални, на једном чвору. Ово је погодно за тестирање. Такође може да ради у режиму кластера, на било ком броју чворова. сервериАко имамо кластер од 100 машина, не мора нужно да ради на 100 машина. Довољно је доделити неколико машина на којима ZooKeeper може да ради. И придржава се принципа високе доступности. ZooKeeper чува комплетну копију података на свакој покренутој инстанци. Објаснићу касније како то ради. Не дели нити партиционише податке. С једне стране, ово је мана јер не можемо много да складиштимо, али с друге стране, то је непотребно. Није дизајниран за то; није база података.
Подаци се могу кеширати на страни клијента. Ово је стандардни принцип тако да не прекидамо услугу и не учитавамо је истим захтевима. Паметан клијент обично зна за ово и кешира то.
На пример, овде се нешто променило. Постоји нека врста апликације. Изабран је нови вођа, који је одговоран, на пример, за обраду операција писања. И желимо да реплицирамо податке. Једно решење је да га ставите у петљу. И стално доводимо у питање нашу услугу - да ли се нешто променило? Друга опција је оптималнија. Ово је механизам за гледање који вам омогућава да обавестите клијенте да се нешто променило. Ово је јефтинији метод у смислу ресурса и погоднији за клијенте.
Клијент је корисник који користи ЗооКеепер.
Сервер је сам процес ЗооКеепер.
Зноде је кључна ствар у ЗооКееперу. Све зноде се чувају у меморији од стране ЗооКеепер-а и организоване су у облику хијерархијског дијаграма, у облику стабла.
Постоје две врсте операција. Први је упдате/врите, када нека операција промени стање нашег стабла. Дрво је уобичајено.
И могуће је да клијент не испуни један захтев и да буде искључен, али може да успостави сесију преко које комуницира са ЗооКеепер-ом.
ЗооКееперов модел података подсећа на систем датотека. Постоји стандардни роот и онда смо прошли као кроз директоријуме који иду од корена. И онда каталог првог нивоа, другог нивоа. Ово је све знодес.
Сваки зноде може да ускладишти неке податке, обично не баш велике, на пример, 10 килобајта. И сваки зноде може имати одређени број деце.
Знодес долази у неколико типова. Могу се креирати. А када креирамо зноде, наводимо тип коме треба да припада.
Постоје две врсте. Прва је ефемерна застава. Зноде живи у оквиру сесије. На пример, клијент је успоставио сесију. И док је ова седница жива, постојаће. Ово је неопходно како се не би произвело нешто непотребно. Ово је такође погодно за тренутке када нам је важно да сачувамо примитиве података у оквиру сесије.
Други тип је секвенцијална застава. Повећава бројач на путу до зноде. На пример, имали смо директоријум са апликацијом 1_5. И када смо креирали први чвор, примио је п_1, други - п_2. И када сваки пут позовемо ову методу, ми проследимо пуну путању, указујући само на део путање, а овај број се аутоматски повећава јер означавамо тип чвора – секвенцијални.
Регулар зноде. Она ће увек живети и имати име које јој кажемо.
Још једна корисна ствар је заставица сата. Ако га инсталирамо, клијент се може претплатити на неке догађаје за одређени чвор. Касније ћу вам показати на примеру како се то ради. Сам ЗооКеепер обавештава клијента да су се подаци на чвору променили. Међутим, обавештења не гарантују да су неки нови подаци стигли. Једноставно кажу да се нешто променило, па и даље морате да поредите податке касније са засебним позивима.
И као што сам већ рекао, редослед података је одређен килобајтима. Нема потребе да се тамо чувају велики текстуални подаци, јер то није база података, то је сервер за координацију акција.
Дозволите ми да вам кажем мало о сесијама. Ако имамо неколико сервера, можемо транспарентно прелазити са једног сервера на други. сервер, користећи ИД сесије. Ово је прилично згодно.
Свака сесија има неку врсту тајм-аута. Сесија је дефинисана тиме да ли клијент шаље било шта серверу током те сесије. Ако није пренео ништа током тајмаута, сесија пада, или је клијент може сам затворити.
Нема толико функција, али са овим АПИ-јем можете радити различите ствари. Тај позив који смо видели да креира креира зноде и узима три параметра. Ово је пут до знодеа, и мора бити наведен у потпуности из корена. И ово су неки подаци које желимо да пренесемо тамо. И врсту заставе. И након креирања враћа путању до знодеа.
Друго, можете га избрисати. Трик је у томе што други параметар, поред путање до знодеа, може одредити верзију. Сходно томе, тај зноде ће бити обрисан ако је његова верзија коју смо пренели еквивалентна оној која стварно постоји.
Ако не желимо да проверимо ову верзију, онда једноставно проследимо аргумент "-1".
Треће, проверава постојање знодеа. Враћа тачно ако чвор постоји, а у супротном нетачно.
А онда се појављује сат са заставицом, који вам омогућава да надгледате овај чвор.
Ову заставицу можете поставити чак и на непостојећи чвор и добити обавештење када се појави. Ово такође може бити корисно.
Још пар изазова је гетДата. Јасно је да можемо да примамо податке преко зноде. Такође можете користити сат са заставом. У овом случају, неће се инсталирати ако нема чвора. Стога, морате схватити да постоји, а затим примити податке.
Постоји и СетДата. Овде преносимо верзију. А ако ово пренесемо даље, подаци о знодеу одређене верзије ће бити ажурирани.
Такође можете да наведете „-1“ да бисте искључили ову проверу.
Још једна корисна метода је гетЦхилдрен. Такође можемо добити списак свих знода који јој припадају. Ово можемо да пратимо постављањем сата за заставу.
И метод синхронизацију омогућава да се све промене пошаљу одједном, чиме се осигурава да су сачуване и да су сви подаци потпуно промењени.
Ако повучемо аналогије са конвенционалним програмирањем, онда када користите методе као што је писање, које нешто записују на диск, а након што вам врати одговор, нема гаранције да сте податке записали на диск. Чак и када је оперативни систем уверен да је све записано, на самом диску постоје механизми где процес пролази кроз слојеве бафера, а тек након тога подаци се смештају на диск.
Углавном се користе асинхрони позиви. Ово омогућава клијенту да ради паралелно са различитим захтевима. Можете користити синхрони приступ, али је мање продуктиван.
Две операције о којима смо говорили су ажурирање/писање, које мењају податке. То су креирање, постављање података, синхронизација, брисање. И реад постоји, гетДата, гетЦхилдрен.
Сада неколико примера како можете направити примитиве за рад у дистрибуираном систему. На пример, везано за конфигурацију нечега. Појавио се нови радник. Додали смо машину и покренули процес. А ту су и следећа три питања. Како поставља упит ЗооКеепер-у за конфигурацију? А ако желимо да променимо конфигурацију, како да је променимо? А након што смо га променили, како то добијају они радници које смо имали?
ЗооКеепер ово чини релативно лаким. На пример, постоји наше дрво зноде. Овде постоји чвор за нашу апликацију, у њему креирамо додатни чвор који садржи податке из конфигурације. Ово могу или не морају бити засебни параметри. Пошто је величина мала, обично је мала и величина конфигурације, тако да је сасвим могуће да је сачувате овде.
Ви користите метод гетДата да бисте добили конфигурацију за радника из чвора. Поставите на труе. Ако из неког разлога овај чвор не постоји, бићемо обавештени о томе када се појави, или када се промени. Ако желимо да знамо да се нешто променило, онда то постављамо на истинито. А ако се подаци у овом чвору промене, знаћемо за то.
СетДата. Постављамо податке, постављамо „-1“, тј. не проверавамо верзију, претпостављамо да увек имамо једну конфигурацију, не морамо да чувамо много конфигурација. Ако треба да складиштите много, мораћете да додате још један ниво. Овде верујемо да постоји само један, па ажурирамо само најновију, тако да не проверавамо верзију. У овом тренутку сви клијенти који су се претходно претплатили добијају обавештење да се нешто променило у овом чвору. А након што га добију, такође морају поново затражити податке. Обавештење је да не добијају саме податке, већ само обавештење о променама. Након тога морају тражити нове податке.
Друга опција за коришћење примитивца је чланство у групи. Имамо дистрибуирану апликацију, има гомила радника и желимо да схватимо да су сви на месту. Стога се морају пријавити да раде у нашој апликацији. Такође желимо да сазнамо, било из Мастер процеса или негде другде, о свим активним радницима које тренутно имамо.
Како да ово урадимо? За апликацију креирамо чвор радника и додајемо подниво користећи метод креирања. Имам грешку на слајду. Овде ти треба Секуентиал наведите, онда ће сви радници бити креирани један по један. А апликација, која захтева све податке о деци овог чвора, прима све активне раднике који постоје.
Ово је тако страшна имплементација како се то може урадити у Јава коду. Почнимо од краја, са главним методом. Ово је наша класа, хајде да креирамо њен метод. Као први аргумент користимо хост, где се повезујемо, односно постављамо га као аргумент. А други аргумент је име групе.
Како настаје веза? Ово је једноставан пример АПИ-ја који се користи. Овде је све релативно једноставно. Постоји стандардна класа ЗооКеепер. Пребацујемо му домаћине. И подесите временско ограничење, на пример, на 5 секунди. И имамо члана који се зове ЦоннецтСигнал. У суштини, ми креирамо групу дуж пута који се преноси. Ми ту не пишемо податке, иако се могло нешто написати. А чвор овде је упорног типа. У суштини, ово је обичан регуларни чвор који ће постојати све време. Овде се креира сесија. Ово је имплементација самог клијента. Наш клијент ће периодично извештавати да је сесија жива. И када завршимо сесију, зовемо затворено и то је то, сесија пада. Ово је у случају да нам нешто падне, па да ЗооКеепер сазна за то и прекине сесију.
Како закључати ресурс? Овде је све мало компликованије. Имамо скуп радника, постоји неки ресурс који желимо да закључамо. Да бисмо то урадили, креирамо посебан чвор, на пример, који се зове лоцк1. Ако смо успели да га створимо, онда имамо браву овде. А ако нисмо били у могућности да га креирамо, онда радник покушава да добије гетДата одавде, а пошто је чвор већ креиран, онда постављамо посматрач овде и у тренутку када се стање овог чвора промени, ми ћемо знати за то. И можемо покушати да имамо времена да га поново створимо. Ако смо узели овај чвор, узели ову браву, онда када нам више не треба закључавање, ми ћемо га напустити, пошто чвор постоји само у оквиру сесије. Сходно томе, нестаће. А други клијент, у оквиру друге сесије, моћи ће да преузме закључавање на овом чвору, тачније, добиће обавештење да се нешто променило и може покушати да то уради на време.
Још један пример како можете изабрати главног вођу. Ово је мало компликованије, али и релативно једноставно. Шта се дешава овде? Постоји главни чвор који агрегира све раднике. Покушавамо да добијемо податке о вођи. Ако се ово десило успешно, односно добили смо неке податке, онда наш радник почиње да прати овог вођу. Он сматра да лидер већ постоји.
Ако је вођа из неког разлога умро, на пример, пао, онда покушавамо да створимо новог вођу. А ако успемо, онда наш радник постаје вођа. А ако је неко у овом тренутку успео да створи новог вођу, онда покушавамо да схватимо ко је то и онда га следимо.
Овде настаје такозвани ефекат стада, односно ефекат стада, јер када вођа умре, вођа постаје онај који је први у времену.
Када хватате ресурс, можете покушати да користите мало другачији приступ, који је следећи. На пример, желимо да добијемо браву, али без херт ефекта. Она ће се састојати у чињеници да наша апликација тражи листе свих ИД-ова чворова за већ постојећи чвор са закључавањем. А ако је пре тога чвор за који смо креирали браву најмањи од скупа који смо добили, онда то значи да смо ухватили браву. Проверавамо да ли смо добили браву. Као провера, постојаће услов да је ид који смо добили приликом креирања нове браве минималан. А ако смо то добили, онда радимо даље.
Ако постоји одређени ИД који је мањи од наше браве, онда стављамо посматрач на овај догађај и чекамо обавештење док се нешто не промени. То јест, добили смо ову браву. И док не падне, нећемо постати минимални ид и нећемо добити минимално закључавање, па ћемо тако моћи да се пријавимо. А ако овај услов није испуњен, онда одмах идемо овамо и поново покушавамо да добијемо ову браву, јер се можда нешто променило за то време.
Од чега се састоји ЗооКеепер? Постоје 4 главне ствари. Ово су процеси обраде - Захтев. И такође ЗооКеепер Атомиц Броадцаст. Постоји дневник урезивања у који се бележе све операције. И сам реплицирани ДБ у меморији, тј. сама база података у којој се чува цело ово стабло.
Вреди напоменути да све операције писања пролазе кроз Процесор захтева. А операције читања иду директно у базу података у меморији.
Сама база података је у потпуности реплицирана. Све инстанце ЗооКеепер-а чувају комплетну копију података.
Да бисте вратили базу података након пада, постоји дневник урезивања. Стандардна пракса је да се пре него што подаци уђу у меморију, тамо записују тако да ако падне, овај дневник може да се репродукује и стање система може да се врати. Такође се користе периодични снимци базе података.
ЗооКеепер Атомиц Броадцаст је ствар која се користи за одржавање реплицираних података.
ЗАБ интерно бира лидера са становишта ЗооКеепер чвора. Други чворови постају њени следбеници и очекују неке акције од ње. Ако добију пријаве, све их прослеђују вођи. Он прво изводи операцију писања, а затим шаље поруку о томе шта се променило својим пратиоцима. Ово, у ствари, мора бити изведено атомски, односно операција снимања и емитовања целе ствари мора бити изведена атомски, чиме се гарантује конзистентност података.
Обрађује само захтеве за писање. Његов главни задатак је да трансформише операцију у трансакцијско ажурирање. Ово је посебно генерисан захтев.
И овде је вредно напоменути да је идемпотенција ажурирања за исту операцију загарантована. Шта је то? Ова ствар, ако се изврши два пута, имаће исто стање, односно сам захтев се неће променити. И то треба да се уради тако да у случају пада можете поново покренути операцију и на тај начин поништити промене које су тренутно отпале. У овом случају ће стање система постати исто, односно не би требало да буде да низ истих, на пример, процеса ажурирања, доведе до различитих коначних стања система.
Извор: ввв.хабр.цом
