Saluton! Mia nomo estas Alexey Pyankov, mi estas programisto ĉe la kompanio Sportmaster. En tio Mi rakontis kiel laboro en la retejo Sportmaster komenciĝis en 2012, kiajn iniciatojn ni sukcesis "puŝi" kaj inverse, kian rastilon ni kolektis.
Hodiaŭ mi volas dividi pensojn, kiuj sekvas alian temon - elektante kaŝmemorsistemon por la java backend en la retejo-administra areo. Tiu ĉi intrigo havas specialan signifon por mi – kvankam la rakonto disvolviĝis nur 2 monatojn, dum ĉi tiuj 60 tagoj ni laboris 12-16 horojn kaj sen unu libera tago. Mi neniam pensis aŭ imagis, ke eblas tiel labori.
Tial mi dividis la tekston en 2 partojn por ne plene ŝargi ĝin. Male, la unua parto estos tre malpeza - preparo, enkonduko, kelkaj konsideroj pri tio, kio estas kaŝmemoro. Se vi jam estas sperta programisto aŭ laboris kun kaŝmemoroj, el la teknika flanko plej verŝajne estos nenio nova en ĉi tiu artikolo. Sed por junulo, tia malgranda recenzo povas diri al li en kiu direkto rigardi se li trovas sin ĉe tia vojkruciĝo.
Kiam la nova versio de la retejo de Sportmaster estis produktata, la datumoj estis ricevitaj en maniero, por paroli milde, ne tre oportuna. La bazo estis tabeloj preparitaj por la antaŭa versio de la retejo (Bitrix), kiuj devis esti tiritaj en ETL, alportitaj al nova formo kaj riĉigitaj per diversaj etaj aferoj el dekduo pli da sistemoj. Por ke nova bildo aŭ produkta priskribo aperu en la retejo, vi devis atendi ĝis la sekva tago - ĝisdatigoj nur nokte, unufoje tage.
Komence, estis tiom da zorgoj de la unuaj semajnoj de produktado, ke tiaj ĝenoj por enhavaj administrantoj estis bagatelo. Sed, tuj kiam ĉio trankviliĝis, la disvolviĝo de la projekto daŭris - kelkajn monatojn poste, komence de 2015, ni komencis aktive disvolvi la administran panelon. En 2015 kaj 2016, ĉio iras bone, ni regule liberigas, la administra panelo kovras pli kaj pli da la datumpreparo, kaj ni prepariĝas por tio, ke baldaŭ nia teamo estos konfidita kun la plej grava kaj kompleksa afero - la produkto. cirkvito (plena preparado kaj prizorgado de datumoj pri ĉiuj produktoj). Sed en la somero de 2017, ĵus antaŭ la lanĉo de la var-cirkvito, la projekto trovos sin en tre malfacila situacio - ĝuste pro problemoj kun kaŝmemoro. Mi volas paroli pri ĉi tiu epizodo en la dua parto de ĉi tiu duparta eldonaĵo.
Sed en ĉi tiu afiŝo mi komencos de malproksime, mi prezentos kelkajn pensojn - ideojn pri kaŝmemoro, kio estus bona paŝo por rulumi antaŭ granda projekto.
Kiam okazas kaŝmemoro tasko
La kaŝmemoro tasko ne nur aperas. Ni estas programistoj, verkantaj programaron kaj volas, ke ĝi estu postulata. Se la produkto estas postulata kaj sukcesa, uzantoj venos. Kaj pli kaj pli venas. Kaj tiam estas multaj uzantoj kaj tiam la produkto fariĝas tre ŝarĝita.
En la unuaj etapoj, ni ne pensas pri optimumigo kaj koda agado. La ĉefa afero estas funkcieco, rapide lanĉado de piloto kaj testado de hipotezoj. Kaj se la ŝarĝo pliiĝas, ni pumpas la feron. Ni pliigas ĝin du aŭ tri fojojn, kvin fojojn, eble 10 fojojn. Ie ĉi tie - financoj ne plu permesos ĝin. Kiom da fojoj kreskos la nombro de uzantoj? Ĝi ne estos kiel 2-5-10, sed se sukcesos, ĝi estos de 100-1000 ĝis 100 mil fojojn. Tio estas, frue aŭ malfrue, vi devos fari optimumigon.
Ni diru, ke iu parto de la kodo (ni nomu tiun ĉi parton funkcio) daŭras maldece longan tempon, kaj ni volas redukti la ekzekuttempon. Funkcio povas esti aliro al datumbazo, aŭ ĝi povas esti la ekzekuto de iu kompleksa logiko - la ĉefa afero estas, ke necesas longa tempo por kompletigi. Kiom vi povas redukti la ekzekuttempon? En la limo, vi povas redukti ĝin al nulo, ne plu. Kiel vi povas redukti ekzekuttempon al nulo? Respondo: elimini ekzekuton entute. Anstataŭe, revenu la rezulton tuj. Kiel vi povas ekscii la rezulton? Respondo: aŭ kalkulu ĝin aŭ rigardu ien. Ĝi bezonas longan tempon por kalkuli. Kaj spioni estas, ekzemple, memori la rezulton, kiun la funkcio produktis la lastan fojon kiam vokis kun la samaj parametroj.
Tio estas, la efektivigo de la funkcio ne gravas por ni. Sufiĉas scii de kiaj parametroj dependas la rezulto. Tiam, se la parametraj valoroj estas reprezentitaj en la formo de objekto, kiu povas esti uzata kiel ŝlosilo en iu stokado, tiam la rezulto de la kalkulo povas esti konservita kaj legita la venontan fojon kiam ĝi estos alirebla. Se ĉi tiu skribo kaj legado de la rezulto estas pli rapida ol ekzekuti la funkcion, ni havas profiton laŭ rapideco. La kvanto de profito povas atingi 100, 1000 kaj 100 mil fojojn (10^5 estas prefere escepto, sed en la kazo de sufiĉe malfrua bazo, ĝi estas tute ebla).
Bazaj postuloj por kaŝmemorsistemo
La unua afero, kiu povas fariĝi postulo por kaŝmemorsistemo, estas rapida legado-rapido kaj, iom pli malgranda mezuro, skriba rapideco. Ĉi tio estas vera, sed nur ĝis ni lanĉos la sistemon al produktado.
Ni ludu ĉi tiun kazon.
Ni diru, ke ni provizis la nunan ŝarĝon per aparataro kaj nun iom post iom enkondukas kaŝmemoron. La nombro de uzantoj iomete kreskas, la ŝarĝo kreskas - ni aldonas iom da kaŝmemoroj, enŝraŭbas ĝin ĉi tie kaj tie. Ĉi tio daŭras iom da tempo, kaj nun pezaj funkcioj praktike ne plu estas nomitaj - la tuta ĉefa ŝarĝo falas sur la kaŝmemoron. La nombro da uzantoj dum ĉi tiu tempo pliiĝis N fojojn.
Kaj se la komenca provizo de aparataro povus esti 2-5 fojojn, tiam helpe de la kaŝmemoro ni povus plibonigi rendimenton je faktoro de 10 aŭ, en bona kazo, je faktoro de 100, en kelkaj lokoj eble per faktoro. de 1000. Tio estas, sur la sama aparataro - ni procesas 100 fojojn pli da petoj. Bonege, vi meritas la zingibropanon!
Sed nun, en unu bela momento, hazarde, la sistemo kraŝis kaj la kaŝmemoro kolapsis. Nenio speciala - post ĉio, la kaŝmemoro estis elektita surbaze de la postulo "alta rapideco de legado kaj skribo, la resto ne gravas."
Rilate al la komenca ŝarĝo, nia fera rezervo estis 2-5 fojojn, kaj la ŝarĝo dum ĉi tiu tempo pliiĝis 10-100 fojojn. Uzante la kaŝmemoron, ni forigis alvokojn por pezaj funkcioj kaj tial ĉio funkciis. Kaj nun, sen kaŝmemoro, kiomfoje nia sistemo malrapidiĝos? Kio okazos al ni? La sistemo falos.
Eĉ se nia kaŝmemoro ne kraŝis, sed estis purigita nur dum kelka tempo, ĝi devos esti varmigita, kaj ĉi tio daŭros iom da tempo. Kaj dum ĉi tiu tempo, la ĉefa ŝarĝo falos sur funkciecon.
Konkludo: tre ŝarĝitaj produktadprojektoj postulas sistemon de kaŝmemoro ne nur por havi altajn legajn kaj skribajn rapidecojn, sed ankaŭ por certigi datumsekurecon kaj reziston al misfunkciadoj.
La agonio de elekto
En projekto kun administra panelo, la elekto iris tiel: unue ni instalis Hazelcast, ĉar Ni jam konis ĉi tiun produkton el la sperto de la ĉefa retejo. Sed ĉi tie ĉi tiu elekto montriĝis malsukcesa - laŭ nia ŝarĝa profilo, Hazelcast estas ne nur malrapida, sed terure malrapida. Kaj tiutempe ni jam aliĝis al la eldondato.
Spoiler: kiel precize disvolviĝis la cirkonstancoj, ke ni maltrafis tiel grandan aferon kaj finiĝis kun akra kaj streĉa situacio - mi rakontos al vi en la dua parto - kaj kiel ni finiĝis kaj kiel ni eliris. Sed nun - mi nur diros, ke ĝi estis multe da streso, kaj "pensi - iel mi ne povas pensi, ni skuas la botelon." "Skuado de la botelo" ankaŭ estas spoiler, pli pri tio poste.
Kion ni faris:
- Ni faras liston de ĉiuj sistemoj, kiujn sugestas Google kaj StackOverflow. Iom pli ol 30
- Ni skribas testojn kun ŝarĝo tipa por produktado. Por fari tion, ni registris datumojn, kiuj trairas la sistemon en produktadmedio - speco de sniffer por datumoj ne en la reto, sed ene de la sistemo. Ĝuste ĉi tiuj datumoj estis uzataj en la testoj.
- Kun la tuta teamo, ĉiuj elektas la sekvan sistemon el la listo, agordas ĝin kaj faras testojn. Ĝi ne pasas la teston, ĝi ne portas la ŝarĝon - ni forĵetas ĝin kaj transiras al la sekva en linio.
- En la 17-a sistemo evidentiĝis, ke ĉio estas senespera. Ĉesu skui la botelon, estas tempo serioze pensi.
Sed ĉi tio estas opcio kiam vi devas elekti sistemon, kiu "trapasos la rapidecon" en antaŭpreparitaj testoj. Kio se ne ekzistas tiaj testoj ankoraŭ kaj vi volas elekti rapide?
Ni modelu ĉi tiun opcion (malfacilas imagi, ke meza+ programisto vivas en vakuo, kaj en la momento de la elekto ankoraŭ ne formaligis sian preferon pri kiu produkto unue provi - do, plia rezonado estas pli teoriulo/filozofio/). pri junulo).
Decidinte pri la postuloj, ni komencos elekti solvon el la skatolo. Kial reinventi la radon: ni iros kaj prenos pretan kaŝmemorsistemon.
Se vi ĵus komencas kaj guglos ĝin, tiam donu aŭ prenu la mendon, sed ĝenerale, la gvidlinioj estos tiaj. Antaŭ ĉio, vi renkontos Redis, ĝi estas aŭdata ĉie. Tiam vi ekscios, ke EhCache estas la plej malnova kaj plej pruvita sistemo. Poste ni skribos pri Tarantool, hejma evoluo, kiu havas unikan aspekton de la solvo. Kaj ankaŭ Ignite, ĉar ĝi nun pliiĝas en populareco kaj ĝuas la subtenon de SberTech. Fine estas ankaŭ Hazelcast, ĉar en la entreprena mondo ĝi ofte aperas inter grandaj kompanioj.
La listo ne estas ĝisfunda; ekzistas dekoj da sistemoj. Kaj ni nur ŝraŭbos unu aferon. Ni prenu la elektitajn 5 sistemojn por la "belkonkurso" kaj faru elekton. Kiu estos la gajnanto?
Redis
Ni legas kion ili skribas en la oficiala retejo.
- malfermfonta projekto. Proponas enmemoran datumstokadon, la kapablon ŝpari sur-disko, aŭtomatan sekcion, altan haveblecon kaj reakiron de retaj malfunkcioj.
Ŝajnas, ke ĉio estas en ordo, vi povas preni ĝin kaj ŝraŭbi ĝin - ĉion, kion vi bezonas, ĝi faras. Sed nur por amuzo, ni rigardu la aliajn kandidatojn.
EhCache
- “la plej uzata kaŝmemoro por Java” (traduko de la slogano el la oficiala retejo). Ankaŭ malfermfonteco. Kaj tiam ni komprenas, ke Redis ne estas por java, sed ĝenerala, kaj por interagi kun ĝi vi bezonas envolvaĵon. Kaj EhCache estos pli oportuna. Kion alian promesas la sistemo? Fidindeco, pruvita, plena funkcieco. Nu, ĝi ankaŭ estas la plej ofta. Kaj konservas terabajtojn da datumoj.
Redis estas forgesita, mi pretas elekti EhCache.
Sed sento de patriotismo puŝas min vidi kio estas bona pri Tarantool.
Tarantool
- renkontas la nomon "Platformo pri realtempa integriĝo de datumoj". Ĝi sonas tre komplika, do ni legas la paĝon detale kaj trovas laŭtan deklaron: "Kaŝmemorigas 100% de la datumoj en RAM." Ĉi tio devus levi demandojn - finfine povas esti multe pli da datumoj ol memoro. La klarigo estas, ke ĝi signifas, ke Tarantool ne rulas seriigon por skribi datumojn al disko el memoro. Anstataŭe, ĝi uzas malaltnivelajn ecojn de la sistemo, kiam memoro estas simple mapita al dosiersistemo kun tre bona I/O-efikeco. Ĝenerale, ili faris ion mirindan kaj mojosa.
Ni rigardu la efektivigojn: Mail.ru kompania ŝoseo, Avito, Beeline, Megafon, Alfa-Banko, Gazprom...
Se ankoraŭ estis duboj pri Tarantool, tiam la efektiviga kazo ĉe Mastercard finas min. Mi prenas Tarantool.
Sed ĉiuokaze…
Igniti
… ĉu estas iom pli , estas proklamita "en-memora komputika platformo... en-memoraj rapidecoj sur petabajtoj da datenoj." Ankaŭ ekzistas multaj avantaĝoj ĉi tie: distribuita en-memora kaŝmemoro, la plej rapida ŝlosilvalora konservado kaj kaŝmemoro, horizontala skalo, alta havebleco, strikta integreco. Ĝenerale, rezultas, ke la plej rapida estas Ignite.
Efektivigoj: Sberbank, American Airlines, Yahoo! Japanio. Kaj tiam mi ekscias, ke Ignite ne estas nur efektivigita en Sberbank, sed la SberTech-teamo sendas siajn homojn al la Ignite-teamo mem por rafini la produkton. Ĉi tio estas tute alloga kaj mi pretas preni Ignite.
Estas tute neklare kial, mi rigardas la kvinan punkton.
hazelcast
Mi iras al la retejo , legante. Kaj rezultas, ke la plej rapida solvo por distribuita kaŝmemoro estas Hazelcast. Ĝi estas ordoj de grandeco pli rapida ol ĉiuj aliaj solvoj kaj ĝenerale ĝi estas gvidanto en la kampo de en-memora datuma krado. En ĉi tiu fono, preni ion alian estas ne respekti vin mem. Ĝi ankaŭ uzas redundan datumstokadon por kontinua funkciado de la areto sen datumperdo.
Jen ĝi, mi pretas preni Hazelcast.
Komparo
Sed se vi rigardas, ĉiuj kvin kandidatoj estas priskribitaj tiel, ke ĉiu el ili estas la plej bona. Kiel elekti? Ni povas vidi, kiu estas la plej populara, serĉi komparojn, kaj la kapdoloro foriros.
Ni trovas tian tian , elektu niajn 5 sistemojn.
Ĉi tie ili estas ordigitaj: Redis estas ĉe la supro, Hazelcast estas en dua loko, Tarantool kaj Ignite akiras popularecon, EhCache estis kaj restas la sama.
Sed ni rigardu : ligiloj al retejoj, ĝenerala intereso pri la sistemo, laborproponoj - bonege! Tio estas, kiam mia sistemo malsukcesos, mi diros: "Ne, ĝi estas fidinda! Estas multaj ofertoj de laboro..." Tia simpla komparo ne utilos.
Ĉiuj ĉi tiuj sistemoj ne estas nur kaŝmemorsistemoj. Ili ankaŭ havas multajn funkciojn, inkluzive kiam datumoj ne estas pumpitaj al la kliento por prilaborado, sed inverse: la kodo, kiu devas esti efektivigita sur la datumoj, moviĝas al la servilo, estas ekzekutita tie, kaj la rezulto estas resendita. Kaj ili ne estas tiom ofte konsiderataj kiel aparta sistemo por kaŝmemoro.
Bone, ni ne rezignu, ni trovu rektan komparon de la sistemoj. Ni prenu la suprajn du eblojn - Redis kaj Hazelcast. Ni interesiĝas pri rapideco, kaj ni komparos ilin laŭ ĉi tiu parametro.
Hz vs Redis
Ni trovas ĉi tion :
Blua estas Redis, ruĝa estas Hazelcast. Hazelcast gajnas ĉie, kaj ekzistas kialo por tio: ĝi estas multfadena, tre optimumigita, ĉiu fadeno funkcias per sia propra sekcio, do ne estas blokado. Kaj Redis estas unufadena; ĝi ne profitas de modernaj plurkernaj CPUoj. Hazelcast havas nesinkronan I/O, Redis-Jedis havas blokantajn ingojn. Post ĉio, Hazelcast uzas binaran protokolon, kaj Redis estas tekst-centra, kio signifas, ke ĝi estas malefika.
Por la okazo, ni turnu nin al alia fonto de komparo. Kion li montros al ni?
Redis kontraŭ Hz
Alia :
Ĉi tie, male, ruĝa estas Redis. Tio estas, Redis superas Hazelcast laŭ rendimento. Hazelcast gajnis la unuan komparon, Redis gajnis la duan. klarigis tre precize kial Hazelcast gajnis la antaŭan komparon.
Rezultas, ke la rezulto de la unua estis efektive rigita: Redis estis prenita en la baza skatolo, kaj Hazelcast estis tajlorita por provo. Tiam rezultas: unue, ni ne povas fidi iun ajn, kaj due, kiam ni finfine elektas sistemon, ni ankoraŭ bezonas agordi ĝin ĝuste. Ĉi tiuj agordoj inkluzivas dekojn, preskaŭ centojn da parametroj.
Skuante la botelon
Kaj mi povas klarigi la tutan procezon, kiun ni nun faris per la sekva metaforo: "Skuante la botelon." Tio estas, nun vi ne devas programi, nun la ĉefa afero estas povi legi stackoverflow. Kaj mi havas personon en mia teamo, profesiulo, kiu funkcias ĝuste tiel en kritikaj momentoj.
Kion li faras? Li vidas rompitan aferon, vidas stakspuron, prenas kelkajn vortojn el ĝi (kiuj estas lia kompetenteco en la programo), serĉas en Guglo, trovas stackoverflow inter la respondoj. Sen legi, sen pripensi, inter la respondoj al la demando, li elektas ion plej similan al la frazo "faru tion kaj tion" (elekti tian respondon estas lia talento, ĉar ne ĉiam la respondo ricevis la plej multajn ŝatojn), aplikas , aspektas: se io ŝanĝiĝis, do bonege. Se ĝi ne ŝanĝiĝis, reiru ĝin. Kaj ripetu lanĉo-kontrolo-serĉon. Kaj en ĉi tiu intuicia maniero, li certigas, ke la kodo funkcias post iom da tempo. Li ne scias kial, li ne scias kion li faris, li ne povas klarigi. Sed! Ĉi tiu infekto funkcias. Kaj "la fajro estas estingita". Nun ni eltrovu, kion ni faris. Kiam la programo funkcias, ĝi estas ordo de grandeco pli facila. Kaj ĝi ŝparas multan tempon.
Ĉi tiu metodo estas tre bone klarigita per ĉi tiu ekzemplo.
Estis iam tre populare kolekti velboaton en botelo. Samtempe, la velŝipo estas granda kaj fragila, kaj la kolo de la botelo estas tre mallarĝa, ne eblas puŝi ĝin enen. Kiel kunveni ĝin?
Estas tia metodo, tre rapida kaj tre efika.
La ŝipo konsistas el aro da etaĵoj: bastonoj, ŝnuroj, veloj, gluo. Ni metas ĉion ĉi en botelon.
Ni prenas la botelon per ambaŭ manoj kaj ektremas. Ni skuas kaj skuas ŝin. Kaj kutime ĝi rezultas esti kompleta rubo, kompreneble. Sed foje. Kelkfoje ĝi montriĝas ŝipo! Pli precize, io simila al ŝipo.
Ni montras ĉi tion al iu: "Serjoga, ĉu vi vidas!?" Kaj ja de malproksime ĝi aspektas kiel ŝipo. Sed ĉi tio ne povas daŭri.
Estas alia maniero. Ili estas uzataj de pli progresintaj uloj, kiel retpiratoj.
Mi donis al tiu ĉi ulo taskon, li faris ĉion kaj foriris. Kaj vi aspektas - ŝajnas, ke ĝi estas farita. Kaj post iom da tempo, kiam la kodo devas esti finita, ĉi tio komenciĝas pro li... Estas bone, ke li jam sukcesis forkuri malproksimen. Ĉi tiuj estas la uloj kiuj, uzante la ekzemplon de botelo, faros tion: vi vidas, kie estas la fundo, la vitro fleksiĝas. Kaj ne estas tute klare ĉu ĝi estas travidebla aŭ ne. Tiam la "hackers" detranĉis ĉi tiun fundon, enmetu ŝipon tien, tiam gluu la fundon denove sur, kaj estas kvazaŭ tiel ĝi devus esti.
El la vidpunkto de fiksado de la problemo, ĉio ŝajnas esti ĝusta. Sed uzante ŝipojn kiel ekzemplon: kial fari ĉi tiun ŝipon entute, kiu ĉiuokaze bezonas ĝin? Ĝi ne provizas ajnan funkcion. Kutime tiaj ŝipoj estas donacoj al tre altnivelaj homoj, kiuj metas ĝin sur breton super ili, kiel ian simbolon, kiel signon. Kaj se tia persono, la estro de granda komerco aŭ altranga oficisto, kiel la flago staros por tia hako, kies kolo estis fortranĉita? Pli bone estus, se li neniam scius pri tio. Do, kiel ili finas fari ĉi tiujn ŝipojn, kiujn oni povas doni al grava persono?
La sola ŝlosila loko, pri kiu vi vere ne povas fari ion ajn, estas la korpo. Kaj la kareno de la ŝipo konvenas ĝuste en la kolon. Dum la ŝipo estas kunvenita ekster la botelo. Sed ĝi ne estas nur muntado de ŝipon, ĝi estas vera juvelaĵa metio. Specialaj leviloj estas aldonitaj al la komponentoj, kiuj tiam permesas ilin esti levitaj. Ekzemple, la veloj estas falditaj, zorge enportataj enen, kaj poste, per la pinĉilo, ili estas tirataj kaj levitaj tre precize, precize. La rezulto estas artaĵo, kiu povas esti donacita kun pura konscienco kaj fiero.
Kaj se ni volas, ke la projekto sukcesu, devas esti almenaŭ unu juvelisto en la teamo. Iu, kiu zorgas pri la kvalito de la produkto kaj konsideras ĉiujn aspektojn, sen oferi ion ajn, eĉ en momentoj de streso, kiam cirkonstancoj postulas fari la urĝan koste de la grava. Ĉiuj sukcesaj projektoj, kiuj estas daŭrigeblaj, kiuj eltenis la provon de la tempo, estas konstruitaj sur ĉi tiu principo. Estas io tre preciza kaj unika ĉe ili, io kiu utiligas ĉiujn disponeblajn eblecojn. En la ekzemplo kun la ŝipo en la botelo, la fakto ke la kareno de la ŝipo pasas tra la kolo estas ludita.
Revenante al la tasko elekti nian kaŝmemorservilon, kiel ĉi tiu metodo povus esti aplikata? Mi proponas ĉi tiun eblon elekti el ĉiuj ekzistantaj sistemoj - ne skuu la botelon, ne elektu, sed rigardu, kion ili principe havas, kion serĉi kiam vi elektas sistemon.
Kie serĉi botelon
Ni provu ne skui la botelon, ne trairi ĉion, kio estas tie unu post alia, sed ni vidu, kiaj problemoj aperos, se ni subite, por nia tasko, desegnas tian sistemon mem. Kompreneble, ni ne kunvenos la biciklon, sed ni uzos ĉi tiun diagramon por helpi nin eltrovi, kiujn punktojn atentu en produktaj priskriboj. Ni skizu tian diagramon.
Se la sistemo estas distribuita, tiam ni havos plurajn servilojn (6). Ni diru, ke estas kvar (estas oportune meti ilin en la bildon, sed, kompreneble, povas esti tiom da ili kiom vi volas). Se la serviloj estas sur malsamaj nodoj, tio signifas, ke ili ĉiuj funkcias iun kodon, kiu respondecas pri certigi, ke ĉi tiuj nodoj formas areton kaj, en la okazo de rompo, ligiĝas kaj rekonas unu la alian.
Ni ankaŭ bezonas kodlogikon (2), kiu fakte temas pri kaŝmemoro. Klientoj interagas kun ĉi tiu kodo per iu API. Klientokodo (1) povas esti aŭ ene de la sama JVM aŭ aliri ĝin tra la reto. La logiko efektivigita interne estas la decido pri kiuj objektoj lasi en la kaŝmemoro kaj kiujn elĵeti. Ni uzas memoron (3) por konservi la kaŝmemoron, sed se necese, ni povas konservi kelkajn el la datumoj sur disko (4).
Ni vidu en kiuj partoj la ŝarĝo okazos. Efektive, ĉiu sago kaj ĉiu nodo estos ŝarĝitaj. Unue, inter la klientokodo kaj la api, se ĉi tio estas retkomunikado, la malkresko povas esti sufiĉe rimarkebla. Due, en la kadro de la apio mem - se ni troigas ĝin kun kompleksa logiko, ni povas renkonti problemojn kun la CPU. Kaj estus bone, se logiko ne perdus tempon por memoro. Kaj restas interago kun la dosiersistemo - en la kutima versio ĉi tio estas seriigi / restarigi kaj skribi / legi.
Sekva estas interago kun la areto. Plej verŝajne, ĝi estos en la sama sistemo, sed ĝi povus esti aparte. Ĉi tie vi ankaŭ devas konsideri la translokigon de datumoj al ĝi, la rapidecon de datuma seriigo kaj interagoj inter la areto.
Nun, unuflanke, ni povas imagi "kiajn ilarojn turniĝos" en la kaŝmemorsistemo dum prilaborado de petoj de nia kodo, kaj aliflanke, ni povas taksi kiajn kaj kiom da petoj nia kodo generos al ĉi tiu sistemo. Ĉi tio sufiĉas por fari pli-malpli sobran elekton - elekti sistemon por nia uzokazo.
hazelcast
Ni vidu kiel apliki ĉi tiun malkomponaĵon al nia listo. Ekzemple, Hazelcast.
Por meti/preni datumojn de Hazelcast, la klientkodo aliras (1) la apion. Hz permesas ruli la servilon kiel enigita, kaj en ĉi tiu kazo, aliri la api estas metodovoko ene de la JVM, kiu povas esti konsiderata senpaga.
Por ke la logiko en (2) funkciu, Hz dependas de la hash de la bajta tabelo de la seriigita ŝlosilo - tio estas, la ŝlosilo estos seriigita ĉiukaze. Ĉi tio estas neevitebla supre por Hz.
Elpeligstrategioj estas bone efektivigitaj, sed por specialaj kazoj vi povas aldoni vian propran. Vi ne devas zorgi pri ĉi tiu parto.
Stokado (4) povas esti konektita. Bonege. Interago (5) por enigita povas esti konsiderata tuja. Interŝanĝo de datumoj inter nodoj en la areto (6) - jes, ĝi ekzistas. Ĉi tio estas investo en faŭltoleremo koste de rapideco. La funkcio Hz Near-cache permesas vin redukti la prezon - datumoj ricevitaj de aliaj nodoj en la areto estos konservitaj.
Kion oni povas fari en tiaj kondiĉoj por pliigi rapidecon?
Ekzemple, por eviti seriigon de la ŝlosilo en (2) - aldonu alian kaŝmemoron supre de Hazelcast, por la plej varmaj datumoj. Sportmaster elektis Kafeinon por tiu celo.
Por tordado je nivelo (6), Hz ofertas du specojn de stokado: IMap kaj ReplicatedMap.
Indas mencii kiel Hazelcast eniris la teknologian stakon de Sportmaster.
En 2012, kiam ni laboris pri la plej unua piloto de la estonta retejo, estis Hazelcast, kiu rezultis esti la unua ligilo, kiun la serĉilo revenis. La konato komencis "la unuan fojon" - ni estis allogitaj de la fakto, ke nur du horojn poste, kiam ni ŝraŭbis Hz en la sistemon, ĝi funkciis. Kaj ĝi funkciis bone. Ĝis la fino de la tago ni kompletigis kelkajn provojn kaj estis feliĉaj. Kaj ĉi tiu rezervo de vigleco sufiĉis por venki la surprizojn, kiujn Hz ĵetis laŭlonge de la tempo. Nun la teamo Sportmaster ne havas kialon forlasi Hazelcast.
Sed tiaj argumentoj kiel "la unua ligilo en la serĉilo" kaj "HelloWorld estis rapide kunvenita" estas, kompreneble, escepto kaj trajto de la momento, kiam la elekto okazis. La veraj provoj por la elektita sistemo komenciĝas per la liberigo en produktadon, kaj estas en ĉi tiu etapo, ke vi devas atenti kiam vi elektas iun ajn sistemon, inkluzive de kaŝmemoro. Efektive, en nia kazo ni povas diri, ke ni elektis Hazelcast hazarde, sed tiam montriĝis, ke ni elektis ĝuste.
Por produktado, multe pli grava: monitorado, pritraktado de misfunkciadoj sur individuaj nodoj, reproduktado de datumoj, kosto de skalo. Tio estas, indas atenti la taskojn, kiuj aperos dum la prizorgado de la sistemo - kiam la ŝarĝo estas dekoble pli alta ol planita, kiam ni hazarde alŝutas ion en malĝusta loko, kiam ni bezonas elŝuti novan version. de la kodo, anstataŭigu datumojn kaj faru ĝin nerimarkite por klientoj.
Por ĉiuj ĉi tiuj postuloj, Hazelcast certe taŭgas.
Daŭrigota
Sed Hazelcast ne estas panaceo. En 2017, ni elektis Hazelcast por la administra kaŝmemoro, simple surbaze de bonaj impresoj de pasinta sperto. Ĉi tio ludis ŝlosilan rolon en tre kruela ŝerco, pro kiu ni trovis nin en malfacila situacio kaj "heroe" eliris el ĝi dum 60 tagoj. Sed pli pri tio en la sekva parto.
Intertempe... Feliĉa Nova Kodo!
fonto: www.habr.com