Aku saranake sampeyan maca transkrip kuliah "Hadoop. ZooKeeper "saka seri "Metode kanggo pangolahan distribusi volume data gedhe ing Hadoop "
Apa ZooKeeper, panggonane ing ekosistem Hadoop. Untruths babagan komputasi sing disebarake. Diagram saka sistem distribusi standar. Kesulitan ing koordinasi sistem distribusi. Masalah koordinasi khas. Prinsip konco desain ZooKeeper. Model data ZooKeeper. gendera znode. Sesi. API klien. Primitif (konfigurasi, anggota grup, kunci prasaja, pemilihan pimpinan, ngunci tanpa efek komplotan). Arsitektur ZooKeeper. ZooKeeper DB. ZAB. Panjaluk pawang.
Dina iki kita bakal ngomong babagan ZooKeeper. Bab iki migunani banget. Iki, kaya produk Apache Hadoop, duwe logo. Iku nggambarake wong.
Sadurunge iki, kita utamané ngomong babagan carane data bisa diproses ing kono, carane nyimpen, yaiku, carane nggunakake lan bisa digunakake. Lan dina iki aku arep ngomong sethithik babagan mbangun aplikasi sing disebarake. Lan ZooKeeper minangka salah sawijining perkara sing ngidini sampeyan nyederhanakake prakara iki. Iki minangka jinis layanan sing dimaksudake kanggo sawetara jinis koordinasi interaksi proses ing sistem sing disebarake, ing aplikasi sing disebarake.
Kebutuhan kanggo aplikasi kaya ngono saben dina, mula kursus kita. Ing tangan siji, MapReduce lan framework siap iki ngijini sampeyan kanggo tingkat metu kerumitan iki lan mbebasake programmer saka nulis primitif kayata interaksi lan koordinasi pangolahan. Nanging ing sisih liya, ora ana sing njamin yen iki ora kudu ditindakake. MapReduce utawa kerangka siap-siap liyane ora mesthi ngganti sawetara kasus sing ora bisa ditindakake nggunakake iki. Kalebu MapReduce dhewe lan akeh proyek Apache liyane, uga aplikasi sing disebarake. Lan supaya nulis luwih gampang, dheweke nulis ZooKeeper.
Kaya kabeh aplikasi sing gegandhengan karo Hadoop, iki dikembangake dening Yahoo! Saiki uga dadi aplikasi Apache resmi. Ora dikembangake kanthi aktif kaya HBase. Yen sampeyan pindhah menyang JIRA HBase, banjur saben dina ana akeh laporan bug, akeh usulan kanggo ngoptimalake apa wae, yaiku urip ing proyek kasebut terus-terusan. Lan ZooKeeper, ing tangan siji, minangka produk sing relatif prasaja, lan ing tangan liyane, iki njamin linuwih. Lan cukup gampang digunakake, mula wis dadi standar ing aplikasi ing ekosistem Hadoop. Dadi aku mikir bakal migunani kanggo mriksa maneh kanggo ngerti cara kerjane lan cara nggunakake.
Iki minangka gambar saka sawetara ceramah sing ditindakake. Kita bisa ngomong yen iku ortogonal kanggo kabeh sing wis dianggep nganti saiki. Lan kabeh sing dituduhake ing kene, kanggo siji utawa liyane, bisa digunakake karo ZooKeeper, yaiku layanan sing nggunakake kabeh produk kasebut. Sanadyan HDFS utawa MapReduce ora nulis layanan sing padha sing bisa digunakake kanggo dheweke. Patut, ZooKeeper digunakake. Lan iki nyederhanakake pangembangan lan sawetara perkara sing ana gandhengane karo kesalahan.
Saka ngendi kabeh iki teka? Iku bakal koyone sing dibukak loro aplikasi ing podo karo ing komputer beda, disambungake karo senar utawa ing bolong, lan kabeh bisa. Nanging masalah iku Jaringan ora dipercaya, lan yen sampeyan sniffed lalu lintas utawa katon ing apa wis kedados ana ing tingkat kurang, carane klien sesambungan ing Jaringan, sampeyan bisa kerep ndeleng sing sawetara paket ilang utawa dikirim maneh. Ora ana gunane yen protokol TCP diciptakake, sing ngidini sampeyan nggawe sesi tartamtu lan njamin pangiriman pesen. Nanging ing kasus apa wae, malah TCP ora bisa nyimpen sampeyan. Kabeh duwe wektu entek. Jaringan kasebut bisa uga ilang sawetara wektu. Bisa uga mung kedhip. Lan iki kabeh nyebabake kasunyatan manawa sampeyan ora bisa ngandelake Jaringan sing bisa dipercaya. Iki minangka prabédan utama saka nulis aplikasi paralel sing mlaku ing siji komputer utawa ing siji superkomputer, ing ngendi ora ana Jaringan, ing ngendi ana bis exchange data sing luwih dipercaya ing memori. Lan iki prabédan dhasar.
Antarane liyane, nalika nggunakake Jaringan, mesthi ana latensi tartamtu. Disk uga duwe, nanging Jaringan luwih akeh. Latency sawetara wektu tundha, kang bisa salah siji cilik utawa cukup pinunjul.
Topologi jaringan wis ganti. Apa topologi - iki panggonan seko saka peralatan jaringan kita. Ana pusat data, ana rak sing ngadeg, ana lilin. Kabeh iki bisa disambungake maneh, dipindhah, lan liya-liyane. Iki kabeh uga kudu digatekake. Jeneng IP ganti, routing liwat lalu lintas kita ganti. Iki uga kudu dijupuk menyang akun.
Jaringan uga bisa owah saka segi peralatan. Saka praktik, aku bisa ujar manawa insinyur jaringan kita seneng banget nganyari babagan lilin. Dumadakan perangkat kukuh anyar metu lan padha ora utamané kasengsem ing sawetara klompok Hadoop. Padha duwe gaweyan dhewe. Kanggo wong-wong mau, sing utama yaiku Jaringan bisa digunakake. Patut, padha arep maneh upload soko ana, apa sumunar ing hardware, lan hardware uga diganti periodik. Kabeh iki piye wae kudu dianggep. Kabeh iki mengaruhi aplikasi sing disebarake.
Biasane wong-wong sing miwiti nggarap data sing akeh amarga sawetara alasan percaya yen Internet ora ana watesan. Yen ana file sawetara terabyte ing kana, sampeyan bisa njupuk menyang server utawa komputer lan mbukak kanthi nggunakake kucing lan nonton. Kesalahan liyane ana ing Vim ndeleng log. Aja nglakoni iki amarga iku ala. Amarga Vim nyoba kanggo buffer kabeh, mbukak kabeh menyang memori, utamané nalika kita miwiti obah liwat log iki lan looking for soko. Iki bab sing lali, nanging worth considering.
Iku luwih gampang kanggo nulis siji program sing mlaku ing siji komputer karo siji prosesor.
Nalika sistem kita tuwuh, kita pengin parallelize kabeh, lan parallelize ora mung ing komputer, nanging uga ing kluster. Pitakonan muncul: carane koordinasi prakara iki? Aplikasi kita bisa uga ora sesambungan karo siji liyane, nanging kita nindakake sawetara proses kanthi paralel ing sawetara server. Lan kepiye carane ngawasi manawa kabeh wis apik kanggo dheweke? Contone, padha ngirim soko liwat Internet. Dheweke kudu nulis babagan negarane ing endi wae, contone, ing sawetara jinis database utawa log, banjur gabungke log iki banjur analisa ing endi wae. Kajaba iku, kita kudu nganggep manawa proses kasebut bisa digunakake lan bisa digunakake, dumadakan ana sawetara kesalahan utawa nabrak, banjur sepira cepet kita bakal ngerti babagan iki?
Cetha yen kabeh iki bisa dipantau kanthi cepet. Iki uga apik, nanging ngawasi minangka winates sing ngidini sampeyan ngawasi sawetara perkara ing tingkat paling dhuwur.
Nalika kita pengin proses kita wiwit sesambungan karo saben liyane, contone, kanggo ngirim saben liyane sawetara data, banjur pitakonan uga muncul - carane iki bakal kelakon? Apa bakal ana sawetara kondisi balapan, bakal padha nimpa saben liyane, bakal data teka kanthi bener, apa bakal ilang ing dalan? Kita kudu ngembangake sawetara jinis protokol, lsp.
Koordinasi kabeh proses kasebut dudu perkara sing ora pati penting. Lan meksa pangembang mudhun kanggo tingkat malah ngisor, lan nulis sistem salah siji saka ngeruk, utawa ora cukup saka ngeruk, nanging iki ora supaya prasaja.
Yen sampeyan teka karo algoritma kriptografi utawa malah ngleksanakake, banjur uncalan langsung, amarga paling kamungkinan iku ora bakal bisa kanggo sampeyan. Iku bakal paling kamungkinan ngemot Bunch saka kasalahan sing kelalen kanggo nyedhiyani kanggo. Aja digunakake kanggo apa wae sing serius amarga kemungkinan bakal ora stabil. Amarga kabeh algoritma sing ana wis dites dening wektu kanggo wektu sing suwe banget. Iku diganggu dening masyarakat. Iki minangka topik sing kapisah. Lan ing kene padha. Yen sampeyan ora bisa nindakake sawetara sinkronisasi proses dhewe, mula luwih becik ora nindakake iki, amarga cukup rumit lan ndadékaké sampeyan mudhun ing dalan sing goyah kanthi terus-terusan nggoleki kesalahan.
Dina iki kita ngomong babagan ZooKeeper. Ing tangan siji, iku framework, ing tangan liyane, iku layanan sing nggawe urip luwih gampang kanggo pangembang lan simplifies implementasine saka logika lan koordinasi pangolahan kita sabisa.
Ayo elinga kaya apa sistem distribusi standar. Iki sing diomongake - HDFS, HBase. Ana proses Master sing ngatur buruh lan proses budak. Dheweke tanggung jawab kanggo koordinasi lan nyebarake tugas, miwiti maneh buruh, ngluncurake tugas anyar, lan nyebarake beban.
Bab sing luwih maju yaiku Layanan Koordinasi, yaiku, mindhah tugas koordinasi dhewe menyang proses sing kapisah, plus mbukak sawetara serep utawa stanby Master kanthi podo karo, amarga Master bisa gagal. Lan yen Master tiba, banjur sistem kita ora bakal bisa. Kita mlaku serep. Sawetara nyatakake yen Master kudu ditiru kanggo serep. Iki uga bisa dipasrahake menyang Layanan Koordinasi. Nanging ing diagram iki, Master dhewe tanggung jawab kanggo koordinasi buruh ing kene layanan koordinasi kegiatan replikasi data.
Pilihan sing luwih maju yaiku nalika kabeh koordinasi ditangani dening layanan kita, kaya biasane. Dheweke tanggung jawab kanggo mesthekake yen kabeh bisa digunakake. Lan yen ana sing ora bisa, kita ngerteni babagan iki lan nyoba ngatasi kahanan iki. Ing kasus apa wae, kita ditinggalake karo Master sing bisa sesambungan karo budak lan bisa ngirim data, informasi, pesen, lan liya-liyane liwat sawetara layanan.
Ana skema sing luwih maju, nalika kita ora duwe Master, kabeh simpul dadi abdi master, beda-beda ing prilaku. Nanging dheweke isih kudu sesambungan, mula isih ana sawetara layanan kanggo koordinasi tumindak kasebut. Mbokmenawa, Cassandra, sing nggarap prinsip iki, cocog karo skema iki.
Iku angel ngomong endi saka rencana iki luwih apik. Saben duwe pro lan cons dhewe.
Lan ora perlu wedi marang sawetara perkara karo Guru, amarga, minangka praktik nuduhake, dheweke ora rentan kanggo terus-terusan ngladeni. Ingkang utama ing kene yaiku milih solusi sing tepat kanggo hosting layanan iki ing simpul kuat sing kapisah, supaya nduweni sumber daya sing cukup, supaya yen bisa, pangguna ora duwe akses ing kana, supaya ora sengaja mateni proses iki. Nanging ing wektu sing padha, ing skema kasebut luwih gampang kanggo ngatur buruh saka proses Master, yaiku skema iki luwih gampang saka sudut pandang implementasine.
Lan skema iki (ing ndhuwur) bisa uga luwih rumit, nanging luwih dipercaya.
Masalah utama yaiku kegagalan parsial. Contone, nalika kita ngirim pesen liwat Jaringan, ana sawetara kacilakan, lan sing ngirim pesen ora ngerti apa pesen kasebut ditampa lan apa sing kedadeyan ing sisih panrima, ora bakal ngerti manawa pesen kasebut diproses kanthi bener. , IE ora bakal nampa konfirmasi sembarang.
Mulane, kita kudu ngolah kahanan iki. Lan sing paling gampang yaiku ngirim pesen iki lan ngenteni nganti entuk tanggapan. Ing kasus iki, iku ora dijupuk menyang akun apa negara panrima wis diganti. Kita bisa ngirim pesen lan nambah data sing padha kaping pindho.
ZooKeeper nawakake cara kanggo ngatasi penolakan kasebut, sing uga nggawe urip luwih gampang.
Kaya sing kasebut sadurunge, iki padha karo nulis program multi-threaded, nanging prabédan utama yaiku ing aplikasi sing disebarake sing dibangun ing mesin sing beda-beda, siji-sijine cara kanggo komunikasi yaiku Jaringan. Ateges, iki minangka arsitektur sing ora dienggo bareng. Saben proses utawa layanan sing mlaku ing siji mesin duwe memori dhewe, disk dhewe, prosesor dhewe, sing ora dienggo bareng karo sapa wae.
Yen kita nulis program multi-threaded ing siji komputer, banjur kita bisa nggunakake memori sambungan kanggo ijol-ijolan data. Kita duwe switch konteks ana, pangolahan bisa ngalih. Iki mengaruhi kinerja. Ing tangan siji, ora ana ing program ing kluster, nanging ana masalah karo Jaringan.
Mulane, masalah utama sing muncul nalika nulis sistem sing disebarake yaiku konfigurasi. Kita nulis sawetara jinis aplikasi. Yen prasaja, banjur kita hardcode kabeh jinis nomer ing kode, nanging iki ora trep, amarga yen kita mutusaké sing tinimbang wektu entek setengah detik kita pengin wektu entek siji detik, banjur kita kudu recompile aplikasi lan muter kabeh metu maneh. Iku salah siji bab nalika ing siji mesin, nalika sampeyan mung bisa miwiti maneh, nanging nalika kita duwe akeh mesin, kita kudu terus-terusan nyalin kabeh. Kita kudu nyoba nggawe aplikasi bisa dikonfigurasi.
Ing kene kita ngomong babagan konfigurasi statis kanggo proses sistem. Iki ora kabeh, bisa uga saka sudut pandang sistem operasi, bisa uga dadi konfigurasi statis kanggo proses kita, yaiku, iki minangka konfigurasi sing ora bisa dijupuk lan dianyari.
Ana uga konfigurasi dinamis. Iki minangka paramèter sing pengin kita ganti kanthi cepet supaya bisa dijupuk ing kana.
Apa masalah ing kene? We nganyari config, mbalek metu, supaya apa? Masalah bisa uga ing tangan siji kita mbalek metu config, nanging kelalen bab anyar, config tetep ana. Sareh, nalika kita muter metu, konfigurasi dianyari ing sawetara panggonan, nanging ora ing liyane. Lan sawetara pangolahan aplikasi kita sing mlaku ing siji mesin diwiwiti maneh karo konfigurasi anyar, lan nang endi wae karo sing lawas. Iki bisa nyebabake aplikasi sing disebarake ora konsisten saka perspektif konfigurasi. Masalah iki umum. Kanggo konfigurasi dinamis, iku luwih cocog amarga iku gawe katut sing bisa diganti ing fly.
Masalah liyane yaiku anggota grup. Kita mesthi duwe sawetara set buruh, kita mesthi pengin ngerti sapa sing isih urip, sapa sing wis mati. Yen ana Master, mula dheweke kudu ngerti buruh sing bisa dialihake menyang klien supaya bisa ngetung utawa nggarap data, lan sing ora bisa. Masalah sing terus-terusan muncul yaiku kita kudu ngerti sapa sing kerja ing kluster kita.
Masalah khas liyane yaiku pemilihan pimpinan, nalika kita pengin ngerti sapa sing tanggung jawab. Salah sawijining conto yaiku replikasi, nalika kita duwe sawetara proses sing nampa operasi nulis lan banjur diulang ing antarane proses liyane. Dheweke bakal dadi pimpinan, kabeh wong bakal manut marang dheweke. Sampeyan kudu milih proses supaya ora ambigu kanggo saben wong, supaya ora dadi loro pimpinan sing dipilih.
Ana uga akses eksklusif. Masalah ing kene luwih rumit. Ana bab kuwi minangka mutex, nalika sampeyan nulis program multi-Utas lan pengin akses kanggo sawetara sumber, contone, sel memori, diwatesi lan digawa metu dening mung siji thread. Ing kene sumber bisa dadi luwih abstrak. Lan aplikasi sing beda-beda saka macem-macem simpul Jaringan kita mung kudu nampa akses eksklusif menyang sumber sing diwenehake, lan ora supaya saben wong bisa ngganti utawa nulis apa wae ing kana. Iki sing disebut kunci.
ZooKeeper ngijini sampeyan kanggo ngatasi kabeh masalah iki kanggo siji gelar utawa liyane. Lan aku bakal nuduhake kanthi conto carane ngidini sampeyan nindakake iki.
Ora ana primitif pamblokiran. Nalika kita miwiti nggunakake soko, primitif iki ora bakal ngenteni kedadeyan apa wae. Paling kamungkinan, bab iki bakal bisa asynchronously, saéngga proses ora macet nalika lagi nunggu soko. Iki minangka bab sing migunani banget.
Kabeh panjalukan klien diproses miturut urutan antrian umum.
Lan klien duwe kesempatan kanggo nampa kabar babagan owah-owahan ing sawetara negara, babagan owah-owahan data, sadurunge klien ndeleng data sing diganti dhewe.
ZooKeeper bisa beroperasi ing rong mode. Sing pertama mandiri, ing siji node. Iki trep kanggo uji coba. ZooKeeper uga bisa beroperasi ing mode kluster, ing pirang-pirang node. serverYen kita duwe kluster 100 mesin, ora mesthi kudu mlaku ing 100 mesin. Cukup kanggo ngalokasikan sawetara mesin ing ngendi ZooKeeper bisa mlaku. Lan netepi prinsip kasedhiyan dhuwur. ZooKeeper nyimpen salinan data lengkap ing saben instansi sing mlaku. Aku bakal nerangake kepiye carane nindakake iki mengko. Ora misahake utawa mbagi data. Ing sisih siji, iki minangka kerugian amarga kita ora bisa nyimpen akeh, nanging ing sisih liya, ora perlu. Ora dirancang kanggo kuwi; dudu database.
Data bisa di-cache ing sisih klien. Iki minangka prinsip standar supaya kita ora ngganggu layanan kasebut lan ora ngemot panjaluk sing padha. Klien sing pinter biasane ngerti babagan iki lan cache.
Contone, ana sing diganti ing kene. Ana sawetara jinis aplikasi. Pimpinan anyar dipilih, sing tanggung jawab, contone, kanggo ngolah operasi nulis. Lan kita pengin niru data. Salah sijine solusi yaiku sijine ing daur ulang. Lan kita terus takon layanan kita - apa ana sing diganti? Pilihan kapindho luwih optimal. Iki minangka mekanisme jam tangan sing ngidini sampeyan ngabari klien yen ana sing wis diganti. Iki minangka cara sing luwih murah babagan sumber daya lan luwih trep kanggo klien.
Klien minangka pangguna sing nggunakake ZooKeeper.
Server minangka proses ZooKeeper dhewe.
Znode minangka kunci ing ZooKeeper. Kabeh znode disimpen ing memori dening ZooKeeper lan diatur ing wangun diagram hirarkis, ing wangun wit.
Ana rong jinis operasi. Kapisan yaiku nganyari / nulis, nalika sawetara operasi ngganti kahanan wit kita. Wit iku umum.
Lan bisa uga klien ora ngrampungake siji panjalukan lan pedhot, nanging bisa nggawe sesi sing bisa sesambungan karo ZooKeeper.
Model data ZooKeeper meh padha karo sistem file. Ana ROOT standar lan banjur kita tindak kaya liwat direktori sing pindhah saka ROOT. Lan banjur katalog tingkat pisanan, tingkat kapindho. Iki kabeh znodes.
Saben znode bisa nyimpen sawetara data, biasane ora gedhe banget, contone, 10 kilobyte. Lan saben znode bisa duwe sawetara anak.
Znodes teka ing sawetara jinis. Padha bisa digawe. Lan nalika nggawe znode, kita nemtokake jinis sing kudu ana.
Ana rong jinis. Sing pisanan yaiku gendera ephemeral. Znode urip ing sesi. Contone, klien wis nggawe sesi. Lan anggere sesi iki isih urip, bakal ana. Iki perlu supaya ora ngasilake barang sing ora perlu. Iki uga cocog kanggo wektu nalika penting kanggo nyimpen primitif data ing sawijining sesi.
Jinis kapindho yaiku gendéra urutan. Iku nambah counter ing cara kanggo znode ing. Contone, kita duwe direktori karo aplikasi 1_5. Lan nalika kita nggawe simpul pisanan, nampa p_1, kaloro - p_2. Lan nalika kita nelpon cara iki saben wektu, kita pass path lengkap, nuduhake mung bagean saka path, lan nomer iki kanthi otomatis incremented amarga kita nunjukaké jinis simpul - sequential.
Biasa wae. Dheweke bakal tansah urip lan duwe jeneng sing kita pitutur marang dheweke.
Bab liya sing migunani yaiku gendéra jam tangan. Yen kita instal, banjur klien bisa langganan sawetara acara kanggo simpul tartamtu. Aku bakal nuduhake sampeyan mengko karo conto carane iki rampung. ZooKeeper dhewe ngabari klien yen data ing simpul wis diganti. Nanging, kabar ora njamin yen sawetara data anyar wis teka. Dheweke mung ujar manawa ana sing wis owah, dadi sampeyan isih kudu mbandhingake data mengko karo telpon sing kapisah.
Lan kaya sing wis dakkandhakake, urutan data ditemtokake dening kilobyte. Ora perlu nyimpen data teks gedhe ing kana, amarga dudu database, iku server koordinasi aksi.
Ayo kula critakake sethithik babagan sesi. Yen kita duwe sawetara server, kita bisa kanthi transparan ngalih saka siji server menyang server liyane. pelayan, nggunakake ID sesi. Iki cukup trep.
Saben sesi duwe sawetara wektu entek. Sesi ditetepake manawa klien ngirim apa wae menyang server sajrone sesi kasebut. Yen dheweke ora ngirim apa-apa sajrone wektu entek, sesi kasebut mandheg, utawa klien bisa nutup dhewe.
Ora akeh fitur, nanging sampeyan bisa nindakake perkara sing beda karo API iki. Telpon sing kita weruh nggawe nggawe znode lan njupuk telung paramèter. Iki minangka path menyang znode, lan kudu kasebut kanthi lengkap saka oyod. Lan uga iki sawetara data sing arep kita transfer ana. Lan jinis gendera. Lan sawise nggawe ngasilake dalan menyang znode.
Kapindho, sampeyan bisa mbusak. Trik ing kene yaiku parameter kapindho, saliyane path menyang znode, bisa nemtokake versi. Mulane, znode kasebut bakal dibusak yen versi sing ditransfer padha karo sing bener-bener ana.
Yen kita ora pengin mriksa versi iki, kita mung ngliwati argumen "-1".
Katelu, mriksa anane znode. Ngasilake bener yen simpul ana, salah yen ora.
Lan banjur watch flag katon, sing ngijini sampeyan kanggo ngawasi simpul iki.
Sampeyan bisa nyetel gendera iki sanajan ing simpul sing ora ana lan nampa kabar nalika katon. Iki uga bisa migunani.
A saperangan liyane tantangan getData. Cetha yen kita bisa nampa data liwat znode. Sampeyan uga bisa nggunakake flag watch. Ing kasus iki, ora bakal diinstal yen ora ana simpul. Mulane, sampeyan kudu ngerti manawa ana, banjur nampa data.
Ana uga SetData. Kene kita pass versi. Lan yen kita ngliwati iki, data ing znode versi tartamtu bakal dianyari.
Sampeyan uga bisa nemtokake "-1" kanggo ngilangi mriksa iki.
Cara liya sing migunani yaiku njalukBocah. Kita uga bisa njaluk dhaptar kabeh znode sing dadi kagungane. Kita bisa ngawasi iki kanthi nyetel watch flag.
Lan metode nyelarasake ngidini kabeh owah-owahan dikirim bebarengan, saéngga mesthekake yen padha disimpen lan kabeh data wis rampung diganti.
Yen kita nggambar analogi karo pemrograman biasa, banjur nalika sampeyan nggunakake cara kayata nulis, sing nulis soko menyang disk, lan sawise menehi respon kanggo sampeyan, ora ana jaminan yen sampeyan wis nulis data menyang disk. Lan sanajan sistem operasi yakin yen kabeh wis ditulis, ana mekanisme ing disk dhewe ing ngendi proses kasebut liwat lapisan buffer, lan mung sawise data kasebut diselehake ing disk.
Biasane telpon asinkron digunakake. Iki ngidini klien bisa kerja sejajar karo panjaluk sing beda. Sampeyan bisa nggunakake pendekatan sinkron, nanging kurang produktif.
Operasi loro sing diomongake yaiku nganyari / nulis, sing ngganti data. Iki nggawe, setData, sinkronisasi, mbusak. Lan maca ana, getData, getChildren.
Saiki sawetara conto carane sampeyan bisa nggawe primitif kanggo nggarap sistem sing disebarake. Contone, related kanggo konfigurasi soko. Pegawe anyar wis katon. We nambah mesin lan miwiti proses. Lan ana telung pitakonan ing ngisor iki. Kepiye carane njaluk ZooKeeper kanggo konfigurasi? Lan yen kita pengin ngganti konfigurasi, kepiye carane ngganti? Lan sawise kita ngganti, kepiye para pekerja sing wis entuk?
ZooKeeper ndadekake iki relatif gampang. Contone, ana wit znode kita. Ana simpul kanggo aplikasi kita ing kene, kita nggawe simpul tambahan ing kono, sing ngemot data saka konfigurasi. Iki bisa uga ora dadi paramèter sing kapisah. Amarga ukurane cilik, ukuran konfigurasi biasane uga cilik, saengga bisa disimpen ing kene.
Sampeyan nggunakake cara getData kanggo njaluk konfigurasi kanggo buruh saka simpul. Setel kanggo bener. Yen sakperangan alesan simpul iki ora ana, kita bakal dilaporake babagan nalika katon, utawa nalika owah-owahan. Yen kita pengin ngerti yen ana sing wis owah, banjur kita nyetel dadi bener. Lan yen data ing simpul iki diganti, kita bakal ngerti babagan iki.
SetData. Kita nyetel data, nyetel "-1", i.e. kita ora mriksa versi, kita nganggep yen kita tansah duwe siji konfigurasi, kita ora perlu kanggo nyimpen akeh konfigurasi. Yen sampeyan kudu nyimpen akeh, sampeyan kudu nambah level liyane. Ing kene kita percaya yen mung ana siji, mula kita nganyari mung sing paling anyar, supaya ora mriksa versi kasebut. Ing wektu iki, kabeh klien sing wis langganan sadurunge nampa kabar yen ana sing wis diganti ing simpul iki. Lan sawise nampa, dheweke uga kudu njaluk data maneh. Kabar kasebut ora nampa data kasebut dhewe, nanging mung kabar babagan owah-owahan. Sawise iki, dheweke kudu njaluk data anyar.
Pilihan kapindho kanggo nggunakake primitif yaiku anggota klompok. Kita duwe aplikasi sing disebarake, ana akeh buruh lan kita pengin ngerti manawa kabeh ana ing papan. Mula, dheweke kudu ndhaptar awake dhewe yen dheweke kerja ing aplikasi kita. Lan kita uga pengin ngerteni, saka proses Master utawa ing papan liya, babagan kabeh buruh aktif sing saiki ana.
Kepiye carane nindakake iki? Kanggo aplikasi kasebut, kita nggawe simpul buruh lan nambah sublevel ing kana nggunakake metode nggawe. Aku duwe kesalahan ing geser. Kene sampeyan kudu runtut nemtokake, banjur kabeh buruh bakal digawe siji-siji. Lan aplikasi kasebut, njaluk kabeh data babagan bocah-bocah saka simpul iki, nampa kabeh buruh aktif sing ana.
Iki minangka implementasine sing nggegirisi babagan carane bisa ditindakake ing kode Jawa. Ayo miwiti saka pungkasan, kanthi cara utama. Iki kelas kita, ayo nggawe metode. Minangka argumen pisanan sing digunakake host, ing ngendi kita nyambungake, yaiku kita nyetel minangka argumen. Lan argumentasi kapindho yaiku jeneng grup.
Kepiye sambungan kasebut kedadeyan? Iki minangka conto prasaja saka API sing digunakake. Kabeh iku relatif prasaja kene. Ana ZooKeeper kelas standar. We pass sarwa dumadi menyang. Lan nyetel wektu entek, contone, kanggo 5 detik. Lan kita duwe anggota sing diarani connectedSignal. Ateges, kita nggawe grup ing sadawane dalan sing ditularake. Kita ora nulis data ana, sanajan ana sing bisa ditulis. Lan simpul ing kene minangka jinis sing terus-terusan. Ateges, iki minangka simpul biasa biasa sing bakal ana ing salawas-lawase. Iki ngendi sesi digawe. Iki minangka implementasine saka klien dhewe. Klien kita bakal dilaporake kanthi periodik yen sesi kasebut urip. Lan nalika kita mungkasi sesi, kita nelpon cedhak lan iku, sesi tiba mati. Iki yen ana kedadeyan kanggo kita, supaya ZooKeeper ngerti babagan iki lan ngethok sesi kasebut.
Carane ngunci sumber daya? Ing kene kabeh luwih rumit. Kita duwe sakumpulan buruh, ana sawetara sumber daya sing pengin dikunci. Kanggo nindakake iki, kita nggawe simpul kapisah, contone, disebut lock1. Yen kita bisa nggawe, banjur kita entuk kunci ing kene. Lan yen kita ora bisa nggawe, banjur buruh nyoba njaluk getData saka kene, lan wiwit simpul wis digawe, banjur kita sijine watcher kene lan wayahe negara simpul iki diganti, kita bakal ngerti bab iku. Lan kita bisa nyoba duwe wektu kanggo nggawe maneh. Yen kita njupuk simpul iki, njupuk kunci iki, banjur sawise kita ora butuh kunci maneh, kita bakal ninggalake, amarga simpul mung ana ing sesi kasebut. Mangkono, iku bakal ilang. Lan klien liyane, ing kerangka sesi liyane, bakal bisa njupuk kunci ing simpul iki, utawa luwih, dheweke bakal nampa kabar yen ana sing wis diganti lan bisa nyoba nindakake ing wektu.
Conto liyane babagan carane sampeyan bisa milih pimpinan utama. Iki rada rumit, nanging uga relatif prasaja. Apa sing kedadeyan ing kene? Ana simpul utama sing nglumpukake kabeh buruh. Kita nyoba golek data babagan pimpinan. Yen iki kedadeyan kanthi sukses, yaiku kita nampa sawetara data, mula buruh kita wiwit ngetutake pimpinan iki. Dheweke percaya yen wis ana pimpinan.
Yen pimpinan mati amarga sawetara alasan, contone, tiba, banjur nyoba nggawe pimpinan anyar. Lan yen kita sukses, buruh kita dadi pimpinan. Lan yen ana wong ing wektu iki bisa nggawe pimpinan anyar, banjur kita nyoba kanggo ngerti sapa iku lan banjur tindakake.
Ing ngriki timbul ingkang dipunsebat herd effect, inggih menika efek herd, amargi menawi pimpinan seda, ingkang langkung rumiyin dados pimpinan.
Nalika njupuk sumber daya, sampeyan bisa nyoba nggunakake pendekatan sing rada beda, yaiku kaya ing ngisor iki. Contone, kita pengin njaluk kunci, nanging tanpa efek hert. Iki bakal kalebu kasunyatan manawa aplikasi kita njaluk dhaptar kabeh id simpul kanggo simpul sing wis ana kanthi kunci. Lan yen sadurunge simpul sing digawe kunci minangka sing paling cilik saka set sing ditampa, mula iki tegese kita wis nyekel kunci kasebut. Kita priksa manawa kita wis nampa kunci. Minangka mriksa, bakal ana syarat yen id sing ditampa nalika nggawe kunci anyar minimal. Lan yen kita nampa, banjur kita bisa luwih.
Yen ana id tartamtu sing luwih cilik tinimbang kunci kita, banjur kita sijine watcher ing acara iki lan ngenteni kabar nganti ana owah-owahan. Sing, kita nampa kunci iki. Lan nganti tiba, kita ora bakal dadi id minimal lan ora bakal nampa kunci minimal, lan kanthi mangkono kita bakal bisa mlebu. Lan yen kondisi iki ora ketemu, banjur kita langsung menyang kene lan nyoba kanggo njaluk kunci iki maneh, amarga ana sawetara owah-owahan ing wektu iki.
Apa ZooKeeper kalebu? Ana 4 perkara utama. Iki proses pangolahan - Request. Lan uga ZooKeeper Atomic Broadcast. Ana Log Komit ing ngendi kabeh operasi direkam. Lan Ing-memori Replicated DB dhewe, IE database dhewe ngendi kabeh wit iki disimpen.
Wigati dicathet yen kabeh operasi nulis liwat Prosesor Request. Lan maca operasi langsung menyang database Ing-memori.
Basis data dhewe wis direplikasi kanthi lengkap. Kabeh kedadean saka ZooKeeper nyimpen salinan lengkap data.
Kanggo mulihake database sawise kacilakan, ana log Komit. Praktek standar yaiku sadurunge data mlebu ing memori, ditulis ing kono supaya yen tubrukan, log iki bisa diputer maneh lan negara sistem bisa dipulihake. Lan snapshot periodik saka database uga digunakake.
ZooKeeper Atomic Broadcast minangka barang sing digunakake kanggo njaga data replika.
ZAB internal milih pimpinan saka titik tampilan simpul ZooKeeper. Kelenjar liyane dadi pandherekipun lan ngarepake sawetara tumindak saka dheweke. Yen dheweke nampa entri, dheweke ngirim kabeh menyang pimpinan. Dheweke pisanan nindakake operasi nulis lan banjur ngirim pesen babagan apa sing wis diganti karo para pengikute. Iki, nyatane, kudu ditindakake kanthi atom, yaiku operasi rekaman lan siaran kabeh kudu ditindakake kanthi atom, saengga njamin konsistensi data.
Iku mung proses nulis panjalukan. Tugas utamane yaiku ngowahi operasi dadi nganyari transaksional. Iki minangka panjaluk sing digawe khusus.
Lan ing kene kudu dicathet yen idempotensi nganyari kanggo operasi sing padha dijamin. Opo iki? Bab iki, yen dieksekusi kaping pindho, bakal duwe negara sing padha, yaiku panjaluk kasebut ora bakal diganti. Lan iki kudu ditindakake supaya yen ana kacilakan, sampeyan bisa miwiti maneh operasi, kanthi mangkono mbaleni owah-owahan sing wis ilang. Ing kasus iki, negara sistem bakal dadi padha, IE ngirim ora dadi cilik sing seri padha, contone, nganyari pangolahan, mimpin kanggo negara final beda saka sistem.
Source: www.habr.com
