Ви предлагам да го прочитате транскриптот од предавањето „Hadoop. ZooKeeper“ од серијалот „Методи за дистрибуирана обработка на голем обем на податоци во Hadoop“
Што е ZooKeeper, неговото место во екосистемот Hadoop. Невистини за дистрибуирани компјутери. Дијаграм на стандарден дистрибуиран систем. Тешкотии во координирање на дистрибуирани системи. Типични проблеми со координацијата. Принципите зад дизајнот на ZooKeeper. Модел на податоци ZooKeeper. znode знаменца. Сесии. Клиент API. Примитивци (конфигурација, членство во група, едноставни брави, избор на лидер, заклучување без ефект на стадо). Архитектура на ZooKeeper. ZooKeeper DB. ЗАБ. Управувач со барања.
Денес ќе зборуваме за ZooKeeper. Оваа работа е многу корисна. Тој, како и секој производ на Apache Hadoop, има лого. Тој прикажува човек.
Пред ова, главно зборувавме за тоа како таму може да се обработуваат податоците, како да се складираат, односно како некако да се користат и некако да се работи со нив. И денес би сакал да зборувам малку за изградба на дистрибуирани апликации. А ZooKeeper е една од оние работи што ви овозможува да ја поедноставите оваа работа. Ова е еден вид услуга која е наменета за некаква координација на интеракцијата на процесите во дистрибуираните системи, во дистрибуираните апликации.
Потребата за вакви апликации секој ден станува се повеќе и повеќе, токму тоа е нашиот курс. Од една страна, MapReduce и оваа готова рамка ви овозможуваат да ја израмните оваа сложеност и да го ослободите програмерот од пишување примитиви како што се интеракцијата и координацијата на процесите. Но, од друга страна, никој не гарантира дека тоа и онака нема да мора да се направи. MapReduce или други готови рамки не секогаш целосно заменуваат некои случаи што не можат да се имплементираат користејќи го ова. Вклучувајќи го самиот MapReduce и еден куп други Apache проекти; тие, всушност, се исто така дистрибуирани апликации. И за да го олеснат пишувањето, напишаа ZooKeeper.
Како и сите апликации поврзани со Hadoop, таа беше развиена од Yahoo! Сега е и официјална апликација Apache. Не е толку активно развиен како HBase. Ако одите во JIRA HBase, тогаш секој ден има еден куп извештаи за грешки, еден куп предлози да се оптимизира нешто, односно животот во проектот постојано трае. И ZooKeeper, од една страна, е релативно едноставен производ, а од друга страна, ова ја осигурува неговата сигурност. И прилично е лесен за користење, поради што стана стандард во апликациите во екосистемот Hadoop. Затоа мислев дека би било корисно да го прегледам за да разберам како функционира и како да го користам.
Ова е слика од некое предавање што го имавме. Можеме да кажеме дека е ортогонално на сето она што досега го разгледавме. И сè што е наведено овде, до еден или друг степен, работи со ZooKeeper, т.е., тоа е услуга што ги користи сите овие производи. Ниту HDFS ниту MapReduce не пишуваат свои слични услуги кои конкретно би работеле за нив. Според тоа, се користи ZooKeeper. И ова го поедноставува развојот и некои работи поврзани со грешки.
Од каде сето ова? Се чини дека лансиравме две апликации паралелно на различни компјутери, ги поврзавме со низа или во мрежа и сè работи. Но, проблемот е што Мрежата е несигурна, и ако го намирисавте сообраќајот или гледавте што се случува таму на ниско ниво, како клиентите комуницираат на мрежата, често може да видите дека некои пакети се губат или повторно се испраќаат. Не за џабе се измислени протоколи TCP, кои ви овозможуваат да воспоставите одредена сесија и да гарантирате испорака на пораки. Но, во секој случај, дури и TCP не може секогаш да ве спаси. Сè има тајмаут. Мрежата едноставно може да падне некое време. Може само да трепка. И сето тоа води до фактот дека не можете да се потпрете на тоа дека мрежата е сигурна. Ова е главната разлика од пишувањето паралелни апликации кои работат на еден компјутер или на еден суперкомпјутер, каде што нема Мрежа, каде што има посигурен автобус за размена на податоци во меморијата. И ова е фундаментална разлика.
Меѓу другото, при користење на Мрежата, секогаш постои одредена латентност. Го има и дискот, но мрежата има повеќе од тоа. Латентноста е одредено време на одложување, кое може да биде или мало или доста значајно.
Топологијата на мрежата се менува. Што е топологија - ова е поставувањето на нашата мрежна опрема. Има центри за податоци, има лавици што стојат таму, има свеќи. Сето ова може повторно да се поврзе, премести итн. Сето ова исто така треба да се земе предвид. Имињата на IP се менуваат, се менува рутирањето низ кое се движи нашиот сообраќај. Ова исто така треба да се земе предвид.
Мрежата може да се промени и во однос на опремата. Од пракса, можам да кажам дека нашите мрежни инженери навистина сакаат периодично да ажурираат нешто на свеќите. Одеднаш излезе нов фирмвер и тие не беа особено заинтересирани за некој Hadoop кластер. Тие имаат своја работа. За нив, главната работа е што Мрежата работи. Според тоа, тие сакаат повторно да прикачат нешто таму, да направат трепкање на нивниот хардвер, а хардверот исто така периодично се менува. Сето ова некако треба да се земе предвид. Сето ова влијае на нашата дистрибуирана апликација.
Обично луѓето кои почнуваат да работат со големи количини на податоци поради некоја причина веруваат дека Интернетот е неограничен. Ако таму има датотека од неколку терабајти, тогаш можете да ја однесете на вашиот сервер или компјутер и да ја отворите користејќи ја мачка и гледај. Друга грешка е во vim погледнете ги дневниците. Никогаш не го правете ова затоа што е лошо. Бидејќи Vim се обидува да пуферира сè, да вчита сè во меморијата, особено кога ќе почнеме да се движиме низ овој дневник и да бараме нешто. Ова се работи кои се заборавени, но вреди да се разгледаат.
Полесно е да се напише една програма што работи на еден компјутер со еден процесор.
Кога нашиот систем расте, сакаме да го паралелизираме сето тоа и да го паралелизираме не само на компјутер, туку и на кластер. Се поставува прашањето: како да се координира оваа работа? Нашите апликации можеби нема ни да комуницираат едни со други, но водевме неколку процеси паралелно на неколку сервери. И како да се следи дека сè им оди добро? На пример, тие испраќаат нешто преку Интернет. Тие мора да напишат за нивната состојба некаде, на пример, во некој вид база на податоци или дневник, потоа да го збират овој дневник и потоа да го анализираат некаде. Плус, треба да земеме предвид дека процесот работеше и работеше, одеднаш се појави некоја грешка во него или падна, тогаш колку брзо ќе дознаеме за тоа?
Јасно е дека сето тоа може брзо да се следи. Ова е исто така добро, но следењето е ограничена работа што ви овозможува да следите некои работи на највисоко ниво.
Кога сакаме нашите процеси да почнат да комуницираат едни со други, на пример, да испраќаат едни со други некои податоци, тогаш се поставува и прашањето - како тоа ќе се случи? Дали ќе има некаква состојба на трка, дали ќе се презапишуваат, дали податоците ќе пристигнат правилно, дали нешто ќе се изгуби на патот? Треба да развиеме некаков протокол итн.
Координацијата на сите овие процеси не е тривијална работа. И го принудува развивачот да се спушти на уште пониско ниво и да пишува системи или од нула, или не сосема од нула, но ова не е толку едноставно.
Ако смислите криптографски алгоритам или дури и го имплементирате, тогаш веднаш фрлете го, бидејќи најверојатно нема да работи за вас. Најверојатно ќе содржи еден куп грешки што сте заборавиле да ги обезбедите. Никогаш не го користете за ништо сериозно бидејќи најверојатно ќе биде нестабилно. Бидејќи сите алгоритми што постојат се тестирани од времето многу долго време. Тоа е прислушувано од заедницата. Ова е посебна тема. И овде е исто. Ако е можно сами да не имплементирате некаква синхронизација на процесите, тогаш подобро е да не го правите ова, бидејќи е доста комплицирано и ве води по разнишаниот пат на постојано пребарување на грешки.
Денес зборуваме за ZooKeeper. Од една страна, тоа е рамка, од друга страна, тоа е услуга што го олеснува животот на развивачот и го поедноставува спроведувањето на логиката и координацијата на нашите процеси што е можно повеќе.
Да се потсетиме како би можел да изгледа стандарден дистрибуиран систем. Ова е она за што разговаравме - HDFS, HBase. Постои Master процес кој управува со работниците и робовите процеси. Тој е одговорен за координација и дистрибуција на задачите, рестартирање на работници, лансирање нови и дистрибуција на товарот.
Понапредна работа е Координативната служба, односно преместување на самата задача за координација во посебен процес, плус водење на некој вид на резервна копија или standby Master паралелно, бидејќи мајсторот може да не успее. И ако Мајсторот падне, тогаш нашиот систем нема да работи. Водиме резервна копија. Некои наведуваат дека Master мора да се реплицира на резервна копија. Ова може да и се довери и на Координативната служба. Но, во овој дијаграм, самиот мајстор е одговорен за координирање на работниците; тука услугата ги координира активностите за репликација на податоци.
Понапредна опција е кога целата координација ја извршува нашата служба, како што обично се прави. Тој ја презема одговорноста да се погрижи сè да функционира. И ако нешто не функционира, дознаваме за тоа и се обидуваме да ја заобиколиме оваа ситуација. Во секој случај, ни останува Господар кој некако комуницира со робовите и може преку некоја услуга да испраќа податоци, информации, пораки и слично.
Постои уште понапредна шема, кога немаме Господар, сите јазли се господар робови, различни во нивното однесување. Но, тие сè уште треба да комуницираат едни со други, така што останува уште некоја услуга за да ги координира овие акции. Веројатно, Касандра, која работи на овој принцип, одговара на оваа шема.
Тешко е да се каже која од овие шеми работи подобро. Секој има свои добрите и лошите страни.
И нема потреба да се плашите од некои работи со Господарот, бидејќи, како што покажува практиката, тој не е толку подложен на постојано служење. Главната работа овде е да се избере вистинското решение за хостирање на оваа услуга на посебен моќен јазол, за да има доволно ресурси, така што ако е можно, корисниците да немаат пристап таму, за да не случајно го убијат овој процес. Но, во исто време, во таква шема е многу полесно да се управуваат работниците од процесот Master, односно оваа шема е поедноставна од гледна точка на имплементација.
И оваа шема (погоре) е веројатно посложена, но посигурна.
Главниот проблем е делумните неуспеси. На пример, кога испраќаме порака преку мрежата, се случува некаква несреќа, а тој што ја испратил пораката нема да знае дали неговата порака е примена и што се случило од страната на примачот, нема да знае дали пораката е правилно обработена. , односно нема да добие никаква потврда.
Според тоа, ние мора да ја обработиме оваа ситуација. И наједноставно е повторно да ја испратите оваа порака и да почекаме додека не добиеме одговор. Во овој случај, не се зема предвид дали состојбата на ресиверот е променета. Може да испратиме порака и да ги додадеме истите податоци двапати.
ZooKeeper нуди начини да се справиме со ваквите одбивања, што исто така ни го олеснува животот.
Како што споменавме малку порано, ова е слично на пишувањето програми со повеќе нишки, но главната разлика е во тоа што во дистрибуираните апликации што ги градиме на различни машини, единствениот начин за комуникација е Мрежата. Во суштина, ова е архитектура што не е споделено. Секој процес или услуга што работи на една машина има своја меморија, свој диск, свој процесор, кој не го споделува со никого.
Ако на еден компјутер напишеме програма со повеќе нишки, тогаш можеме да користиме споделена меморија за размена на податоци. Имаме контекстуален прекинувач таму, процесите може да се префрлат. Ова влијае на перформансите. Од една страна, нема такво нешто во програмата на кластер, но има проблеми со Мрежата.
Според тоа, главните проблеми што се јавуваат при пишување на дистрибуирани системи се конфигурацијата. Пишуваме некаква апликација. Ако е едноставно, тогаш хардкодираме секакви броеви во кодот, но ова е незгодно, бидејќи ако одлучиме дека наместо тајмаут од половина секунда сакаме тајмаут од една секунда, тогаш треба повторно да ја компајлираме апликацијата и наново сè повторно. Една работа е кога е на една машина, кога можете само да ја рестартирате, но кога имаме многу машини, мора постојано да копираме сè. Мора да се обидеме да ја направиме апликацијата конфигурабилна.
Овде зборуваме за статичка конфигурација за системски процеси. Ова не е целосно, можеби од гледна точка на оперативниот систем, можеби е статична конфигурација за нашите процеси, односно, ова е конфигурација што не може едноставно да се преземе и ажурира.
Има и динамична конфигурација. Ова се параметрите што сакаме да ги смениме при летот за да бидат подигнати таму.
Што е тука проблемот? Ја ажуриравме конфигурацијата, ја објавивме, па што? Проблемот може да е што од една страна ја отворивме конфигурацијата, но заборавивме на новото, конфигурацијата остана таму. Второ, додека се пуштавме, конфигурацијата беше ажурирана на некои места, но не и на други. И некои процеси на нашата апликација што работат на една машина беа рестартирани со нова конфигурација, а некаде со стара. Ова може да резултира со тоа што нашата дистрибуирана апликација е неконзистентна од перспектива на конфигурација. Овој проблем е вообичаен. За динамична конфигурација, таа е порелевантна бидејќи имплицира дека може да се менува во лет.
Друг проблем е членството во групата. Секогаш имаме некој збир на работници, секогаш сакаме да знаеме кој од нив е жив, кој од нив е мртов. Ако има мајстор, тогаш тој мора да разбере кои работници може да се пренасочат кон клиентите за да извршуваат пресметки или да работат со податоци, а кои не. Проблем кој постојано се појавува е тоа што треба да знаеме кој работи во нашиот кластер.
Друг типичен проблем се изборите за лидери, кога сакаме да знаеме кој е главен. Еден пример е репликацијата, кога имаме некој процес кој прима операции за запишување и потоа ги реплицира меѓу другите процеси. Тој ќе биде лидер, сите други ќе го слушаат, ќе го следат. Потребно е да се избере процес за да биде недвосмислен за сите, за да не испадне дека се избрани двајца лидери.
Има и взаемно исклучен пристап. Проблемот овде е покомплексен. Постои такво нешто како мутекс, кога пишувате програми со повеќе нишки и сакате пристапот до некој ресурс, на пример, мемориска ќелија, да биде ограничен и спроведен од само една нишка. Овде ресурсот би можел да биде нешто поапстрактно. А различни апликации од различни јазли на нашата Мрежа треба да добиваат исклучиво ексклузивен пристап до даден ресурс, а не секој да може да го промени или да напише нешто таму. Тоа се таканаречените брави.
ZooKeeper ви овозможува да ги решите сите овие проблеми до еден или друг степен. И ќе покажам со примери како ви дозволува да го направите тоа.
Нема блокирачки примитиви. Кога ќе почнеме да користиме нешто, овој примитив нема да чека да се случи некој настан. Најверојатно, оваа работа ќе работи асинхроно, а со тоа ќе дозволи процесите да не висат додека чекаат нешто. Ова е многу корисна работа.
Сите барања на клиентите се обработуваат по редоследот на општата редица.
И клиентите имаат можност да добијат известување за промени во некоја состојба, за промени во податоците, пред самиот клиент да ги види променетите податоци.
ZooKeeper може да работи во два режима. Првиот е самостоен, на еден јазол. Ова е погодно за тестирање. Може да работи и во кластер режим на кој било број на сервери. Ако имаме кластер од 100 машини, тогаш не е неопходно тој да работи на 100 машини. Доволно е да изберете неколку машини каде што можете да го стартувате ZooKeeper. И го исповеда принципот на висока достапност. На секој работен примерок, ZooKeeper складира цела копија од податоците. Подоцна ќе ви кажам како го прави тоа. Не ги дели податоците и не ги поделува. Од една страна, тоа е минус што не можеме многу да складираме, од друга страна, нема потреба да го правиме ова. Тоа не е она за што е дизајниран, не е база на податоци.
Податоците може да се кешираат на страната на клиентот. Ова е стандарден принцип за да не ја прекинеме услугата и да не ја вчитаме со истите барања. Паметниот клиент обично знае за ова и го кешира.
На пример, тука нешто се смени. Постои некаква апликација. Беше избран нов лидер, кој е одговорен, на пример, за обработка на операциите за пишување. И ние сакаме да ги реплицираме податоците. Едно решение е да го ставите во јамка. И ние постојано ја преиспитуваме нашата услуга - дали нешто се смени? Втората опција е пооптимална. Ова е механизам за часовник кој ви овозможува да ги известите клиентите дека нешто се променило. Ова е поевтин метод во однос на ресурсите и попогоден за клиентите.
Клиент е корисникот кој користи ZooKeeper.
Серверот е самиот процес на ZooKeeper.
Znode е клучната работа во ZooKeeper. Сите зноди се складирани во меморија од ZooKeeper и се организирани во форма на хиерархиски дијаграм, во форма на дрво.
Постојат два типа на операции. Првата е ажурирање/запишување, кога некоја операција ја менува состојбата на нашето дрво. Дрвото е вообичаено.
И можно е клиентот да не исполни едно барање и да биде исклучен, но може да воспостави сесија преку која комуницира со ZooKeeper.
Моделот на податоци на ZooKeeper наликува на датотечен систем. Има стандарден корен и потоа одевме како низ директориумите што одат од коренот. А потоа каталогот на прво ниво, второ ниво. Сето ова е зноди.
Секој znode може да складира некои податоци, обично не многу големи, на пример, 10 килобајти. И секој znode може да има одреден број деца.
Знодите доаѓаат во неколку видови. Тие можат да се создадат. И кога креираме znode, го одредуваме типот на кој треба да припаѓа.
Постојат два вида. Првиот е ефемерното знаме. Знод живее во сесија. На пример, клиентот има воспоставено сесија. И се додека е жива оваа седница ќе постои. Ова е неопходно за да не се произведе нешто непотребно. Ова е исто така погодно за моменти кога ни е важно да складираме примитиви на податоци во рамките на сесија.
Вториот тип е секвенцијално знаме. Го зголемува бројачот на патот до znode. На пример, имавме директориум со апликација 1_5. И кога го создадовме првиот јазол, тој доби p_1, вториот - p_2. И кога го повикуваме овој метод секој пат, ја поминуваме целосната патека, означувајќи само дел од патеката, а овој број автоматски се зголемува бидејќи го означуваме типот на јазол - секвенцијален.
Редовна знода. Таа секогаш ќе живее и ќе го има името што и го кажуваме.
Друга корисна работа е знамето на часовникот. Ако го инсталираме, тогаш клиентот може да се претплати на некои настани за одреден јазол. Ќе ви покажам подоцна со пример како се прави ова. Самиот ZooKeeper го известува клиентот дека податоците на јазолот се променети. Сепак, известувањата не гарантираат дека пристигнале некои нови податоци. Тие едноставно велат дека нешто се сменило, па сепак треба да ги споредувате податоците подоцна со посебни повици.
И како што веќе реков, редоследот на податоците се одредува по килобајти. Нема потреба да се складираат големи текстуални податоци таму, бидејќи тоа не е база на податоци, тоа е сервер за координација на акции.
Ќе ви кажам малку за сесиите. Ако имаме повеќе сервери, тогаш можеме транспарентно да се движиме од сервер до сервер користејќи го идентификаторот на сесијата. Тоа е доста погодно.
Секоја сесија има некаков тајмаут. Сесијата се дефинира со тоа дали клиентот испраќа нешто до серверот за време на таа сесија. Ако тој не пренел ништо за време на тајмаутот, сесијата паѓа или клиентот може сам да ја затвори.
Нема толку многу функции, но можете да правите различни работи со ова API. Тој повик што го видовме создава создава znode и зема три параметри. Ова е патеката до znode, и таа мора да биде целосно наведена од коренот. И, исто така, ова се некои податоци што сакаме да ги пренесеме таму. И типот на знамето. И по создавањето го враќа патот до znode.
Второ, можете да го избришете. Трикот овде е што вториот параметар, покрај патеката до znode, може да ја специфицира верзијата. Според тоа, тој znode ќе биде избришан ако неговата верзија што ја префрливме е еквивалентна на онаа што всушност постои.
Ако не сакаме да ја провериме оваа верзија, тогаш едноставно го пренесуваме аргументот „-1“.
Трето, проверува дали постои znode. Враќа точно ако јазолот постои, неточно во спротивно.
И тогаш се појавува часовник со знаме, што ви овозможува да го следите овој јазол.
Можете да го поставите ова знаменце дури и на непостоечки јазол и да добивате известување кога ќе се појави. Ова исто така може да биде корисно.
Има уште неколку предизвици добие податоци. Јасно е дека можеме да примаме податоци преку znode. Можете исто така да користите часовник со знаме. Во овој случај, нема да се инсталира ако нема јазол. Затоа, треба да разберете дека постои, а потоа да примате податоци.
Исто така постои SetData. Тука ја пренесуваме верзијата. И ако го пренесеме ова, податоците за znode на одредена верзија ќе се ажурираат.
Можете исто така да наведете „-1“ за да ја исклучите оваа проверка.
Друг корисен метод е земи деца. Можеме да добиеме и листа на сите зноди што му припаѓаат. Можеме да го следиме ова со поставување на часовник со знаме.
И метод синхронизирате овозможува сите промени да се испраќаат одеднаш, со што се осигурува дека тие се зачувани и сите податоци се целосно променети.
Ако цртаме аналогии со редовното програмирање, тогаш кога користите методи како што се запишување, кои пишуваат нешто на дискот и откако ќе ви врати одговор, нема гаранција дека сте ги напишале податоците на дискот. И дури и кога оперативниот систем е уверен дека сè е напишано, во самиот диск има механизми каде што процесот минува низ слоеви на бафери и дури после тоа податоците се ставаат на дискот.
Најчесто се користат асинхрони повици. Ова му овозможува на клиентот да работи паралелно со различни барања. Можете да го користите синхрониот пристап, но тој е помалку продуктивен.
Двете операции за кои зборувавме се ажурирање/запишување, кои ги менуваат податоците. Тоа се креирање, поставување податоци, синхронизација, бришење. И читај постои, getData, getChildren.
Сега неколку примери за тоа како можете да направите примитиви за работа во дистрибуиран систем. На пример, поврзано со конфигурацијата на нешто. Се појави нов работник. Ја додадовме машината и го започнавме процесот. И тука се следните три прашања. Како го бара ZooKeeper за конфигурација? И ако сакаме да ја смениме конфигурацијата, како да ја промениме? И откако го сменивме, како добиваат тие работници што ги имавме?
ZooKeeper го прави ова релативно лесно. На пример, тука е нашето дрво znode. Тука има јазол за нашата апликација, креираме дополнителен јазол во него, кој содржи податоци од конфигурацијата. Овие може или не мора да бидат посебни параметри. Бидејќи големината е мала, големината на конфигурацијата е обично мала, така што е сосема можно да се складира овде.
Го користите методот добие податоци за да се добие конфигурацијата за работникот од јазолот. Поставете точно. Ако поради некоја причина овој јазол не постои, ќе бидеме информирани за тоа кога ќе се појави или кога ќе се промени. Ако сакаме да знаеме дека нешто се променило, тогаш го поставуваме на вистина. И ако податоците во овој јазол се променат, ќе знаеме за тоа.
SetData. Ги поставуваме податоците, поставуваме „-1“, односно не ја проверуваме верзијата, претпоставуваме дека секогаш имаме една конфигурација, не треба да складираме многу конфигурации. Ако треба да складирате многу, ќе треба да додадете уште едно ниво. Овде веруваме дека има само една, па ја ажурираме само најновата, за да не ја проверуваме верзијата. Во овој момент, сите клиенти кои претходно се претплатиле добиваат известување дека нешто се променило во овој јазол. И откако ќе го примат, исто така мора повторно да ги побараат податоците. Известувањето е дека не ги добиваат самите податоци, туку само известување за промени. По ова тие мора да побараат нови податоци.
Втората опција за користење на примитивот е членство во група. Имаме дистрибуирана апликација, има еден куп работници и сакаме да разбереме дека сите се на место. Затоа, тие мора да се пријават дека работат во нашата апликација. И, исто така, сакаме да дознаеме, или од процесот Master или на друго место, за сите активни работници што ги имаме во моментов.
Како го правиме ова? За апликацијата, создаваме работнички јазол и додаваме подниво таму користејќи го методот креирање. Имам грешка на слајдот. Тука ви треба последователен наведете, тогаш сите работници ќе бидат создадени еден по еден. И апликацијата, барајќи ги сите податоци за децата од овој јазол, ги прима сите активни работници што постојат.
Ова е толку страшна имплементација за тоа како ова може да се направи во Java кодот. Да почнеме од крајот, со главниот метод. Ова е нашата класа, ајде да го создадеме нејзиниот метод. Како прв аргумент го користиме домаќинот, каде што се поврзуваме, односно го поставуваме како аргумент. А вториот аргумент е името на групата.
Како се случува врската? Ова е едноставен пример на API што се користи. Сè е релативно едноставно овде. Постои стандардна класа ZooKeeper. Им подаваме домаќини. И поставете го тајмаутот, на пример, на 5 секунди. И ние имаме член наречен connectSignal. Во суштина, создаваме група по должината на пренесената патека. Таму не пишуваме податоци, иако нешто можело да се напише. И јазолот овде е од перзистентен тип. Во суштина, ова е обичен редовен јазол кој ќе постои цело време. Тука се креира сесијата. Ова е имплементација на самиот клиент. Нашиот клиент ќе испраќа периодични пораки што укажуваат дека сесијата е жива. И кога ќе ја завршиме сесијата, повикуваме затворање и готово, сесијата паѓа. Ова е во случај да ни падне нешто, па ZooKeeper да дознае за тоа и да ја прекине сесијата.
Како да заклучите ресурс? Тука сè е малку покомплицирано. Имаме сет на работници, има некој ресурс што сакаме да го заклучиме. За да го направите ова, создаваме посебен јазол, на пример, наречен lock1. Ако можевме да го создадеме, тогаш добивме брава овде. И ако не можевме да го создадеме, тогаш работникот се обидува да добие getData од тука, и бидејќи јазолот е веќе создаден, тогаш ставаме набљудувач овде и во моментот кога ќе се промени состојбата на овој јазол, ќе знаеме за тоа. И можеме да се обидеме да имаме време да го пресоздадеме. Ако го зедовме овој јазол, го зедовме ова заклучување, тогаш откако повеќе не ни треба заклучувањето, ќе го напуштиме, бидејќи јазолот постои само во рамките на сесијата. Според тоа, ќе исчезне. И друг клиент, во рамките на друга сесија, ќе може да ја преземе бравата на овој јазол, или подобро кажано, ќе добие известување дека нешто се променило и може да се обиде да го направи тоа навреме.
Друг пример за тоа како можете да го изберете главниот лидер. Ова е малку покомплицирано, но и релативно едноставно. Што се случува овде? Постои главен јазол кој ги собира сите работници. Се обидуваме да добиеме податоци за лидерот. Ако ова се случи успешно, односно добивме некои податоци, тогаш нашиот работник почнува да го следи овој лидер. Тој смета дека веќе има лидер.
Ако лидерот умрел поради некоја причина, на пример, паднал, тогаш се обидуваме да создадеме нов лидер. И ако успееме, тогаш нашиот работник станува лидер. И ако некој во овој момент успеа да создаде нов лидер, тогаш се обидуваме да разбереме кој е тоа и потоа да го следиме.
Овде се јавува таканаречениот ефект на стадо, односно ефектот на стадото, бидејќи кога ќе умре лидерот, тој што е прв во времето ќе стане лидер.
Кога фаќате ресурс, можете да се обидете да користите малку поинаков пристап, кој е како што следува. На пример, сакаме да добиеме брава, но без херт ефект. Ќе се состои во тоа што нашата апликација бара списоци со сите идентификатори на јазли за веќе постоечки јазол со заклучување. И ако пред тоа јазолот за кој создадовме брава е најмалиот од множеството што го добивме, тогаш тоа значи дека сме ја заробиле бравата. Проверуваме дали сме добиле брава. Како проверка, ќе има услов идентификацијата што ја добивме при креирање на нова брава да биде минимална. И ако го добивме, тогаш работиме понатаму.
Ако има одреден id кој е помал од нашата брава, тогаш ставаме набљудувач на овој настан и чекаме известување додека нешто не се промени. Односно, ја добивме оваа брава. И додека не падне, нема да станеме минимален ид и нема да го добиеме минималното заклучување, а со тоа ќе можеме да се најавиме. И ако овој услов не е исполнет, тогаш веднаш одиме овде и се обидуваме повторно да ја земеме оваа брава, бидејќи можеби нешто се променило во ова време.
Од што се состои ZooKeeper? Има 4 главни работи. Ова е процеси на обработка - Барање. И, исто така, ZooKeeper Atomic Broadcast. Постои Commit Log каде што се евидентираат сите операции. И самиот во меморијата Replicated DB, односно самата база на податоци каде што е зачувано целото дрво.
Вреди да се напомене дека сите операции за пишување минуваат низ Процесорот за барање. И операциите за читање одат директно во базата на податоци во меморијата.
Самата база на податоци е целосно реплицирана. Сите примероци на ZooKeeper складираат целосна копија од податоците.
За да се врати базата на податоци по падот, постои дневник на Commit. Стандардна практика е дека пред податоците да влезат во меморијата, тие се запишуваат таму, така што ако се урна, овој дневник може да се репродуцира и да се врати состојбата на системот. Исто така, се користат периодични снимки од базата на податоци.
ZooKeeper Atomic Broadcast е нешто што се користи за одржување на реплицирани податоци.
ZAB интерно избира лидер од гледна точка на јазолот ZooKeeper. Другите јазли стануваат нејзини следбеници и очекуваат некои постапки од неа. Ако добијат записи, тие ги проследуваат сите до лидерот. Прво прави операција за пишување, а потоа им испраќа порака за тоа што се променило на неговите следбеници. Ова, всушност, мора да се изврши атомски, т.е. операцијата за снимање и емитување на целата работа мора да се изврши атомски, со што се гарантира конзистентност на податоците.
Обработува само барања за пишување. Неговата главна задача е да ја трансформира операцијата во трансакциско ажурирање. Ова е специјално генерирано барање.
И тука вреди да се напомене дека немоќта на ажурирањата за истата операција е загарантирана. Што е тоа? Оваа работа, ако се изврши двапати, ќе ја има истата состојба, односно самото барање нема да се промени. И ова треба да се направи така што во случај на несреќа, можете да ја рестартирате операцијата, а со тоа да ги вратите промените што паднале во моментот. Во овој случај, состојбата на системот ќе стане иста, односно не треба да се случува низа од истите, на пример, процеси на ажурирање, да доведат до различни конечни состојби на системот.
Извор: www.habr.com