Zookeeper adalah subproyek dari Hadoop, dan meskipun berasal dari hadoop, saya telah menemukan bahwa zookeeper semakin banyak menggunakan kerangka kerja terdistribusi di luar hadoop. Hari ini saya ingin berbicara tentang zookeeper, artikel ini tidak akan berbicara tentang cara menggunakan zookeeper, tetapi apa saja aplikasi praktis zookeeper, jenis aplikasi apa yang dapat memainkan keunggulan zookeeper, dan terakhir berbicara tentang peran apa yang dapat dimainkan zookeeper dalam arsitektur situs web terdistribusi.
Zookeeper adalah sistem koordinasi yang sangat andal untuk sistem terdistribusi besar. Dari definisi ini, kita tahu bahwa penjaga kebun binatang adalah sistem terkoordinasi yang bekerja pada sistem terdistribusi. Mengapa sistem terdistribusi membutuhkan sistem koordinasi? Alasannya adalah sebagai berikut:
Mengembangkan sistem terdistribusi adalah hal yang sangat sulit, dan kesulitannya terutama tercermin dalam "kegagalan parsial" dari sistem terdistribusi. "Kegagalan parsial" mengacu pada transmisi informasi antara dua node jaringan, jika jaringan gagal, pengirim tidak dapat mengetahui apakah penerima telah menerima pesan, dan penyebab kegagalan ini kompleks, penerima mungkin atau mungkin belum menerima pesan sebelum kesalahan jaringan, atau proses penerima mati. Satu-satunya cara pengirim bisa mendapatkan gambaran sebenarnya adalah dengan menghubungkan kembali ke penerima dan bertanya kepada penerima mengapa kesalahan terjadi, yang merupakan masalah "kegagalan parsial" dalam pengembangan sistem terdistribusi.
Zookeeper adalah kerangka kerja untuk memecahkan "kegagalan parsial" dari sistem terdistribusi. Zookeeper tidak mengizinkan sistem terdistribusi untuk menghindari masalah "kegagalan parsial", tetapi memungkinkan sistem terdistribusi untuk menangani masalah tersebut dengan benar ketika menghadapi kegagalan parsial, sehingga sistem terdistribusi dapat beroperasi secara normal.
Mari kita bicara tentang penggunaan praktis penjaga kebun binatang:
Skenario 1: Ada sekelompok server yang menyediakan layanan tertentu kepada klien (misalnya, sisi server dari situs web terdistribusi yang saya buat sebelumnya adalah kluster yang terdiri dari empat server untuk menyediakan layanan ke klaster front-end), dan kami berharap klien dapat menemukan server di kluster server setiap kali klien memintanya, sehingga server dapat menyediakan klien dengan layanan yang dibutuhkan oleh klien. Untuk skenario ini, kita harus memiliki daftar server dalam program kita, dari mana kita membaca daftar server setiap kali klien memintanya. Maka sublist ini jelas tidak dapat disimpan di server node tunggal, jika tidak, node akan menutup telepon dan seluruh cluster akan gagal, dan kami berharap daftar ini akan sangat tersedia pada saat itu. Jika server dalam daftar penyimpanan rusak, server lain dapat segera mengganti server yang rusak, dan server yang rusak dapat dihapus dari daftar, sehingga server yang gagal dapat menarik diri dari pengoperasian seluruh kluster, dan semua operasi ini tidak akan dioperasikan oleh server yang gagal, tetapi oleh server normal di kluster. Ini adalah struktur data terdistribusi aktif yang dapat secara aktif memodifikasi status item data saat kondisi eksternal berubah. Kerangka kerja Zookeeper menyediakan layanan ini. Nama layanan ini adalah: Unified Naming Service, yang sangat mirip dengan layanan JNDI di javaEE.
Skenario 2: Layanan kunci terdistribusi. Ketika sistem terdistribusi memanipulasi data, seperti membaca data, menganalisis data, dan akhirnya memodifikasi data. Dalam sistem terdistribusi, operasi ini dapat tersebar ke node yang berbeda di kluster, maka ada masalah konsistensi dalam proses operasi data, jika tidak konsisten, kita akan mendapatkan hasil operasi yang salah, dalam satu program proses, masalah konsistensi mudah dipecahkan, tetapi lebih sulit untuk mencapai sistem terdistribusi, karena operasi server yang berbeda dalam sistem terdistribusi berada dalam proses independen, dan hasil perantara serta proses operasi harus ditransmisikan melalui jaringan. Maka jauh lebih sulit untuk mencapai konsistensi operasi data. Zookeeper menyediakan layanan kunci yang memecahkan masalah ini, memungkinkan kami memastikan konsistensi operasi data saat melakukan operasi data terdistribusi.
Skenario 3: Manajemen konfigurasi. Dalam sistem terdistribusi, kami akan menyebarkan aplikasi layanan ke n server secara terpisah, dan file konfigurasi server ini sama (misalnya, dalam kerangka situs web terdistribusi yang saya rancang, ada 4 server di sisi server, program di 4 server sama, dan file konfigurasinya sama), jika opsi konfigurasi file konfigurasi berubah, maka kita harus mengubah file konfigurasi ini satu per satu, jika kita perlu mengubah server relatif kecil, operasi ini tidak terlalu merepotkan, Jika kita memiliki sejumlah besar server terdistribusi, seperti kluster Hadoop perusahaan Internet besar dengan ribuan server, maka mengubah opsi konfigurasi bisa menjadi hal yang merepotkan dan berbahaya. Saat ini, zookeeper dapat berguna, kita dapat menggunakan zookeeper sebagai memori konfigurasi yang sangat tersedia, menyerahkan hal seperti itu ke zookeeper untuk manajemen, kita menyalin file konfigurasi kluster ke node sistem file zookeeper, dan kemudian menggunakan zookeeper untuk memantau status file konfigurasi di semua sistem terdistribusi, setelah ditemukan bahwa file konfigurasi telah berubah, Setiap server akan menerima pemberitahuan dari Zookeeper untuk menyinkronkan file konfigurasi di Zookeeper, dan layanan Zookeeper juga akan memastikan bahwa operasi sinkronisasi bersifat atomik untuk memastikan bahwa file konfigurasi setiap server diperbarui dengan benar.
Skenario 4: Menyediakan fungsi perbaikan kesalahan untuk sistem terdistribusi. Manajemen klaster itu sulit, dan menambahkan layanan penjaga kebun binatang ke sistem terdistribusi memudahkan kami untuk mengelola klaster. Hal yang paling merepotkan dalam manajemen klaster adalah manajemen kesalahan simpul, penjaga kebun binatang dapat membiarkan kluster memilih simpul yang sehat sebagai master, simpul master akan mengetahui status kesehatan saat ini dari setiap server di kluster, setelah simpul gagal, master akan memberi tahu server lain di kluster, untuk mendistribusikan ulang tugas komputasi dari simpul yang berbeda. Zookeeper tidak hanya dapat menemukan kesalahan, tetapi juga menyaring server yang rusak, melihat jenis kesalahan server kesalahannya, jika kesalahan dapat diperbaiki, Zookeeper dapat secara otomatis memperbaiki atau memberi tahu administrator sistem alasan kesalahan, sehingga administrator dapat dengan cepat menemukan masalah dan memperbaiki kesalahan node. Anda mungkin masih memiliki pertanyaan, apa yang harus saya lakukan jika tuannya rusak? Penjaga kebun binatang juga memperhitungkan hal ini, penjaga kebun binatang memiliki "algoritma untuk memilih pemimpin" internal, master dapat dipilih secara dinamis, dan ketika master gagal, penjaga kebun binatang dapat segera memilih master baru untuk mengelola kluster.
Mari kita bicara tentang fitur-fitur penjaga kebun binatang:
ZooKeeper adalah sistem file yang disederhanakan. Ini agak mirip dengan Hadoop, tetapi sistem file ZooKeeper mengelola file kecil, sedangkan Hadoop mengelola file yang sangat besar.
Zookeeper menyediakan banyak "artefak" yang memungkinkan banyak operasi untuk mengoordinasikan struktur dan protokol data. Misalnya: antrean terdistribusi, kunci terdistribusi, dan algoritme "pemilihan pemimpin" dari grup simpul pada tingkat yang sama.
ZooKeeper sangat tersedia, stabilitasnya sendiri cukup baik, kluster terdistribusi dapat mengandalkan pengelolaan kluster Zookeeper, dan ZooKeeper digunakan untuk menghindari masalah kegagalan titik tunggal sistem terdistribusi.
Zookeeper mengadopsi mode interaksi yang digabungkan secara longgar. Hal ini paling jelas dalam fakta bahwa zookeeper menyediakan kunci terdistribusi, yang dapat digunakan sebagai mekanisme penunjukan untuk memungkinkan proses yang berpartisipasi menemukan dan berinteraksi satu sama lain tanpa mengetahui proses lain (atau jaringan), dan pihak yang berpartisipasi bahkan tidak harus ada pada saat yang sama, selama mereka meninggalkan pesan di zookeeper, dan setelah proses berakhir, proses lain dapat membaca pesan ini, sehingga memisahkan hubungan antar node.
ZooKeeper menyediakan repositori bersama untuk kluster, dari mana kluster dapat membaca dan menulis informasi bersama secara terpusat, menghindari pemrograman operasi bersama untuk setiap node dan mengurangi kesulitan pengembangan sistem terdistribusi.
Zookeeper terutama bertanggung jawab untuk menyimpan dan mengelola data yang dipedulikan semua orang, dan kemudian menerima pendaftaran pengamat, setelah status data ini berubah, Zookeeper akan bertanggung jawab untuk memberi tahu pengamat yang telah terdaftar di Zookeeper untuk merespons dengan tepat, sehingga mencapai mode manajemen master/slave yang mirip dengan cluster.
Dapat dilihat bahwa zookeeper sangat kondusif untuk pengembangan sistem terdistribusi, yang dapat membuat sistem terdistribusi lebih kuat dan efisien.
Belum lama ini, saya berpartisipasi dalam kelompok minat hadoop departemen, dan saya menginstal hadoop, mapreduce, Hive, dan Hbase di lingkungan pengujian, dan saya menginstal zookeeper terlebih dahulu saat menginstal hbase. Zookeeper dapat menyediakan layanan, jadi lebih dari setengah dari 3 adalah 2, dan lebih dari setengah dari 4 juga dua, sehingga menginstal tiga server dapat mencapai efek 4 server. Dalam proses belajar hadoop, saya merasa bahwa penjaga kebun binatang adalah sub-proyek yang paling sulit untuk dipahami, alasannya bukan karena bertanggung jawab secara teknis, tetapi arah penerapannya sangat membingungkan bagi saya, jadi artikel pertama saya tentang teknologi hadoop dimulai dengan penjaga kebun binatang, dan tidak berbicara tentang implementasi teknis tertentu, tetapi dari skenario aplikasi penjaga kebun binatang, saya memahami bidang aplikasi penjaga kebun binatang, saya pikir belajar penjaga kebun binatang akan lebih efektif dengan setengah usaha.
Alasan mengapa saya ingin berbicara tentang penjaga kebun binatang hari ini adalah untuk melengkapi kerangka kerja situs web terdistribusi di artikel saya sebelumnya. Meskipun saya merancang arsitektur situs web untuk menjadi struktur terdistribusi, saya juga membuat mekanisme penanganan kesalahan sederhana, seperti mekanisme detak jantung, tetapi masih belum ada cara untuk mengatasi titik kegagalan tunggal kluster, jika server rusak, klien akan mencoba terhubung ke server ini, mengakibatkan pemblokiran beberapa permintaan, dan juga menyebabkan pemborosan sumber daya server. Namun, saya tidak ingin memodifikasi kerangka kerja saya saat ini, karena saya selalu merasa bahwa menambahkan layanan penjaga kebun binatang ke layanan yang ada akan memengaruhi efisiensi situs web. Untungnya, departemen kami juga telah menemukan masalah seperti itu, departemen kami akan mengembangkan kerangka kerja panggilan jarak jauh yang kuat, memisahkan manajemen kluster dan manajemen komunikasi, dan menyediakan layanan yang efisien dan tersedia secara terpusat.
Ditransfer dari ttp://www.cnblogs.com/sharpxiajun/archive/2013/06/02/3113923.html |
Diposting pada 18/07/2017 14.19.01
|
|
|
