Përshëndetje! Emri im është Alexey Pyankov, unë jam një zhvillues në kompaninë Sportmaster. Në atë Unë tregova se si filloi puna në faqen e internetit të Sportmaster në 2012, çfarë iniciativash arritëm të "përfundonim" dhe anasjelltas, çfarë rakete grumbulluam.
Sot dua të ndaj mendimet që ndjekin një temë tjetër - zgjedhjen e një sistemi memorie për backend-in java në panelin e administratorit të faqes. Ky komplot ka një domethënie të veçantë për mua - megjithëse historia u zhvillua vetëm për 2 muaj, gjatë këtyre 60 ditëve ne punuam 12-16 orë dhe pa asnjë ditë pushim. Nuk e kisha menduar apo imagjinuar kurrë se ishte e mundur të punoja kaq shumë.
Prandaj, e ndaj tekstin në 2 pjesë për të mos e ngarkuar plotësisht. Përkundrazi, pjesa e parë do të jetë shumë e lehtë - përgatitja, prezantimi, disa konsiderata se çfarë është caching. Nëse jeni tashmë një zhvillues me përvojë ose keni punuar me cache, nga ana teknike ka shumë të ngjarë që nuk do të ketë asgjë të re në këtë artikull. Por për një junior, një rishikim kaq i vogël mund t'i tregojë se në cilin drejtim duhet të shikojë nëse e gjen veten në një udhëkryq të tillë.
Kur u vu në prodhim versioni i ri i faqes së internetit Sportmaster, të dhënat u morën në një mënyrë që, për ta thënë butë, jo shumë të përshtatshme. Baza ishin tabelat e përgatitura për versionin e mëparshëm të faqes (Bitrix), të cilat duhej të tërhiqeshin në ETL, të silleshin në një formë të re dhe të pasuroheshin me gjëra të ndryshme të vogla nga një duzinë sisteme të tjera. Në mënyrë që një fotografi e re ose përshkrimi i produktit të shfaqej në faqe, duhej të prisnit deri ditën tjetër - përditësime vetëm natën, një herë në ditë.
Në fillim, kishte kaq shumë shqetësime që në javët e para të hyrjes në prodhim, saqë shqetësime të tilla për menaxherët e përmbajtjes ishin një gjë e vogël. Por, sapo gjithçka u vendos, zhvillimi i projektit vazhdoi - disa muaj më vonë, në fillim të vitit 2015, filluam të zhvillojmë në mënyrë aktive panelin e administratorit. Në 2015 dhe 2016, gjithçka po shkon mirë, ne lëshojmë rregullisht, paneli i administratorit mbulon gjithnjë e më shumë përgatitjen e të dhënave dhe po përgatitemi për faktin që së shpejti ekipit tonë do t'i besohet gjëja më e rëndësishme dhe komplekse - produkti. qark (përgatitja e plotë dhe mirëmbajtja e të dhënave për të gjitha produktet). Por në verën e vitit 2017, pak para nisjes së qarkut të mallrave, projekti do të gjendet në një situatë shumë të vështirë - pikërisht për shkak të problemeve me caching. Dua të flas për këtë episod në pjesën e dytë të këtij botimi dypjesësh.
Por në këtë postim do të filloj nga larg, do të paraqes disa mendime - ide rreth caching, të cilat do të ishin një hap i mirë për të lëvizur përpara një projekti të madh.
Kur ndodh një detyrë memorie
Detyra e memorizimit nuk shfaqet vetëm. Ne jemi zhvillues, duke shkruar një produkt softuerësh dhe duam që ai të jetë në kërkesë. Nëse produkti është i kërkuar dhe i suksesshëm, përdoruesit do të vijnë. Dhe gjithnjë e më shumë vijnë. Dhe pastaj ka shumë përdorues dhe më pas produkti bëhet shumë i ngarkuar.
Në fazat e para, ne nuk mendojmë për optimizimin dhe performancën e kodit. Gjëja kryesore është funksionaliteti, nxjerrja e shpejtë e një pilot dhe testimi i hipotezave. Dhe nëse ngarkesa rritet, ne pompojmë hekurin. E rrisim dy-tre herë, pesë herë, ndoshta 10 herë. Diku këtu - financat nuk do ta lejojnë më. Sa herë do të rritet numri i përdoruesve? Nuk do të jetë si 2-5-10, por nëse ka sukses, do të jetë nga 100-1000 në 100 mijë herë. Kjo do të thotë, herët a vonë, do t'ju duhet të bëni optimizim.
Le të themi se një pjesë e kodit (le ta quajmë këtë pjesë një funksion) kërkon një kohë të pahijshme të gjatë, dhe ne duam të zvogëlojmë kohën e ekzekutimit. Një funksion mund të jetë qasja në një bazë të dhënash, ose mund të jetë ekzekutimi i ndonjë logjike komplekse - gjëja kryesore është se kërkon shumë kohë për t'u përfunduar. Sa mund ta zvogëloni kohën e ekzekutimit? Në kufi, ju mund ta zvogëloni atë në zero, jo më tej. Si mund ta reduktoni kohën e ekzekutimit në zero? Përgjigje: eliminoni fare ekzekutimin. Në vend të kësaj, kthejeni menjëherë rezultatin. Si mund ta zbuloni rezultatin? Përgjigje: ose llogarisni ose shikoni diku. Duhet shumë kohë për të llogaritur. Dhe të spiunosh është, për shembull, të kujtosh rezultatin që funksioni prodhoi herën e fundit kur thirrej me të njëjtat parametra.
Domethënë, zbatimi i funksionit nuk është i rëndësishëm për ne. Mjafton vetëm të dimë se nga cilat parametra varet rezultati. Më pas, nëse vlerat e parametrave përfaqësohen në formën e një objekti që mund të përdoret si çelës në disa ruajtje, atëherë rezultati i llogaritjes mund të ruhet dhe të lexohet herën tjetër që të aksesohet. Nëse ky shkrim dhe lexim i rezultatit është më i shpejtë se ekzekutimi i funksionit, kemi një fitim për nga shpejtësia. Shuma e fitimit mund të arrijë 100, 1000 dhe 100 mijë herë (10^5 është më tepër një përjashtim, por në rastin e një baze mjaft të vonuar, është mjaft e mundur).
Kërkesat themelore për një sistem memorie
Gjëja e parë që mund të bëhet një kërkesë për një sistem memorie është shpejtësia e shpejtë e leximit dhe, në një masë më të vogël, shpejtësia e shkrimit. Kjo është e vërtetë, por vetëm derisa ta nxjerrim sistemin në prodhim.
Le të luajmë këtë rast.
Le të themi se kemi siguruar ngarkesën aktuale me harduer dhe tani po prezantojmë gradualisht caching. Numri i përdoruesve rritet pak, ngarkesa rritet - ne shtojmë pak cache, e vidhosim aty-këtu. Kjo vazhdon për ca kohë, dhe tani funksionet e rënda praktikisht nuk thirren më - e gjithë ngarkesa kryesore bie në cache. Numri i përdoruesve gjatë kësaj kohe është rritur N herë.
Dhe nëse furnizimi fillestar i harduerit mund të jetë 2-5 herë, atëherë me ndihmën e cache-it mund të përmirësojmë performancën me një faktor 10 ose, në një rast të mirë, me një faktor prej 100, në disa vende ndoshta me një faktor prej 1000. Kjo do të thotë, në të njëjtin harduer – ne përpunojmë 100 herë më shumë kërkesa. E shkëlqyeshme, ju e meritoni bukën me xhenxhefil!
Por tani, në një moment të mirë, rastësisht, sistemi u rrëzua dhe cache u shemb. Asgjë e veçantë - në fund të fundit, cache u zgjodh bazuar në kërkesën "shpejtësi të lartë të leximit dhe shkrimit, pjesa tjetër nuk ka rëndësi".
Në lidhje me ngarkesën fillestare, rezerva jonë e hekurit ishte 2-5 herë, dhe ngarkesa gjatë kësaj kohe u rrit 10-100 herë. Duke përdorur cache, ne eliminuam thirrjet për funksione të rënda dhe për këtë arsye gjithçka funksionoi. Dhe tani, pa një cache, sa herë do të ngadalësohet sistemi ynë? Çfarë do të ndodhë me ne? Sistemi do të bjerë.
Edhe nëse cache-ja jonë nuk u rrëzua, por u fshi vetëm për një kohë, do të duhet të ngrohet dhe kjo do të marrë pak kohë. Dhe gjatë kësaj kohe, barra kryesore do të bjerë mbi funksionalitetin.
Përfundim: projektet e prodhimit me ngarkesë të lartë kërkojnë një sistem memorie jo vetëm që të ketë shpejtësi të larta leximi dhe shkrimi, por edhe për të siguruar sigurinë e të dhënave dhe rezistencën ndaj dështimeve.
Miell i zgjedhur
Në një projekt me një panel admin, zgjedhja shkoi kështu: fillimisht instaluam Hazelcast, sepse Ne ishim të njohur tashmë me këtë produkt nga përvoja e faqes kryesore. Por këtu kjo zgjedhje doli të jetë e pasuksesshme - nën profilin tonë të ngarkesës, Hazelcast nuk është thjesht i ngadaltë, por tmerrësisht i ngadalshëm. Dhe në atë kohë ne ishim regjistruar tashmë për datën e lëshimit.
Spoiler: si u zhvilluan saktësisht rrethanat që ne humbëm një punë kaq të madhe dhe përfunduam në një situatë akute dhe të tensionuar - do t'ju tregoj në pjesën e dytë - dhe si përfunduam dhe si dolëm. Por tani - do të them vetëm se ishte shumë stres, dhe "të mendosh - disi nuk mund të mendoj, ne po tundim shishen". "Tundja e shishes" është gjithashtu një spoiler, më shumë për këtë më vonë.
Çfarë bëmë:
- Ne bëjmë një listë të të gjitha sistemeve që sugjerojnë Google dhe StackOverflow. Pak më shumë se 30
- Ne shkruajmë teste me një ngarkesë tipike për prodhim. Për ta bërë këtë, ne regjistruam të dhëna që kalojnë nëpër sistem në një mjedis prodhimi - një lloj sniffer për të dhënat jo në rrjet, por brenda sistemit. Pikërisht këto të dhëna janë përdorur në teste.
- Me të gjithë ekipin, të gjithë zgjedhin sistemin tjetër nga lista, e konfigurojnë atë dhe kryejnë teste. Nuk e kalon provën, nuk e mban ngarkesën - e hedhim dhe kalojmë te tjetra në radhë.
- Në sistemin e 17-të u bë e qartë se gjithçka ishte e pashpresë. Mos e tundni shishen, është koha të mendoni seriozisht.
Por ky është një opsion kur ju duhet të zgjidhni një sistem që do të "kalojë shpejtësinë" në testet e parapërgatitura. Po nëse nuk ka ende teste të tilla dhe dëshironi të zgjidhni shpejt?
Le të modelojmë këtë opsion (është e vështirë të imagjinohet që një zhvillues i mesëm+ jeton në vakum dhe në kohën e përzgjedhjes nuk e ka zyrtarizuar ende preferencën e tij se cilin produkt të provojë më parë - prandaj, arsyetimi i mëtejshëm është më shumë një teoricien/filozofi/ rreth një junior).
Pasi të kemi vendosur për kërkesat, le të fillojmë të zgjedhim një zgjidhje jashtë kutisë. Pse të rishpikni rrotën: do të shkojmë dhe do të marrim një sistem të gatshëm të memorizimit.
Nëse sapo po filloni dhe e kërkoni në google, atëherë jepni ose merrni porosinë, por në përgjithësi, udhëzimet do të jenë të tilla. Para së gjithash do të hasni në Redis, dëgjohet gjithandej. Atëherë do të zbuloni se EhCache është sistemi më i vjetër dhe më i provuar. Më pas do të shkruajmë për Tarantool, një zhvillim vendas që ka një aspekt unik të zgjidhjes. Dhe gjithashtu Ignite, sepse tani është në rritje të popullaritetit dhe gëzon mbështetjen e SberTech. Në fund është edhe Hazelcast, sepse në botën e sipërmarrjeve shfaqet shpesh në mesin e kompanive të mëdha.
Lista nuk është shteruese; ka dhjetëra sisteme. Dhe ne do të vidhosim vetëm një gjë. Le të marrim 5 sistemet e përzgjedhura për "konkursin e bukurisë" dhe të bëjmë një përzgjedhje. Kush do të jetë fituesi?
Redis
Lexojmë se çfarë shkruajnë në faqen zyrtare.
- projekt me burim të hapur. Ofron ruajtjen e të dhënave në memorie, aftësinë për të ruajtur në disk, ndarje automatike, disponueshmëri të lartë dhe rikuperim nga ndërprerjet e rrjetit.
Duket se gjithçka është në rregull, mund ta merrni dhe ta vidhni - gjithçka që ju nevojitet, bën. Por thjesht për argëtim, le të shohim kandidatët e tjerë.
EhCache
- "cache më e përdorur për Java" (përkthimi i sloganit nga faqja zyrtare e internetit). Gjithashtu opensource. Dhe atëherë e kuptojmë që Redis nuk është për java, por i përgjithshëm, dhe për të bashkëvepruar me të ju duhet një mbështjellës. Dhe EhCache do të jetë më i përshtatshëm. Çfarë tjetër premton sistemi? Besueshmëri, e provuar, funksionalitet i plotë. Epo, është gjithashtu më e zakonshme. Dhe ruan terabajt të dhëna.
Redis është harruar, unë jam gati të zgjedh EhCache.
Por një ndjenjë patriotizmi më shtyn të shoh se çfarë është e mirë për Tarantool.
Tarantool
- plotëson përcaktimin “Platforma e integrimit të të dhënave në kohë reale”. Tingëllon shumë e ndërlikuar, kështu që ne lexojmë faqen në detaje dhe gjejmë një deklaratë me zë të lartë: "Caches 100% të të dhënave në RAM". Kjo duhet të ngrejë pyetje - në fund të fundit, mund të ketë shumë më tepër të dhëna sesa memorie. Shpjegimi është se kjo do të thotë që Tarantool nuk ekzekuton serializimin për të shkruar të dhëna në disk nga memoria. Në vend të kësaj, ai përdor veçori të nivelit të ulët të sistemit, kur memoria thjesht lidhet me një sistem skedari me performancë shumë të mirë I/O. Në përgjithësi, ata bënë diçka të mrekullueshme dhe të lezetshme.
Le të shohim zbatimet: autostrada e korporatës Mail.ru, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...
Nëse kishte akoma dyshime për Tarantool, atëherë rasti i zbatimit në Mastercard më përfundon. Unë marr Tarantool.
Por gjithsesi…
Ndez
… ka më shumë , është faturuar si një "platformë informatike në memorie... shpejtësi në memorie në petabajt të dhënash". Ka gjithashtu shumë përparësi këtu: cache e shpërndarë në memorie, ruajtja dhe cache më e shpejtë me vlerë kyçe, shkallëzim horizontal, disponueshmëri e lartë, integritet i rreptë. Në përgjithësi, rezulton se më i shpejti është Ignite.
Zbatimet: Sberbank, American Airlines, Yahoo! Japonia. Dhe më pas zbuloj se Ignite nuk zbatohet vetëm në Sberbank, por ekipi SberTech i dërgon njerëzit e tij te vetë ekipi Ignite për të rafinuar produktin. Kjo është plotësisht magjepsëse dhe unë jam gati të marr Ignite.
Është plotësisht e paqartë pse, po shikoj pikën e pestë.
lajthi
Shkoj në sit , duke lexuar. Dhe rezulton se zgjidhja më e shpejtë për caching të shpërndarë është Hazelcast. Është urdhra madhësie më i shpejtë se të gjitha zgjidhjet e tjera dhe në përgjithësi është lider në fushën e rrjetit të të dhënave në memorie. Në këtë sfond, të marrësh diçka tjetër nuk do të thotë të respektosh veten. Ai gjithashtu përdor ruajtjen e tepërt të të dhënave për funksionimin e vazhdueshëm të grupit pa humbje të të dhënave.
Kjo është ajo, unë jam gati të marr Hazelcast.
krahasim
Por nëse shikoni, të pesë kandidatët përshkruhen në atë mënyrë që secili prej tyre të jetë më i miri. Si të zgjidhni? Mund të shohim se cila është më e njohura, të kërkojmë krahasime dhe dhimbja e kokës do të largohet.
Ne gjejmë një të tillë , zgjidhni 5 sistemet tona.
Këtu janë renditur: Redis është në krye, Hazelcast është në vendin e dytë, Tarantool dhe Ignite po fitojnë popullaritet, EhCache ka qenë dhe mbetet i njëjtë.
Por le të shohim : lidhjet me faqet e internetit, interesi i përgjithshëm për sistemin, ofertat e punës - fantastike! Kjo do të thotë, kur sistemi im dështon, unë do të them: "Jo, është i besueshëm! Ka shumë oferta pune…” Një krahasim kaq i thjeshtë nuk do të bëjë.
Të gjitha këto sisteme nuk janë vetëm sisteme cache. Ata gjithashtu kanë shumë funksionalitet, duke përfshirë kur të dhënat nuk pompohen te klienti për përpunim, por anasjelltas: kodi që duhet të ekzekutohet në të dhënat lëviz në server, ekzekutohet atje dhe rezultati kthehet. Dhe ato nuk konsiderohen aq shpesh si një sistem i veçantë për ruajtjen e memories.
Mirë, 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 për shpejtësinë dhe ne do t'i krahasojmë ato bazuar në këtë parametër.
Hz vs Redis
Ne e gjejmë këtë :
Blu është Redis, e kuqja është Hazelcast. Hazelcast fiton kudo dhe ka një arsyetim për këtë: është me shumë fije, shumë i optimizuar, çdo fije funksionon me ndarjen e vet, kështu që nuk ka bllokime. Dhe Redis është me një fije; nuk përfiton nga CPU-të moderne me shumë bërthama. Hazelcast ka hyrje/dalje asinkrone, Redis-Jedis ka priza bllokuese. Në fund të fundit, Hazelcast përdor një protokoll binar dhe Redis është në qendër të tekstit, që do të thotë se është joefikas.
Për çdo rast, le t'i drejtohemi një burimi tjetër krahasimi. Çfarë do të na tregojë ai?
Redis vs Hz
Një tjetër :
Këtu, përkundrazi, e kuqja është Redis. Kjo do të thotë, Redis tejkalon Hazelcast për sa i përket performancës. Hazelcast fitoi krahasimin e parë, Redis fitoi të dytin. shpjegoi shumë saktë pse Hazelcast fitoi krahasimin e mëparshëm.
Rezulton se rezultati i të parës ishte në të vërtetë i manipuluar: Redis u mor në kutinë bazë dhe Hazelcast u përshtat për një rast testimi. Pastaj rezulton: së pari, ne nuk mund t'i besojmë askujt, dhe së dyti, kur më në fund zgjedhim një sistem, ne ende duhet ta konfigurojmë saktë. Këto cilësime përfshijnë dhjetëra, pothuajse qindra parametra.
Duke tundur shishen
Dhe mund ta shpjegoj të gjithë procesin që kemi bërë tani me metaforën e mëposhtme: "Të tundim shishen". Kjo do të thotë, tani nuk keni nevojë të programoni, tani gjëja kryesore është të jeni në gjendje të lexoni stackoverflow. Dhe unë kam një person në ekipin tim, një profesionist, që punon pikërisht kështu në momente kritike.
Çfarë po bën ai? Ai sheh një gjë të prishur, sheh një gjurmë stiv, merr disa fjalë prej saj (cilat janë ekspertiza e tij në program), kërkon në Google, gjen stackoverflow midis përgjigjeve. Pa lexuar, pa menduar, midis përgjigjeve të pyetjes, ai zgjedh diçka më të ngjashme me fjalinë "bëj këtë dhe atë" (zgjedhja e një përgjigjeje të tillë është talenti i tij, sepse jo gjithmonë është përgjigjja që ka marrë më shumë pëlqime). vlen , duket: nëse diçka ka ndryshuar, atëherë shkëlqyeshëm. Nëse nuk ka ndryshuar, kthejeni përsëri. Dhe përsëris kërkimin e nisjes-kontrollit. Dhe në këtë mënyrë intuitive, ai siguron që kodi të funksionojë pas njëfarë kohe. Ai nuk e di pse, nuk e di se çfarë ka bërë, nuk mund të shpjegojë. Por! Ky infeksion funksionon. Dhe "zjarri është shuar". Tani le të kuptojmë se çfarë bëmë. Kur programi funksionon, është një renditje e madhësisë më e lehtë. Dhe kursen shumë kohë.
Kjo metodë shpjegohet shumë mirë me këtë shembull.
Dikur ishte shumë popullor për të mbledhur një varkë me vela në një shishe. Në të njëjtën kohë, varka me vela është e madhe dhe e brishtë, dhe qafa e shishes është shumë e ngushtë, është e pamundur ta shtyni brenda. Si ta montoni atë?
Ekziston një metodë e tillë, shumë e shpejtë dhe shumë efektive.
Anija përbëhet nga një tufë gjërash të vogla: shkopinj, litarë, vela, ngjitës. Të gjitha këto i vendosim në një shishe.
Marrim shishen me të dyja duart dhe fillojmë të tundim. E tundim dhe e tundim. Dhe zakonisht rezulton të jetë mbeturina e plotë, natyrisht. Por ndonjëherë. Ndonjëherë rezulton të jetë një anije! Më saktësisht, diçka e ngjashme me një anije.
I tregojmë dikujt këtë diçka: "Seryoga, a e sheh!" Dhe me të vërtetë, nga larg duket si një anije. Por kjo nuk mund të lejohet të vazhdojë.
Ka një mënyrë tjetër. Ato përdoren nga njerëz më të avancuar, siç janë hakerat.
I dhashë një detyrë këtij djali, ai bëri gjithçka dhe u largua. Dhe ju shikoni - duket sikur është bërë. Dhe pas pak, kur kodi duhet të finalizohet, kjo fillon për shkak të tij... Mirë që tashmë ka arritur të ikë shumë larg. Këta janë djemtë që, duke përdorur shembullin e një shishe, do ta bëjnë këtë: e shihni, ku është fundi, xhami përkulet. Dhe nuk është plotësisht e qartë nëse është transparente apo jo. Pastaj "hakerët" e prenë këtë fund, futin një anije atje, më pas ngjisin përsëri pjesën e poshtme, dhe është sikur kështu duhet të jetë.
Nga pikëpamja e vendosjes së problemit, gjithçka duket të jetë e saktë. Por duke përdorur anijet si shembull: pse ta bëni këtë anije fare, kujt i duhet gjithsesi? Nuk ofron asnjë funksionalitet. Zakonisht anije të tilla janë dhurata për njerëz shumë të lartë, të cilët e vendosin në një raft sipër tyre, si një lloj simboli, si shenjë. Dhe nëse një person i tillë, kreu i një biznesi të madh apo një zyrtar i lartë, si do të qëndrojë flamuri për një hak të tillë, të cilit i është prerë qafa? Do të ishte më mirë nëse ai kurrë nuk e dinte për këtë. Pra, si përfundojnë duke i bërë këto anije që mund t'i jepen një personi të rëndësishëm?
I vetmi vend kyç për të cilin nuk mund të bësh asgjë është trupi. Dhe byku i anijes përshtatet pikërisht në qafë. Ndërsa anija është montuar jashtë shishes. Por nuk është vetëm montimi i një anijeje, është një zanat i vërtetë bizhuterish. Përbërësve u shtohen leva speciale, të cilat më pas lejojnë ngritjen e tyre. Për shembull, velat palosen, futen brenda me kujdes dhe më pas, me ndihmën e piskatores, tërhiqen dhe ngrihen shumë saktë, me saktësi. Rezultati është një vepër arti që mund të dhurohet me një ndërgjegje të pastër dhe krenari.
Dhe nëse duam që projekti të jetë i suksesshëm, duhet të ketë të paktën një argjendari në ekip. Dikush që kujdeset për cilësinë e produktit dhe merr parasysh të gjitha aspektet, pa sakrifikuar asgjë, edhe në momentet e stresit, kur rrethanat kërkojnë të bëhet urgjenca në kurriz të të rëndësishmes. Të gjitha projektet e suksesshme që janë të qëndrueshme, që i kanë rezistuar kohës, janë ndërtuar mbi këtë parim. Ka diçka shumë të saktë dhe unike në to, diçka që përfiton nga të gjitha mundësitë e disponueshme. Në shembullin me anijen në shishe, luhet fakti që byka e anijes kalon nëpër qafë.
Duke iu rikthyer detyrës së zgjedhjes së serverit tonë të memorizimit, si mund të zbatohet kjo metodë? Unë ofroj këtë mundësi zgjedhjeje nga të gjitha sistemet që ekzistojnë - mos e tundni shishen, mos zgjidhni, por shikoni se çfarë kanë në parim, çfarë të kërkoni kur zgjidhni një sistem.
Ku të shikoni për qafën e shisheve
Le të përpiqemi të mos e tundim shishen, të mos kalojmë gjithçka që është atje një nga një, por le të shohim se çfarë problemesh do të lindin nëse befas, për detyrën tonë, projektojmë vetë një sistem të tillë. Sigurisht, ne nuk do ta montojmë biçikletën, por do të përdorim këtë diagram për të na ndihmuar të kuptojmë se cilat pika duhet t'i kushtojmë vëmendje në përshkrimet e produkteve. Le të skicojmë një diagram të tillë.
Nëse sistemi shpërndahet, atëherë do të kemi disa serverë (6). Le të themi se janë katër (është i përshtatshëm për t'i vendosur ato në foto, por, natyrisht, mund të ketë aq shumë sa të doni). Nëse serverët janë në nyje të ndryshme, kjo do të thotë se ata të gjithë ekzekutojnë një kod që është përgjegjës për të siguruar që këto nyje të formojnë një grup dhe, në rast prishjeje, të lidhen dhe të njohin njëri-tjetrin.
Ne gjithashtu kemi nevojë për logjikën e kodit (2), e cila në fakt ka të bëjë me caching. Klientët ndërveprojnë me këtë kod nëpërmjet disa API. Kodi i klientit (1) mund të jetë ose brenda të njëjtit JVM ose të hyjë në të përmes rrjetit. Logjika e zbatuar brenda është vendimi se cilat objekte të lihen në cache dhe cilat të hidhen jashtë. Ne përdorim memorien (3) për të ruajtur cache, por nëse është e nevojshme, mund të ruajmë disa nga të dhënat në disk (4).
Le të shohim se në cilat pjesë do të ndodhë ngarkesa. Në fakt, çdo shigjetë dhe çdo nyje do të ngarkohet. Së pari, midis kodit të klientit dhe api, nëse ky është komunikim në rrjet, ulja mund të jetë mjaft e dukshme. Së dyti, brenda kornizës së vetë api - nëse e teprojmë me logjikën komplekse, mund të hasim probleme me CPU-në. Dhe do të ishte mirë nëse logjika nuk do të humbiste kohë në kujtesë. Dhe mbetet ndërveprim me sistemin e skedarëve - në versionin e zakonshëm kjo është serializimi / rivendosja dhe shkrimi / leximi.
Tjetra është ndërveprimi me grupin. Me shumë mundësi, do të jetë në të njëjtin sistem, por mund të jetë veçmas. Këtu gjithashtu duhet të merrni parasysh transferimin e të dhënave në të, shpejtësinë e serializimit të të dhënave dhe ndërveprimet midis grupit.
Tani, nga njëra anë, ne mund të imagjinojmë "çfarë ingranazhesh do të rrotullohen" në sistemin e memories kur përpunohen kërkesat nga kodi ynë, dhe nga ana tjetër, ne mund të vlerësojmë se çfarë 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 - për të zgjedhur një sistem për rastin tonë të përdorimit.
lajthi
Le të shohim se si ta zbatojmë këtë dekompozim në listën tonë. Për shembull, Hazelcast.
Për të vendosur/marrë të dhëna nga Hazelcast, kodi i klientit akseson (1) në api. Hz ju lejon të ekzekutoni serverin si të integruar, dhe në këtë rast, qasja në api është një thirrje metodë brenda JVM, e cila mund të konsiderohet e lirë.
Në mënyrë që logjika në (2) të funksionojë, Hz mbështetet në hash-in e grupit të bajtit të çelësit të serializuar - domethënë, çelësi do të serializohet në çdo rast. Kjo është e pashmangshme për Hz.
Strategjitë e dëbimit zbatohen mirë, por për raste të veçanta mund të shtoni tuajat. Nuk duhet të shqetësoheni për këtë pjesë.
Magazinimi (4) mund të lidhet. E madhe. Ndërveprimi (5) për të integruar mund të konsiderohet i menjëhershëm. Shkëmbimi i të dhënave ndërmjet nyjeve në grup (6) - po, ekziston. Ky është një investim në tolerancën e gabimeve në kurriz të shpejtësisë. Tipari Hz Near-cache ju lejon të ulni çmimin - të dhënat e marra nga nyjet e tjera në grup do të ruhen në memorie.
Ç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ësit në (2) - bashkëngjitni një cache tjetër në krye të Hazelcast, për të dhënat më të nxehta. Sportmaster zgjodhi Kafeinën për këtë qëllim.
Për përdredhje në nivelin (6), Hz ofron dy lloje të ruajtjes: IMap dhe ReplicatedMap.
Vlen të përmendet se si Hazelcast hyri në grupin e teknologjisë Sportmaster.
Në vitin 2012, kur po punonim në pilotin e parë të faqes së ardhshme, ishte Hazelcast që doli të ishte lidhja e parë që ktheu motori i kërkimit. Njohja filloi "herën e parë" - ne u mahnitëm nga fakti se vetëm dy orë më vonë, kur vidhosëm Hz në sistem, ai funksionoi. Dhe funksionoi mirë. Në fund të ditës kishim përfunduar një sërë testesh dhe ishim të lumtur. Dhe kjo rezervë energjie mjaftoi për të kapërcyer të papriturat që Hz hodhi me kalimin e kohës. Tani skuadra Sportmaster nuk ka asnjë arsye për të braktisur Hazelcast.
Por argumente të tilla si "lidhja e parë në motorin e kërkimit" dhe "HelloWorld u mblodh shpejt" janë, natyrisht, një përjashtim dhe një veçori e momentit në të cilin u bë zgjedhja. Testet e vërteta për sistemin e zgjedhur fillojnë me lëshimin në prodhim, dhe është në këtë fazë që duhet t'i kushtoni vëmendje kur zgjidhni ndonjë sistem, përfshirë cache. Në fakt, në rastin tonë mund të themi se zgjodhëm rastësisht Hazelcast, por më pas doli që zgjodhëm saktë.
Për prodhimin, shumë më e rëndësishme: monitorimi, trajtimi i dështimeve në nyjet individuale, përsëritja e të dhënave, kostoja e shkallëzimit. Kjo do të thotë, ia vlen t'i kushtohet vëmendje detyrave që do të lindin gjatë mirëmbajtjes së sistemit - kur ngarkesa është dhjetëra herë më e lartë se sa ishte planifikuar, kur ngarkojmë aksidentalisht diçka në vendin e gabuar, kur duhet të nxjerrim një version të ri të kodit, zëvendësoni të dhënat dhe bëjeni atë pa u vënë re për klientët.
Për të gjitha këto kërkesa, Hazelcast sigurisht i përshtatet faturave.
Vazhdon
Por Hazelcast nuk është një ilaç. Në vitin 2017, ne zgjodhëm Hazelcast për memorien e administratorit, thjesht bazuar në përshtypjet e mira nga përvoja e kaluar. Kjo luajti një rol kyç në një shaka shumë mizore, për shkak të së cilës u gjendëm në një situatë të vështirë dhe "heroikisht" dolëm prej saj për 60 ditë. Por më shumë për këtë në pjesën tjetër.
Ndërkohë... Gëzuar Kodin e Ri!
Burimi: www.habr.com