Men sizga "Hadoop. ZooKeeper" ma'ruzasining "Hadoop'da katta hajmdagi ma'lumotlarni taqsimlangan qayta ishlash usullari" turkumidan o'qishni taklif qilaman.
ZooKeeper nima, uning Hadoop ekotizimidagi o'rni. Tarqalgan hisoblash haqida yolg'on. Standart taqsimlangan tizimning diagrammasi. Tarqalgan tizimlarni muvofiqlashtirishda qiyinchilik. Oddiy muvofiqlashtirish muammolari. ZooKeeper dizaynining tamoyillari. ZooKeeper ma'lumotlar modeli. znode bayroqlari. Seanslar. Client API. Primitivlar (konfiguratsiya, guruhga a'zolik, oddiy qulflar, etakchini tanlash, suruv effektisiz qulflash). ZooKeeper arxitekturasi. ZooKeeper DB. ZAB. So'rovni qayta ishlash.
Bugun biz ZooKeeper haqida gaplashamiz. Bu narsa juda foydali. U, har qanday Apache Hadoop mahsuloti singari, logotipga ega. Unda erkak tasvirlangan.
Bundan oldin, biz asosan u erda ma'lumotlarni qanday qayta ishlash mumkinligi, uni qanday saqlash, ya'ni qandaydir tarzda qanday foydalanish va u bilan qanday ishlash haqida gaplashdik. Va bugun men taqsimlangan ilovalarni yaratish haqida bir oz gaplashmoqchiman. ZooKeeper esa bu masalani soddalashtirishga imkon beradigan narsalardan biridir. Bu taqsimlangan tizimlarda, taqsimlangan ilovalarda jarayonlarning o'zaro ta'sirini qandaydir muvofiqlashtirish uchun mo'ljallangan xizmat turi.
Bunday ilovalarga bo'lgan ehtiyoj kundan-kunga ortib bormoqda, bizning kursimiz shundan iborat. Bir tomondan, MapReduce va bu tayyor ramka ushbu murakkablikni tekislash va dasturchini jarayonlarning o'zaro ta'siri va muvofiqlashtirish kabi ibtidoiy narsalarni yozishdan ozod qilish imkonini beradi. Ammo boshqa tomondan, hech kim buni baribir qilish shart emasligiga kafolat bermaydi. MapReduce yoki boshqa tayyor ramkalar har doim ham bu yordamida amalga oshirib bo'lmaydigan ba'zi holatlarni to'liq almashtirmaydi. Shu jumladan MapReduce va boshqa bir qator Apache loyihalari, ular ham tarqatilgan ilovalardir; Va yozishni osonlashtirish uchun ular ZooKeeperni yozishdi.
Hadoop bilan bog'liq barcha ilovalar singari, u Yahoo! Endi u rasmiy Apache ilovasi hisoblanadi. U HBase kabi faol rivojlanmagan. Agar siz JIRA HBase-ga kirsangiz, unda har kuni bir nechta xato hisobotlari, biror narsani optimallashtirish bo'yicha takliflar to'plami keladi, ya'ni loyihadagi hayot doimiy ravishda davom etadi. ZooKeeper esa, bir tomondan, nisbatan sodda mahsulot bo‘lsa, ikkinchi tomondan, bu uning ishonchliligini ta’minlaydi. Va undan foydalanish juda oson, shuning uchun u Hadoop ekotizimidagi ilovalarda standartga aylandi. Shuning uchun men uni qanday ishlashini va undan qanday foydalanishni tushunish uchun uni ko'rib chiqish foydali bo'ladi deb o'yladim.
Bu biz o'qigan ma'ruzadan olingan rasm. Aytishimiz mumkinki, biz hozirgacha ko'rib chiqqan hamma narsaga ortogonaldir. Va bu erda ko'rsatilgan hamma narsa, u yoki bu darajada, ZooKeeper bilan ishlaydi, ya'ni bu barcha mahsulotlardan foydalanadigan xizmatdir. HDFS ham, MapReduce ham ular uchun maxsus ishlaydigan o'xshash xizmatlarni yozmaydi. Shunga ko'ra, ZooKeeper ishlatiladi. Va bu rivojlanishni va xatolar bilan bog'liq ba'zi narsalarni soddalashtiradi.
Bularning barchasi qayerdan keladi? Ko'rinishidan, biz ikkita dasturni turli xil kompyuterlarda parallel ravishda ishga tushirdik, ularni sim yoki tarmoq bilan bog'ladik va hamma narsa ishlaydi. Ammo muammo shundaki, Tarmoq ishonchsizdir va agar siz trafikni hidlagan bo'lsangiz yoki u erda nima sodir bo'layotganini past darajada ko'rib chiqsangiz, mijozlar tarmoqda qanday o'zaro aloqada bo'lsa, siz ko'pincha ba'zi paketlar yo'qolganini yoki qayta yuborilganini ko'rishingiz mumkin. TCP protokollari ixtiro qilingani bejiz emas, bu sizga ma'lum bir seansni o'rnatish va xabarlarni etkazib berishni kafolatlash imkonini beradi. Lekin har qanday holatda ham, hatto TCP ham sizni doimo qutqara olmaydi. Hamma narsaning vaqti bor. Tarmoq shunchaki bir muddat tushib ketishi mumkin. Bu shunchaki miltillashi mumkin. Va bularning barchasi siz tarmoqning ishonchliligiga tayanolmaysiz. Bu bitta kompyuterda yoki bitta superkompyuterda ishlaydigan, tarmoq mavjud bo'lmagan, xotirada ishonchliroq ma'lumot almashish shinasi mavjud bo'lgan parallel dasturlarni yozishdan asosiy farq. Va bu asosiy farq.
Boshqa narsalar qatorida, Tarmoqdan foydalanganda har doim ma'lum bir kechikish mavjud. Diskda ham bor, lekin tarmoqda undan ko'proq narsa bor. Kechikish - bu biroz kechikish vaqti bo'lib, u kichik yoki juda muhim bo'lishi mumkin.
Tarmoq topologiyasi o'zgarmoqda. Topologiya nima - bu bizning tarmoq uskunalarini joylashtirish. Ma'lumotlar markazlari bor, u erda turadigan stendlar, shamlar bor. Bularning barchasini qayta ulash, ko'chirish va hokazo. Bularning barchasini ham hisobga olish kerak. IP nomlari o'zgaradi, bizning trafik sayohatimiz yo'nalishi o'zgaradi. Buni ham hisobga olish kerak.
Tarmoq uskuna jihatidan ham o'zgarishi mumkin. Amaliyotdan shuni aytishim mumkinki, bizning tarmoq muhandislarimiz vaqti-vaqti bilan shamlarda nimanidir yangilashni yaxshi ko'radilar. To'satdan yangi proshivka paydo bo'ldi va ular Hadoop klasteriga unchalik qiziqmasdi. Ularning o'z ishi bor. Ular uchun asosiysi Tarmoq ishlaydi. Shunga ko'ra, ular u erda biror narsani qayta yuklashni, o'zlarining apparatlarida miltillashni xohlashadi va apparat vaqti-vaqti bilan o'zgarib turadi. Bularning barchasi qandaydir tarzda hisobga olinishi kerak. Bularning barchasi bizning tarqatilgan ilovamizga ta'sir qiladi.
Odatda katta hajmdagi ma'lumotlar bilan ishlashni boshlagan odamlar negadir Internetning cheksiz ekanligiga ishonishadi. Agar u erda bir necha terabaytli fayl bo'lsa, uni serveringizga yoki kompyuteringizga olib borib, undan foydalanib ochishingiz mumkin mushuk va tomosha qiling. Yana bir xato Vim jurnallarga qarang. Hech qachon buni qilmang, chunki bu yomon. Chunki Vim hamma narsani buferlashga, xotiraga hamma narsani yuklashga harakat qiladi, ayniqsa biz ushbu jurnal orqali harakat qilishni va biror narsani qidira boshlaganimizda. Bu unutilgan narsalar, ammo e'tiborga olish kerak.
Bitta protsessorli bitta kompyuterda ishlaydigan bitta dasturni yozish osonroq.
Tizimimiz o'sib ulg'aygach, biz hammasini parallellashtirishni va uni nafaqat kompyuterda, balki klasterda ham parallel qilishni xohlaymiz. Savol tug'iladi: bu masalani qanday muvofiqlashtirish kerak? Bizning ilovalarimiz hatto bir-biri bilan o'zaro aloqada bo'lmasligi mumkin, lekin biz bir nechta serverlarda parallel ravishda bir nechta jarayonlarni bajardik. Va ular uchun hamma narsa yaxshi ketayotganini qanday kuzatish mumkin? Misol uchun, ular Internet orqali biror narsa yuborishadi. Ular o'zlarining holati haqida biror joyda, masalan, ma'lumotlar bazasi yoki jurnalida yozishlari kerak, keyin bu jurnalni yig'ib, keyin uni biron bir joyda tahlil qilishlari kerak. Bundan tashqari, jarayon ishlayotganini va ishlayotganini hisobga olishimiz kerak, to'satdan unda qandaydir xatolik paydo bo'ldi yoki u qulab tushdi, keyin biz bu haqda qanchalik tez bilib olamiz?
Bularning barchasini tezda kuzatib borish mumkinligi aniq. Bu ham yaxshi, lekin monitoring ba'zi narsalarni eng yuqori darajada kuzatish imkonini beruvchi cheklangan narsadir.
Agar biz jarayonlarimiz bir-biri bilan o'zaro aloqada bo'lishini xohlasak, masalan, bir-birimizga ba'zi ma'lumotlarni yuborishimiz uchun, savol tug'iladi - bu qanday sodir bo'ladi? Qandaydir poyga holati bo'ladimi, ular bir-birining ustiga yozadimi, ma'lumotlar to'g'ri keladimi, yo'lda biror narsa yo'qoladimi? Biz qandaydir protokolni ishlab chiqishimiz kerak va hokazo.
Bu jarayonlarning barchasini muvofiqlashtirish arzimas narsa emas. Va bu ishlab chiquvchini yanada pastroq darajaga tushishga va tizimlarni noldan yoki noldan yozishga majbur qiladi, ammo bu unchalik oddiy emas.
Agar siz kriptografik algoritmni o'ylab topsangiz yoki hatto uni amalga oshirsangiz, uni darhol tashlang, chunki u siz uchun ishlamaydi. Unda siz ta'minlashni unutgan bir qator xatolar bo'lishi mumkin. Uni hech qachon jiddiy narsa uchun ishlatmang, chunki u beqaror bo'lishi mumkin. Chunki mavjud bo'lgan barcha algoritmlar juda uzoq vaqt davomida sinovdan o'tgan. Bu jamiyat tomonidan buziladi. Bu alohida mavzu. Va bu erda ham xuddi shunday. Agar jarayonni sinxronlashtirishning bir turini o'zingiz amalga oshirmaslik mumkin bo'lsa, unda buni qilmaslik yaxshiroqdir, chunki bu juda murakkab va sizni doimiy ravishda xatolarni qidirishning chayqaladigan yo'liga olib boradi.
Bugun biz ZooKeeper haqida gaplashamiz. Bir tomondan, bu ramka, boshqa tomondan, bu ishlab chiquvchining hayotini osonlashtiradigan va mantiqni amalga oshirishni va jarayonlarimizni muvofiqlashtirishni imkon qadar soddalashtiradigan xizmatdir.
Keling, standart taqsimlangan tizim qanday ko'rinishini eslaylik. Bu biz gaplashgan narsa - HDFS, HBase. Ishchilar va qul jarayonlarini boshqaradigan Master jarayoni mavjud. U vazifalarni muvofiqlashtirish va taqsimlash, ishchilarni qayta ishga tushirish, yangilarini ishga tushirish va yukni taqsimlash uchun javobgardir.
Keyinchalik rivojlangan narsa - Muvofiqlashtirish xizmati, ya'ni muvofiqlashtirish vazifasini o'zi alohida jarayonga o'tkazing, shuningdek, qandaydir zaxira nusxasini yoki stanby Master-ni parallel ravishda ishga tushiring, chunki Master muvaffaqiyatsiz bo'lishi mumkin. Va agar Usta tushib qolsa, unda bizning tizimimiz ishlamaydi. Biz zaxira nusxasini ishga tushirmoqdamiz. Ba'zilar Master-ni zaxiralash uchun nusxalash kerakligini ta'kidlaydi. Buni muvofiqlashtirish xizmatiga ham ishonib topshirish mumkin. Ammo bu diagrammada ustaning o'zi ishchilarni muvofiqlashtirish uchun javobgardir, bu erda xizmat ma'lumotlarni takrorlash faoliyatini muvofiqlashtiradi;
Odatdagidek, barcha muvofiqlashtirish bizning xizmatimiz tomonidan amalga oshirilganda yanada rivojlangan variant. U hamma narsa ishlayotganiga ishonch hosil qilish uchun mas'uliyatni o'z zimmasiga oladi. Va agar biror narsa ishlamasa, biz bu haqda bilib olamiz va bu vaziyatdan chiqishga harakat qilamiz. Qanday bo'lmasin, bizda qandaydir tarzda qullar bilan o'zaro aloqada bo'lgan va qandaydir xizmat orqali ma'lumotlar, ma'lumotlar, xabarlar va hokazolarni yuborishi mumkin bo'lgan Usta qoladi.
Bundan ham takomillashtirilgan sxema mavjud, agar bizda Usta bo'lmasa, barcha tugunlar o'zlarining xatti-harakatlarida har xil bo'lgan usta qullardir. Lekin ular hali ham bir-birlari bilan o'zaro aloqada bo'lishlari kerak, shuning uchun bu harakatlarni muvofiqlashtirish uchun hali ham ba'zi xizmatlar mavjud. Ehtimol, ushbu printsip bo'yicha ishlaydigan Kassandra bu sxemaga mos keladi.
Ushbu sxemalarning qaysi biri yaxshiroq ishlashini aytish qiyin. Har birining o'zining ijobiy va salbiy tomonlari bor.
Ustoz bilan ba'zi narsalardan qo'rqishning hojati yo'q, chunki amaliyot shuni ko'rsatadiki, u doimiy ravishda xizmat qilishga unchalik moyil emas. Bu erda asosiy narsa - bu xizmatni alohida kuchli tugunga joylashtirish uchun to'g'ri echimni tanlash, u etarli resurslarga ega bo'lishi uchun, agar iloji bo'lsa, foydalanuvchilar bu jarayonni tasodifan o'ldirmasliklari uchun u erga kirish imkoniga ega emaslar. Ammo shu bilan birga, bunday sxemada ishchilarni Master jarayonidan boshqarish ancha oson, ya'ni bu sxema amalga oshirish nuqtai nazaridan oddiyroq.
Va bu sxema (yuqorida) ehtimol murakkabroq, ammo ishonchliroq.
Asosiy muammo - qisman muvaffaqiyatsizliklar. Misol uchun, biz tarmoq orqali xabar yuborganimizda, qandaydir baxtsiz hodisa ro'y beradi va xabarni yuborgan odam o'z xabari qabul qilinganmi yoki qabul qiluvchi tomonida nima sodir bo'lganligini bilmaydi, xabar to'g'ri ishlanganmi yoki yo'qligini bilmaydi. , ya'ni u hech qanday tasdiqni olmaydi.
Shunga ko'ra, biz bu vaziyatni qayta ishlashimiz kerak. Va eng oddiy narsa - bu xabarni qayta yuborish va biz javob olguncha kutish. Bunday holda, qabul qiluvchining holati o'zgarganmi yoki yo'qmi, hisobga olinmaydi. Biz xabar yuborishimiz va bir xil ma'lumotlarni ikki marta qo'shishimiz mumkin.
ZooKeeper bunday rad etish bilan kurashish usullarini taklif qiladi, bu ham bizning hayotimizni osonlashtiradi.
Biroz oldin aytib o'tganimizdek, bu ko'p bosqichli dasturlarni yozishga o'xshaydi, lekin asosiy farq shundaki, biz turli xil mashinalarda yaratadigan taqsimlangan ilovalarda muloqot qilishning yagona yo'li Tarmoqdir. Asosan, bu umumiy hech narsa bo'lmagan arxitektura. Bitta mashinada ishlaydigan har bir jarayon yoki xizmat o'z xotirasiga, o'z diskiga, o'z protsessoriga ega bo'lib, u hech kim bilan baham ko'rmaydi.
Agar biz bir kompyuterda ko'p tarmoqli dastur yozsak, u holda ma'lumotlarni almashish uchun umumiy xotiradan foydalanishimiz mumkin. Bizda kontekstli kalit bor, jarayonlar o'zgarishi mumkin. Bu ishlashga ta'sir qiladi. Bir tomondan, klasterdagi dasturda bunday narsa yo'q, lekin Tarmoq bilan bog'liq muammolar mavjud.
Shunga ko'ra, taqsimlangan tizimlarni yozishda yuzaga keladigan asosiy muammolar konfiguratsiyadir. Biz qandaydir ariza yozyapmiz. Agar bu oddiy bo'lsa, biz koddagi barcha turdagi raqamlarni qattiq kodlaymiz, lekin bu noqulay, chunki agar biz yarim soniyalik taym-aut o'rniga bir soniyalik taym-autni xohlaymiz deb qaror qilsak, biz ilovani qayta kompilyatsiya qilishimiz kerak va hamma narsani yana aylantiring. Agar u bitta mashinada bo'lsa, uni qayta ishga tushirishingiz mumkin bo'lgan narsa, lekin bizda ko'plab mashinalar mavjud bo'lganda, biz doimo hamma narsani nusxalashimiz kerak. Biz ilovani sozlanishi mumkin qilishga harakat qilishimiz kerak.
Bu erda biz tizim jarayonlari uchun statik konfiguratsiya haqida gapiramiz. Bu butunlay emas, balki operatsion tizim nuqtai nazaridan, bu bizning jarayonlarimiz uchun statik konfiguratsiya bo'lishi mumkin, ya'ni bu oddiygina qabul qilinishi va yangilanishi mumkin bo'lmagan konfiguratsiya.
Bundan tashqari, dinamik konfiguratsiya mavjud. Bu biz tezda o'zgartirmoqchi bo'lgan parametrlar, shunda ular o'sha erda olinadi.
Bu yerda qanday muammo bor? Biz konfiguratsiyani yangiladik, chiqardik, nima bo'ladi? Muammo shundaki, biz bir tomondan konfiguratsiyani chiqardik, lekin yangi narsani unutdik, konfiguratsiya o'sha erda qoldi. Ikkinchidan, biz ishlab chiqarayotganimizda, konfiguratsiya ba'zi joylarda yangilandi, ammo boshqalarida emas. Va bitta mashinada ishlaydigan ilovamizning ba'zi jarayonlari yangi konfiguratsiya bilan va biron bir joyda eskisi bilan qayta ishga tushirildi. Bu bizning tarqatilgan ilovamiz konfiguratsiya nuqtai nazaridan mos kelmasligiga olib kelishi mumkin. Bu muammo keng tarqalgan. Dinamik konfiguratsiya uchun bu ko'proq mos keladi, chunki u tezda o'zgartirilishi mumkinligini anglatadi.
Yana bir muammo - guruhga a'zolik. Bizda har doim ishchilar to'plami bor, biz doimo ulardan qaysi biri tirik, qaysi biri o'lik ekanligini bilishni xohlaymiz. Agar Magistr bo'lsa, u qaysi ishchilarni mijozlarga hisob-kitoblarni amalga oshirishi yoki ma'lumotlar bilan ishlashi uchun yo'naltirilishi mumkinligini tushunishi kerak va qaysi biri mumkin emas. Doimiy ravishda paydo bo'ladigan muammo shundaki, biz klasterimizda kim ishlayotganini bilishimiz kerak.
Yana bir tipik muammo - bu rahbarlar saylovi bo'lib, biz kimni boshqarayotganini bilishni xohlaymiz. Misollardan biri replikatsiya, agar bizda yozish operatsiyalarini qabul qiladigan va keyin ularni boshqa jarayonlar orasida takrorlaydigan ba'zi bir jarayon mavjud bo'lsa. U rahbar bo'ladi, hamma unga bo'ysunadi, unga ergashadi. Jarayonni shunday tanlash kerakki, u hamma uchun bir ma'noli bo'lsin, shunda ikki rahbar tanlanadi.
O'zaro eksklyuziv kirish ham mavjud. Bu erda muammo yanada murakkab. Muteks degan narsa bor, agar siz ko'p bosqichli dasturlarni yozsangiz va biron bir manbaga, masalan, xotira katakchasiga kirishni xohlasangiz, cheklangan bo'lishi va faqat bitta ip bilan amalga oshirilishi kerak. Bu erda resurs mavhumroq narsa bo'lishi mumkin. Tarmoqimizning turli tugunlaridagi turli xil ilovalar faqat ma'lum resursga eksklyuziv kirish huquqiga ega bo'lishi kerak, lekin hamma uni o'zgartirishi yoki u erda biror narsa yozishi mumkin emas. Bu qulflar deb ataladigan narsalar.
ZooKeeper sizga ushbu muammolarni u yoki bu darajada hal qilish imkonini beradi. Va men buni qanday amalga oshirishga imkon berishini misollar bilan ko'rsataman.
Hech qanday blokirovka qiluvchi primitivlar mavjud emas. Biz biror narsadan foydalanishni boshlaganimizda, bu ibtidoiy biron bir voqea sodir bo'lishini kutmaydi. Katta ehtimol bilan, bu narsa asinxron ishlaydi va shu bilan jarayonlar biror narsani kutayotganda osilib qolmasligiga imkon beradi. Bu juda foydali narsa.
Mijozlarning barcha so'rovlari umumiy navbat tartibida ko'rib chiqiladi.
Mijozlar o'zgartirilgan ma'lumotlarni o'zlari ko'rmasdan oldin, ba'zi bir holatdagi o'zgarishlar, ma'lumotlarning o'zgarishi haqida xabar olish imkoniyatiga ega.
ZooKeeper ikki rejimda ishlashi mumkin. Birinchisi mustaqil, bitta tugunda. Bu sinov uchun qulay. Shuningdek, u istalgan miqdordagi tugunda klaster rejimida ishlashi mumkin. serverlarAgar bizda 100 ta mashinadan iborat klaster bo'lsa, u 100 ta mashinada ishlashi shart emas. ZooKeeper ishlay oladigan bir nechta mashinalarni ajratish kifoya. Va u yuqori mavjudlik tamoyiliga amal qiladi. ZooKeeper har bir ishlayotgan misolda ma'lumotlarning to'liq nusxasini saqlaydi. Buni qanday qilishini keyinroq tushuntiraman. U ma'lumotlarni parchalamaydi yoki bo'lmaydi. Bir tomondan, bu kamchilik, chunki biz ko'p narsani saqlay olmaymiz, lekin boshqa tomondan, bu keraksiz. U buning uchun mo'ljallanmagan; bu ma'lumotlar bazasi emas.
Ma'lumotlar mijoz tomonida keshlanishi mumkin. Bu xizmatni to'xtatmasligimiz va uni bir xil so'rovlar bilan yuklamasligimiz uchun standart printsipdir. Aqlli mijoz odatda bu haqda biladi va uni keshlaydi.
Misol uchun, bu erda nimadir o'zgardi. Qandaydir dastur mavjud. Yangi rahbar saylandi, u, masalan, yozish operatsiyalarini qayta ishlash uchun javobgardir. Va biz ma'lumotlarni takrorlashni xohlaymiz. Bitta yechim uni halqa ichiga qo'yishdir. Va biz doimo xizmatimizni shubha ostiga qo'yamiz - biror narsa o'zgarganmi? Ikkinchi variant yanada maqbuldir. Bu mijozlarga biror narsa o'zgarganligi haqida xabar berishga imkon beruvchi soat mexanizmi. Bu resurslar nuqtai nazaridan arzonroq va mijozlar uchun qulayroq usul.
Mijoz ZooKeeper-dan foydalanadigan foydalanuvchidir.
Server ZooKeeper jarayonining o'zi.
Znode ZooKeeper-dagi asosiy narsadir. Barcha znodelar ZooKeeper tomonidan xotirada saqlanadi va ierarxik diagramma shaklida, daraxt shaklida tashkil etilgan.
Ikki turdagi operatsiyalar mavjud. Birinchisi, ba'zi operatsiyalar daraxtimizning holatini o'zgartirganda, yangilash/yozish. Daraxt keng tarqalgan.
Va, ehtimol, mijoz bitta so'rovni bajarmaydi va uzilib qoladi, lekin u ZooKeeper bilan o'zaro aloqada bo'ladigan seans o'rnatishi mumkin.
ZooKeeper ma'lumotlar modeli fayl tizimiga o'xshaydi. Standart ildiz bor va keyin biz ildizdan o'tadigan kataloglar orqali o'tdik. Va keyin birinchi darajali katalog, ikkinchi darajali. Bularning barchasi znodlar.
Har bir znode ba'zi ma'lumotlarni saqlashi mumkin, odatda unchalik katta bo'lmagan, masalan, 10 kilobayt. Va har bir znode ma'lum miqdordagi bolalarga ega bo'lishi mumkin.
Znodlar bir necha turga bo'linadi. Ular yaratilishi mumkin. Va znode yaratishda biz unga tegishli bo'lishi kerak bo'lgan turni belgilaymiz.
Ikkita tur mavjud. Birinchisi - vaqtinchalik bayroq. Znode bir seans ichida yashaydi. Masalan, mijoz seans o'rnatgan. Va bu sessiya tirik ekan, u mavjud bo'ladi. Bu keraksiz narsalarni ishlab chiqarmaslik uchun kerak. Bu seansda ma'lumotlarning primitivlarini saqlash biz uchun muhim bo'lgan paytlar uchun ham mos keladi.
Ikkinchi tur - ketma-ket bayroq. Znodega boradigan yo'lda hisoblagichni oshiradi. Misol uchun, bizda 1_5 ilovasi bo'lgan katalog mavjud edi. Va biz birinchi tugunni yaratganimizda, u p_1, ikkinchisi - p_2 oldi. Va bu usulni har safar chaqirganimizda, biz yo'lning faqat bir qismini ko'rsatib, to'liq yo'lni o'tkazamiz va bu raqam avtomatik ravishda oshiriladi, chunki biz tugun turini ko'rsatamiz - ketma-ket.
Oddiy znode. U har doim yashaydi va biz unga aytadigan ismga ega bo'ladi.
Yana bir foydali narsa - bu soat bayrog'i. Agar biz uni o'rnatsak, mijoz ma'lum bir tugun uchun ba'zi voqealarga obuna bo'lishi mumkin. Bu qanday amalga oshirilishini sizga misol bilan keyinroq ko'rsataman. ZooKeeper o'zi mijozga tugundagi ma'lumotlar o'zgarganligi haqida xabar beradi. Biroq, bildirishnomalar ba'zi yangi ma'lumotlar kelganligini kafolatlamaydi. Ular shunchaki biror narsa o'zgarganini aytishadi, shuning uchun siz hali ham ma'lumotlarni keyinroq alohida qo'ng'iroqlar bilan solishtirishingiz kerak.
Va allaqachon aytganimdek, ma'lumotlarning tartibi kilobaytlar bilan belgilanadi. U erda katta matnli ma'lumotlarni saqlashning hojati yo'q, chunki u ma'lumotlar bazasi emas, u harakatlarni muvofiqlashtirish serveridir.
Sizga sessiyalar haqida ozgina gapirib beray. Agar bizda bir nechta serverlar bo'lsa, biz bir serverdan boshqasiga shaffof ravishda o'tishimiz mumkin. server, sessiya identifikatoridan foydalanish. Bu juda qulay.
Har bir seansning o'ziga xos vaqti bor. Seans mijoz ushbu sessiya davomida serverga biror narsa yuboradimi yoki yo'qligi bilan belgilanadi. Agar u kutish vaqtida hech narsa uzatmagan bo'lsa, sessiya to'xtaydi yoki mijoz uni o'zi yopishi mumkin.
Unda unchalik ko'p funksiyalar mavjud emas, lekin siz ushbu API bilan har xil narsalarni qilishingiz mumkin. Biz yaratgan chaqiruv znode hosil qiladi va uchta parametrni oladi. Bu znode yo'lidir va u ildizdan to'liq ko'rsatilishi kerak. Shuningdek, bu biz u erga uzatmoqchi bo'lgan ba'zi ma'lumotlar. Va bayroq turi. Va yaratilgandan so'ng u znodega yo'lni qaytaradi.
Ikkinchidan, uni o'chirishingiz mumkin. Bu erda hiyla, ikkinchi parametr, znode yo'liga qo'shimcha ravishda, versiyani ko'rsatishi mumkin. Shunga ko'ra, agar biz uzatgan versiyasi haqiqatda mavjud bo'lganiga teng bo'lsa, ushbu znode o'chiriladi.
Agar biz ushbu versiyani tekshirishni istamasak, biz shunchaki "-1" argumentini o'tkazamiz.
Uchinchidan, u znode mavjudligini tekshiradi. Agar tugun mavjud bo'lsa, true qiymatini qaytaradi, aks holda noto'g'ri.
Va keyin bayroq soati paydo bo'ladi, bu sizga ushbu tugunni kuzatish imkonini beradi.
Siz ushbu bayroqni hatto mavjud bo'lmagan tugunga ham o'rnatishingiz va u paydo bo'lganda bildirishnoma olishingiz mumkin. Bu ham foydali bo'lishi mumkin.
Yana bir nechta qiyinchiliklar bor getData. Ma'lumotni znode orqali qabul qilishimiz aniq. Shuningdek, siz bayroq soatlaridan foydalanishingiz mumkin. Bunday holda, agar tugun bo'lmasa, u o'rnatilmaydi. Shuning uchun, siz uning mavjudligini tushunishingiz va keyin ma'lumotlarni olishingiz kerak.
Shuningdek bor SetData. Bu erda biz versiyaga o'tamiz. Va agar biz buni uzatsak, ma'lum bir versiyaning znode ma'lumotlari yangilanadi.
Ushbu chekni istisno qilish uchun "-1" ni ham belgilashingiz mumkin.
Yana bir foydali usul Bolalarni oling. Shuningdek, biz unga tegishli bo'lgan barcha znodlar ro'yxatini olishimiz mumkin. Biz buni bayroqcha soatini o'rnatish orqali kuzatishimiz mumkin.
Va usul Sinxronlash barcha o'zgarishlarni bir vaqtning o'zida yuborish imkonini beradi, shu bilan ularning saqlanishi va barcha ma'lumotlar to'liq o'zgartirilishini ta'minlaydi.
Agar biz oddiy dasturlash bilan o'xshashlik qilsak, diskka biror narsa yozadigan yozish kabi usullardan foydalanganda va u sizga javob qaytargandan so'ng, ma'lumotlarni diskka yozganingizga kafolat yo'q. Va operatsion tizim hamma narsa yozilganligiga ishonch hosil qilganda ham, diskning o'zida jarayon bufer qatlamlari orqali o'tadigan mexanizmlar mavjud va shundan keyingina ma'lumotlar diskka joylashtiriladi.
Ko'pincha asinxron qo'ng'iroqlar qo'llaniladi. Bu mijozga turli so'rovlar bilan parallel ravishda ishlash imkonini beradi. Sinxron yondashuvdan foydalanishingiz mumkin, ammo unumdorligi past.
Biz gaplashgan ikkita operatsiya - bu ma'lumotlarni o'zgartiradigan yangilash/yozish. Bular yaratish, sozlash, sinxronlash, o'chirish. Va o'qish mavjud, getData, getChildren.
Endi taqsimlangan tizimda ishlash uchun primitivlarni qanday yaratishingiz mumkinligiga bir nechta misollar. Masalan, biror narsaning konfiguratsiyasi bilan bog'liq. Yangi ishchi paydo bo'ldi. Biz mashinani qo'shdik va jarayonni boshladik. Va quyidagi uchta savol bor. Konfiguratsiya uchun ZooKeeper qanday so'raladi? Va agar biz konfiguratsiyani o'zgartirmoqchi bo'lsak, uni qanday o'zgartiramiz? Va biz uni o'zgartirganimizdan so'ng, bizda bo'lgan ishchilar buni qanday olishadi?
ZooKeeper buni nisbatan osonlashtiradi. Masalan, bizning znode daraxtimiz bor. Bu erda bizning ilovamiz uchun tugun mavjud, biz unda konfiguratsiya ma'lumotlarini o'z ichiga olgan qo'shimcha tugunni yaratamiz. Bu alohida parametrlar bo'lishi mumkin yoki bo'lmasligi mumkin. Hajmi kichik bo'lgani uchun, konfiguratsiya hajmi odatda kichik, shuning uchun uni bu erda saqlash juda mumkin.
Siz usuldan foydalanasiz getData tugundan ishchi uchun konfiguratsiyani olish uchun. rostga sozlang. Agar biron sababga ko'ra ushbu tugun mavjud bo'lmasa, u paydo bo'lganda yoki u o'zgarganda bizga xabar beriladi. Agar biror narsa o'zgarganini bilmoqchi bo'lsak, uni haqiqatga aylantiramiz. Va agar bu tugundagi ma'lumotlar o'zgarsa, biz bu haqda bilib olamiz.
SetData. Biz ma'lumotlarni o'rnatamiz, "-1" ni o'rnatamiz, ya'ni versiyani tekshirmaymiz, biz doimo bitta konfiguratsiyaga egamiz deb hisoblaymiz, ko'p konfiguratsiyalarni saqlashimiz shart emas. Agar siz ko'p narsalarni saqlashingiz kerak bo'lsa, siz boshqa darajani qo'shishingiz kerak bo'ladi. Bu erda biz faqat bittasi borligiga ishonamiz, shuning uchun biz faqat oxirgisini yangilaymiz, shuning uchun versiyani tekshirmaymiz. Ayni paytda avval obuna bo'lgan barcha mijozlar ushbu tugunda biror narsa o'zgarganligi haqida xabar olishadi. Va ular uni olgandan so'ng, ular yana ma'lumotlarni so'rashlari kerak. Xabar shundaki, ular ma'lumotlarni o'zi olmaydilar, faqat o'zgarishlar haqida xabar berishadi. Shundan so'ng ular yangi ma'lumotlarni so'rashlari kerak.
Primitivdan foydalanishning ikkinchi varianti guruhga a'zolik. Bizda tarqatilgan dastur bor, bir guruh ishchilar bor va biz ularning hammasi joyida ekanligini tushunmoqchimiz. Shuning uchun ular bizning arizamizda ishlayotganliklarini ro'yxatdan o'tkazishlari kerak. Shuningdek, biz Master jarayonidan yoki boshqa joydan, bizda mavjud bo'lgan barcha faol ishchilar haqida bilishni xohlaymiz.
Buni qanday qilamiz? Ilova uchun biz ishchilar tugunini yaratamiz va yaratish usuli yordamida u erga pastki darajani qo'shamiz. Slaydda xatolik bor. Mana sizga kerak ketma-ket belgilang, keyin barcha ishchilar birma-bir yaratiladi. Va ushbu tugunning bolalari haqidagi barcha ma'lumotlarni so'rab dastur mavjud bo'lgan barcha faol ishchilarni oladi.
Bu Java kodida buni qanday amalga oshirish mumkinligining dahshatli amalga oshirilishi. Asosiy usul bilan oxiridan boshlaylik. Bu bizning sinfimiz, keling, uning usulini yarataylik. Birinchi argument sifatida biz ulanayotgan hostdan foydalanamiz, ya'ni uni argument sifatida o'rnatamiz. Va ikkinchi dalil - bu guruhning nomi.
Ulanish qanday sodir bo'ladi? Bu ishlatiladigan APIning oddiy misolidir. Bu erda hamma narsa nisbatan sodda. ZooKeeper standart sinfi mavjud. Biz unga xostlarni o'tkazamiz. Va vaqt tugashini, masalan, 5 soniyaga o'rnating. Va bizda connectSignal nomli a'zomiz bor. Aslida, biz uzatilgan yo'l bo'ylab guruh yaratamiz. Biz u erda ma'lumot yozmaymiz, garchi biror narsa yozilishi mumkin edi. Va bu erda tugun doimiy turdagi. Aslida, bu har doim mavjud bo'lgan oddiy oddiy tugun. Bu erda sessiya yaratiladi. Bu mijozning o'zini amalga oshirishdir. Bizning mijozimiz vaqti-vaqti bilan sessiya tirikligi haqida xabar beradi. Va biz sessiyani tugatgandan so'ng, biz yaqin deb qo'ng'iroq qilamiz va tamom, sessiya tushadi. Bu biz uchun biror narsa tushib qolsa, ZooKeeper bu haqda bilib oladi va sessiyani to'xtatadi.
Resursni qanday qulflash mumkin? Bu erda hamma narsa biroz murakkabroq. Bizda ishchilar to'plami bor, biz qulflamoqchi bo'lgan manba bor. Buning uchun biz alohida tugun yaratamiz, masalan, lock1 deb ataladi. Agar biz uni yarata olgan bo'lsak, unda biz bu erda qulfni oldik. Va agar biz uni yarata olmasak, u holda ishchi bu yerdan getData ni olishga harakat qiladi va tugun allaqachon yaratilganligi sababli, biz bu erga kuzatuvchi qo'yamiz va bu tugunning holati o'zgarganda, biz bu haqda bilib olamiz. Va biz uni qayta yaratishga vaqt ajratishga harakat qilishimiz mumkin. Agar biz ushbu tugunni olgan bo'lsak, bu qulfni olgan bo'lsak, endi qulfga muhtoj bo'lmaganimizdan so'ng, biz uni tark etamiz, chunki tugun faqat seans ichida mavjud. Shunga ko'ra, u yo'qoladi. Va yana bir mijoz, boshqa sessiya doirasida, ushbu tugunni qulflashi mumkin, aniqrog'i, u biror narsa o'zgarganligi haqida xabar oladi va u buni o'z vaqtida bajarishga harakat qilishi mumkin.
Asosiy rahbarni qanday tanlash mumkinligiga yana bir misol. Bu biroz murakkabroq, lekin ayni paytda nisbatan sodda. Bu yerda nima bo'lyapti? Barcha ishchilarni birlashtiruvchi asosiy tugun mavjud. Biz rahbar haqida ma'lumot olishga harakat qilmoqdamiz. Agar bu muvaffaqiyatli sodir bo'lgan bo'lsa, ya'ni biz ba'zi ma'lumotlarni olgan bo'lsak, unda bizning ishchimiz bu rahbarga ergashishni boshlaydi. U allaqachon rahbar borligiga ishonadi.
Agar rahbar biron sababga ko'ra vafot etgan bo'lsa, masalan, yiqilib tushsa, biz yangi rahbar yaratishga harakat qilamiz. Va agar biz muvaffaqiyatga erishsak, unda bizning ishchimiz etakchiga aylanadi. Va agar kimdir hozirgi paytda yangi rahbar yaratishga muvaffaq bo'lsa, biz uning kimligini tushunishga harakat qilamiz va keyin unga ergashamiz.
Bu erda poda effekti deb ataladigan narsa paydo bo'ladi, ya'ni poda effekti, chunki lider vafot etganda, vaqtida birinchi bo'lgan etakchiga aylanadi.
Resursni qo'lga kiritishda siz biroz boshqacha yondashuvdan foydalanishga harakat qilishingiz mumkin, bu quyidagicha. Misol uchun, biz qulf olishni xohlaymiz, lekin hert effektisiz. Bu bizning ilovamiz qulflangan allaqachon mavjud tugun uchun barcha tugun identifikatorlari ro'yxatini so'rashidan iborat bo'ladi. Va agar bundan oldin biz qulf yaratgan tugun biz olgan to'plamning eng kichigi bo'lsa, bu biz qulfni qo'lga kiritganimizni anglatadi. Biz qulf olganimizni tekshiramiz. Tekshirish sifatida, yangi qulf yaratishda biz olgan identifikator minimal bo'lishi sharti bo'ladi. Va agar biz uni olgan bo'lsak, unda biz yana ishlaymiz.
Agar ma'lum bir identifikator bizning qulfimizdan kichikroq bo'lsa, biz ushbu hodisaga kuzatuvchi qo'yamiz va biror narsa o'zgarmaguncha bildirishnomani kutamiz. Ya'ni, biz bu qulfni oldik. Va u yiqilmaguncha, biz minimal identifikatorga aylanmaymiz va minimal qulfni olmaymiz, shuning uchun biz tizimga kira olamiz. Va agar bu shart bajarilmasa, biz darhol bu erga boramiz va bu qulfni qayta tiklashga harakat qilamiz, chunki bu vaqt ichida biror narsa o'zgargan bo'lishi mumkin.
ZooKeeper nimadan iborat? 4 ta asosiy narsa bor. Bu qayta ishlash jarayonlari - So'rov. Shuningdek, ZooKeeper Atomic Broadcast. Barcha operatsiyalar qayd etilgan Commit jurnali mavjud. Va In-Memory Replicated DB ning o'zi, ya'ni bu butun daraxt saqlanadigan ma'lumotlar bazasining o'zi.
Shuni ta'kidlash kerakki, barcha yozish operatsiyalari so'rov protsessoridan o'tadi. Va o'qish operatsiyalari to'g'ridan-to'g'ri In-Memory ma'lumotlar bazasiga o'tadi.
Ma'lumotlar bazasining o'zi to'liq takrorlanadi. ZooKeeper-ning barcha nusxalari ma'lumotlarning to'liq nusxasini saqlaydi.
Buzilishdan keyin ma'lumotlar bazasini tiklash uchun "Commit" jurnali mavjud. Standart amaliyot shundan iboratki, ma'lumotlar xotiraga tushishidan oldin u erda yoziladi, shunda u ishlamay qolsa, bu jurnalni qayta o'ynash va tizim holatini tiklash mumkin. Shuningdek, ma'lumotlar bazasining davriy suratlari ham qo'llaniladi.
ZooKeeper Atomic Broadcast - bu takrorlangan ma'lumotlarni saqlash uchun ishlatiladigan narsa.
ZAB ZooKeeper tugunining nuqtai nazaridan liderni ichki tanlaydi. Boshqa tugunlar uning izdoshlariga aylanadi va undan ba'zi harakatlarni kutadi. Agar ular arizalarni qabul qilsalar, ularning barchasini rahbarga yuboradilar. U birinchi navbatda yozish operatsiyasini bajaradi va keyin uning izdoshlariga nima o'zgarganligi haqida xabar yuboradi. Bu, aslida, atomik tarzda amalga oshirilishi kerak, ya'ni hamma narsani yozib olish va translyatsiya qilish jarayoni atomik tarzda amalga oshirilishi kerak, bu esa ma'lumotlarning mustahkamligini kafolatlaydi.
U faqat yozish so'rovlarini qayta ishlaydi. Uning asosiy vazifasi operatsiyani tranzaksiya yangilanishiga aylantirishdir. Bu maxsus yaratilgan so'rov.
Va bu erda shuni ta'kidlash kerakki, xuddi shu operatsiya uchun yangilanishlarning kuchsizligi kafolatlanadi. Bu nima? Bu narsa, agar ikki marta bajarilsa, bir xil holatga ega bo'ladi, ya'ni so'rovning o'zi o'zgarmaydi. Va bu shunday qilish kerakki, avariya sodir bo'lgan taqdirda siz operatsiyani qayta boshlashingiz va shu bilan hozirgi vaqtda tushib qolgan o'zgarishlarni qaytarib olishingiz mumkin. Bunday holda, tizimning holati bir xil bo'ladi, ya'ni bir xil ketma-ketliklar, masalan, yangilash jarayonlari tizimning turli yakuniy holatiga olib kelgan bo'lmasligi kerak.
Manba: www.habr.com
