"Hadoop. ZooKeeper" лекциясының транскрипциясын "Hadoop-та үлкен көлемдегі мәліметтерді үлестірілген өңдеу әдістері" сериясынан оқуды ұсынамын.
ZooKeeper дегеніміз не, оның Hadoop экожүйесіндегі орны. Бөлінген есептеулер туралы жалған ақпарат. Стандартты үлестірілген жүйенің диаграммасы. Бөлінген жүйелерді үйлестірудегі қиындықтар. Координацияның типтік мәселелері. ZooKeeper дизайнының принциптері. ZooKeeper деректер үлгісі. znode жалаулары. Сеанстар. Клиент API. Примитивтер (конфигурация, топ мүшелігі, қарапайым құлыптар, лидерді сайлау, табын әсерінсіз құлыптау). ZooKeeper архитектурасы. ZooKeeper DB. ZAB. Сұраныс өңдеушісі.
Бүгін біз 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. Жұмысшылар мен құлдық процестерді басқаратын Мастер процесі бар. Ол тапсырмаларды үйлестіруге және бөлуге, жұмысшыларды қайта іске қосуға, жаңаларын іске қосуға және жүктемені бөлуге жауапты.
Неғұрлым жетілдірілген нәрсе - Үйлестіру қызметі, яғни үйлестіру тапсырмасының өзін бөлек процеске жылжытыңыз, сонымен қатар сақтық көшірме немесе күту шеберінің қандай да бір түрін параллельді іске қосыңыз, себебі Мастер сәтсіз болуы мүмкін. Ал егер Мастер құласа, онда біздің жүйе жұмыс істемейді. Біз сақтық көшірме жасаудамыз. Кейбіреулер Мастер сақтық көшірме жасау үшін көшіру қажет екенін айтады. Мұны Үйлестіру қызметіне де тапсыруға болады. Бірақ бұл диаграммада шебердің өзі жұмысшыларды үйлестіруге жауап береді; мұнда қызмет деректерді қайталау әрекеттерін үйлестіреді.
Неғұрлым жетілдірілген опция - әдетте орындалатындай, барлық үйлестіруді біздің қызмет атқаратын кезде. Ол барлығының жұмыс істейтініне көз жеткізу үшін жауапкершілік алады. Егер бірдеңе жұмыс істемесе, біз бұл туралы білеміз және бұл жағдайдан шығуға тырысамыз. Қалай болғанда да, бізде қандай да бір түрде құлдармен өзара әрекеттесетін және қандай да бір қызмет арқылы деректер, ақпарат, хабарламалар және т.б. жібере алатын Мастер қалды.
Одан да жетілдірілген схема бар, бізде Мастер болмаған кезде, барлық түйіндер өздерінің мінез-құлқында әртүрлі шебер құлдар болып табылады. Бірақ олар әлі де бір-бірімен өзара әрекеттесуі керек, сондықтан бұл әрекеттерді үйлестіру үшін әлі де біраз қызмет қалады. Мүмкін, осы принцип бойынша жұмыс істейтін Кассандра бұл схемаға сәйкес келеді.
Бұл схемалардың қайсысы жақсы жұмыс істейтінін айту қиын. Әрқайсысының өз артықшылықтары мен кемшіліктері бар.
Ұстазбен кейбір нәрселерден қорқудың қажеті жоқ, өйткені тәжірибе көрсеткендей, ол үнемі қызмет етуге соншалықты сезімтал емес. Мұнда ең бастысы - бұл қызметті бөлек қуатты түйінде орналастыру үшін дұрыс шешімді таңдау, оның ресурстары жеткілікті болуы үшін, мүмкін болса, пайдаланушылар бұл процесті кездейсоқ өлтіріп алмас үшін. Бірақ сонымен бірге мұндай схемада жұмысшыларды Мастер-процесстен басқару әлдеқайда оңай, яғни бұл схема іске асыру тұрғысынан оңайырақ.
Және бұл схема (жоғарыда) күрделірек, бірақ сенімдірек.
Негізгі мәселе - ішінара сәтсіздіктер. Мысалы, біз желі арқылы хабарлама жіберген кезде қандай да бір апат орын алады және хабарламаны жіберген адам оның хабарламасының қабылданғанын және қабылдаушы жағында не болғанын білмейді, хабарламаның дұрыс өңделгенін білмейді. , яғни ол ешқандай растауды алмайды.
Тиісінше, біз бұл жағдайды өңдеуіміз керек. Ең қарапайым нәрсе - бұл хабарламаны қайта жіберу және біз жауап алғанша күту. Бұл жағдайда қабылдағыштың күйінің өзгергені ескерілмейді. Біз хабар жіберіп, бір деректерді екі рет қоса аламыз.
ZooKeeper мұндай бас тартумен күресу жолдарын ұсынады, бұл да біздің өмірімізді жеңілдетеді.
Біраз бұрын айтылғандай, бұл көп ағынды бағдарламаларды жазуға ұқсайды, бірақ басты айырмашылығы - біз әртүрлі машиналарда құрастыратын таратылған қолданбаларда, байланысудың жалғыз жолы - Желі. Негізінде, бұл ортақ ештеңе жоқ архитектура. Бір машинада жұмыс істейтін әрбір процесс немесе қызметтің өзінің жеке жады, өзінің дискісі, ешкіммен бөліспейтін өз процессоры болады.
Егер біз көп ағынды программаны бір компьютерде жазсақ, онда мәліметтер алмасу үшін ортақ жадты пайдалана аламыз. Бізде контекстік қосқыш бар, процестер ауыса алады. Бұл өнімділікке әсер етеді. Бір жағынан, кластердегі бағдарламада мұндай нәрсе жоқ, бірақ желіде проблемалар бар.
Тиісінше, бөлінген жүйелерді жазу кезінде туындайтын негізгі мәселелер конфигурация болып табылады. Біз қандай да бір өтініш жазып жатырмыз. Егер бұл қарапайым болса, онда біз кодтағы барлық сандарды қатаң кодтаймыз, бірақ бұл ыңғайсыз, өйткені жарты секундтық күту уақытының орнына бір секунд күту керек деп шешсек, онда қосымшаны қайта құрастыру керек және бәрін қайтадан жайыңыз. Бұл бір машинада болғанда, оны жай ғана қайта іске қосуға болатын нәрсе, бірақ бізде көптеген машиналар болған кезде, біз үнемі бәрін көшіріп алуымыз керек. Біз қолданбаны конфигурациялауға тырысуымыз керек.
Бұл жерде біз жүйелік процестер үшін статикалық конфигурация туралы айтып отырмыз. Бұл толығымен емес, мүмкін операциялық жүйе тұрғысынан, бұл біздің процестер үшін статикалық конфигурация болуы мүмкін, яғни бұл жай ғана қабылданбайтын және жаңартылмайтын конфигурация.
Сондай-ақ динамикалық конфигурация бар. Бұл параметрлерді біз бірден өзгерткіміз келеді, сонда олар сол жерден алынады.
Мұнда қандай мәселе бар? Біз конфигурацияны жаңарттық, оны шығардық, сонда не болады? Мәселе мынада болуы мүмкін, бір жағынан біз конфигурацияны шығардық, бірақ жаңа нәрсені ұмытып кеттік, конфигурация сол жерде қалды. Екіншіден, біз шығарған кезде конфигурация кейбір жерлерде жаңартылды, бірақ басқаларында емес. Бір машинада жұмыс істейтін қолданбамыздың кейбір процестері жаңа конфигурациямен және бір жерде ескі конфигурациямен қайта іске қосылды. Бұл біздің таратылған қолданбамыздың конфигурация тұрғысынан сәйкес келмеуіне әкелуі мүмкін. Бұл мәселе жиі кездеседі. Динамикалық конфигурация үшін ол маңыздырақ, себебі ол оны жылдам өзгертуге болатынын білдіреді.
Тағы бір мәселе – топтық мүшелік. Бізде әрқашан жұмысшылар бар, олардың қайсысы тірі, қайсысы өлі екенін білгіміз келеді. Егер Мастер болса, онда ол есептеулерді немесе деректермен жұмыс істеу үшін клиенттерге қай жұмысшыларды қайта бағыттауға болатынын түсінуі керек, ал қайсысы мүмкін емес. Үнемі туындайтын мәселе - біздің кластерде кім жұмыс істейтінін білуіміз керек.
Тағы бір типтік мәселе – көшбасшы сайлауы, біз кімнің басқаратынын білгіміз келеді. Бір мысал - бізде жазу операцияларын қабылдайтын, содан кейін оларды басқа процестер арасында қайталайтын кейбір процесс болған кезде репликация. Ол басшы болады, қалғандары оған бағынады, соңынан ереді. Екі басшы таңдалып қалмас үшін, әркім үшін бір мағыналы болатындай процесті таңдау керек.
Сондай-ақ өзара эксклюзивті қолжетімділік бар. Мұндағы мәселе күрделірек. Мутекс деген нәрсе бар, сіз көп ағынды бағдарламаларды жазғанда және қандай да бір ресурсқа, мысалы, жад ұяшығына қол жеткізгіңіз келсе, шектелген және тек бір ағынмен орындалатын болады. Мұнда ресурс дерексіз нәрсе болуы мүмкін. Біздің Желіміздің әртүрлі түйіндеріндегі әртүрлі қолданбалар тек берілген ресурсқа эксклюзивті рұқсат алуы керек және оны әркім өзгерте алатындай немесе сол жерде бірдеңе жаза алатындай емес. Бұл құлыптар деп аталатындар.
ZooKeeper барлық осы мәселелерді бір дәрежеде шешуге мүмкіндік береді. Мен мұны қалай жасауға мүмкіндік беретінін мысалдармен көрсетемін.
Бұғаттау примитивтері жоқ. Біз бір нәрсені пайдалана бастағанда, бұл қарабайыр кез келген оқиғаның орын алуын күтпейді. Сірә, бұл нәрсе асинхронды түрде жұмыс істейді, осылайша процестер бірдеңені күтіп тұрғанда тоқтап қалмауға мүмкіндік береді. Бұл өте пайдалы нәрсе.
Клиенттің барлық сұраулары жалпы кезек тәртібімен өңделеді.
Клиенттердің кейбір күйдегі өзгерістер туралы, деректердегі өзгерістер туралы хабарламаны клиент өзгертілген деректерді өзі көрмей тұрып алу мүмкіндігі бар.
ZooKeeper екі режимде жұмыс істей алады. Біріншісі дербес, бір түйінде. Бұл тестілеуге ыңғайлы. Ол сондай-ақ серверлердің кез келген санында кластерлік режимде жұмыс істей алады. Егер бізде 100 станоктан тұратын кластер болса, онда оның 100 станокта жұмыс істеуі міндетті емес. ZooKeeper іске қосуға болатын бірнеше машинаны таңдау жеткілікті. Және ол жоғары қолжетімділік принципін ұстанады. Әрбір іске қосылған данада ZooKeeper деректердің толық көшірмесін сақтайды. Оның қалай істейтінін кейінірек айтамын. Ол деректерді бөлмейді немесе оны бөлмейді. Бір жағынан, біз көп нәрсені сақтай алмайтын минус, екінші жағынан, мұны істеудің қажеті жоқ. Ол үшін әзірленген емес, бұл дерекқор емес.
Деректерді клиент жағында кэштеуге болады. Бұл стандартты принцип, сондықтан біз қызметке кедергі жасамаймыз және оны бірдей сұраулармен жүктемейміз. Ақылды клиент әдетте бұл туралы біледі және оны кэштейді.
Мысалы, мұнда бір нәрсе өзгерді. Қолданбаның бір түрі бар. Жаңа басшы сайланды, ол, мысалы, жазу операцияларын өңдеуге жауапты. Және біз деректерді қайталағымыз келеді. Бір шешім - оны циклге қою. Біз өз қызметімізге үнемі күмән келтіреміз - бірдеңе өзгерді ме? Екінші нұсқа тиімдірек. Бұл клиенттерге бір нәрсенің өзгергені туралы хабарлауға мүмкіндік беретін сағат механизмі. Бұл ресурстар тұрғысынан арзанырақ әдіс және клиенттер үшін қолайлырақ.
Клиент – ZooKeeper қолданбасын пайдаланатын пайдаланушы.
Сервер ZooKeeper процесінің өзі болып табылады.
Znode - ZooKeeper-дегі басты нәрсе. Барлық znode ZooKeeper жадында сақталады және иерархиялық диаграмма түрінде, ағаш түрінде ұйымдастырылған.
Операциялардың екі түрі бар. Біріншісі - жаңарту/жазу, кейбір әрекеттер ағаштың күйін өзгерткен кезде. Ағаш қарапайым.
Клиент бір сұрауды орындамай, ажыратылып қалуы мүмкін, бірақ ол ZooKeeper-пен өзара әрекеттесетін сеанс орната алады.
ZooKeeper деректер үлгісі файлдық жүйеге ұқсайды. Стандартты түбір бар, содан кейін біз түбірден өтетін каталогтар арқылы өткендей болдық. Содан кейін бірінші деңгейдің каталогы, екінші деңгей. Мұның бәрі znodes.
Әрбір znode кейбір деректерді сақтай алады, әдетте өте үлкен емес, мысалы, 10 килобайт. Және әрбір зонада белгілі бір бала саны болуы мүмкін.
Знодтар бірнеше түрге бөлінеді. Оларды жасауға болады. Ал znode құру кезінде оның қай типке жататынын көрсетеміз.
Екі түрі бар. Біріншісі – эфемерлі ту. Znode сеанс ішінде өмір сүреді. Мысалы, клиент сеанс орнатты. Және бұл сессия тірі болғанша, ол бар. Бұл қажетсіз нәрсені жасамау үшін қажет. Бұл сеанс ішінде деректер примитивтерін сақтау біз үшін маңызды болған сәттер үшін де қолайлы.
Екінші түрі - тізбекті жалау. Ол znode жолында есептегішті ұлғайтады. Мысалы, бізде 1_5 қолданбасы бар каталог болды. Ал біз бірінші түйінді жасағанда, ол p_1, екіншісі - p_2 алды. Ал біз бұл әдісті әр жолы шақырған кезде жолдың бір бөлігін ғана көрсете отырып, толық жолды өткіземіз және бұл сан автоматты түрде өседі, өйткені біз түйін түрін – тізбекті көрсетеміз.
Тұрақты түйін. Ол әрқашан өмір сүреді және біз оған айтатын есімге ие болады.
Тағы бір пайдалы нәрсе - сағат жалауы. Егер біз оны орнатсақ, онда клиент белгілі бір түйін үшін кейбір оқиғаларға жазыла алады. Мұның қалай жасалатынын кейінірек мысалмен көрсетемін. ZooKeeper өзі клиентке түйіндегі деректер өзгергенін хабарлайды. Дегенмен, хабарландырулар кейбір жаңа деректердің келгеніне кепілдік бермейді. Олар жай ғана бірдеңе өзгерді деп айтады, сондықтан деректерді кейінірек бөлек қоңыраулармен салыстыруға тура келеді.
Жоғарыда айтқанымдай, деректердің реті килобайттармен анықталады. Онда үлкен мәтіндік деректерді сақтаудың қажеті жоқ, себебі бұл деректер базасы емес, бұл әрекетті үйлестіру сервері.
Мен сеанстар туралы аздап айтып беремін. Егер бізде бірнеше серверлер болса, онда сеанс идентификаторын пайдаланып серверден серверге мөлдір түрде ауыса аламыз. Бұл өте ыңғайлы.
Әрбір сеанстың қандай да бір күту уақыты бар. Сеанс клиенттің сол сеанс кезінде серверге бірдеңе жіберетін-жібермейтінімен анықталады. Егер күту уақытында ол ештеңе жібермесе, сеанс тоқтатылады немесе клиент оны өзі жаба алады.
Оның соншалықты көп мүмкіндіктері жоқ, бірақ бұл API арқылы әртүрлі әрекеттерді орындауға болады. Біз көрген бұл шақыру құру znode жасайды және үш параметрді қабылдайды. Бұл znode жолы және ол түбірден толық көрсетілуі керек. Сондай-ақ бұл біз сонда тасымалдағымыз келетін кейбір деректер. Және тудың түрі. Ал жасалғаннан кейін ол znode жолын қайтарады.
Екіншіден, оны жоюға болады. Мұндағы қулық мынада, екінші параметр znode жолына қосымша нұсқаны көрсете алады. Тиісінше, егер оның біз жіберген нұсқасы шын мәнінде бар нұсқаға тең болса, бұл znode жойылады.
Егер біз бұл нұсқаны тексергіміз келмесе, біз жай ғана «-1» аргументін өткіземіз.
Үшіншіден, znode бар-жоғын тексереді. Түйін бар болса ақиқат, әйтпесе жалған мәнін қайтарады.
Содан кейін осы түйінді бақылауға мүмкіндік беретін жалауша сағаты пайда болады.
Бұл жалаушаны тіпті жоқ түйінге орнатуға және ол пайда болған кезде хабарландыру алуға болады. Бұл да пайдалы болуы мүмкін.
Тағы бірнеше қиындықтар бар деректер алу. Біз znode арқылы деректерді қабылдай алатынымыз анық. Сіз сондай-ақ жалауша сағатын пайдалана аласыз. Бұл жағдайда түйін болмаса, ол орнатылмайды. Сондықтан оның бар екенін түсіну керек, содан кейін деректерді алу керек.
Сондай-ақ бар SetData. Мұнда біз нұсқаны береміз. Ал егер біз мұны тапсырсақ, белгілі бір нұсқаның znode деректері жаңартылады.
Сондай-ақ бұл тексеруді алып тастау үшін «-1» көрсетуге болады.
Тағы бір пайдалы әдіс Балаларды алыңыз. Біз сондай-ақ оған жататын барлық znode тізімін ала аламыз. Біз мұны жалауша сағатын орнату арқылы бақылай аламыз.
Және әдіс синхрондау барлық өзгерістерді бірден жіберуге мүмкіндік береді, осылайша олардың сақталуын және барлық деректердің толығымен өзгертілгенін қамтамасыз етеді.
Егер біз кәдімгі бағдарламалаумен ұқсастықтар жасасақ, онда дискіге бірдеңе жазатын жазу сияқты әдістерді қолданғанда және ол сізге жауап қайтарғаннан кейін деректерді дискіге жазғаныңызға кепілдік жоқ. Тіпті операциялық жүйе бәрі жазылғанына сенімді болса да, дискінің өзінде процесс буфер қабаттары арқылы өтетін механизмдер бар, содан кейін ғана деректер дискіге орналастырылады.
Негізінен асинхронды шақырулар қолданылады. Бұл клиентке әртүрлі сұраныстармен қатар жұмыс істеуге мүмкіндік береді. Синхронды тәсілді қолдануға болады, бірақ оның өнімділігі төмен.
Біз айтқан екі операция деректерді өзгертетін жаңарту/жазу. Бұл жасау, орнату деректері, синхрондау, жою. Ал оқу бар, getData, getChildren.
Енді таратылған жүйеде жұмыс істеу үшін примитивтерді қалай жасауға болатынының бірнеше мысалдары. Мысалы, бір нәрсенің конфигурациясына қатысты. Жаңа жұмысшы пайда болды. Біз машинаны қосып, процесті бастадық. Ал келесі үш сұрақ бар. ZooKeeper конфигурациясын қалай сұрайды? Ал егер конфигурацияны өзгерткіміз келсе, оны қалай өзгертеміз? Ал біз оны өзгерткеннен кейін бізде болған жұмысшылар оны қалай алады?
ZooKeeper мұны салыстырмалы түрде жеңілдетеді. Мысалы, біздің znode ағашы бар. Мұнда біздің қосымшамыз үшін түйін бар, біз онда конфигурация деректерін қамтитын қосымша түйін жасаймыз. Бұл жеке параметрлер болуы немесе болмауы мүмкін. Көлемі кішкентай болғандықтан, конфигурация өлшемі де әдетте кішкентай, сондықтан оны осында сақтау әбден мүмкін.
Сіз әдісті қолданасыз деректер алу түйіннен жұмысшыға арналған конфигурацияны алу үшін. Шын мәніне орнатыңыз. Егер қандай да бір себептермен бұл түйін жоқ болса, ол пайда болған кезде немесе ол өзгерген кезде бізге хабарланады. Егер біз бір нәрсенің өзгергенін білгіміз келсе, оны шындыққа қоямыз. Ал егер бұл түйіндегі деректер өзгерсе, біз бұл туралы білетін боламыз.
SetData. Біз деректерді орнатамыз, «-1» орнаттық, яғни нұсқаны тексермейміз, бізде әрқашан бір конфигурация бар деп есептейміз, көптеген конфигурацияларды сақтаудың қажеті жоқ. Егер сізге көп нәрсені сақтау қажет болса, басқа деңгейді қосу керек. Мұнда біз тек біреуі бар деп есептейміз, сондықтан біз тек соңғысын жаңартамыз, сондықтан нұсқаны тексермейміз. Осы сәтте бұрын жазылған барлық клиенттер осы түйінде бір нәрсе өзгергені туралы хабарлама алады. Және олар оны алғаннан кейін деректерді қайтадан сұрауы керек. Хабарландыру олар деректерді өзі қабылдамайды, тек өзгерістер туралы хабарлама алады. Осыдан кейін олар жаңа деректерді сұрауы керек.
Примитивті пайдаланудың екінші нұсқасы топ мүшелігі. Бізде таратылған өтінім бар, жұмысшылар тобы бар және біз олардың барлығы орнында екенін түсінгіміз келеді. Сондықтан олар біздің қосымшамызда жұмыс істейтінін өздері тіркеуі керек. Сондай-ақ біз Мастер процесінен немесе басқа жерде қазіргі уақытта бар барлық белсенді жұмысшылар туралы білгіміз келеді.
Мұны қалай істейміз? Қолданба үшін біз жұмысшылар түйінін жасаймыз және оған құру әдісі арқылы ішкі деңгейді қосамыз. Слайдта қате бар. Мұнда сізге керек дәйекті көрсетіңіз, содан кейін барлық жұмысшылар бір-бірден құрылады. Осы түйіннің еншілестері туралы барлық деректерді сұрайтын қолданба бар барлық белсенді жұмысшыларды қабылдайды.
Бұл Java кодында мұны қалай жасауға болатынын өте қорқынышты іске асыру. Негізгі әдіспен соңынан бастайық. Бұл біздің сынып, оның әдісін жасайық. Бірінші аргумент ретінде біз қосылып жатқан хостты пайдаланамыз, яғни оны аргумент ретінде орнатамыз. Ал екінші аргумент – топтың аты.
Байланыс қалай жүзеге асады? Бұл қолданылатын API қарапайым мысалы. Мұнда бәрі салыстырмалы түрде қарапайым. ZooKeeper стандартты класы бар. Біз оған хосттарды жібереміз. Және күту уақытын, мысалы, 5 секундқа орнатыңыз. Ал бізде connectSignal деп аталатын мүше бар. Негізінде, біз жіберілетін жол бойымен топ жасаймыз. Біз ол жерде деректерді жазбаймыз, бірақ бірдеңе жазылуы мүмкін еді. Ал мұндағы түйін тұрақты типке жатады. Негізінде, бұл барлық уақытта болатын қарапайым тұрақты түйін. Бұл жерде сеанс жасалады. Бұл клиенттің өзін жүзеге асыру. Біздің клиент сеанстың тірі екенін көрсететін мерзімді хабарламалар жібереді. Біз сеансты аяқтаған кезде, біз жабу деп атаймыз және міне, сеанс тоқтайды. Бұл ZooKeeper бұл туралы біліп, сеансты тоқтату үшін бізге бірдеңе түсіп қалған жағдайда.
Ресурсты қалай құлыптау керек? Мұнда бәрі біршама күрделірек. Бізде жұмысшылар жинағы бар, біз құлыптауды қалайтын ресурс бар. Ол үшін біз бөлек түйін жасаймыз, мысалы, lock1 деп аталады. Егер біз оны жасай алсақ, онда біз мұнда құлып алдық. Егер біз оны жасай алмасақ, онда жұмысшы getData-ны осы жерден алуға тырысады және түйін әлдеқашан жасалғандықтан, біз мұнда бақылаушыны қоямыз және осы түйіннің күйі өзгерген кезде біз бұл туралы білетін боламыз. Біз оны қайта жасауға уақыт табуға тырысамыз. Егер біз осы түйінді алсақ, осы құлыпты алсақ, содан кейін бізге құлып қажет болмай қалғаннан кейін, біз одан бас тартамыз, өйткені түйін тек сеанс ішінде бар. Тиісінше, ол жоғалады. Ал басқа клиент басқа сеанс аясында осы түйінде құлыпты ала алады, дәлірек айтсақ, ол бірдеңе өзгергені туралы хабарлама алады және оны уақытында орындауға тырысады.
Басты көшбасшыны таңдаудың тағы бір мысалы. Бұл сәл күрделірек, бірақ сонымен бірге салыстырмалы түрде қарапайым. Мұнда не болып жатыр? Барлық жұмысшыларды біріктіретін негізгі түйін бар. Біз көшбасшы туралы деректер алуға тырысамыз. Егер бұл сәтті орындалса, яғни біз кейбір мәліметтерді алдық, онда біздің жұмысшы осы көшбасшыға ілесе бастайды. Ол қазірдің өзінде көшбасшы бар деп есептейді.
Егер көшбасшы қандай да бір себептермен қайтыс болса, мысалы, құлап кетсе, біз жаңа көшбасшы құруға тырысамыз. Ал жетістікке жетсек, біздің жұмысшы көшбасшы болады. Егер біреу осы сәтте жаңа көшбасшы құра алса, біз оның кім екенін түсінуге тырысамыз, содан кейін оның соңынан ереміз.
Мұнда табын эффектісі, яғни табын әсері деп аталатын нәрсе туындайды, өйткені көшбасшы өлгенде, уақытында бірінші болған көшбасшы болады.
Ресурсты түсіру кезінде сәл басқа тәсілді қолдануға болады, ол келесідей. Мысалы, біз құлыпты алғымыз келеді, бірақ герт әсері жоқ. Бұл біздің қолданба құлпы бар бұрыннан бар түйін үшін барлық түйін идентификаторларының тізімін сұрайтындығынан тұрады. Ал егер бұған дейін біз құлыпты жасаған түйін біз алған жиынтықтың ең кішісі болса, онда бұл құлыпты басып алғанымызды білдіреді. Біз құлып алғанымызды тексереміз. Тексеру ретінде жаңа құлыпты жасау кезінде алған идентификатордың минималды болуы шарты болады. Ал алған болсақ, ары қарай жұмыс істейміз.
Егер құлыптан кішірек белгілі бір идентификатор болса, біз осы оқиғаға бақылаушыны қойып, бірдеңе өзгергенше хабарландыруды күтеміз. Яғни, біз бұл құлыпты алдық. Және ол құлағанша, біз минималды идентификатор болмаймыз және ең төменгі құлыпты алмаймыз, осылайша біз жүйеге кіре аламыз. Ал егер бұл шарт орындалмаса, біз бірден осы жерге барып, осы құлыпты қайтадан алуға тырысамыз, себебі осы уақыт ішінде бірдеңе өзгерген болуы мүмкін.
ZooKeeper неден тұрады? 4 негізгі нәрсе бар. Бұл өңдеу процестері - Сұраныс. Сондай-ақ ZooKeeper Atomic Broadcast. Барлық әрекеттер жазылатын Тапсырма журналы бар. Және жадтағы репликацияланған ДҚ өзі, яғни бұл бүкіл ағаш сақталатын дерекқордың өзі.
Айта кету керек, барлық жазу операциялары Сұраныс өңдеушісі арқылы өтеді. Ал оқу операциялары тікелей жадтағы дерекқорға өтеді.
Деректер қорының өзі толығымен қайталанады. ZooKeeper бағдарламасының барлық даналары деректердің толық көшірмесін сақтайды.
Бұзылғаннан кейін дерекқорды қалпына келтіру үшін Тапсырма журналы бар. Стандартты тәжірибе мынада, деректер жадқа түспес бұрын, ол бұзылса, бұл журналды ойнатуға және жүйе күйін қалпына келтіруге болатындай етіп сол жерде жазылады. Сондай-ақ деректер қорының мерзімді суреттері де қолданылады.
ZooKeeper Atomic Broadcast - қайталанатын деректерді сақтау үшін пайдаланылатын нәрсе.
ZAB ZooKeeper түйіні тұрғысынан көшбасшыны іштей таңдайды. Басқа түйіндер оның ізбасарларына айналады және одан кейбір әрекеттерді күтеді. Егер олар жазбаларды алса, олардың барлығын жетекшіге жібереді. Ол алдымен жазу әрекетін орындайды, содан кейін оның ізбасарларына не өзгергені туралы хабарлама жібереді. Бұл, шын мәнінде, атомдық түрде орындалуы керек, яғни барлық нәрсені жазу және тарату операциясы атомдық түрде орындалуы керек, осылайша деректердің сәйкестігіне кепілдік береді.
Ол тек жазу сұрауларын өңдейді. Оның негізгі міндеті операцияны транзакциялық жаңартуға түрлендіру болып табылады. Бұл арнайы жасалған сұрау.
Мұнда бір операция үшін жаңартулардың импульссіздігіне кепілдік берілгенін атап өткен жөн. Бұл не? Бұл нәрсе, егер екі рет орындалса, бірдей күйге ие болады, яғни сұраудың өзі өзгермейді. Бұл апат болған жағдайда операцияны қайта бастауға, осылайша қазіргі уақытта жойылған өзгерістерді кері қайтаруға болатындай етіп жасау керек. Бұл жағдайда жүйенің күйі бірдей болады, яғни бір қатарлар, мысалы, жаңарту процестері жүйенің әртүрлі соңғы күйлеріне әкеліп соқтырмауы керек.
Ақпарат көзі: www.habr.com