"Hadoop-д их хэмжээний өгөгдлийг тархсан боловсруулах аргууд" цувралаас "Hadoop. ZooKeeper" лекцийн хуулбарыг уншихыг санал болгож байна.
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. Ажилчид болон боолын үйл явцыг удирддаг Мастер процесс байдаг. Тэрээр үүрэг даалгаврыг зохицуулах, хуваарилах, ажилчдыг дахин эхлүүлэх, шинээр ажиллуулах, ачааллыг хуваарилах үүрэгтэй.
Илүү дэвшилтэт зүйл бол Зохицуулах үйлчилгээ юм, өөрөөр хэлбэл зохицуулалтын ажлыг тусдаа процесс болгон шилжүүлж, ямар нэгэн нөөцлөлт эсвэл зогсолтын мастерыг зэрэгцүүлэн ажиллуул, учир нь Мастер бүтэлгүйтэж магадгүй юм. Хэрэв Багш унавал манай систем ажиллахгүй болно. Бид нөөцлөлт хийж байна. Зарим нь Мастерыг нөөцлөхийн тулд хуулбарлах шаардлагатай гэж заасан байдаг. Үүнийг зохицуулах албанд ч даатгаж болно. Гэхдээ энэ диаграммд мастер өөрөө ажилчдыг зохицуулах үүрэгтэй; энд үйлчилгээ нь өгөгдлийг хуулбарлах үйл ажиллагааг зохицуулдаг.
Илүү дэвшилтэт сонголт бол бүх зохицуулалтыг ихэвчлэн хийдэг шиг манай үйлчилгээ хийх явдал юм. Тэр бүх зүйл хэвийн байгаа эсэхийг шалгах үүрэгтэй. Хэрэв ямар нэг зүйл ажиллахгүй бол бид энэ талаар олж мэдээд энэ нөхцөл байдлаас гарахыг хичээдэг. Ямар ч байсан бид боолуудтай ямар нэгэн байдлаар харилцаж, ямар нэгэн үйлчилгээгээр дамжуулан өгөгдөл, мэдээлэл, мессеж гэх мэтийг илгээж чаддаг Мастертай үлддэг.
Бүр илүү дэвшилтэт схем байдаг, бидэнд Мастер байхгүй үед бүх зангилаа нь зан авираараа ялгаатай мастер боолууд байдаг. Гэхдээ тэд бие биетэйгээ харилцах шаардлагатай хэвээр байгаа тул эдгээр үйлдлийг зохицуулах үйлчилгээ хэвээр байна. Магадгүй энэ зарчмаар ажилладаг Кассандра энэ схемд тохирсон байх.
Эдгээр схемүүдийн аль нь илүү сайн ажилладагийг хэлэхэд хэцүү байдаг. Тус бүр өөрийн гэсэн давуу болон сул талуудтай.
Багштай зарим зүйлээс айх шаардлагагүй, учир нь практикээс харахад тэрээр байнга үйлчлэхэд тийм ч өртөмтгий биш юм. Энд гол зүйл бол энэ үйлчилгээг тусдаа хүчирхэг зангилаа дээр байршуулах зөв шийдлийг сонгох, ингэснээр хангалттай нөөцтэй байх, хэрэв боломжтой бол хэрэглэгчид тэнд нэвтрэх эрхгүй байх, ингэснээр тэд энэ үйл явцыг санамсаргүйгээр устгахгүй байх явдал юм. Гэхдээ үүнтэй зэрэгцэн ийм схемд ажилчдыг Мастер процессоос удирдах нь илүү хялбар байдаг, өөрөөр хэлбэл энэ схем нь хэрэгжилтийн үүднээс илүү хялбар байдаг.
Мөн энэ схем (дээрх) нь магадгүй илүү төвөгтэй, гэхдээ илүү найдвартай байдаг.
Гол асуудал бол хэсэгчилсэн бүтэлгүйтэл юм. Жишээлбэл, бид сүлжээгээр мессеж илгээх үед ямар нэгэн осол гарч, мессеж илгээсэн хүн өөрийн мессежийг хүлээн авсан эсэх, хүлээн авагчийн талд юу болсныг мэдэхгүй, мессеж зөв боловсруулсан эсэхийг мэдэхгүй байх болно. , өөрөөр хэлбэл тэр ямар ч баталгаа хүлээн авахгүй.
Үүний дагуу бид энэ байдлыг боловсруулах ёстой. Хамгийн энгийн зүйл бол энэ мессежийг дахин илгээж, хариу ирэх хүртэл хүлээх явдал юм. Энэ тохиолдолд хүлээн авагчийн төлөв өөрчлөгдсөн эсэхийг тооцохгүй. Бид мессеж илгээж, ижил өгөгдлийг хоёр удаа нэмж болно.
ZooKeeper ийм татгалзалтай тэмцэх арга замыг санал болгодог бөгөөд энэ нь бидний амьдралыг хөнгөвчилдөг.
Өмнө дурьдсанчлан, энэ нь олон урсгалтай программ бичихтэй төстэй боловч гол ялгаа нь бидний өөр өөр машин дээр бүтээдэг тархсан програмуудад харилцах цорын ганц арга бол Сүлжээ юм. Үндсэндээ энэ бол юу ч биш, хуваалцсан архитектур юм. Нэг машин дээр ажилладаг процесс, үйлчилгээ бүр өөрийн санах ой, өөрийн диск, өөрийн процессортой байдаг бөгөөд үүнийг хэнтэй ч хуваалцдаггүй.
Хэрэв бид нэг компьютер дээр олон урсгалтай програм бичвэл хуваалцсан санах ойг ашиглан өгөгдөл солилцох боломжтой. Бидэнд контекст шилжүүлэгч байдаг, процессууд сольж болно. Энэ нь гүйцэтгэлд нөлөөлдөг. Нэг талаас, кластер дээрх хөтөлбөрт ийм зүйл байхгүй, гэхдээ Сүлжээнд асуудал гардаг.
Үүний дагуу тархсан системийг бичихэд гарч ирдэг гол асуудал бол тохиргоо юм. Бид ямар нэгэн төрлийн өргөдөл бичиж байна. Хэрэв энэ нь энгийн бол бид кодонд бүх төрлийн тоог хатуу кодлодог боловч энэ нь тохиромжгүй, учир нь бид хагас секундын завсарлага авахын оронд нэг секундын завсарлага авахыг хүсч байвал бид програмыг дахин эмхэтгэх хэрэгтэй. бүгдийг дахин өнхрүүл. Энэ нь нэг машин дээр байгаа бол зүгээр л дахин асаах боломжтой, гэхдээ олон машинтай бол бид бүгдийг байнга хуулах хэрэгтэй болдог. Бид програмыг тохируулах боломжтой болгохыг хичээх ёстой.
Энд бид системийн процессуудын статик тохиргооны тухай ярьж байна. Энэ нь бүхэлдээ биш, магадгүй үйлдлийн системийн үүднээс авч үзвэл энэ нь бидний процессуудын статик тохиргоо байж болох юм, өөрөөр хэлбэл энэ нь зүгээр л авч, шинэчлэх боломжгүй тохиргоо юм.
Мөн динамик тохиргоо байдаг. Эдгээр нь бидний нэн даруй өөрчлөхийг хүсч буй параметрүүд бөгөөд тэдгээрийг тэндээс авах болно.
Энд ямар асуудал байна вэ? Бид тохиргоог шинэчилж, гаргалаа, тэгээд яах вэ? Асуудал нь нэг талаас бид тохиргоогоо гаргасан, гэхдээ шинэ зүйлээ мартсан, тохиргоо тэнд үлдсэн байж магадгүй юм. Хоёрдугаарт, биднийг танилцуулж байх үед тохиргоо зарим газарт шинэчлэгдсэн боловч зарим газарт шинэчлэгдсэнгүй. Нэг машин дээр ажилладаг манай програмын зарим процессууд шинэ тохиргоогоор, хаа нэгтээ хуучин тохиргоогоор дахин ачаалагдсан. Энэ нь бидний тархсан програм тохиргооны үүднээс нийцэхгүй байхад хүргэж болзошгүй. Энэ асуудал нийтлэг байдаг. Динамик тохиргооны хувьд энэ нь шууд өөрчлөх боломжтой гэсэн үг учраас илүү хамааралтай юм.
Өөр нэг асуудал бол бүлгийн гишүүнчлэл юм. Бидэнд үргэлж хэдэн ажилчид байдаг, тэдний хэн нь амьд, аль нь үхсэн болохыг мэдэхийг үргэлж хүсдэг. Хэрэв Мастер байгаа бол тэр ямар ажилчдыг үйлчлүүлэгчид рүү шилжүүлж, тооцоо хийх эсвэл өгөгдөлтэй ажиллах боломжтойг ойлгох ёстой. Байнга үүсдэг асуудал бол манай кластерт хэн ажиллаж байгааг мэдэх хэрэгтэй.
Өөр нэг нийтлэг асуудал бол хэн удирдаж байгааг мэдэхийг хүссэн удирдагчийн сонгууль юм. Үүний нэг жишээ бол бичих үйлдлүүдийг хүлээн авч, дараа нь бусад процессуудын дунд хуулбарлах процесстой бол хуулбарлах явдал юм. Тэр удирдагч байх болно, бусад нь түүнд дуулгавартай байх болно, түүнийг дагах болно. Хүн бүрт хоёрдмол утгагүй байхын тулд хоёр удирдагч сонгогддоггүйн тулд үйл явцыг сонгох хэрэгтэй.
Мөн харилцан онцгой хандалт байдаг. Энд байгаа асуудал илүү төвөгтэй юм. Олон урсгалтай программ бичиж, зарим эх сурвалж, жишээлбэл санах ойн нүд рүү нэвтрэх эрхийг зөвхөн нэг урсгалаар хязгаарлахыг хүсэх үед мутекс гэж байдаг. Энд нөөц нь илүү хийсвэр зүйл байж болно. Манай Сүлжээний өөр өөр зангилааны өөр өөр програмууд нь зөвхөн өгөгдсөн эх сурвалжид онцгой хандалт авах ёстой бөгөөд хүн бүр үүнийг өөрчлөх эсвэл тэнд ямар нэгэн зүйл бичих боломжгүй юм. Эдгээр нь цоож гэж нэрлэгддэг цоожнууд юм.
ZooKeeper нь эдгээр бүх асуудлыг аль нэг хэмжээгээр шийдвэрлэх боломжийг танд олгоно. Энэ нь танд үүнийг хэрхэн хийхийг зөвшөөрч байгааг би жишээгээр харуулах болно.
Блоклох командууд байхгүй. Бид ямар нэг зүйлийг ашиглаж эхлэхэд энэ команд нь ямар ч үйл явдал гарахыг хүлээхгүй. Хамгийн магадлалтай нь энэ зүйл асинхроноор ажиллах бөгөөд ингэснээр процессууд ямар нэг зүйлийг хүлээж байх үед зогсохгүй байх боломжийг олгоно. Энэ бол маш хэрэгтэй зүйл юм.
Үйлчлүүлэгчийн бүх хүсэлтийг ерөнхий дарааллын дарааллаар боловсруулдаг.
Үйлчлүүлэгчид өөрчлөгдсөн өгөгдлийг өөрсдөө харахаас өмнө зарим төлөвийн өөрчлөлт, өгөгдлийн өөрчлөлтийн талаар мэдэгдэл хүлээн авах боломжтой.
ZooKeeper нь хоёр горимд ажиллах боломжтой. Эхнийх нь бие даасан, нэг зангилаа дээр байна. Энэ нь туршилт хийхэд тохиромжтой. Мөн кластер горимд хэдэн ч сервер дээр ажиллах боломжтой. Хэрэв бид 100 машинтай кластертай бол 100 машин дээр ажиллах шаардлагагүй. ZooKeeper ажиллуулж болох хэд хэдэн машин сонгоход хангалттай. Мөн энэ нь өндөр хүртээмжтэй байх зарчмыг баримталдаг. Ажиллаж байгаа тохиолдол бүрт ZooKeeper мэдээллийн бүх хувийг хадгалдаг. Дараа нь би түүнийг яаж хийхийг танд хэлэх болно. Энэ нь өгөгдлийг хуваахгүй эсвэл хуваахгүй. Нэг талаас, энэ нь бид маш их зүйлийг хадгалах боломжгүй, нөгөө талаас үүнийг хийх шаардлагагүй юм. Үүнд зориулагдаагүй, мэдээллийн сан ч биш.
Үйлчлүүлэгч тал дээр өгөгдлийг кэшлэх боломжтой. Энэ нь бид үйлчилгээг тасалдуулж, ижил хүсэлтээр ачаалахгүй байх стандарт зарчим юм. Ухаалаг үйлчлүүлэгч ихэвчлэн энэ талаар мэддэг бөгөөд кэш хийдэг.
Жишээлбэл, энд ямар нэг зүйл өөрчлөгдсөн. Ямар нэг төрлийн хэрэглээ бий. Жишээлбэл, бичих үйлдлийг боловсруулах үүрэгтэй шинэ удирдагч сонгогдов. Мөн бид өгөгдлийг хуулбарлахыг хүсч байна. Нэг шийдэл нь үүнийг гогцоонд оруулах явдал юм. Мөн бид үйлчилгээндээ байнга эргэлздэг - ямар нэг зүйл өөрчлөгдсөн үү? Хоёр дахь сонголт нь илүү оновчтой юм. Энэ бол ямар нэг зүйл өөрчлөгдсөнийг үйлчлүүлэгчдэд мэдэгдэх боломжийг олгодог цагны механизм юм. Энэ нь нөөцийн хувьд хямд, үйлчлүүлэгчдэд илүү тохиромжтой арга юм.
Үйлчлүүлэгч нь ZooKeeper ашигладаг хэрэглэгч юм.
Сервер нь өөрөө ZooKeeper процесс юм.
Znode бол ZooKeeper-ийн гол зүйл юм. Бүх znodes нь ZooKeeper-ийн санах ойд хадгалагдаж, шаталсан диаграмм хэлбэрээр, мод хэлбэрээр зохион байгуулагдсан.
Хоёр төрлийн үйл ажиллагаа байдаг. Эхнийх нь шинэчлэлт/бичих бөгөөд зарим үйлдэл нь бидний модны төлөвийг өөрчилдөг. Мод нь нийтлэг байдаг.
Үйлчлүүлэгч нэг хүсэлтийг гүйцэтгээгүй бөгөөд салсан ч ZooKeeper-тэй харилцах сесс үүсгэж болно.
ZooKeeper-ийн өгөгдлийн загвар нь файлын системтэй төстэй. Стандарт язгуур байдаг бөгөөд дараа нь бид үндэснээс гардаг сангуудаар дамждаг юм шиг л явсан. Тэгээд дараа нь нэгдүгээр түвшний каталог, хоёрдугаар түвшний. Энэ бол бүгд znodes.
Znode бүр зарим өгөгдлийг хадгалах боломжтой, ихэвчлэн тийм ч том биш, жишээлбэл, 10 килобайт. Мөн znode бүр тодорхой тооны хүүхэдтэй байж болно.
Znodes нь хэд хэдэн төрлөөр ирдэг. Тэдгээрийг үүсгэж болно. Мөн znode үүсгэхдээ бид түүнд хамаарах төрлийг зааж өгдөг.
Хоёр төрөл байдаг. Эхнийх нь түр зуурын туг юм. Znode нь сесс дотор амьдардаг. Жишээлбэл, үйлчлүүлэгч сесс байгуулсан. Мөн энэ хуралдаан амьд байгаа цагт энэ нь оршин тогтнох болно. Энэ нь шаардлагагүй зүйл гаргахгүйн тулд зайлшгүй шаардлагатай. Энэ нь бидний хувьд өгөгдлийн командыг сесс дотор хадгалах нь чухал үед тохиромжтой.
Хоёр дахь төрөл нь дараалсан туг юм. Энэ нь znode хүрэх замд тоолуурыг нэмэгдүүлдэг. Жишээлбэл, бид 1_5 програмтай лавлахтай байсан. Бид эхний зангилааг үүсгэх үед p_1, хоёр дахь нь p_2 хүлээн авсан. Мөн бид энэ аргыг дуудах болгондоо бүрэн замыг дамжуулж, замын зөвхөн хэсгийг зааж өгдөг бөгөөд зангилааны төрлийг зааж өгдөг тул энэ тоо автоматаар нэмэгддэг - дараалсан.
Ердийн зангилаа. Тэр үргэлж амьдарч, бидний түүнд хэлдэг нэртэй байх болно.
Өөр нэг хэрэгтэй зүйл бол цагны туг юм. Хэрэв бид үүнийг суулгавал үйлчлүүлэгч тодорхой зангилааны зарим үйл явдлыг захиалж болно. Үүнийг хэрхэн хийдгийг жишээгээр би дараа нь харуулах болно. ZooKeeper өөрөө зангилааны өгөгдөл өөрчлөгдсөнийг үйлчлүүлэгчид мэдэгддэг. Гэсэн хэдий ч мэдэгдэл нь зарим шинэ өгөгдөл ирсэн гэсэн баталгаа болохгүй. Тэд зүгээр л ямар нэг зүйл өөрчлөгдсөн гэж хэлдэг тул та дараа нь тусдаа дуудлагатай өгөгдлийг харьцуулах хэрэгтэй.
Би аль хэдийн хэлсэнчлэн өгөгдлийн дарааллыг килобайтаар тодорхойлдог. Тэнд том хэмжээний текст мэдээлэл хадгалах шаардлагагүй, учир нь энэ нь мэдээллийн сан биш, үйл ажиллагааны зохицуулалтын сервер юм.
Би хуралдааны талаар бага зэрэг хэлье. Хэрэв бид олон сервертэй бол сесс танигчийг ашиглан серверээс сервер рүү ил тод шилжих боломжтой. Энэ нь нэлээд тохиромжтой.
Сеанс бүр тодорхой хугацааны завсарлагатай байдаг. Сесс нь тухайн сессийн үеэр үйлчлүүлэгч сервер рүү ямар нэгэн зүйл илгээсэн эсэхээр тодорхойлогддог. Хэрэв тэр завсарлагааны хугацаанд юу ч дамжуулаагүй бол сесс унана эсвэл үйлчлүүлэгч өөрөө үүнийг хааж болно.
Энэ нь тийм ч олон функцгүй, гэхдээ та энэ API-ээр өөр зүйл хийх боломжтой. Бидний харсан дуудлага нь znode үүсгэж, гурван параметрийг авдаг. Энэ бол znode руу хүрэх зам бөгөөд үүнийг үндэснээс нь бүрэн зааж өгөх ёстой. Мөн энэ нь бидний тэнд шилжүүлэхийг хүсч буй зарим өгөгдөл юм. Мөн тугны төрөл. Мөн бүтээсний дараа энэ нь znode хүртэлх замыг буцаана.
Хоёрдугаарт, та үүнийг устгаж болно. Энд байгаа заль мэх нь хоёр дахь параметр нь znode руу хүрэх замаас гадна хувилбарыг зааж өгч болно. Үүний дагуу, хэрэв бидний шилжүүлсэн хувилбар нь одоо байгаа хувилбартай дүйцэх юм бол тухайн znode устгагдах болно.
Хэрэв бид энэ хувилбарыг шалгахыг хүсэхгүй байгаа бол "-1" аргументыг зүгээр л дамжуулна.
Гуравдугаарт, znode байгаа эсэхийг шалгадаг. Хэрэв зангилаа байгаа бол үнэн, үгүй бол худал буцаана.
Дараа нь тугны цаг гарч ирэх бөгөөд энэ нь танд энэ зангилааг хянах боломжийг олгоно.
Та энэ тугийг байхгүй зангилаа дээр ч тавьж, гарч ирэх үед мэдэгдэл хүлээн авах боломжтой. Энэ нь бас ашигтай байж болно.
Өөр хэд хэдэн сорилт байна өгөгдөл авах. Бид znode-ээр дамжуулан өгөгдөл хүлээн авах боломжтой нь тодорхой байна. Та мөн тугны цагийг ашиглаж болно. Энэ тохиолдолд зангилаа байхгүй бол суулгахгүй. Тиймээс та энэ нь байгаа гэдгийг ойлгож, дараа нь өгөгдлийг хүлээн авах хэрэгтэй.
Бас байдаг SetData. Энд бид хувилбарыг дамжуулж байна. Хэрэв бид үүнийг дамжуулбал тодорхой хувилбарын znode дээрх өгөгдөл шинэчлэгдэх болно.
Та мөн энэ шалгалтыг хасахын тулд "-1" гэж зааж өгч болно.
Өөр нэг ашигтай арга Хүүхэд авах. Мөн бид түүнд хамаарах бүх znodes жагсаалтыг авах боломжтой. Бид тугны цагийг тохируулснаар үүнийг хянах боломжтой.
Мөн арга синк хийх бүх өөрчлөлтийг нэг дор илгээх боломжийг олгодог бөгөөд ингэснээр тэдгээр нь хадгалагдаж, бүх өгөгдөл бүрэн өөрчлөгдсөн байх болно.
Хэрэв бид ердийн програмчлалын аналогийг хийвэл диск рүү ямар нэгэн зүйл бичих бичих гэх мэт аргуудыг ашиглах ба энэ нь танд хариу ирсний дараа диск рүү өгөгдлийг бичсэн гэсэн баталгаа байхгүй болно. Үйлдлийн систем бүх зүйл бичигдсэн гэдэгт итгэлтэй байсан ч процесс нь буферийн давхаргуудаар дамждаг механизмууд дискэнд байдаг бөгөөд үүний дараа л өгөгдлийг дискэн дээр байрлуулдаг.
Ихэвчлэн асинхрон дуудлагыг ашигладаг. Энэ нь үйлчлүүлэгч өөр өөр хүсэлттэй зэрэгцэн ажиллах боломжийг олгодог. Та синхрон аргыг ашиглаж болно, гэхдээ энэ нь бүтээмж багатай.
Бидний ярьсан хоёр үйлдэл бол өгөгдлийг өөрчилдөг update/write юм. Эдгээр нь үүсгэх, тохируулах, синк хийх, устгах. Унших нь байдаг, getData, getChildren.
Одоо тархсан системд ажиллахын тулд командуудыг хэрхэн хийж болох талаар цөөн хэдэн жишээ. Жишээлбэл, ямар нэг зүйлийн тохиргоотой холбоотой. Шинэ ажилтан гарч ирэв. Бид машиныг нэмж, процессыг эхлүүлсэн. Мөн дараах гурван асуулт байна. Энэ нь ZooKeeper-ээс тохиргоог хэрхэн хайдаг вэ? Хэрэв бид тохиргоог өөрчлөхийг хүсвэл яаж өөрчлөх вэ? Тэгээд бид үүнийг өөрчилсний дараа бидэнд байсан тэдгээр ажилчид яаж үүнийг олж авах вэ?
ZooKeeper үүнийг харьцангуй хялбар болгодог. Жишээлбэл, манай znode мод байдаг. Энд манай програмын зангилаа байгаа бөгөөд бид түүнд тохиргооны өгөгдлийг агуулсан нэмэлт зангилаа үүсгэдэг. Эдгээр нь тусдаа параметрүүд байж болно, үгүй ч байж болно. Хэмжээ нь жижиг тул тохиргооны хэмжээ нь ихэвчлэн бага байдаг тул энд хадгалах бүрэн боломжтой.
Та энэ аргыг хэрэглэж байна өгөгдөл авах зангилаанаас ажилчинд зориулсан тохиргоог авах. Үнэн гэж тохируулсан. Хэрэв ямар нэг шалтгаанаар энэ зангилаа байхгүй бол энэ нь гарч ирэх эсвэл өөрчлөгдөх үед бидэнд мэдэгдэх болно. Хэрэв бид ямар нэг зүйл өөрчлөгдсөнийг мэдэхийг хүсвэл үүнийг үнэн гэж тохируулна. Хэрэв энэ зангилааны өгөгдөл өөрчлөгдвөл бид энэ талаар мэдэх болно.
SetData. Бид өгөгдлийг тохируулж, "-1" гэж тохируулсан, өөрөөр хэлбэл бид хувилбарыг шалгадаггүй, бид үргэлж нэг тохиргоотой гэж үздэг, олон тохиргоог хадгалах шаардлагагүй. Хэрэв та маш их хадгалах шаардлагатай бол өөр түвшинг нэмэх шаардлагатай болно. Энд бид зөвхөн нэг байгаа гэдэгт итгэж байгаа тул бид зөвхөн хамгийн сүүлийн хувилбарыг шинэчилдэг тул хувилбарыг нь шалгадаггүй. Энэ мөчид өмнө нь бүртгүүлсэн бүх үйлчлүүлэгчид энэ зангилаанд ямар нэг зүйл өөрчлөгдсөн тухай мэдэгдлийг хүлээн авдаг. Мөн тэд үүнийг хүлээн авсны дараа өгөгдлийг дахин хүсэх ёстой. Мэдэгдэл нь тэд өгөгдлийг өөрөө хүлээн авдаггүй, зөвхөн өөрчлөлтийн тухай мэдэгддэг. Үүний дараа тэд шинэ өгөгдөл хүсэх ёстой.
Командыг ашиглах хоёр дахь сонголт бол бүлгийн гишүүнчлэл. Бидэнд тараагдсан програм байгаа, олон тооны ажилчид байгаа бөгөөд тэд бүгд байрандаа байгаа гэдгийг ойлгохыг хүсч байна. Тиймээс тэд манай өргөдөлд ажиллаж байгаагаа бүртгүүлэх ёстой. Мөн бид одоо байгаа бүх идэвхтэй ажилчдын талаар Мастер процессоос эсвэл өөр газар олж мэдэхийг хүсч байна.
Үүнийг бид яаж хийх вэ? Програмын хувьд бид ажилчны зангилаа үүсгэж, үүсгэх аргыг ашиглан тэнд дэд түвшинг нэмнэ. Надад слайд дээр алдаа байна. Энд танд хэрэгтэй байна дараалсан зааж өгвөл бүх ажилчдыг нэг нэгээр нь үүсгэнэ. Мөн энэ зангилааны хүүхдүүдийн талаархи бүх өгөгдлийг хүссэн програм нь одоо байгаа бүх идэвхтэй ажилчдыг хүлээн авдаг.
Энэ бол Java код дээр үүнийг хэрхэн хийж болохыг харуулсан аймшигтай хэрэглүүр юм. Үндсэн аргаас эхлээд төгсгөлөөс нь эхэлцгээе. Энэ бол манай анги, түүний аргыг бий болгоё. Эхний аргумент болгон бид холбосон хостыг ашигладаг, өөрөөр хэлбэл бид үүнийг аргумент болгон тохируулдаг. Мөн хоёр дахь маргаан нь бүлгийн нэр юм.
Холболт хэрхэн үүсдэг вэ? Энэ бол ашигладаг API-ийн энгийн жишээ юм. Энд бүх зүйл харьцангуй энгийн. ZooKeeper стандарт анги байдаг. Бид түүнд хостуудыг дамжуулдаг. Мөн завсарлагааны хугацааг жишээлбэл 5 секунд болгож тохируулна уу. Тэгээд манайд connectSignal гэдэг гишүүн бий. Үндсэндээ бид дамжуулсан замын дагуу бүлэг үүсгэдэг. Ямар нэг зүйл бичиж болох байсан ч бид тэнд мэдээлэл бичдэггүй. Энд байгаа зангилаа нь байнгын төрөл юм. Үндсэндээ энэ бол байнга оршин тогтнох ердийн ердийн зангилаа юм. Энэ нь сессийг үүсгэсэн газар юм. Энэ бол үйлчлүүлэгч өөрөө хэрэгжүүлэх явдал юм. Манай үйлчлүүлэгч сесс идэвхтэй байгааг илтгэх үе үе мессеж илгээх болно. Бид хуралдааныг дуусгах үед бид хаах гэж дууддаг, тэгээд л хуралдаан тасардаг. Энэ нь бидэнд ямар нэг зүйл унасан тохиолдолд ZooKeeper үүнийг олж мэдээд хуралдааныг тасална.
Нөөцийг хэрхэн түгжих вэ? Энд бүх зүйл арай илүү төвөгтэй байдаг. Бидэнд олон тооны ажилчид байгаа, бид түгжихийг хүсч буй зарим нөөц бий. Үүнийг хийхийн тулд бид тусдаа зангилаа үүсгэдэг, жишээлбэл, lock1 гэж нэрлэдэг. Хэрэв бид үүнийг бүтээж чадсан бол энд цоожтой болсон. Хэрэв бид үүнийг үүсгэж чадаагүй бол ажилтан эндээс getData-г авахыг оролдох бөгөөд зангилаа аль хэдийн үүсгэгдсэн тул бид энд ажиглагч байрлуулж, энэ зангилааны төлөв өөрчлөгдөх үед бид үүнийг мэдэх болно. Мөн бид үүнийг дахин бүтээх цаг гаргахыг оролдож болно. Хэрэв бид энэ зангилаа авч, энэ түгжээг авсан бол цоож хэрэггүй болсны дараа зангилаа нь зөвхөн сесс дотор байдаг тул бид үүнийг орхих болно. Үүний дагуу энэ нь алга болно. Өөр нэг үйлчлүүлэгч өөр сессийн хүрээнд энэ зангилааны түгжээг авах боломжтой болно, эс тэгвээс тэр ямар нэг зүйл өөрчлөгдсөн тухай мэдэгдэл хүлээн авах бөгөөд тэр үүнийг цаг тухайд нь хийхийг оролдож болно.
Гол удирдагчаа хэрхэн сонгох бас нэг жишээ. Энэ нь арай илүү төвөгтэй, гэхдээ бас харьцангуй энгийн. Энд юу болоод байна? Бүх ажилчдыг нэгтгэдэг гол зангилаа байдаг. Бид удирдагчийн талаар мэдээлэл авахыг оролдож байна. Хэрэв энэ нь амжилттай болсон бол, өөрөөр хэлбэл бид зарим мэдээлэл хүлээн авсан бол манай ажилтан энэ удирдагчийг дагаж эхэлнэ. Тэр аль хэдийн удирдагч байгаа гэдэгт итгэдэг.
Хэрэв удирдагч ямар нэг шалтгаанаар нас барсан бол жишээлбэл, унасан бол бид шинэ удирдагчийг бий болгохыг хичээдэг. Хэрэв бид амжилтанд хүрвэл манай ажилтан удирдагч болно. Хэрэв энэ мөчид хэн нэгэн шинэ удирдагчийг бий болгож чадсан бол бид хэн болохыг ойлгохыг хичээж, дараа нь түүнийг дагахыг хичээдэг.
Энд сүргийн эффект гэж нэрлэгддэг, өөрөөр хэлбэл сүргийн нөлөө үүсдэг, учир нь удирдагч нас барахад цаг хугацааны хувьд түрүүлж байсан нь удирдагч болно.
Нөөцийг олж авахдаа та арай өөр аргыг ашиглахыг оролдож болно, энэ нь дараах байдалтай байна. Жишээлбэл, бид цоож авахыг хүсч байгаа боловч герт эффектгүй. Энэ нь манай аппликешн нь цоожтой аль хэдийн байгаа зангилааны бүх зангилааны id-н жагсаалтыг хүсэхээс бүрдэх болно. Хэрэв үүнээс өмнө бидний түгжээ үүсгэсэн зангилаа нь бидний хүлээн авсан багцын хамгийн жижиг нь байсан бол энэ нь бид түгжээг барьж авсан гэсэн үг юм. Бид цоож авсан эсэхээ шалгана. Шалгалтын хувьд шинэ түгжээ үүсгэх үед бидний хүлээн авсан id хамгийн бага байх нөхцөл бий болно. Хэрэв бид үүнийг хүлээн авбал бид цаашаа ажиллана.
Хэрэв бидний түгжээнээс бага тодорхой ID байгаа бол бид энэ үйл явдалд ажиглагч байрлуулж, ямар нэг зүйл өөрчлөгдөх хүртэл мэдэгдэл хүлээнэ. Өөрөөр хэлбэл, бид энэ түгжээг хүлээн авсан. Энэ нь унах хүртэл бид хамгийн бага id болж чадахгүй бөгөөд хамгийн бага түгжээг хүлээн авахгүй бөгөөд ингэснээр бид нэвтрэх боломжтой болно. Хэрэв энэ нөхцөл хангагдаагүй бол бид нэн даруй энд очоод энэ түгжээг дахин авахыг оролдоорой, учир нь энэ хугацаанд ямар нэг зүйл өөрчлөгдсөн байж магадгүй юм.
ZooKeeper юунаас бүрддэг вэ? 4 үндсэн зүйл байдаг. Энэ бол боловсруулах процесс юм - Хүсэлт. Мөн ZooKeeper Atomic Broadcast. Бүх үйлдлийг бүртгэдэг Commit Log байдаг. Мөн In-Memory Replicated DB өөрөө, өөрөөр хэлбэл энэ модыг бүхэлд нь хадгалдаг мэдээллийн сан нь өөрөө юм.
Бүх бичих үйлдлүүд Хүсэлтийн процессороор дамждаг гэдгийг тэмдэглэх нь зүйтэй. Унших үйлдлүүд нь санах ойн мэдээллийн сан руу шууд ордог.
Мэдээллийн сан нь өөрөө бүрэн хуулбарлагдсан. ZooKeeper-ийн бүх тохиолдлууд мэдээллийн бүрэн хуулбарыг хадгалдаг.
Гэмтлийн дараа мэдээллийн санг сэргээхийн тулд Commit log байдаг. Стандарт практик нь өгөгдөл санах ойд орохоос өмнө үүнийг бичдэг бөгөөд хэрэв гацвал энэ бүртгэлийг тоглуулж, системийн төлөвийг сэргээж болно. Мөн мэдээллийн сангийн үе үе агшин зуурын зургийг бас ашигладаг.
ZooKeeper Atomic Broadcast нь хуулбарласан өгөгдлийг хадгалахад хэрэглэгддэг зүйл юм.
ZAB дотооддоо удирдагчийг ZooKeeper зангилааны үүднээс сонгодог. Бусад зангилаа нь түүний дагалдагчид болж, түүнээс зарим үйлдлийг хүлээж байдаг. Хэрэв тэд бүртгэл хүлээн авбал бүгдийг нь удирдагч руу дамжуулдаг. Тэрээр эхлээд бичих үйлдлийг хийж, дараа нь дагагчдаа юу өөрчлөгдсөн тухай мессеж илгээдэг. Энэ нь үнэн хэрэгтээ атомын аргаар хийгдэх ёстой, өөрөөр хэлбэл бүх зүйлийг бичих, дамжуулах ажиллагааг атомаар гүйцэтгэх ёстой бөгөөд ингэснээр өгөгдлийн тогтвортой байдлыг хангах болно.
Энэ нь зөвхөн бичих хүсэлтийг боловсруулдаг. Үүний гол үүрэг бол үйл ажиллагааг гүйлгээний шинэчлэл болгон хувиргах явдал юм. Энэ бол тусгайлан боловсруулсан хүсэлт юм.
Ижил үйл ажиллагаанд зориулсан шинэчлэлтийн чадваргүй байдал баталгаатай гэдгийг энд тэмдэглэх нь зүйтэй. Энэ юу вэ? Энэ зүйл, хэрэв хоёр удаа гүйцэтгэсэн бол ижил төлөвтэй байх болно, өөрөөр хэлбэл хүсэлт өөрөө өөрчлөгдөхгүй. Үүнийг хийх хэрэгтэй бөгөөд ингэснээр эвдэрсэн тохиолдолд та үйл ажиллагааг дахин эхлүүлэх боломжтой бөгөөд ингэснээр тухайн үед унасан өөрчлөлтүүдийг буцааж болно. Энэ тохиолдолд системийн төлөв байдал ижил байх болно, жишээлбэл, шинэчлэлтийн хэд хэдэн процесс нь системийн янз бүрийн эцсийн төлөв байдалд хүргэсэн байх ёсгүй.
Эх сурвалж: www.habr.com