Saya cadangkan anda membaca transkrip kuliah "Hadoop. ZooKeeper" daripada siri "Kaedah untuk pemprosesan teragih volum data yang besar dalam Hadoop"
Apakah itu ZooKeeper, tempatnya dalam ekosistem Hadoop. Kebohongan tentang pengkomputeran teragih. Gambar rajah sistem teragih piawai. Kesukaran dalam menyelaraskan sistem teragih. Masalah penyelarasan biasa. Prinsip di sebalik reka bentuk ZooKeeper. Model data ZooKeeper. bendera znod. Sesi. API Pelanggan. Primitif (konfigurasi, keahlian kumpulan, kunci mudah, pemilihan pemimpin, penguncian tanpa kesan kumpulan). Seni bina ZooKeeper. ZooKeeper DB. ZAB. Pengendali permintaan.
Hari ini kita akan bercakap tentang ZooKeeper. Perkara ini sangat berguna. Ia, seperti mana-mana produk Apache Hadoop, mempunyai logo. Ia menggambarkan seorang lelaki.
Sebelum ini, kami terutamanya bercakap tentang bagaimana data boleh diproses di sana, bagaimana untuk menyimpannya, iaitu, bagaimana untuk menggunakannya entah bagaimana dan bekerja dengannya entah bagaimana. Dan hari ini saya ingin bercakap sedikit tentang membina aplikasi yang diedarkan. Dan ZooKeeper adalah salah satu perkara yang membolehkan anda memudahkan perkara ini. Ini adalah sejenis perkhidmatan yang bertujuan untuk beberapa jenis penyelarasan interaksi proses dalam sistem teragih, dalam aplikasi teragih.
Keperluan untuk permohonan sebegini semakin menjadi-jadi setiap hari, itulah maksud kursus kami. Di satu pihak, MapReduce dan rangka kerja sedia ini membolehkan anda meratakan kerumitan ini dan membebaskan pengaturcara daripada menulis primitif seperti interaksi dan penyelarasan proses. Tetapi sebaliknya, tiada siapa yang menjamin bahawa ini tidak perlu dilakukan. MapReduce atau rangka kerja sedia lain tidak selalu menggantikan sepenuhnya beberapa kes yang tidak boleh dilaksanakan menggunakan ini. Termasuk MapReduce sendiri dan sekumpulan projek Apache lain; mereka, sebenarnya, juga merupakan aplikasi yang diedarkan. Dan untuk memudahkan penulisan, mereka menulis ZooKeeper.
Seperti semua aplikasi berkaitan Hadoop, ia dibangunkan oleh Yahoo! Ia kini juga merupakan aplikasi Apache rasmi. Ia tidak dibangunkan secara aktif seperti HBase. Jika anda pergi ke JIRA HBase, maka setiap hari terdapat sekumpulan laporan pepijat, sekumpulan cadangan untuk mengoptimumkan sesuatu, iaitu kehidupan dalam projek itu sentiasa berjalan. Dan ZooKeeper, dalam satu tangan, adalah produk yang agak mudah, dan sebaliknya, ini memastikan kebolehpercayaannya. Dan ia agak mudah untuk digunakan, itulah sebabnya ia telah menjadi standard dalam aplikasi dalam ekosistem Hadoop. Jadi saya fikir ia berguna untuk menyemaknya untuk memahami cara ia berfungsi dan cara menggunakannya.
Ini adalah gambar dari beberapa kuliah yang kami ada. Kita boleh mengatakan bahawa ia adalah ortogonal kepada semua yang telah kita pertimbangkan setakat ini. Dan semua yang ditunjukkan di sini, pada satu tahap atau yang lain, berfungsi dengan ZooKeeper, iaitu, ia adalah perkhidmatan yang menggunakan semua produk ini. Baik HDFS mahupun MapReduce tidak menulis perkhidmatan serupa mereka sendiri yang secara khusus akan berfungsi untuk mereka. Sehubungan itu, ZooKeeper digunakan. Dan ini memudahkan pembangunan dan beberapa perkara yang berkaitan dengan ralat.
Dari mana datangnya semua ini? Nampaknya kami melancarkan dua aplikasi secara selari pada komputer yang berbeza, menyambungkannya dengan rentetan atau dalam jaringan, dan semuanya berfungsi. Tetapi masalahnya ialah Rangkaian tidak boleh dipercayai, dan jika anda menghidu trafik atau melihat apa yang berlaku di sana pada tahap yang rendah, cara pelanggan berinteraksi di Rangkaian, anda sering dapat melihat bahawa sesetengah paket hilang atau dihantar semula. Bukan tanpa alasan bahawa protokol TCP dicipta, yang membolehkan anda menubuhkan sesi tertentu dan menjamin penghantaran mesej. Tetapi dalam apa jua keadaan, walaupun TCP tidak selalu dapat menyelamatkan anda. Semuanya mempunyai masa tamat. Rangkaian mungkin terputus untuk seketika. Ia mungkin hanya berkelip. Dan ini semua membawa kepada fakta bahawa anda tidak boleh bergantung pada Rangkaian yang boleh dipercayai. Ini adalah perbezaan utama daripada menulis aplikasi selari yang berjalan pada satu komputer atau pada satu superkomputer, di mana tiada Rangkaian, di mana terdapat bas pertukaran data yang lebih dipercayai dalam ingatan. Dan ini adalah perbezaan asas.
Antara lain, apabila menggunakan Rangkaian, sentiasa ada kependaman tertentu. Cakera juga mempunyainya, tetapi Rangkaian mempunyai lebih banyak daripadanya. Latensi ialah beberapa masa kelewatan, yang boleh sama ada kecil atau agak ketara.
Topologi rangkaian sedang berubah. Apakah itu topologi - ini ialah penempatan peralatan rangkaian kami. Ada pusat data, ada rak yang berdiri di sana, ada lilin. Semua ini boleh disambung semula, dipindahkan, dan lain-lain. Ini semua juga perlu diambil kira. Nama IP berubah, laluan yang melaluinya trafik kita berubah. Ini juga perlu diambil kira.
Rangkaian juga mungkin berubah dari segi peralatan. Dari amalan, saya boleh mengatakan bahawa jurutera rangkaian kami sangat suka mengemas kini sesuatu secara berkala pada lilin. Tiba-tiba perisian tegar baharu keluar dan mereka tidak begitu berminat dengan beberapa kluster Hadoop. Mereka ada kerja sendiri. Bagi mereka, perkara utama ialah Rangkaian berfungsi. Sehubungan itu, mereka ingin memuat naik semula sesuatu di sana, melakukan flashing pada perkakasan mereka, dan perkakasan juga berubah secara berkala. Semua ini entah bagaimana perlu diambil kira. Semua ini menjejaskan aplikasi yang diedarkan kami.
Biasanya orang yang mula bekerja dengan jumlah data yang besar atas sebab tertentu percaya bahawa Internet tidak terhad. Jika terdapat fail beberapa terabait di sana, maka anda boleh membawanya ke pelayan atau komputer anda dan membukanya menggunakan kucing dan tonton. Ralat lain berlaku Vim tengok balak. Jangan sekali-kali melakukan ini kerana ia tidak baik. Kerana Vim cuba menimbal segala-galanya, memuatkan segala-galanya ke dalam memori, terutamanya apabila kita mula bergerak melalui log ini dan mencari sesuatu. Ini adalah perkara yang dilupakan, tetapi patut dipertimbangkan.
Lebih mudah untuk menulis satu program yang berjalan pada satu komputer dengan satu pemproses.
Apabila sistem kami berkembang, kami mahu menyelaraskan semuanya, dan menyelaraskannya bukan sahaja pada komputer, tetapi juga pada kelompok. Timbul persoalan: bagaimana untuk menyelaraskan perkara ini? Aplikasi kami mungkin tidak berinteraksi antara satu sama lain, tetapi kami menjalankan beberapa proses secara selari pada beberapa pelayan. Dan bagaimana untuk memantau bahawa semuanya berjalan lancar untuk mereka? Sebagai contoh, mereka menghantar sesuatu melalui Internet. Mereka mesti menulis tentang keadaan mereka di suatu tempat, contohnya, dalam beberapa jenis pangkalan data atau log, kemudian agregat log ini dan kemudian menganalisisnya di suatu tempat. Selain itu, kita perlu mengambil kira bahawa proses itu berfungsi dan berfungsi, tiba-tiba beberapa ralat muncul di dalamnya atau ia ranap, maka berapa cepat kita akan mengetahui tentangnya?
Adalah jelas bahawa semua ini boleh dipantau dengan cepat. Ini juga bagus, tetapi pemantauan adalah perkara terhad yang membolehkan anda memantau beberapa perkara pada tahap tertinggi.
Apabila kita mahu proses kita mula berinteraksi antara satu sama lain, sebagai contoh, untuk menghantar satu sama lain beberapa data, maka persoalan juga timbul - bagaimana ini akan berlaku? Adakah terdapat beberapa jenis keadaan perlumbaan, adakah mereka akan menimpa satu sama lain, adakah data akan tiba dengan betul, adakah apa-apa akan hilang di sepanjang jalan? Kita perlu membangunkan beberapa jenis protokol, dsb.
Penyelarasan semua proses ini bukanlah perkara yang remeh. Dan ia memaksa pembangun untuk turun ke tahap yang lebih rendah, dan menulis sistem sama ada dari awal, atau bukan dari awal, tetapi ini tidak begitu mudah.
Sekiranya anda menghasilkan algoritma kriptografi atau bahkan melaksanakannya, maka buangnya dengan segera, kerana kemungkinan besar ia tidak akan berfungsi untuk anda. Ia berkemungkinan besar akan mengandungi sekumpulan ralat yang anda terlupa sediakan. Jangan sekali-kali menggunakannya untuk perkara yang serius kerana kemungkinan besar ia tidak stabil. Kerana semua algoritma yang wujud telah diuji oleh masa untuk masa yang sangat lama. Ia diganggu oleh masyarakat. Ini adalah topik yang berasingan. Dan ia adalah sama di sini. Sekiranya ada kemungkinan untuk tidak melaksanakan beberapa jenis penyegerakan proses sendiri, maka lebih baik tidak melakukan ini, kerana ia agak rumit dan membawa anda ke jalan yang goyah untuk sentiasa mencari ralat.
Hari ini kita bercakap tentang ZooKeeper. Di satu pihak, ia adalah rangka kerja, sebaliknya, ia adalah perkhidmatan yang menjadikan kehidupan lebih mudah untuk pembangun dan memudahkan pelaksanaan logik dan penyelarasan proses kami sebanyak mungkin.
Mari kita ingat bagaimana rupa sistem edaran standard. Inilah yang kami bincangkan - HDFS, HBase. Terdapat proses Master yang menguruskan proses pekerja dan hamba. Dia bertanggungjawab untuk menyelaras dan mengagihkan tugas, memulakan semula pekerja, melancarkan tugas baharu dan mengagihkan beban.
Perkara yang lebih maju ialah Perkhidmatan Penyelarasan, iaitu, memindahkan tugas penyelarasan itu sendiri ke dalam proses yang berasingan, ditambah menjalankan beberapa jenis sandaran atau Master stanby secara selari, kerana Master mungkin gagal. Dan jika Master jatuh, maka sistem kita tidak akan berfungsi. Kami menjalankan sandaran. Sesetengah menyatakan bahawa Master perlu ditiru kepada sandaran. Ini juga boleh diamanahkan kepada Perkhidmatan Penyelarasan. Tetapi dalam rajah ini, Guru sendiri bertanggungjawab untuk menyelaraskan pekerja; di sini perkhidmatan itu menyelaraskan aktiviti replikasi data.
Pilihan yang lebih maju ialah apabila semua penyelarasan dikendalikan oleh perkhidmatan kami, seperti yang biasa dilakukan. Dia bertanggungjawab untuk memastikan semuanya berfungsi. Dan jika sesuatu tidak berfungsi, kami mengetahui tentangnya dan cuba mengatasi situasi ini. Walau apa pun, kita ditinggalkan dengan seorang Guru yang entah bagaimana berinteraksi dengan hamba dan boleh menghantar data, maklumat, mesej, dll melalui beberapa perkhidmatan.
Terdapat skim yang lebih maju, apabila kita tidak mempunyai Master, semua nod adalah hamba tuan, berbeza dalam tingkah laku mereka. Tetapi mereka masih perlu berinteraksi antara satu sama lain, jadi masih ada beberapa perkhidmatan yang tinggal untuk menyelaraskan tindakan ini. Mungkin, Cassandra, yang bekerja pada prinsip ini, sesuai dengan skema ini.
Sukar untuk mengatakan yang mana antara skim ini berfungsi lebih baik. Masing-masing ada kebaikan dan keburukan tersendiri.
Dan tidak perlu takut dengan beberapa perkara dengan Guru, kerana, seperti yang ditunjukkan oleh amalan, dia tidak begitu terdedah untuk terus berkhidmat. Perkara utama di sini ialah memilih penyelesaian yang tepat untuk mengehos perkhidmatan ini pada nod berkuasa yang berasingan, supaya ia mempunyai sumber yang mencukupi, supaya jika boleh, pengguna tidak mempunyai akses ke sana, supaya mereka tidak membunuh proses ini secara tidak sengaja. Tetapi pada masa yang sama, dalam skim sedemikian adalah lebih mudah untuk menguruskan pekerja dari proses Master, iaitu skim ini lebih mudah dari sudut pelaksanaan.
Dan skim ini (di atas) mungkin lebih kompleks, tetapi lebih dipercayai.
Masalah utama ialah kegagalan separa. Sebagai contoh, apabila kami menghantar mesej melalui Rangkaian, beberapa jenis kemalangan berlaku, dan orang yang menghantar mesej itu tidak akan tahu sama ada mesejnya diterima dan apa yang berlaku di pihak penerima, tidak akan tahu sama ada mesej itu diproses dengan betul , iaitu dia tidak akan menerima sebarang pengesahan.
Sehubungan itu, kita mesti memproses keadaan ini. Dan perkara yang paling mudah ialah menghantar semula mesej ini dan tunggu sehingga kami menerima balasan. Dalam kes ini, ia tidak diambil kira sama ada keadaan penerima telah berubah. Kami mungkin menghantar mesej dan menambah data yang sama dua kali.
ZooKeeper menawarkan cara untuk menangani penolakan sedemikian, yang juga menjadikan hidup kita lebih mudah.
Seperti yang dinyatakan sedikit sebelum ini, ini sama seperti menulis program berbilang benang, tetapi perbezaan utama ialah dalam aplikasi teragih yang kami bina pada mesin yang berbeza, satu-satunya cara untuk berkomunikasi ialah Rangkaian. Pada asasnya, ini adalah seni bina tanpa berkongsi. Setiap proses atau perkhidmatan yang berjalan pada satu mesin mempunyai memorinya sendiri, cakeranya sendiri, pemprosesnya sendiri, yang ia tidak berkongsi dengan sesiapa pun.
Jika kita menulis program berbilang benang pada satu komputer, maka kita boleh menggunakan memori yang dikongsi untuk menukar data. Kami mempunyai suis konteks di sana, proses boleh bertukar. Ini menjejaskan prestasi. Di satu pihak, tidak ada perkara sedemikian dalam program pada kelompok, tetapi terdapat masalah dengan Rangkaian.
Sehubungan itu, masalah utama yang timbul semasa menulis sistem teragih ialah konfigurasi. Kami sedang menulis beberapa jenis permohonan. Jika ia mudah, maka kita mengeraskan semua jenis nombor dalam kod, tetapi ini menyusahkan, kerana jika kita memutuskan bahawa bukannya tamat masa setengah saat kita mahu tamat masa satu saat, maka kita perlu menyusun semula aplikasi dan melancarkan segalanya semula. Ia satu perkara apabila ia berada pada satu mesin, apabila anda hanya boleh memulakannya semula, tetapi apabila kita mempunyai banyak mesin, kita perlu sentiasa menyalin segala-galanya. Kita mesti cuba menjadikan aplikasi itu boleh dikonfigurasikan.
Di sini kita bercakap tentang konfigurasi statik untuk proses sistem. Ini bukan sepenuhnya, mungkin dari sudut pandangan sistem pengendalian, ia mungkin konfigurasi statik untuk proses kami, iaitu konfigurasi yang tidak boleh diambil dan dikemas kini dengan mudah.
Terdapat juga konfigurasi dinamik. Ini adalah parameter yang kami mahu ubah dengan cepat supaya ia diambil di sana.
Apa masalah di sini? Kami mengemas kini konfigurasi, melancarkannya, jadi apa? Masalahnya mungkin bahawa di satu pihak kami melancarkan konfigurasi, tetapi terlupa tentang perkara baru, konfigurasi kekal di sana. Kedua, semasa kami melancarkan, konfigurasi telah dikemas kini di beberapa tempat, tetapi tidak di tempat lain. Dan beberapa proses aplikasi kami yang dijalankan pada satu mesin telah dimulakan semula dengan konfigurasi baharu, dan di suatu tempat dengan yang lama. Ini boleh menyebabkan aplikasi yang diedarkan kami tidak konsisten dari perspektif konfigurasi. Masalah ini adalah perkara biasa. Untuk konfigurasi dinamik, ia lebih relevan kerana ia membayangkan bahawa ia boleh ditukar dengan cepat.
Masalah lain ialah keahlian kumpulan. Kami sentiasa mempunyai beberapa set pekerja, kami sentiasa ingin tahu mana antara mereka yang masih hidup, yang mana antara mereka sudah mati. Jika ada Master, maka dia mesti memahami pekerja mana yang boleh dialihkan kepada pelanggan supaya mereka menjalankan pengiraan atau bekerja dengan data, dan yang tidak boleh. Masalah yang sentiasa timbul ialah kita perlu tahu siapa yang bekerja dalam kluster kita.
Satu lagi masalah biasa ialah pemilihan pemimpin, apabila kita ingin tahu siapa yang bertanggungjawab. Satu contoh ialah replikasi, apabila kita mempunyai beberapa proses yang menerima operasi tulis dan kemudian mereplikasinya antara proses lain. Dia akan menjadi ketua, orang lain akan patuh kepadanya, akan mengikutnya. Adalah perlu untuk memilih proses supaya ia tidak jelas untuk semua orang, supaya tidak menjadi dua pemimpin dipilih.
Terdapat juga akses yang saling eksklusif. Masalah di sini lebih kompleks. Terdapat perkara seperti mutex, apabila anda menulis program berbilang benang dan mahu akses kepada beberapa sumber, contohnya, sel memori, dihadkan dan dijalankan oleh hanya satu utas. Di sini sumber boleh menjadi sesuatu yang lebih abstrak. Dan aplikasi yang berbeza daripada nod berbeza Rangkaian kami seharusnya hanya menerima akses eksklusif kepada sumber yang diberikan, dan bukan supaya semua orang boleh mengubahnya atau menulis sesuatu di sana. Ini adalah apa yang dipanggil kunci.
ZooKeeper membolehkan anda menyelesaikan semua masalah ini ke satu tahap atau yang lain. Dan saya akan menunjukkan dengan contoh bagaimana ia membolehkan anda melakukan ini.
Tiada primitif menyekat. Apabila kita mula menggunakan sesuatu, primitif ini tidak akan menunggu sebarang peristiwa berlaku. Kemungkinan besar, perkara ini akan berfungsi secara tidak segerak, dengan itu membenarkan proses tidak digantung semasa mereka menunggu sesuatu. Ini adalah perkara yang sangat berguna.
Semua permintaan pelanggan diproses mengikut susunan baris gilir umum.
Dan pelanggan berpeluang untuk menerima pemberitahuan tentang perubahan di beberapa negeri, tentang perubahan dalam data, sebelum pelanggan melihat data yang diubah itu sendiri.
ZooKeeper boleh berfungsi dalam dua mod. Yang pertama adalah kendiri, pada satu nod. Ini mudah untuk ujian. Ia juga boleh beroperasi dalam mod kluster pada sebarang bilangan pelayan. Jika kita mempunyai sekumpulan 100 mesin, maka ia tidak perlu untuk berfungsi pada 100 mesin. Ia cukup untuk memilih beberapa mesin di mana anda boleh menjalankan ZooKeeper. Dan ia menyatakan prinsip ketersediaan tinggi. Pada setiap contoh yang sedang berjalan, ZooKeeper menyimpan keseluruhan salinan data. Nanti saya ceritakan cara dia buat. Ia tidak memecah data atau membahagikannya. Di satu pihak, ia adalah tolak bahawa kita tidak boleh menyimpan banyak, sebaliknya, tidak perlu melakukan ini. Bukan untuk itu ia direka, ia bukan pangkalan data.
Data boleh dicache pada bahagian klien. Ini adalah prinsip standard supaya kami tidak mengganggu perkhidmatan dan tidak memuatkannya dengan permintaan yang sama. Pelanggan pintar biasanya tahu tentang perkara ini dan menyimpannya.
Sebagai contoh, sesuatu telah berubah di sini. Terdapat beberapa jenis aplikasi. Seorang pemimpin baru telah dipilih, yang bertanggungjawab, contohnya, untuk memproses operasi tulis. Dan kami mahu meniru data. Satu penyelesaian ialah meletakkannya dalam gelung. Dan kami sentiasa mempersoalkan perkhidmatan kami - adakah ada yang berubah? Pilihan kedua adalah lebih optimum. Ini ialah mekanisme jam tangan yang membolehkan anda memberitahu pelanggan bahawa sesuatu telah berubah. Ini adalah kaedah yang lebih murah dari segi sumber dan lebih mudah untuk pelanggan.
Pelanggan ialah pengguna yang menggunakan ZooKeeper.
Pelayan ialah proses ZooKeeper itu sendiri.
Znode ialah perkara utama dalam ZooKeeper. Semua znod disimpan dalam ingatan oleh ZooKeeper dan disusun dalam bentuk rajah hierarki, dalam bentuk pokok.
Terdapat dua jenis operasi. Yang pertama ialah kemas kini/tulis, apabila beberapa operasi mengubah keadaan pokok kami. Pokok itu biasa.
Dan ada kemungkinan bahawa pelanggan tidak menyelesaikan satu permintaan dan diputuskan sambungan, tetapi boleh mewujudkan sesi di mana ia berinteraksi dengan ZooKeeper.
Model data ZooKeeper menyerupai sistem fail. Terdapat akar standard dan kemudian kami pergi seolah-olah melalui direktori yang pergi dari akar. Dan kemudian katalog tahap pertama, tahap kedua. Ini semua adalah znod.
Setiap znod boleh menyimpan beberapa data, biasanya tidak terlalu besar, contohnya, 10 kilobait. Dan setiap znod boleh mempunyai bilangan anak tertentu.
Znod terdapat dalam beberapa jenis. Mereka boleh dicipta. Dan apabila mencipta znod, kami menentukan jenis yang sepatutnya dimiliki.
Terdapat dua jenis. Yang pertama ialah bendera fana. Znode hidup dalam satu sesi. Sebagai contoh, pelanggan telah menubuhkan sesi. Dan selagi sesi ini masih ada, ia akan wujud. Ini perlu supaya tidak menghasilkan sesuatu yang tidak perlu. Ini juga sesuai untuk saat-saat penting bagi kami untuk menyimpan data primitif dalam sesi.
Jenis kedua ialah bendera berurutan. Ia menambah kaunter dalam perjalanan ke znod. Sebagai contoh, kami mempunyai direktori dengan aplikasi 1_5. Dan apabila kami mencipta nod pertama, ia menerima p_1, yang kedua - p_2. Dan apabila kami memanggil kaedah ini setiap kali, kami melepasi laluan penuh, menunjukkan hanya sebahagian daripada laluan, dan nombor ini secara automatik meningkat kerana kami menunjukkan jenis nod - berjujukan.
Znod biasa. Dia akan sentiasa hidup dan mempunyai nama yang kami beritahu dia.
Satu lagi perkara yang berguna ialah bendera jam tangan. Jika kami memasangnya, maka pelanggan boleh melanggan beberapa acara untuk nod tertentu. Saya akan menunjukkan kepada anda kemudian dengan contoh bagaimana ini dilakukan. ZooKeeper sendiri memberitahu pelanggan bahawa data pada nod telah berubah. Walau bagaimanapun, pemberitahuan tidak menjamin bahawa beberapa data baharu telah tiba. Mereka hanya mengatakan bahawa sesuatu telah berubah, jadi anda masih perlu membandingkan data kemudian dengan panggilan berasingan.
Dan seperti yang telah saya katakan, susunan data ditentukan oleh kilobait. Tidak perlu menyimpan data teks besar di sana, kerana ia bukan pangkalan data, ia adalah pelayan untuk menyelaraskan tindakan.
Saya akan memberitahu anda sedikit tentang sesi. Jika kita mempunyai berbilang pelayan, maka kita boleh bergerak secara telus dari pelayan ke pelayan menggunakan pengecam sesi. Ia agak mudah.
Setiap sesi mempunyai beberapa jenis tamat masa. Sesi ditakrifkan oleh sama ada pelanggan menghantar apa-apa kepada pelayan semasa sesi itu. Jika dia tidak menghantar apa-apa semasa tamat masa, sesi akan terhenti, atau pelanggan boleh menutupnya sendiri.
Ia tidak mempunyai banyak ciri, tetapi anda boleh melakukan perkara yang berbeza dengan API ini. Panggilan yang kita lihat mencipta mencipta znod dan mengambil tiga parameter. Ini ialah laluan ke znod, dan ia mesti dinyatakan sepenuhnya daripada akar. Dan juga ini adalah beberapa data yang kami ingin pindahkan ke sana. Dan jenis bendera. Dan selepas penciptaan ia mengembalikan laluan ke znode.
Kedua, anda boleh memadamkannya. Caranya di sini ialah parameter kedua, sebagai tambahan kepada laluan ke znode, boleh menentukan versi. Sehubungan itu, znod itu akan dipadamkan jika versinya yang kami pindahkan adalah bersamaan dengan yang sebenarnya wujud.
Jika kita tidak mahu menyemak versi ini, maka kita hanya luluskan hujah "-1".
Ketiga, ia menyemak kewujudan znod. Mengembalikan benar jika nod wujud, palsu sebaliknya.
Dan kemudian jam tangan bendera muncul, yang membolehkan anda memantau nod ini.
Anda boleh menetapkan bendera ini walaupun pada nod yang tidak wujud dan menerima pemberitahuan apabila ia muncul. Ini juga boleh berguna.
Beberapa lagi cabaran adalah getData. Adalah jelas bahawa kita boleh menerima data melalui znode. Anda juga boleh menggunakan jam tangan bendera. Dalam kes ini, ia tidak akan dipasang jika tiada nod. Oleh itu, anda perlu memahami bahawa ia wujud, dan kemudian menerima data.
Terdapat juga SetData. Di sini kita lulus versi. Dan jika kami meneruskannya, data pada znod versi tertentu akan dikemas kini.
Anda juga boleh menentukan "-1" untuk mengecualikan semakan ini.
Kaedah lain yang berguna ialah dapatkanKanak-kanak. Kami juga boleh mendapatkan senarai semua znod yang dimiliki olehnya. Kita boleh memantau ini dengan menetapkan jam tangan bendera.
Dan kaedah menyegerakkan membenarkan semua perubahan dihantar sekali gus, dengan itu memastikan ia disimpan dan semua data telah diubah sepenuhnya.
Jika kita membuat analogi dengan pengaturcaraan biasa, maka apabila anda menggunakan kaedah seperti menulis, yang menulis sesuatu ke cakera, dan selepas ia mengembalikan respons kepada anda, tidak ada jaminan bahawa anda telah menulis data ke cakera. Dan walaupun sistem pengendalian yakin bahawa semuanya telah ditulis, terdapat mekanisme dalam cakera itu sendiri di mana proses itu melalui lapisan penampan, dan hanya selepas itu data diletakkan pada cakera.
Kebanyakannya panggilan tak segerak digunakan. Ini membolehkan pelanggan bekerja selari dengan permintaan yang berbeza. Anda boleh menggunakan pendekatan segerak, tetapi ia kurang produktif.
Dua operasi yang kami bincangkan ialah kemas kini/tulis, yang menukar data. Ini adalah create, setData, sync, delete. Dan baca adalah wujud, getData, getChildren.
Sekarang beberapa contoh bagaimana anda boleh membuat primitif untuk bekerja dalam sistem teragih. Contohnya, berkaitan dengan konfigurasi sesuatu. Seorang pekerja baru telah muncul. Kami menambah mesin dan memulakan proses. Dan terdapat tiga soalan berikut. Bagaimanakah ia menanyakan ZooKeeper untuk konfigurasi? Dan jika kita ingin menukar konfigurasi, bagaimana kita mengubahnya? Dan selepas kami menukarnya, bagaimana pekerja yang kami ada mendapatnya?
ZooKeeper menjadikan ini agak mudah. Sebagai contoh, terdapat pokok znod kami. Terdapat nod untuk aplikasi kami di sini, kami membuat nod tambahan di dalamnya, yang mengandungi data daripada konfigurasi. Ini mungkin atau mungkin bukan parameter yang berasingan. Oleh kerana saiznya kecil, saiz konfigurasi biasanya kecil juga, jadi agak mungkin untuk menyimpannya di sini.
Anda menggunakan kaedah tersebut getData untuk mendapatkan konfigurasi untuk pekerja daripada nod. Tetapkan kepada benar. Jika atas sebab tertentu nod ini tidak wujud, kami akan dimaklumkan mengenainya apabila ia muncul, atau apabila ia berubah. Jika kita ingin tahu bahawa sesuatu telah berubah, maka kita menetapkannya kepada benar. Dan jika data dalam nod ini berubah, kami akan mengetahuinya.
SetData. Kami menetapkan data, tetapkan "-1", iaitu kami tidak menyemak versi, kami menganggap bahawa kami sentiasa mempunyai satu konfigurasi, kami tidak perlu menyimpan banyak konfigurasi. Jika anda perlu menyimpan banyak, anda perlu menambah satu lagi tahap. Di sini kami percaya bahawa hanya ada satu, jadi kami mengemas kini hanya yang terkini, jadi kami tidak menyemak versi. Pada masa ini, semua pelanggan yang telah melanggan sebelum ini menerima pemberitahuan bahawa sesuatu telah berubah dalam nod ini. Dan selepas mereka menerimanya, mereka juga mesti meminta data itu semula. Pemberitahuan adalah bahawa mereka tidak menerima data itu sendiri, tetapi hanya pemberitahuan perubahan. Selepas ini mereka mesti meminta data baru.
Pilihan kedua untuk menggunakan primitif ialah keahlian kumpulan. Kami mempunyai aplikasi yang diedarkan, terdapat sekumpulan pekerja dan kami ingin memahami bahawa mereka semua sudah sedia. Oleh itu, mereka mesti mendaftarkan diri mereka bahawa mereka bekerja dalam permohonan kami. Dan kami juga ingin mengetahui, sama ada dari proses Master atau di tempat lain, tentang semua pekerja aktif yang kami ada sekarang.
Bagaimana kita melakukan ini? Untuk aplikasi, kami mencipta nod pekerja dan menambah subperingkat di sana menggunakan kaedah cipta. Saya mempunyai ralat pada slaid. Di sini anda perlukan berjujukan tentukan, maka semua pekerja akan dibuat satu persatu. Dan aplikasi, meminta semua data tentang anak-anak nod ini, menerima semua pekerja aktif yang wujud.
Ini adalah pelaksanaan yang mengerikan tentang bagaimana ini boleh dilakukan dalam kod Java. Mari kita mulakan dari akhir, dengan kaedah utama. Ini kelas kami, mari buat kaedahnya. Sebagai hujah pertama kami menggunakan hos, tempat kami menyambung, iaitu kami menetapkannya sebagai hujah. Dan hujah kedua ialah nama kumpulan.
Bagaimanakah sambungan berlaku? Ini adalah contoh mudah API yang digunakan. Segala-galanya agak mudah di sini. Terdapat ZooKeeper kelas standard. Kami menyampaikan tuan rumah kepadanya. Dan tetapkan tamat masa, sebagai contoh, kepada 5 saat. Dan kami mempunyai ahli yang dipanggil connectedSignal. Pada asasnya, kami membuat kumpulan di sepanjang laluan yang dihantar. Kami tidak menulis data di sana, walaupun sesuatu boleh ditulis. Dan nod di sini adalah daripada jenis berterusan. Pada asasnya, ini adalah nod biasa biasa yang akan wujud sepanjang masa. Di sinilah sesi dibuat. Ini adalah pelaksanaan klien itu sendiri. Pelanggan kami akan menghantar mesej berkala yang menunjukkan bahawa sesi itu masih hidup. Dan apabila kami menamatkan sesi, kami membuat panggilan dekat dan itu sahaja, sesi itu gagal. Ini sekiranya ada sesuatu yang menimpa kita, supaya ZooKeeper mengetahuinya dan memutuskan sesi.
Bagaimana untuk mengunci sumber? Di sini semuanya lebih rumit. Kami mempunyai satu set pekerja, ada beberapa sumber yang ingin kami kunci. Untuk melakukan ini, kami mencipta nod berasingan, sebagai contoh, dipanggil lock1. Jika kami dapat menciptanya, maka kami mendapat kunci di sini. Dan jika kami tidak dapat menciptanya, maka pekerja cuba mendapatkan getData dari sini, dan memandangkan nod telah dibuat, maka kami meletakkan pemerhati di sini dan apabila keadaan nod ini berubah, kami akan mengetahui tentangnya. Dan kita boleh cuba mempunyai masa untuk menciptanya semula. Jika kami mengambil nod ini, mengambil kunci ini, maka selepas kami tidak lagi memerlukan kunci itu, kami akan meninggalkannya, kerana nod itu hanya wujud dalam sesi. Sehubungan itu, ia akan hilang. Dan pelanggan lain, dalam rangka sesi lain, akan dapat mengambil kunci pada nod ini, atau sebaliknya, dia akan menerima pemberitahuan bahawa sesuatu telah berubah dan dia boleh cuba melakukannya dalam masa.
Satu lagi contoh bagaimana anda boleh memilih pemimpin utama. Ini sedikit lebih rumit, tetapi juga agak mudah. Apa yang berlaku di sini? Terdapat nod utama yang mengagregatkan semua pekerja. Kami cuba mendapatkan data tentang ketua. Jika ini berlaku dengan jayanya, iaitu kami menerima beberapa data, maka pekerja kami mula mengikuti pemimpin ini. Dia percaya sudah ada pemimpin.
Jika pemimpin itu mati atas sebab tertentu, misalnya, jatuh, maka kita cuba mencipta pemimpin baru. Dan jika kita berjaya, maka pekerja kita menjadi ketua. Dan jika seseorang pada masa ini berjaya mencipta pemimpin baru, maka kita cuba memahami siapa dia dan kemudian mengikutinya.
Di sini timbul apa yang dipanggil herd effect, iaitu herd effect, kerana apabila seseorang pemimpin itu mati, orang yang pertama dalam masa akan menjadi ketua.
Apabila menangkap sumber, anda boleh cuba menggunakan pendekatan yang sedikit berbeza, iaitu seperti berikut. Sebagai contoh, kami ingin mendapatkan kunci, tetapi tanpa kesan hert. Ia terdiri daripada fakta bahawa aplikasi kami meminta senarai semua id nod untuk nod yang sedia ada dengan kunci. Dan jika sebelum itu nod yang kami buat kunci adalah minimum set yang kami terima, maka ini bermakna kami telah menangkap kunci itu. Kami menyemak bahawa kami telah menerima kunci. Sebagai semakan, akan ada syarat bahawa id yang kami terima semasa membuat kunci baharu adalah minimum. Dan jika kami menerimanya, maka kami bekerja lebih jauh.
Jika terdapat id tertentu yang lebih kecil daripada kunci kami, maka kami meletakkan pemerhati pada acara ini dan menunggu pemberitahuan sehingga sesuatu berubah. Iaitu, kami menerima kunci ini. Dan sehingga ia jatuh, kami tidak akan menjadi id minimum dan tidak akan menerima kunci minimum, dan dengan itu kami akan dapat log masuk. Dan jika syarat ini tidak dipenuhi, maka kami segera pergi ke sini dan cuba mendapatkan kunci ini semula, kerana sesuatu mungkin telah berubah pada masa ini.
Apakah yang terdiri daripada ZooKeeper? Terdapat 4 perkara utama. Ini ialah proses pemprosesan - Permintaan. Dan juga Siaran Atom ZooKeeper. Terdapat Log Komit di mana semua operasi direkodkan. Dan In-memory Replicated DB itu sendiri, iaitu pangkalan data itu sendiri di mana keseluruhan pokok ini disimpan.
Perlu diingat bahawa semua operasi tulis melalui Pemproses Permintaan. Dan operasi baca pergi terus ke pangkalan data Dalam memori.
Pangkalan data itu sendiri direplikasi sepenuhnya. Semua kejadian ZooKeeper menyimpan salinan lengkap data.
Untuk memulihkan pangkalan data selepas ranap sistem, terdapat log Komit. Amalan standard ialah sebelum data masuk ke dalam ingatan, ia ditulis di sana supaya jika ia ranap, log ini boleh dimainkan semula dan keadaan sistem boleh dipulihkan. Dan petikan berkala pangkalan data juga digunakan.
Siaran Atom ZooKeeper ialah perkara yang digunakan untuk mengekalkan data yang direplikasi.
ZAB secara dalaman memilih pemimpin dari sudut pandangan nod ZooKeeper. Nod lain menjadi pengikutnya dan mengharapkan beberapa tindakan daripadanya. Jika mereka menerima penyertaan, mereka memajukan semuanya kepada ketua. Mula-mula dia melakukan operasi tulis dan kemudian menghantar mesej tentang perkara yang telah berubah kepada pengikutnya. Ini, sebenarnya, mesti dilakukan secara atom, iaitu operasi rakaman dan penyiaran keseluruhannya mesti dilakukan secara atom, dengan itu menjamin ketekalan data.
Ia hanya memproses permintaan tulis. Tugas utamanya ialah ia mengubah operasi menjadi kemas kini transaksi. Ini adalah permintaan yang dijana khas.
Dan di sini perlu diperhatikan bahawa idempotency kemas kini untuk operasi yang sama dijamin. Apa ini? Perkara ini, jika dilaksanakan dua kali, akan mempunyai keadaan yang sama, iaitu permintaan itu sendiri tidak akan berubah. Dan ini perlu dilakukan supaya sekiranya berlaku kemalangan, anda boleh memulakan semula operasi, dengan itu melancarkan semula perubahan yang telah hilang pada masa ini. Dalam kes ini, keadaan sistem akan menjadi sama, iaitu tidak sepatutnya berlaku satu siri yang sama, sebagai contoh, proses kemas kini, membawa kepada keadaan akhir sistem yang berbeza.
Sumber: www.habr.com