Прапаную азнаёміцца з расшыфроўкай лекцыі "Hadoop. ZooKeeper" з серыі "Метады размеркаванай апрацоўкі вялікіх аб'ёмаў дадзеных у Hadoop"
Што такое ZooKeeper, яго месца ў экасістэме Hadoop. Няпраўда аб размеркаваных вылічэннях. Схема стандартнай размеркаванай сістэмы. Складанасць каардынацыі размеркаваных сістэм. Тыповыя праблемы каардынацыі. Прынцыпы, закладзеныя ў дызайн ZooKeeper. Мадэль дадзеных ZooKeeper. Сцягі znode. Сесіі. Кліенцкі API. Прымітывы (configuration, group membership, simple locks, leader election, locking без herd effect). Архітэктура ZooKeeper. ZooKeeper DB. ZAB. Апрацоўшчык запытаў.
Сёння пагаворым пра ZooKeeper. Гэтая штука вельмі карысная. У яго, як у любога прадукта Apache Hadoop, ёсць лагатып. На ім намаляваны чалавек.
Да гэтага мы казалі ў асноўным, як там можна апрацоўваць дадзеныя, як іх захоўваць, г.зн. ужо імі неяк карыстацца і неяк з імі працаваць. А сёння хацелася б трошкі пагаварыць пра пабудову размеркаваных дадаткаў. І ZooKeeper - гэта адна з тых рэчаў, якая дазваляе гэтую справу спрасціць. Гэта нейкі сэрвіс, які прызначаны для нейкай каардынацыі ўзаемадзеяння працэсаў у размеркаваных сістэмах, у размеркаваных дадатках.
Патрэба ў такіх дадатках становіцца ўсё больш і больш з кожным днём, гэта тое, пра што наш курс. З аднаго боку, MapReduce і гэты гатовы фрэймворк дазваляе нівеліраваць гэтую складанасць і вызваліць праграміста ад напісання прымітываў такіх, як узаемадзеянне, каардынацыя працэсаў. Але з іншага боку, ніхто не гарантуе, што гэтага ўсё роўна не давядзецца рабіць. Не заўсёды MapReduce ці іншыя гатовыя фрэймворкі цалкам замяняюць нейкія выпадкі, якія нельга рэалізаваць на гэтым. У тым ліку і сам MapReduce і куча іншых праектаў апачавых, яны, па сутнасці, таксама з'яўляюцца размеркаванымі праграмамі. І для таго, каб пісаць было прасцей, напісалі ZooKeeper.
Як усе прыкладанні, звязаныя з Hadoop, ён быў распрацаваны ў кампаніі Yahoo! Цяпер гэта таксама афіцыйнае дадатак Apache. Яно не настолькі актыўна развіваецца як HBase. Калі вы зойдзеце ў JIRA HBase, то тамака кожны дзень з'яўляецца куча цягачаў на багі, куча прапаноў нешта аптымізаваць, т. е. стала ідзе жыццё ў праекце. А ZooKeeper, з аднаго боку, адносна просты прадукт, а з другога боку, гэта забяспечвае яго надзейнасць. І яго даволі лёгка выкарыстоўваць, таму ён стаў стандартам у дадатках у рамках экасістэмы Hadoop. Таму я падумаў, што было б карысна яго разгледзець, каб зразумець, як ён працуе і як ім скарыстацца.
Гэта карцінка, з нейкай лекцыі, якая ў нас была. Можна сказаць, што ён артаганальны ўсяму таму, што мы да гэтага разглядалі. І ўсё, што тут паказана, у той ці іншай ступені працуе з ZooKeeper, т. е. - гэта сэрвіс, які выкарыстоўвае ўсе гэтыя прадукты. Ні HDFS, ні MapReduce не пішуць сваіх падобных сэрвісаў, якія для іх спецыяльна працавалі б. Адпаведна, выкарыстоўваецца ZooKeeper. І гэта спрашчае распрацоўку і нейкія рэчы, звязаныя з памылкамі.
Адкуль усё гэта зьяўляецца? Здавалася б, запусцілі два прыкладанні паралельна на розных кампутарах, злучылі іх шнурком ці ў сетку, і ўсё працуе. Але праблема ў тым, што Сетка ненадзейная, а калі б вы зніфілі трафік ці паглядзелі, што там адбываецца на нізкім узроўні, як узаемадзейнічаюць кліенты ў Сеткі, то можна часта ўбачыць, што нейкія пакеты губляюцца, перасылаюцца. Нездарма прыдумалі пратаколы TCP, якія дазваляюць устанавіць нейкую сесію, гарантаваць дастаўку паведамленняў. Але ў любым выпадку не заўседы нават TCP можа ратаваць. Ва ўсяго ёсць таймаўт. Сетка можа проста на нейкі час адвальвацца. Яна можа проста міргаць. І гэта ўсё прыводзіць да таго, што нельга спадзявацца на тое, што Сетка надзейная. Гэта асноўнае адрозненне ад напісання паралельных прыкладанняў, якія працуюць на адным кампутары ці на нейкім адным суперкампутары, дзе Сеткі няма, дзе ёсць больш надзейная шына абмену дадзенымі ў памяці. І гэтае прынцыповае адрозненне.
Акрамя ўсяго іншага, выкарыстоўваючы Сетка, ёсць заўсёды нейкая latency. У дыска яна таксама ёсць, але ў Сеткі яна большая. Latency - гэта нейкі час затрымкі, якое можа быць як невялікім, так і даволі істотным.
Тапалогія Сеткі мяняецца. Што такое тапалогія - гэта размяшчэнне нашага сеткавага абсталявання. Ёсць дата-цэнтры, ёсць стойкі, якія там стаяць, ёсць свечкі. Усё гэта можа перападключаць, пераязджаць і г. д. Гэта ўсё таксама трэба ўлічваць. Змяняюцца айпішнікі, мяняюцца роўтынг, па якім у нас ходзіць трафік. Гэта таксама трэба ўлічваць.
Сетка таксама можа мяняцца ў плане абсталявання. З практыкі магу сказаць, што нашы сеткавыя інжынеры вельмі кахаюць перыядычна абнаўляць нешта на свечках. Раптам выйшла новая прашыўка, і іх не асабліва цікавіць нейкі кластар Hadoop. У іх свая праца. Для іх галоўнае, каб Сетка працавала. Адпаведна, яны хочуць там нешта перазаліць, зрабіць перапрашыўку на сваім жалезе, пры гэтым жалязякі таксама перыядычна мяняюцца. Усё гэта нейкім чынам трэба ўлічваць. Усё гэта ўплывае на наша размеркаванае дадатак.
Звычайна людзі, якія пачынаюць працаваць з вялікім аб'ёмам дадзеных, лічаць чамусьці, што Сетка бязмежная. Калі тамака ляжыць файл у некалькі тэрабайт, то можна яго ўзяць да сябе на сервер або на кампутар, адкрыць з дапамогай котка і глядзець. Яшчэ адна з памылак - гэта ў напор глядзець логі. Ніколі такога не рабіце, бо гэта дрэнна. Таму што Vim усё імкнецца буферызаваць, усё грузіць у памяць, асабліва, калі мы пачынаем па гэтым логу перамяшчацца і нешта шукаць. Гэта такія рэчы, пра якія забываюцца, але іх варта ўлічваць.
Прасцей напісаць адну праграму, якая працуе на адным кампутары з адным працэсарам.
Калі ў нас наша сістэма расце, мы жадаем усё гэта раўналежыць, прычым раўналежыць не толькі на кампутары, але і на кластары. Узнікае пытанне - як гэтую справу каардынаваць? Нашы праграмы могуць нават не ўзаемадзейнічаць паміж сабой, але мы паралельна на некалькіх серверах запусцілі некалькі працэсаў. І як маніторыць, што ўсё ў іх ідзе добра? Яны, напрыклад, што-небудзь адпраўляюць па Сеткі. Яны павінны кудысьці пісаць пра свой стан, напрыклад, у нейкую базу дадзеных ці ў лог, потым гэты лог агрэгаваць і потым недзе яго аналізаваць. Плюс трэба ўлічваць, што працэс працаваў-працаваў, раптоўна ў ім з'явілася нейкая памылка ці ён упаў, то як хутка мы пра гэта даведаемся?
Зразумела, што ўсё гэта хутка можна заманіторыць. Гэта таксама добра, але маніторынг - гэта абмежаваная рэч, якая дазваляе маніторыць нейкія рэчы на самым вышэйшым узроўні.
Калі мы хочам, каб нашыя працэсы пачалі ўзаемадзейнічаць паміж сабой, напрыклад, адпраўляць адзін аднаму нейкія дадзеныя, то тут таксама ўзнікае пытанне - як гэта будзе адбывацца? Ці не будзе нейкага race condition, ці не будуць яны перазапісваць адзін аднаго, ці даходзяць дадзеныя правільна, ці не губляецца нешта па дарозе? Трэба распрацоўваць нейкі пратакол і т. д.
Каардынацыя ўсіх гэтых працэсаў - рэч нетрывіяльная. І прымушае распрацоўніка апускацца на ўзровень яшчэ ніжэй, і пісаць сістэмы альбо з нуля, альбо не зусім з нуля, але гэта не так проста.
Калі вы прыдумалі крыптаграфічны алгарытм ці нават яго рэалізавалі, то вазьміце і выкіньце яго адразу, таму што, хутчэй за ўсё, ён у вас не будзе працаваць. У ім, хутчэй за ўсё, знойдзецца куча памылак, якія вы забыліся прадугледзець. Ні ў якім разе не выкарыстоўвайце яго для чагосьці сур'ёзнага, таму што, хутчэй за ўсё, ён няўстойлівым будзе. Бо ўсе алгарытмы, якія ёсць, яны вельмі доўга правяраюцца часам. У ім шукаюцца памылкі супольнасьцю. Гэта асобная тэма. І тое ж самае і тут. Калі ёсць магчымасць не рэалізоўваць нейкую сінхранізацыю працэсаў самастойна, то лепш гэтага не рабіць, таму што гэта даволі складана і заводзіць вас на зыбкі шлях пастаянных пошукаў памылак.
Мы сёння гаворым аб ZooKeeper. З аднаго боку - гэта фрэймворк, з другога боку, гэта сэрвіс, які дазваляе аблегчыць распрацоўніку жыццё і максімальна спрасціць рэалізацыю логікі і каардынацыю нашых працэсаў.
Успамінаем, як можа выглядаць стандартная размеркаваная сістэма. Гэта тое, пра што мы казалі - гэта HDFS, HBase. Ёсць Майстар-працэс, які кіруе воркерамі, slave-працэсамі. Ён займаецца каардынацыяй і размеркаваннем задач, перазапускам воркераў, запускам новых, размеркаваннем нагрузкі.
Больш прасунутая рэч - гэта Coordination Service, г. зн. саму задачу каардынацыі вынесці ў асобны працэс, плюс паралельна запускаць нейкі backup або stanby Майстры, таму што Майстар можа ўпасці. А калі Майстар упадзе, то сістэма наша не будзе працаваць. Мы запускаем backup. Нейкія станы, якія ёсць у Майстра, трэба рэпліцыраваць на backup. Гэта таксама можна даручыць Coordination Service. Але на гэтай схеме каардынацыяй воркераў займаецца сам Майстар, тут сэрвіс займаецца каардынацыяй дзеянняў па рэплікацыі дадзеных.
Больш прасунуты варыянт - гэта калі ўсёй каардынацыяй займаецца наш сэрвіс, як звычайна і робіцца. Ён бярэ на сябе адказнасць за тое, што ўсё працуе. А калі нешта не працуе, мы пра гэта даведаемся і спрабуем гэтую сітуацыю абысці. У любым выпадку ў нас застаецца Майстар, які неяк узаемадзейнічае яшчэ са slaves, праз нейкі сэрвіс можа адпраўляць дадзеныя, інфармацыю, паведамленні і т. д.
Ёсць яшчэ больш прасунутая схема, калі ў нас няма Майстры, усе ноды з'яўляюцца майстар-slaves, разназначнымі ў сваіх паводзінах. Але ўсё роўна ім трэба паміж сабой узаемадзейнічаць, таму ўсё роўна застаецца нейкі сэрвіс для каардынацыі гэтых дзеянняў. Мусіць, пад гэтую схему падыходзіць Cassandra, якая па такім прынцыпе працуе.
Складана сказаць, якая з гэтых схемаў лепш працуе. У кожнай ёсць свае мінусы і плюсы.
І не трэба баяцца нейкіх рэчаў з Майстрам, таму што, як паказвае практыка, не так ён схільны да таго, каб пастаянна падаць. Тут галоўнае - выбіраць правільнае рашэнне для размяшчэння гэтага сэрвісу на асобнай нодзе магутнай, каб у яе было дастаткова рэсурсаў, каб па магчымасці ў карыстальнікаў не было туды доступу, каб яны выпадкова не забілі гэты працэс. Але пры гэтым у такой схеме нашмат прасцей з Майстар-працэсу кіраваць воркерамі, т. е. гэтая схема прасцей з пункта гледжання рэалізацыі.
А гэтая схема (вышэй), мусіць, больш складаная, але больш надзейная.
Асноўная праблема - гэта partial failures. Напрыклад, калі мы адпраўляем паведамленне па Сеткі, адбываецца нейкая аварыя, і той, хто адправіў паведамленне, не даведаецца ці дайшло яго паведамленне і што адбылося на баку прымача, не даведаецца ці правільна паведамленне апрацавалася, т. е. ён не атрымае ніякага пацверджання.
Адпаведна, мы павінны гэтую сытуацыю апрацаваць. І самае простае - гэта пераадправіць гэтае паведамленне і чакаць, пакуль нам прыйдзе адказ. Пры гэтым нідзе не ўлічваецца ці змянілася стан прымача. Магчыма, мы адправім паведамленне і два разы дадалі адны і тыя ж дадзеныя.
ZooKeeper прапануе спосабы дужання з такімі адмовамі, што таксама спрашчае нам жыццё.
Як крыху раней гаварылася, гэта падобна на напісанне шматструменных праграм, але асноўнае адрозненне ў тым, што ў размеркаваных прыкладаннях, якія мы будуем на розных машынах, спосабам узаемадзеяння з'яўляецца толькі Сетка. Па сутнасці, гэта архітэктура shared-nothing. У кожнага працэсу ці сэрвісу, які працуе на адной машыне, ёсць свая памяць, свая кружэлка, свой працэсар, якім ён ні з кім не дзеліцца.
Калі мы пішам шматструменную праграму на адным кампутары, то мы можам выкарыстоўваць shared memory для абмену дадзенымі. У нас тамака ёсць context switch, працэсы могуць перамыкацца. Гэта ўплывае на прадукцыйнасць. З аднаго боку, у праграме на кластары такога няма, але ёсць праблемы з Сеткай.
Адпаведна, асноўныя праблемы, якія ўзнікаюць пры напісанні размеркаваных сістэм, гэта канфігурацыя. Мы пішам нейкі дадатак. Калі яно просценькае, то мы хардкадзім усякія цыферкі ў кодзе, але гэта няёмка, таму што калі мы вырашаем, што замест таймаўту ў паўсекунды мы жадаем таймаўт у адну секунду, то трэба перакампіляваць прыкладанне, усё зноўку раскачаць. Адна справа, калі гэта на адной машыне, калі можна проста перазапусціць, а калі ў нас шмат машын, то трэба ўсё ўвесь час капіяваць. Трэба старацца, каб прыкладанне было канфігуруемае.
Тут гаворыцца аб статычнай канфігурацыі для сістэмных працэсаў. Гэта не зусім, можа быць, з пункта гледжання аперацыйнай сістэмы, гэта можа быць статычная канфігурацыя для нашых працэсаў, т. е. гэта канфігурацыя, якую нельга проста ўзяць і абнавіць.
А таксама ёсць дынамічная канфігурацыя. Гэта параметры, якія мы жадаем змяняць на лёце, каб яны тамака падхапляліся.
У чым тут праблема? Абнавілі мы канфіг, выкацілі і што? Праблема можа быць у тым, што з аднаго боку мы выкацілі канфіг, а пра абноўку забылі, там застаўся канфіг. Па-другое, пакуль мы выкочвалі, недзе канфігурацыя абнавілася, а недзе не. І нейкія працэсы нашага прыкладання, якія працуюць на адной машыне перазапусцілі з новым канфігам, а недзе са старым. Гэта можа прыводзіць да таго, што наша размеркаванае прыкладанне будзе не ў кансістэнтнай стане з пункту гледжання канфігурацыі. Гэтая праблема агульная. Для дынамічнай канфігурацыі яна найболей актуальная, таму што разумеецца, што яе можна змяняць на лета.
Яшчэ адна праблема - гэта group membership. Заўсёды ў нас ёсць нейкі набор воркераў, мы заўсёды хочам ведаць - хто з іх жывы, хто з іх мёртвы. Калі ёсць Майстар, то ён павінен разумець, на якія воркеры можна перанакіроўваць кліентаў, каб яны запускалі вылічэнні ці працавалі з дадзенымі, а на якія нельга. Увесь час узнікае праблема, што трэба ведаць, хто ў нашым кластары працуе.
Яшчэ адна тыповая праблема - гэта leader election, калі мы хочам ведаць, хто адказны. Адзін з прыкладаў - гэта рэплікацыя, калі ў нас ёсць нейкі працэс, які прымае аперацыі на запіс і потым рэплікуе іх па астатніх працэсах. Ён будзе лідарам, усе астатнія будуць яму падпарадкоўвацца, будуць за ім ісці. Трэба выбіраць такі працэс, каб ён быў адназначны для ўсіх, каб не атрымалася так, што выбралася двое лідэраў.
Яшчэ ёсць mutually exclusive access. Тут праблема больш складаная. Ёсць такое паняцце як м'ютэкс, калі вы пішыце шматструменныя праграмы і жадаеце, каб доступ да нейкага рэсурсу, напрыклад, да вочка памяці, быў абмежаваны і ажыццяўляўся толькі адным струменем. Тут рэсурсам можа быць нешта больш абстрактнае. І розныя прыкладанні з розных нод нашай Сеткі павінны атрымліваць толькі эксклюзіўны доступ для дадзенага рэсурсу, а не так, каб усе маглі яго змяняць ці пісаць туды нешта. Гэта, так званыя, locks.
Усе гэтыя праблемы ZooKeeper дазваляе ў той ці іншай ступені вырашыць. І я пакажу на прыкладах, як ён дазваляе гэта зрабіць.
Няма блакавальных прымітываў. Калі мы пачынаем нешта выкарыстоўваць, гэты прымітыў не будзе чакаць надыходу якой-небудзь падзеі. Хутчэй за ўсё, гэтая штука будзе працаваць асінхронна, тым самым дазваляючы працэсам не завісаць у стане таго, што яны чагосьці чакаюць. Гэта вельмі карысная рэч.
Усе кліенцкія запыты апрацоўваюцца ў парадку агульнай чаргі.
І кліенты маюць магчымасць атрымліваць натыфікацыю аб зменах нейкага стану, аб зменах дадзеных, перш чым кліент убачыць самі змененыя дадзеныя.
ZooKeeper можа працаваць у двух рэжымах. Першы гэта standalone, на адной нодзе. Гэта зручна для тэсціравання. А таксама ён можа працаваць у рэжыме кластара, на любой колькасці сервераў. Калі ў нас кластар - 100 машын, то неабавязкова, каб ён працаваў на 100 машынах. Досыць вылучыць некалькі машынак, дзе можна запусціць ZooKeeper. І вызнае прынцып high availability. На кожным запушчаным інстансе ZooKeeper захоўвае ўсю копію дадзеных. Пазней раскажу, як ён гэта робіць. Ён не шардзіць дадзеныя, не партыцыянуе іх. З аднаго боку - гэта мінус, што мы не можам захоўваць шмат, з другога боку - гэта рабіць і не трэба. Ён не для гэтага прызначаны, гэта не база даных.
Дадзеныя можна кэшаваць на баку кліента. Гэта стандартны прынцып, каб нам не тузаць сервіс, не нагружаць яго аднолькавымі запытамі. Разумны кліент звычайна ведае пра гэта і кэшуе ў сябе.
Напрыклад, нешта ў нас змянілася. Ёсць нейкае дадатак. Выбралі новага лідэра, які адказвае, напрыклад, за апрацоўку аперацый запісу. І мы хочам рэпліцыраваць дадзеныя. Адно з рашэнняў - паставіць цыклік. І ўвесь час апытваем наш сэрвіс – ці не змянілася нешта? Другі варыянт больш аптымальны. Гэта watch mechanism, які дазваляе апавяшчаць кліентаў аб тым, што нешта змянілася. Гэта менш затратны спосаб па рэсурсах і больш зручны для кліентаў.
Client - гэта карыстач, які карыстаецца ZooKeeper.
Server - гэта сам працэс ZooKeeper.
Znode - гэта ключавая штука ў ZooKeeper. Усе znode захоўваюцца ў памяці ў ZooKeeper і арганізоўваюцца ў выглядзе іерархічнай схемы, у выглядзе дрэва.
Ёсць два тыпу аперацый. Першы - гэта update/write, калі нейкая аперацыя змяняе стан нашага дрэва. Дрэва агульнае.
І магчыма, што кліент не выконвае адзін запыт і адсякаецца, а можа ўсталяваць сесію, з дапамогай якой узаемадзейнічае з ZooKeeper.
Мадэль дадзеных ZooKeeper нагадвае файлавую сістэму. Ёсць стандартны корань і далей мы пайшлі нібыта па каталогах, якія ідуць ад кораня. І далей каталог першага ўзроўня, другога ўзроўня. Гэта ўсё зяўляецца znodes.
Кожная znode можа захоўваць у сабе нейкія дадзеныя, звычайна не вельмі вялікага аб'ёму, напрыклад, 10 кілабайт. І ў кожнай znode можа быць нейкая колькасць дзяцей.
Znode бываюць некалькіх тыпаў. Іх можна ствараць. І пры стварэньні znode мы паказваем тып, да якога яна павінна ставіцца.
Ёсць два тыпы. Першы гэта ephemeral flag. Znode жыве ў межах нейкай сесіі. Напрыклад, кліент устанавіў сесію. І пакуль гэтая сэсія жывая, яна будзе існаваць. Гэта трэба для таго, каб не пладзіць нечага лішняга. Гэта таксама падыходзіць для такіх момантаў, калі нам важна ў рамках сесіі захоўваць прымітывы дадзеных.
Другі тып - гэта sequential flag. Ён павялічвае лічыльнік на шляху да znode. Напрыклад, у нас быў каталог з дадаткам 1_5. І калі мы стварылі першую ноду, яна атрымала p_1, другая - p_2. І калі мы кожны раз выклікаем гэты метад, то мы перадаем поўны шлях, паказваючы толькі частку пусці, а гэты нумар аўтаматычна інкрыментуецца, таму што мы паказваем тып ноды - sequential.
Рэгулярная znode. Яна будзе жыць заўсёды і мець тое імя, якое мы ёй скажам.
Яшчэ адна карысная рэч - гэта watch flag. Калі мы яго ўстанаўліваем, то кліент можа падпісвацца на нейкія падзеі для пэўнай ноды. Пакажу потым на прыкладзе, як гэта робіцца. Сам ZooKeeper паведамляе кліенту аб тым, што дадзеныя на нодзе змяніліся. Пры гэтым апавяшчэнні не гарантуюць, што гэта нейкія новыя дадзеныя прыехалі. Яны проста кажуць пра тое, што нешта змянілася, таму параўноўваць дадзеныя потым давядзецца ўсё роўна асобнымі выклікамі.
І як я ўжо казаў, парадак дадзеных вызначаецца кілабайтамі. Не трэба тамака захоўваць вялікія тэкставыя дадзеныя, таму што гэта не база дадзеных, гэта сервер каардынацыі дзеянняў.
Трохі раскажу пра сесіі. Калі ў нас некалькі сервераў, то мы можам празрыста пераходзіць ад сервера да сервера, выкарыстоўваючы ідэнтыфікатар сесіі. Гэта даволі зручна.
У кожнай сесіі ёсць нейкі таймаўт. Сесія вызначаецца тым, ці перадае нешта кліент падчас гэтай сесіі серверу. Калі ён за час таймаўту нічога не перадаў, сесія адвальваецца, альбо кліент сам яе можа закрыць.
У яго няма так шмат функцый, але пры дапамозе гэтага API можна рабіць розныя штукі. Той выклік, які мы бачылі, create стварае znode і прымае тры параметры. Гэта шлях да znode, прычым яго трэба ўказваць поўным ад кораня. А таксама гэта нейкія дадзеныя, якія мы жадаем туды перадаць. І тып сцяга. І пасьля стварэньня ён вяртае шлях да znode.
Другое - можна выдаліць. Тут фішка ў тым, што другім параметрам, акрамя шляхі да znode можна паказаць версію. Адпаведна, будзе выдаленая тая znode, калі яе версія, якую мы перадалі, будзе эквівалентная той, якая насамрэч.
Калі мы жадаем не правяраць гэтую версію, то мы проста перадаем аргумент "-1".
Трэцяе - ажыццяўляе праверку існавання znode. Вяртае true, калі нода існуе, інакш false.
І тут з'яўляецца flag watch, які дазваляе ўсталяваць назіранне за гэтай нодай.
Можна ўсталяваць гэты flag нават на неіснуючую ноду і атрымаць апавяшчэнне ў тым выпадку, калі яна з'явіцца. Гэта таксама бывае карысна.
Яшчэ парачка выклікаў - гэта getData. Зразумела, што мы па znode можам атрымаць дадзеныя. Таксама можна выкарыстоўваць flag watch. У дадзеным выпадку ён не ўсталюецца, калі ноды няма. Таму трэба зразумець, што яна існуе, а потым ужо атрымліваць дадзеныя.
А таксама ёсць SetData. Тут мы перадаем version. І калі мы гэта перададзім, то будуць абноўлены дадзеныя на znode вызначанай версіі.
Таксама можна пазначыць "-1", каб гэтую праверку выключыць.
Яшчэ адзін карысны метад - гэта getChildren. Таксама мы можам атрымаць спіс усіх znode, якія належаць ёй. Можам за гэтым паназіраць, усталяваўшы flag watch.
І метад сінхранізаваць дазваляе ўсе змены адправіць адразу, тым самым гарантуючы тое, што яны захаваліся і ўсе дадзеныя поўнасцю змяніліся.
Калі праводзіць аналогіі са звычайным праграмаваннем, то, калі вы выкарыстоўваеце метады такія, як write, якія пішуць нешта на дыск, і пасля таго як ён вярнуў вам адказ, няма гарантыі, што ў вас дадзеныя запісаліся на дыск. І нават калі аперацыйная сістэма ўпэўнена, што ўсё запісалася, у самой кружэлцы ёсць механізмы, дзе працэс праходзіць праз узроўні буфераў, і толькі пасля гэтага дадзеныя змяшчаюцца на кружэлку.
У асноўным выкарыстоўваюцца асінхронныя выклікі. Гэта дазваляе кліенту працаваць паралельна з рознымі запытамі. Можна выкарыстоўваць сінхронны падыход, але ён менш прадукцыйны.
Дзве аперацыі, пра якія мы казалі, гэта update/write, якія змяняюць дадзеныя. Гэта create, setData, sync, delete. І read - гэта exists, getData, getChildren.
Цяпер некалькі прыкладаў, як можна зрабіць прымітывы працы ў размеркаванай сістэме. Напрыклад, звязаны са канфігурацыяй чагосьці. З'явіўся новы воркер. Мы дадалі машыну, запусцілі працэс. І ёсць наступныя тры пытанні. Як ён запытвае канфігурацыю ў ZooKeeper? І калі мы жадаем змяніць канфігурацыю, то як мы яе змяняем? І пасля таго, як мы яе змянілі, як тыя воркеры, якія ў нас былі, атрымліваюць яе?
У ZooKeeper гэта можна зрабіць адносна проста. Напрыклад, ёсць наша дрэва znode. Тут ёсць нода для нашага прыкладання, мы ствараем у ёй дадатковую ноду, дзе змяшчаюцца дадзеныя з канфігурацыі. Гэта могуць быць як асобныя параметры, так і не. Бо памер невялікі, то звычайна памер канфігурацыі таксама невялікі, таму тут суцэль можна яе захоўваць.
Вы карыстаецеся метад getData для атрымання канфігурацыі для воркера з ноды. Усталёўваны true. Калі гэтай ноды з нейкай прычыны няма, нас пра гэта паінфармуюць, калі яна з'явіцца, альбо, калі яна зменіцца. Калі мы жадаем ведаць, што нешта змянілася, то ставім true. І ў выпадку змены дадзеных у гэтай нодзе, мы пра гэта даведаемся.
SetData. Задаем дадзеныя, які ўсталёўваецца «-1», т. е. не правяраем версію, лічым, што канфігурацыя ў нас заўсёды адна, нам не трэба захоўваць шмат канфігурацый. Калі трэба шмат захоўваць, тое трэба будзе дадаць яшчэ адзін узровень. Тут лічым, што яна адна, таму абнаўляем толькі апошнюю, таму версію не правяраем. У гэты момант усе кліенты, якія да гэтага падпісаліся, яны атрымліваюць апавяшчэнне аб тым, што нешта змянілася ў гэтай нодзе. І пасля таго, як яны яго атрымалі, яны таксама павінны запытаць дадзеныя яшчэ раз. Апавяшчэнне складаецца ў тым, што яны атрымліваюць не самі дадзеныя, а толькі апавяшчэнне аб зменах. Пасля гэтага яны павінны папрасіць новыя дадзеныя.
Другі варыянт ужывання прымітыва - гэта group membership. У нас размеркаванае дадатак, ёсць куча воркераў і мы хочам разумець, што ўсе яны на месцы. Таму яны павінны сябе зарэгістраваць, што яны працуюць у нашым дадатку. І таксама мы хочам альбо з Майстар-працэсу, альбо яшчэ аднекуль даведацца пра ўсіх актыўных воркераў, якія ў нас зараз ёсць.
Як мы гэта робім? Для прыкладання ствараем ноду workers і дадаем туды падузровень з дапамогай метаду create. У мяне памылка на слайдзе. Тут трэба паслядоўны паказваць, тады ўсе воркеры будуць стварацца па адным. І дадатак запытваючы ўсе дадзеныя аб children гэтай ноды, атрымлівае ўсе актыўныя воркеры, якія ёсць.
Вось такая страшная імплементацыя таго, як гэта можа быць зроблена ў Java-кодзе. Пачнём з канца, з метаду main. Вось гэта наш клас, ствараем ягоны метад. У якасці першага аргументу выкарыстоўваем host, куды падлучаемся, т. е. задаём яго аргументам. А ў якасці другога аргумента - імя групы.
Як адбываецца злучэнне? Гэта просты прыклад API, які выкарыстоўваецца. Тут усё адносна проста. Ёсць стандартны клас ZooKeeper. Мы перадаем яму hosts. І задаем таймаўт, напрыклад, у 5 секунд. І ў нас есць такі член, як connectedSignal. Па сутнасці, мы ствараем групу па шляху, які перадаецца. Дадзеныя туды не пішам, хаця што-небудзь можна было напісаць. І нода тут мае тып persistent. Па сутнасці, гэта звычайная рэгулярная нода, якая будзе існаваць увесь час. Тут ствараецца сэсія. Гэта імплементацыя самога кліента. Наш кліент будзе ажыццяўляць перыядычна паведамленні аб тым, што сесія жывая. А калі мы сесію завяршаем, то мы выклікаем close і ўсё, сесія адвальваецца. Гэта на той выпадак, калі ў нас нешта адваліцца, каб ZooKeeper пра гэта даведаўся і сесію адсек.
Як залачыць нейкі рэсурс? Тут усё крыху больш складана. У нас ёсць набор воркераў, ёсць нейкі рэсурс, які мы жадаем залачыць. Для гэтага мы ствараем асобную ноду, напрыклад, пад назовам lock1. Калі мы змаглі яе стварыць, значыць, мы атрымалі lock сюды. А калі мы не змаглі яе стварыць, то воркер спрабуе атрымаць getData адгэтуль, а т. да. нода ўжо створаная, то мы ставім сюды watcher і ў той момант, калі стан гэтай ноды зменіцца, мы пра гэта даведаемся. І мы можам паспрабаваць паспець яе перастварыць. Калі мы забралі гэтую наду, забралі гэты lock, то пасля таго, як lock нам больш не патрэбен, мы ад яго адмовімся, бо нода існуе толькі ў рамках сесіі. Адпаведна, яна знікне. І іншы кліент у рамках іншай сесіі зможа забраць lock на гэтую ноду, дакладней ён атрымае апавяшчэнне аб тым, што нешта змянілася і ён можа паспрабаваць паспець гэта паспець гэта зрабіць.
Іншы прыклад, як можна выбіраць асноўнага лідэра. Тут крыху больш складана, але таксама адносна проста. Што тут у нас адбываецца? Ёсць асноўная нода, якая агрэгуе ў сабе ўсіх воркераў. Мы спрабуем атрымаць дадзеныя пра лідэра. Калі гэта паспяхова адбылося, т. е. мы атрымалі нейкія дадзеныя, то наш воркер пачынае ісці за гэтым лідэрам. Ён лічыць, што лідар ужо ёсць.
Калі лідэр з нейкай прычыны памёр, напрыклад, адваліўся, то мы спрабуем стварыць новага лідэра. І калі ў нас гэта атрымалася, то наш воркер становіцца лідарам. А калі нехта ў гэты момант паспеў стварыць новага лідэра, то мы спрабуем зразумець, хто гэта і потым за ім рушыць услед.
Тут узнікае, так званы, herd effect, т. е. эфект статка, таму што, калі лідэр памірае, то той, хто першы паспее, той і стане лідарам.
Пры захопе рэсурсу можна паспрабаваць выкарыстоўваць некалькі іншы падыход, які заключаецца ў наступным. Напрыклад, мы жадаем атрымаць lock, але без hert effect. Складацца ён будзе ў тым, што наша дадатак запытвае спісы ўсіх id нод для ўжо існуючай ноды з lock. І калі перад гэтым тую ноду, lock для якой мы стварылі, яна будзе мінімальнай з таго набору, які мы атрымалі, тое гэта азначае, што мы захапілі lock. Мы правяраем, што мы атрымалі lock. У якасці праверкі будзе ўмова, што той id, які мы атрымалі пры стварэньні новага lock, ён зьяўляецца мінімальным. І калі мы атрымалі, то мы працуем далей.
Калі існуе нейкі id, які меншы за наш lock, то мы ставім на гэтую падзею watcher і чакаем натыфікацыі, пакуль нешта не зменіцца. Т. е. мы атрымалі гэты lock. І пакуль той не адваліцца, мы не станем мінімальным id і не атрымаем мінімальны lock, і тым самым зможам залачыцца. А калі гэтая ўмова не выконваецца, тады мы адразу ідзем сюды і спрабуем яшчэ раз атрымаць гэты lock, таму што за гэты час магло нешта змяніцца.
З чаго складаецца ZooKeeper? Ёсць 4 асноўныя рэчы. Гэта апрацоўка працэсаў - Request. А таксама ZooKeeper Atomic Broadcast. Ёсць Commit Log, куды заносяцца ўсе аперацыі. І сама In-memory Replicated DB, т. е. сама база дадзеных, дзе захоўваецца ўсё гэтае дрэва.
Варта адзначыць, што ўсе аперацыі на запіс праходзяць праз Request Processor. А аперацыі на чытанне ідуць адразу ў In-memory базу.
Сама база поўнасцю рэплікаваная. На ўсіх ZooKeeper instances захоўваецца поўная копія дадзеных.
Для таго каб аднавіць бд пасля падзення, існуе Commit log. Стандартная практыка, калі дадзеныя перш чым пападаюць у памяць, яны пішуцца туды, каб у выпадку падзення гэты log можна было прайграць і аднавіць стан сістэмы. І таксама прымяняюцца перыядычныя снапшоты базы.
ZooKeeper Atomic Broadcast - гэта такая штука, якая выкарыстоўваецца для падтрымання рэплікаваных дадзеных.
ZAB усярэдзіне сябе выбірае лідэра з пункта гледжання ноды ZooKeeper. Іншыя ноды становяцца яе фолаверамі, чакаюць ад яе нейкіх дзеянняў. Калі на іх прыходзяць запісы, то яны ўсе іх перанакіроўваюць лідэру. Той папярэдне выконвае аперацыю запісу і затым рассылае паведамленне аб тым, што змянілася сваім фолаверам. Гэта, у сутнасці, павінна выконвацца атамарна, т. е. аперацыя запісу і broadcasting усёй гэтай справы павінны выконвацца атамарна, тым самым гарантуецца кансістэнтнасць дадзеных.
Ён апрацоўвае толькі write request. Асноўная яго задача ў тым, што ён трансфармуе аперацыю ў transactional update. Гэта спецыяльна сфарміраваны запыт.
І тут варта адзначыць, што гарантуецца ідэмпатэнтнасць апдэйтаў для адной і той жа аперацыі. Што гэта такое? Гэтая рэч, калі якую выканаць два разы, яна будзе мець адзін і той жа стан, т. е. сам запыт ад гэтага не зменіцца. І зрабіць гэта трэба для таго, каб у выпадку падзення можна было зноўку запусціць аперацыю, тым самым накаціць змены, якія адваліліся на дадзены момант. Пры гэтым стан сістэмы стане такім жа, т. е. не павінна быць такога, што чарада адных і тых жа, напрыклад, працэсаў абнаўленняў, прыводзіла да розных выніковых станаў сістэмы.
Крыніца: habr.com