{"id":73949,"date":"2020-03-13T02:42:07","date_gmt":"2020-03-12T23:42:07","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1"},"modified":"2020-03-13T02:42:07","modified_gmt":"2020-03-12T23:42:07","slug":"kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1","title":{"rendered":"Si ne n\u00eb Sportmaster zgjodh\u00ebm sistemin e caching. Pjesa 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

P\u00ebrsh\u00ebndetje! Un\u00eb quhem Aleksey Pyankov, jam zhvillues n\u00eb kompanin\u00eb Sportmaster. N\u00eb k\u00ebt\u00eb post<\/a><\/noindex> un\u00eb tregova se si filloi puna p\u00ebr faqen e Sportmaster n\u00eb vitin 2012, cilat iniciativa arrit\u00ebm t\u00eb \"shtyjm\u00eb\" dhe, p\u00ebrkundrazi, cilat pengesa mblodh\u00ebm.<\/p>\n

Sot dua t\u00eb ndaj mendimet e mia q\u00eb vijn\u00eb nga nj\u00eb histori tjet\u00ebr \u2013 zgjedhja e sistemit t\u00eb caching p\u00ebr backend-in java n\u00eb administrat\u00ebn e faqes. Kjo histori ka nj\u00eb r\u00ebnd\u00ebsi t\u00eb ve\u00e7ant\u00eb p\u00ebr mua \u2013 ndon\u00ebse e gjith\u00eb historia zhvillohej p\u00ebr vet\u00ebm 2 muaj, k\u00ebto 60 dit\u00eb punuam nga 12-16 or\u00eb pa asnj\u00eb dit\u00eb pushimi. Kurr\u00eb m\u00eb par\u00eb nuk kisha menduar dhe as imagjinuar se mund t\u00eb punosh kaq shum\u00eb.<\/p>\n

Prandaj, tekstin e ndaj n\u00eb 2 pjes\u00eb, q\u00eb t\u00eb mos ngarkojm\u00eb plot\u00ebsisht. P\u00ebrkundrazi, pjesa e par\u00eb do t\u00eb jet\u00eb shum\u00eb e leht\u00eb \u2014 nj\u00eb p\u00ebrgatitje, nj\u00eb hyrje, disa reflektime mbi at\u00eb se \u00e7'\u00ebsht\u00eb caching. N\u00ebse ju jeni tashm\u00eb nj\u00eb zhvillues me p\u00ebrvoj\u00eb ose keni punuar me cache, nga ana teknike, p\u00ebr t\u00eb, ndoshta nuk do t\u00eb ket\u00eb asgj\u00eb t\u00eb re n\u00eb k\u00ebt\u00eb artikull. Por p\u00ebr nj\u00eb junior, nj\u00eb p\u00ebrmbledhje e till\u00eb mund t\u00eb tregoj\u00eb n\u00eb \u00e7far\u00eb drejtimi t\u00eb shikoni n\u00ebse ndodhet n\u00eb nj\u00eb kryq\u00ebzim t\u00eb till\u00eb.<\/p>\n

\"Si<\/a><\/noindex>
\n<\/a><\/noindex>
\nKur versioni i ri i faqes Sportmaster u lan\u00e7ua n\u00eb produksion, t\u00eb dh\u00ebnat mb\u00ebrrinin n\u00eb nj\u00eb m\u00ebnyr\u00eb q\u00eb, t\u00eb themi, nuk ishte shum\u00eb e k\u00ebndshme. Baza p\u00ebrb\u00ebhej nga tabela t\u00eb p\u00ebrgatitura p\u00ebr versionin e kaluar t\u00eb faqes (Bitrix), t\u00eb cilat duhej t\u00eb ngarkoheshin n\u00eb ETL, t\u00eb silleshin n\u00eb nj\u00eb pamje t\u00eb re dhe t\u00eb pasuroheshin me lloje t\u00eb ndryshme nga dhjetra sisteme t\u00eb tjera. Q\u00eb nj\u00eb foto e re ose p\u00ebrshkrimi i produktit t\u00eb shfaqej n\u00eb faqe, duhej t\u00eb prishej deri n\u00eb dit\u00ebn tjet\u00ebr \u2014 p\u00ebrdit\u00ebsimi ndodhte vet\u00ebm nat\u00ebn, nj\u00eb her\u00eb n\u00eb dit\u00eb.<\/p>\n

Fillimisht kishte aq shum\u00eb shqet\u00ebsime nga jav\u00ebt e para t\u00eb daljes n\u00eb prodhim, saq\u00eb k\u00ebto inconvenienca p\u00ebr menaxher\u00ebt e p\u00ebrmbajtjes ishin t\u00eb vogla. Por, sapo gjith\u00e7ka u qet\u00ebsua, zhvillimi i projektit vazhdoi \u2014 pas disa muajve, n\u00eb fillim t\u00eb vitit 2015, filluam t\u00eb zhvillojm\u00eb aktivisht administrat\u00ebn. N\u00eb vitet 2015 dhe 2016 gjith\u00e7ka shkonte mir\u00eb, ne l\u00ebshonim rregullisht, administrata p\u00ebrfshinte gjithnj\u00eb e m\u00eb shum\u00eb pjes\u00eb t\u00eb p\u00ebrgatitjes s\u00eb t\u00eb dh\u00ebnave dhe ne po p\u00ebrgatitemi p\u00ebr faktin se s\u00eb shpejti ekipit ton\u00eb do t'i besohej gj\u00ebja m\u00eb e r\u00ebnd\u00ebsishme dhe m\u00eb e v\u00ebshtir\u00eb \u2013 konturi i produktit (p\u00ebrgatitja e plot\u00eb dhe menaxhimi i t\u00eb dh\u00ebnave p\u00ebr t\u00eb gjith\u00eb produktet). Por gjat\u00eb ver\u00ebs s\u00eb vitit 2017, pik\u00ebrisht para lan\u00e7imit t\u00eb konturit t\u00eb produktit, projekti do t\u00eb gjendej n\u00eb nj\u00eb situat\u00eb shum\u00eb t\u00eb v\u00ebshtir\u00eb \u2013 pik\u00ebrisht p\u00ebr shkak t\u00eb problemeve me caching. P\u00ebr k\u00ebt\u00eb episod dua t\u00eb flas n\u00eb pjes\u00ebn e dyt\u00eb t\u00eb k\u00ebtij publikimi me dy pjes\u00eb.<\/p>\n

Por k\u00ebt\u00eb post, do t\u00eb filloj nga larg, duke p\u00ebrmbledhur disa mendime \u2013 p\u00ebrceptime mbi caching, t\u00eb cilat do t\u00eb ishte nj\u00eb hap i mir\u00eb t\u00eb rrotulloheshin p\u00ebrpara nj\u00eb projekti t\u00eb madh.<\/p>\n

Kur lind detyra e caching-ut<\/h2>\n

\nDetyra e caching-ut nuk shfaqet pa arsye. Ne jemi zhvillues, shkruajm\u00eb produkte softuerike dhe duam q\u00eb ato t\u00eb jen\u00eb t\u00eb k\u00ebrkuara. N\u00ebse produkti \u00ebsht\u00eb i k\u00ebrkuar dhe i suksessh\u00ebm \u2013 p\u00ebrdoruesit vijn\u00eb. Dhe vijn\u00eb dhe m\u00eb shum\u00eb. Pastaj numri i p\u00ebrdoruesve rritet ndjesh\u00ebm dhe produkti b\u00ebhet me ngarkes\u00eb t\u00eb lart\u00eb.<\/p>\n

N\u00eb fazat e para nuk mendojm\u00eb p\u00ebr optimizimin dhe performanc\u00ebn e kodit. E r\u00ebnd\u00ebsishme \u00ebsht\u00eb funksionaliteti, t\u00eb nxjerrim nj\u00eb pilot sa m\u00eb shpejt dhe t\u00eb testojm\u00eb hipotezat. Dhe n\u00ebse ngarkesa rritet \u2013 ne p\u00ebrmir\u00ebsojm\u00eb harduerin. E dyfishojm\u00eb dy deri tri her\u00eb, pes\u00eb, le t\u00eb themi dhjet\u00eb her\u00eb. Diku k\u00ebtu \u2013 financat nuk do t\u00eb lejojn\u00eb m\u00eb. Sa her\u00eb do t\u00eb rritet numri i p\u00ebrdoruesve? Nuk do t\u00eb jet\u00eb thjesht 2-5-10, por n\u00eb rast suksesi \u2013 do t\u00eb jet\u00eb nga 100-1000 dhe deri n\u00eb 100 mij\u00eb her\u00eb. Pra, p\u00ebr m\u00ebnyr\u00ebn m\u00eb t\u00eb shkurt\u00ebr, optimizimi do t\u00eb b\u00ebhet i nevojsh\u00ebm n\u00eb nj\u00eb moment.<\/p>\n

Le t\u00eb themi se nj\u00eb pjes\u00eb e caktuar e kodit (ta quajm\u00eb k\u00ebt\u00eb pjes\u00eb funksion) punon rreziksh\u00ebm gjat\u00eb, dhe ne duam t\u00eb shkurtim koh\u00ebn e ekzekutimit. Funksioni \u2013 mund t\u00eb jet\u00eb nj\u00eb akses n\u00eb baz\u00ebn e t\u00eb dh\u00ebnave, mund t\u00eb jet\u00eb ekzekutimi i ndonj\u00eb logjike komplekse \u2013 e r\u00ebnd\u00ebsishme \u00ebsht\u00eb se n\u00eb \u00e7far\u00ebdo forme, ajo zgjat shum\u00eb. Sa mund t\u00eb shkurtosh koh\u00ebn e ekzekutimit? N\u00eb maksimum \u2013 mund ta shkurtosh deri n\u00eb zero, jo m\u00eb tej. Si mund ta shkurtosh koh\u00ebn e ekzekutimit deri n\u00eb zero? P\u00ebrgjigja: ta p\u00ebrjashtosh ekzekutimin. N\u00eb vend t\u00eb k\u00ebsaj \u2013 t\u00eb kthejm\u00eb menj\u00ebher\u00eb rezultatin. Si mund ta dim\u00eb rezultatin? P\u00ebrgjigja: ose ta llogarisim, ose ta shikojm\u00eb diku. T\u00eb llogarish \u2013 \u00ebsht\u00eb me vones\u00eb. Dhe t\u00eb shikosh \u2013 \u00ebsht\u00eb, p\u00ebr shembull, t\u00eb mbash n\u00eb mend rezultatin q\u00eb funksioni e dha her\u00ebn e kaluar kur u thirr me t\u00eb nj\u00ebjtat parametra.<\/p>\n

K\u00ebshtu q\u00eb, implementimi i funksionit p\u00ebr ne nuk ka r\u00ebnd\u00ebsi. Mjafton t\u00eb dim\u00eb se nga cilat parametra varen rezultatet. At\u00ebher\u00eb, n\u00ebse vlerat e parametrave paraqiten si nj\u00eb objekt, i cili mund t\u00eb p\u00ebrdoret si \u00e7el\u00ebs n\u00eb nj\u00eb magazin\u00eb t\u00eb caktuar \u2014 at\u00ebher\u00eb rezultatin e llogaritjes mund ta ruajm\u00eb dhe kur t\u00eb kthehemi ta lexojm\u00eb at\u00eb s\u00ebrish. N\u00ebse ky regjistrim-lexim i rezultatit ndodh m\u00eb shpejt se sa ekzekutimi i funksionit \u2013 kemi p\u00ebrfitime n\u00eb shpejt\u00ebsi. Shuma e p\u00ebrfitimit mund t\u00eb arrij\u00eb edhe 100, edhe 1000, e madje edhe 100 mij\u00eb her\u00eb (10^5 \u00ebsht\u00eb m\u00eb tep\u00ebr nj\u00eb p\u00ebrjashtim, por n\u00eb rastin e nj\u00eb baze q\u00eb ka vonesa t\u00eb konsiderueshme \u2013 \u00ebsht\u00eb krejt\u00ebsisht e mundshme).<\/p>\n

K\u00ebrkesat kryesore p\u00ebr sistemin e keqcache<\/h2>\n

\nE para q\u00eb mund t\u00eb b\u00ebhet k\u00ebrkes\u00eb p\u00ebr sistemin e keqcache \u2014 shpejt\u00ebsi e lart\u00eb e leximit dhe, n\u00eb nj\u00eb mas\u00eb m\u00eb t\u00eb vog\u00ebl, shpejt\u00ebsi e shkrimit. Kjo \u00ebsht\u00eb e v\u00ebrtet\u00eb, por vet\u00ebm derisa t\u00eb mos e \u00e7ojm\u00eb sistemin n\u00eb prodhim.<\/p>\n

Le t\u00eb luajm\u00eb nj\u00eb rast t\u00eb till\u00eb.<\/p>\n

Supozoni se ne kemi siguruar harduerin p\u00ebr ngarkes\u00ebn aktuale dhe tani ngadal\u00eb po implementojm\u00eb keqcache. Disa p\u00ebrdorues shtohen, ngarkesa rritet \u2013 pak e shtojm\u00eb keqcachen, e lidhim k\u00ebtu e atje. K\u00ebshtu vazhdon p\u00ebr nj\u00eb koh\u00eb, dhe tani funksionet e r\u00ebnda pothuajse nuk thirren \u2014 e gjith\u00eb ngarkesa themelore bie mbi keqcache. Numri i p\u00ebrdoruesve gjat\u00eb k\u00ebtij kohe \u00ebsht\u00eb rritur N her\u00eb.<\/p>\n

Dhe n\u00ebse rezervat fillestare p\u00ebr harduerin ishin 2-5 her\u00eb, me ndihm\u00ebn e keqcache ne mund t\u00eb p\u00ebrmir\u00ebsojm\u00eb performanc\u00ebn her\u00eb 10 ose, n\u00eb nj\u00eb rast t\u00eb mir\u00eb, her\u00eb 100, ndonj\u00ebher\u00eb, ndoshta, edhe 1000. K\u00ebshtu, me t\u00eb nj\u00ebjtin harduer \u2013 p\u00ebrpunojm\u00eb 100 her\u00eb m\u00eb shum\u00eb k\u00ebrkesa. Shk\u00eblqyesh\u00ebm, e meriton nj\u00eb shp\u00ebrblim!<\/p>\n

Por tani, n\u00eb nj\u00eb moment t\u00eb bukur, rast\u00ebsisht, sistemi d\u00ebshtoi dhe keqcache r\u00ebnkoi. Asgj\u00eb speciale \u2013 sepse keqcache u zgjodh sipas k\u00ebrkesave \"shpejt\u00ebsi e lart\u00eb leximi dhe shkrimi, e gjith\u00eb pjesa tjet\u00ebr nuk ka r\u00ebnd\u00ebsi\".<\/p>\n

N\u00eb lidhje me ngarkes\u00ebn fillestare, rezervat p\u00ebr harduerin ishin 2-5 her\u00eb, nd\u00ebrsa ngarkesa gjat\u00eb k\u00ebsaj kohe u rrit 10-100 her\u00eb. Me ndihm\u00ebn e keqcache ne ndaluam thirrjet p\u00ebr funksionet e r\u00ebnda dhe k\u00ebshtu gjith\u00e7ka fluturonte. Tani, pa keqcache \u2013 sa her\u00eb do t\u00eb bjer\u00eb sistemi yn\u00eb? \u00c7far\u00eb do t\u00eb ndodh\u00eb me ne? Sistemi do t\u00eb bjer\u00eb.<\/p>\n

Edhe n\u00ebse keqcache nuk u rr\u00ebzua, por vet\u00ebm u pastrua p\u00ebr nj\u00eb koh\u00eb t\u00eb caktuar \u2013 duhet t\u00eb ngrohet, dhe kjo do t\u00eb marr\u00eb pak koh\u00eb. Dhe p\u00ebr k\u00ebt\u00eb koh\u00eb \u2013 ngarkesa themelore do t\u00eb bjer\u00eb mbi funksionalitetin.<\/p>\n

P\u00ebrfundimi: projektet me ngarkes\u00eb t\u00eb lart\u00eb n\u00eb prodhim k\u00ebrkojn\u00eb nga sistemi i caching jo vet\u00ebm shpejt\u00ebsi t\u00eb lart\u00eb leximi dhe shkruaje, por gjithashtu ruajtjen e t\u00eb dh\u00ebnave dhe q\u00ebndrueshm\u00ebri ndaj d\u00ebshtimeve.<\/p>\n

Duf i zgjedhjes<\/h2>\n

\nN\u00eb projektin me admin panel \u2013 zgjedhja nisi k\u00ebshtu: fillimisht vendos\u00ebm Hazelcast, sepse ishim t\u00eb njohur me k\u00ebt\u00eb produkt nga p\u00ebrvoja e faqes kryesore. Por, k\u00ebtu ky zgjedhje doli t\u00eb ishte e pasuksesshme \u2013 n\u00ebn profilin ton\u00eb t\u00eb ngarkes\u00ebs, Hazelcast funksiononte jo thjesht ngadal\u00eb, por shum\u00eb ngadal\u00eb. Dhe p\u00ebr afatet e fillimit t\u00eb prodhimit n\u00eb at\u00eb moment ne tashm\u00eb ishim n\u00ebnshkruar.<\/p>\n

Spoiler: si u zhvilluan rrethanat q\u00eb ne e humb\u00ebm nj\u00eb perk dhe u p\u00ebrball\u00ebm me nj\u00eb situat\u00eb t\u00eb tensionuar \u2013 do ta tregoj n\u00eb pjes\u00ebn e dyt\u00eb \u2014 dhe si arrit\u00ebm atje, dhe si u shp\u00ebtuam. Por tani \u2014 do t\u00eb them vet\u00ebm se ishte nj\u00eb stres i madh, dhe \"t\u00eb mendosh - asnj\u00ebher\u00eb nuk mendohet, tundim shishen\". \"Tundim shishen\" \u2014 ky \u00ebsht\u00eb gjithashtu nj\u00eb spoiler, p\u00ebr k\u00ebt\u00eb pak m\u00eb von\u00eb.<\/p>\n

\u00c7far\u00eb b\u00ebm\u00eb:<\/p>\n

    \n
  1. Krijojm\u00eb nj\u00eb list\u00eb t\u00eb t\u00eb gjitha sistemeve q\u00eb sugjeron google dhe StackOverflow. Pak m\u00eb shum\u00eb se 30.<\/li>\n
  2. Shkruajm\u00eb teste me ngarkes\u00ebn tipike p\u00ebr prodhimin. P\u00ebr k\u00ebt\u00eb q\u00ebllim, regjistruam t\u00eb dh\u00ebnat q\u00eb kalojn\u00eb p\u00ebrmes sistemit n\u00eb mjedisin e prodhimit \u2014 nj\u00eb lloj sniffing p\u00ebr t\u00eb dh\u00ebnat jo n\u00eb rrjet, por brenda sistemit. N\u00eb teste, ekzekutuam pik\u00ebrisht k\u00ebto t\u00eb dh\u00ebna.<\/li>\n
  3. E t\u00ebr\u00eb ekipi, secili zgjedh sistemin tjet\u00ebr nga lista, e konfiguron, ekzekuton testet. N\u00ebse testi nuk kalon, nuk mban ngarkes\u00ebn \u2014 e heqim, kalojm\u00eb n\u00eb at\u00eb tjet\u00ebr n\u00eb radh\u00eb.<\/li>\n
  4. N\u00eb sistemin e 17-t\u00eb b\u00ebhej e qart\u00eb se gjith\u00e7ka ishte pa shpres\u00eb. Mjaft m\u00eb me \"tundjen e shishes\", \u00ebsht\u00eb koha p\u00ebr t\u00eb menduar seriozisht.<\/li>\n<\/ol>\n

    \nPor ky \u00ebsht\u00eb nj\u00eb variant, kur duhet t\u00eb zgjidhni nj\u00eb sistem q\u00eb \"kalon n\u00eb shpejt\u00ebsi\" n\u00eb testet e p\u00ebrgatitura m\u00eb par\u00eb. Dhe n\u00ebse nuk ka teste t\u00eb tilla dhe d\u00ebshirojm\u00eb t\u00eb zgjedhim sa m\u00eb shpejt?<\/p>\n

    Modele sot nj\u00eb variant t\u00eb till\u00eb (e v\u00ebshtir\u00eb t\u00eb paraqitet se nj\u00eb zhvillues mjedisi+ jeton n\u00eb vakuum, dhe n\u00eb momentin e zgjedhjes nuk ka formuluar preferenc\u00eb, se cilin produkt t\u00eb provoj\u00eb n\u00eb radh\u00eb t\u00eb par\u00eb \u2014 prandaj, argumentet e m\u00ebpasshme jan\u00eb m\u00eb shum\u00eb teorike\/filozofi\/rreth juniorit).<\/p>\n

    Pas p\u00ebrcaktimit t\u00eb k\u00ebrkesave, do t\u00eb fillojm\u00eb t\u00eb zgjedhim nj\u00eb zgjidhje prej kutie. Pse t\u00eb shpikim bi\u00e7iklet\u00ebn: ne do t\u00eb shkojm\u00eb dhe do t\u00eb marrim nj\u00eb sistem caching t\u00eb gatsh\u00ebm.<\/p>\n

    N\u00ebse sapo keni filluar dhe po shqyrtoni n\u00eb Google, ka disa renditje, por n\u00eb p\u00ebrgjith\u00ebsi, do t\u00eb jeni t\u00eb orientuar k\u00ebshtu. S\u00eb pari, do t\u00eb ndeshni Redis, i cili \u00ebsht\u00eb n\u00eb t\u00eb gjith\u00eb bisedat. Pastaj do t\u00eb m\u00ebsoni se ekziston EhCache si sistemi m\u00eb i vjet\u00ebr dhe i provuar. M\u00eb pas, do t\u00eb shkruhet p\u00ebr Tarantool \u2014 nj\u00eb zhvillim vendas, i cili ka nj\u00eb aspekt unik zgjidhjeje. Dhe gjithashtu Ignite, sepse tani \u00ebsht\u00eb n\u00eb rritje t\u00eb popullaritetit dhe mb\u00ebshtetet nga SberTech. N\u00eb fund, Hazelcast, sepse n\u00eb bot\u00ebn e enterprise ai shpesh p\u00ebrmendet n\u00eb mesin e kompanive t\u00eb m\u00ebdha.<\/p>\n

    Ky lista nuk \u00ebsht\u00eb t\u00ebr\u00ebsore, ka dhjet\u00ebra sisteme. Dhe ne do t\u00eb lidhim vet\u00ebm nj\u00eb. Do t\u00eb marrim 5 sistemet e zgjedhura n\u00eb \"konkursin e bukuris\u00eb\" dhe do t\u00eb b\u00ebjm\u00eb nj\u00eb p\u00ebrzgjedhje. Kush do t\u00eb jet\u00eb fituesi?<\/p>\n

    Redis<\/h3>\n

    \nLe t\u00eb shohim se \u00e7far\u00eb shkruajn\u00eb n\u00eb faqen zyrtare.
    \n    Redis<\/a><\/noindex> \u2014 projekt opensource. Ofro gjetje t\u00eb dh\u00ebnash n\u00eb memorie, mund\u00ebsi ruajtjeje n\u00eb disk, ndarje automatikisht n\u00eb parti, disponueshm\u00ebri t\u00eb lart\u00eb dhe rikuperim pas nd\u00ebrprerjeve n\u00eb rrjet.<\/p>\n

    Duket gjith\u00e7ka n\u00eb rregull, mund t\u00eb merret dhe t\u00eb lidhet \u2014 gjith\u00e7ka q\u00eb nevojitet, ai e b\u00ebn. Por le t\u00eb shohim thjesht p\u00ebr kureshtje kandidat\u00ebt e tjer\u00eb.<\/p>\n

    EhCache<\/h3>\n

    \nEhCache<\/a><\/noindex> \u2014 \"cache m\u00eb i p\u00ebrdorur p\u00ebr Java\" (p\u00ebrkthim i sloganit nga faqja zyrtare). Po ashtu opensource. Dhe k\u00ebtu e kuptojm\u00eb se Redis nuk \u00ebsht\u00eb p\u00ebr java, por \u00ebsht\u00eb i p\u00ebrgjithsh\u00ebm, dhe p\u00ebr nd\u00ebrveprimin me t\u00eb nevojitet nj\u00eb mb\u00ebshtjell\u00ebs. Dhe EhCache do t\u00eb jet\u00eb m\u00eb e p\u00ebrshtatshme. \u00c7far\u00eb tjet\u00ebr premton sistemi? Besueshm\u00ebri, provueshm\u00ebri, funksionalitet t\u00eb plot\u00eb. Dhe gjithashtu \u00ebsht\u00eb m\u00eb e p\u00ebrhapura. Dhe cache sasi t\u00eb dh\u00ebnash n\u00eb terabajt.<\/p>\n

    Redis \u00ebsht\u00eb harruar, un\u00eb jam i gatsh\u00ebm t\u00eb zgjedh EhCache.<\/p>\n

    Por ndjenja e patriotizmit m\u00eb shtyn t\u00eb shoh se \u00e7far\u00eb ka t\u00eb mira Tarantool.<\/p>\n

    Tarantool<\/h3>\n

    \nTarantool<\/a><\/noindex> \u2014 takon me emrin \"Platforma e integrimit t\u00eb t\u00eb dh\u00ebnave n\u00eb koh\u00eb reale\". Duket shum\u00eb e komplikuar, prandaj lexohet faqja me kujdes dhe gjejm\u00eb nj\u00eb deklarat\u00eb t\u00eb z\u00ebshme: \"Cache 100% t\u00eb dh\u00ebnave n\u00eb memorien operative\". Kjo duhet t\u00eb ngrej\u00eb disa pyetje \u2014 sepse t\u00eb dh\u00ebnat mund t\u00eb jen\u00eb ndjesh\u00ebm m\u00eb shum\u00eb se memoria. Shpjegimi \u00ebsht\u00eb se k\u00ebtu n\u00ebnkuptohet se p\u00ebr t\u00eb shkruar t\u00eb dh\u00ebna n\u00eb disk nga memoria, Tarantool nuk kalon p\u00ebrmes serializimit. N\u00eb vend t\u00eb k\u00ebsaj \u2013 p\u00ebrdor karakteristikat e ulta t\u00eb sistemit, kur memoria thjesht mapohet n\u00eb sistemin e skedar\u00ebve me tregues shum\u00eb t\u00eb mir\u00eb I\/O. N\u00eb t\u00ebr\u00ebsi, e b\u00ebn\u00eb si\u00e7 duhet dhe bukur.<\/p>\n

    Le t\u00eb shohim implementimet: Mail.ru, magjira korporative, Avito, Beeline, MegaFon, Alfa-Banka, Gazprom\u2026<\/p>\n

    N\u00ebse kishin mbetur ndonj\u00eb dyshim n\u00eb lidhje me Tarantool, rastin e implementimit n\u00eb Mastercard m\u00eb bind plot\u00ebsisht. Po e zgjedh Tarantool.<\/p>\n

    Por megjithat\u00eb\u2026<\/p>\n

    Ignite<\/h3>\n

    \n\u2026 ka gjithashtu Ignite<\/a><\/noindex>, i shpallur si \u00abplatform\u00eb p\u00ebrpunimi in-memory\u2026 shpejt\u00ebsit\u00eb in-memory n\u00eb petabajt t\u00eb dh\u00ebnash\u00bb. K\u00ebtu ka shum\u00eb p\u00ebrpar\u00ebsi: cache in-memory t\u00eb shp\u00ebrndar\u00eb, depoja m\u00eb e shpejt\u00eb key-value dhe cache, shkall\u00ebzim horizontal, disponueshm\u00ebri e lart\u00eb, integritet i fort\u00eb. N\u00eb p\u00ebrgjith\u00ebsi, rezulton se m\u00eb i shpejti \u00ebsht\u00eb Ignite.<\/p>\n

    Implementimet: Sberbank, American Airlines, Yahoo! Japan. Dhe pastaj un\u00eb m\u00ebsoj se Ignite \u00ebsht\u00eb jo vet\u00ebm implementuar n\u00eb Sberbank, por ekipi i SberTech d\u00ebrgon njer\u00ebzit e vet n\u00eb ekipin e vet\u00eb Ignite p\u00ebr t\u00eb p\u00ebrmir\u00ebsuar produktin. Kjo m\u00eb bind plot\u00ebsisht dhe un\u00eb jam gati ta zgjedh Ignite.<\/p>\n

    P\u00ebr nj\u00eb arsyetim t\u00eb panjohur, un\u00eb shikoj pik\u00ebn e pest\u00eb.<\/p>\n

    Hazelcast<\/h3>\n

    \nHap faqen e internetit Hazelcast<\/a><\/noindex>, e lexoj. Dhe rezulton se zgjidhja m\u00eb e shpejt\u00eb p\u00ebr cache t\u00eb shp\u00ebrndar\u00eb \u2014 \u00ebsht\u00eb Hazelcast. Ai \u00ebsht\u00eb shum\u00eb m\u00eb i shpejt\u00eb se t\u00eb gjitha zgjidhjet e tjera dhe \u00ebsht\u00eb n\u00eb fakt lider n\u00eb fush\u00ebn e in-memory data grid. N\u00eb k\u00ebt\u00eb kontekst, t\u00eb zgjedh\u00ebsh di\u00e7ka tjet\u00ebr do t\u00eb ishte munges\u00eb respekti ndaj vetes. Dhe gjithashtu p\u00ebrdor ruajtje t\u00eb tepruar t\u00eb t\u00eb dh\u00ebnave p\u00ebr t\u00eb siguruar pun\u00ebn e vazhdueshme t\u00eb klasterit pa humbje t\u00eb dh\u00ebnash.<\/p>\n

    T\u00eb gjitha, un\u00eb jam i gatsh\u00ebm t\u00eb zgjedh Hazelcast.<\/p>\n

    Krahasimi<\/h2>\n

    \nPor n\u00ebse shikojm\u00eb, t\u00eb gjitha pes\u00eb kandidat\u00ebt jan\u00eb p\u00ebrshkruar n\u00eb m\u00ebnyr\u00eb q\u00eb secili prej tyre \u00ebsht\u00eb m\u00eb i miri. Si ta zgjidhim? Mund t\u00eb shohim se cili prej tyre \u00ebsht\u00eb m\u00eb i popullarizuar, t\u00eb k\u00ebrkojm\u00eb krahasime, dhe dhimbja e kok\u00ebs do t\u00eb shkoj\u00eb.<\/p>\n

    Gjejm\u00eb nj\u00eb t\u00eb till\u00eb p\u00ebrmbledhje<\/a><\/noindex>, zgjedhim sistemet tona 5.<\/p>\n

    \"Si
    \n
    \nK\u00ebtu ato jan\u00eb renditur: n\u00eb krye Redis, n\u00eb vendin e dyt\u00eb \u2014 Hazelcast, po fitojn\u00eb popullaritet Tarantool dhe Ignite, nd\u00ebrsa EhCache mbetet ashtu si ka qen\u00eb. <\/p>\n

    Por le t\u00eb shohim n\u00eb metodologjin\u00eb e llogaritjes<\/a><\/noindex>: lidhjet n\u00eb faqet e internetit, interesi i p\u00ebrgjithsh\u00ebm p\u00ebr sistemin, ofertat e pun\u00ebs \u2014 shk\u00eblqyesh\u00ebm! K\u00ebshtu q\u00eb, kur sistemi im do t\u00eb rr\u00ebzohet, do t\u00eb them: \u00abJo, ajo \u00ebsht\u00eb e besueshme! Ja shum\u00eb oferta pune...\u00bb. Nj\u00eb krahasim i till\u00eb i thjesht\u00eb nuk do t\u00eb p\u00ebrshtatet.<\/p>\n

    T\u00eb gjith\u00eb k\u00ebto sisteme nuk jan\u00eb thjesht sisteme p\u00ebr caching. Ato gjithashtu kan\u00eb shum\u00eb funksionalitete, p\u00ebrfshir\u00eb \u2013 kur t\u00eb dh\u00ebnat nuk d\u00ebrgohen te klienti p\u00ebr p\u00ebrpunim, por p\u00ebrkundrazi: kodi q\u00eb duhet t\u00eb ekzekutohet mbi t\u00eb dh\u00ebnat, transferohet n\u00eb server, atje ekzekutohet dhe rezultati kthehet. Dhe si nj\u00eb sistem t\u00eb ve\u00e7ant\u00eb p\u00ebr caching, ato nuk shqyrtohen aq shpesh.<\/p>\n

    Mir\u00eb, nuk dor\u00ebzohemi, do t\u00eb gjejm\u00eb nj\u00eb krahasim t\u00eb drejtp\u00ebrdrejt\u00eb t\u00eb sistemeve. Do t\u00eb marrim dy opsionet kryesore \u2014 Redis dhe Hazelcast. Na intereson shpejt\u00ebsia, dhe me k\u00ebt\u00eb parametrat do t'i krahasojm\u00eb.<\/p>\n

    Hz vs Redis<\/h3>\n

    \nGjejm\u00eb nj\u00eb t\u00eb till\u00eb krahasimi<\/a><\/noindex>:
    \n\"Si
    \n
    \nE kuqe \u00ebsht\u00eb Redis, e kalt\u00ebr \u00ebsht\u00eb Hazelcast. Hazelcast fiton gjithmon\u00eb, dhe kjo \u00ebsht\u00eb e justifikuar: \u00ebsht\u00eb shum\u00ebthjesht, e optimizuar n\u00eb m\u00ebnyr\u00eb t\u00eb lart\u00eb, \u00e7do gjeth punon me nj\u00eb pjes\u00eb t\u00eb saj, k\u00ebshtu q\u00eb nuk ka bllokime. Nd\u00ebrsa Redis \u00ebsht\u00eb nj\u00ebthjesht, dhe nuk p\u00ebrfiton nga CPU-t\u00eb moderne me shum\u00eb b\u00ebrthama. Hazelcast ka I\/O asinkron, nd\u00ebrsa Redis-Jedis ka socket\u00eb bllokues. N\u00eb fund t\u00eb fundit, Hazelcast p\u00ebrdor nj\u00eb protokoll binar, nd\u00ebrsa Redis \u00ebsht\u00eb e orientuar n\u00eb tekst, pra \u00ebsht\u00eb e pasakt\u00eb.<\/p>\n

    P\u00ebr \u00e7do rast, le t\u00eb kthehemi tek nj\u00eb burim tjet\u00ebr krahasimi. \u00c7far\u00eb do t\u00eb na tregoj\u00eb ai?<\/p>\n

    Redis vs Hz<\/h3>\n

    \nNj\u00eb tjet\u00ebr krahasimi<\/a><\/noindex>:
    \n\"Si
    \n
    \nK\u00ebtu e kund\u00ebrta, e kuqe \u00ebsht\u00eb Redis. Kjo do t\u00eb thot\u00eb se Redis sipas performanc\u00ebs e kalon Hazelcast. N\u00eb krahasimin e par\u00eb fitonte Hazelcast, n\u00eb t\u00eb dytin - Redis.     K\u00ebtu<\/a><\/noindex> shpjeguan shum\u00eb sakt\u00eb pse n\u00eb krahasimin e m\u00ebparsh\u00ebm fitoi Hazelcast.<\/p>\n

    Doli se rezultati i par\u00eb ishte praktikisht i manipuluar: Redis u mor nga kutia themelore, nd\u00ebrsa Hazelcast u p\u00ebrshtat p\u00ebr rastin testues. K\u00ebshtu q\u00eb del se: s\u00eb pari, askush nuk duhet besuar, s\u00eb dyti, kur t\u00eb zgjidhim nj\u00eb sistem, na duhet ta konfigurojm\u00eb at\u00eb si\u00e7 duhet. K\u00ebto konfigurime p\u00ebrfshijn\u00eb dhjet\u00ebra, pothuajse qindra parametra.<\/p>\n

    T\u00eb tundim shishen<\/h2>\n

    \nDhe procesi q\u00eb kemi kryer tani, mund ta shpjegoj me k\u00ebt\u00eb metafor\u00eb \"T\u00eb tundim shishen\". Pra, aktualisht nuk \u00ebsht\u00eb e nevojshme t\u00eb programojm\u00eb, tani \u00ebsht\u00eb e r\u00ebnd\u00ebsishme t\u00eb dim\u00eb si t\u00eb lexojm\u00eb stackoverflow. N\u00eb ekipin tim kam nj\u00eb profesionist q\u00eb punon n\u00eb k\u00ebt\u00eb m\u00ebnyr\u00eb n\u00eb momentet kritike.<\/p>\n

    \u00c7far\u00eb b\u00ebn ai? Ai sheh nj\u00eb gj\u00eb q\u00eb nuk funksionon, sheh stack trace, merr disa fjal\u00eb nga ajo (cilat sakt\u00ebsisht - \u00ebsht\u00eb ekspertiz\u00eb e tij n\u00eb program), k\u00ebrkon n\u00eb Google, gjen stackoverflow midis p\u00ebrgjigjeve. Ai nuk lexon, nuk mendon, midis p\u00ebrgjigjeve n\u00eb pyetje - ai zgjedh di\u00e7ka q\u00eb \u00ebsht\u00eb m\u00eb e ngjashme me propozimin \"t\u00eb b\u00ebsh k\u00ebt\u00eb e at\u00eb\" (zgjedhja e nj\u00eb p\u00ebrgjigjeje t\u00eb till\u00eb \u00ebsht\u00eb talenti i tij, sepse nuk \u00ebsht\u00eb gjithmon\u00eb ajo p\u00ebrgjigje q\u00eb ka marr\u00eb m\u00eb shum\u00eb like), e aplikon, shikon: n\u00ebse ka ndonj\u00eb ndryshim, at\u00ebher\u00eb \u00ebsht\u00eb shk\u00eblqyer. N\u00ebse nuk ka ndryshim - rikthejm\u00eb. Dhe p\u00ebrs\u00ebrisim fillimin-verifikimin-k\u00ebrkimin. N\u00eb k\u00ebt\u00eb m\u00ebnyr\u00eb intuituese ai arrin q\u00eb pas nj\u00eb kohe kodi t\u00eb funksionoj\u00eb. Ai nuk e di pse, ai nuk e di se \u00e7far\u00eb b\u00ebri, ai nuk mund ta shpjegoj\u00eb. Por! Kjo gj\u00eb funksionon. Dhe \"zjarri \u00ebsht\u00eb shuar\". Tani shohim \u00e7far\u00eb b\u00ebm\u00eb. Kur programi funksionon - kjo \u00ebsht\u00eb shum\u00eb m\u00eb e leht\u00eb. Dhe kursen ndjesh\u00ebm koh\u00ebn.<\/p>\n

    Ky \u044d\u0442\u043e\u0442 m\u00ebnyr\u00eb shpjegohet shum\u00eb mir\u00eb me nj\u00eb shembull si ky.<\/p>\n

    Nj\u00ebher\u00eb, ishte shum\u00eb popullor t\u00eb nd\u00ebrtohej nj\u00eb anije vela n\u00eb nj\u00eb shishe. Anija \u00ebsht\u00eb e madhe dhe e brisht\u00eb, nd\u00ebrsa goja e shishes \u00ebsht\u00eb shum\u00eb e ngusht\u00eb, nuk mund ta fut\u00ebsh brenda. Si ta b\u00ebjm\u00eb at\u00eb?<\/p>\n

    \"Si
    \n
    \nKa nj\u00eb metod\u00eb t\u00eb till\u00eb, shum\u00eb t\u00eb shpejt\u00eb dhe shum\u00eb efektive.<\/p>\n

    Anija p\u00ebrb\u00ebhet nga shum\u00eb gj\u00ebra: shkopinj, litar\u00eb, vela, ngjit\u00ebs. T\u00eb gjitha k\u00ebto i vendosim n\u00eb shishe.
    \nMarrim shishen me dy duar dhe fillojm\u00eb ta tundim. E tundim-tundim. Dhe zakonisht \u2013 del nj\u00eb gj\u00eb e \u00e7uditshme, sigurisht. Por her\u00eb pas here. Her\u00eb pas here del nj\u00eb anije! Sakt\u00ebsisht, di\u00e7ka q\u00eb ngjan me anijen.<\/p>\n

    I tregojm\u00eb dikujt k\u00ebt\u00eb di\u00e7ka: \u00abSerjozha, e sheh!?\u00bb. Dhe me t\u00eb v\u00ebrtet\u00eb, nga larg \u2013 duket si nj\u00eb anije. Por m\u00eb tutje nuk mund ta l\u00ebsh k\u00ebt\u00eb.<\/p>\n

    Ka edhe nj\u00eb m\u00ebnyr\u00eb tjet\u00ebr. P\u00ebrdoret nga djemt\u00eb m\u00eb t\u00eb avancuar, t\u00eb ashtuquajturit haker\u00eb.<\/p>\n

    I dhash\u00eb nj\u00eb detyr\u00eb nj\u00eb djali t\u00eb till\u00eb, ai e b\u00ebri gjith\u00e7ka dhe u largua. Dhe e shikon \u2013 duket se \u00ebsht\u00eb b\u00ebr\u00eb. Por pas nj\u00eb kohe, kur duhet t\u00eb p\u00ebrmir\u00ebsohet kodi \u2013 aty fillon nj\u00eb ngat\u00ebrrim p\u00ebr shkak t\u00eb tij\u2026 Mir\u00eb, q\u00eb ai kishte ikur ndar\u00eb. K\u00ebta jan\u00eb djem q\u00eb p\u00ebr shembull, b\u00ebjn\u00eb k\u00ebshtu me shishen: e shihni, aty ku \u00ebsht\u00eb fundi \u2013 \u0441\u0442\u0435\u043a\u043b\u043e \u0443\u0442\u043e\u043d\u0447\u0430\u0435\u0442\u0441\u044f. Dhe nuk \u00ebsht\u00eb krejt\u00ebsisht e qart\u00eb, n\u00ebse \u00ebsht\u00eb transparente apo jo. At\u00ebher\u00eb \u00abhaker\u00ebt\u00bb e presin k\u00ebt\u00eb fund, e vendosin anijen brenda, e ngjitin s\u00ebrish fundin, dhe duket se \u00ebsht\u00eb ashtu si\u00e7 duhet.<\/p>\n

    Nga pik\u00ebpamja e formulimit t\u00eb detyr\u00ebs duket se gjith\u00e7ka \u00ebsht\u00eb n\u00eb rregull. Por k\u00ebtu tek shembujt e anijeve: p\u00ebrse n\u00eb t\u00eb v\u00ebrtet\u00eb ta b\u00ebsh k\u00ebt\u00eb anije, kujt i nevojitet ajo? Ajo nuk ka funksionalitet. Zakonisht, k\u00ebto anije jan\u00eb dhurata p\u00ebr njer\u00ebz shum\u00eb t\u00eb r\u00ebnd\u00ebsish\u00ebm, t\u00eb cil\u00ebt e vendosin at\u00eb n\u00eb raftin e tyre, si nj\u00eb simbol, nj\u00eb shenj\u00eb. Dhe n\u00ebse nj\u00eb njeri i till\u00eb, lider i nj\u00eb biznesi t\u00eb madh ose nj\u00eb funksionar t\u00eb lart\u00eb, e sheh k\u00ebt\u00eb si nj\u00eb flamur t\u00eb till\u00eb q\u00eb \u00ebsht\u00eb b\u00ebr\u00eb me nj\u00eb pun\u00eb t\u00eb dob\u00ebt? Do t\u00eb ishte m\u00eb mir\u00eb, n\u00ebse ai kurr\u00eb nuk do ta dinte p\u00ebr k\u00ebt\u00eb. At\u00ebher\u00eb, si i b\u00ebjn\u00eb n\u00eb p\u00ebrfundim k\u00ebto anije, q\u00eb mund t'u dhurohen njer\u00ebzve t\u00eb r\u00ebnd\u00ebsish\u00ebm?<\/p>\n

    Vendi i vet\u00ebm ku me t\u00eb v\u00ebrtet\u00eb nuk mund t\u00eb b\u00ebsh asgj\u00eb \u00ebsht\u00eb trupi. Dhe trupi i anijes kalon pik\u00ebrisht n\u00eb qaf\u00eb. Nd\u00ebrsa anija ndahet jasht\u00eb shishk\u00ebs. Por nuk \u00ebsht\u00eb e thjesht\u00eb ta mbledh\u00ebsh anijen, \u00ebsht\u00eb nj\u00eb art i v\u00ebrtet\u00eb i arritur. N\u00eb pjes\u00ebt p\u00ebrb\u00ebr\u00ebse shtohen lev\u00eb t\u00eb ve\u00e7anta q\u00eb lejojn\u00eb q\u00eb ato t\u00eb ngrihen m\u00eb von\u00eb. P\u00ebr shembull, dimrat palosen, futen me kujdes brenda, dhe pastaj me pinc\u00eb, shum\u00eb me precizitet, t\u00ebrhiqen dhe ngrihen. Si rezultat, krijohet nj\u00eb vep\u00ebr arti q\u00eb mund t'i dhurohet me krenari.<\/p>\n

    Dhe n\u00ebse duam q\u00eb projekti t\u00eb jet\u00eb i suksessh\u00ebm, n\u00eb ekip duhet t\u00eb ket\u00eb t\u00eb pakt\u00ebn nj\u00eb person-artizan. Ai q\u00eb kujdeset p\u00ebr cil\u00ebsin\u00eb e produktit dhe merr parasysh t\u00eb gjitha aspektet, pa sakrifikuar asnj\u00eb edhe n\u00eb momentet e stresit, kur rrethanat k\u00ebrkojn\u00eb t\u00eb b\u00ebsh di\u00e7ka t\u00eb menj\u00ebhershme n\u00eb d\u00ebm t\u00eb asaj q\u00eb \u00ebsht\u00eb e r\u00ebnd\u00ebsishme. T\u00eb gjitha projektet e suksesshme q\u00eb jan\u00eb t\u00eb q\u00ebndrueshme dhe kan\u00eb q\u00ebndruar p\u00ebrball\u00eb prov\u00ebs s\u00eb koh\u00ebs, jan\u00eb nd\u00ebrtuar mbi k\u00ebt\u00eb parim. Aty \u00ebsht\u00eb di\u00e7ka shum\u00eb e sakt\u00eb dhe unike, di\u00e7ka q\u00eb shfryt\u00ebzon t\u00eb gjitha mund\u00ebsit\u00eb e disponueshme. N\u00eb shembullin me anijen n\u00eb shishe, p\u00ebrmendet se trupi i anijes kalon n\u00ebp\u00ebr qaf\u00eb.<\/p>\n

    Duke u kthyer n\u00eb detyr\u00ebn e zgjedhjes s\u00eb serverit ton\u00eb t\u00eb caches, si mund t\u00eb aplikohej ky m\u00ebnyr\u00eb? Sugjeroj nj\u00eb variant t\u00eb till\u00eb zgjedhjeje nga t\u00eb gjitha sistemet q\u00eb jan\u00eb - t\u00eb mos e tronditim shishk\u00ebn, jo t\u00eb zgjedhim, por t\u00eb shohim se \u00e7far\u00eb ka parasysh n\u00eb to q\u00eb \u00ebsht\u00eb e r\u00ebnd\u00ebsishme p\u00ebr zgjedhjen e sistemit.<\/p>\n

    Ku t\u00eb k\u00ebrkosh bottleneck<\/h2>\n

    \nT\u00eb p\u00ebrpiqemi t\u00eb mos e tronditim shishk\u00ebn, t\u00eb mos i kalojm\u00eb t\u00eb gjitha nj\u00eb nga nj\u00eb, por t\u00eb shikojm\u00eb cilat detyra do t\u00eb dalin, n\u00ebse ndonj\u00ebher\u00eb, n\u00ebn detyr\u00ebn ton\u00eb - t\u00eb projektosh nj\u00eb sistem t\u00eb till\u00eb vet\u00eb. Sigurisht q\u00eb nuk do t\u00eb rregullojm\u00eb bi\u00e7iklet\u00ebn, por do t\u00eb shfryt\u00ebzojm\u00eb k\u00ebt\u00eb skem\u00eb p\u00ebr t\u00eb u orientuar p\u00ebr momentet q\u00eb duhet pasur parasysh n\u00eb p\u00ebrshkrimet e produkteve. T\u00eb rr\u00ebshqasim nj\u00eb skem\u00eb t\u00eb till\u00eb.<\/p>\n

    \"Si
    \n
    \nN\u00ebse sistemi \u00ebsht\u00eb i shp\u00ebrndar\u00eb, at\u00ebher\u00eb do t\u00eb kemi disa servera (6). Le t\u00eb themi se kat\u00ebr jan\u00eb (t\u00eb lehta p\u00ebr t'u vendosur n\u00eb imazh, por sigurisht, mund t\u00eb jen\u00eb sa t\u00eb duash). N\u00ebse serverat jan\u00eb n\u00eb node t\u00eb ndryshme, at\u00ebher\u00eb mbi ta do t\u00eb funksionoj\u00eb nj\u00eb kod q\u00eb \u00ebsht\u00eb p\u00ebrgjegj\u00ebs q\u00eb k\u00ebto node t\u00eb formojn\u00eb nj\u00eb grup dhe n\u00eb rast ndarjeje - t\u00eb lidhin dhe t\u00eb njohin nj\u00ebri-tjetrin.<\/p>\n

    Kemi p\u00ebrs\u00ebri nj\u00eb kod-logjik\u00eb (2), e cila \u00ebsht\u00eb n\u00eb thelb rreth caches. Me k\u00ebt\u00eb kod, klient\u00ebt nd\u00ebrveprojn\u00eb me nj\u00eb API t\u00eb caktuar. Kodi i klientit (1) mund t\u00eb jet\u00eb brenda k\u00ebsaj JVM-je, ose t\u00eb interesohet p\u00ebr t\u00eb n\u00ebp\u00ebrmjet rrjetit. Logjika e zbatuar brenda lidhet me vendimet se cilat objeto n\u00eb cache duhen ruajtur dhe cilat duhen hequr. P\u00ebr ruajtjen e cache-it, p\u00ebrdorim memorien (3), por n\u00ebse \u00ebsht\u00eb e nevojshme, mund t\u00eb ruajm\u00eb nj\u00eb pjes\u00eb t\u00eb t\u00eb dh\u00ebnave edhe n\u00eb disk (4).<\/p>\n

    T\u00eb shohim se n\u00eb cilat pjes\u00eb do t\u00eb ndodh\u00eb ngarkesa. N\u00eb thelb, do t\u00eb ngarkohet \u00e7do shigjet\u00eb dhe \u00e7do nyje. S\u00eb pari, mes kodit t\u00eb klientit dhe API-t, n\u00ebse \u00ebsht\u00eb nd\u00ebrveprim rrjetor, r\u00ebnia mund t\u00eb jet\u00eb mjaft e dukshme. S\u00eb dyti, brenda vet\u00eb API-t \u2014 n\u00ebse e teprojm\u00eb me logjik\u00ebn e komplikuar, mund t\u00eb p\u00ebrballim CPU-n\u00eb. Dhe do t\u00eb ishte mir\u00eb q\u00eb logjika t\u00eb mos p\u00ebrdor\u00eb memorien m\u00eb shum\u00eb se duhet. Kjo mbetet nd\u00ebrveprimi me sistemin e skedar\u00ebve \u2013 n\u00eb variantin e zakonsh\u00ebm, kjo \u00ebsht\u00eb t\u00eb serializosh \/ rikuperosh dhe t\u00eb shkruash \/ lexosh.<\/p>\n

    Pastaj, nd\u00ebrveprimi me klasterin. Me shum\u00eb mund\u00ebsi, ai do t\u00eb jet\u00eb n\u00eb k\u00ebt\u00eb sistem, por mund t\u00eb jet\u00eb edhe ve\u00e7mas. K\u00ebtu gjithashtu duhet marr\u00eb parasysh transferimi i t\u00eb dh\u00ebnave te ai, shpejt\u00ebsia e serializimit t\u00eb t\u00eb dh\u00ebnave dhe nd\u00ebrveprimi mes klasterit.<\/p>\n

    Tani, nga nj\u00ebra an\u00eb \u2013 ne mund t\u00eb paraqesim, \"cila do t\u00eb jet\u00eb mekanizmi q\u00eb do t\u00eb funksionoj\u00eb\" n\u00eb sistemin e caches gjat\u00eb p\u00ebrpunimit t\u00eb k\u00ebrkesave nga kodi yn\u00eb, dhe nga ana tjet\u00ebr \u2013 ne mund t\u00eb vler\u00ebsojm\u00eb se cilat dhe sa k\u00ebrkesa do t\u00eb gjeneroj\u00eb kodi yn\u00eb ndaj k\u00ebtij sistemi. Kjo \u00ebsht\u00eb mjaft e mjaftueshme p\u00ebr t\u00eb b\u00ebr\u00eb nj\u00eb zgjedhje m\u00eb se t\u00eb arsyeshme \u2013 p\u00ebr t\u00eb zgjedhur sistemin sipas variantit ton\u00eb t\u00eb p\u00ebrdorimit.<\/p>\n

    Hazelcast<\/b><\/p>\n

    T\u00eb shohim se si t\u00eb aplikojm\u00eb nj\u00eb shp\u00ebrndarje t\u00eb till\u00eb n\u00eb list\u00ebn ton\u00eb. P\u00ebr shembull, Hazelcast.<\/p>\n

    P\u00ebr t\u00eb vendosur \/ marr\u00eb t\u00eb dh\u00ebna nga Hazelcast, kodi i klientit i afrohet (1) API-t. Hz lejon t\u00eb nis\u00ebsh serverin si embedded, dhe n\u00eb k\u00ebt\u00eb rast, qasja n\u00eb API \u00ebsht\u00eb nj\u00eb thirrje metode brenda JVM, mund t\u00eb merret si falas.<\/p>\n

    P\u00ebr t\u00eb funksionuar logjika n\u00eb (2), Hz mb\u00ebshtetet n\u00eb hash nga byte-array i serializuar t\u00eb \u00e7el\u00ebsit \u2013 dometh\u00ebn\u00eb, serializimi i \u00e7el\u00ebsit do t\u00eb ndodh\u00eb n\u00eb \u00e7do rast. Kjo \u00ebsht\u00eb nj\u00eb overhead e pashmangshme p\u00ebr Hz.
    \nStrategjit\u00eb e Eviction jan\u00eb zbatuar mir\u00eb, por p\u00ebr raste t\u00eb ve\u00e7anta \u2013 mund t\u00eb lidhen t\u00eb tuat. P\u00ebr k\u00ebt\u00eb pjes\u00eb nuk ka nevoj\u00eb t\u00eb shqet\u00ebsoheni.<\/p>\n

    Memorizimi (4) mund t\u00eb lidhet. Shk\u00eblqyer. Interaksioni (5) p\u00ebr embedded mund t\u00eb merret si momental. Shk\u00ebmbimi i t\u00eb dh\u00ebnave midis nyjave n\u00eb klaster (6) \u2013 po, ai ekziston. Kjo \u00ebsht\u00eb nj\u00eb kontribut n\u00eb favor t\u00eb q\u00ebndrueshm\u00ebris\u00eb me koston e shpejt\u00ebsis\u00eb. \u00c7mimi mund t\u00eb ulet fal\u00eb karakteristik\u00ebs Hz Near-cache \u2013 t\u00eb dh\u00ebnat e marra nga nyjat e tjera t\u00eb klasterit do t\u00eb ken\u00eb nj\u00eb cache.<\/p>\n

    \u00c7far\u00eb mund t\u00eb b\u00ebhet n\u00eb k\u00ebto kushte p\u00ebr t\u00eb rritur shpejt\u00ebsin\u00eb?<\/p>\n

    P\u00ebr shembull, p\u00ebr t\u00eb shmangur serializimin e \u00e7el\u00ebsit n\u00eb (2) \u2013 p\u00ebrdorimi i nj\u00eb cache tjet\u00ebr mbi Hazelcast, p\u00ebr t\u00eb dh\u00ebnat m\u00eb t\u00eb ngrohta. N\u00eb Sportmaster, p\u00ebr k\u00ebt\u00eb q\u00ebllim u zgjodh Caffeine.<\/p>\n

    P\u00ebr rregullimin n\u00eb nivelin (6), n\u00eb Hz u ofruan dy lloje ruajtjeje: IMap dhe ReplicatedMap.
    \n\"Si
    \n
    \nDuhet t\u00eb themi si Hazelcast arriti n\u00eb ngarkes\u00ebn teknologjike t\u00eb Sportmaster.<\/p>\n

    N\u00eb vitin 2012, kur po punonim mbi prototipin e par\u00eb t\u00eb faqes s\u00eb internetit t\u00eb ardhshme, Hazelcast ishte lidhja e par\u00eb q\u00eb k\u00ebrkuesi na dha. Takimi filloi \"n\u00eb her\u00ebn e par\u00eb\" \u2013 ishim t\u00eb impresionuar se pas vet\u00ebm dy or\u00ebsh, kur e integruam Hz n\u00eb sistem \u2013 ai punonte. Dhe punonte mir\u00eb. Deri n\u00eb fund t\u00eb dit\u00ebs kishim p\u00ebrfunduar disa teste, u g\u00ebzuam. Dhe ky rezerv\u00eb energjie na mjaftoi p\u00ebr t\u00eb p\u00ebrballuar surprizat q\u00eb Hz na ofronte me kalimin e koh\u00ebs. Tani ekipi i Sportmaster nuk ka arsye p\u00ebr t\u00eb braktisur Hazelcast.<\/p>\n

    Por argumente t\u00eb tilla si \"lidhja e par\u00eb n\u00eb k\u00ebrkues\" dhe \"e nd\u00ebrtuam shpejt HelloWorld\" \u2013 jan\u00eb, natyrisht, p\u00ebrjashtime dhe ve\u00e7ori t\u00eb momentit n\u00eb t\u00eb cilin u b\u00eb p\u00ebrzgjedhja. Provimi i v\u00ebrtet\u00eb p\u00ebr sistemin e zgjedhur fillon me daljen n\u00eb prodhim, dhe pik\u00ebrisht n\u00eb k\u00ebt\u00eb faz\u00eb duhet t\u00eb kushtohet v\u00ebmendje kur zgjedhim \u00e7do sistem, p\u00ebrfshir\u00eb dhe cache. N\u00eb fakt, n\u00eb rastin ton\u00eb, mund t\u00eb themi se zgjodh\u00ebm Hazelcast p\u00ebr rast\u00ebsi, por m\u00eb pas doli se kishim zgjedhur sakt\u00eb.<\/p>\n

    P\u00ebr prodhimin, shum\u00eb m\u00eb e r\u00ebnd\u00ebsishme \u00ebsht\u00eb: monitorimi, trajtimi i d\u00ebshtimeve n\u00eb nyjat e ve\u00e7anta, replikimi i t\u00eb dh\u00ebnave, kostoja e shkall\u00ebzimit. Pra, duhet t\u00eb kushtohet v\u00ebmendje detyrave q\u00eb do t\u00eb shfaqen pik\u00ebrisht n\u00eb mb\u00ebshtetje t\u00eb sistemit \u2013 kur ngarkesa t\u00eb kaloj\u00eb disa her\u00eb at\u00eb q\u00eb ishte planifikuar, kur rast\u00ebsisht t\u00eb b\u00ebjm\u00eb ngarkimin e di\u00e7kaje q\u00eb nuk \u00ebsht\u00eb e drejt\u00eb dhe jo aty, kur do t\u00eb nevojitet p\u00ebr t\u00eb l\u00ebshuar nj\u00eb version t\u00eb ri t\u00eb kodit, p\u00ebr t\u00eb z\u00ebvend\u00ebsuar t\u00eb dh\u00ebnat dhe p\u00ebr ta b\u00ebr\u00eb k\u00ebt\u00eb pa u v\u00ebn\u00eb re nga klient\u00ebt.<\/p>\n

    P\u00ebr t\u00eb gjitha k\u00ebto k\u00ebrkesa, Hazelcast \u00ebsht\u00eb pa dyshim i p\u00ebrshtatsh\u00ebm.<\/p>\n

    Do t\u00eb vazhdoj\u00eb<\/h2>\n

    \nPor\u00eb, Hazelcast nuk \u00ebsht\u00eb nj\u00eb zgjidhje magjike. N\u00eb vitin 2017, ne zgjodh\u00ebm Hazelcast p\u00ebr caching n\u00eb panelin administrativ, duke u bazuar thjesht n\u00eb p\u00ebrshtypjet pozitiv\u00eb nga eksperiencat e kaluara. Kjo luajti nj\u00eb rol ky\u00e7 n\u00eb nj\u00eb shaka t\u00eb tmerrshme, duke na sjell\u00eb n\u00eb nj\u00eb situat\u00eb t\u00eb v\u00ebshtir\u00eb nga t\u00eb cilat dol\u00ebm \"heroikisht\" pas 60 dit\u00ebsh. Por p\u00ebr k\u00ebt\u00eb, n\u00eb pjes\u00ebn tjet\u00ebr.<\/p>\n

    Deri at\u00ebher\u00eb\u2026 G\u00ebzuar Kode t\u00eb Reja!
    \n
    Burimi:     habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

    \u041f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041f\u044c\u044f\u043d\u043a\u043e\u0432, \u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440. \u0412 \u044d\u0442\u043e\u043c \u043f\u043e\u0441\u0442\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b, \u043a\u0430\u043a \u043d\u0430\u0447\u0438\u043d\u0430\u043b\u0430\u0441\u044c \u0440\u0430\u0431\u043e\u0442\u0430 \u043d\u0430\u0434 \u0441\u0430\u0439\u0442\u043e\u043c \u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440 \u0432 2012 \u0433\u043e\u0434\u0443, \u043a\u0430\u043a\u0438\u0435 \u0438\u043d\u0438\u0446\u0438\u0430\u0442\u0438\u0432\u044b \u0443\u0434\u0430\u043b\u043e\u0441\u044c \u00ab\u043f\u0440\u043e\u0442\u043e\u043b\u043a\u043d\u0443\u0442\u044c\u00bb \u0438 \u043d\u0430\u043e\u0431\u043e\u0440\u043e\u0442, \u043a\u0430\u043a\u0438\u0435 \u0433\u0440\u0430\u0431\u043b\u0438 \u043c\u044b \u0441\u043e\u0431\u0440\u0430\u043b\u0438. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u044f \u0445\u043e\u0447\u0443 \u043f\u043e\u0434\u0435\u043b\u0438\u0442\u044c\u0441\u044f \u043c\u044b\u0441\u043b\u044f\u043c\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0441\u043b\u0435\u0434\u0443\u044e\u0442 \u0437\u0430 \u0434\u0440\u0443\u0433\u0438\u043c \u0441\u044e\u0436\u0435\u0442\u043e\u043c \u2013 \u0432\u044b\u0431\u043e\u0440 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u043a\u0435\u0448\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0434\u043b\u044f java-\u0431\u044d\u043a\u0435\u043d\u0434\u0430 \u0432 \u0430\u0434\u043c\u0438\u043d\u043a\u0435 \u0441\u0430\u0439\u0442\u0430. \u042d\u0442\u043e\u0442 \u0441\u044e\u0436\u0435\u0442 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":73950,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-73949","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Si zgjodh\u00ebm sistemin e caching n\u00eb Sportmaster. Pjesa 1 | ProHoster","description":"P\u00ebrsh\u00ebndetje! Un\u00eb quhem Aleksei Pyankov, jam zhvillues n\u00eb kompanin\u00eb Sportmaster.","canonical_url":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sq_AL","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u0430\u043a \u043c\u044b \u0432 \u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440\u0435 \u0432\u044b\u0431\u0438\u0440\u0430\u043b\u0438 \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u043a\u0435\u0448\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f. \u0427\u0430\u0441\u0442\u044c 1 | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041f\u044c\u044f\u043d\u043a\u043e\u0432, \u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440.","og:url":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-03-12T23:42:07+00:00","article:modified_time":"2020-03-12T23:42:07+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"73949","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 18:23:51","updated":"2022-09-28 05:05:57","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts\/73949","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/comments?post=73949"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts\/73949\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/media\/73950"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/media?parent=73949"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/categories?post=73949"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/tags?post=73949"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}