Përshëndetje! Unë quhem Aleksey Pyankov, jam zhvillues në kompaninë Sportmaster. Në këtë unë tregova se si filloi puna për faqen e Sportmaster në vitin 2012, cilat iniciativa arritëm të "shtyjmë" dhe, përkundrazi, cilat pengesa mblodhëm.
Sot dua tĂ« ndaj mendimet e mia qĂ« vijnĂ« nga njĂ« histori tjetĂ«r â zgjedhja e sistemit tĂ« caching pĂ«r backend-in java nĂ« administratĂ«n e faqes. Kjo histori ka njĂ« rĂ«ndĂ«si tĂ« veçantĂ« pĂ«r mua â ndonĂ«se e gjithĂ« historia zhvillohej pĂ«r vetĂ«m 2 muaj, kĂ«to 60 ditĂ« punuam nga 12-16 orĂ« pa asnjĂ« ditĂ« pushimi. KurrĂ« mĂ« parĂ« nuk kisha menduar dhe as imagjinuar se mund tĂ« punosh kaq shumĂ«.
Prandaj, tekstin e ndaj nĂ« 2 pjesĂ«, qĂ« tĂ« mos ngarkojmĂ« plotĂ«sisht. PĂ«rkundrazi, pjesa e parĂ« do tĂ« jetĂ« shumĂ« e lehtĂ« â njĂ« pĂ«rgatitje, njĂ« hyrje, disa reflektime mbi atĂ« se ç'Ă«shtĂ« caching. NĂ«se ju jeni tashmĂ« njĂ« zhvillues me pĂ«rvojĂ« ose keni punuar me cache, nga ana teknike, pĂ«r tĂ«, ndoshta nuk do tĂ« ketĂ« asgjĂ« tĂ« re nĂ« kĂ«tĂ« artikull. Por pĂ«r njĂ« junior, njĂ« pĂ«rmbledhje e tillĂ« mund tĂ« tregojĂ« nĂ« çfarĂ« drejtimi tĂ« shikoni nĂ«se ndodhet nĂ« njĂ« kryqĂ«zim tĂ« tillĂ«.
Kur versioni i ri i faqes Sportmaster u lançua nĂ« produksion, tĂ« dhĂ«nat mbĂ«rrinin nĂ« njĂ« mĂ«nyrĂ« qĂ«, tĂ« themi, nuk ishte shumĂ« e kĂ«ndshme. Baza pĂ«rbĂ«hej nga tabela tĂ« pĂ«rgatitura pĂ«r versionin e kaluar tĂ« faqes (Bitrix), tĂ« cilat duhej tĂ« ngarkoheshin nĂ« ETL, tĂ« silleshin nĂ« njĂ« pamje tĂ« re dhe tĂ« pasuroheshin me lloje tĂ« ndryshme nga dhjetra sisteme tĂ« tjera. QĂ« njĂ« foto e re ose pĂ«rshkrimi i produktit tĂ« shfaqej nĂ« faqe, duhej tĂ« prishej deri nĂ« ditĂ«n tjetĂ«r â pĂ«rditĂ«simi ndodhte vetĂ«m natĂ«n, njĂ« herĂ« nĂ« ditĂ«.
Fillimisht kishte aq shumĂ« shqetĂ«sime nga javĂ«t e para tĂ« daljes nĂ« prodhim, saqĂ« kĂ«to inconvenienca pĂ«r menaxherĂ«t e pĂ«rmbajtjes ishin tĂ« vogla. Por, sapo gjithçka u qetĂ«sua, zhvillimi i projektit vazhdoi â pas disa muajve, nĂ« fillim tĂ« vitit 2015, filluam tĂ« zhvillojmĂ« aktivisht administratĂ«n. NĂ« vitet 2015 dhe 2016 gjithçka shkonte mirĂ«, ne lĂ«shonim rregullisht, administrata pĂ«rfshinte gjithnjĂ« e mĂ« shumĂ« pjesĂ« tĂ« pĂ«rgatitjes sĂ« tĂ« dhĂ«nave dhe ne po pĂ«rgatitemi pĂ«r faktin se sĂ« shpejti ekipit tonĂ« do t'i besohej gjĂ«ja mĂ« e rĂ«ndĂ«sishme dhe mĂ« e vĂ«shtirĂ« â konturi i produktit (pĂ«rgatitja e plotĂ« dhe menaxhimi i tĂ« dhĂ«nave pĂ«r tĂ« gjithĂ« produktet). Por gjatĂ« verĂ«s sĂ« vitit 2017, pikĂ«risht para lançimit tĂ« konturit tĂ« produktit, projekti do tĂ« gjendej nĂ« njĂ« situatĂ« shumĂ« tĂ« vĂ«shtirĂ« â pikĂ«risht pĂ«r shkak tĂ« problemeve me caching. PĂ«r kĂ«tĂ« episod dua tĂ« flas nĂ« pjesĂ«n e dytĂ« tĂ« kĂ«tij publikimi me dy pjesĂ«.
Por kĂ«tĂ« post, do tĂ« filloj nga larg, duke pĂ«rmbledhur disa mendime â pĂ«rceptime mbi caching, tĂ« cilat do tĂ« ishte njĂ« hap i mirĂ« tĂ« rrotulloheshin pĂ«rpara njĂ« projekti tĂ« madh.
Kur lind detyra e caching-ut
Detyra e caching-ut nuk shfaqet pa arsye. Ne jemi zhvillues, shkruajmĂ« produkte softuerike dhe duam qĂ« ato tĂ« jenĂ« tĂ« kĂ«rkuara. NĂ«se produkti Ă«shtĂ« i kĂ«rkuar dhe i suksesshĂ«m â pĂ«rdoruesit vijnĂ«. Dhe vijnĂ« dhe mĂ« shumĂ«. Pastaj numri i pĂ«rdoruesve rritet ndjeshĂ«m dhe produkti bĂ«het me ngarkesĂ« tĂ« lartĂ«.
NĂ« fazat e para nuk mendojmĂ« pĂ«r optimizimin dhe performancĂ«n e kodit. E rĂ«ndĂ«sishme Ă«shtĂ« funksionaliteti, tĂ« nxjerrim njĂ« pilot sa mĂ« shpejt dhe tĂ« testojmĂ« hipotezat. Dhe nĂ«se ngarkesa rritet â ne pĂ«rmirĂ«sojmĂ« harduerin. E dyfishojmĂ« dy deri tri herĂ«, pesĂ«, le tĂ« themi dhjetĂ« herĂ«. Diku kĂ«tu â financat nuk do tĂ« lejojnĂ« mĂ«. Sa herĂ« do tĂ« rritet numri i pĂ«rdoruesve? Nuk do tĂ« jetĂ« thjesht 2-5-10, por nĂ« rast suksesi â do tĂ« jetĂ« nga 100-1000 dhe deri nĂ« 100 mijĂ« herĂ«. Pra, pĂ«r mĂ«nyrĂ«n mĂ« tĂ« shkurtĂ«r, optimizimi do tĂ« bĂ«het i nevojshĂ«m nĂ« njĂ« moment.
Le tĂ« themi se njĂ« pjesĂ« e caktuar e kodit (ta quajmĂ« kĂ«tĂ« pjesĂ« funksion) punon rrezikshĂ«m gjatĂ«, dhe ne duam tĂ« shkurtim kohĂ«n e ekzekutimit. Funksioni â mund tĂ« jetĂ« njĂ« akses nĂ« bazĂ«n e tĂ« dhĂ«nave, mund tĂ« jetĂ« ekzekutimi i ndonjĂ« logjike komplekse â e rĂ«ndĂ«sishme Ă«shtĂ« se nĂ« çfarĂ«do forme, ajo zgjat shumĂ«. Sa mund tĂ« shkurtosh kohĂ«n e ekzekutimit? NĂ« maksimum â mund ta shkurtosh deri nĂ« zero, jo mĂ« tej. Si mund ta shkurtosh kohĂ«n e ekzekutimit deri nĂ« zero? PĂ«rgjigja: ta pĂ«rjashtosh ekzekutimin. NĂ« vend tĂ« kĂ«saj â tĂ« kthejmĂ« menjĂ«herĂ« rezultatin. Si mund ta dimĂ« rezultatin? PĂ«rgjigja: ose ta llogarisim, ose ta shikojmĂ« diku. TĂ« llogarish â Ă«shtĂ« me vonesĂ«. Dhe tĂ« shikosh â Ă«shtĂ«, pĂ«r shembull, tĂ« mbash nĂ« mend rezultatin qĂ« funksioni e dha herĂ«n e kaluar kur u thirr me tĂ« njĂ«jtat parametra.
KĂ«shtu qĂ«, implementimi i funksionit pĂ«r ne nuk ka rĂ«ndĂ«si. Mjafton tĂ« dimĂ« se nga cilat parametra varen rezultatet. AtĂ«herĂ«, nĂ«se vlerat e parametrave paraqiten si njĂ« objekt, i cili mund tĂ« pĂ«rdoret si çelĂ«s nĂ« njĂ« magazinĂ« tĂ« caktuar â atĂ«herĂ« rezultatin e llogaritjes mund ta ruajmĂ« dhe kur tĂ« kthehemi ta lexojmĂ« atĂ« sĂ«rish. NĂ«se ky regjistrim-lexim i rezultatit ndodh mĂ« shpejt se sa ekzekutimi i funksionit â kemi pĂ«rfitime nĂ« shpejtĂ«si. Shuma e pĂ«rfitimit mund tĂ« arrijĂ« edhe 100, edhe 1000, e madje edhe 100 mijĂ« herĂ« (10^5 Ă«shtĂ« mĂ« tepĂ«r njĂ« pĂ«rjashtim, por nĂ« rastin e njĂ« baze qĂ« ka vonesa tĂ« konsiderueshme â Ă«shtĂ« krejtĂ«sisht e mundshme).
Kërkesat kryesore për sistemin e keqcache
E para qĂ« mund tĂ« bĂ«het kĂ«rkesĂ« pĂ«r sistemin e keqcache â shpejtĂ«si e lartĂ« e leximit dhe, nĂ« njĂ« masĂ« mĂ« tĂ« vogĂ«l, shpejtĂ«si e shkrimit. Kjo Ă«shtĂ« e vĂ«rtetĂ«, por vetĂ«m derisa tĂ« mos e çojmĂ« sistemin nĂ« prodhim.
Le të luajmë një rast të tillë.
Supozoni se ne kemi siguruar harduerin pĂ«r ngarkesĂ«n aktuale dhe tani ngadalĂ« po implementojmĂ« keqcache. Disa pĂ«rdorues shtohen, ngarkesa rritet â pak e shtojmĂ« keqcachen, e lidhim kĂ«tu e atje. KĂ«shtu vazhdon pĂ«r njĂ« kohĂ«, dhe tani funksionet e rĂ«nda pothuajse nuk thirren â e gjithĂ« ngarkesa themelore bie mbi keqcache. Numri i pĂ«rdoruesve gjatĂ« kĂ«tij kohe Ă«shtĂ« rritur N herĂ«.
Dhe nĂ«se rezervat fillestare pĂ«r harduerin ishin 2-5 herĂ«, me ndihmĂ«n e keqcache ne mund tĂ« pĂ«rmirĂ«sojmĂ« performancĂ«n herĂ« 10 ose, nĂ« njĂ« rast tĂ« mirĂ«, herĂ« 100, ndonjĂ«herĂ«, ndoshta, edhe 1000. KĂ«shtu, me tĂ« njĂ«jtin harduer â pĂ«rpunojmĂ« 100 herĂ« mĂ« shumĂ« kĂ«rkesa. ShkĂ«lqyeshĂ«m, e meriton njĂ« shpĂ«rblim!
Por tani, nĂ« njĂ« moment tĂ« bukur, rastĂ«sisht, sistemi dĂ«shtoi dhe keqcache rĂ«nkoi. AsgjĂ« speciale â sepse keqcache u zgjodh sipas kĂ«rkesave "shpejtĂ«si e lartĂ« leximi dhe shkrimi, e gjithĂ« pjesa tjetĂ«r nuk ka rĂ«ndĂ«si".
NĂ« lidhje me ngarkesĂ«n fillestare, rezervat pĂ«r harduerin ishin 2-5 herĂ«, ndĂ«rsa ngarkesa gjatĂ« kĂ«saj kohe u rrit 10-100 herĂ«. Me ndihmĂ«n e keqcache ne ndaluam thirrjet pĂ«r funksionet e rĂ«nda dhe kĂ«shtu gjithçka fluturonte. Tani, pa keqcache â sa herĂ« do tĂ« bjerĂ« sistemi ynĂ«? ĂfarĂ« do tĂ« ndodhĂ« me ne? Sistemi do tĂ« bjerĂ«.
Edhe nĂ«se keqcache nuk u rrĂ«zua, por vetĂ«m u pastrua pĂ«r njĂ« kohĂ« tĂ« caktuar â duhet tĂ« ngrohet, dhe kjo do tĂ« marrĂ« pak kohĂ«. Dhe pĂ«r kĂ«tĂ« kohĂ« â ngarkesa themelore do tĂ« bjerĂ« mbi funksionalitetin.
Përfundimi: projektet me ngarkesë të lartë në prodhim kërkojnë nga sistemi i caching jo vetëm shpejtësi të lartë leximi dhe shkruaje, por gjithashtu ruajtjen e të dhënave dhe qëndrueshmëri ndaj dështimeve.
Duf i zgjedhjes
NĂ« projektin me admin panel â zgjedhja nisi kĂ«shtu: fillimisht vendosĂ«m Hazelcast, sepse ishim tĂ« njohur me kĂ«tĂ« produkt nga pĂ«rvoja e faqes kryesore. Por, kĂ«tu ky zgjedhje doli tĂ« ishte e pasuksesshme â nĂ«n profilin tonĂ« tĂ« ngarkesĂ«s, Hazelcast funksiononte jo thjesht ngadalĂ«, por shumĂ« ngadalĂ«. Dhe pĂ«r afatet e fillimit tĂ« prodhimit nĂ« atĂ« moment ne tashmĂ« ishim nĂ«nshkruar.
Spoiler: si u zhvilluan rrethanat qĂ« ne e humbĂ«m njĂ« perk dhe u pĂ«rballĂ«m me njĂ« situatĂ« tĂ« tensionuar â do ta tregoj nĂ« pjesĂ«n e dytĂ« â dhe si arritĂ«m atje, dhe si u shpĂ«tuam. Por tani â do tĂ« them vetĂ«m se ishte njĂ« stres i madh, dhe "tĂ« mendosh - asnjĂ«herĂ« nuk mendohet, tundim shishen". "Tundim shishen" â ky Ă«shtĂ« gjithashtu njĂ« spoiler, pĂ«r kĂ«tĂ« pak mĂ« vonĂ«.
ĂfarĂ« bĂ«mĂ«:
- Krijojmë një listë të të gjitha sistemeve që sugjeron google dhe StackOverflow. Pak më shumë se 30.
- ShkruajmĂ« teste me ngarkesĂ«n tipike pĂ«r prodhimin. PĂ«r kĂ«tĂ« qĂ«llim, regjistruam tĂ« dhĂ«nat qĂ« kalojnĂ« pĂ«rmes sistemit nĂ« mjedisin e prodhimit â njĂ« lloj sniffing pĂ«r tĂ« dhĂ«nat jo nĂ« rrjet, por brenda sistemit. NĂ« teste, ekzekutuam pikĂ«risht kĂ«to tĂ« dhĂ«na.
- E tĂ«rĂ« ekipi, secili zgjedh sistemin tjetĂ«r nga lista, e konfiguron, ekzekuton testet. NĂ«se testi nuk kalon, nuk mban ngarkesĂ«n â e heqim, kalojmĂ« nĂ« atĂ« tjetĂ«r nĂ« radhĂ«.
- Në sistemin e 17-të bëhej e qartë se gjithçka ishte pa shpresë. Mjaft më me "tundjen e shishes", është koha për të menduar seriozisht.
Por ky është një variant, kur duhet të zgjidhni një sistem që "kalon në shpejtësi" në testet e përgatitura më parë. Dhe nëse nuk ka teste të tilla dhe dëshirojmë të zgjedhim sa më shpejt?
Modele sot njĂ« variant tĂ« tillĂ« (e vĂ«shtirĂ« tĂ« paraqitet se njĂ« zhvillues mjedisi+ jeton nĂ« vakuum, dhe nĂ« momentin e zgjedhjes nuk ka formuluar preferencĂ«, se cilin produkt tĂ« provojĂ« nĂ« radhĂ« tĂ« parĂ« â prandaj, argumentet e mĂ«passhme janĂ« mĂ« shumĂ« teorike/filozofi/rreth juniorit).
Pas përcaktimit të kërkesave, do të fillojmë të zgjedhim një zgjidhje prej kutie. Pse të shpikim biçikletën: ne do të shkojmë dhe do të marrim një sistem caching të gatshëm.
NĂ«se sapo keni filluar dhe po shqyrtoni nĂ« Google, ka disa renditje, por nĂ« pĂ«rgjithĂ«si, do tĂ« jeni tĂ« orientuar kĂ«shtu. SĂ« pari, do tĂ« ndeshni Redis, i cili Ă«shtĂ« nĂ« tĂ« gjithĂ« bisedat. Pastaj do tĂ« mĂ«soni se ekziston EhCache si sistemi mĂ« i vjetĂ«r dhe i provuar. MĂ« pas, do tĂ« shkruhet pĂ«r Tarantool â njĂ« zhvillim vendas, i cili ka njĂ« aspekt unik zgjidhjeje. Dhe gjithashtu Ignite, sepse tani Ă«shtĂ« nĂ« rritje tĂ« popullaritetit dhe mbĂ«shtetet nga SberTech. NĂ« fund, Hazelcast, sepse nĂ« botĂ«n e enterprise ai shpesh pĂ«rmendet nĂ« mesin e kompanive tĂ« mĂ«dha.
Ky lista nuk është tërësore, ka dhjetëra sisteme. Dhe ne do të lidhim vetëm një. Do të marrim 5 sistemet e zgjedhura në "konkursin e bukurisë" dhe do të bëjmë një përzgjedhje. Kush do të jetë fituesi?
Redis
Le të shohim se çfarë shkruajnë në faqen zyrtare.
â projekt opensource. Ofro gjetje tĂ« dhĂ«nash nĂ« memorie, mundĂ«si ruajtjeje nĂ« disk, ndarje automatikisht nĂ« parti, disponueshmĂ«ri tĂ« lartĂ« dhe rikuperim pas ndĂ«rprerjeve nĂ« rrjet.
Duket gjithçka nĂ« rregull, mund tĂ« merret dhe tĂ« lidhet â gjithçka qĂ« nevojitet, ai e bĂ«n. Por le tĂ« shohim thjesht pĂ«r kureshtje kandidatĂ«t e tjerĂ«.
EhCache
â "cache mĂ« i pĂ«rdorur pĂ«r Java" (pĂ«rkthim i sloganit nga faqja zyrtare). Po ashtu opensource. Dhe kĂ«tu e kuptojmĂ« se Redis nuk Ă«shtĂ« pĂ«r java, por Ă«shtĂ« i pĂ«rgjithshĂ«m, dhe pĂ«r ndĂ«rveprimin me tĂ« nevojitet njĂ« mbĂ«shtjellĂ«s. Dhe EhCache do tĂ« jetĂ« mĂ« e pĂ«rshtatshme. ĂfarĂ« tjetĂ«r premton sistemi? BesueshmĂ«ri, provueshmĂ«ri, funksionalitet tĂ« plotĂ«. Dhe gjithashtu Ă«shtĂ« mĂ« e pĂ«rhapura. Dhe cache sasi tĂ« dhĂ«nash nĂ« terabajt.
Redis është harruar, unë jam i gatshëm të zgjedh EhCache.
Por ndjenja e patriotizmit më shtyn të shoh se çfarë ka të mira Tarantool.
Tarantool
â takon me emrin "Platforma e integrimit tĂ« tĂ« dhĂ«nave nĂ« kohĂ« reale". Duket shumĂ« e komplikuar, prandaj lexohet faqja me kujdes dhe gjejmĂ« njĂ« deklaratĂ« tĂ« zĂ«shme: "Cache 100% tĂ« dhĂ«nave nĂ« memorien operative". Kjo duhet tĂ« ngrejĂ« disa pyetje â sepse tĂ« dhĂ«nat mund tĂ« jenĂ« ndjeshĂ«m mĂ« shumĂ« se memoria. Shpjegimi Ă«shtĂ« se kĂ«tu nĂ«nkuptohet se pĂ«r tĂ« shkruar tĂ« dhĂ«na nĂ« disk nga memoria, Tarantool nuk kalon pĂ«rmes serializimit. NĂ« vend tĂ« kĂ«saj â pĂ«rdor karakteristikat e ulta tĂ« sistemit, kur memoria thjesht mapohet nĂ« sistemin e skedarĂ«ve me tregues shumĂ« tĂ« mirĂ« I/O. NĂ« tĂ«rĂ«si, e bĂ«nĂ« siç duhet dhe bukur.
Le tĂ« shohim implementimet: Mail.ru, magjira korporative, Avito, Beeline, MegaFon, Alfa-Banka, GazpromâŠ
Nëse kishin mbetur ndonjë dyshim në lidhje me Tarantool, rastin e implementimit në Mastercard më bind plotësisht. Po e zgjedh Tarantool.
Por megjithatĂ«âŠ
Ignite
⊠ka gjithashtu , i shpallur si «platformë përpunimi in-memory⊠shpejtësitë in-memory në petabajt të dhënash». Këtu ka shumë përparësi: cache in-memory të shpërndarë, depoja më e shpejtë key-value dhe cache, shkallëzim horizontal, disponueshmëri e lartë, integritet i fortë. Në përgjithësi, rezulton se më i shpejti është Ignite.
Implementimet: Sberbank, American Airlines, Yahoo! Japan. Dhe pastaj unë mësoj se Ignite është jo vetëm implementuar në Sberbank, por ekipi i SberTech dërgon njerëzit e vet në ekipin e vetë Ignite për të përmirësuar produktin. Kjo më bind plotësisht dhe unë jam gati ta zgjedh Ignite.
Për një arsyetim të panjohur, unë shikoj pikën e pestë.
Hazelcast
Hap faqen e internetit , e lexoj. Dhe rezulton se zgjidhja mĂ« e shpejtĂ« pĂ«r cache tĂ« shpĂ«rndarĂ« â Ă«shtĂ« Hazelcast. Ai Ă«shtĂ« shumĂ« mĂ« i shpejtĂ« se tĂ« gjitha zgjidhjet e tjera dhe Ă«shtĂ« nĂ« fakt lider nĂ« fushĂ«n e in-memory data grid. NĂ« kĂ«tĂ« kontekst, tĂ« zgjedhĂ«sh diçka tjetĂ«r do tĂ« ishte mungesĂ« respekti ndaj vetes. Dhe gjithashtu pĂ«rdor ruajtje tĂ« tepruar tĂ« tĂ« dhĂ«nave pĂ«r tĂ« siguruar punĂ«n e vazhdueshme tĂ« klasterit pa humbje tĂ« dhĂ«nash.
Të gjitha, unë jam i gatshëm të zgjedh Hazelcast.
Krahasimi
Por nëse shikojmë, të gjitha pesë kandidatët janë përshkruar në mënyrë që secili prej tyre është më i miri. Si ta zgjidhim? Mund të shohim se cili prej tyre është më i popullarizuar, të kërkojmë krahasime, dhe dhimbja e kokës do të shkojë.
Gjejmë një të tillë , zgjedhim sistemet tona 5.
KĂ«tu ato janĂ« renditur: nĂ« krye Redis, nĂ« vendin e dytĂ« â Hazelcast, po fitojnĂ« popullaritet Tarantool dhe Ignite, ndĂ«rsa EhCache mbetet ashtu si ka qenĂ«.
Por le tĂ« shohim nĂ« : lidhjet nĂ« faqet e internetit, interesi i pĂ«rgjithshĂ«m pĂ«r sistemin, ofertat e punĂ«s â shkĂ«lqyeshĂ«m! KĂ«shtu qĂ«, kur sistemi im do tĂ« rrĂ«zohet, do tĂ« them: «Jo, ajo Ă«shtĂ« e besueshme! Ja shumĂ« oferta pune...». NjĂ« krahasim i tillĂ« i thjeshtĂ« nuk do tĂ« pĂ«rshtatet.
TĂ« gjithĂ« kĂ«to sisteme nuk janĂ« thjesht sisteme pĂ«r caching. Ato gjithashtu kanĂ« shumĂ« funksionalitete, pĂ«rfshirĂ« â kur tĂ« dhĂ«nat nuk dĂ«rgohen te klienti pĂ«r pĂ«rpunim, por pĂ«rkundrazi: kodi qĂ« duhet tĂ« ekzekutohet mbi tĂ« dhĂ«nat, transferohet nĂ« server, atje ekzekutohet dhe rezultati kthehet. Dhe si njĂ« sistem tĂ« veçantĂ« pĂ«r caching, ato nuk shqyrtohen aq shpesh.
MirĂ«, nuk dorĂ«zohemi, do tĂ« gjejmĂ« njĂ« krahasim tĂ« drejtpĂ«rdrejtĂ« tĂ« sistemeve. Do tĂ« marrim dy opsionet kryesore â Redis dhe Hazelcast. Na intereson shpejtĂ«sia, dhe me kĂ«tĂ« parametrat do t'i krahasojmĂ«.
Hz vs Redis
Gjejmë një të tillë :
E kuqe është Redis, e kaltër është Hazelcast. Hazelcast fiton gjithmonë, dhe kjo është e justifikuar: është shumëthjesht, e optimizuar në mënyrë të lartë, çdo gjeth punon me një pjesë të saj, kështu që nuk ka bllokime. Ndërsa Redis është njëthjesht, dhe nuk përfiton nga CPU-të moderne me shumë bërthama. Hazelcast ka I/O asinkron, ndërsa Redis-Jedis ka socketë bllokues. Në fund të fundit, Hazelcast përdor një protokoll binar, ndërsa Redis është e orientuar në tekst, pra është e pasaktë.
PĂ«r çdo rast, le tĂ« kthehemi tek njĂ« burim tjetĂ«r krahasimi. ĂfarĂ« do tĂ« na tregojĂ« ai?
Redis vs Hz
Një tjetër :
Këtu e kundërta, e kuqe është Redis. Kjo do të thotë se Redis sipas performancës e kalon Hazelcast. Në krahasimin e parë fitonte Hazelcast, në të dytin - Redis. shpjeguan shumë saktë pse në krahasimin e mëparshëm fitoi Hazelcast.
Doli se rezultati i parë ishte praktikisht i manipuluar: Redis u mor nga kutia themelore, ndërsa Hazelcast u përshtat për rastin testues. Kështu që del se: së pari, askush nuk duhet besuar, së dyti, kur të zgjidhim një sistem, na duhet ta konfigurojmë atë siç duhet. Këto konfigurime përfshijnë dhjetëra, pothuajse qindra parametra.
TĂ« tundim shishen
Dhe procesi që kemi kryer tani, mund ta shpjegoj me këtë metaforë "Të tundim shishen". Pra, aktualisht nuk është e nevojshme të programojmë, tani është e rëndësishme të dimë si të lexojmë stackoverflow. Në ekipin tim kam një profesionist që punon në këtë mënyrë në momentet kritike.
ĂfarĂ« bĂ«n ai? Ai sheh njĂ« gjĂ« qĂ« nuk funksionon, sheh stack trace, merr disa fjalĂ« nga ajo (cilat saktĂ«sisht - Ă«shtĂ« ekspertizĂ« e tij nĂ« program), kĂ«rkon nĂ« Google, gjen stackoverflow midis pĂ«rgjigjeve. Ai nuk lexon, nuk mendon, midis pĂ«rgjigjeve nĂ« pyetje - ai zgjedh diçka qĂ« Ă«shtĂ« mĂ« e ngjashme me propozimin "tĂ« bĂ«sh kĂ«tĂ« e atĂ«" (zgjedhja e njĂ« pĂ«rgjigjeje tĂ« tillĂ« Ă«shtĂ« talenti i tij, sepse nuk Ă«shtĂ« gjithmonĂ« ajo pĂ«rgjigje qĂ« ka marrĂ« mĂ« shumĂ« like), e aplikon, shikon: nĂ«se ka ndonjĂ« ndryshim, atĂ«herĂ« Ă«shtĂ« shkĂ«lqyer. NĂ«se nuk ka ndryshim - rikthejmĂ«. Dhe pĂ«rsĂ«risim fillimin-verifikimin-kĂ«rkimin. NĂ« kĂ«tĂ« mĂ«nyrĂ« intuituese ai arrin qĂ« pas njĂ« kohe kodi tĂ« funksionojĂ«. Ai nuk e di pse, ai nuk e di se çfarĂ« bĂ«ri, ai nuk mund ta shpjegojĂ«. Por! Kjo gjĂ« funksionon. Dhe "zjarri Ă«shtĂ« shuar". Tani shohim çfarĂ« bĂ«mĂ«. Kur programi funksionon - kjo Ă«shtĂ« shumĂ« mĂ« e lehtĂ«. Dhe kursen ndjeshĂ«m kohĂ«n.
Ky ŃŃĐŸŃ mĂ«nyrĂ« shpjegohet shumĂ« mirĂ« me njĂ« shembull si ky.
Njëherë, ishte shumë popullor të ndërtohej një anije vela në një shishe. Anija është e madhe dhe e brishtë, ndërsa goja e shishes është shumë e ngushtë, nuk mund ta futësh brenda. Si ta bëjmë atë?
Ka një metodë të tillë, shumë të shpejtë dhe shumë efektive.
Anija përbëhet nga shumë gjëra: shkopinj, litarë, vela, ngjitës. Të gjitha këto i vendosim në shishe.
Marrim shishen me dy duar dhe fillojmĂ« ta tundim. E tundim-tundim. Dhe zakonisht â del njĂ« gjĂ« e çuditshme, sigurisht. Por herĂ« pas here. HerĂ« pas here del njĂ« anije! SaktĂ«sisht, diçka qĂ« ngjan me anijen.
I tregojmĂ« dikujt kĂ«tĂ« diçka: «Serjozha, e sheh!?». Dhe me tĂ« vĂ«rtetĂ«, nga larg â duket si njĂ« anije. Por mĂ« tutje nuk mund ta lĂ«sh kĂ«tĂ«.
Ka edhe një mënyrë tjetër. Përdoret nga djemtë më të avancuar, të ashtuquajturit hakerë.
I dhashĂ« njĂ« detyrĂ« njĂ« djali tĂ« tillĂ«, ai e bĂ«ri gjithçka dhe u largua. Dhe e shikon â duket se Ă«shtĂ« bĂ«rĂ«. Por pas njĂ« kohe, kur duhet tĂ« pĂ«rmirĂ«sohet kodi â aty fillon njĂ« ngatĂ«rrim pĂ«r shkak tĂ« tij⊠MirĂ«, qĂ« ai kishte ikur ndarĂ«. KĂ«ta janĂ« djem qĂ« pĂ«r shembull, bĂ«jnĂ« kĂ«shtu me shishen: e shihni, aty ku Ă«shtĂ« fundi â ŃŃĐ”ĐșĐ»ĐŸ ŃŃĐŸĐœŃĐ°Đ”ŃŃŃ. Dhe nuk Ă«shtĂ« krejtĂ«sisht e qartĂ«, nĂ«se Ă«shtĂ« transparente apo jo. AtĂ«herĂ« «hakerĂ«t» e presin kĂ«tĂ« fund, e vendosin anijen brenda, e ngjitin sĂ«rish fundin, dhe duket se Ă«shtĂ« ashtu siç duhet.
Nga pikëpamja e formulimit të detyrës duket se gjithçka është në rregull. Por këtu tek shembujt e anijeve: përse në të vërtetë ta bësh këtë anije, kujt i nevojitet ajo? Ajo nuk ka funksionalitet. Zakonisht, këto anije janë dhurata për njerëz shumë të rëndësishëm, të cilët e vendosin atë në raftin e tyre, si një simbol, një shenjë. Dhe nëse një njeri i tillë, lider i një biznesi të madh ose një funksionar të lartë, e sheh këtë si një flamur të tillë që është bërë me një punë të dobët? Do të ishte më mirë, nëse ai kurrë nuk do ta dinte për këtë. Atëherë, si i bëjnë në përfundim këto anije, që mund t'u dhurohen njerëzve të rëndësishëm?
Vendi i vetëm ku me të vërtetë nuk mund të bësh asgjë është trupi. Dhe trupi i anijes kalon pikërisht në qafë. Ndërsa anija ndahet jashtë shishkës. Por nuk është e thjeshtë ta mbledhësh anijen, është një art i vërtetë i arritur. Në pjesët përbërëse shtohen levë të veçanta që lejojnë që ato të ngrihen më vonë. Për shembull, dimrat palosen, futen me kujdes brenda, dhe pastaj me pincë, shumë me precizitet, tërhiqen dhe ngrihen. Si rezultat, krijohet një vepër arti që mund t'i dhurohet me krenari.
Dhe nëse duam që projekti të jetë i suksesshëm, në ekip duhet të ketë të paktën një person-artizan. Ai që kujdeset për cilësinë e produktit dhe merr parasysh të gjitha aspektet, pa sakrifikuar asnjë edhe në momentet e stresit, kur rrethanat kërkojnë të bësh diçka të menjëhershme në dëm të asaj që është e rëndësishme. Të gjitha projektet e suksesshme që janë të qëndrueshme dhe kanë qëndruar përballë provës së kohës, janë ndërtuar mbi këtë parim. Aty është diçka shumë e saktë dhe unike, diçka që shfrytëzon të gjitha mundësitë e disponueshme. Në shembullin me anijen në shishe, përmendet se trupi i anijes kalon nëpër qafë.
Duke u kthyer në detyrën e zgjedhjes së serverit tonë të caches, si mund të aplikohej ky mënyrë? Sugjeroj një variant të tillë zgjedhjeje nga të gjitha sistemet që janë - të mos e tronditim shishkën, jo të zgjedhim, por të shohim se çfarë ka parasysh në to që është e rëndësishme për zgjedhjen e sistemit.
Ku të kërkosh bottleneck
Të përpiqemi të mos e tronditim shishkën, të mos i kalojmë të gjitha një nga një, por të shikojmë cilat detyra do të dalin, nëse ndonjëherë, nën detyrën tonë - të projektosh një sistem të tillë vetë. Sigurisht që nuk do të rregullojmë biçikletën, por do të shfrytëzojmë këtë skemë për të u orientuar për momentet që duhet pasur parasysh në përshkrimet e produkteve. Të rrëshqasim një skemë të tillë.
Nëse sistemi është i shpërndarë, atëherë do të kemi disa servera (6). Le të themi se katër janë (të lehta për t'u vendosur në imazh, por sigurisht, mund të jenë sa të duash). Nëse serverat janë në node të ndryshme, atëherë mbi ta do të funksionojë një kod që është përgjegjës që këto node të formojnë një grup dhe në rast ndarjeje - të lidhin dhe të njohin njëri-tjetrin.
Kemi përsëri një kod-logjikë (2), e cila është në thelb rreth caches. Me këtë kod, klientët ndërveprojnë me një API të caktuar. Kodi i klientit (1) mund të jetë brenda kësaj JVM-je, ose të interesohet për të nëpërmjet rrjetit. Logjika e zbatuar brenda lidhet me vendimet se cilat objeto në cache duhen ruajtur dhe cilat duhen hequr. Për ruajtjen e cache-it, përdorim memorien (3), por nëse është e nevojshme, mund të ruajmë një pjesë të të dhënave edhe në disk (4).
TĂ« shohim se nĂ« cilat pjesĂ« do tĂ« ndodhĂ« ngarkesa. NĂ« thelb, do tĂ« ngarkohet çdo shigjetĂ« dhe çdo nyje. SĂ« pari, mes kodit tĂ« klientit dhe API-t, nĂ«se Ă«shtĂ« ndĂ«rveprim rrjetor, rĂ«nia mund tĂ« jetĂ« mjaft e dukshme. SĂ« dyti, brenda vetĂ« API-t â nĂ«se e teprojmĂ« me logjikĂ«n e komplikuar, mund tĂ« pĂ«rballim CPU-nĂ«. Dhe do tĂ« ishte mirĂ« qĂ« logjika tĂ« mos pĂ«rdorĂ« memorien mĂ« shumĂ« se duhet. Kjo mbetet ndĂ«rveprimi me sistemin e skedarĂ«ve â nĂ« variantin e zakonshĂ«m, kjo Ă«shtĂ« tĂ« serializosh / rikuperosh dhe tĂ« shkruash / lexosh.
Pastaj, ndërveprimi me klasterin. Me shumë mundësi, ai do të jetë në këtë sistem, por mund të jetë edhe veçmas. Këtu gjithashtu duhet marrë parasysh transferimi i të dhënave te ai, shpejtësia e serializimit të të dhënave dhe ndërveprimi mes klasterit.
Tani, nga njĂ«ra anĂ« â ne mund tĂ« paraqesim, "cila do tĂ« jetĂ« mekanizmi qĂ« do tĂ« funksionojĂ«" nĂ« sistemin e caches gjatĂ« pĂ«rpunimit tĂ« kĂ«rkesave nga kodi ynĂ«, dhe nga ana tjetĂ«r â ne mund tĂ« vlerĂ«sojmĂ« se cilat dhe sa kĂ«rkesa do tĂ« gjenerojĂ« kodi ynĂ« ndaj kĂ«tij sistemi. Kjo Ă«shtĂ« mjaft e mjaftueshme pĂ«r tĂ« bĂ«rĂ« njĂ« zgjedhje mĂ« se tĂ« arsyeshme â pĂ«r tĂ« zgjedhur sistemin sipas variantit tonĂ« tĂ« pĂ«rdorimit.
Hazelcast
Të shohim se si të aplikojmë një shpërndarje të tillë në listën tonë. Për shembull, Hazelcast.
Për të vendosur / marrë të dhëna nga Hazelcast, kodi i klientit i afrohet (1) API-t. Hz lejon të nisësh serverin si embedded, dhe në këtë rast, qasja në API është një thirrje metode brenda JVM, mund të merret si falas.
PĂ«r tĂ« funksionuar logjika nĂ« (2), Hz mbĂ«shtetet nĂ« hash nga byte-array i serializuar tĂ« çelĂ«sit â domethĂ«nĂ«, serializimi i çelĂ«sit do tĂ« ndodhĂ« nĂ« çdo rast. Kjo Ă«shtĂ« njĂ« overhead e pashmangshme pĂ«r Hz.
StrategjitĂ« e Eviction janĂ« zbatuar mirĂ«, por pĂ«r raste tĂ« veçanta â mund tĂ« lidhen tĂ« tuat. PĂ«r kĂ«tĂ« pjesĂ« nuk ka nevojĂ« tĂ« shqetĂ«soheni.
Memorizimi (4) mund tĂ« lidhet. ShkĂ«lqyer. Interaksioni (5) pĂ«r embedded mund tĂ« merret si momental. ShkĂ«mbimi i tĂ« dhĂ«nave midis nyjave nĂ« klaster (6) â po, ai ekziston. Kjo Ă«shtĂ« njĂ« kontribut nĂ« favor tĂ« qĂ«ndrueshmĂ«risĂ« me koston e shpejtĂ«sisĂ«. Ămimi mund tĂ« ulet falĂ« karakteristikĂ«s Hz Near-cache â tĂ« dhĂ«nat e marra nga nyjat e tjera tĂ« klasterit do tĂ« kenĂ« njĂ« cache.
ĂfarĂ« mund tĂ« bĂ«het nĂ« kĂ«to kushte pĂ«r tĂ« rritur shpejtĂ«sinĂ«?
PĂ«r shembull, pĂ«r tĂ« shmangur serializimin e çelĂ«sit nĂ« (2) â pĂ«rdorimi i njĂ« cache tjetĂ«r mbi Hazelcast, pĂ«r tĂ« dhĂ«nat mĂ« tĂ« ngrohta. NĂ« Sportmaster, pĂ«r kĂ«tĂ« qĂ«llim u zgjodh Caffeine.
Për rregullimin në nivelin (6), në Hz u ofruan dy lloje ruajtjeje: IMap dhe ReplicatedMap.
Duhet të themi si Hazelcast arriti në ngarkesën teknologjike të Sportmaster.
NĂ« vitin 2012, kur po punonim mbi prototipin e parĂ« tĂ« faqes sĂ« internetit tĂ« ardhshme, Hazelcast ishte lidhja e parĂ« qĂ« kĂ«rkuesi na dha. Takimi filloi "nĂ« herĂ«n e parĂ«" â ishim tĂ« impresionuar se pas vetĂ«m dy orĂ«sh, kur e integruam Hz nĂ« sistem â ai punonte. Dhe punonte mirĂ«. Deri nĂ« fund tĂ« ditĂ«s kishim pĂ«rfunduar disa teste, u gĂ«zuam. Dhe ky rezervĂ« energjie na mjaftoi pĂ«r tĂ« pĂ«rballuar surprizat qĂ« Hz na ofronte me kalimin e kohĂ«s. Tani ekipi i Sportmaster nuk ka arsye pĂ«r tĂ« braktisur Hazelcast.
Por argumente tĂ« tilla si "lidhja e parĂ« nĂ« kĂ«rkues" dhe "e ndĂ«rtuam shpejt HelloWorld" â janĂ«, natyrisht, pĂ«rjashtime dhe veçori tĂ« momentit nĂ« tĂ« cilin u bĂ« pĂ«rzgjedhja. Provimi i vĂ«rtetĂ« pĂ«r sistemin e zgjedhur fillon me daljen nĂ« prodhim, dhe pikĂ«risht nĂ« kĂ«tĂ« fazĂ« duhet tĂ« kushtohet vĂ«mendje kur zgjedhim çdo sistem, pĂ«rfshirĂ« dhe cache. NĂ« fakt, nĂ« rastin tonĂ«, mund tĂ« themi se zgjodhĂ«m Hazelcast pĂ«r rastĂ«si, por mĂ« pas doli se kishim zgjedhur saktĂ«.
PĂ«r prodhimin, shumĂ« mĂ« e rĂ«ndĂ«sishme Ă«shtĂ«: monitorimi, trajtimi i dĂ«shtimeve nĂ« nyjat e veçanta, replikimi i tĂ« dhĂ«nave, kostoja e shkallĂ«zimit. Pra, duhet tĂ« kushtohet vĂ«mendje detyrave qĂ« do tĂ« shfaqen pikĂ«risht nĂ« mbĂ«shtetje tĂ« sistemit â kur ngarkesa tĂ« kalojĂ« disa herĂ« atĂ« qĂ« ishte planifikuar, kur rastĂ«sisht tĂ« bĂ«jmĂ« ngarkimin e diçkaje qĂ« nuk Ă«shtĂ« e drejtĂ« dhe jo aty, kur do tĂ« nevojitet pĂ«r tĂ« lĂ«shuar njĂ« version tĂ« ri tĂ« kodit, pĂ«r tĂ« zĂ«vendĂ«suar tĂ« dhĂ«nat dhe pĂ«r ta bĂ«rĂ« kĂ«tĂ« pa u vĂ«nĂ« re nga klientĂ«t.
Për të gjitha këto kërkesa, Hazelcast është pa dyshim i përshtatshëm.
Do të vazhdojë
Porë, Hazelcast nuk është një zgjidhje magjike. Në vitin 2017, ne zgjodhëm Hazelcast për caching në panelin administrativ, duke u bazuar thjesht në përshtypjet pozitivë nga eksperiencat e kaluara. Kjo luajti një rol kyç në një shaka të tmerrshme, duke na sjellë në një situatë të vështirë nga të cilat dolëm "heroikisht" pas 60 ditësh. Por për këtë, në pjesën tjetër.
Deri atëherë⊠Gëzuar Kode të Reja!
Burimi: habr.com
