Hello! Jenengku Alexey Pyankov, aku dadi pangembang ing perusahaan Sportmaster. Ing iku Aku marang carane karya ing situs web Sportmaster wiwit ing 2012, apa inisiatif kita ngatur kanggo "push liwat" lan kosok balene, apa rake kita diklumpukake.
Dina iki aku pengin nuduhake pikirane sing ngetutake topik liyane - milih sistem caching kanggo backend java ing panel admin situs. Plot iki duwe makna khusus kanggo aku - sanajan critane mung 2 wulan, sajrone 60 dina iki kita kerja 12-16 jam lan tanpa dina libur. Aku ora tau mikir utawa mbayangno yen bisa kerja keras.
Mula, teks kasebut dipérang dadi 2 bagean supaya ora mbukak kanthi lengkap. Kosok baline, bagean pisanan bakal entheng banget - persiapan, introduksi, sawetara pertimbangan babagan apa caching. Yen sampeyan wis dadi pangembang sing berpengalaman utawa wis nggarap cache, saka sisih teknis, kemungkinan ora ana sing anyar ing artikel iki. Nanging kanggo bocah cilik, review cilik kasebut bisa menehi pitutur marang arah sing kudu dideleng yen dheweke nemoni prapatan.
Nalika versi anyar saka situs web Sportmaster dilebokake ing produksi, data kasebut ditampa kanthi cara sing gampang, ora trep banget. Ing basis iki tabel disiapake kanggo versi sadurungé saka situs (Bitrix), kang kudu ditarik menyang ETL, digawa menyang wangun anyar lan enriched karo macem-macem cilik saka sistem rolas liyane. Supaya gambar utawa deskripsi produk anyar katon ing situs kasebut, sampeyan kudu ngenteni nganti dina sabanjure - nganyari mung ing wayah wengi, sapisan dina.
Kaping pisanan, ana akeh kuwatir saka minggu pisanan mlebu produksi sing ora nyenengake kanggo manajer konten minangka sepele. Nanging, sanalika kabeh rampung, pangembangan proyek kasebut terus - sawetara wulan sabanjure, ing awal 2015, kita wiwit aktif ngembangake panel admin. Ing 2015 lan 2016, kabeh mlaku kanthi apik, kita ngeculake kanthi rutin, panel admin nyakup luwih akeh persiapan data, lan kita nyiapake kasunyatan manawa tim kita bakal dipasrahake karo sing paling penting lan rumit - produk. sirkuit (persiapan lengkap lan pangopènan data ing kabeh produk). Nanging ing mangsa panas 2017, sadurungé diluncurake sirkuit komoditas, proyek kasebut bakal nemokake dhewe ing kahanan sing angel banget - amarga ana masalah karo caching. Aku pengin ngomong babagan episode iki ing bagean kapindho publikasi rong bagean iki.
Nanging ing kirim iki aku bakal miwiti saka adoh, aku bakal saiki sawetara pikirane - gagasan bab caching, kang bakal dadi langkah apik kanggo nggulung liwat sadurunge project gedhe.
Nalika tugas caching dumadi
Tugas caching ora mung katon. Kita minangka pangembang, nulis produk piranti lunak lan pengin dikarepake. Yen produk dikarepake lan sukses, pangguna bakal teka. Lan liyane lan liyane teka. Banjur ana akeh pangguna lan banjur prodhuk dadi dimuat banget.
Ing tahap pisanan, kita ora mikir babagan optimasi lan kinerja kode. Sing utama yaiku fungsionalitas, kanthi cepet ngluncurake pilot lan nguji hipotesis. Lan yen beban mundhak, kita pompa wesi. We nambah loro utawa telu, kaping lima, bisa 10 kaping. Nang endi wae ing kene - keuangan ora bakal ngidini maneh. Kaping pirang-pirang pangguna bakal nambah? Ora bakal kaya 2-5-10, nanging yen sukses, bakal saka 100-1000 nganti 100 ewu kaping. Sing, cepet utawa mengko, sampeyan kudu nindakake optimasi.
Ayo dadi ngomong sing sawetara bagéan saka kode (ayo nelpon bagean iki fungsi) njupuk wektu indecently dawa, lan kita arep kanggo ngurangi wektu eksekusi. Fungsi bisa dadi akses menyang database, utawa bisa dadi eksekusi sawetara logika kompleks - sing paling penting yaiku mbutuhake wektu sing suwe kanggo eksekusi. Pira sampeyan bisa nyuda wektu eksekusi? Ing watesan, sampeyan bisa nyuda menyang nul, ora luwih. Kepiye sampeyan bisa nyuda wektu eksekusi dadi nol? Jawaban: ngilangi eksekusi kabeh. Nanging, bali asil langsung. Kepiye carane sampeyan bisa ngerteni asile? Wangsulan: etung utawa goleki nang endi wae. Butuh wektu suwe kanggo ngitung. Lan kanggo Spy iku, contone, kanggo elinga asil sing fungsi diprodhuksi wektu pungkasan nalika disebut karo paramèter padha.
Tegese, implementasine fungsi kasebut ora penting kanggo kita. Cukup ngerti apa parameter asil gumantung. Banjur, yen nilai parameter diwakili ing wangun obyek sing bisa digunakake minangka kunci ing sawetara panyimpenan, banjur asil pitungan bisa disimpen lan diwaca ing wektu sabanjuré diakses. Yen nulis lan maca asil iki luwih cepet tinimbang nglakokake fungsi kasebut, kita duwe bathi babagan kacepetan. Jumlah bathi bisa tekan 100, 1000, lan 100 ewu kaping (10 ^ 5 luwih pangecualian, nanging ing kasus basis sing cukup lagging, bisa uga).
Syarat dhasar kanggo sistem caching
Babagan pisanan sing bisa dadi syarat kanggo sistem caching yaiku kacepetan maca cepet lan, kanthi sithik, kacepetan nulis. Iki bener, nanging mung nganti kita muter metu sistem kanggo produksi.
Ayo dolanan kasus iki.
Contone, kita wis nyedhiyakake beban saiki karo piranti keras lan saiki mboko sithik ngenalake caching. Jumlah pangguna mundhak sethithik, beban mundhak - kita nambah cache cilik, meneng ing kene. Iki terus kanggo sawetara wektu, lan saiki fungsi abot meh ora disebut maneh - kabeh mbukak utama tumiba ing cache. Jumlah pangguna ing wektu iki wis tambah N kaping.
Lan yen sumber hardware awal bisa 2-5 kaping, banjur kanthi bantuan cache, kita bisa nambah kinerja kanthi faktor 10 utawa, ing kasus sing apik, kanthi faktor 100, ing sawetara panggonan bisa uga kanthi faktor. saka 1000. Sing, ing hardware padha - kita proses 100 kaping panjalukan. Apik, sampeyan pantes roti jahe!
Nanging saiki, ing wayahe, kanthi kasempatan, sistem kasebut ambruk lan cache ambruk. Ora ana sing khusus - sawise kabeh, cache dipilih adhedhasar syarat "kacepetan maca lan nulis dhuwur, liyane ora masalah."
Relatif kanggo beban wiwitan, cadangan wesi kita 2-5 kaping, lan beban ing wektu iki tambah 10-100 kali. Nggunakake cache, kita ngilangi telpon kanggo fungsi abot lan mulane kabeh bisa digunakake. Lan saiki, tanpa cache, kakehan sistem kita bakal alon? Apa sing bakal kelakon kanggo kita? Sistem bakal tiba.
Sanajan cache kita ora kacilakan, nanging mung dibuwang sedhela, mula kudu dipanasake, lan butuh sawetara wektu. Lan sajrone wektu iki, beban utama bakal ana ing fungsi.
Kesimpulan: proyek produksi sing akeh dimuat mbutuhake sistem caching ora mung nduweni kecepatan maca lan nulis sing dhuwur, nanging uga kanggo njamin keamanan data lan resistensi kegagalan.
Glepung pilihan
Ing proyek karo panel admin, pilihan dadi kaya iki: pisanan kita nginstal Hazelcast, amarga Kita wis kenal karo produk iki saka pengalaman situs utama. Nanging ing kene pilihan iki ora kasil - miturut profil beban kita, Hazelcast ora mung alon, nanging alon banget. Lan ing wektu iku kita wis ndhaptar tanggal rilis.
Spoiler: kepiye kahanan sing dikembangake manawa kita ora kejawab masalah gedhe lan kedadeyan kanthi kahanan sing akut lan tegang - aku bakal pitutur marang kowe ing bagean kapindho - lan kepiye pungkasane lan kepiye metu. Nanging saiki - aku mung bakal ujar manawa stres banget, lan "kanggo mikir - kepiye wae aku ora bisa mikir, kita goyangake botol." "Goyang botol" uga spoiler, liyane ing mengko.
Apa sing ditindakake:
- Kita nggawe dhaptar kabeh sistem sing disaranake Google lan StackOverflow. Kurang luwih 30
- Kita nulis tes kanthi beban sing khas kanggo produksi. Kanggo nindakake iki, kita ngrekam data sing ngliwati sistem ing lingkungan produksi - jenis sniffer kanggo data ora ing jaringan, nanging ing njero sistem. Persis data iki digunakake ing tes.
- Kanthi kabeh tim, kabeh wong milih sistem sabanjure saka dhaptar, ngatur, lan nganakake tes. Ora lulus tes, ora nggawa beban - kita mbuwang lan pindhah menyang baris sabanjure.
- Ing sistem kaping 17 dadi cetha yen kabeh ora ana pengarep-arep. Aja goyang-goyang botol, wayahe mikir kanthi serius.
Nanging iki minangka pilihan yen sampeyan kudu milih sistem sing bakal "liwat kacepetan" ing tes sing wis disiapake. Kepiye yen durung ana tes kasebut lan sampeyan pengin milih kanthi cepet?
Ayo model pilihan iki (iku angel mbayangno sing tengah + pangembang urip ing vakum, lan ing wektu seleksi durung formal preferensi kanggo produk apa kanggo nyoba pisanan - mulane, pertimbangan luwih saka teori/filosofi/ babagan junior).
Sawise mutusake syarat, kita bakal miwiti milih solusi metu saka kothak. Apa reinvent setir: kita bakal pindhah lan njupuk sistem caching siap-digawe.
Yen sampeyan lagi miwiti lan google, banjur menehi utawa njupuk pesenan, nanging ing umum, pedoman bakal kaya iki. Kaping pisanan, sampeyan bakal nemokake Redis, keprungu ing endi wae. Banjur sampeyan bakal nemokake yen EhCache minangka sistem sing paling tuwa lan paling bukti. Sabanjure kita bakal nulis babagan Tarantool, pangembangan domestik sing nduweni aspek unik saka solusi. Lan uga Ignite, amarga saiki wis dadi popularitas lan seneng dhukungan saka SberTech. Ing pungkasan ana uga Hazelcast, amarga ing donya perusahaan asring katon ing antarane perusahaan gedhe.
Daftar kasebut ora lengkap; ana puluhan sistem. Lan kita mung bakal meneng siji bab. Ayo njupuk sistem 5 sing dipilih kanggo "kontes kecantikan" lan pilih. Sapa sing bakal dadi juara?
Redis
Kita maca apa sing ditulis ing situs web resmi.
- proyek opensource. Nawakake panyimpenan data ing-memori, kemampuan kanggo nyimpen ing disk, partisi otomatis, kasedhiyan dhuwur lan Recovery saka outages jaringan.
Iku misale jek sing kabeh iku nggoleki, sampeyan bisa njupuk lan meneng ing - kabeh sing perlu, iku. Nanging mung kanggo seneng-seneng, ayo katon ing calon liyane.
EhCache
- "cache sing paling akeh digunakake kanggo Jawa" (terjemahan slogan saka situs web resmi). Uga opensource. Banjur kita ngerti yen Redis ora kanggo java, nanging umum, lan kanggo sesambungan karo sampeyan kudu pambungkus. Lan EhCache bakal luwih trep. Apa maneh janji sistem? Keandalan, bukti, fungsionalitas lengkap. Inggih, iku uga paling umum. Lan caches terabyte data.
Redis lali, aku siap milih EhCache.
Nanging rasa patriotisme nyurung aku kanggo ndeleng apa sing apik babagan Tarantool.
Tarantool
- ketemu sebutan "Platform integrasi data wektu nyata". Iku muni rumit banget, supaya kita maca kaca kanthi rinci lan nemokake statement banter: "Cache 100% data ing RAM." Iki kudu nuwuhake pitakon - sawise kabeh, bisa uga ana data luwih akeh tinimbang memori. Panjelasan iku tegese Tarantool ora mbukak serialization kanggo nulis data menyang disk saka memori. Nanging, nggunakake fitur-tingkat kurang saka sistem, nalika memori mung dipetakan menyang sistem file karo I / O kinerja apik banget. Umumé, dheweke nindakake perkara sing apik lan keren.
Ayo ndeleng implementasine: Mail.ru dalan gedhe perusahaan, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...
Yen isih ana keraguan babagan Tarantool, mula kasus implementasine ing Mastercard rampung. Aku njupuk Tarantool.
Nanging piye wae…
ignite
… ana liyane , ditagih minangka "platform komputasi ing memori ... kacepetan ing memori ing petabyte data." Ana uga akeh kaluwihan ing kene: cache ing memori sing disebarake, panyimpenan lan cache nilai kunci paling cepet, skala horisontal, kasedhiyan dhuwur, integritas sing ketat. Umumé, ternyata sing paling cepet yaiku Ignite.
Implementasine: Sberbank, American Airlines, Yahoo! Jepang. Banjur aku ngerteni manawa Ignite ora mung ditindakake ing Sberbank, nanging tim SberTech ngirim wong menyang tim Ignite dhewe kanggo nyaring produk kasebut. Iki pancen nggumunake lan aku siap njupuk Ignite.
Iku rampung cetho kok, Aku looking ing titik kalima.
hazelcast
Aku menyang situs , maca. Lan ternyata solusi paling cepet kanggo caching sing disebarake yaiku Hazelcast. Iki minangka urutan gedhene luwih cepet tinimbang kabeh solusi liyane lan umume minangka pimpinan ing kothak data ing memori. Ing latar mburi iki, kanggo njupuk soko liyane ora kanggo ngormati dhewe. Uga nggunakake panyimpenan data keluwih kanggo operasi terus kluster tanpa mundhut data.
Mekaten, aku siap njupuk Hazelcast.
Perbandingan
Nanging yen dideleng, limang calon kasebut digambarake kanthi cara sing paling apik. Carane milih? Kita bisa ndeleng endi sing paling populer, goleki perbandingan, lan sirah bakal ilang.
Kita nemokake siji kaya iki , pilih 5 sistem kita.
Ing kene padha diurutake: Redis ana ing ndhuwur, Hazelcast ing posisi kaping pindho, Tarantool lan Ignite entuk popularitas, EhCache wis lan tetep padha.
Nanging ayo kang katon ing : pranala menyang situs web, kapentingan umum ing sistem, nawakake proyek - gedhe! Yaiku, nalika sistemku gagal, aku bakal ujar: "Ora, bisa dipercaya! Akeh tawaran kerja… " Perbandhingan prasaja kasebut ora bakal ditindakake.
Kabeh sistem iki ora mung sistem caching. Dheweke uga duwe akeh fungsi, kalebu nalika data ora dipompa menyang klien kanggo diproses, nanging kosok balene: kode sing kudu dieksekusi ing data kasebut pindhah menyang server, dieksekusi ana, lan asil kasebut bali. Lan padha ora asring dianggep minangka sistem kapisah kanggo caching.
Oke, ayo ora nyerah, ayo golek perbandingan langsung saka sistem kasebut. Ayo dadi njupuk rong pilihan ndhuwur - Redis lan Hazelcast. Kita kasengsem ing kacepetan, lan kita bakal mbandhingake adhedhasar parameter iki.
Hz vs Redis
Kita nemokake iki :
Biru iku Redis, abang iku Hazelcast. Hazelcast menang nang endi wae, lan ana alesan kanggo iki: iku multi-Utas, Highly optimized, saben thread dianggo karo partisi dhewe, supaya ora ana pamblokiran. Lan Redis iku siji-Utas; ora entuk manfaat saka CPU multi-inti modern. Hazelcast duwe I / O bedo, Redis-Jedis wis ngalangi soket. Sawise kabeh, Hazelcast nggunakake protokol binar, lan Redis minangka teks-sentris, tegese ora efisien.
Yen ngono, ayo goleki sumber perbandingan liyane. Apa sing bakal dituduhake marang kita?
Redis vs Hz
siji maneh :
Ing kene, sebaliknya, abang yaiku Redis. Yaiku, Redis ngluwihi Hazelcast babagan kinerja. Hazelcast menang perbandingan pisanan, Redis menang nomer loro. diterangake kanthi tepat kenapa Hazelcast menangake perbandingan sadurunge.
Pranyata asil saka pisanan bener rigged: Redis dijupuk ing kothak dhasar, lan Hazelcast iki ngarang kanggo kasus test. Banjur ternyata: pisanan, kita ora bisa dipercaya sapa wae, lan kaping pindho, nalika pungkasane milih sistem, kita isih kudu ngatur kanthi bener. Setelan kasebut kalebu puluhan, meh atusan parameter.
Goyang-goyang botol
Lan aku bisa nerangake kabeh proses sing saiki wis ditindakake kanthi metafora ing ngisor iki: "Goyang botol." Yaiku, saiki sampeyan ora kudu program, saiki sing utama yaiku bisa maca stackoverflow. Lan aku duwe wong ing tim, profesional, sing kerjane kaya iki ing wektu kritis.
Dheweke nyapo? Dheweke ndeleng barang sing rusak, ndeleng jejak tumpukan, njupuk sawetara tembung saka iku (sing dadi keahliane ing program kasebut), nggoleki ing Google, nemokake stackoverflow ing antarane jawaban. Tanpa maca, tanpa mikir, ing antarane jawaban kanggo pitakonan, dheweke milih sing paling mirip karo ukara "nindakake iki lan iki" (milih jawaban kasebut minangka bakat, amarga ora mesthi jawaban sing paling disenengi). ditrapake , katon: yen soko wis diganti, banjur gedhe. Yen durung diganti, gulung maneh. Lan baleni peluncuran-check-search. Lan kanthi cara intuisi iki, dheweke njamin kode kasebut bisa digunakake sawise sawetara wektu. Dheweke ora ngerti kenapa, ora ngerti apa sing ditindakake, ora bisa nerangake. Nanging! Infeksi iki kerjane. Lan "geni wis dipateni". Saiki ayo ngerteni apa sing ditindakake. Nalika program dianggo, iku urutan gedhene luwih gampang. Lan ngirit wektu akeh.
Cara iki diterangake kanthi apik karo conto iki.
Biyen banget populer kanggo ngumpulake prau layar ing botol. Ing wektu sing padha, prau layar gedhe lan rapuh, lan gulu botol kasebut sempit banget, ora bisa didorong ing njero. Carane ngumpul?
Ana cara kasebut, cepet banget lan efektif banget.
Kapal kasebut dumadi saka pirang-pirang barang cilik: teken, tali, layar, lem. Kita sijine kabeh iki ing botol.
Kita njupuk botol nganggo tangan loro lan wiwit goyangake. Kita goyangake lan goyangake dheweke. Lan biasane dadi sampah lengkap, mesthi. Nanging kadhangkala. Kadhangkala dadi kapal! Luwih tepate, kaya kapal.
Kita nuduhake iki marang wong liya: "Seryoga, sampeyan ndeleng!?" Lan pancen, saka kadohan katon kaya kapal. Nanging iki ora bisa diijini terus.
Ana cara liya. Dheweke digunakake dening wong lanang sing luwih maju, kayata peretas.
Aku menehi tugas marang wong iki, dheweke nindakake kabeh lan lunga. Lan sampeyan katon - katon kaya wis rampung. Lan sawise sawetara wektu, nalika kode kudu dirampungake, iki diwiwiti amarga dheweke ... Iku apik yen dheweke wis bisa mlayu adoh. Iki minangka wong lanang sing, nggunakake conto botol, bakal nindakake iki: sampeyan ndeleng, ing endi ngisor, kaca bend. Lan ora sakabehe jelas apa transparan utawa ora. Banjur "peretas" ngethok ngisor iki, nglebokake kapal ing kana, banjur lem ing ngisor maneh, lan kaya-kaya kaya ngono.
Saka sudut pandang nyetel masalah, kabeh katon bener. Nanging nggunakake kapal minangka conto: kenapa nggawe kapal iki, sapa sing butuh? Ora menehi fungsi apa wae. Biasane kapal kasebut minangka hadiah kanggo wong sing duwe pangkat dhuwur, sing dilebokake ing rak ing ndhuwur, minangka simbol, minangka tandha. Lan yen wong kaya ngono, kepala bisnis gedhe utawa pejabat dhuwur, kepiye gendéra bakal ngadeg kanggo hack kaya ngono, gulu sing dipotong? Luwih becik dheweke ora ngerti babagan iki. Dadi, kepiye carane nggawe kapal kasebut sing bisa diwenehake marang wong penting?
Siji-sijine papan kunci sing sampeyan ora bisa nindakake apa-apa yaiku awak. Lan lambung kapal pas menyang gulu. Dene kapal dirakit ing njaba botol. Nanging ora mung ngrakit kapal, iku kerajinan perhiasan nyata. Tuas khusus ditambahake ing komponen, sing banjur bisa diangkat. Contone, layar dilipat, kanthi ati-ati digawa menyang jero, banjur, kanthi bantuan pinset, ditarik lan diunggahake kanthi tepat, kanthi presisi. Asilipun karya seni ingkang saged dipunparingi kalbu ingkang resik lan bangga.
Lan yen kita pengin proyek kasebut sukses, paling ora ana siji tukang perhiasan ing tim kasebut. Sapa sing peduli babagan kualitas produk lan nganggep kabeh aspek, tanpa ngorbanake apa-apa, sanajan ing wektu kaku, nalika kahanan mbutuhake nindakake perkara sing penting kanthi biaya sing penting. Kabeh proyek sukses sing sustainable, sing wis tahan uji wektu, dibangun ing prinsip iki. Ana sing tepat lan unik babagan dheweke, sing njupuk kauntungan saka kabeh kemungkinan sing kasedhiya. Ing conto karo kapal ing botol, kasunyatan sing awak kapal liwat gulu diputer metu.
Bali menyang tugas milih server caching kita, kepiye cara iki bisa ditrapake? Aku nawakake pilihan iki kanggo milih saka kabeh sistem sing ana - aja goyangake botol, aja milih, nanging deleng apa sing ana ing prinsip, apa sing kudu digoleki nalika milih sistem.
Where kanggo nggoleki bottle-neck
Ayo nyoba ora goyangake botol, ora ngliwati kabeh sing ana siji-sijine, nanging ayo ndeleng masalah apa sing bakal kedadeyan yen tiba-tiba, kanggo tugas, ngrancang sistem kasebut dhewe. Mesthi, kita ora bakal ngumpulake mancal, nanging kita bakal nggunakake diagram iki kanggo bantuan kita ngerti apa TCTerms kanggo mbayar manungsa waé kanggo ing gambaran produk. Ayo gawe sketsa diagram kasebut.
Yen sistem disebarake, banjur kita bakal duwe sawetara server (6). Ayo dadi ngomong ana papat (iku trep kanggo nyelehake ing gambar, nanging, mesthi, bisa dadi akeh sing kaya). Yen server ing macem-macem kelenjar, iku ateges sing kabeh mbukak sawetara kode sing tanggung jawab kanggo mesthekake yen kelenjar iki mbentuk kluster lan, ing acara saka break, nyambung lan ngenali saben liyane.
Kita uga butuh logika kode (2), sing sejatine babagan caching. Klien sesambungan karo kode iki liwat sawetara API. Kode klien (1) bisa uga ana ing JVM sing padha utawa ngakses liwat jaringan. Logika sing dileksanakake ing njero yaiku keputusane obyek sing kudu ditinggalake ing cache lan sing dibuwang. Kita nggunakake memori (3) kanggo nyimpen cache, nanging yen perlu, kita bisa nyimpen sawetara data ing disk (4).
Ayo ndeleng ing bagean endi beban bakal kedadeyan. Bener, saben panah lan saben simpul bakal dimuat. Pisanan, antarane kode klien lan api, yen iki komunikasi jaringan, subsidence bisa cukup katon. Sareh, ing framework saka api dhewe - yen kita overdo karo logika Komplek, kita bisa nemu masalah karo CPU. Lan luwih becik yen logika ora mbuwang wektu ing memori. Lan tetep ana interaksi karo sistem file - ing versi biasanipun iki serialize / mulihake lan nulis / maca.
Sabanjure yaiku interaksi karo kluster. Paling kamungkinan, bakal ana ing sistem sing padha, nanging bisa uga kapisah. Kene sampeyan uga kudu njupuk menyang akun transfer data menyang, kacepetan serialization data lan interaksi antarane kluster.
Saiki, ing tangan siji, kita bisa mbayangno "perpindahan apa sing bakal diuripake" ing sistem cache nalika ngolah panjalukan saka kode kita, lan ing sisih liya, kita bisa ngira-ngira apa lan pirang-pirang panjaluk kode sing bakal digawe kanggo sistem iki. Iki cukup kanggo nggawe pilihan sing luwih utawa kurang sober - kanggo milih sistem kanggo kasus panggunaan kita.
hazelcast
Ayo ndeleng carane ngetrapake dekomposisi iki ing dhaptar kita. Contone, Hazelcast.
Kanggo nyelehake / njupuk data saka Hazelcast, kode klien ngakses (1) api. Hz ngijini sampeyan kanggo mbukak server minangka ditempelake, lan ing kasus iki, ngakses api minangka telpon cara nang JVM, kang bisa dianggep free.
Supaya logika ing (2) bisa digunakake, Hz gumantung ing hash array byte saka tombol serialized - yaiku, tombol bakal serialized ing kasus apa wae. Iki minangka overhead sing ora bisa ditindakake kanggo Hz.
Sastranegara eviction dileksanakake uga, nanging kanggo kasus khusus sampeyan bisa nambah dhewe. Sampeyan ora perlu kuwatir babagan bagean iki.
Panyimpenan (4) bisa disambungake. gedhe. Interaksi (5) kanggo embedded bisa dianggep cepet. Ijol-ijolan data antarane simpul ing kluster (6) - ya, ana. Iki minangka investasi ing toleransi kesalahan kanthi biaya kacepetan. Fitur Hz Near-cache ngidini sampeyan nyuda rega - data sing ditampa saka kelenjar liyane ing kluster bakal di-cache.
Apa sing bisa ditindakake ing kahanan kasebut kanggo nambah kacepetan?
Contone, supaya serialization saka tombol ing (2) - masang cache liyane ing ndhuwur Hazelcast, kanggo data monjo. Sportmaster milih Kafein kanggo tujuan iki.
Kanggo twisting ing tingkat (6), Hz nawakake rong jinis panyimpenan: IMap lan ReplicatedMap.
Perlu dicritakake kepiye Hazelcast mlebu tumpukan teknologi Sportmaster.
Ing 2012, nalika kita lagi nggarap pilot pisanan saka situs mangsa, iku Hazelcast sing dadi link pisanan sing mesin telusur bali. Kenalan kasebut diwiwiti "pisanan" - kita kepincut karo kasunyatan sing mung rong jam mengko, nalika kita ngaco Hz menyang sistem, kerjane. Lan kerjane apik. Ing pungkasan dina kita wis rampung sawetara tes lan seneng. Lan cadangan semangat iki cukup kanggo ngatasi kejutan sing dibuwang Hz liwat wektu. Saiki tim Sportmaster ora duwe alesan kanggo ninggalake Hazelcast.
Nanging bantahan kasebut minangka "link pisanan ing mesin telusuran" lan "HelloWorld dirakit kanthi cepet", mesthine minangka pangecualian lan fitur ing wektu sing dipilih. Tes nyata kanggo sistem sing dipilih diwiwiti kanthi rilis menyang produksi, lan ing tahap iki sampeyan kudu menehi perhatian nalika milih sistem apa wae, kalebu cache. Bener, ing kasus kita bisa ngomong yen kita milih Hazelcast kanthi ora sengaja, nanging banjur ternyata kita milih kanthi bener.
Kanggo produksi, luwih penting: ngawasi, nangani kegagalan ing node individu, replikasi data, biaya skala. Sing, iku worth mbayar manungsa waé kanggo tugas sing bakal njedhul sak pangopènan sistem - nalika mbukak sepuluh kaping luwih saka ngrancang, nalika ora sengaja upload soko ing panggonan salah, nalika kita kudu muter versi anyar. saka kode, ngganti data lan nindakake unnoticed kanggo klien.
Kanggo kabeh syarat kasebut, Hazelcast mesthi cocog karo tagihan kasebut.
Kanggo terus
Nanging Hazelcast dudu panacea. Ing 2017, kita milih Hazelcast kanggo cache admin, mung adhedhasar kesan sing apik saka pengalaman kepungkur. Iki nduweni peran kunci ing lelucon sing kejem banget, amarga kita nemoni kahanan sing angel lan "herois" metu saka iku sajrone 60 dina. Nanging luwih akeh babagan ing bagean sabanjure.
Ing sawetoro wektu ... Happy New Code!
Source: www.habr.com