Përshëndetje! Emri im është Alexey Pyankov, jam zhvillues në Sportmaster. Ju tregova se si filloi puna në faqen e internetit të Sportmaster në vitin 2012, cilat iniciativa arritëm të çonim përpara dhe, anasjelltas, çfarë grackash hasëm.
Sot do të doja të ndaja mendimet e mia mbi një temë tjetër: zgjedhja e një sistemi të ruajtjes në memorje për backend-in Java të panelit të administratorit të faqes së internetit. Kjo temë ka një rëndësi të veçantë për mua - megjithëse ndodhi vetëm gjatë dy muajve, ne i kaluam ato 60 ditë duke punuar 12-16 orë në ditë, pa asnjë ditë pushim. Nuk e mendova ose imagjinova kurrë se ishte e mundur të punoja kaq shumë.
Prandaj, po e ndaj tekstin në dy pjesë për të mos ju mbingarkuar. Në fakt, pjesa e parë do të jetë shumë e lehtë - përgatitja, hyrja dhe disa konsiderata në lidhje me ruajtjen në memorje. Nëse jeni tashmë një zhvillues me përvojë ose keni punuar me memorje në memorje, ka të ngjarë të mos ketë asgjë të re në këtë artikull nga pikëpamja teknike. Megjithatë, për një zhvillues të ri, ky përmbledhje e shkurtër mund t'ju ndihmojë të orientoheni në drejtimin e duhur nëse e gjeni veten në një udhëkryq.
Kur versioni i ri i faqes së internetit Sportmaster u lançua në prodhim, rrjedha e të dhënave ishte, për ta thënë butë, e papërshtatshme. Tabelat e përgatitura për versionin e mëparshëm të faqes së internetit (Bitrix) shërbyen si bazë dhe ato duhej të tërhiqeshin në ETL, të përditësoheshin në një pamje të re dhe të pasuroheshin me veçori të ndryshme nga një duzinë sistemesh të tjera. Që një imazh ose përshkrim i ri produkti të shfaqej në faqen e internetit, ishte e nevojshme të pritej deri të nesërmen - përditësimet ishin të disponueshme vetëm natën, një herë në ditë.
Në fillim, javët e para të prodhimit ishin aq të vështira saqë shqetësime të tilla për menaxherët e përmbajtjes ishin një çështje e vogël. Por, sapo gjithçka u qetësua, zhvillimi i projektit vazhdoi - disa muaj më vonë, në fillim të vitit 2015, filluam të zhvillonim në mënyrë aktive panelin e administratorit. Në vitin 2015 dhe 2016, gjithçka po shkonte mirë, ne po publikonim rregullisht, paneli i administratorit po mbulonte gjithnjë e më shumë procesin e përgatitjes së të dhënave dhe ne po përgatiteshim që ekipit tonë së shpejti t'i besohej detyra më e rëndësishme dhe komplekse - konturi i produktit (përgatitja dhe mirëmbajtja e plotë e të dhënave për të gjitha produktet). Por në verën e vitit 2017, pak para lançimit të konturit të produktit, projekti u gjend në një situatë shumë të vështirë - konkretisht, për shkak të problemeve me ruajtjen në memorje. Dua të flas për këtë episod në pjesën e dytë të këtij botimi me dy pjesë.
Por në këtë postim, do të filloj nga larg, duke ndarë disa mendime dhe ide rreth ruajtjes në memorje që do të ishin një hap i mirë për t'u marrë në konsideratë përpara se të ndërmerrni një projekt të madh.
Kur lind problemi i ruajtjes në memorje
Detyra e ruajtjes në memorje nuk lind vetë. Ne zhvilluesit shkruajmë një produkt softuerik dhe duam që ai të jetë i kërkuar. Nëse produkti është i kërkuar dhe i suksesshëm, përdoruesit vijnë. Dhe gjithnjë e më shumë. Dhe pastaj ka kaq shumë përdorues, dhe atëherë produkti bëhet shumë i ngarkuar.
Në fazat e hershme, ne nuk mendojmë për optimizimin e kodit dhe performancën. Gjëja kryesore është funksionaliteti, zbatimi i shpejtë i një projekti pilot dhe testimi i hipotezave. Dhe nëse ngarkesa rritet, ne përmirësojmë harduerin. E rrisim atë me dy, tre, pesë ose edhe dhjetë herë. Në këtë pikë, financat nuk do të lejojnë më shumë. Dhe sa herë do të rritet numri i përdoruesve? Nuk do të jetë 2-5-10 herë, por nëse ka sukses, do të jetë 100-1000-fish, madje 100,000-fish. Pra, herët a vonë, do të na duhet të merremi me optimizimin.
Le të themi se një pjesë e kodit (le ta quajmë funksion) kërkon një kohë jashtëzakonisht të gjatë për t'u ekzekutuar dhe ne duam ta zvogëlojmë kohën e ekzekutimit të tij. Ky funksion mund të jetë qasja në një bazë të dhënash ose ekzekutimi i ndonjë logjike komplekse - gjëja e rëndësishme është se kërkon shumë kohë. Sa mund ta zvogëlojmë kohën e ekzekutimit? Në fund të fundit, mund ta zvogëlojmë atë në zero dhe asgjë më shumë. Pra, si mund ta zvogëlojmë kohën e ekzekutimit në zero? Përgjigja: eliminoni plotësisht ekzekutimin. Në vend të kësaj, kthejeni rezultatin menjëherë. Dhe si mund ta gjejmë rezultatin? Përgjigja është ose ta llogarisim ose ta kërkojmë diku. Llogaritja e tij kërkon shumë kohë. Dhe kërkimi i tij do të thotë, për shembull, të kujtojmë rezultatin që funksioni e ktheu herën e fundit që u thirr me të njëjtat parametra.
Me fjalë të tjera, zbatimi i funksionit nuk është i rëndësishëm për ne. Mjafton të dimë se nga cilët parametra varet rezultati. Pastaj, nëse vlerat e parametrave përfaqësohen si një objekt që mund të përdoret si çelës në ndonjë memorie, ne mund ta ruajmë rezultatin e llogaritjes dhe ta lexojmë atë herën tjetër që i qasemi. Nëse këto shkrime dhe lexime të rezultatit janë më të shpejta se ekzekutimi i funksionit, ne arrijmë një rritje në shpejtësi. Rritja mund të arrijë 100, 1000 ose edhe 100 herë (10^5 është më shumë një përjashtim, por është plotësisht e mundur në rastin e një baze të dhënash që vonohet ndjeshëm).
Kërkesat themelore për një sistem ruajtjeje në memorje
Kërkesa e parë për një sistem ruajtjeje në memorje është shpejtësia e lartë e leximit dhe, në një masë më të vogël, shpejtësia e shkrimit. Kjo është e vërtetë, por vetëm derisa ta vendosim sistemin në prodhim.
Le ta shqyrtojmë një rast të tillë.
Le të themi se kemi siguruar pajisjet për të trajtuar ngarkesën aktuale dhe tani po zbatojmë gradualisht ruajtjen në memorje. Numri i përdoruesve rritet pak, ngarkesa rritet, kështu që shtojmë pak memorje në memorje, duke ndryshuar gjërat këtu e atje. Kjo vazhdon për njëfarë kohe, derisa funksionet e rënda praktikisht të mos thirren më - e gjithë ngarkesa mbahet nga memoria në memorje. Numri i përdoruesve është rritur me një faktor N gjatë kësaj kohe.
Edhe pse hapësira fillestare e harduerit mund të ketë qenë 2-5 herë më e madhe, duke përdorur memorien e përkohshme mund ta rrisnim performancën me një faktor prej 10, ose në rastin më të mirë, 100 herë, dhe në disa raste, ndoshta edhe 1000 herë. Me fjalë të tjera, me të njëjtin harduer, po përpunojmë 100 herë më shumë kërkesa. Shkëlqyeshëm, meritojmë një bonus!
Por pastaj, një ditë të bukur, rastësisht, sistemi u bllokua dhe memoria e përkohshme u bllokua. Asgjë e madhe - në fund të fundit, memoria e përkohshme u zgjodh bazuar në kërkesën e "shpejtësive të larta të leximit dhe shkrimit, asgjë tjetër nuk ka rëndësi".
Kishim 2-5 herë më shumë hapësirë për harduerin krahasuar me ngarkesën fillestare, por ngarkesa u rrit 10-100 herë gjatë asaj kohe. Duke përdorur memorien e përkohshme, eliminuam thirrjet për funksione të rënda dhe për këtë arsye gjithçka funksionoi mirë. Por tani, pa memorien e përkohshme, sa do të ngadalësohet sistemi ynë? Çfarë do të ndodhë? Sistemi do të rrëzohet.
Edhe nëse memoria jonë e përkohshme nuk ka pësuar probleme, por është pastruar vetëm për njëfarë kohe, do të duhet të ngrohet, gjë që do të kërkojë pak kohë. Dhe gjatë kësaj kohe, ngarkesa kryesore do të bjerë mbi funksionalitetin.
Përfundim: Projektet e prodhimit me ngarkesë të lartë kërkojnë një sistem ruajtjeje në memorje jo vetëm që të ofrojë shpejtësi të larta leximi dhe shkrimi, por edhe integritet të të dhënave dhe rezistencë ndaj dështimeve.
Miell i zgjedhur
Për projektin me panelin e administratorit, zgjedhja ishte kështu: instaluam Hazelcast së pari, pasi ishim tashmë të njohur me të nga përvoja jonë me faqen kryesore të internetit. Megjithatë, kjo doli të ishte një zgjedhje e keqe këtu - sipas profilit tonë të ngarkesës së punës, Hazelcast nuk ishte thjesht i ngadaltë, por tmerrësisht i ngadaltë. Dhe në atë pikë, ne tashmë ishim të përkushtuar ndaj afatit të prodhimit.
Paralajmërim për zbulim të të dhënave: Do t'ju tregoj saktësisht se si u zhvilluan rrethanat, duke na lejuar të humbasim një mundësi kaq të madhe dhe të përfundojmë në këtë situatë të tensionuar dhe stresuese, në Pjesën e Dytë - si arritëm atje dhe si dolëm prej saj. Por tani për tani, do të them vetëm se ishte tepër stresuese, dhe "të mendosh - disi, është thjesht të tundësh shishen". "Shkundja e shishes" është gjithashtu një zbulim i të dhënave; më shumë për këtë më vonë.
Çfarë bëmë:
- Po përpilojmë një listë të të gjitha sistemeve të sugjeruara nga Google dhe StackOverflow. Pak më shumë se 30
- Ne shkruam teste me një ngarkesë pune tipike për prodhim. Për ta bërë këtë, regjistruam të dhëna që rrjedhin nëpër sistem në mjedisin e prodhimit - një lloj sniffer për të dhëna jo në rrjet, por brenda sistemit. Këto të dhëna ishin pikërisht ato që ekzekutuam në teste.
- I gjithë ekipi punon së bashku, secili duke zgjedhur sistemin tjetër nga lista, duke e konfiguruar atë dhe duke kryer teste. Nëse nuk e kalon testin ose nuk mund ta përballojë ngarkesën, ne e hedhim poshtë dhe kalojmë te sistemi tjetër në radhë.
- Deri në sistemin e 17-të, u bë e qartë se gjithçka ishte e pashpresë. Mjaft me tundjen e shishes; koha për pak mendim serioz.
Por ky është një opsion kur duhet të zgjidhni një sistem që do të "kalojë me shpejtësi" në testet e përgatitura paraprakisht. Po sikur teste të tilla të mos ekzistojnë ende dhe dëshironi të zgjidhni shpejt?
Le ta simulojmë një skenar të tillë (është e vështirë të imagjinohet që një zhvillues i nivelit të mesëm+ jeton në një boshllëk dhe, në kohën e zgjedhjes, ende nuk ka formuluar një preferencë se cilin produkt të provojë i pari - prandaj, arsyetimi i mëtejshëm është më teorik/filozofik/rreth një zhvilluesi të nivelit të tretë).
Pasi të kemi përcaktuar kërkesat tona, le të fillojmë të zgjedhim një zgjidhje të gatshme. Pse të shpikim rrotën nga e para? Do të zgjedhim një sistem të gatshëm për ruajtje në memorje.
Nëse sapo keni filluar dhe sapo keni kërkuar në Google, rendi do të ndryshojë, por në përgjithësi, udhëzimet do të jenë si më poshtë. Së pari, do të hasni Redis; është i njohur gjerësisht. Pastaj do të mësoni rreth EhCache, sistemit më të vjetër dhe më të provuar. Më pas, do të lexoni rreth Tarantool, një zhvillim vendas me një aspekt unik në zgjidhjen e tij. Dhe gjithashtu Ignite, sepse aktualisht po përjeton një rritje të popullaritetit dhe mbështetet nga SberTech. Së fundmi, është Hazelcast, sepse përmendet shpesh në botën e ndërmarrjeve midis kompanive të mëdha.
Kjo listë nuk është e plotë; ka dhjetëra sisteme. Do të shtojmë vetëm një. Do t'i kalojmë pesë sistemet e zgjedhura në një "konkurs bukurie" dhe do të zhvillojmë një proces përzgjedhjeje. Kush do të fitojë?
Redis
Le të lexojmë se çfarë shkruajnë në faqen zyrtare të internetit.
— një projekt me burim të hapur. Ofron ruajtje të të dhënave në memorie, qëndrueshmëri në disk, ndarje automatike, disponueshmëri të lartë dhe rikuperim nga dështimet e rrjetit.
Duket sikur gjithçka është shumë mirë, mund ta bësh edhe më mirë—bën gjithçka që të nevojitet. Por le t’i hedhim një sy kandidatëve të tjerë, thjesht për qejf.
EhCache
— "memoria e përkohshme më e përdorur për Java" (përkthyer nga faqja zyrtare e internetit). Është gjithashtu me burim të hapur. Dhe këtu kuptojmë se Redis nuk është për Java, por një memorje e përkohshme me qëllim të përgjithshëm, dhe nevojitet një mbështjellës për të bashkëvepruar me të. EhCache, megjithatë, do të ishte më i përshtatshëm. Çfarë tjetër premton sistemi? Besueshmëri, performancë të provuar dhe funksionalitet të plotë. Dhe është gjithashtu më i përdoruri. Dhe ruan në memorien e përkohshme terabajt të dhënash.
Redis është harruar, jam gati të zgjedh EhCache.
Por një ndjenjë patriotizmi më shtyn të shoh çfarë është e mirë te Tarantool.
Tarantool
— është etiketuar si "Platformë e Integrimit të të Dhënave në Kohë Reale". Tingëllon shumë e ndërlikuar, kështu që e lexojmë faqen me detaje dhe gjejmë një pohim të guximshëm: "Ruan 100% të të dhënave në RAM". Kjo duhet të ngrejë disa pyetje, pasi mund të ketë dukshëm më shumë të dhëna sesa memorie. Implikimi këtu është se Tarantool nuk i serializon të dhënat nga memoria në disk. Në vend të kësaj, ai përdor veçori të sistemit të nivelit të ulët, ku memoria thjesht i është lidhur sistemit të skedarëve, i cili ka performancë shumë të mirë I/O. Në përgjithësi, është një implementim i mrekullueshëm dhe i projektuar mirë.
Le të shohim implementimet: rrjeti kryesor i korporatës Mail.ru, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...
Nëse kisha ndonjë dyshim në lidhje me Tarantool, rasti i implementimit të Mastercard është pika kupë e fundit. Unë do të zgjedh Tarantool.
Por prapë...
Ndez
...ka më shumë , i reklamuar si një "platformë kompjuterike në memorie… shpejtësi në memorie në petabajt të dhënash". Ai gjithashtu krenohet me shumë përparësi: një memorje të shpërndarë në memorie, ruajtjen më të shpejtë të çelësave dhe vlerave dhe memorjen e përkohshme, shkallëzueshmëri horizontale, disponueshmëri të lartë dhe integritet të fortë. Shkurt, rezulton se Ignite është më i shpejti.
Implementimet: Sberbank, American Airlines, Yahoo! Japan. Pastaj mësova se Ignite nuk ishte implementuar vetëm në Sberbank, por se ekipi i SberTech po dërgonte njerëzit e tij në ekipin e Ignite për të përsosur produktin. Kjo më magjepsi plotësisht dhe isha gati ta merrja Ignite-in.
Është plotësisht e paqartë pse, unë shikoj pikën e pestë.
lajthi
Unë shkoj në faqen e internetit , Po lexoj. Dhe rezulton se zgjidhja më e shpejtë e ruajtjes në memorje të shpërndarë është Hazelcast. Është shumë më e shpejtë se të gjitha zgjidhjet e tjera dhe është lider në hapësirën e rrjetit të të dhënave në memorie. Në këtë sfond, zgjedhja e çdo gjëje tjetër do të ishte mungesë respekti. Gjithashtu përdor ruajtje të tepërt të të dhënave për të siguruar funksionimin e vazhdueshëm të klasterit pa humbje të të dhënave.
Në rregull, jam gati të marr Hazelcastin.
krahasim
Por nëse i shikoni me kujdes, të pesë kandidatët janë aq të merituar sa secili prej tyre është më i miri. Si i zgjidhni? Mund të shohim se cili është më i popullarizuari, të kërkojmë krahasime dhe dhimbja e kokës do të zhduket.
Ne gjejmë të tilla , ne zgjedhim 5 sistemet tona.
Ja ku janë renditur: Redis është në krye, Hazelcast është në vendin e dytë, Tarantool dhe Ignite po fitojnë popullaritet, EhCache mbetet siç ishte.
Por le të shohim : lidhje me faqet e internetit, interes i përgjithshëm për sistemin, oferta pune—shumë mirë! Pra, kur sistemi im rrëzohet, them: "Jo, është i besueshëm! Ka shumë oferta pune..." Një krahasim kaq i thjeshtë nuk do të funksionojë.
Të gjitha këto sisteme nuk janë thjesht sisteme të ruajtjes në memorje. Ato kanë shumë më tepër funksionalitet, duke përfshirë aftësinë për të transferuar të dhëna te klienti për përpunim në vend që t'i transferojnë ato vetëm në server. Kodi që duhet të ekzekutohet në të dhëna dërgohet në server, ekzekutohet atje dhe rezultati kthehet. Dhe ato nuk konsiderohen shpesh si një sistem i pavarur i ruajtjes në memorje.
Në rregull, le të mos dorëzohemi. Le të gjejmë një krahasim të drejtpërdrejtë të sistemeve. Le të marrim dy opsionet kryesore - Redis dhe Hazelcast. Ne jemi të interesuar në shpejtësi, kështu që do t'i krahasojmë ato duke përdorur atë metrikë.
Hz kundrejt Redis
Ne e gjejmë këtë :
Blu është Redis, e kuqja është Hazelcast. Hazelcast fiton në të gjitha fushat, dhe për një arsye të mirë: është me shumë fije dhe shumë i optimizuar, me çdo fije që punon në ndarjen e vet, duke eliminuar bllokimet. Redis, nga ana tjetër, është me një fije dhe nuk përfiton nga CPU-të moderne me shumë bërthama. Hazelcast përdor I/O asinkrone, ndërsa Redis-Jedis përdor soketa bllokuese. Së fundmi, Hazelcast përdor një protokoll binar, ndërsa Redis është i orientuar drejt tekstit, që do të thotë se është joefikas.
Për çdo rast, le të kalojmë te një burim tjetër krahasimi. Çfarë do të na tregojë ai?
Redis kundrejt Hz
Edhe një gjë :
Këtu, e kundërta është e vërtetë: ngjyra e kuqe është Redis. Kjo do të thotë që Redis ia kalon Hazelcast për sa i përket performancës. Në krahasimin e parë, Hazelcast fitoi, ndërsa në të dytin, Redis fitoi. Ata shpjeguan shumë saktë pse fitoi Hazelcast në krahasimin e mëparshëm.
Rezulton se rezultati i parë ishte në fakt i manipuluar: Redis ishte përfshirë në paketën bazë, ndërsa Hazelcast ishte përshtatur për rastin e testimit. Pra, së pari, nuk mund t'i besojmë askujt dhe, së dyti, pasi të zgjedhim më në fund një sistem, na duhet ta konfigurojmë atë saktë. Këto cilësime përfshijnë dhjetëra, pothuajse qindra parametra.
Tunde shishen
Dhe mund ta shpjegoj të gjithë procesin që sapo përfunduam me metaforën e "tundjes së një shisheje". Domethënë, nuk keni nevojë të programoni tani; gjëja më e rëndësishme tani është të jeni në gjendje të lexoni Stack Overflow. Dhe kam një profesionist në ekipin tim që bën pikërisht këtë në momente kritike.
Çfarë bën ai? Ai sheh një gjë të prishur, sheh një gjurmë të stack-ut, merr disa fjalë prej saj (cilat saktësisht janë ekspertiza e tij në program), e kërkon në Google dhe gjen Stack Overflow midis përgjigjeve. Pa lexuar ose menduar, midis përgjigjeve të pyetjes, ai zgjedh diçka që i ngjan më shumë një sugjerimi për të "bërë këtë dhe atë" (zgjedhja e një përgjigjeje të tillë është talenti i tij, pasi nuk është gjithmonë përgjigjja me më shumë pëlqime), e zbaton atë, kontrollon: nëse diçka ka ndryshuar, atëherë shkëlqyeshëm. Nëse asgjë nuk ka ndryshuar, ne e anulojmë atë. Dhe përsërisim nisjen-kontrollin-kërkimin. Dhe në këtë mënyrë intuitive, ai e vë kodin në punë pas një farë kohe. Ai nuk e di pse, nuk e di çfarë bëri, nuk mund ta shpjegojë. Por! Kjo gjë funksionon. Dhe "zjarri është shuar". Tani e kuptojmë se çfarë bëmë. Kur programi funksionon, është shumë më e lehtë. Dhe kursen shumë kohë.
Kjo metodë shpjegohet shumë mirë me shembullin e mëposhtëm.
Dikur ishte shumë e zakonshme të ndërtoje një varkë me vela në shishe. Megjithatë, varka me vela është e madhe dhe e brishtë, dhe qafa e shishes është aq e ngushtë sa nuk futet dot brenda. Si ndërtohet një e tillë?
Ekziston një metodë e tillë, shumë e shpejtë dhe shumë efektive.
Anija është bërë nga një mori gjërash të vogla: shkopinj, spango, vela, ngjitës. Ne i vendosim të gjitha këto në shishe.
E marrim shishen me të dyja duart dhe fillojmë ta tundim. E tundim e tundim. Dhe zakonisht, sigurisht, del krejtësisht pa vlerë. Por ndonjëherë. Ndonjëherë del të jetë një anije! Ose më saktë, diçka që duket si një anije.
Ia tregojmë këtë diçka dikujt: "Seryoga, e sheh!?" Dhe me të vërtetë, nga larg, duket si një anije. Por nuk mund ta lëmë të shkojë më tej.
Ka një mënyrë tjetër. Njerëzit më të përparuar, si hakerat, e përdorin atë.
I jep këtij djali një detyrë, ai e kryen dhe pastaj largohet. Dhe shikon - pak a shumë është bërë. Por pas një kohe, kur duhet ta përsosësh kodin, fillojnë të ndodhin të gjitha llojet e gjërave për shkak të tij... Është mirë që ia doli të ikte larg. Këta janë lloji i djemve që, duke përdorur një shishe si shembull, do ta bënin këtë: shiko, aty ku është fundi, qelqi përkulet. Dhe nuk është plotësisht e qartë nëse është transparent apo jo. Kështu që "hakerat" e prenë pjesën e poshtme, fusin një anije atje, pastaj e ngjisin përsëri pjesën e poshtme dhe është sikur të ishte e destinuar të ishte.
Nga një perspektivë zgjidhjeje problemesh, gjithçka duket e saktë. Por duke marrë shembull anijet: pse të ndërtohet kjo anije? Kujt i duhet gjithsesi? Nuk shërben për asnjë qëllim. Anije të tilla zakonisht janë dhurata për individë shumë të rangut të lartë, të cilët i vendosin ato në një raft sipër vetes si simbol, një shenjë. Po sikur një person i tillë, një drejtues i madh biznesi ose një zyrtar i rangut të lartë, të kishte një punë të tillë, me qafën e prerë, të varur si një flamur? Do të ishte më mirë sikur të mos e dinin kurrë për këtë. Pra, si i bëjnë në fund të fundit këto anije që mund t'i dhurohen një personi të rëndësishëm?
E vetmja pjesë kyçe që nuk mund të ndërhyhet është trupi i anijes. Trupi i anijes përshtatet tamam në qafën e shishes, ndërsa anija montohet jashtë shishes. Por nuk është thjesht montimi i një anijeje; është një kryevepër e vërtetë. Leva të posaçme shtohen në pjesët përbërëse, duke lejuar që ato të ngrihen më vonë. Për shembull, velat palosen, futen me kujdes brenda dhe më pas, me piskatore, tërhiqen dhe ngrihen me saktësi dhe precizion të madh. Rezultati është një vepër arti që mund të jepet si dhuratë me ndërgjegje dhe krenari të pastër.
Dhe nëse duam që një projekt të jetë i suksesshëm, duhet të ketë të paktën një argjendar në ekip. Dikush që kujdeset për cilësinë e produktit dhe që merr në konsideratë të gjitha aspektet, pa sakrifikuar asnjërin, madje edhe në kohë stresi, kur rrethanat kërkojnë që urgjentja të bëhet në kurriz të së rëndësishmes. Të gjitha projektet e suksesshme që janë të qëndrueshme dhe i kanë rezistuar kohës janë ndërtuar mbi këtë parim. Ka diçka shumë të saktë dhe unike në lidhje me to, diçka që shfrytëzon çdo mundësi të disponueshme. Në shembullin e anijes në një shishe, trupi kalon nëpër qafën e shishes, duke luajtur me faktin se trupi i anijes kalon nëpër qafën e shishes.
Duke u kthyer te detyra e zgjedhjes së serverit tonë të ruajtjes në memorje, si mund të zbatohet kjo qasje? Unë propozoj këtë qasje për të zgjedhur nga të gjitha sistemet e disponueshme: në vend që të tundim shishen dhe të zgjedhim, duhet të shohim se çfarë kanë të përbashkët dhe çfarë të kërkojmë kur zgjedhim një sistem.
Ku të kërkoni për një bllokim
Le të përpiqemi të mos e tundim shishen ose të kalojmë nëpër gjithçka një nga një, por të shqyrtojmë sfidat që lindin nëse do ta projektonim vetë një sistem të tillë, të përshtatur sipas nevojave tona. Sigurisht, nuk do të montojmë një biçikletë, por do ta përdorim këtë diagram për të na ndihmuar të kuptojmë se çfarë duhet të kërkojmë në përshkrimet e produkteve. Le të skicojmë diagramin e mëposhtëm.
Nëse sistemi është i shpërndarë, atëherë do të kemi servera të shumtë (6). Le të themi katër (është e përshtatshme t'i vendosni në figurë, por sigurisht, mund të ketë aq sa dëshironi). Nëse serverat janë në nyje të ndryshme, atëherë të gjithë ekzekutojnë një kod që siguron që këto nyje të formojnë një grumbull dhe, në rast të një ndërprerjeje, të lidhen dhe të njohin njëra-tjetrën.
Gjithashtu na duhet një logjikë e ruajtjes në memorje (cache) (2), e cila është ajo që në të vërtetë merret me ruajtjen në memorje. Klientët bashkëveprojnë me këtë kod nëpërmjet një API-je. Kodi i klientit (1) mund të jetë brenda të njëjtës JVM ose të aksesohet nëpërmjet rrjetit. Logjika e zbatuar brenda tij vendos se cilat objekte duhen mbajtur në memorje dhe cilat duhen hedhur poshtë. Ne përdorim memorien (3) për të ruajtur memorjen në memorje, por nëse është e nevojshme, mund të ruajmë edhe disa të dhëna në disk (4).
Le të shohim se ku do të ndodhë ngarkesa. Në thelb, çdo shigjetë dhe çdo nyje do t'i nënshtrohet ngarkesës. Së pari, midis kodit të klientit dhe API-t, nëse është bashkëveprim rrjeti, rënia mund të jetë mjaft e dukshme. Së dyti, brenda vetë API-t, nëse e teprojmë me logjikë komplekse, mund të godasim CPU-në. Do të ishte mirë nëse logjika nuk do të harxhonte memorie pa nevojë. Dhe pastaj është bashkëveprimi i sistemit të skedarëve - zakonisht, serializimi/rivendosja dhe shkrimi/leximi.
Më pas vjen ndërveprimi me klasterin. Ka shumë të ngjarë që të jetë në të njëjtin sistem, por mund të jetë edhe i ndarë. Edhe këtu duhet të marrim në konsideratë transferimin e të dhënave në të, shpejtësinë e serializimit të të dhënave dhe ndërveprimet brenda klasterit.
Tani, nga njëra anë, mund të imagjinojmë që rrotat rrotullohen në sistemin e memorjes së përkohshme kur përpunohen kërkesat nga kodi ynë, dhe nga ana tjetër, mund të vlerësojmë se çfarë lloji dhe sa kërkesa do të gjenerojë kodi ynë për këtë sistem. Kjo është e mjaftueshme për të bërë një zgjedhje pak a shumë të matur - duke zgjedhur një sistem që i përshtatet më së miri rastit tonë të përdorimit.
lajthi
Le të shohim se si zbatohet ky zbërthim në listën tonë. Për shembull, Hazelcast.
Për të vendosur/marrë të dhëna nga Hazelcast, kodi i klientit thërret (1) API-në. Hz ju lejon të ekzekutoni serverin si të integruar, në të cilin rast thirrja e API-t është një thirrje metode brenda JVM-së, e cila është falas.
Që logjika në (2) të funksionojë, Hz mbështetet në hash-in e vargut të bajteve të çelësit të serializuar - që do të thotë se çelësi do të serializohet në çdo rast. Ky është një mbingarkesë e pashmangshme për Hz.
Strategjitë e dëbimit janë zbatuar mirë, por për raste të veçanta, mund të shtoni tuajat. Nuk keni pse të shqetësoheni për këtë pjesë.
Hapësira e ruajtjes (4) mund të lidhet. Shkëlqyeshëm. Ndërveprimi (5) për sistemet e ngulitura mund të konsiderohet i menjëhershëm. Shkëmbimi i të dhënave midis nyjeve të klasterit (6) - po, ekziston. Kjo kontribuon në tolerancën e gabimeve në kurriz të shpejtësisë. Funksioni Hz Near-cache ndihmon në uljen e kostove - të dhënat e marra nga nyjet e tjera të klasterit do të ruhen në memorien e përkohshme.
Çfarë mund të bëhet në kushte të tilla për të rritur shpejtësinë?
Për shembull, për të shmangur serializimin e çelësave në (2), shtoni një memorje tjetër të përkohshme sipër Hazelcast për të dhënat më të nxehta. Sportmaster zgjodhi Caffeine për këtë qëllim.
Për akordimin e nivelit (6), Hz ofron dy lloje ruajtjeje: IMap dhe ReplicatedMap.
Vlen të përmendet se si Hazelcast hyri në grupin e teknologjisë Sportmaster.
Në vitin 2012, kur po punonim në prototipin e parë të faqes së internetit të së ardhmes, Hazelcast ishte lidhja e parë e kthyer nga një motor kërkimi. Ne u lidhëm menjëherë - u mahnitëm nga fakti që vetëm dy orë pasi instaluam Hz në sistem, ai po funksiononte. Dhe funksiononte mirë. Në fund të ditës, kishim mbaruar së shkruari disa teste dhe ishim të kënaqur. Dhe kjo rezervë energjie ishte e mjaftueshme për të kapërcyer surprizat që Hz na dha me kalimin e kohës. Tani ekipi i Sportmaster nuk ka arsye të heqë dorë nga Hazelcast.
Por argumente si "lidhja e parë në motorin e kërkimit" dhe "bashkimi i shpejtë i HelloWorld" janë, sigurisht, përjashtime dhe veçori të momentit kur është bërë zgjedhja. Testet e vërteta për sistemin e zgjedhur fillojnë me nisjen e prodhimit, dhe është kjo fazë që ia vlen t'i kushtohet vëmendje kur zgjidhni çdo sistem, përfshirë një memorje të përkohshme. Në fakt, në rastin tonë, mund të themi se zgjodhëm Hazelcast rastësisht, por më vonë doli të ishte zgjedhja e duhur.
Për prodhimin, faktorë shumë më të rëndësishëm përfshijnë monitorimin, ndërprerjen e funksionimit në nyje individuale, replikimin e të dhënave dhe kostot e shkallëzimit. Kjo do të thotë që ia vlen t'i kushtohet vëmendje sfidave që lindin gjatë mirëmbajtjes së sistemit - kur ngarkesa është dhjetëra herë më e lartë se sa ishte planifikuar, kur ngarkojmë aksidentalisht gjënë e gabuar në vendndodhjen e gabuar, kur duhet të vendosim një version të ri të kodit, të zëvendësojmë të dhënat dhe ta bëjmë këtë pa probleme pa e vënë re klientët.
Për të gjitha këto kërkesa, Hazelcast me siguri i plotëson kërkesat.
Vazhdon
Por Hazelcast nuk është ilaç për të gjitha problemet. Në vitin 2017, ne zgjodhëm Hazelcast për memorjen e panelit tonë të administratorit thjesht bazuar në një përshtypje pozitive nga përvoja e mëparshme. Kjo luajti një rol kyç në një shaka shumë mizore, e cila na futi në një situatë të vështirë dhe "heroikisht" na mori 60 ditë për t'u rikuperuar. Por më shumë për këtë në pjesën tjetër.
Deri atëherë… Gëzuar Kodin e Ri!
Burimi: www.habr.com
