Мен сизге "Hadoop. ZooKeeper" лекциясынын стенограммасын "Hadoopто чоң көлөмдөгү маалыматтарды бөлүштүрүлгөн иштетүүнүн ыкмалары" сериясынан окууну сунуштайм.
ZooKeeper деген эмне, анын Hadoop экосистемасындагы орду. Бөлүштүрүлгөн эсептөөлөр жөнүндө жалган маалыматтар. Стандарттык бөлүштүрүлгөн системанын диаграммасы. Бөлүштүрүлгөн системаларды координациялоодо кыйынчылыктар. Типтүү координация көйгөйлөрү. ZooKeeper дизайнынын принциптери. ZooKeeper маалымат модели. znode желектери. Сеанстар. Client 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. Жумушчуларды жана кул процесстерин башкарган Master процесси бар. Ал тапшырмаларды координациялоо жана бөлүштүрүү, жумушчуларды кайра ишке киргизүү, жаңыларын ишке киргизүү жана жүктү бөлүштүрүү үчүн жооптуу.
Бир кыйла өркүндөтүлгөн нерсе - Координациялык кызмат, башкача айтканда, координациялоо тапшырмасын өзүнчө процесске жылдыруу, ошондой эле кандайдыр бир резервдик көчүрмөнү же стабилдик мастерди параллелдүү иштетүү, анткени Мастер иштебей калышы мүмкүн. Анан агай кулап калса, биздин система иштебейт. Биз камдык көчүрмөнү иштеп жатабыз. Кээ бирлери Мастер камдык көчүрмөнү көчүрүү керек деп айтышат. Муну координациялык кызматка да тапшырса болот. Бирок бул диаграммада, Мастер өзү жумушчуларды координациялоо үчүн жооптуу болуп саналат, бул жерде кызмат маалыматтарды репликациялоо ишин координациялайт.
Көбүрөөк өнүккөн вариант - бул, адаттагыдай, бардык координациялоо биздин кызмат тарабынан чечилет. Ал бардыгынын иштеши үчүн жоопкерчиликти алат. Ал эми бир нерсе иштебей калса, биз бул тууралуу билип, бул кырдаалдан чыгууга аракет кылабыз. Кандай болгон күндө да, биз кулдар менен кандайдыр бир жол менен өз ара аракеттенген жана кандайдыр бир кызмат аркылуу маалыматтарды, маалыматты, билдирүүлөрдү ж.б. жөнөтө алган Кожоюн менен калдык.
Андан да өнүккөн схема бар, бизде Кожоюн жок болгондо, бардык түйүндөр кожоюн кулдар, жүрүм-туруму менен айырмаланат. Бирок алар дагы эле бири-бири менен өз ара аракеттениши керек, ошондуктан бул иш-аракеттерди координациялоо үчүн дагы эле бир аз кызмат калды. Балким, ушул принцип боюнча иштеген Кассандра бул схемага туура келет.
Бул схемалардын кайсынысы жакшыраак иштейт деп айтуу кыйын. Ар биринин өзүнүн жакшы жана жаман жактары бар.
Ал эми Устат менен кээ бир нерселерден коркуунун кереги жок, анткени, практика көрсөткөндөй, ал дайыма кызмат кылууга анчалык жакын эмес. Бул жерде негизги нерсе - бул кызматты өзүнчө күчтүү түйүндө жайгаштыруу үчүн туура чечимди тандоо, анын ресурстары жетиштүү болушу үчүн, мүмкүн болсо, колдонуучулар бул процессти кокусунан өлтүрүп албашы үчүн. Бирок, ошол эле учурда, мындай схемада мастер процессинен жумушчуларды башкаруу алда канча жеңил, башкача айтканда, бул схема ишке ашыруу көз карашынан караганда жөнөкөй.
Жана бул схема (жогоруда) балким татаалыраак, бирок ишенимдүү.
Негизги көйгөй - жарым-жартылай иштебей калуу. Мисалы, биз Тармак аркылуу билдирүү жөнөткөндө кандайдыр бир кырсык болуп, кабарды жөнөткөн адам өзүнүн билдирүүсү кабыл алынганын жана алуучу тарапта эмне болгонун билбей калат, билдирүү туура иштетилгенби же жокпу билбей калат. , башкача айтканда, ал эч кандай ырастоо кабыл албайт.
Ошого жараша биз бул кырдаалды иштеп чыгышыбыз керек. Эң жөнөкөй нерсе - бул билдирүүнү кайра жөнөтүү жана жооп алганга чейин күтүү. Мында кабылдагычтын абалынын өзгөргөндүгү эске алынбайт. Балким, биз билдирүү жөнөтүп, бир эле маалыматты эки жолу кошобуз.
ZooKeeper мындай баш тартуу менен күрөшүүнүн жолдорун сунуштайт, бул да биздин жашообузду жеңилдетет.
Бир аз мурда айтылгандай, бул көп агымдуу программаларды жазууга окшош, бирок негизги айырмасы, биз ар кандай машиналарда курган бөлүштүрүлгөн тиркемелерде, байланыштын жалгыз жолу - Тармак. Негизинен, бул жалпы эч нерсе болбогон архитектура. Бир машинада иштеген ар бир процесстин же кызматтын өзүнүн эс тутуму, өзүнүн диски, өзүнүн процессору бар, ал эч ким менен бөлүшпөйт.
Эгерде биз бир компьютерде көп жиптүү программа жазсак, анда маалымат алмашуу үчүн жалпы эстутумду колдоно алабыз. Бизде контексттик которгуч бар, процесстер которулушу мүмкүн. Бул аткарууга таасир этет. Бир жагынан, кластердеги программада мындай нерсе жок, бирок Тармакта көйгөйлөр бар.
Демек, бөлүштүрүлгөн системаларды жазууда пайда болгон негизги көйгөйлөр конфигурация болуп саналат. Биз кандайдыр бир арыз жазып жатабыз. Эгерде бул жөнөкөй болсо, анда биз коддогу бардык сандарды катуу коддойбуз, бирок бул ыңгайсыз, анткени биз жарым секунданын тайм-ауттун ордуна бир секунддун тайм-аутун каалайбыз деп чечсек, анда биз тиркемени кайра компиляциялашыбыз керек жана баарын кайра жайып. Бул бир машинада болгондо, аны жөн эле өчүрүп күйгүзсөңүз болот, бирок бизде көп машиналар болгондо, биз бардыгын дайыма көчүрүп турушубуз керек. Биз колдонмону конфигурациялоого аракет кылышыбыз керек.
Бул жерде система процесстери үчүн статикалык конфигурация жөнүндө сөз болуп жатат. Бул толугу менен эмес, балким, операциялык тутумдун көз карашынан алганда, бул биздин процесстерибиз үчүн статикалык конфигурация болушу мүмкүн, б.а. бул жөн гана кабыл алынбай турган жана жаңыртылган конфигурация.
Ошондой эле динамикалык конфигурация бар. Булар ошол жерден алынышы үчүн, биз учуп өзгөргүбүз келген параметрлер.
Бул жерде эмне көйгөй бар? Конфигурацияны жаңырттык, аны чыгардык, анан эмне болот? Көйгөй бир жагынан конфигурацияны чыгардык, бирок жаңы нерсени унутуп койдук, конфигурация ошол жерде калды. Экинчиден, биз чыгарып жатканда, конфигурация кээ бир жерлерде жаңыртылган, бирок башкаларында эмес. Жана биздин тиркеменин бир машинада иштеген кээ бир процесстери жаңы конфигурация менен, ал эми бир жерде эскиси менен кайра иштетилген. Бул биздин бөлүштүрүлгөн колдонмо конфигурациянын көз карашынан карама-каршы болушуна алып келиши мүмкүн. Бул көйгөй жалпы болуп саналат. Динамикалык конфигурация үчүн ал актуалдуураак, анткени аны тез эле өзгөртүүгө болот.
Дагы бир көйгөй - топко мүчөлүк. Бизде ар дайым жумушчулардын кээ бир топтому бар, биз алардын кайсынысы тирүү, кайсынысы өлгөнүн билгибиз келет. Эгерде Мастер бар болсо, анда ал кайсы жумушчуларды кардарларга кайра багыттаса болорун түшүнүшү керек, алар эсептөөлөрдү жүргүзүшү же маалыматтар менен иштешет, ал эми кайсынысы мүмкүн эмес. Дайыма пайда болгон көйгөй - бул биздин кластерде ким иштеп жатканын билишибиз керек.
Дагы бир типтүү көйгөй - бул лидерди шайлоо, биз ким башкаарын билгибиз келет. Бир мисал, бизде жазуу операцияларын кабыл алган, анан аларды башка процесстердин арасында репликациялаган процесс болгондо, репликация. Ал жетекчи болот, калгандары ага баш ийишет, аны ээрчишет. Процессти тандоо керек, ал бардыгы үчүн ачык-айкын болсун, эки лидер тандалды деп чыкпасын.
Ошондой эле бири-бирин эксклюзивдүү мүмкүнчүлүктөр бар. Бул жерде маселе татаалыраак. Мутекс деген нерсе бар, сиз көп агымдуу программаларды жазганыңызда жана кандайдыр бир ресурска, мисалы, эс тутум клеткасына кирүү мүмкүнчүлүгү чектелген жана бир гана жип менен аткарылышын кааласаңыз. Бул жерде ресурс дагы абстракттуу нерсе болушу мүмкүн. Биздин Тармактын ар кандай түйүндөрүнүн ар кандай тиркемелери берилген ресурска эксклюзивдүү кирүү мүмкүнчүлүгүн гана алышы керек, бирок ар бир адам аны өзгөртүп же ал жерге бир нерсе жаза албайт. Бул кулпулар деп аталат.
ZooKeeper бул көйгөйлөрдүн баарын тигил же бул даражада чечүүгө мүмкүндүк берет. Мен муну кантип жасоого мүмкүндүк берет мисалдар менен көрсөтөм.
Бөгөттөөчү примитивдер жок. Биз бир нерсени колдоно баштаганда, бул примитив кандайдыр бир окуянын болушун күтпөйт. Кыязы, бул нерсе асинхрондуу иштейт, ошону менен процесстер бир нерсени күтүп жатканда илинип калбоого мүмкүндүк берет. Бул абдан пайдалуу нерсе.
Кардардын бардык суроо-талаптары жалпы кезек тартибинде каралат.
Ал эми кардарлар кандайдыр бир абалдагы өзгөрүүлөр жөнүндө, маалыматтардагы өзгөрүүлөр жөнүндө, кардар өзгөртүлгөн маалыматтарды өзү көрө электе билдирүү алуу мүмкүнчүлүгүнө ээ.
ZooKeeper эки режимде иштей алат. Биринчиси өзүнчө, бир түйүндө. Бул сыноо үчүн ыңгайлуу. Ошондой эле, ал кластердик режимде, каалаган сандагы түйүндөрдө иштей алат. серверлерЭгерде бизде 100 машиналык кластер болсо, анда ал сөзсүз түрдө 100 машинада иштеши керек эмес. ZooKeeper иштей турган бир нече машинаны бөлүп коюу жетиштүү. Жана ал жогорку жеткиликтүүлүк принцибине карманат. ZooKeeper ар бир иштеп жаткан инстанциядагы маалыматтардын толук көчүрмөсүн сактайт. Мен муну кантип жасай турганын кийинчерээк түшүндүрүп берем. Ал маалыматтарды бөлбөйт же бөлбөйт. Бир жагынан, бул кемчилик, анткени биз көп нерсени сактай албайбыз, бирок экинчи жагынан, бул керексиз. Ал ал үчүн иштелип чыккан эмес; бул маалымат базасы эмес.
Маалыматтар кардар тарабынан кэштелет. Бул кызматты үзгүлтүккө учуратпоо жана аны бир эле суроо-талаптар менен жүктөбөш үчүн стандарттуу принцип. Акылдуу кардар, адатта, бул жөнүндө билет жана аны кэштейт.
Мисалы, бул жерде бир нерсе өзгөрдү. Кандайдыр бир колдонмо бар. Жаңы жетекчи шайланды, ал, мисалы, жазуу операцияларын иштетүү үчүн жооптуу. Жана биз маалыматтарды кайталагыбыз келет. Чечимдердин бири - аны циклге салуу. Жана биз дайыма биздин кызматыбыздан шек санайбыз - бир нерсе өзгөрдүбү? Экинчи вариант оптималдуураак. Бул кардарларга бир нерсе өзгөргөнүн билдирүүгө мүмкүндүк берген саат механизми. Бул ресурстар жагынан арзаныраак ыкма жана кардарлар үчүн ыңгайлуу.
Кардар - ZooKeeperди колдонгон колдонуучу.
Сервер бул ZooKeeper процессинин өзү.
Znode - ZooKeeperдеги негизги нерсе. Бардык зоналар ZooKeeper тарабынан эс тутумда сакталат жана иерархиялык диаграмма түрүндө, дарак түрүндө уюштурулат.
Операциялардын эки түрү бар. Биринчиси - жаңыртуу/жазуу, кандайдыр бир операция биздин дарактын абалын өзгөрткөндө. Дарак жалпы болуп саналат.
Ал эми кардар бир суроо-талапты аткарбай, ажырап калышы мүмкүн, бирок ал ZooKeeper менен өз ара аракеттене турган сеанс түзө алат.
ZooKeeperдин маалымат модели файлдык системага окшош. Стандарттык тамыр бар, анан биз тамырдан чыккан каталогдордон өткөндөй болдук. Анан биринчи деңгээлдеги каталог, экинчи деңгээлдеги. Мунун баары znodes.
Ар бир znode кээ бир маалыматтарды сактай алат, адатта өтө чоң эмес, мисалы, 10 килобайт. Ал эми ар бир znode балдардын белгилүү бир саны болушу мүмкүн.
Znodes бир нече түрлөрү болот. Алар түзүлүшү мүмкүн. Жана znode түзүүдө биз анын кайсы түргө таандык болушу керек экенин белгилейбиз.
эки түрү бар. Биринчиси - эфемердик желек. Znode сессиянын ичинде жашайт. Мисалы, кардар сессияны түздү. Жана бул сессия тирүү турганда, ал бар. Бул керексиз нерсени чыгарбоо үчүн зарыл. Бул маалымат примитивдерин сессиянын ичинде сактоо биз үчүн маанилүү болгон учурларга да ылайыктуу.
Экинчи түрү ырааттуу желек болуп саналат. Бул znode жолунда эсептегичти көбөйтөт. Мисалы, бизде 1_5 тиркемеси бар каталог бар болчу. Ал эми биз биринчи түйүн жаратканда, ал p_1 алды, экинчиси - p_2. Жана биз бул ыкманы ар бир жолу чакырганда, биз жолдун бир бөлүгүн гана көрсөтүү менен толук жолду өтөбүз жана бул сан автоматтык түрдө көбөйөт, анткени биз түйүн түрүн - ырааттуу көрсөтөбүз.
Кадимки znode. Ал ар дайым жашайт жана биз ага айткан ысымга ээ болот.
Дагы бир пайдалуу нерсе - бул сааттын желеги. Эгер биз аны орнотуп алсак, анда кардар белгилүү бир түйүн үчүн кээ бир окуяларга жазыла алат. Мен муну кантип жасоону мисал менен кийинчерээк көрсөтөм. ZooKeeper өзү кардарга түйүндөгү маалыматтар өзгөргөнүн кабарлайт. Бирок, эскертмелер кээ бир жаңы маалыматтар келди деп кепилдик бере албайт. Алар жөн гана бир нерсе өзгөрдү деп айтышат, андыктан сиз дагы эле кийинчерээк өзүнчө чалуулар менен маалыматтарды салыштырышыңыз керек.
Мен буга чейин айткандай, маалыматтардын тартиби килобайттар менен аныкталат. Ал жерде чоң тексттик маалыматтарды сактоонун кереги жок, анткени ал маалымат базасы эмес, ал аракеттерди координациялоо сервери.
Сеанстар жөнүндө бир аз айтып берейин. Эгерде бизде бир нече сервер болсо, биз бир серверден экинчисине ачык-айкын которула алабыз. сервер, сессиянын ID'син колдонуу. Бул абдан ыңгайлуу.
Ар бир сессиянын кандайдыр бир тайм-ауту бар. Сеанс ошол сеанс учурунда кардар серверге кандайдыр бир нерсени жөнөтүп же жөнөтпөгөнү менен аныкталат. Эгерде ал тайм-ауттун ичинде эч нерсе өткөрбөсө, сеанс токтоп калат же кардар аны өзү жаба алат.
Анын мынчалык көп функциялары жок, бирок сиз бул API менен ар кандай нерселерди кыла аласыз. Биз жараткан чакырык znode жаратат жана үч параметрди алат. Бул znode жолу болуп саналат, ал түп тамырынан толугу менен көрсөтүлүшү керек. Жана ошондой эле бул биз ал жакка өткөргүбүз келген кээ бир маалыматтар. Жана желектин түрү. Ал эми түзүлгөндөн кийин ал znode жолун кайтарат.
Экинчиден, сиз аны жок кыла аласыз. Бул жерде куулук экинчи параметр, znode жолуна тышкары, нускасын көрсөтүүгө болот. Демек, биз өткөрүп берген версия чындыгында бар версияга барабар болсо, ал znode жок кылынат.
Эгерде биз бул версияны текшергибиз келбесе, анда биз жөн гана "-1" аргументин өткөрөбүз.
Үчүнчүдөн, znode бар экендигин текшерет. Түйүн бар болсо чындыкты кайтарат, антпесе жалган.
Ошондо желек сааты пайда болот, бул түйүндү көзөмөлдөөгө мүмкүндүк берет.
Сиз бул желекти жок түйүнгө орнотуп, ал пайда болгондо эскертмени ала аласыз. Бул да пайдалуу болушу мүмкүн.
Дагы бир нече кыйынчылыктар бар getData. Биз znode аркылуу маалыматтарды ала аларыбыз түшүнүктүү. Сиз ошондой эле желек саатын колдоно аласыз. Бул учурда, түйүн жок болсо орнотулбайт. Ошондуктан, анын бар экенин түшүнүп, андан кийин маалыматтарды алуу керек.
Ошондой эле бар SetData. Бул жерде биз версиясын өткөрүп жатабыз. Эгер биз муну өткөрүп берсек, белгилүү бир версиянын znode маалыматтары жаңыланат.
Ошондой эле бул текшерүүнү алып салуу үчүн "-1" белгилесеңиз болот.
Дагы бир пайдалуу ыкмасы болуп саналат GetChildren. Биз ошондой эле ага таандык бардык znodes тизмесин ала аласыз. Биз муну желек саатын коюу менен көзөмөлдөй алабыз.
Жана метод синхрондоштуруу бардык өзгөртүүлөрдү бир эле учурда жөнөтүүгө мүмкүндүк берет, ошону менен алардын сакталышын жана бардык маалыматтар толугу менен өзгөртүлгөнүн камсыздайт.
Эгерде биз кадимки программалоо менен окшоштуктарды түзсөк, анда дискке бир нерсе жаза турган жазуу сыяктуу ыкмаларды колдонгондо жана ал сизге жооп кайтаргандан кийин, дискке маалыматтарды жазганыңызга кепилдик жок. Жана операциялык система баары жазылганына ишенсе дагы, дисктин өзүндө процесс буферлердин катмарлары аркылуу өтүүчү механизмдер бар жана андан кийин гана маалыматтар дискке жайгаштырылат.
Көбүнчө асинхрондук чалуулар колдонулат. Бул кардар ар кандай суроо-талаптар менен параллелдүү иштөөгө мүмкүндүк берет. Сиз синхрондук ыкманы колдоно аласыз, бирок ал азыраак жемиштүү.
Биз сөз кылган эки операция - бул маалыматтарды өзгөрткөн жаңыртуу/жазуу. Бул түзүү, setData, синхрондоштуруу, жок кылуу. Жана окуу бар, getData, getChildren.
Эми бөлүштүрүлгөн системада иштөө үчүн примитивдерди кантип жасоого болорун бир нече мисалдар. Мисалы, бир нерсенин конфигурациясына байланыштуу. Жаны жумушчу пайда болду. Биз машинаны кошуп, процессти баштадык. Ал эми төмөнкү үч суроо бар. Конфигурация үчүн ZooKeeperди кантип сурайт? Ал эми конфигурацияны өзгөрткүбүз келсе, аны кантип өзгөртөбүз? Ал эми биз аны өзгөрткөндөн кийин, бизде болгон жумушчулар аны кантип алышты?
ZooKeeper муну салыштырмалуу жеңил кылат. Мисалы, биздин znode дарагы бар. Бул жерде биздин тиркеме үчүн түйүн бар, биз анда конфигурациядан алынган маалыматтарды камтыган кошумча түйүн түзөбүз. Булар өзүнчө параметрлер болушу мүмкүн же болбошу мүмкүн. Өлчөмү кичинекей болгондуктан, конфигурациянын өлчөмү, адатта, кичинекей, андыктан аны бул жерде сактоо толук мүмкүн.
Сиз ыкманы колдонуп жатасыз getData түйүндөн жумушчу үчүн конфигурацияны алуу үчүн. Чындыкка коюу. Эгер кандайдыр бир себептерден улам бул түйүн жок болсо, ал пайда болгондо же өзгөргөндө бизге кабар берилет. Эгерде биз бир нерсе өзгөргөнүн билгибиз келсе, анда аны чындыкка коебуз. Ал эми бул түйүндөгү маалыматтар өзгөрсө, биз бул тууралуу билебиз.
SetData. Биз берилиштерди коюп, “-1” койдук, б.а. биз версияны текшербейбиз, бизде ар дайым бир конфигурация бар деп ойлойбуз, көп конфигурацияларды сактоонун кереги жок. Эгер көп сактоо керек болсо, дагы бир деңгээлди кошуу керек болот. Бул жерде биз бир гана бар экенине ишенебиз, андыктан акыркысын гана жаңыртабыз, андыктан версиясын текшербейбиз. Ушул тапта, буга чейин жазылган бардык кардарлар бул түйүндө бир нерсе өзгөргөндүгү жөнүндө билдирүү алышат. Жана алар аны алгандан кийин, алар дагы маалыматтарды талап кылышы керек. Кабарлоо, алар маалыматтын өзүн эмес, өзгөртүүлөр жөнүндө гана билдирүүнү алышат. Андан кийин алар жаңы маалыматтарды сурашы керек.
Примитивди колдонуунун экинчи варианты топтун мүчөлүгү. Бизде таратылган арыз бар, бир топ жумушчулар бар жана биз алардын баары ордунда экенин түшүнгүбүз келет. Ошондуктан, алар биздин тиркемеде иштешет деп өздөрүн катташы керек. Ошондой эле биз Мастер процессинен же башка жерден, азыркы учурда бизде болгон бардык активдүү жумушчулар жөнүндө билгибиз келет.
Муну кантип кылабыз? Колдонмо үчүн биз жумушчулар түйүнүн түзүп, түзүү ыкмасын колдонуп, ал жерге субдеңгээлди кошобуз. Менде слайдда ката бар. Мына сага керек ырааттуу тактаса, анда бардык жумушчулар бирден түзүлөт. Ал эми тиркеме, бул түйүндүн балдары жөнүндө бардык маалыматтарды сурап, бардык активдүү жумушчуларды кабыл алат.
Бул Java кодунда муну кантип жасоого болорун ушунчалык коркунучтуу ишке ашыруу. Негизги ыкма менен аягынан баштайлы. Бул биздин класс, анын методун түзөлү. Биринчи аргумент катары биз туташып жаткан хостту колдонобуз, б.а. биз аны аргумент катары койдук. Ал эми экинчи аргумент топтун аты.
Байланыш кантип ишке ашат? Бул колдонулган API жөнөкөй мисалы. Бул жерде баары салыштырмалуу жөнөкөй. Стандарттык класс ZooKeeper бар. Биз ага хостторду өткөрүп беребиз. Ал эми күтүү убактысын, мисалы, 5 секундга орнотуңуз. Ал эми бизде connectSignal деген мүчө бар. Негизи, биз берилген жол боюнча топ түзөбүз. Биз ал жерге маалыматтарды жазбайбыз, бирок бир нерсе жазылган болушу мүмкүн. Ал эми бул жердеги түйүн туруктуу түргө кирет. Негизи, бул ар дайым боло турган кадимки үзгүлтүксүз түйүн. Бул жерде сессия түзүлөт. Бул кардар өзү ишке ашыруу болуп саналат. Биздин кардар мезгил-мезгили менен билдирүүлөрдү жөнөтүп турат, бул сессиянын жандуу экенин көрсөтүп турат. Ал эми сессияны аяктагандан кийин, биз жакын деп атабыз жана ушуну менен сессия токтойт. Бул ZooKeeper бул жөнүндө билип, сессияны токтотушу үчүн, биз үчүн бир нерсе түшүп калса.
Ресурсту кантип кулпулоо керек? Бул жерде баары бир аз татаалыраак. Бизде жумушчулардын топтому бар, биз бекиткиси келген ресурс бар. Бул үчүн биз өзүнчө түйүн түзөбүз, мисалы, lock1 деп аталат. Эгер биз аны түзө алсак, анда биз бул жерде кулпу алдык. Эгерде биз аны түзө албасак, анда жумушчу бул жерден getData алууга аракет кылат жана түйүн мурунтан эле түзүлгөндүктөн, биз бул жерге байкоочуну коёбуз жана бул түйүндүн абалы өзгөргөндө, биз бул жөнүндө билебиз. Жана биз аны кайра жаратуу үчүн убакыт табууга аракет кылсак болот. Эгерде биз бул түйүндү алсак, бул кулпуну алсак, анда кулпуга муктаж болбой калгандан кийин, биз андан баш тартабыз, анткени түйүн сессиянын ичинде гана бар. Ошого жараша ал жок болот. Ал эми дагы бир кардар, дагы бир сессиянын алкагында, бул түйүндөн кулпусун ала алат, тагыраагы, ал бир нерсе өзгөргөндүгү жөнүндө билдирүү алат жана аны өз убагында жасоого аракет кыла алат.
Негизги лидерди кантип тандай ала турганыңыздын дагы бир мисалы. Бул бир аз татаал, бирок ошол эле учурда салыштырмалуу жөнөкөй. Бул жерде эмне болуп жатат? Бардык жумушчуларды бириктирген негизги түйүн бар. Биз лидер тууралуу маалымат алууга аракет кылып жатабыз. Бул ийгиликтүү ишке ашса, башкача айтканда, биз кандайдыр бир маалыматтарды алдык, анда биздин жумушчу бул лидерди ээрчий баштайт. Ал буга чейин эле лидер бар деп эсептейт.
Эгерде лидер кандайдыр бир себептерден улам каза болуп калса, мисалы, жыгылып калса, анда биз жаңы лидер түзгөнгө аракет кылабыз. Ал эми ийгиликке жетсек, анда жумушчубуз жетекчи болуп калат. Эгерде кимдир бирөө ушул тапта жаңы лидер түзө алган болсо, анда биз анын ким экенин түшүнүүгө аракет кылып, анан анын артынан ээрчип жатабыз.
Бул жерде үйүр эффектиси деп аталган нерсе пайда болот, б.а. үйүр эффектиси, анткени лидер өлгөндө, убагында ким биринчи болсо, ошол лидер болот.
Ресурсту басып алууда сиз бир аз башкача ыкманы колдонууга аракет кылсаңыз болот, ал төмөнкүдөй. Мисалы, биз кулпу алгыбыз келет, бирок герт эффекти жок. Бул биздин колдонмо кулпусу бар түйүн үчүн бардык түйүн идентификаторлорунун тизмелерин сурайт. Эгерде буга чейин биз кулпу жараткан түйүн биз алган топтомдун эң кичинеси болсо, анда бул кулпуну басып алганыбызды билдирет. Кулпуну алганыбызды текшеребиз. Чек катары, жаңы кулпу түзүүдө биз алган id минималдуу деген шарт болот. А эгер алган болсок, андан ары иштейбиз.
Эгерде биздин кулпубуздан кичине id бар болсо, анда биз бул окуяга байкоочу коюп, бир нерсе өзгөрмөйүнчө кабарлоону күтөбүз. Башкача айтканда, биз бул кулпуну алдык. Жана ал кулаганга чейин, биз минималдуу id болуп калбайбыз жана минималдуу кулпуну албайбыз, ошентип биз кире алабыз. Ал эми бул шарт аткарылбаса, анда биз дароо бул жакка барып, бул кулпуну кайра алууга аракет кылабыз, анткени бул убакыттын ичинде бир нерсе өзгөргөн болушу мүмкүн.
ZooKeeper эмнеден турат? 4 негизги нерсе бар. Бул процесс процесстери - Сурам. Жана ошондой эле ZooKeeper Atomic Broadcast. Бардык операциялар жазылган Commit Log бар. Жана эс тутумдагы репликацияланган МБнын өзү, б.а., бул бүт дарак сакталган маалымат базасы.
Белгилей кетчү нерсе, бардык жазуу операциялары Request Processor аркылуу өтөт. Жана окуу операциялары түздөн-түз эс тутумдагы маалымат базасына өтөт.
Маалымат базасы толугу менен кайталанат. ZooKeeperдин бардык инстанциялары маалыматтардын толук көчүрмөсүн сактайт.
Кыйроодон кийин маалымат базасын калыбына келтирүү үчүн, Commit журналы бар. Стандарттык практика - маалыматтар эстутумга түшкөнгө чейин, эгер ал бузулуп калса, бул журналды кайра ойнотуу жана системанын абалын калыбына келтирүү үчүн ошол жерге жазылат. Ошондой эле маалымат базасынын мезгил-мезгили менен тартылган сүрөттөрү да колдонулат.
ZooKeeper Atomic Broadcast - бул репликацияланган маалыматтарды сактоо үчүн колдонулган нерсе.
ZAB лидерди ZooKeeper түйүнүнүн көз карашынан тандайт. Башка түйүндөр анын жолдоочулары болуп, андан кандайдыр бир аракеттерди күтүшөт. Эгер алар жазууларды алса, алардын баарын лидерге жөнөтүшөт. Ал алгач жазуу операциясын аткарып, андан кийин анын жолдоочуларына эмне өзгөргөнүн билдирүү жөнөтөт. Бул, чындыгында, атомдук түрдө аткарылышы керек, б.а., бүт нерсенин жаздыруу жана берүү операциясы атомдук түрдө аткарылышы керек, ошону менен маалыматтардын ырааттуулугуна кепилдик берилет.
Ал жазуу өтүнүчтөрүн гана иштетет. Анын негизги милдети - операцияны транзакциялык жаңыртууга айландыруу. Бул атайын түзүлгөн өтүнүч.
Жана бул жерде бир эле операция үчүн жаңыртуулардын потенциалсыздыгы кепилденгендигин белгилей кетүү керек. Бул эмне? Бул нерсе, эки жолу аткарылса, ошол эле абалга ээ болот, б.а. сурамдын өзү өзгөрбөйт. Жана бул кыйроого учураган учурда, сиз операцияны кайра башташыңыз үчүн, ошону менен учурда өчүрүлгөн өзгөртүүлөрдү артка кайтаруу үчүн жасалышы керек. Бул учурда, системанын абалы бирдей болуп калат, башкача айтканда, бир эле катар, мисалы, жаңыртуу процесстери системанын ар кандай акыркы абалына алып келген жагдай болбошу керек.
Source: www.habr.com
