Përshëndetje! Emri im është Aleksei Pjankov, unë jam zhvillues në kompaninë Sportmaster. Në këtë kam treguar se si filloi puna për uebsajtin Sportmaster në vitin 2012, cilat iniciativa arritëm të "shtyjmë" dhe anasjelltas, cilat vështirësi mblodhëm.
Sot dua tĂ« ndaj mendimet e mia, tĂ« cilat ndjekin njĂ« narrativ tjetĂ«r â zgjedhja e sistemit tĂ« caching pĂ«r backend-in java nĂ« adminin e uebsajtit. Ky narrativ ka njĂ« rĂ«ndĂ«si tĂ« veçantĂ« pĂ«r mua â edhe pse historia zgjati vetĂ«m 2 muaj, nĂ« kĂ«to 60 ditĂ« punuam nga 12-16 orĂ« pa asnjĂ« ditĂ« pushimi. AsnjĂ«herĂ« nuk kisha menduar dhe nuk e imagjinoja se mund tĂ« punohej kaq shumĂ«.
Prandaj, tekstin e ndaj nĂ« 2 pjesĂ«, pĂ«r tĂ« mos e mbingarkuar. NĂ« fakt, pjesa e parĂ« do tĂ« jetĂ« shumĂ« e lehtĂ« â pĂ«rgatitje, hyrje, disa mendime, çfarĂ« Ă«shtĂ« caching. NĂ«se ju jeni tashmĂ« njĂ« zhvillues me pĂ«rvojĂ« ose keni punuar me caching, nga ana teknike nuk ka gjĂ« tĂ« re nĂ« kĂ«tĂ« artikull, ndoshta. NdĂ«rsa pĂ«r njĂ« junior, njĂ« pĂ«rmbledhje e tillĂ« mund tĂ« sugjerojĂ« nĂ« cilĂ«n drejtim tĂ« shikoni, nĂ«se ndodh tĂ« jeni nĂ« njĂ« udhĂ«kryq tĂ« tillĂ«.
Kur versioni i ri i uebsajtit tĂ« Sportmaster u lançua nĂ« prodhim, tĂ« dhĂ«nat arrinin nĂ« njĂ« mĂ«nyrĂ«, tĂ« thĂ«nĂ« pak, jo shumĂ« tĂ« rehatshme. Baza ishin tabelat e pĂ«rgatitura pĂ«r versionin e kaluar tĂ« uebsajtit (Bitrix), tĂ« cilat duhej tĂ« importoheshin nĂ« ETL, tĂ« transformoheshin nĂ« njĂ« format tĂ« ri dhe tĂ« pasuroheshin me disa elemente tĂ« tjera nga njĂ« duzinĂ« sistemesh. QĂ« njĂ« imazh i ri ose pĂ«rshkrimi i produktit tĂ« shfaqej nĂ« uebsajt, duhej tĂ« prisnim deri nĂ« nesĂ«r â pĂ«rditĂ«simi ndodhte vetĂ«m natĂ«n, njĂ« herĂ« nĂ« ditĂ«.
Fillimisht kishte kaq shumĂ« shqetĂ«sime nĂ« javĂ«t e para pas lançimit, saqĂ« kĂ«to pengesa pĂ«r menaxherĂ«t e pĂ«rmbajtjes ishin detaje. Por, sapo gjithçka u qetĂ«sua, zhvillimi i projektit vazhdoi â pas disa muajve, fillimi i vitit 2015 e gjeti ekipin tonĂ« duke punuar aktivisht nĂ« admin. NĂ« vitet 2015 dhe 2016 gjithçka shkonte mirĂ«, ne lĂ«shonim rregullisht, admin mbulonte njĂ« pjesĂ« gjithnjĂ« e mĂ« tĂ« madhe tĂ« pĂ«rgatitjes sĂ« tĂ« dhĂ«nave dhe ne pĂ«rgatiteshim qĂ« sĂ« shpejti ekipi ynĂ« do tĂ« besoheshin detyra mĂ« tĂ« rĂ«ndĂ«sishme dhe mĂ« tĂ« komplikuara â konturi i produkteve (pĂ«rgatitja e plotĂ« dhe menaxhimi i tĂ« dhĂ«nave pĂ«r tĂ« gjitha produktet). Por verĂ«n e vitit 2017, pikĂ«risht pĂ«rpara lançimit tĂ« konturit tĂ« produkteve, projekti do tĂ« pĂ«rfundonte nĂ« njĂ« situatĂ« shumĂ« tĂ« komplikuar â pikĂ«risht pĂ«r shkak tĂ« problemeve me caching. PĂ«r kĂ«tĂ« episod dua tĂ« flas nĂ« pjesĂ«n e dytĂ« tĂ« kĂ«saj publikimi nĂ« dy seria.
Por nĂ« kĂ«tĂ« post do tĂ« filloj nga larg, pĂ«r tĂ« pĂ«rmbledhur disa mendime â pĂ«rfytyrime mbi caching, tĂ« cilat do tĂ« ishin njĂ« hap i mirĂ« tĂ« rrotulloheshin pĂ«rpara njĂ« projekti tĂ« madh.
Kur lind detyra e caching
Detyra e caching nuk shfaqet thjesht kĂ«shtu. Ne jemi zhvillues, krijojmĂ« produktin softuerik dhe duam qĂ« ai tĂ« jetĂ« i kĂ«rkuar. NĂ«se produkti Ă«shtĂ« i kĂ«rkuar dhe i suksesshĂ«m â pĂ«rdoruesit rriten. Dhe mĂ« shumĂ« rriten dhe mĂ« shumĂ«. Dhe ja ku janĂ« shumĂ« pĂ«rdorues dhe atĂ«herĂ« produkti bĂ«het me ngarkesĂ« tĂ« lartĂ«.
NĂ« fazat fillestare nuk mendojmĂ« pĂ«r optimizimin dhe performancĂ«n e kodit. E rĂ«ndĂ«sishme Ă«shtĂ« funksionaliteti, ta nxjerrim shpejt pilotin dhe tĂ« testojmĂ« hipotezat. Dhe nĂ«se ngarkesa rritet â ne e pĂ«rmirĂ«sojmĂ« harduerin. E rrisim dy- deri tri- deri pesĂ«fish, le tĂ« jetĂ« deri nĂ« 10 herĂ«. Diku kĂ«tu â financat mĂ« shumĂ« nuk do tĂ« lejojnĂ«. Sa herĂ« do tĂ« rritet numri i pĂ«rdoruesve? Kjo do tĂ« jetĂ« jo 2-5-10, por nĂ« rast suksesi â do tĂ« jetĂ« nga 100-1000 deri nĂ« 100 mijĂ« herĂ«. Pra, herĂ«t a vonĂ« do tĂ« kemi nevojĂ« tĂ« merremi me optimizimin.
Supozoni, njĂ« pjesĂ« e kodit (ta quajmĂ« kĂ«tĂ« pjesĂ« funksion) punon pĂ«r njĂ« kohĂ« tĂ« gjatĂ« tĂ« papĂ«rshtatshme, dhe ne duam tĂ« reduktojmĂ« kohĂ«n e ekzekutimit. Funksioni â mund tĂ« jetĂ« qasje nĂ« bazĂ«n e tĂ« dhĂ«nave, mund tĂ« jetĂ« ekzekutimi i njĂ« logjike tĂ« komplikuar â e rĂ«ndĂ«sishme Ă«shtĂ« se ekzekutohet pĂ«r njĂ« kohĂ« tĂ« gjatĂ«. Sa mund tĂ« reduktohet koha e ekzekutimit? NĂ« limit â mund tĂ« reduktohet deri nĂ« zero, jo mĂ« tej. Si mund tĂ« reduktohet koha e ekzekutimit deri nĂ« zero? PĂ«rgjigjja: tĂ« pĂ«rjashtohet krejtĂ«sisht ekzekutimi. NĂ« vend tĂ« kĂ«saj â tĂ« kthehet menjĂ«herĂ« rezultati. Si mund ta njohim rezultatin? PĂ«rgjigjja: ose ta llogarisim, ose ta shohim diku. TĂ« llogarisim â Ă«shtĂ« e gjatĂ«. Dhe tĂ« shohim â Ă«shtĂ«, pĂ«r shembull, tĂ« mbajmĂ« mend rezultatin qĂ« funksioni e dha herĂ«n e kaluar kur u thirr me tĂ« njĂ«jtat parametra.
Pra ndaj, realizimi i funksionit nuk Ă«shtĂ« i rĂ«ndĂ«sishĂ«m pĂ«r ne. Mjafton tĂ« dimĂ« se cilat parametra ndikojnĂ« nĂ« rezultat. AtĂ«herĂ«, nĂ«se paraqesim vlerat e parametrave si njĂ« objekt qĂ« mund tĂ« pĂ«rdoret si çelĂ«s nĂ« njĂ« magazinĂ« tĂ« caktuar â atĂ«herĂ« rezultati i llogaritjes mund tĂ« ruhet dhe nĂ« kĂ«rkesĂ«n e ardhshme tĂ« merret pĂ«rsĂ«ri. NĂ«se kĂ«to regjistrime dhe lexime rezultati kalojnĂ« mĂ« shpejt se sa ekzekutimi i funksionit â kemi pĂ«rfitim tĂ« shpejtĂ«sisĂ«. Sasia e pĂ«rfitimit mund tĂ« arrijĂ« madje deri nĂ« 100, 1000 ose 100 mijĂ« herĂ« (10^5 â kjo Ă«shtĂ« mĂ« shumĂ« pĂ«rjashtim, por nĂ« rastin e njĂ« baze tĂ« rĂ«nduar â Ă«shtĂ« plotĂ«sisht e mundur).
Kërkesat kryesore për sistemin e memorizimit në cache
E para qĂ« mund tĂ« bĂ«het njĂ« kĂ«rkesĂ« pĂ«r sistemin e memorizimit nĂ« cache â shpejtĂ«sia e leximit dhe, nĂ« njĂ« masĂ« pak mĂ« tĂ« vogĂ«l â shpejtĂ«sia e shkruajtjes. Kjo Ă«shtĂ« e vĂ«rtetĂ«, por vetĂ«m deri nĂ« momentin kur ne e lançojmĂ« sistemin nĂ« prodhim.
Le të shkrijmë një rast të tillë.
Supozoni se kemi siguruar pajisjet pĂ«r ngarkesĂ«n aktuale dhe tani gradualisht po implementojmĂ« memorizimin nĂ« cache. Pak nga pak mĂ« shumĂ« pĂ«rdorues po shtohen, ngarkesa po rritet â pak shtojmĂ« cache, lidhim kĂ«tu e atje. Kjo vazhdon pĂ«r njĂ«farĂ« kohe, dhe tani funksionet e ngarkesĂ«s sĂ« rĂ«ndĂ« pothuajse nuk thirren mĂ« â e gjithĂ« ngarkesa e madhe bie mbi cache. Numri i pĂ«rdoruesve gjatĂ« kĂ«tij kohe Ă«shtĂ« rritur N herĂ«.
Dhe nĂ«se rezerva fillestare pĂ«r pajisjet mund tĂ« ishte 2-5 herĂ«, atĂ«herĂ« me ndihmĂ«n e cache-it ne mund tĂ« pĂ«rmirĂ«sojmĂ« performancĂ«n 10 herĂ« ose, nĂ« njĂ« rast tĂ« mirĂ«, 100 herĂ«, ndoshta edhe 1000 herĂ«. Kjo do tĂ« thotĂ«, nĂ« tĂ« njĂ«jtin ekip â pĂ«rpunojmĂ« 100 herĂ« mĂ« shumĂ« kĂ«rkesa. Mrekullisht, kemi merituar njĂ« shpĂ«rblim!
Por tani, nĂ« njĂ« moment tĂ« bukur, rastĂ«sisht, sistemi dĂ«shtoi dhe cache ra. AsgjĂ« e veçantĂ« â sepse cache u zgjodh sipas kĂ«rkesĂ«s "shpejtĂ«si e lartĂ« leximi dhe shkruajtjeje, e tjera nuk janĂ« tĂ« rĂ«ndĂ«sishme".
NĂ« lidhje me ngarkesĂ«n fillestare, rezerva pĂ«r pajisjet ishte 2-5 herĂ«, ndĂ«rsa ngarkesa gjatĂ« kĂ«tij procesi Ă«shtĂ« rritur 10-100 herĂ«. Me ndihmĂ«n e cache-it ne pĂ«rjashtuam thirrjet pĂ«r funksione tĂ« rĂ«nda dhe prandaj gjithçka funksiononte shpejt. Tani, pa cache â pĂ«r sa herĂ« do tĂ« bjerĂ« sistemi ynĂ«? ĂfarĂ« do tĂ« ndodhĂ« me ne? Sistemi do tĂ« bjerĂ«.
Edhe nĂ«se cache nuk ka rĂ«nĂ«, por vetĂ«m Ă«shtĂ« pastruar pĂ«r njĂ«farĂ« kohe â do tĂ« duhet ta ngrohĂ«m, dhe kjo do tĂ« marrĂ« ca kohĂ«. Dhe pĂ«r kĂ«tĂ« periudhĂ« â ngarkesa kryesore do tĂ« bjerĂ« mbi funksionalitetin.
Përfundim: projektet me ngarkesë të lartë në prodhim kërkojnë nga sistemi i memorizimit në cache jo vetëm shpejtësi të lartë leximi dhe shkruajtjeje, por gjithashtu ruajtje të të dhënave dhe qëndresë ndaj dështimeve.
DĂ«shtimi i zgjedhjes
NĂ« projektin me panelin e administratĂ«s â zgjedhja u bĂ« kĂ«shtu: fillimisht instaluan Hazelcast, pasi tashmĂ« ishin tĂ« njohur me kĂ«tĂ« produkt nga eksperienca e faqes kryesore. Por, kĂ«tu njĂ« zgjedhje e tillĂ« rezultoi e pasuksesshme â pĂ«r profilin tonĂ« tĂ« ngarkesĂ«s, Hazelcast punon jo vetĂ«m ngadalĂ«, por jashtĂ«zakonisht ngadalĂ«. Dhe me afatet e prodhimit, ne nĂ« atĂ« kohĂ« kishim nĂ«nshkruar tashmĂ«.
Spoiler: si kam ndodhur rrethanat qĂ« ne humbĂ«m njĂ« dobĂ«si tĂ« tillĂ« dhe patĂ«m njĂ« situatĂ« tĂ« tensionuar â do t'ju tregoj nĂ« pjesĂ«n e dytĂ« â dhe si pĂ«rfunduam, dhe si doli situata. Por tani â do tĂ« them vetĂ«m se ishte njĂ« stres i fortĂ«, dhe "nuk po mendojmĂ«, trondisim shishen". "Trondisim shishen" â Ă«shtĂ« gjithashtu njĂ« spoiler, pĂ«r kĂ«tĂ« pak mĂ« poshtĂ«.
ĂfarĂ« bĂ«mĂ«:
- Kemi bërë një listë të të gjitha sistemeve që sugjeron google dhe StackOverflow. Pak më shumë se 30.
- Krijuam teste me ngarkesĂ«n, qĂ« karakterizon prodhimin. PĂ«r kĂ«tĂ«, regjistruam tĂ« dhĂ«nat qĂ« kalojnĂ« pĂ«rmes sistemit nĂ« ambientin e prodhimit â njĂ« lloj sniffer pĂ«r tĂ« dhĂ«nat jo nĂ« rrjet, por brenda sistemit. NĂ« teste, ekzekutuam pikĂ«risht kĂ«to tĂ« dhĂ«na.
- E gjithĂ« ekipi, çdo kush zgjedh sistemin tjetĂ«r nga lista, e konfigurton, e provon testin. NĂ«se testi nuk kalon, nuk e mban ngarkesĂ«n â e heqim, kalojmĂ« te tĂ« ardhshmit nĂ« radhĂ«.
- Në sistemin e 17-të u bë e qartë se gjithçka është e pafat. Mjafton "të trondisim shishen", është koha për të menduar seriozisht.
Por ky është varianti, kur ne duhet të zgjedhim një sistem që "do të kalojë me shpejtësi" në testet e përgatitura paraprakisht. Por çfarë nëse nuk ka teste të tilla dhe dëshirojmë të zgjedhim më shpejt?
Le tĂ« modelojmĂ« njĂ« skenar tĂ« tillĂ« (Ă«shtĂ« e vĂ«shtirĂ« tĂ« imagjinoni se njĂ« zhvillues mid-level ose mĂ« i avancuar jeton nĂ« vakuum, dhe nĂ« momentin e zgjedhjes ende nuk ka pĂ«rcaktuar preferencĂ«n se çfarĂ« produkti tĂ« provojĂ« sĂ« pari â prandaj, reflektimet e mĂ«tejshme janĂ« mĂ« shumĂ« teorike/filozofike/rrreth njĂ« juniori).
Pasi kemi përcaktuar kërkesat, do të fillojmë të zgjedhim një zgjidhje nga kutia. Pse të shpikim biçikletën: ne do të shkosh dhe marrim një sistem memorizimi në cache të gatshëm.
NĂ«se sapo po filloni dhe do tĂ« kĂ«rkoni nĂ« Google, ndoshta do tĂ« jetĂ« njĂ« renditje mĂ« shumĂ«-mĂ« pak, por nĂ« pĂ«rgjithĂ«si, kĂ«to do tĂ« jenĂ« orientimet. NĂ« radhĂ« tĂ« parĂ« do tĂ« ndeshni Redis, ai Ă«shtĂ« kudo nĂ« bisedĂ«. MĂ« pas do tĂ« mĂ«soni se ekziston EhCache si sistemi mĂ« i vjetĂ«r dhe i provuar. MĂ« tej do tĂ« shkruhet pĂ«r Tarantool â njĂ« zhvillim vendas, qĂ« ka njĂ« aspekt unik zgjidhjeje. Dhe gjithashtu pĂ«r Ignite, sepse tani Ă«shtĂ« nĂ« rritje tĂ« popullaritetit dhe gĂ«zon mbĂ«shtetje nga SberTech. NĂ« fund do tĂ« flasim edhe pĂ«r Hazelcast, sepse nĂ« botĂ«n e enterprise-it ai shpesh shfaqet nĂ« mesin e kompanive tĂ« mĂ«dha.
Ky listë nuk përfundon këtu, ekzistojnë dhjetëra sisteme. Ne do të trajtojmë vetëm një. Do të marrim 5 sistemet e zgjedhura për një "konkurs bukurie" dhe do të kryejmë një përzgjedhje. Kush do të jetë fituesi?
Redis
Le të lexojmë se çfarë thonë në faqen zyrtare.
â projekt open-source. Ofron njĂ« depo tĂ« dhĂ«nash nĂ« memorie, mundĂ«sinĂ« e ruajtjes nĂ« disk, ndarjen automatikisht nĂ« parti, disponueshmĂ«ri tĂ« lartĂ« dhe rikuperim pas ndĂ«rprerjeve rrjeti.
Duket se gjithçka Ă«shtĂ« nĂ« rregull, mund ta marrim dhe ta lidhim â gjithçka qĂ« nevojitet, ai e bĂ«n. Por le tĂ« shohim vetĂ«m pĂ«r kuriozitetin mbi kandidatĂ«t e tjerĂ«.
EhCache
â "cache mĂ« i pĂ«rdorur pĂ«r Java" (pĂ«rkthimi i sloganit nga faqja zyrtare). Edhe ai Ă«shtĂ« open-source. Dhe kĂ«tu kuptojmĂ« se Redis nuk Ă«shtĂ« pĂ«r java, Ă«shtĂ« njĂ« sistem i pĂ«rgjithshĂ«m, dhe pĂ«r t'u lidhur me tĂ« nevojitet njĂ« mbĂ«shtjellĂ«s. NdĂ«rsa EhCache do tĂ« ishte mĂ« i pĂ«rshtatshĂ«m. ĂfarĂ« tjetĂ«r premton sistemi? BesueshmĂ«ri, provim, funksionalitet tĂ« plotĂ«. Po ashtu, Ă«shtĂ« edhe sistemi mĂ« i pĂ«rhapur. Dhe cache tĂ« terabajtĂ«ve tĂ« dhĂ«nash.
Redis është harruar, jam gati të zgjedh EhCache.
Por ndjenja patriotike më shtyn të shoh se çfarë ka Tarantool.
Tarantool
â pĂ«rballet me emĂ«rtimin "Platforma pĂ«r integrimin e tĂ« dhĂ«nave nĂ« kohĂ« reale". Duket shumĂ« e komplikuar, prandaj le tĂ« lexojmĂ« faqen me kujdes dhe tĂ« gjejmĂ« njĂ« deklaratĂ« tĂ« zhurmshme: "Cache 100% tĂ« tĂ« dhĂ«nave nĂ« memorie". Kjo duhet tĂ« ngrejĂ« pyetje â sepse tĂ« dhĂ«nat mund tĂ« jenĂ« shumĂ« mĂ« tĂ« mĂ«dha se memoria. Shpjegimi pĂ«r kĂ«tĂ« Ă«shtĂ« se pĂ«r shkrimin e tĂ« dhĂ«nave nĂ« disk nga memoria, Tarantool nuk kalon pĂ«rmes serializimit. NĂ« vend tĂ« kĂ«saj â pĂ«rdor veçoritĂ« e nivelit tĂ« ulĂ«t tĂ« sistemit, kur memoria thjesht mapehet nĂ« sistemin e skedarĂ«ve me rezultate shumĂ« tĂ« mira I/O. NĂ« tĂ«rĂ«si, e bĂ«nĂ« ndonjĂ«herĂ« fantastike dhe tĂ« shkĂ«lqyer.
Le tĂ« shqyrtojmĂ« aplikimet: Mail.ru, Avito, Beeline, MegaFon, Alfa-Bank, GazpromâŠ
Nëse ende kishte ndonjë dyshim për Tarantool, atëherë rasti i implementimit në Mastercard më çon deri në vend. Po e marr Tarantool.
Por gjithsesiâŠ
Ignite
... ka akoma , paraqitet si "platforma e llogaritjes në memorie... shpejtësi në memorie mbi petabajt të dhënash". Këtu gjithashtu ka shumë përfitime: cache të shpërndarë në memorie, depo më e shpejtë e çelës-vlerë dhe cache, shkallëzim horizontal, disponueshmëri të lartë, integritet të rreptë. Në përgjithësi, ndodhet se më i shpejti është Ignite.
Aplikimet: Sberbank, American Airlines, Yahoo! Japan. Dhe pastaj mësoj se Ignite nuk është thjesht implementuar në Sberbank, por ekipi i SberTech dërgon njerëzit e tij në ekipin e vetë Ignite, për ta përmirësuar produktin. Kjo më bën tërheqës dhe jam gati të zgjedh Ignite.
Kjo është krejt e paqartë për çfarë arsyeje, unë shikoj në pikën e pestë.
Hazelcast
Hyr në faqen , lexoj. Dhe del se zgjidhja më e shpejtë për caching të shpërndarë është Hazelcast. Ai është disa herë më i shpejtë se të gjitha zgjidhjet e tjera dhe në fakt është lider në fushën e grid-it të dhënave në memorie. Në këtë kontekst, marrjen e diçkaje tjetër do të ishte një çmenduri. Po ashtu, përdor ruajtjen e tepruar të të dhënave për të siguruar funksionimin e vazhdueshëm të klasterit pa humbje të të dhënave.
Mjaft, kam vendosur të marr Hazelcast.
Krahasimi
Por nëse shikon, të pesë kandidatët janë përshkruar në mënyrë që secili prej tyre është më i miri. Si të zgjedhësh? Mund të shikojmë se cili është më i popullarizuari, të kërkojmë krahasime dhe dhimbja e kokës do të kalojë.
Gjejmë një të tillë , zgjedhim sistemet tona 5.
Aty janĂ« tĂ« renditura: nĂ« krye Redis, nĂ« vendin e dytĂ« â Hazelcast, po popullarizojnĂ« Tarantool dhe Ignite, EhCache vazhdon tĂ« mbetet siç ishte.
Por le tĂ« shikojmĂ« : lidhjet nĂ« faqet e internetit, interesi i pĂ«rgjithshĂ«m pĂ«r sistemin, ofertat e punĂ«s â e shkĂ«lqyer! Do tĂ« thotĂ«, kur sistemi im do tĂ« bjerĂ«, do tĂ« them: "Jo, ai Ă«shtĂ« i besueshĂ«m! Ja shumĂ« oferta pune...". NjĂ« krahasim kaq i thjeshtĂ« nuk Ă«shtĂ« i mjaftueshĂ«m.
Të gjitha këto sisteme nuk janë thjesht sisteme për caching. Ata gjithashtu kanë shumë caktuara, përfshirë - kur të dhënat nuk dërgohen klientit për përpunim, por përkundazi: kodi që duhet të ekzekutohet mbi të dhënat, zhvendoset në server, aty ekzekutohet dhe rezultati kthehet. Dhe si një sistem të veçantë për caching, ata nuk shqyrtohen aq shpesh.
MirĂ«, nuk dorĂ«zohemi, do tĂ« gjejmĂ« njĂ« krahasim tĂ« drejtpĂ«rdrejtĂ« tĂ« sistemeve. Marrim dy opsionet e sipĂ«rme â Redis dhe Hazelcast. Na intereson shpejtĂ«sia, mbi kĂ«tĂ« parametrin do i krahasojmĂ«.
Hz vs Redis
Gjejmë një të tillë :
Blu është Redis, e kuqe është Hazelcast. Hazelcast fiton gjithmonë, dhe kjo ka një arsyetim: është shumë-threading, i optimizuar lartë, çdo thread punon me një particion të vet, kështu që nuk ka bllokime. Ndërsa Redis është një-threading, dhe nuk përfiton nga CPU-të moderne shumë-njëshe. Hazelcast ka I/O asinkron, ndërsa Redis-Jedis ka socket të bllokuar. Në fund të fundit, Hazelcast përdor një protokoll binar, ndërsa Redis është orientuar në tekst, domethënë nuk është efikas.
PĂ«r çdo rast, le tĂ« referohemi nĂ« njĂ« burim tjetĂ«r krahasimi. ĂfarĂ« do tĂ« na tregojĂ« ai?
Redis vs Hz
Një tjetër :
KĂ«tu anasjelltas, e kuqe Ă«shtĂ« Redis. DomethĂ«nĂ«, Redis fiton ndaj Hazelcast nĂ« performancĂ«. NĂ« krahasimin e parĂ«, fitonte Hazelcast, nĂ« tĂ« dytin â Redis. e shpjeguan shumĂ« saktĂ«, pse nĂ« krahasimin e mĂ«parshĂ«m fitoi Hazelcast.
Doli se rezultati i parës ishte në të vërtetë i manipuluar: Redis u mor në kutinë e tij bazë, ndërsa Hazelcast u optimizua për rastin e testit. Kështu që del: së pari, askujt nuk mund t'i besohet, së dyti, kur përfundojmë duke zgjedhur një sistem, duhet ta konfigurim të saktë. Këto konfigurime përfshijnë dhjetëra, pothuajse qindra parametra.
TĂ« tundim shishen
Dhe e gjithë kjo proces, që ne tani e kemi kryer, mund ta shpjegoj me metaforën "Të tundim shishen". Domethënë, tani mund të mos programojmë, tani e rëndësishme është të dimë të lexojmë stackoverflow. Dhe kam në ekipin tim një person, profesionist, i cili punon me këtë mënyrë në momentet kritike.
ĂfarĂ« bĂ«n ai? Shikon njĂ« gjĂ« qĂ« nuk funksionon, sheh stack trace, merr disa fjalĂ« prej tij (cilat saktĂ«sisht â kjo Ă«shtĂ« ekspertiza e tij nĂ« program), kĂ«rkon nĂ« google, gjen stackoverflow mes pĂ«rgjigjeve. Pa lexuar, pa menduar, mes pĂ«rgjigjeve pĂ«r pyetjen â ai zgjedh diçka qĂ« i ngjan mĂ« shumĂ« propozimit "tĂ« bĂ«jmĂ« kĂ«tĂ« e atĂ«" (zgjidhja e njĂ« pĂ«rgjigjeje â kjo Ă«shtĂ« talenti i tij, sepse nuk Ă«shtĂ« gjithmonĂ« ajo pĂ«rgjigje qĂ« ka marrĂ« mĂ« shumĂ« like), e aplikon, sheh: nĂ«se diçka ka ndryshuar, atĂ«herĂ« shkĂ«lqyer. NĂ«se nuk ka ndryshuar â e rikthejmĂ«. Dhe pĂ«rsĂ«risim ekzekutimin-kontrollin-kĂ«rkimin. Dhe me kĂ«tĂ« mĂ«nyrĂ« intuitiv ai arrin qĂ« brenda njĂ« kohe, kodi tĂ« funksionojĂ«. Ai nuk e di pse, nuk e di se çfarĂ« ka bĂ«rĂ«, nuk mund ta shpjegojĂ«. Por! Kjo gjĂ« punon. Dhe "zjarri Ă«shtĂ« shuar". Tani po kuptojmĂ« se çfarĂ« kemi bĂ«rĂ«. Kur programa funksionon â Ă«shtĂ« shumĂ« mĂ« e lehtĂ«. Dhe kursen ndjeshĂ«m kohĂ«n.
Ky metodë shpjegohet shumë mirë me këtë shembull.
Dikur ka qenë shumë popullor të ndërtohen anije në shishe. Në këtë rast, anija është e madhe dhe e brishtë, ndërsa goja e shishes është shumë e ngushtë, nuk mund të futet brenda. Si të ndërtohet?
Ka një metodë të tillë, shumë të shpejtë dhe shumë efektive.
Anija përbëhet nga shumë detaje: shkopinj, litarë, vela, ngjitës. Të gjitha këto i vendosim në shishe.
E marrim shishen me dy duar, dhe fillojmĂ« ta tundim. E tundim-tundim. Dhe zakonisht â del njĂ« gjĂ« e çfarĂ«doshme, sigurisht. Por ndonjĂ«herĂ«. NdonjĂ«herĂ« del anija! MĂ« saktĂ«, diçka qĂ« i ngjan anijes.
Ne kĂ«tĂ« diçka i tregojmĂ« dikujt: "SerĂ«ga, e sheh!?". Dhe me tĂ« vĂ«rtetĂ«, nga larg â si duket anija. Por mĂ« tej nuk duhet lejuar.
Ka edhe një mënyrë tjetër. Përdorim djem më të avancuar, si hakerë.
I kam dhĂ«nĂ« njĂ« detyrĂ« njĂ« tĂ« tilli, ai e bĂ«ri gjithçka dhe iku. Dhe shikon â sikur Ă«shtĂ« bĂ«rĂ«. Por pas njĂ« kohe, kur duhet pĂ«rmirĂ«suar kodi â atĂ«herĂ« fillon njĂ« kaos pĂ«r shkak tĂ« tij... MirĂ« se ai pĂ«rfundoi tĂ« ikĂ« larg. KĂ«ta janĂ« djem tĂ« tillĂ«, qĂ« nĂ« shembullin e shishes do tĂ« bĂ«jnĂ« kĂ«shtu: shihni, aty ku Ă«shtĂ« fundi â qelqi Ă«shtĂ« e deformuar. Dhe nuk Ă«shtĂ« krejtĂ«sisht e qartĂ«, a Ă«shtĂ« e tejdukshme apo jo. AtĂ«herĂ« "hakerĂ«t" e presin kĂ«tĂ« fund, e fusin anijen brenda, fundin pastaj e ngjisin pĂ«rsĂ«ri, dhe si duket kĂ«shtu duhet.
Nga pikĂ«pamja e formulimit tĂ« detyrĂ«s duket se gjithçka Ă«shtĂ« nĂ« rregull. Por nĂ« shembullin e anijeve: pĂ«r çfarĂ« duhet tĂ« ndĂ«rtohet kjo anije, kujt i nevojitet ajo? Ajo nuk ka asnjĂ« funksionalitet. Zakonisht kĂ«to anije â janĂ« dhurata pĂ«r njerĂ«z shumĂ« tĂ« rĂ«ndĂ«sishĂ«m, qĂ« e vendosin ato nĂ« raftin e tyre lart, si njĂ« simbol, si njĂ« shenjĂ«. Dhe nĂ«se pĂ«r njĂ« person tĂ« tillĂ«, njĂ« drejtues biznesi tĂ« madh ose njĂ« zyrtar tĂ« lartĂ«, si flamur do tĂ« qĂ«ndrojĂ« njĂ« gjĂ« e tillĂ« e bĂ«rĂ« keq, ku i Ă«shtĂ« prerĂ« qafa? Do tĂ« ishte mĂ« mirĂ« tĂ« mos e di kurrĂ« pĂ«r kĂ«tĂ«. Pra, si bĂ«hen nĂ« fund kĂ«to anije, tĂ« cilat mund tĂ« dhurohen njĂ« personi tĂ« rĂ«ndĂ«sishĂ«m?
Vendi i vetëm, ky është një vend kyç në të cilin nuk mund të bëhet asgjë, është korniza. Dhe trupi i anijes kalon përmes qafës. Ndërsa anija montohen jashtë shishe. Por nuk është e thjeshtë të montosh anijen, është një art delikat. Një mekanizëm special shtohet në pjesët, i cili i lejon ato të ngrihen më vonë. Për shembull, vela mblidhen me kujdes dhe futen brenda, dhe pastaj me pincë ato ngrihen me precizitet dhe kujdes. Në fund, prodhohet një vepër arti që mund të dhurohet me krenari dhe pastërti.
Dhe nĂ«se duam qĂ« projekti tĂ« jetĂ« i suksesshĂ«m â nĂ« ekip duhet tĂ« ketĂ« tĂ« paktĂ«n njĂ« njeri-artizan. Ai, i cili kujdeset pĂ«r cilĂ«sinĂ« e produktit dhe merr parasysh tĂ« gjitha aspektet, pa sakrifikuar asgjĂ«, madje as nĂ« momentet e stresit, kur rrethanat kĂ«rkojnĂ« tĂ« bĂ«jmĂ« diçka me ngut nĂ« dĂ«m tĂ« asaj qĂ« Ă«shtĂ« e rĂ«ndĂ«sishme. TĂ« gjitha projektet e suksesshme, tĂ« cilat janĂ« tĂ« qĂ«ndrueshme, tĂ« cilat kanĂ« kaluar provĂ«n e kohĂ«s, janĂ« ndĂ«rtuar mbi kĂ«tĂ« parim. Ato kanĂ« diçka shumĂ« tĂ« saktĂ« dhe unike, diçka qĂ« pĂ«rdor tĂ« gjitha mundĂ«sitĂ« e disponueshme. NĂ« shembullin e anijes nĂ« shishe â pĂ«rshkruhet se trupi i anijes kalon pĂ«rmes qafĂ«s.
Duke u kthyer te detyra e zgjedhjes sĂ« serverit tonĂ« tĂ« keq-katalogjimit, si mund tĂ« aplikohej ky metodĂ«? UnĂ« propozoj njĂ« variant zgjedhjeje nga tĂ« gjitha sistemet qĂ« ekzistojnĂ« â mos e tundni shishen, mos zgjidhni, por shihni se çfarĂ« ka brenda dhe ku duhet tĂ« japim vĂ«mendjen kur zgjidhim sistemin.
Ku të kërkojmë ngushticën
Le tĂ« pĂ«rpiqemi tĂ« mos e tundim shishen, tĂ« mos shqyhej gjithçka njĂ« nga njĂ«, por tĂ« shohim se cilat probleme do tĂ« shfaqen, nĂ«se ndonjĂ«herĂ«, pĂ«r detyrĂ«n tonĂ« â tĂ« projektojmĂ« njĂ« sistem tĂ« tillĂ« vetĂ«. Sigurisht, nuk do tĂ« ndihmojmĂ« pĂ«r tĂ« ndĂ«rtuar njĂ« biçikletĂ«, por do tĂ« pĂ«rdorim kĂ«tĂ« skemĂ« pĂ«r tĂ« orientuar nĂ« çfarĂ« tĂ« dhĂ«nash tĂ« fokusohemi nĂ« pĂ«rshkrimet e produkteve. Le tĂ« skicojmĂ« njĂ« skemĂ« tĂ« tillĂ«.
NĂ«se sistemi Ă«shtĂ« i shpĂ«rndarĂ«, do tĂ« kemi disa servera (6). Le tĂ« themi katĂ«r (Ă«shtĂ« e lehtĂ« t'i vendosim nĂ« imazh, por, natyrisht, ata mund tĂ« jenĂ« sa tĂ« dojĂ«). NĂ«se serverat janĂ« nĂ« nyje tĂ« ndryshme, do tĂ« ketĂ« ndonjĂ« kod qĂ« ndryshon pĂ«r tĂ« bĂ«rĂ« qĂ« kĂ«to nyje tĂ« formojnĂ« njĂ« grup dhe nĂ« rast ndarjeje â tĂ« lidhin dhe tĂ« njohin njĂ«ri-tjetrin.
Gjithashtu na nevojitet logjika e kodit (2), e cila merret me keq-katalogjimin. Me kĂ«tĂ« kod, disa klientĂ« ndĂ«rveprojnĂ« pĂ«rmes njĂ« API. Kodi klientit (1) mund tĂ« jetĂ« ose brenda kĂ«saj JVM, ose tĂ« lidhet pĂ«rmes rrjetit. Logjika, e implementuar brenda â ka vendime pĂ«r cilat objekte do tĂ« mbahen nĂ« memorie, cilat do tĂ« hidhen. PĂ«r tĂ« ruajtur cache-in, pĂ«rdorim memorien (3), por nĂ«se Ă«shtĂ« e nevojshme, njĂ« pjesĂ« e tĂ« dhĂ«nave mund tĂ« ruhet gjithashtu nĂ« disk (4).
Le tĂ« shohim nĂ« cilat pjesĂ« do tĂ« ndodhĂ« ngarkesa. NĂ« tĂ« vĂ«rtetĂ«, çdo shigjetĂ« dhe çdo nyje do tĂ« ngarkohen. SĂ« pari, midis kodit tĂ« klientit dhe API-sĂ«, nĂ«se Ă«shtĂ« ndĂ«rveprimi nĂ« rrjet, rĂ«nia mund tĂ« jetĂ« mjaft e dukshme. SĂ« dyti, brenda vetĂ« API-sĂ« â duke u pĂ«rpjekur shumĂ« me logjikĂ«n e komplikuar, mund tĂ« bllokohemi nĂ« CPU. Dhe do tĂ« ishte mirĂ« qĂ« logjika tĂ« mos e menaxhojĂ« memorien mĂ« tepĂ«r se sa Ă«shtĂ« e nevojshme. Dhe ndĂ«rlidhja me sistemin e skedarĂ«ve mbetet â nĂ« rast tĂ« zakonshĂ«m, kjo do tĂ« thotĂ« tĂ« serializohem / tĂ« rikuperohet dhe tĂ« shkruhet / tĂ« lexohen.
Më pas, ndërveprimi me grupin. Ka shumë mundësi që ai të jetë në këtë sistem, por mund të jetë edhe ndaras. Këtu gjithashtu duhet marrë parasysh kalimi i të dhënave për të, shpejtësia e serializimit të të dhënave dhe ndërveprimi midis grupit.
Tani, nga njĂ«ra anĂ« â mund tĂ« paraqesim "cila ingranazhe do tĂ« lĂ«vizin" nĂ« sistemin e keq-katalogjimit gjatĂ« pĂ«rpunimit tĂ« kĂ«rkesave nga kodi ynĂ«, dhe nga ana tjetĂ«r â mund tĂ« parashikojmĂ« se çfarĂ« lloj 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 mĂ« shumĂ« ose mĂ« pak tĂ« arsyeshme â pĂ«r tĂ« pĂ«rzgjedhur sistemin sipas rastit tonĂ« tĂ« pĂ«rdorimit.
Hazelcast
Le të shohim si mund ta aplikojmë këtë ndarje në listën tonë. për shembull, Hazelcast.
Për të vendosur / marrë të dhënat nga Hazelcast, kodi i klientit i referohet (1) API-së. Hz lejon të ekzekutohet serveri si embedded, dhe në këtë rast referimi ndaj API-së është një thirrje metodu brenda JVM, mund të konsiderohet pa kosto.
PĂ«r tĂ« punuar logjika nĂ« (2), Hz mbĂ«shtetet nĂ« hashin e vargje tĂ« bajtave tĂ« serializuar tĂ« çelĂ«sit â do tĂ« thotĂ«, serializimi i çelĂ«sit do tĂ« ndodhĂ« me çdo rast. Ky Ă«shtĂ« njĂ« overhead i pashmangshĂ«m pĂ«r Hz.
StrategjitĂ« e Eviction-it janĂ« implementuar mirĂ«, por pĂ«r raste tĂ« veçanta â mund tĂ« aktivizohen tĂ« tuat. PĂ«r kĂ«tĂ« pjesĂ« nuk ka nevojĂ« tĂ« shqetĂ«sohesh.
Ruajtja (4) mund tĂ« conectohet. ShkĂ«lqyer. Interaksioni (5) pĂ«r embedded mund tĂ« konsiderohet momental. ShkĂ«mbimi i tĂ« dhĂ«nave midis nyjave nĂ« klasĂ«r (6) â po, ai ekziston. Kjo Ă«shtĂ« njĂ« kontribut pĂ«r qĂ«ndrueshmĂ«rinĂ« nĂ« kosto tĂ« shpejtĂ«sisĂ«. Ămimin e ul nĂ«pĂ«rmjet Hz-funksionit Near-cache â tĂ« dhĂ«nat e marra nga nyjat e tjera tĂ« klasrĂ«s do tĂ« ruhen nĂ« 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) â mbi Hazelcast mund tĂ« vendoset njĂ« cache tjetĂ«r, pĂ«r tĂ« dhĂ«nat mĂ« tĂ« nxehta. NĂ« Sportmaster pĂ«r kĂ«tĂ« qĂ«llim u zgjodh Caffeine.
Për përmirësim në nivelin (6), në Hz janë ofruar dy lloje ruajtjeje: IMap dhe ReplicatedMap.
Duhet të themi si Hazelcast hyri në grumbullin e teknologjive të Sportmaster.
NĂ« vitin 2012, kur ne punonim mbi pilotin e parĂ« tĂ« faqes sĂ« internetit tĂ« ardhshĂ«m, pikĂ«risht Hazelcast ishte lidhja e parĂ« qĂ« ofroi motorri i kĂ«rkimit. Njohja filloi "nga hera e parĂ«" â na mahniti se brenda dy orĂ«ve, kur e lidhem Hz nĂ« sistem â ai funksiononte. Dhe funksiononte mirĂ«. Deri nĂ« fund tĂ« ditĂ«s pĂ«rfunduan disa teste, u gĂ«zuam. Dhe kjo rezervĂ« gĂ«zimi na mjaftoi pĂ«r tĂ« kaluar ato surpriza qĂ« Hz na ofroi me kalimin e kohĂ«s. Tani ekipi i Sportmaster nuk ka arsye pĂ«r tĂ« hequr dorĂ« nga Hazelcast.
Por argumente tĂ« tilla si "lidhja e parĂ« nĂ« motorin e kĂ«rkimit" dhe "mbi shpejtĂ« pĂ«r tĂ« krijuar HelloWorld" â kjo, natyrisht, Ă«shtĂ« njĂ« pĂ«rjashtim dhe veçori e momentit nĂ« tĂ« cilin ndodhi zgjedhja. Sfidat e vĂ«rteta pĂ«r sistemin e zgjedhur fillojnĂ« me kalimin nĂ« prodhim, dhe pikĂ«risht nĂ« kĂ«tĂ« fazĂ« duhet tĂ« jepet vĂ«mendje kur zgjidhni çdo sistem, pĂ«rfshirĂ« dhe cache-in. NĂ« thelb, nĂ« rastin tonĂ« mund tĂ« thuhet se zgjodhĂ«m Hazelcast rastĂ«sisht, por pastaj doli se e zgjodhĂ«m siç duhet.
PĂ«r prodhimin shumĂ« Ă«shtĂ« mĂ« e rĂ«ndĂ«sishme: monitorimi, trajtimi i gabimeve nĂ« nyjat e veçanta, replikimi i tĂ« dhĂ«nave, kostoja e shkallĂ«zimit. Pra, Ă«shtĂ« e nevojshme tĂ« jepet vĂ«mendje ndaj detyrave qĂ« do tĂ« lindin pikĂ«risht gjatĂ« mbĂ«shtetjes sĂ« sistemit â kur ngarkesa do tĂ« kalojĂ« me dhjetĂ«ra herĂ« atĂ« qĂ« Ă«shtĂ« planifikuar, kur tĂ« ngarkohet ndonjĂ« gjĂ« e gabuar dhe nĂ« vendin e gabuar, kur do tĂ« nevojitet tĂ« deploy njĂ« version tĂ« ri tĂ« kodit, tĂ« zĂ«vendĂ«sohet tĂ« dhĂ«nat dhe tĂ« bĂ«het kjo pa u vĂ«nĂ« re nga klientĂ«t.
Për të gjitha këto kërkesa, Hazelcast, padyshim, përshtatet.
Të vazhdojmë
Por Hazelcast â nuk Ă«shtĂ« njĂ« panacee. NĂ« vitin 2017 ne zgjodhĂ«m Hazelcast pĂ«r cache nĂ« admin panel, thjesht duke u mbĂ«shtetur nĂ« pĂ«rshtypjet e mira nga eksperienca e kaluar. Kjo luajti njĂ« rol kryesor nĂ« njĂ« shaka tĂ« keqe, pĂ«r shkak tĂ« sĂ« cilĂ«s ne u gjendĂ«m nĂ« njĂ« situatĂ« tĂ« komplikuar dhe "heroikisht" dolĂ«m nga ajo pĂ«r 60 ditĂ«. Por pĂ«r kĂ«tĂ«, nĂ« pjesĂ«n tjetĂ«r.
Dhe për tani⊠Gëzuar Kod të Ri!
Burimi: habr.com
