Halo! Ngaran abdi Alexey Pyankov, Kami pamekar di parusahaan Sportmaster. Dina éta Kuring bébéja kumaha gawé dina ramatloka Sportmaster dimimitian dina 2012, naon inisiatif urang junun "nyorong ngaliwatan" jeung sabalikna, naon rake kami dikumpulkeun.
Dinten abdi hoyong bagikeun pikiran anu nuturkeun topik anu sanés - milih sistem cache pikeun backend java dina panel admin situs. Plot ieu ngagaduhan hartos khusus pikeun kuring - sanaos caritana ngan ukur 2 sasih, salami 60 dinten ieu kami damel 12-16 jam sareng tanpa dinten libur. Abdi henteu kantos nginten atanapi ngabayangkeun yén éta tiasa dianggo pisan.
Ku alatan éta, kuring ngabagi téks kana 2 bagian supados henteu ngamuat lengkep. Sabalikna, bagian kahiji bakal pisan lampu - persiapan, bubuka, sababaraha pertimbangan ngeunaan naon cache. Upami anjeun parantos janten pamekar anu berpengalaman atanapi parantos damel sareng cache, tina sisi téknis sigana bakal aya anu énggal dina tulisan ieu. Tapi pikeun SMP, ulasan leutik sapertos kitu tiasa nyarioskeun ka arah mana anu kedah ditingali upami anjeunna mendakan dirina dina parapatan sapertos kitu.
Nalika versi anyar tina ramatloka Sportmaster ieu nempatkeun kana produksi, data ieu ditampi dina cara anu, mun nempatkeun eta mildly, teu pisan merenah. Dasarna nyaéta tabel anu disiapkeun pikeun versi situs sateuacana (Bitrix), anu kedah ditarik kana ETL, dibawa ka bentuk énggal sareng diperkaya ku rupa-rupa hal-hal sakedik tina belasan langkung sistem. Supados gambar atanapi pedaran produk énggal muncul dina situs, anjeun kedah ngantosan dugi ka énjing - apdet ngan ukur wengi, sakali sapoé.
Dina awalna, aya kitu loba worries ti minggu mimiti bade kana produksi nu inconveniences misalna pikeun manajer eusi éta trifle a. Tapi, pas sagalana netep, ngembangkeun proyék dituluykeun - sababaraha bulan engké, dina awal 2015, urang mimitian aktip ngamekarkeun panel admin. Dina 2015 sareng 2016, sadayana bakal lancar, kami ngaleupaskeun rutin, panel admin nyertakeun langkung seueur persiapan data, sareng kami nyiapkeun kanyataan yén pas tim kami bakal dipercayakeun hal anu paling penting sareng kompleks - produk. sirkuit (persiapan lengkep sareng pangropéa data dina sadaya produk). Tapi dina usum panas 2017, ngan méméh peluncuran sirkuit komoditi, proyék bakal manggihan sorangan dina kaayaan hésé pisan - persis alatan masalah cache. Abdi hoyong ngobrol ngeunaan épisode ieu dina bagian kadua publikasi dua bagian ieu.
Tapi dina tulisan ieu kuring bakal ngamimitian ti kajauhan, kuring bakal nampilkeun sababaraha pamikiran - ideu ngeunaan cache, anu bakal janten léngkah anu saé pikeun ngagulung sateuacan proyék ageung.
Nalika tugas cache lumangsung
Tugas cache henteu ngan muncul. Kami pamekar, nyerat produk parangkat lunak sareng hoyong janten paménta. Upami produkna aya dina paménta sareng suksés, pangguna bakal sumping. Sarta beuki loba datang. Teras aya seueur pangguna teras produkna janten sarat pisan.
Dina tahap kahiji, urang teu mikir ngeunaan optimasi jeung kinerja kode. Hal utama nyaéta fungsionalitas, gancang ngaluncurkeun pilot sareng nguji hipotesis. Sareng upami beban naék, kami ngompa beusi. Urang ningkatkeun eta dua atawa tilu kali, lima kali, meureun 10 kali. Di dieu wae - finances moal ngidinan deui. Sabaraha kali jumlah pangguna bakal ningkat? Éta moal sapertos 2-5-10, tapi upami suksés, éta bakal ti 100-1000 dugi ka 100 rébu kali. Nyaeta, sooner atanapi engké, anjeun bakal kudu ngalakukeun optimasi.
Hayu urang nyebutkeun yén sababaraha bagian tina kode (nyaéta nyauran bagian ieu fungsi hiji) nyokot hiji waktu indecently lila, sarta kami rék ngurangan waktu palaksanaan. Hiji fungsi bisa jadi aksés ka database, atawa bisa jadi palaksanaan sababaraha logika kompléks - hal utama nyaéta yén waktu nu diperlukeun lila pikeun ngalengkepan. Sabaraha anjeun tiasa ngirangan waktos palaksanaan? Dina watesna, anjeun tiasa ngirangan kana nol, henteu langkung. Kumaha anjeun tiasa ngirangan waktos palaksanaan janten nol? Jawaban: ngaleungitkeun palaksanaan sakabehna. Gantina, balikkeun hasilna langsung. Kumaha anjeun tiasa terang hasilna? Jawabna: boh itung-itung atawa pilari wae. Butuh waktu lila pikeun ngitung. Jeung nénjo téh, contona, pikeun nginget hasil yén fungsi dihasilkeun panungtungan waktu nalika disebut ku parameter sarua.
Hartina, palaksanaan fungsi éta henteu penting pikeun urang. Ieu cukup ngan uninga kana parameter naon hasilna gumantung. Teras, upami nilai parameter diwakilan dina bentuk obyék anu tiasa dianggo salaku konci dina sababaraha panyimpen, maka hasil itungan tiasa disimpen sareng dibaca nalika diakses salajengna. Lamun tulisan ieu jeung maca hasilna leuwih gancang ti executing fungsi, urang boga untung dina watesan speed. Jumlah kauntungan bisa ngahontal 100, 1000, sarta 100 sarébu kali (10 ^ 5 rada iwal, tapi dina kasus basa rada katinggaleun, éta rada mungkin).
Syarat dasar pikeun sistem cache
Hal kahiji anu tiasa janten sarat pikeun sistem cache nyaéta laju maca gancang sareng, dugi ka sakedik, laju nyerat. Ieu leres, tapi ngan dugi kami gulung kaluar sistem pikeun produksi.
Hayu urang maénkeun kasus ieu.
Anggap urang parantos nyayogikeun beban ayeuna sareng hardware sareng ayeuna sacara bertahap ngenalkeun cache. Jumlah pamaké tumuwuh saeutik, beban tumuwuh - urang nambahkeun caches saeutik, screw eta di ditu di dieu. Ieu dituluykeun pikeun sawatara waktu, sarta ayeuna fungsi beurat praktis teu disebut deui - sakabéh beban utama ragrag kana cache nu. Jumlah pamaké salila ieu geus ngaronjat N kali.
Sareng upami suplai awal hardware tiasa 2-5 kali, maka kalayan bantosan cache urang tiasa ningkatkeun kinerja ku faktor 10 atanapi, dina kasus anu saé, ku faktor 100, di sababaraha tempat sigana ku faktor. ti 1000. Maksudna, dina hardware sarua - urang ngolah 100 kali leuwih requests. Hébat, anjeun pantes roti jahé!
Tapi ayeuna, dina hiji momen alus, ku kasempetan, sistem nabrak jeung cache nu rubuh. Henteu aya anu khusus - saatosna, cache dipilih dumasar kana sarat "kecepatan maca sareng nyerat anu luhur, sésana henteu masalah."
Relatif kana beban awal, cadangan beusi kami 2-5 kali, sareng beban dina waktos ieu ningkat 10-100 kali. Ngagunakeun cache, urang ngaleungitkeun panggero pikeun fungsi beurat sahingga sagalana jalan. Sareng ayeuna, tanpa cache, sabaraha kali sistem urang bakal ngalambatkeun? Naon anu bakal kajadian ka urang? Sistim bakal ragrag.
Malah lamun cache urang teu ngadat, tapi ngan diberesihan sakedap, éta bakal perlu warmed up, sarta ieu bakal butuh sababaraha waktu. Sareng salami ieu, beban utama bakal tumiba kana fungsionalitas.
Kacindekan: proyék-proyék produksi anu sarat pisan ngabutuhkeun sistem cache henteu ngan ukur gaduh kecepatan maca sareng nyerat anu luhur, tapi ogé pikeun mastikeun kasalametan data sareng résistansi kana gagal.
Kasiksa pilihan
Dina proyék sareng panel admin, pilihanna sapertos kieu: mimitina urang dipasang Hazelcast, sabab Kami parantos wawuh sareng produk ieu tina pangalaman situs utama. Tapi di dieu pilihan ieu tétéla gagal - dina profil beban urang, Hazelcast henteu ngan slow, tapi pisan slow. Sareng dina waktos éta kami parantos ngadaptarkeun tanggal sékrési.
Spoiler: kumaha persisna kaayaan dikembangkeun yén urang sono pisan sareng ditungtungan ku kaayaan anu akut sareng tegang - kuring bakal nyarioskeun ka anjeun dina bagian kadua - sareng kumaha urang réngsé sareng kumaha urang kaluar. Tapi ayeuna - kuring ngan bakal nyarios yén éta seueur setrés, sareng "pikeun mikir - kumaha waé kuring henteu tiasa mikir, urang ngoyagkeun botol." "Ngoyagkeun botol" ogé spoiler, langkung seueur ngeunaan éta engké.
Naon anu urang lakukeun:
- Kami ngadamel daptar sadaya sistem anu disarankeun ku Google sareng StackOverflow. Saeutik leuwih 30
- Urang nulis tés kalawan beban has pikeun produksi. Jang ngalampahkeun ieu, urang dirékam data nu ngaliwatan sistem dina lingkungan produksi - jenis sniffer pikeun data teu dina jaringan, tapi di jero sistem. Persis data ieu dipaké dina tés.
- Sareng sadaya tim, sadayana milih sistem salajengna tina daptar, ngonpigurasikeunana, sareng ngajalankeun tés. Teu lulus ujian, teu mawa beban - urang buang jauh jeung ngaléngkah ka hareup dina garis.
- Dina sistem 17 janten jelas yén sagalana éta harepan. Eureun ngoyagkeun botol, geus waktuna pikeun mikir serius.
Tapi ieu mangrupikeun pilihan nalika anjeun kedah milih sistem anu bakal "ngalangkungan laju" dina tés anu tos disiapkeun. Kumaha upami teu acan aya tés sapertos kitu sareng anjeun badé milih gancang?
Hayu urang model pilihan ieu (hésé ngabayangkeun yén pamekar tengah + hirup dina vakum, sarta dina waktu seleksi teu acan formalized leuwih sering dipake tinimbang na kana produk mana coba munggaran - ku kituna, penalaran salajengna leuwih ti hiji teoritis / filsafat / ngeunaan hiji junior).
Sanggeus mutuskeun dina sarat, urang bakal ngawitan milih solusi out of the box. Naha reinvent kabayang: urang bakal balik sarta nyandak sistem cache siap-dijieun.
Upami anjeun nembé ngamimitian sareng google, teras masihan atanapi nyandak pesenan, tapi sacara umum, pedomanna bakal sapertos kieu. Anu mimiti, anjeun bakal mendakan Redis, kadéngé dimana-mana. Teras anjeun bakal terang yén EhCache mangrupikeun sistem pangkolotna sareng paling kabuktian. Salajengna urang bakal nyerat ngeunaan Tarantool, pamekaran domestik anu gaduh aspék unik tina solusi. Sareng ogé Ignite, sabab ayeuna naék popularitas sareng nikmati dukungan SberTech. Dina tungtungna aya ogé Hazelcast, sabab di dunya perusahaan mindeng muncul diantara pausahaan badag.
Daptar éta henteu lengkep; aya puluhan sistem. Sarta kami ngan bakal screw hiji hal. Hayu urang nyandak 5 sistem anu dipilih pikeun "kontes kageulisan" sareng ngadamel pilihan. Saha anu bakal juara?
Redis
Urang maca naon maranéhna nulis dina ramatloka resmi.
- proyék opensource. Nawarkeun panyimpen data dina mémori, kamampuan pikeun ngahémat dina disk, partisi otomatis, kasadiaan anu luhur sareng pamulihan tina gangguan jaringan.
Sigana mah sagalana geus rupa, anjeun tiasa nyandak na screw eta on - sagalana nu peryogi, teu. Tapi ngan pikeun senang, hayu urang nempo calon séjén.
EhCache
- "Cache anu paling seueur dianggo pikeun Java" (tarjamahan slogan tina situs wéb resmi). Ogé opensource. Teras we ngartos yen Redis sanes pikeun java, tapi umum, sarta pikeun berinteraksi sareng eta nu peryogi wrapper a. Jeung EhCache bakal leuwih merenah. Naon deui anu janji sistem? Reliabiliti, kabuktian, fungsionalitas pinuh. Nya, éta ogé anu paling umum. Jeung caches terabytes data.
Redis hilap, abdi siap milih EhCache.
Tapi rasa patriotisme ngadorong kuring ningali naon anu hadé ngeunaan Tarantool.
Tarantool
- meets designation "Platform integrasi data real-time". Éta pajeulit pisan, janten urang maca halaman sacara rinci sareng mendakan pernyataan anu nyaring: "Cache 100% data dina RAM." Ieu kedah ngangkat patarosan - sanggeus kabeh, aya bisa jadi leuwih data ti memori. Katerangan téh nya éta hartina Tarantool teu ngajalankeun serialization nulis data kana disk ti memori. Gantina, eta ngagunakeun fitur-tingkat low tina sistem, lamun memori ngan saukur dipetakeun kana sistem file kalawan kinerja I / O pohara alus. Sacara umum, aranjeunna ngalakukeun hal anu saé sareng keren.
Hayu urang tingali palaksanaan: Mail.ru perusahaan jalan raya, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...
Upami masih aya mamang ngeunaan Tarantool, maka kasus palaksanaan di Mastercard ngabéréskeun kuring. Abdi nyandak Tarantool.
Tapi kumaha waé…
ngahurungkeun
… aya deui , ditagih salaku "platform komputasi dina mémori ... laju mémori dina petabytes data." Aya ogé loba kaunggulan dieu: disebarkeun di-memori cache, nu panggancangna neundeun konci-nilai jeung cache, skala horizontal, kasadiaan tinggi, integritas ketat. Sacara umum, tétéla yén panggancangna nyaéta Ignite.
Palaksanaan: Sberbank, American Airlines, Yahoo! Jepang. Teras kuring terang yén Ignite henteu ngan ukur dilaksanakeun di Sberbank, tapi tim SberTech ngirim jalma-jalma ka tim Ignite sorangan pikeun nyaring produk. Ieu sagemblengna captivating tur Abdi siap nyandak Ignite.
Ieu sagemblengna can écés naha, Kuring nempo titik kalima.
Hazelcast
Abdi angkat ka situs , bacaan. Sareng tétéla yén solusi panggancangna pikeun cache anu disebarkeun nyaéta Hazelcast. Éta pesenan gedéna langkung gancang tibatan sadaya solusi anu sanés sareng sacara umum mangrupikeun pamimpin dina widang grid data dina mémori. Ngalawan latar tukang ieu, nyandak hal sejenna henteu ngahargaan diri. Ogé ngagunakeun gudang data kaleuleuwihan pikeun operasi kontinyu tina klaster tanpa leungitna data.
Sakitu wae, abdi siap nyandak Hazelcast.
pabandingan
Tapi upami ditingali, sadayana lima calon dijelaskeun ku cara masing-masing anu pangsaéna. Kumaha carana milih? Urang tiasa ningali mana anu pang populerna, milarian perbandingan, sareng nyeri sirah bakal ngaleungit.
Urang manggihan hiji kawas ieu , pilih 5 sistem kami.
Di dieu aranjeunna diurutkeun: Redis aya di luhur, Hazelcast aya di tempat kadua, Tarantool sareng Ignite kéngingkeun popularitas, EhCache parantos sareng tetep sami.
Tapi hayu urang tingali : Tumbu ka ramatloka, kapentingan umum dina sistem, nawaran pakasaban - hébat! Nyaéta, nalika sistem kuring gagal, kuring bakal nyarios: "Henteu, éta tiasa dipercaya! Aya seueur tawaran padamelan. ”… Saperti babandingan basajan moal ngalakukeun.
Sadaya sistem ieu sanés ngan ukur sistem cache. Éta ogé ngagaduhan seueur fungsi, kalebet nalika data henteu dipompa ka klien pikeun diolah, tapi sabalikna: kode anu kedah dieksekusi dina data ngalir ka server, dieksekusi di dinya, sareng hasilna dipulangkeun. Sareng aranjeunna henteu sering dianggap salaku sistem anu misah pikeun cache.
Oké, hayu urang teu nyerah, hayu urang manggihan hiji ngabandingkeun langsung tina sistem. Hayu urang nyandak dua pilihan luhur - Redis sareng Hazelcast. Kami museurkeun speed, sarta kami bakal ngabandingkeun éta dumasar kana parameter ieu.
Hz vs Redis
Urang manggihan ieu :
Biru nyaéta Redis, beureum nyaéta Hazelcast. Hazelcast meunang di mana waé, sareng aya alesan pikeun ieu: éta multi-threaded, dioptimalkeun pisan, unggal benang tiasa dianggo sareng partisi sorangan, janten henteu aya anu ngahalangan. Sareng Redis nyaéta single-threaded; éta henteu nguntungkeun tina CPU multi-inti modern. Hazelcast boga I / O Asynchronous, Redis-Jedis boga blocking stop kontak. Barina ogé, Hazelcast ngagunakeun protokol binér, sareng Redis mangrupikeun téks-centric, hartosna éta henteu éfisién.
Bisi wae, hayu urang balikkeun ka sumber ngabandingkeun sejen. Naon anu bakal anjeunna nunjukkeun ka urang?
Redis vs Hz
Lian :
Di dieu, sabalikna, beureum nyaéta Redis. Hartina, Redis outperforms Hazelcast dina hal kinerja. Hazelcast meunang babandingan kahiji, Redis meunang kadua. dipedar pisan persis naha Hazelcast meunang ngabandingkeun saméméhna.
Tétéla yén hasil tina hiji munggaran ieu sabenerna rigged: Redis dicokot dina kotak dasar, sarta Hazelcast ieu tailored pikeun hal test. Teras tétéla: kahiji, urang henteu tiasa percanten ka saha waé, sareng kadua, nalika tungtungna milih sistem, urang masih kedah ngonpigurasikeunana leres. Setelan ieu ngawengku puluhan, ampir ratusan parameter.
Ngoyagkeun botol
Sareng kuring tiasa ngajelaskeun sadayana prosés anu ayeuna urang lakukeun ku métafora ieu: "Ngoyagkeun botol." Hartina, ayeuna anjeun teu kudu program, ayeuna hal utama anu bisa maca stackoverflow. Sareng kuring ngagaduhan jalma di tim kuring, profésional, anu damel sapertos kieu dina waktos kritis.
Naon anu anjeunna lakukeun? Anjeunna ningali hal anu rusak, ningali jejak tumpukan, nyandak sababaraha kecap tina éta (anu mangrupikeun kaahlianna dina program), milarian dina Google, mendakan stackoverflow diantara jawaban. Tanpa maca, tanpa mikir, diantara waleran kana patarosan, anjeunna milih hiji hal nu paling sarupa jeung kalimah "ngalakukeun ieu jeung éta" (milih jawaban misalna hiji bakat na, sabab teu salawasna jawaban nu narima paling likes). lumaku , Sigana: lamun hal geus robah, lajeng hébat. Lamun teu robah, gulung deui. Jeung malikan peluncuran-pariksa-search. Sarta dina cara intuitif ieu, anjeunna ensures yén kode jalan sanggeus sababaraha waktu. Anjeunna henteu terang kunaon, anjeunna henteu terang naon anu anjeunna laksanakeun, anjeunna henteu tiasa ngajelaskeun. Tapi! Inféksi ieu jalan. Jeung "seuneu geus pareum". Ayeuna hayu urang terang naon anu urang lakukeun. Nalika program jalan, éta mangrupikeun urutan gedéna langkung gampang. Sarta eta ngaheéat loba waktu.
Metoda ieu kacida alusna dipedar kalawan conto ieu.
Éta pisan populér pikeun ngumpulkeun parahu layar dina botol. Dina waktos anu sami, parahu layar ageung sareng rapuh, sareng beuheung botolna sempit pisan, mustahil nyorong ka jero. Kumaha ngumpulna?
Aya metodeu sapertos kitu, gancang pisan sareng efektif pisan.
The kapal diwangun ku kebat hal saeutik: iteuk, tali, sails, lem. Urang nempatkeun sagala ieu dina botol.
Kami nyandak botol ku dua leungeun sareng mimitian oyag. Urang ngocok jeung ngocok manéhna. Sareng biasana tétéla janten sampah lengkep, tangtosna. Tapi sakapeung. Sok tétéla jadi kapal! Leuwih tepat, hal sarupa kapal.
Kami nunjukkeun ieu ka batur: "Seryoga, naha anjeun ningali!?" Jeung memang, ti kajauhan kasampak kawas kapal. Tapi ieu teu bisa diwenangkeun neruskeun.
Aya jalan sejen. Éta dianggo ku jalma anu langkung maju, sapertos peretas.
Kuring masihan lalaki ieu tugas, anjeunna ngalakukeun sagalana jeung ninggalkeun. Sareng anjeun katingali - sigana parantos réngsé. Sarta sanggeus bari, nalika kode nu kudu finalized, ieu dimimitian kusabab anjeunna ... Ieu alus yén anjeunna geus junun ngajalankeun jauh. Ieu mangrupikeun jalma-jalma anu, nganggo conto botol, bakal ngalakukeun ieu: anjeun ningali, dimana handapeunna, gelasna ngagulung. Jeung teu sagemblengna jelas naha éta transparan atawa henteu. Lajeng "hacker" neukteuk off handap ieu, selapkeun kapal aya, lajeng lem handap deui on deui, tur éta saolah-olah éta kumaha sakuduna jadi.
Tina sudut pandang netepkeun masalah, sadayana sigana leres. Tapi ngagunakeun kapal sabagé conto: naha ngadamel kapal ieu pisan, saha waé anu peryogi? Éta henteu nyayogikeun fungsionalitas naon waé. Biasana kapal sapertos kado pikeun jalma anu pangkat pisan luhur, anu nempatkeun éta dina rak luhureun aranjeunna, salaku sababaraha jinis simbol, salaku tanda. Sareng upami jalma sapertos kitu, kapala bisnis ageung atanapi pejabat luhur, kumaha bandéra bakal nangtung pikeun hack sapertos kitu, anu beuheungna dipotong? Éta langkung saé upami anjeunna henteu kantos terang ngeunaan éta. Janten, kumaha aranjeunna tungtungna ngadamel kapal-kapal ieu anu tiasa dipasihkeun ka jalma penting?
Hiji-hijina tempat konci anu anjeun teu tiasa ngalakukeun nanaon nyaéta awak. Jeung hull kapal urang fits katuhu kana beuheung. Padahal kapal dirakit di luar botol. Tapi éta henteu ngan ukur ngarakit kapal, éta mangrupikeun karajinan perhiasan anu nyata. Levers husus ditambahkeun kana komponén, nu lajeng ngidinan maranéhna pikeun diangkat. Contona, sails na narilep, taliti dibawa ka jero, lajeng, kalayan bantuan pinset, aranjeunna ditarik sarta diangkat pisan persis, kalawan precision. Hasilna mangrupikeun karya seni anu tiasa dipasihan kalbu anu jelas sareng kareueus.
Sareng upami urang hoyong proyék éta suksés, sahenteuna kedah aya hiji tukang perhiasan dina tim. Batur anu paduli ngeunaan kualitas produk jeung tumut kana akun sagala aspek, tanpa sacrificing nanaon, sanajan dina moments setrés, nalika kaayaan merlukeun lakukeun urgent di expense tina penting. Sadaya proyék suksés anu sustainable, anu parantos diuji waktos, diwangun dina prinsip ieu. Aya hal anu tepat sareng unik ngeunaan aranjeunna, anu ngamangpaatkeun sagala kemungkinan anu aya. Dina conto sareng kapal dina botol, kanyataan yén awak kapal ngalangkungan beuheung dimaénkeun.
Balik deui ka tugas milih server cache urang, kumaha cara ieu tiasa diterapkeun? Kuring nawiskeun pilihan ieu pikeun milih tina sadaya sistem anu aya - entong ngocok botol, henteu milih, tapi tingali naon anu aya dina prinsipna, naon anu kedah dipilarian nalika milih sistem.
Dimana néangan botol-beuheung
Hayu urang cobaan teu ngocok botol, teu ngaliwat sagalana nu aya hiji-hiji, tapi hayu urang nempo naon masalah bakal timbul lamun urang ujug-ujug, pikeun tugas urang, ngarancang sistem misalna sorangan. Tangtu, urang moal ngumpul sapédah, tapi urang bakal ngagunakeun diagram ieu pikeun mantuan kami angka kaluar naon titik nengetan dina déskripsi produk. Hayu urang sketsa diagram sapertos kitu.
Upami sistemna disebarkeun, maka urang bakal ngagaduhan sababaraha server (6). Hayu urang nyebutkeun aya opat (éta merenah pikeun nempatkeun aranjeunna dina gambar, tapi, tangtosna, aya bisa jadi saloba anjeun resep). Lamun server aya dina titik béda, hartina aranjeunna sadayana ngajalankeun sababaraha kode anu tanggung jawab pikeun mastikeun yén titik ieu ngabentuk klaster sarta, dina acara putus, nyambung jeung ngakuan silih.
Urang ogé butuh logika kode (2), nu sabenerna ngeunaan cache. Klién berinteraksi sareng kode ieu via sababaraha API. Kodeu klien (1) tiasa aya dina JVM anu sami atanapi aksés kana jaringan. Logika anu dilaksanakeun di jero nyaéta kaputusan dimana objék anu kedah ditinggalkeun dina cache sareng anu kedah dibuang. Urang make memori (3) pikeun nyimpen cache, tapi lamun perlu, urang tiasa nyimpen sababaraha data dina disk (4).
Hayu urang tingali di bagian mana beban bakal lumangsung. Sabenerna, unggal panah sareng unggal titik bakal dimuat. Firstly, antara kode klien tur api, lamun ieu komunikasi jaringan, subsidence nu bisa jadi rada noticeable. Bréh, dina kerangka api sorangan - lamun overdo eta kalawan logika kompléks, urang tiasa ngajalankeun kana masalah jeung CPU. Sarta eta bakal nice lamun logika teu runtah waktu dina memori. Sareng tetep aya interaksi sareng sistem file - dina versi anu biasa nyaéta serialize / malikkeun sareng nyerat / maca.
Salajengna nyaéta interaksi jeung klaster. Paling dipikaresep, éta bakal aya dina sistem anu sami, tapi tiasa nyalira. Di dieu Anjeun oge kudu tumut kana akun mindahkeun data ka dinya, laju serialization data sarta interaksi antara klaster.
Ayeuna, di hiji sisi, urang tiasa ngabayangkeun "naon gears bakal ngahurungkeun" dina sistem cache nalika ngolah requests ti kode urang, sarta di sisi séjén, urang bisa estimasi naon jeung sabaraha requests kode urang bakal ngahasilkeun sistem ieu. Ieu cukup pikeun nyieun pilihan leuwih atawa kirang sober - pikeun milih sistem pikeun pamakéan urang.
Hazelcast
Hayu urang tingali kumaha nerapkeun dékomposisi ieu kana daptar urang. Contona, Hazelcast.
Pikeun nempatkeun / nyandak data tina Hazelcast, kode klien aksés (1) api. Hz ngidinan Anjeun pikeun ngajalankeun server sakumaha embedded, sarta dina hal ieu, ngakses api nyaéta panggero metoda jero JVM, nu bisa dianggap bébas.
Supados logika di (2) dianggo, Hz ngandelkeun hash tina Asép Sunandar Sunarya bait sahiji konci serialized - nyaeta, konci bakal serialized dina sagala hal. Ieu dilawan overhead pikeun Hz.
Strategi pangusir dilaksanakeun ogé, tapi pikeun kasus khusus anjeun tiasa nambihan nyalira. Anjeun teu kedah hariwang ngeunaan bagian ieu.
Panyimpenan (4) tiasa disambungkeun. Hebat. Interaksi (5) pikeun embedded bisa dianggap instan. Bursa data antara titik dina klaster (6) - enya, éta aya. Ieu mangrupa investasi di kasabaran sesar di expense of speed. Fitur Hz Near-cache ngamungkinkeun anjeun ngirangan harga - data anu ditampi tina titik anu sanés dina kluster bakal di-cache.
Naon anu tiasa dilakukeun dina kaayaan sapertos kitu pikeun ningkatkeun kagancangan?
Contona, ulah serialization sahiji konci dina (2) - ngagantelkeun cache sejen dina luhureun Hazelcast, pikeun data hottest. Sportmaster milih Kafein pikeun tujuan ieu.
Pikeun twisting di tingkat (6), Hz nawarkeun dua jenis gudang: IMap jeung ReplicatedMap.
Perlu disebatkeun kumaha Hazelcast asup kana tumpukan téknologi Sportmaster.
Dina 2012, nalika kami nuju damel dina pilot anu pangheulana tina situs anu bakal datang, éta Hazelcast anu tétéla janten tautan anu munggaran anu dipulangkeun ku mesin pencari. Kenalan dimimitian "pertama kalina" - kami katarik ku kanyataan yén ngan ukur dua jam saatos, nalika urang ngaco Hz kana sistem, éta jalan. Sarta eta digawé ogé. Nepi ka tungtun taun kami geus réngsé sababaraha tés jeung senang. Sareng cagar kakuatan ieu cekap pikeun ngatasi kejutan anu dialungkeun ku Hz kana waktosna. Ayeuna tim Sportmaster teu gaduh alesan pikeun ngantunkeun Hazelcast.
Tapi argumen sapertos "numbu munggaran dina mesin pencari" sareng "HelloWorld gancang dirakit" tangtosna, iwal sareng fitur dina waktos pilihan éta lumangsung. Tés nyata pikeun sistem anu dipilih dimimitian ku sékrési kana produksi, sareng dina tahap ieu anjeun kedah nengetan nalika milih sistem naon waé, kalebet cache. Sabenerna, dina hal urang bisa disebutkeun yen urang milih Hazelcast ku kacilakaan, tapi lajeng tétéla yén urang milih bener.
Pikeun produksi, langkung penting: ngawaskeun, nanganan gagal dina titik individu, réplikasi data, biaya skala. Nyaéta, éta patut nengetan tugas anu bakal timbul nalika pangropéa sistem - nalika bebanna puluhan kali langkung luhur tibatan anu direncanakeun, nalika urang ngahaja unggah hiji hal di tempat anu salah, nalika urang kedah ngagulung versi énggal. kode, ngaganti data sarta ngalakukeun eta unnoticed pikeun klien.
Pikeun sakabéh sarat ieu, Hazelcast pasti fits tagihanana.
Ngalajengkeun
Tapi Hazelcast sanés panacea. Dina 2017, kami milih Hazelcast pikeun cache admin, ngan ukur dumasar kana tayangan anu saé tina pangalaman baheula. Ieu maénkeun peran konci dina lulucon pisan kejam, sabab urang kapanggih sorangan dina kaayaan hésé tur "heroically" kaluar ti dinya salila 60 poé. Tapi langkung seueur ngeunaan éta dina bagian salajengna.
Samentara éta... Bagja Kodeu Anyar!
sumber: www.habr.com