Artikel ini berbicara tentang prinsip Zookeeper. Editor berpikir itu cukup bagus. Saya akan membaginya dengan Anda untuk referensi Anda. Dengan rincian sebagai berikut:
Kata pengantar
Zookeeper adalah layanan koordinasi terdistribusi sumber terbuka yang dibuat oleh Yahoo dan merupakan implementasi open source dari Google Chubby. Aplikasi terdistribusi dapat mengimplementasikan fungsi -fungsi seperti penerbitan/berlangganan data, penyeimbangan beban, layanan penamaan, koordinasi/pemberitahuan terdistribusi, manajemen cluster, pemilihan utama, penguncian terdistribusi dan antrian terdistribusi berdasarkan Zookeeper.
1. Pendahuluan
Zookeeper adalah layanan koordinasi terdistribusi sumber terbuka yang dibuat oleh Yahoo dan merupakan implementasi open source dari Google Chubby. Aplikasi terdistribusi dapat mengimplementasikan fungsi -fungsi seperti penerbitan/berlangganan data, penyeimbangan beban, layanan penamaan, koordinasi/pemberitahuan terdistribusi, manajemen cluster, pemilihan utama, penguncian terdistribusi dan antrian terdistribusi berdasarkan Zookeeper.
2. Konsep Dasar
Bagian ini akan memperkenalkan beberapa konsep inti ZooKeeper. Konsep -konsep ini dijelaskan secara lebih mendalam di kemudian hari, jadi perlu untuk memahami konsep -konsep ini sebelumnya.
2.1 peran cluster
Di Zookeeper, ada tiga karakter:
Pemimpin
Pengikut
Pengamat
Cluster Zookeeper hanya akan memiliki satu pemimpin pada saat yang sama, dan yang lainnya akan menjadi pengikut atau pengamat.
Konfigurasi ZooKeeper sangat sederhana. File konfigurasi (zoo.cfg) dari setiap node adalah sama, dan hanya file MYID yang berbeda. Nilai myID harus menjadi bagian {numerik} dari server. {Numeric} di zoo.cfg.
Contoh konten file zoo.cfg:
Zookeeper
Jalankan status server zookeeper pada terminal mesin dengan zookeeper. Anda dapat melihat apa peran zookeeper dari simpul saat ini (pemimpin atau pengikut).
Zookeeper
Seperti disebutkan di atas, Node-20-104 adalah pemimpin dan Node-20-103 adalah pengikut.
Zookeeper hanya memiliki dua peran: pemimpin dan pengikut secara default, dan tidak ada peran pengamat. Untuk menggunakan mode pengamat, tambahkan: peerType = pengamat ke file konfigurasi dari setiap node yang ingin menjadi pengamat dan tambahkan: pengamat ke jalur konfigurasi server yang dikonfigurasi dalam mode pengamat dalam file konfigurasi semua server, misalnya: misalnya:
server.1:localhost:2888:3888:observer
Semua mesin di kluster zookeeper memilih mesin yang disebut "pemimpin" melalui proses pemilihan pemimpin. Server pemimpin menyediakan layanan baca dan tulis kepada klien.
Baik pengikut dan pengamat dapat menyediakan layanan membaca, tetapi tidak menulis layanan. Satu -satunya perbedaan antara keduanya adalah bahwa mesin pengamat tidak berpartisipasi dalam proses pemilihan pemimpin, juga tidak berpartisipasi dalam strategi "lebih dari setengah penulisan yang berhasil" dari operasi penulisan, sehingga Observer dapat meningkatkan kinerja baca dari cluster tanpa mempengaruhi kinerja tulis.
2.2 Sesi
Sesi mengacu pada sesi klien. Sebelum menjelaskan sesi klien, mari kita pahami koneksi klien terlebih dahulu. Di Zookeeper, koneksi klien mengacu pada koneksi TCP yang panjang antara klien dan server Zookeeper.
Port layanan default Zookeeper adalah 2181. Ketika klien dimulai, koneksi TCP akan dibuat dengan server. Mulai dari pendirian koneksi pertama, siklus hidup sesi klien juga dimulai. Melalui koneksi ini, klien dapat mempertahankan sesi yang valid dengan server melalui deteksi detak jantung, dan juga dapat mengirim permintaan ke server Zookeeper dan menerima tanggapan. Pada saat yang sama, ia juga dapat menerima pemberitahuan acara Watch dari server melalui koneksi ini.
Nilai sesi sesi sesi digunakan untuk mengatur waktu batas waktu sesi klien. Ketika koneksi klien terputus karena tekanan server yang berlebihan, kegagalan jaringan, atau pemutusan aktif klien, selama server pada cluster dapat dihubungkan kembali dalam waktu yang ditentukan oleh sessionTimeout, sesi yang dibuat sebelumnya masih valid.
2.3 Node Data (Znode)
Saat berbicara tentang terdistribusi, umumnya "node" merujuk ke setiap mesin yang membentuk cluster. Node data di Zookeeper mengacu pada unit data dalam model data, yang disebut Znode. Zookeeper menyimpan semua data dalam memori. Model data adalah pohon (pohon znode). Jalur yang dibagi dengan slash (/) adalah znode, seperti/hbase/master, di mana hbase dan master keduanya adalah Znode. Setiap Znode akan menyimpan konten datanya sendiri, dan serangkaian informasi atribut akan disimpan.
Catatan:
Znode di sini dapat dipahami sebagai file di UNIX dan direktori di UNIX. Karena setiap Znode tidak hanya dapat menulis data itu sendiri (setara dengan file di UNIX), tetapi juga memiliki file atau direktori tingkat berikutnya (setara dengan direktori di UNIX).
Di Zookeeper, Znode dapat dibagi menjadi dua kategori: node persisten dan node sementara.
Simpul persisten
Node persisten yang disebut berarti bahwa setelah znode ini dibuat, znode akan disimpan pada zookeeper kecuali jika znode dihapus secara aktif.
Node sementara
Siklus hidup simpul sementara terikat pada sesi klien. Setelah sesi klien gagal, semua node sementara yang dibuat oleh klien ini akan dihapus.
Selain itu, Zookeeper juga memungkinkan pengguna untuk menambahkan atribut khusus: berurutan ke setiap node. Setelah node ditandai dengan atribut ini, ketika node ini dibuat, Zookeeper akan secara otomatis menambahkan nomor integer setelah simpulnya, yang merupakan nomor autoINCREMENTAL yang dikelola oleh node induk.
Versi 2.4
Data disimpan pada setiap zoODEper. Sesuai dengan masing -masing Znode, Zookeeper memelihara struktur data yang disebut stat untuk itu. STAT mencatat tiga versi data Znode ini, yaitu versi (versi Znode saat ini), cVersion (versi node anak Znode saat ini) dan Aversion (versi Znode ACL saat ini).
2.5 Informasi Status
Selain menyimpan konten data, masing -masing Znode juga menyimpan beberapa informasi status Znode itu sendiri. Gunakan perintah GET untuk mendapatkan konten dan informasi status Znode tertentu secara bersamaan. sebagai berikut:
Zookeeper
Di Zookeeper, atribut versi digunakan untuk mengimplementasikan "verifikasi tulis" dalam mekanisme kunci optimis (untuk memastikan operasi atom dari data terdistribusi).
2.6 Operasi Transaksi
Di Zookeeper, operasi yang dapat mengubah keadaan server Zookeeper disebut operasi transaksi. Ini umumnya mencakup operasi seperti pembuatan dan penghapusan simpul data, pembaruan konten data, pembuatan sesi klien dan kegagalan. Untuk setiap permintaan transaksi, Zookeeper akan menetapkan ID transaksi yang unik secara global, diwakili oleh ZXID, biasanya angka 64-bit. Setiap ZXID sesuai dengan operasi pembaruan, dari mana Zookeeper dapat secara tidak langsung mengidentifikasi urutan global di mana permintaan operasi transaksi ini diproses.
2.7 Watcher
Watcher (pendengar acara) adalah fitur yang sangat penting di Zookeeper. Zookeeper memungkinkan pengguna untuk mendaftarkan beberapa pengamat pada node yang ditentukan, dan ketika beberapa acara spesifik dipicu, server Zookeeper akan memberi tahu acara tersebut kepada klien yang tertarik. Mekanisme ini merupakan fitur penting dari Zookeeper untuk mengimplementasikan layanan koordinasi terdistribusi.
2.8 ACL
Zookeeper menggunakan kebijakan ACL (Daftar Kontrol Akses) untuk mengontrol izin. Zookeeper mendefinisikan 5 izin berikut.
Buat: Izin untuk membuat node anak.
Baca: Dapatkan izin ke data simpul dan daftar node anak.
Tulis: Izin untuk memperbarui data simpul.
Hapus: Hapus izin node anak.
Admin: Atur izin untuk node ACL.
Catatan: Buat dan hapus keduanya kontrol izin untuk node anak.
3. Skenario Aplikasi Khas ZooKeeper
Zookeeper adalah kerangka kerja manajemen data dan koordinasi terdistribusi yang sangat tersedia. Berdasarkan implementasi algoritma ZAB, kerangka kerja ini dapat memastikan konsistensi data dalam lingkungan terdistribusi. Ini juga didasarkan pada fitur ini yang menjadikan Zookeeper alat yang ampuh untuk menyelesaikan masalah konsistensi yang didistribusikan.
3.1 Penerbitan dan Langganan Data (Pusat Konfigurasi)
Penerbitan dan Langganan Data, yang disebut Pusat Konfigurasi, seperti namanya, adalah bahwa penerbit menerbitkan data ke node Zookeeper untuk pelanggan ke data, sehingga mencapai tujuan mendapatkan data secara dinamis, dan mewujudkan manajemen terpusat dan pembaruan dinamis dari informasi konfigurasi.
Dalam pengembangan sistem aplikasi kami yang biasa, kami sering menemukan persyaratan ini: beberapa informasi konfigurasi umum diperlukan dalam sistem, seperti informasi daftar mesin, informasi konfigurasi basis data, dll. Informasi konfigurasi global ini biasanya memiliki tiga fitur berikut.
Jumlah data biasanya relatif kecil.
Konten data berubah secara dinamis saat runtime.
Semua mesin di cluster dibagikan dan konfigurasinya konsisten.
Informasi konfigurasi global tersebut dapat dipublikasikan di ZooKeeper, yang memungkinkan klien (mesin cluster) untuk berlangganan pesan.
Umumnya ada dua mode desain untuk sistem penerbitan/berlangganan, yaitu mendorong dan menarik.
Push: Server secara aktif mengirimkan pembaruan data ke semua klien yang berlangganan.
Tarik: Klien secara aktif memulai permintaan untuk mendapatkan data terbaru. Biasanya, klien mengadopsi metode pemungutan suara dan penarik waktu.
Zookeeper menggunakan kombinasi dorongan dan tarik. sebagai berikut:
Klien ingin server mendaftarkan node yang perlu diperhatikan. Setelah data node berubah, server akan mengirim pemberitahuan acara Watcher ke klien yang sesuai. Setelah klien menerima pemberitahuan pesan ini, perlu secara aktif pergi ke server untuk mendapatkan data terbaru (dikombinasikan oleh Push and Pull).
3.2 Layanan Penamaan
Layanan penamaan juga merupakan jenis skenario umum dalam sistem terdistribusi. Dalam sistem terdistribusi, dengan menggunakan layanan penamaan, aplikasi klien dapat memperoleh informasi seperti alamat sumber daya atau layanan, penyedia, dll. Berdasarkan nama yang ditentukan. Entitas yang disebutkan biasanya dapat menjadi mesin di cluster, layanan yang disediakan, objek jarak jauh, dll. - Kita secara kolektif dapat menyebutnya nama (nama).
Di antara mereka, yang paling umum adalah daftar alamat layanan dalam beberapa kerangka kerja layanan terdistribusi (seperti RPC, RMI). Dengan membuat node berurutan di ZooKeEpr, mudah untuk membuat jalur yang unik secara global, yang dapat digunakan sebagai nama.
Layanan penamaan Zookeeper menghasilkan ID unik secara global.
3.3 Koordinasi/pemberitahuan terdistribusi
Zookeeper memiliki pendaftaran pengamat yang unik dan mekanisme pemberitahuan asinkron, yang dapat mewujudkan pemberitahuan dan koordinasi antara mesin yang berbeda dan bahkan sistem yang berbeda dalam lingkungan terdistribusi, sehingga mewujudkan pemrosesan perubahan data yang nyata. Metode penggunaan biasanya klien yang berbeda mendaftarkan Znode yang sama pada ZK untuk mendengarkan perubahan Znode (termasuk konten Znode itu sendiri dan node anak). Jika Znode berubah, semua klien yang berlangganan dapat menerima pemberitahuan pengamat yang sesuai dan membuat pemrosesan yang sesuai.
Koordinasi/pemberitahuan terdistribusi ZK adalah cara komunikasi yang umum antara sistem dan mesin terdistribusi.
3.3.1 Deteksi Detak Jantung
Mekanisme deteksi detak jantung antara mesin berarti bahwa dalam lingkungan terdistribusi, mesin yang berbeda (atau proses) perlu mendeteksi apakah satu sama lain berjalan secara normal. Misalnya, mesin A perlu mengetahui apakah mesin B berjalan secara normal. Dalam pengembangan tradisional, kami biasanya menilai apakah tuan rumah dapat secara langsung saling melakukan ping. Jika lebih rumit, kami akan membangun hubungan panjang antara mesin dan menyadari deteksi detak jantung mesin tingkat atas melalui mekanisme deteksi deteksi detak jantung yang melekat pada koneksi TCP. Ini adalah metode deteksi detak jantung yang sangat umum.
Mari kita lihat cara menggunakan ZK untuk mengimplementasikan deteksi detak jantung antara mesin terdistribusi (proses).
Berdasarkan karakteristik node sementara ZK, proses yang berbeda dapat membuat node anak sementara di bawah node yang ditentukan di ZK. Proses yang berbeda dapat secara langsung menilai apakah proses yang sesuai itu hidup berdasarkan simpul anak sementara ini. Dengan cara ini, deteksi dan sistem yang terdeteksi tidak perlu terkait langsung, tetapi dikaitkan melalui simpul tertentu pada ZK, kopling sistem yang sangat mengurangi.
3.3.2 Laporan Kemajuan Kerja
Dalam sistem distribusi tugas umum, biasanya setelah tugas didistribusikan ke mesin yang berbeda untuk dieksekusi, perlu untuk melaporkan kemajuan pelaksanaan tugasnya ke sistem distribusi secara real time. Kali ini dapat dicapai melalui ZK. Pilih node pada ZK, dan setiap klien tugas membuat node anak sementara di bawah node ini, sehingga dua fungsi dapat dicapai:
Tentukan apakah mesin tugas bertahan dengan menilai apakah node sementara ada.
Setiap mesin tugas akan menulis kemajuan eksekusi tugasnya ke simpul sementara ini secara real time sehingga sistem pusat dapat memperoleh kemajuan eksekusi tugas secara real time.
3.4 Pemilihan Master
Pemilihan utama dapat dikatakan sebagai skenario aplikasi Zookeeper yang paling khas. Misalnya, pemilihan namenode aktif dalam HDFS, pemilihan sumber daya aktif aktif dalam benang, dan pemilihan HMaster aktif dalam HBase.
Menanggapi kebutuhan pemilihan master, kami biasanya dapat memilih fitur kunci utama dalam database relasional umum untuk diimplementasikan: Jika mesin yang menjadi master memasukkan catatan dari ID kunci utama yang sama ke dalam database, database akan membantu kami melakukan pemeriksaan konflik kunci utama, yaitu satu mesin yang dapat menyisipkan - kemudian, kami berpikir bahwa mesin klien yang berhasil menyisipkan data ke dalam basis datab yang berhasil.
Mengandalkan karakteristik kunci utama dari database relasional memang dapat memastikan bahwa satu -satunya master dipilih dalam cluster.
Tapi apa yang harus saya lakukan jika master yang saat ini terpilih sudah mati? Siapa yang akan memberitahuku bahwa tuan itu sudah mati? Jelas, database relasional tidak dapat memberi tahu kami tentang acara ini. Tapi Zookeeper bisa melakukannya!
Menggunakan konsistensi kuat ZookeePr dapat memastikan bahwa penciptaan node dapat memastikan keunikan global dalam konkurensi tinggi terdistribusi, yaitu, Zookeeper akan memastikan bahwa klien tidak dapat membuat Znode yang ada.
Artinya, jika banyak klien meminta untuk membuat simpul sementara yang sama pada saat yang sama, maka hanya satu permintaan klien yang dapat berhasil dibuat pada akhirnya. Dengan menggunakan fitur ini, pemilihan master dapat dengan mudah dilakukan di lingkungan terdistribusi.
Mesin tempat klien yang berhasil membuat node berada menjadi master. Pada saat yang sama, klien lain yang tidak berhasil membuat node akan mendaftarkan pengamat untuk perubahan simpul anak pada node untuk memantau apakah mesin master saat ini masih hidup. Setelah master saat ini ditemukan mati, klien lain akan dipilih kembali.
Ini memungkinkan pemilihan master yang dinamis.
3.5 Kunci Terdistribusi
Kunci terdistribusi adalah cara untuk mengontrol akses sinkron ke sumber daya bersama antara sistem terdistribusi.
Kunci terdistribusi dibagi menjadi kunci eksklusif dan kunci bersama.
3.5.1 Kunci Eksklusif
Kunci eksklusif (Kunci X singkatnya), juga dikenal sebagai kunci tulis atau kunci eksklusif.
Jika transaksi T1 menambahkan kunci eksklusif ke objek data O1, maka selama seluruh periode penguncian, hanya transaksi T1 yang diizinkan untuk membaca dan memperbarui O1, dan tidak ada transaksi lain yang dapat melakukan semua jenis operasi pada objek data ini (objek tidak dapat dikunci) sampai T1 melepaskan kunci eksklusif.
Dapat dilihat bahwa inti dari kunci eksklusif adalah bagaimana memastikan bahwa hanya satu transaksi yang saat ini memperoleh kunci, dan setelah kunci dilepaskan, semua transaksi yang menunggu untuk memperoleh kunci yang dapat diberitahukan.
Bagaimana cara menggunakan Zookeeper untuk mencapai kunci eksklusif?
Tentukan kunci
Znode pada Zookeeper dapat mewakili kunci. Misalnya, simpul /eksklusif_lock /kunci dapat didefinisikan sebagai kunci.
Dapatkan kunci
Seperti disebutkan di atas, pertimbangkan Znode pada Zookeeper sebagai kunci, dan mendapatkan kunci dicapai dengan membuat Znode. Semua klien pergi ke /eksklusif_lock /lock untuk membuat node anak sementara /eksklusif_lock /lock di bawah /eksklusif_lock node. Zookeeper akan memastikan bahwa di antara semua klien, hanya satu klien yang dapat dibuat dengan sukses, dan kemudian dapat dipertimbangkan bahwa klien telah memperoleh kunci. Pada saat yang sama, semua klien yang belum mendapatkan kunci perlu mendaftarkan pengamat untuk perubahan simpul anak pada simpul /eksklusif_lock untuk mendengarkan perubahan node kunci secara real time.
Lepaskan kunci
Karena /eksklusif_lock /lock adalah simpul sementara, dimungkinkan untuk melepaskan kunci dalam kedua kasus.
Jika mesin klien saat ini mendapatkan kunci gagal atau restart, simpul sementara akan dihapus dan kunci akan dilepaskan.
Setelah logika bisnis dieksekusi secara normal, klien akan secara aktif menghapus simpul sementara yang dibuat dan melepaskan kunci.
Tidak masalah dalam keadaan apa simpul kunci dihapus, Zookeeper memberi tahu semua klien yang telah mendaftarkan Node Change Watcher mendengarkan pada simpul /eksklusif_lock. Setelah menerima pemberitahuan, klien-klien ini memulai kembali akuisisi kunci yang didistribusikan lagi, yaitu, mengulangi "akuisisi kunci".
3.5.2 Kunci Bersama
Kunci bersama (kunci S, disebut sebagai kunci S), juga dikenal sebagai kunci baca. Jika transaksi T1 menambahkan kunci bersama ke objek data O1, maka T1 hanya dapat membaca O1, dan transaksi lainnya juga dapat menambahkan kunci bersama ke O1 pada saat yang sama (bukan kunci eksklusif). O1 hanya dapat ditambahkan ke kunci eksklusif sampai semua kunci bersama pada O1 dirilis.
Ringkasan: Beberapa transaksi dapat memperoleh kunci bersama untuk suatu objek pada saat yang sama (dibaca pada saat yang sama). Jika ada kunci bersama, Anda tidak dapat menambahkan kunci eksklusif (karena kunci eksklusif adalah kunci tulis)
4. Penerapan ZooKeeper dalam sistem terdistribusi besar
Skenario aplikasi khas Zookeeper telah diperkenalkan sebelumnya. Bagian ini akan memperkenalkan aplikasi Zookeeper dalam produk Big Data Common Hadoop dan HBase sebagai contoh untuk membantu semua orang lebih memahami skenario aplikasi yang didistribusikan dari Zookeeper.
4.1 Aplikasi ZooKeeper di Hadoop
Di Hadoop, Zookeeper terutama digunakan untuk mengimplementasikan HA (ketersediaan Hive), termasuk namanode HDFS dan HA ResourceManager HDFS. Pada saat yang sama, dalam benang, ZooKeEpr juga digunakan untuk menyimpan status operasi aplikasi.
Prinsip menggunakan ZooKeEpr untuk mengimplementasikan HA adalah sama di Namanode dan Benang HDFS dan Yarn's ResourceManager, jadi bagian ini memperkenalkannya dengan benang sebagai contoh.
Zookeeper
Seperti dapat dilihat dari gambar di atas, benang terutama terdiri dari empat bagian: ResourceManager (RM), Nodemanager (NM), ApplicationMaster (AM) dan wadah. Inti yang paling dari mereka adalah ResourceManager.
ResourceManager bertanggung jawab atas manajemen terpadu dan alokasi semua sumber daya di cluster. Ini juga menerima informasi pelaporan sumber daya dari masing -masing node (NODemanager) dan mengalokasikan informasi ini untuk setiap aplikasi (Manajer Aplikasi) sesuai dengan kebijakan tertentu. Ini memelihara informasi ApplicationMaster, informasi NODemanager, dan informasi penggunaan sumber daya dari setiap aplikasi.
Untuk mengimplementasikan HA, beberapa sumber daya nanggilan harus hidup berdampingan (biasanya dua), dan hanya satu ResourceManager yang dalam keadaan aktif, sementara yang lain dalam keadaan siaga. Ketika simpul aktif tidak dapat bekerja dengan baik (seperti downtime mesin atau restart), siaga akan bersaing untuk menghasilkan simpul aktif baru.
4.2 sakelar utama dan cadangan
Mari kita lihat bagaimana benang mengimplementasikan perpindahan master-subsidi di antara beberapa sumber daya.
1. Buat node kunci. Di Zookeeper, akan ada /node kunci pemilihan /benang-leader /appluster-yarn. Ketika semua Resourcemanagers dimulai, mereka akan bersaing untuk menulis node anak terkunci:/pemilihan benang-pemimpin/appcluster-yarn/ActiveBreadCrumb. Node ini adalah simpul sementara.
ZooKeEpr dapat memastikan bahwa hanya satu ResourceManager yang dapat dibuat dengan sukses pada akhirnya. ResourceManager yang berhasil dibuat akan dialihkan ke keadaan aktif, sedangkan yang tidak berhasil akan beralih ke status siaga.
Zookeeper
Anda dapat melihat bahwa ResourceManager2 di cluster aktif saat ini.
Daftar Monitor Pengamat
Semua Resourcemanagers di negara-negara siaga akan mendaftarkan pengamat untuk perubahan simpul ke simpul/pemilihan benang/appluster-yarn/ActiveBreadcrumb. Menggunakan karakteristik node sementara, Anda dapat dengan cepat merasakan pengoperasian sumber daya sumber daya di negara -negara aktif.
Sakelar utama dan cadangan
Ketika sebuah negara bagian yang aktif, ResourceManager mengalami pengecualian seperti downtime atau restart, sesi klien yang terhubung ke ZooKeeper akan tidak valid, sehingga simpul/pemilihan benang/appcluster-yarn/ActiveBreadCrumb akan dihapus. Pada saat ini, status sumber daya lain dalam status siaga akan menerima pemberitahuan acara Watcher dari server Zookeeper, dan kemudian ulangi pengoperasian langkah 1.
Di atas adalah proses penggunaan Zookeeper untuk mewujudkan switching utama dan cadangan ResourceManager, yang mewujudkan HA ResourceManager.
Prinsip implementasi namenode HA dalam HDFS sama dengan prinsip implementasi ResourceManager HA dalam benang. Node kuncinya adalah/Hadoop-ha/mycluster/ActiveBreadCrumb.
4.3 Penyimpanan Status ResourceManager
Di ResourceManager, RMStateStore dapat menyimpan beberapa informasi negara internal RM, termasuk aplikasi dan informasi upaya mereka, token delegasi, informasi versi, dll. Perlu dicatat bahwa sebagian besar informasi negara bagian dalam RMStatestore tidak perlu penyimpanan yang bertahan, karena mudah untuk merekonstruksi dari informasi konteks, seperti penggunaan sumber daya. Dalam skema desain penyimpanan, tiga implementasi yang mungkin disediakan, masing -masing sebagai berikut.
Berdasarkan implementasi memori, ini umumnya digunakan untuk pengembangan dan pengujian harian.
Implementasi berbasis sistem file seperti HDFS.
Berdasarkan implementasi Zookeeper.
Karena jumlah data dari informasi negara ini tidak terlalu besar, Hadoop secara resmi merekomendasikan agar ia menyadari penyimpanan informasi negara berdasarkan Zookeeper. Di ZooKeEpr, informasi status dari ResourceManager disimpan di bawah node root /rmstore.
Zookeeper
Node RMAPPROOT menyimpan informasi yang terkait dengan setiap aplikasi, dan RMDTSecretManagerroot menyimpan informasi yang terkait dengan keamanan dan informasi lainnya. ResourceManager dari setiap negara aktif membaca informasi status ini dari Zookeeper selama fase inisialisasi dan terus memproses sesuai dengan informasi status ini.
4.4 Ringkasan:
Aplikasi utama ZooKeEpr di Hadoop adalah:
Ha namenode dalam hdfs dan ha resourceManager dalam benang.
Simpan informasi status rmstatestore
5. Aplikasi ZooKeeper di HBase
HBase terutama menggunakan Zookeeper untuk mewujudkan pemilihan HMASTER dan switching master-slip, toleransi kesalahan sistem, manajemen rootregion, manajemen negara bagian dan terdistribusi
Manajemen Tugas Splitwal, dll.
5.1 Pemilihan HMaster dan sakelar cadangan utama
Prinsip pemilihan HMASTER dan switching dukungan master sama dengan prinsip HA namenode dalam HDF dan ResourceManager dalam benang.
5.2 Toleransi Kesalahan Sistem
Ketika HBASE dimulai, setiap regionerver akan membuat simpul informasi di bawah simpul/RS HBase/RS dari Zookeeper (selanjutnya, kami menyebut simpul ini "Node Negara RS"), seperti/hbase/rs/[hostname]. Pada saat yang sama, HMaster akan mendaftar dan mendengarkan node ini. Ketika sebuah regionerver gagal, Zookeeper akan menghapus simpul status RS yang sesuai dengan server RegionServer karena tidak dapat menerima detak jantungnya untuk jangka waktu tertentu (mis. Sesi tidak valid).
Pada saat yang sama, HMaster akan menerima pemberitahuan Nodedelete dari ZooKeeper, sehingga merasakan sebuah simpul terputus dan segera memulai pekerjaan toleran kesalahan.
Mengapa HBase tidak secara langsung membiarkan HMASTER bertanggung jawab atas pemantauan Regionerver? Jika HMaster secara langsung mengelola status server daerah melalui mekanisme detak jantung, karena cluster menjadi lebih besar dan lebih besar, beban manajemen HMASTER akan menjadi lebih berat, dan mungkin juga gagal, sehingga data perlu bertahan. Dalam hal ini, ZooKeeper menjadi pilihan yang ideal.
5.3 Manajemen Rootregion
Untuk kelompok HBase, informasi lokasi penyimpanan data dicatat pada wilayah metadata, yaitu rootregion. Setiap kali klien memulai permintaan baru dan perlu mengetahui lokasi data, itu akan menanyakan rootregion, dan lokasi rootregion sendiri direkam pada ZooKeeper (secara default, direkam dalam node server-server zookeeper /hBase /meta-region).
Ketika rootregion berubah, seperti pergerakan manual wilayah, memuat ulang penyeimbangan, atau kegagalan server rootregion, itu dapat merasakan perubahan ini melalui zookeeper dan mengambil serangkaian langkah pemulihan bencana yang sesuai untuk memastikan bahwa klien selalu dapat memperoleh informasi rootregion yang benar.
5.4 Manajemen Wilayah
Daerah di HBase sering diubah. Alasan untuk perubahan ini adalah kegagalan sistem, penyeimbangan beban, modifikasi konfigurasi, pemisahan dan penggabungan wilayah, dll. Setelah wilayah bergerak, ia melewati proses offline dan online.
Data tidak dapat diakses selama offline, dan perubahan keadaan ini di wilayah ini harus diketahui ke tingkat global, jika tidak, pengecualian transaksional dapat terjadi.
Untuk kelompok HBase besar, jumlah daerah mungkin setinggi 100.000, atau bahkan lebih. Ini juga merupakan pilihan yang baik untuk meninggalkan manajemen negara bagian pada skala ini ke Zookeeper.
5.5 Manajemen Tugas Splitwal Terdistribusi
Ketika server RegionServer menutup telepon, karena selalu ada sebagian dari data yang baru ditulis yang belum ada di hfile, ketika memigrasi layanan RegionServer, tugas penting adalah mengembalikan bagian data ini yang masih dalam memori dari WAL. Langkah paling kritis di bagian pekerjaan ini adalah Splitwal, yaitu, HMaster perlu melintasi Wal dari server Regionerver, membaginya menjadi potongan -potongan kecil dan memindahkannya ke alamat baru, dan memutar ulang log.
Karena volume log dari server region tunggal relatif besar (mungkin ada ribuan wilayah, dengan GB log), pengguna sering berharap bahwa sistem dapat dengan cepat menyelesaikan pekerjaan pemulihan log. Oleh karena itu, solusi yang layak adalah mengalokasikan tugas ini yang menangani WAL ke beberapa server Regionerver untuk pemrosesan bersama, yang membutuhkan komponen yang persisten untuk membantu HMASTER dalam menyelesaikan alokasi tugas.
Praktik saat ini adalah bahwa HMASTER akan membuat simpul splitwal di ZooKeeper (secara default, itu adalah /hbase /splitwal node), menyimpan informasi seperti "RegionServer mana yang menangani wilayah mana" pada node dalam daftar, dan kemudian setiap server region akan gagal ke node untuk mengumpulkan tugas dan memperbarui informasi node setelah langkah -langkah tugas yang berhasil ke node untuk mengumpulkan node untuk mengumpulkan tugas dan memperbarui informasi node. Zookeeper memainkan peran pemberitahuan bersama dan kegigihan informasi dalam kelompok terdistribusi di sini.
5.6 Ringkasan:
Di atas adalah beberapa skenario khas dalam HBase yang mengandalkan Zookeeper untuk menyelesaikan fungsi koordinasi yang didistribusikan. Namun pada kenyataannya, HBase memiliki lebih dari ketergantungan pada penjaga kebun binatang. Misalnya, HMaster juga bergantung pada Zookeeper untuk menyelesaikan catatan status Enable/Nonaktifkan tabel, dan hampir semua penyimpanan metadata di HBase ditempatkan pada Zookeeper.
Karena kemampuan koordinasi terdistribusi yang sangat baik dari Zookeeper dan mekanisme pemberitahuan yang baik, HBASE semakin menambahkan skenario aplikasi Zookeeper dalam evolusi setiap versi, dan dari perspektif tren, keduanya memiliki lebih banyak persimpangan. Semua operasi di ZooKeeper di HBase dienkapsulasi dalam paket org.apache.hadoop.hbase.zooKeeper. Siswa yang tertarik dapat mempelajarinya sendiri.
Di atas adalah modul boot pegas yang diperkenalkan editor kepada Anda. Saya harap ini akan membantu Anda. Jika Anda memiliki pertanyaan, silakan tinggalkan saya pesan dan editor akan membalas Anda tepat waktu!