Saya sarankan Anda membaca transkrip kuliah "Hadoop. ZooKeeper" dari seri "Metode untuk pemrosesan terdistribusi data dalam jumlah besar di Hadoop"
Apa itu ZooKeeper, tempatnya di ekosistem Hadoop. Ketidakbenaran tentang komputasi terdistribusi. Diagram sistem terdistribusi standar. Kesulitan dalam mengoordinasikan sistem terdistribusi. Masalah koordinasi yang khas. Prinsip di balik desain ZooKeeper. Model data Penjaga Kebun Binatang. bendera znode. Sesi. API Klien. Primitif (konfigurasi, keanggotaan grup, penguncian sederhana, pemilihan pemimpin, penguncian tanpa efek kawanan). Arsitektur Penjaga Kebun Binatang. Penjaga Kebun Binatang DB. ZAB. Penangan permintaan.
Hari ini kita akan berbicara tentang ZooKeeper. Hal ini sangat berguna. Seperti produk Apache Hadoop lainnya, ia memiliki logo. Ini menggambarkan seorang pria.
Sebelumnya, kita terutama berbicara tentang bagaimana data dapat diproses di sana, bagaimana cara menyimpannya, yaitu bagaimana menggunakannya dan bekerja dengannya. Dan hari ini saya ingin berbicara sedikit tentang membangun aplikasi terdistribusi. Dan ZooKeeper adalah salah satu hal yang memungkinkan Anda menyederhanakan masalah ini. Ini adalah jenis layanan yang dimaksudkan untuk semacam koordinasi interaksi proses dalam sistem terdistribusi, dalam aplikasi terdistribusi.
Kebutuhan akan aplikasi seperti itu semakin hari semakin meningkat, itulah inti kursus kami. Di satu sisi, MapReduce dan kerangka kerja siap pakai ini memungkinkan Anda untuk menghilangkan kompleksitas ini dan membebaskan pemrogram dari penulisan primitif seperti interaksi dan koordinasi proses. Namun di sisi lain, tidak ada yang menjamin hal tersebut tidak perlu dilakukan. MapReduce atau kerangka kerja siap pakai lainnya tidak selalu sepenuhnya menggantikan beberapa kasus yang tidak dapat diimplementasikan menggunakan ini. Termasuk MapReduce sendiri dan sejumlah proyek Apache lainnya; mereka sebenarnya juga merupakan aplikasi terdistribusi. Dan untuk mempermudah menulis, mereka menulis ZooKeeper.
Seperti semua aplikasi terkait Hadoop, aplikasi ini dikembangkan oleh Yahoo! Sekarang juga merupakan aplikasi resmi Apache. Ini tidak dikembangkan secara aktif seperti HBase. Jika Anda pergi ke JIRA HBase, maka setiap hari ada banyak laporan bug, banyak proposal untuk mengoptimalkan sesuatu, mis. kehidupan dalam proyek terus berjalan. Dan ZooKeeper, di satu sisi, adalah produk yang relatif sederhana, dan di sisi lain, menjamin keandalannya. Dan cukup mudah digunakan, itulah sebabnya ini menjadi standar aplikasi dalam ekosistem Hadoop. Jadi saya pikir akan berguna untuk meninjaunya untuk memahami cara kerjanya dan cara menggunakannya.
Ini adalah gambar dari beberapa ceramah yang kami adakan. Kita dapat mengatakan bahwa ini ortogonal terhadap segala sesuatu yang telah kita pertimbangkan sejauh ini. Dan semua yang ditunjukkan di sini, pada tingkat tertentu, berfungsi dengan ZooKeeper, yaitu layanan yang menggunakan semua produk ini. Baik HDFS maupun MapReduce tidak menulis layanan serupa yang secara khusus cocok untuk mereka. Oleh karena itu, ZooKeeper digunakan. Dan ini menyederhanakan pengembangan dan beberapa hal yang berhubungan dengan kesalahan.
Dari mana semua ini berasal? Tampaknya kami meluncurkan dua aplikasi secara paralel di komputer yang berbeda, menghubungkannya dengan string atau mesh, dan semuanya berfungsi. Namun masalahnya adalah Jaringan tidak dapat diandalkan, dan jika Anda mengendus lalu lintas atau melihat apa yang terjadi di sana pada tingkat rendah, bagaimana klien berinteraksi di Jaringan, Anda sering dapat melihat bahwa beberapa paket hilang atau dikirim ulang. Bukan tanpa alasan protokol TCP diciptakan, yang memungkinkan Anda membuat sesi tertentu dan menjamin pengiriman pesan. Namun bagaimanapun juga, TCP pun tidak selalu bisa menyelamatkan Anda. Semuanya ada batas waktunya. Jaringan mungkin terputus untuk sementara waktu. Ini mungkin hanya berkedip. Dan ini semua mengarah pada fakta bahwa Anda tidak dapat mengandalkan Jaringan yang dapat diandalkan. Inilah perbedaan utama dari penulisan aplikasi paralel yang berjalan di satu komputer atau di satu superkomputer, di mana tidak ada Jaringan, di mana terdapat bus pertukaran data yang lebih andal di memori. Dan ini adalah perbedaan mendasar.
Antara lain, saat menggunakan Jaringan, selalu ada latensi tertentu. Disk juga memilikinya, tetapi Jaringan memiliki lebih banyak. Latensi adalah waktu tunda, yang bisa kecil atau cukup signifikan.
Topologi jaringan berubah. Apa itu topologi - ini adalah penempatan peralatan jaringan kami. Ada data center, ada rak yang berdiri disana, ada lilin. Semua ini bisa disambungkan kembali, dipindahkan, dll. Ini semua juga perlu diperhitungkan. Nama IP berubah, rute perjalanan lalu lintas kita berubah. Hal ini juga perlu diperhitungkan.
Jaringan juga dapat berubah dalam hal peralatan. Dari praktik, saya dapat mengatakan bahwa teknisi jaringan kami sangat suka memperbarui sesuatu secara berkala. Tiba-tiba firmware baru keluar dan mereka tidak terlalu tertarik pada beberapa cluster Hadoop. Mereka punya pekerjaan sendiri. Bagi mereka, yang utama adalah Jaringannya berfungsi. Oleh karena itu, mereka ingin mengunggah ulang sesuatu di sana, melakukan flashing pada perangkat kerasnya, dan perangkat keras tersebut juga berubah secara berkala. Semua ini perlu diperhitungkan. Semua ini mempengaruhi aplikasi terdistribusi kami.
Biasanya orang yang mulai bekerja dengan data dalam jumlah besar karena alasan tertentu percaya bahwa Internet tidak terbatas. Jika terdapat file berukuran beberapa terabyte di sana, maka Anda dapat membawanya ke server atau komputer Anda dan membukanya menggunakan kucing dan lihatlah. Kesalahan lain terjadi semangat lihat lognya. Jangan pernah melakukan ini karena itu buruk. Karena Vim mencoba untuk menyangga semuanya, memuat semuanya ke dalam memori, terutama ketika kita mulai menelusuri log ini dan mencari sesuatu. Ini adalah hal-hal yang dilupakan, namun patut dipertimbangkan.
Lebih mudah untuk menulis satu program yang berjalan pada satu komputer dengan satu prosesor.
Ketika sistem kami berkembang, kami ingin memparalelkan semuanya, dan memparalelkannya tidak hanya di komputer, tetapi juga di cluster. Timbul pertanyaan: bagaimana mengkoordinasikan hal ini? Aplikasi kami bahkan mungkin tidak berinteraksi satu sama lain, tetapi kami menjalankan beberapa proses secara paralel di beberapa server. Dan bagaimana cara memantau bahwa semuanya berjalan baik bagi mereka? Misalnya, mereka mengirim sesuatu melalui Internet. Mereka harus menulis tentang statusnya di suatu tempat, misalnya, di beberapa jenis database atau log, kemudian menggabungkan log ini dan kemudian menganalisisnya di suatu tempat. Ditambah lagi, kita perlu memperhitungkan bahwa prosesnya berjalan dan berjalan, tiba-tiba muncul kesalahan atau crash, lalu seberapa cepat kita akan mengetahuinya?
Jelas bahwa semua ini dapat dipantau dengan cepat. Ini juga bagus, tetapi pemantauan adalah hal terbatas yang memungkinkan Anda memantau beberapa hal pada tingkat tertinggi.
Ketika kita ingin proses kita mulai berinteraksi satu sama lain, misalnya saling mengirim beberapa data, maka muncul pertanyaan - bagaimana ini akan terjadi? Akankah ada semacam kondisi balapan, apakah akan saling menimpa, apakah data akan sampai dengan benar, apakah ada yang hilang di tengah jalan? Kita perlu mengembangkan semacam protokol, dll.
Koordinasi seluruh proses tersebut bukanlah hal yang sepele. Dan ini memaksa pengembang untuk turun ke tingkat yang lebih rendah lagi, dan menulis sistem dari awal, atau tidak sepenuhnya dari awal, tetapi ini tidak sesederhana itu.
Jika Anda menemukan algoritma kriptografi atau bahkan menerapkannya, segera buang, karena kemungkinan besar itu tidak akan berhasil untuk Anda. Kemungkinan besar berisi banyak kesalahan yang Anda lupa berikan. Jangan pernah menggunakannya untuk hal yang serius karena kemungkinan besar tidak stabil. Karena semua algoritma yang ada telah teruji oleh waktu dalam waktu yang sangat lama. Hal ini disadap oleh masyarakat. Ini adalah topik yang terpisah. Dan itu sama di sini. Jika memungkinkan untuk tidak menerapkan sendiri semacam sinkronisasi proses, maka lebih baik tidak melakukan ini, karena ini cukup rumit dan membawa Anda ke jalan yang goyah karena terus-menerus mencari kesalahan.
Hari ini kita berbicara tentang Penjaga Kebun Binatang. Di satu sisi, ini adalah kerangka kerja, di sisi lain, ini adalah layanan yang membuat hidup lebih mudah bagi pengembang dan menyederhanakan implementasi logika dan koordinasi proses kami sebanyak mungkin.
Mari kita ingat seperti apa sistem terdistribusi standar. Inilah yang kita bicarakan - HDFS, HBase. Ada proses Master yang mengelola proses pekerja dan budak. Dia bertanggung jawab untuk mengoordinasikan dan mendistribusikan tugas, memulai kembali pekerja, meluncurkan pekerja baru, dan mendistribusikan beban.
Hal yang lebih maju adalah Layanan Koordinasi, yaitu memindahkan tugas koordinasi itu sendiri ke dalam proses terpisah, ditambah menjalankan semacam Master cadangan atau stanby secara paralel, karena Master bisa saja gagal. Dan jika Masternya jatuh, maka sistem kami tidak akan berfungsi. Kami sedang menjalankan cadangan. Beberapa menyatakan bahwa Master perlu direplikasi untuk dijadikan cadangan. Hal ini juga dapat dipercayakan kepada Dinas Koordinasi. Namun dalam diagram ini, Master sendiri yang bertanggung jawab untuk mengkoordinasikan para pekerjanya, disini layanannya mengkoordinasikan kegiatan replikasi data.
Opsi yang lebih maju adalah ketika semua koordinasi ditangani oleh layanan kami, seperti yang biasa dilakukan. Dia mengambil tanggung jawab untuk memastikan semuanya berjalan baik. Dan jika sesuatu tidak berhasil, kami mencari tahu dan mencoba menyiasati situasi ini. Bagaimanapun, kita memiliki seorang Master yang entah bagaimana berinteraksi dengan budak dan dapat mengirim data, informasi, pesan, dll melalui beberapa layanan.
Ada skema yang lebih maju lagi, ketika kita tidak memiliki Master, semua node adalah budak master, berbeda dalam perilakunya. Namun mereka masih perlu berinteraksi satu sama lain, sehingga masih ada layanan yang tersisa untuk mengoordinasikan tindakan tersebut. Mungkin Cassandra, yang bekerja berdasarkan prinsip ini, cocok dengan skema ini.
Sulit untuk mengatakan skema mana yang bekerja lebih baik. Masing-masing memiliki kelebihan dan kekurangannya masing-masing.
Dan tidak perlu takut pada beberapa hal dengan Sang Guru, karena, seperti yang ditunjukkan oleh latihan, dia tidak begitu rentan untuk terus-menerus melayani. Hal utama di sini adalah memilih solusi yang tepat untuk menghosting layanan ini pada node kuat yang terpisah, sehingga memiliki sumber daya yang cukup, sehingga jika memungkinkan, pengguna tidak memiliki akses ke sana, sehingga mereka tidak menghentikan proses ini secara tidak sengaja. Namun pada saat yang sama, dalam skema seperti itu jauh lebih mudah untuk mengelola pekerja dari proses Master, yaitu skema ini lebih sederhana dari sudut pandang implementasi.
Dan skema ini (di atas) mungkin lebih kompleks, tetapi lebih dapat diandalkan.
Masalah utamanya adalah kegagalan sebagian. Misalnya, ketika kita mengirim pesan melalui Jaringan, terjadi semacam kecelakaan, dan orang yang mengirim pesan tidak akan mengetahui apakah pesannya telah diterima dan apa yang terjadi di pihak penerima, tidak akan mengetahui apakah pesan tersebut diproses dengan benar. , yaitu dia tidak akan menerima konfirmasi apa pun.
Oleh karena itu, kita harus memproses situasi ini. Dan yang paling sederhana adalah mengirim ulang pesan ini dan menunggu sampai kami menerima tanggapan. Dalam hal ini, tidak diperhitungkan apakah status penerima telah berubah. Kami mungkin mengirim pesan dan menambahkan data yang sama dua kali.
ZooKeeper menawarkan cara untuk mengatasi penolakan tersebut, yang juga membuat hidup kita lebih mudah.
Seperti disebutkan sebelumnya, ini mirip dengan menulis program multi-thread, namun perbedaan utamanya adalah dalam aplikasi terdistribusi yang kita bangun di mesin berbeda, satu-satunya cara untuk berkomunikasi adalah Jaringan. Pada dasarnya, ini adalah arsitektur yang tidak berbagi apa pun. Setiap proses atau layanan yang berjalan pada satu mesin memiliki memorinya sendiri, disknya sendiri, prosesornya sendiri, yang tidak dibagikan kepada siapa pun.
Jika kita menulis program multi-thread pada satu komputer, maka kita dapat menggunakan memori bersama untuk bertukar data. Kami memiliki peralihan konteks di sana, proses dapat beralih. Hal ini mempengaruhi kinerja. Di satu sisi, tidak ada hal seperti itu dalam program di cluster, tetapi ada masalah dengan Jaringan.
Oleh karena itu, masalah utama yang muncul ketika menulis sistem terdistribusi adalah konfigurasi. Kami sedang menulis semacam aplikasi. Jika sederhana, maka kita melakukan hardcode semua jenis angka dalam kode tersebut, tetapi ini merepotkan, karena jika kita memutuskan bahwa alih-alih batas waktu setengah detik kita menginginkan batas waktu satu detik, maka kita perlu mengkompilasi ulang aplikasi dan gulung semuanya lagi. Itu adalah satu hal ketika itu berada di satu mesin, ketika Anda dapat memulai ulang, tetapi ketika kita memiliki banyak mesin, kita harus terus-menerus menyalin semuanya. Kita harus mencoba membuat aplikasi dapat dikonfigurasi.
Di sini kita berbicara tentang konfigurasi statis untuk proses sistem. Ini tidak sepenuhnya, mungkin dari sudut pandang sistem operasi, ini mungkin merupakan konfigurasi statis untuk proses kami, yaitu konfigurasi yang tidak dapat diambil dan diperbarui begitu saja.
Ada juga konfigurasi dinamis. Ini adalah parameter yang ingin kami ubah dengan cepat agar dapat diambil di sana.
Apa masalahnya disini? Kami memperbarui konfigurasi, meluncurkannya, lalu bagaimana? Masalahnya mungkin di satu sisi kami meluncurkan konfigurasi, tetapi lupa tentang yang baru, konfigurasinya tetap ada. Kedua, saat kami meluncurkannya, konfigurasi diperbarui di beberapa tempat, namun tidak di tempat lain. Dan beberapa proses aplikasi kita yang berjalan di satu mesin di-restart dengan konfigurasi baru, dan di suatu tempat dengan konfigurasi lama. Hal ini dapat mengakibatkan aplikasi terdistribusi kami menjadi tidak konsisten dari sudut pandang konfigurasi. Masalah ini biasa terjadi. Untuk konfigurasi dinamis, ini lebih relevan karena menyiratkan bahwa konfigurasi tersebut dapat diubah dengan cepat.
Masalah lainnya adalah keanggotaan kelompok. Kami selalu memiliki sekumpulan pekerja, kami selalu ingin tahu siapa di antara mereka yang masih hidup, siapa di antara mereka yang sudah mati. Jika ada seorang Master, maka dia harus memahami pekerja mana yang bisa dialihkan ke klien agar bisa menjalankan perhitungan atau bekerja dengan data, dan mana yang tidak. Masalah yang terus-menerus muncul adalah kita perlu mengetahui siapa yang bekerja di cluster kita.
Masalah umum lainnya adalah pemilihan pemimpin, ketika kita ingin mengetahui siapa yang memimpin. Salah satu contohnya adalah replikasi, ketika kita memiliki beberapa proses yang menerima operasi tulis dan kemudian mereplikasinya di antara proses lainnya. Dia akan menjadi pemimpin, semua orang akan mematuhinya, akan mengikutinya. Prosesnya harus dipilih sedemikian rupa sehingga tidak ambigu bagi semua orang, sehingga tidak terjadi dua pemimpin yang dipilih.
Ada juga akses yang saling eksklusif. Permasalahan di sini lebih kompleks. Ada yang namanya mutex, ketika Anda menulis program multi-thread dan ingin akses ke beberapa sumber daya, misalnya sel memori, dibatasi dan dilakukan hanya oleh satu thread. Di sini sumber dayanya bisa berupa sesuatu yang lebih abstrak. Dan aplikasi yang berbeda dari node berbeda di Jaringan kami seharusnya hanya menerima akses eksklusif ke sumber daya tertentu, dan bukan agar semua orang dapat mengubahnya atau menulis sesuatu di sana. Inilah yang disebut kunci.
ZooKeeper memungkinkan Anda menyelesaikan semua masalah ini sampai tingkat tertentu. Dan saya akan menunjukkan dengan contoh bagaimana hal ini memungkinkan Anda melakukan ini.
Tidak ada primitif pemblokiran. Saat kita mulai menggunakan sesuatu, primitif ini tidak akan menunggu terjadinya peristiwa apa pun. Kemungkinan besar, hal ini akan bekerja secara asinkron, sehingga memungkinkan proses tidak terhenti saat menunggu sesuatu. Ini adalah hal yang sangat berguna.
Semua permintaan klien diproses dalam urutan antrian umum.
Dan klien memiliki kesempatan untuk menerima pemberitahuan tentang perubahan di beberapa negara, tentang perubahan data, sebelum klien melihat sendiri data yang diubah.
ZooKeeper dapat bekerja dalam dua mode. Yang pertama berdiri sendiri, pada satu node. Ini nyaman untuk pengujian. Itu juga dapat beroperasi dalam mode cluster di sejumlah server. Jika kita mempunyai cluster yang terdiri dari 100 mesin, maka cluster tersebut tidak perlu bekerja pada 100 mesin. Cukup memilih beberapa mesin tempat Anda dapat menjalankan ZooKeeper. Dan ini menganut prinsip ketersediaan tinggi. Pada setiap instance yang berjalan, ZooKeeper menyimpan seluruh salinan data. Nanti saya akan memberitahu Anda bagaimana dia melakukannya. Itu tidak memecah data atau mempartisinya. Di satu sisi minusnya kita tidak bisa menyimpan banyak, di sisi lain tidak perlu melakukan ini. Bukan itu tujuannya, ini bukan database.
Data dapat di-cache di sisi klien. Ini adalah prinsip standar agar kami tidak mengganggu layanan dan memuatnya dengan permintaan yang sama. Klien yang cerdas biasanya mengetahui hal ini dan menyimpannya dalam cache.
Misalnya, ada sesuatu yang berubah di sini. Ada semacam aplikasi. Seorang pemimpin baru telah dipilih, yang bertanggung jawab, misalnya, untuk memproses operasi penulisan. Dan kami ingin mereplikasi datanya. Salah satu solusinya adalah dengan memasukkannya ke dalam satu lingkaran. Dan kami terus-menerus mempertanyakan layanan kami - apakah ada yang berubah? Opsi kedua lebih optimal. Ini adalah mekanisme arloji yang memungkinkan Anda memberi tahu klien bahwa ada sesuatu yang berubah. Ini adalah metode yang lebih murah dalam hal sumber daya dan lebih nyaman bagi klien.
Klien adalah pengguna yang menggunakan ZooKeeper.
Server adalah proses ZooKeeper itu sendiri.
Znode adalah kunci dalam ZooKeeper. Semua znode disimpan dalam memori oleh ZooKeeper dan disusun dalam bentuk diagram hierarki, dalam bentuk pohon.
Ada dua jenis operasi. Yang pertama adalah perbarui/tulis, ketika beberapa operasi mengubah status pohon kita. Pohon itu biasa saja.
Dan ada kemungkinan bahwa klien tidak menyelesaikan satu permintaan dan terputus, tetapi dapat membuat sesi yang melaluinya ia berinteraksi dengan ZooKeeper.
Model data ZooKeeper menyerupai sistem file. Ada root standar dan kemudian kami menelusuri seolah-olah melalui direktori yang berasal dari root. Dan kemudian katalog tingkat pertama, tingkat kedua. Ini semua znode.
Setiap znode dapat menyimpan beberapa data, biasanya tidak terlalu besar, misalnya 10 kilobyte. Dan setiap znode dapat memiliki sejumlah anak tertentu.
Znode hadir dalam beberapa jenis. Mereka bisa diciptakan. Dan saat membuat znode, kami menentukan tipe yang seharusnya.
Ada dua jenis. Yang pertama adalah bendera fana. Znode hidup dalam satu sesi. Misalnya, klien telah membuat sesi. Dan selama sesi ini masih hidup, sesi ini akan tetap ada. Hal ini diperlukan agar tidak menghasilkan sesuatu yang tidak diperlukan. Ini juga cocok untuk saat-saat ketika penting bagi kita untuk menyimpan data primitif dalam suatu sesi.
Tipe kedua adalah bendera sekuensial. Ini menambah penghitung dalam perjalanan ke znode. Misalnya, kami memiliki direktori dengan aplikasi 1_5. Dan saat kita membuat node pertama, ia menerima p_1, node kedua - p_2. Dan ketika kita memanggil metode ini setiap kali kita melewati jalur lengkap, menunjukkan hanya sebagian dari jalur, dan nomor ini secara otomatis bertambah karena kita menunjukkan jenis simpul - berurutan.
Znode biasa. Dia akan selalu hidup dan memiliki nama yang kita beri tahu padanya.
Hal berguna lainnya adalah bendera arloji. Jika kita menginstalnya, maka klien dapat berlangganan beberapa event untuk node tertentu. Saya akan menunjukkan kepada Anda nanti dengan sebuah contoh bagaimana hal ini dilakukan. ZooKeeper sendiri memberi tahu klien bahwa data pada node telah berubah. Namun notifikasi tidak menjamin ada data baru yang masuk. Mereka hanya mengatakan ada sesuatu yang berubah, jadi Anda masih harus membandingkan data nanti dengan panggilan terpisah.
Dan seperti yang sudah saya katakan, urutan data ditentukan oleh kilobyte. Tidak perlu menyimpan data teks berukuran besar di sana, karena ini bukan database, melainkan server koordinasi tindakan.
Saya akan bercerita sedikit tentang sesi-sesi tersebut. Jika kami memiliki beberapa server, maka kami dapat berpindah dari satu server ke server lainnya secara transparan menggunakan pengidentifikasi sesi. Ini cukup nyaman.
Setiap sesi memiliki semacam batas waktu. Sesi ditentukan oleh apakah klien mengirimkan sesuatu ke server selama sesi itu. Jika dia tidak mengirimkan apa pun selama waktu tunggu, sesi akan terhenti, atau klien dapat menutupnya sendiri.
Fiturnya tidak banyak, tetapi Anda dapat melakukan berbagai hal dengan API ini. Panggilan yang kita lihat buat menciptakan znode dan mengambil tiga parameter. Ini adalah jalur menuju znode, dan harus ditentukan secara lengkap dari root. Dan ini juga beberapa data yang ingin kami transfer disana. Dan jenis benderanya. Dan setelah pembuatan, ia mengembalikan jalur ke znode.
Kedua, Anda bisa menghapusnya. Kuncinya di sini adalah parameter kedua, selain jalur ke znode, dapat menentukan versinya. Oleh karena itu, znode tersebut akan dihapus jika versi yang kami transfer setara dengan versi yang sebenarnya ada.
Jika kita tidak ingin memeriksa versi ini, kita cukup meneruskan argumen "-1".
Ketiga, ia memeriksa keberadaan znode. Mengembalikan nilai benar jika simpul ada, salah jika sebaliknya.
Dan kemudian arloji bendera muncul, yang memungkinkan Anda memantau node ini.
Anda dapat menyetel tanda ini bahkan pada node yang tidak ada dan menerima pemberitahuan ketika tanda itu muncul. Ini juga bisa bermanfaat.
Ada beberapa tantangan lagi dapatkanData. Jelas kita bisa menerima data melalui znode. Anda juga dapat menggunakan jam tangan bendera. Dalam hal ini, tidak akan diinstal jika tidak ada node. Oleh karena itu, Anda perlu memahami keberadaannya, dan kemudian menerima datanya.
Ada juga SetData. Di sini kami meneruskan versi. Dan jika kita meneruskannya, data di znode versi tertentu akan diperbarui.
Anda juga dapat menentukan "-1" untuk mengecualikan pemeriksaan ini.
Metode lain yang bermanfaat adalah dapatkanAnak-anak. Kita juga bisa mendapatkan daftar semua znode yang menjadi miliknya. Kita dapat memantaunya dengan mengatur flag watch.
Dan metode sinkronisasi memungkinkan semua perubahan dikirim sekaligus, sehingga memastikan bahwa perubahan tersebut disimpan dan semua data telah diubah sepenuhnya.
Jika kita analogikan dengan pemrograman biasa, maka ketika Anda menggunakan metode seperti write, yang menulis sesuatu ke disk, dan kemudian mengembalikan respons kepada Anda, tidak ada jaminan bahwa Anda telah menulis data ke disk. Dan bahkan ketika sistem operasi yakin bahwa semuanya telah ditulis, ada mekanisme di dalam disk itu sendiri di mana proses melewati lapisan buffer, dan hanya setelah itu data ditempatkan pada disk.
Sebagian besar panggilan asinkron digunakan. Hal ini memungkinkan klien untuk bekerja secara paralel dengan permintaan yang berbeda. Anda dapat menggunakan pendekatan sinkron, namun kurang produktif.
Dua operasi yang kita bicarakan adalah pembaruan/penulisan, yang mengubah data. Ini adalah buat, setData, sinkronisasi, hapus. Dan baca ada, getData, getChildren.
Sekarang beberapa contoh bagaimana Anda dapat membuat primitif untuk bekerja dalam sistem terdistribusi. Misalnya saja terkait konfigurasi sesuatu. Seorang pekerja baru telah muncul. Kami menambahkan mesin dan memulai prosesnya. Dan ada tiga pertanyaan berikut. Bagaimana cara menanyakan ZooKeeper untuk konfigurasi? Dan jika kita ingin mengubah konfigurasinya, bagaimana cara mengubahnya? Dan setelah kami mengubahnya, bagaimana para pekerja yang kami miliki mendapatkannya?
ZooKeeper membuat ini relatif mudah. Misalnya, ada pohon znode kita. Ada node untuk aplikasi kita di sini, kita membuat node tambahan di dalamnya, yang berisi data dari konfigurasi. Ini mungkin merupakan parameter terpisah atau tidak. Karena ukurannya yang kecil, biasanya ukuran konfigurasinya juga kecil, sehingga sangat memungkinkan untuk disimpan di sini.
Anda menggunakan metode ini dapatkanData untuk mendapatkan konfigurasi pekerja dari node. Setel ke benar. Jika karena alasan tertentu simpul ini tidak ada, kami akan diberitahu tentangnya saat simpul tersebut muncul, atau saat simpul tersebut berubah. Jika kita ingin mengetahui bahwa ada sesuatu yang berubah, maka kita setel ke true. Dan jika data di node ini berubah, kita akan mengetahuinya.
SetData. Kami mengatur data, mengatur "-1", yaitu kami tidak memeriksa versinya, kami berasumsi bahwa kami selalu memiliki satu konfigurasi, kami tidak perlu menyimpan banyak konfigurasi. Jika Anda perlu menyimpan banyak, Anda perlu menambahkan level lain. Disini kami yakin hanya ada satu, jadi kami update yang terbaru saja, jadi tidak kami cek versinya. Saat ini, semua klien yang sebelumnya berlangganan menerima pemberitahuan bahwa ada sesuatu yang berubah di node ini. Dan setelah mereka menerimanya, mereka juga harus meminta datanya kembali. Notifikasinya mereka tidak menerima data itu sendiri, melainkan hanya notifikasi perubahan. Setelah ini mereka harus meminta data baru.
Opsi kedua untuk menggunakan primitif adalah keanggotaan grup. Kami memiliki aplikasi terdistribusi, ada banyak pekerja dan kami ingin memahami bahwa mereka semua sudah siap. Oleh karena itu, mereka harus mendaftarkan diri agar mereka bekerja di aplikasi kita. Dan kami juga ingin mengetahui, baik dari proses Master atau di tempat lain, tentang semua pekerja aktif yang kami miliki saat ini.
Bagaimana kita melakukan ini? Untuk aplikasinya, kami membuat node pekerja dan menambahkan sublevel di sana menggunakan metode create. Saya memiliki kesalahan pada slide. Di sini Anda perlu berurutan tentukan, maka semua pekerja akan dibuat satu per satu. Dan aplikasi, yang meminta semua data tentang anak-anak dari node ini, menerima semua pekerja aktif yang ada.
Ini adalah implementasi yang buruk tentang bagaimana hal ini dapat dilakukan dalam kode Java. Mari kita mulai dari akhir, dengan metode utama. Ini kelas kita, mari buat metodenya. Sebagai argumen pertama kita menggunakan host, tempat kita terhubung, yaitu kita menetapkannya sebagai argumen. Dan argumen kedua adalah nama grupnya.
Bagaimana koneksinya terjadi? Ini adalah contoh sederhana API yang digunakan. Semuanya relatif sederhana di sini. Ada ZooKeeper kelas standar. Kami meneruskan host ke sana. Dan atur batas waktu, misalnya, menjadi 5 detik. Dan kami memiliki anggota bernama connectSignal. Intinya, kami membuat grup di sepanjang jalur yang ditransmisikan. Kami tidak menulis data di sana, meskipun sesuatu bisa saja ditulis. Dan node di sini adalah tipe persisten. Intinya, ini adalah node reguler biasa yang akan ada sepanjang waktu. Di sinilah sesi dibuat. Ini adalah implementasi dari klien itu sendiri. Klien kami akan mengirimkan pesan berkala yang menunjukkan bahwa sesi tersebut aktif. Dan ketika kita mengakhiri sesi, kita menutupnya dan hanya itu, sesi tersebut terhenti. Ini untuk berjaga-jaga kalau ada sesuatu yang tidak beres pada kita, sehingga Penjaga Kebun Binatang mengetahuinya dan menghentikan sesinya.
Bagaimana cara mengunci sumber daya? Di sini segalanya menjadi sedikit lebih rumit. Kami memiliki sekumpulan pekerja, ada beberapa sumber daya yang ingin kami kunci. Untuk melakukan ini, kita membuat node terpisah, misalnya disebut lock1. Jika kita mampu membuatnya, maka kita mendapat kunci di sini. Dan jika kita tidak dapat membuatnya, maka pekerja mencoba mendapatkan getData dari sini, dan karena node telah dibuat, maka kita menempatkan pengamat di sini dan saat status node ini berubah, kita akan mengetahuinya. Dan kita dapat mencoba memiliki waktu untuk membuatnya kembali. Jika kita mengambil node ini, mengambil kunci ini, maka setelah kita tidak lagi membutuhkan kunci tersebut, kita akan meninggalkannya, karena node tersebut hanya ada dalam sesi tersebut. Oleh karena itu, itu akan hilang. Dan klien lain, sebagai bagian dari sesi lain, akan dapat mengunci node ini, atau lebih tepatnya, dia akan menerima pemberitahuan bahwa ada sesuatu yang berubah dan dia dapat mencoba melakukannya tepat waktu.
Contoh lain bagaimana Anda bisa memilih pemimpin utama. Ini sedikit lebih rumit, namun juga relatif sederhana. Apa yang terjadi di sini? Ada node utama yang mengumpulkan semua pekerja. Kami mencoba mendapatkan data tentang pemimpinnya. Jika ini berhasil terjadi, yaitu kami menerima beberapa data, maka pekerja kami mulai mengikuti pemimpin ini. Ia yakin sudah ada pemimpinnya.
Kalau pemimpinnya meninggal karena suatu hal, misalnya terjatuh, maka kita coba buat pemimpin baru. Dan jika kita berhasil, maka pekerja kitalah yang menjadi pemimpinnya. Dan jika seseorang saat ini berhasil menciptakan pemimpin baru, maka kami mencoba memahami siapa orang tersebut dan kemudian mengikutinya.
Di sinilah timbul apa yang disebut efek kawanan, yaitu efek kawanan, karena ketika seorang pemimpin meninggal, yang pertama kali akan menjadi pemimpin.
Saat mengambil sumber daya, Anda dapat mencoba menggunakan pendekatan yang sedikit berbeda, yaitu sebagai berikut. Misalnya kita ingin mendapatkan kunci, tetapi tanpa efek hert. Ini terdiri dari fakta bahwa aplikasi kita meminta daftar semua id node untuk node yang sudah ada dengan kunci. Dan jika sebelumnya node yang kita buat kuncinya adalah yang terkecil dari himpunan yang kita terima, maka ini berarti kita telah menangkap kunci tersebut. Kami memeriksa apakah kami telah menerima kunci. Sebagai pengecekannya, akan ada syarat bahwa id yang kita terima saat membuat kunci baru minimal. Dan jika kami menerimanya, maka kami terus bekerja.
Jika ada id tertentu yang lebih kecil dari lock kita, maka kita pasang watcher pada event ini dan tunggu notifikasi sampai ada perubahan. Artinya, kami menerima kunci ini. Dan sampai hilang, kita tidak akan menjadi id minimum dan tidak akan menerima kunci minimum, sehingga kita bisa login. Dan jika syarat ini tidak terpenuhi, maka kita segera menuju kesini dan mencoba untuk mendapatkan kunci ini kembali, karena mungkin saja ada yang berubah selama ini.
Terdiri dari apa Penjaga Kebun Binatang? Ada 4 hal utama. Ini sedang memproses proses - Permintaan. Dan juga Siaran Atom Penjaga Kebun Binatang. Ada Log Komit tempat semua operasi dicatat. Dan DB Replikasi Dalam Memori itu sendiri, yaitu database itu sendiri tempat seluruh pohon ini disimpan.
Perlu dicatat bahwa semua operasi penulisan melalui Pemroses Permintaan. Dan operasi baca langsung masuk ke database dalam memori.
Basis datanya sendiri sepenuhnya direplikasi. Semua instance ZooKeeper menyimpan salinan data lengkap.
Untuk memulihkan database setelah crash, ada log Komit. Praktik standarnya adalah sebelum data masuk ke memori, data tersebut ditulis di sana sehingga jika terjadi kerusakan, log ini dapat diputar ulang dan status sistem dapat dipulihkan. Dan snapshot database secara berkala juga digunakan.
ZooKeeper Atomic Broadcast adalah sesuatu yang digunakan untuk memelihara data yang direplikasi.
ZAB secara internal memilih pemimpin dari sudut pandang node ZooKeeper. Node lain menjadi pengikutnya dan mengharapkan tindakan darinya. Jika mereka menerima entri, mereka meneruskan semuanya ke pemimpin. Dia pertama-tama melakukan operasi tulis dan kemudian mengirimkan pesan tentang apa yang telah berubah kepada pengikutnya. Faktanya, hal ini harus dilakukan secara atomik, yaitu operasi perekaman dan penyiaran keseluruhannya harus dilakukan secara atomik, sehingga menjamin konsistensi data.
Itu hanya memproses permintaan tulis. Tugas utamanya adalah mengubah operasi menjadi pembaruan transaksional. Ini adalah permintaan yang dibuat khusus.
Dan di sini perlu dicatat bahwa idempotensi pembaruan untuk operasi yang sama dijamin. Apa itu? Hal ini, jika dijalankan dua kali, akan memiliki keadaan yang sama, yaitu permintaan itu sendiri tidak akan berubah. Dan ini perlu dilakukan agar jika terjadi kegagalan, Anda dapat memulai kembali operasi, sehingga mengembalikan perubahan yang telah dilakukan saat ini. Dalam hal ini, keadaan sistem akan menjadi sama, yaitu tidak boleh terjadi serangkaian proses yang sama, misalnya, pembaruan, menyebabkan keadaan akhir sistem yang berbeda.
Sumber: www.habr.com