{"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\/da\/blog\/administrirovanie\/kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1","title":{"rendered":"Hvordan vi i Sportmaster valgte et cache-system. Del 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hej! Jeg hedder Alexey P'yankov, jeg er udvikler hos Sportmaster. I dette indl\u00e6g<\/a><\/noindex> har jeg fortalt, hvordan arbejdet med Sportmaster-websitet startede i 2012, hvilke initiativer vi kunne \"skubbe igennem\" og omvendt, hvilke fejl vi samlede op.<\/p>\n

I dag vil jeg dele mine tanker, der f\u00f8lger et andet plot \u2013 valget af cache-system til java-backend i adminpanelet p\u00e5 websitet. Dette plot har en s\u00e6rlig betydning for mig \u2013 selvom historien kun strakte sig over 2 m\u00e5neder, arbejdede vi 12-16 timer om dagen uden en eneste fridag. Jeg havde aldrig f\u00f8r t\u00e6nkt eller forestillet mig, at man kunne arbejde s\u00e5 meget.<\/p>\n

Derfor opdeler jeg teksten i 2 dele, for ikke at overbelaste for meget. Omvendt vil den f\u00f8rste del v\u00e6re meget let \u2013 en forberedelse, en introduktion, nogle overvejelser over, hvad caching er. Hvis du allerede er en erfaren udvikler eller har arbejdet med caches \u2013 vil der sandsynligvis ikke v\u00e6re noget nyt p\u00e5 det tekniske plan i denne artikel. Men for en junior kan en lille oversigt m\u00e5ske indikere, hvilken vej man skal se, hvis man befinder sig i en s\u00e5dan situation.<\/p>\n

\"Hvordan<\/a><\/noindex>
\n<\/a><\/noindex>
\nDa den nye version af Sportmaster-websitet blev lanceret i produktion, blev dataene indhentet p\u00e5 en m\u00e5de, vi m\u00e5 sige, var temmelig uh\u00e5ndterlig. Grundlaget var tabeller, der var forberedt til den tidligere version af websitet (Bitrix), som skulle tr\u00e6kkes ind i ETL, tilpasses til den nye form og beriges med forskellige ekstra elementer fra et dusin systemer. For at et nyt billede eller en produktbeskrivelse kunne komme p\u00e5 websitet, m\u00e5tte man vente til n\u00e6ste dag \u2013 opdateringer kun om natten, 1 gang om dagen.<\/p>\n

I begyndelsen var der s\u00e5 mange bekymringer i de f\u00f8rste uger efter lanceringen, at content manageres ulemper virkede ubetydelige. Men s\u00e5 snart det hele var faldet til ro, fortsatte projektets udvikling \u2013 i begyndelsen af 2015 begyndte vi aktivt at udvikle administrationspanelet. I 2015 og 2016 gik det godt, vi udgav regelm\u00e6ssigt, administrationspanelet d\u00e6kkede en stadig st\u00f8rre del af dataforberedelsen, og vi forberedte os p\u00e5, at vores team snart ville f\u00e5 ansvaret for det vigtigste og mest komplekse \u2013 produktkonturen (den fulde forberedelse og vedligeholdelse af data for alle produkter). Men om sommeren 2017, lige f\u00f8r lanceringen af produktkonturen, kom projektet i en meget vanskelig situation \u2013 netop p\u00e5 grund af problemer med caching. Om dette episode vil jeg gerne fort\u00e6lle i den anden del af denne to-delte publikation.<\/p>\n

Men i dette indl\u00e6g vil jeg starte fra begyndelsen og opsummere nogle tanker \u2013 ideer om caching, som det ville v\u00e6re en god id\u00e9 at overveje p\u00e5 forh\u00e5nd inden et stort projekt.<\/p>\n

N\u00e5r opgaven med caching opst\u00e5r<\/h2>\n

\nCache-opgaven opst\u00e5r ikke bare s\u00e5dan. Vi er udviklere, skriver softwareprodukter, og vi \u00f8nsker, at de skal v\u00e6re eftertragtede. Hvis produktet er eftertragtet og succesfuldt \u2013 kommer brugerne. Og endnu flere kommer, og s\u00e5 videre. Og pludselig er der rigtig mange brugere, og s\u00e5 bliver produktet h\u00f8jt belastet.<\/p>\n

I de tidlige faser t\u00e6nker vi ikke p\u00e5 optimering og kodeydelse. Det vigtigste er funktionalitet, hurtigt at f\u00e5 pilotversionen ud og teste hypoteser. Og hvis belastningen stiger \u2013 opgraderer vi hardwaren. Vi \u00f8ger den med to til tre, fem, lad os sige ti gange. Her begynder \u00f8konomien dog at s\u00e6tte gr\u00e6nser. Og hvor mange brugere kan vi forvente i fremtiden? Det vil ikke kun v\u00e6re 2-5-10, men i tilf\u00e6lde af succes \u2013 fra 100 til 1000 og op til 100.000 gange. S\u00e5dan at p\u00e5 et tidspunkt m\u00e5 vi tage os af optimering.<\/p>\n

Lad os antage, at en del af koden (lad os kalde den funktion) k\u00f8rer bem\u00e6rkelsesv\u00e6rdigt langsomt, og vi \u00f8nsker at reducere eksekveringstiden. En funktion kan v\u00e6re adgang til en database eller udf\u00f8relse af en kompleks logik \u2013 det vigtigste er, at den tager lang tid. Hvor meget kan eksekveringstiden reduceres? I teorien kan den reduceres til nul, ikke mindre. Men hvordan kan vi reducere eksekveringstiden til nul? Svaret er: ved slet ikke at udf\u00f8re den. I stedet kan vi straks returnere resultatet. Hvordan kan vi finde resultatet? Svaret er: enten beregne det, eller kigge det op et sted. At beregne det tager tid. At kigge det op er, for eksempel, at huske det resultat, som funktionen gav sidste gang, da den blev kaldt med de samme parametre.<\/p>\n

Det vil sige, implementeringen af funktionen er ikke s\u00e5 vigtig for os. Det er kun n\u00f8dvendigt at vide, hvilke parametre resultatet afh\u00e6nger af. Hvis vi s\u00e5 pr\u00e6senterer v\u00e6rdierne for parametrene som et objekt, der kan bruges som en n\u00f8gle i et eller andet lager \u2013 kan vi gemme resultatet og ved n\u00e6ste anmodning hente det. Hvis disse opslag og hentninger g\u00e5r hurtigere end at udf\u00f8re funktionen, s\u00e5 f\u00e5r vi en hastighedsfordel. Fordelen kan v\u00e6re op til 100, 1000 eller endda 100.000 gange (10^5 er n\u00e6ppe normen, men i tilf\u00e6lde af en betydeligt langsom database er det helt muligt).<\/p>\n

De grundl\u00e6ggende krav til et cache-system<\/h2>\n

\nDet f\u00f8rste, der kan blive et krav til et cache-system, er hurtig l\u00e6sehastighed og i lidt mindre grad \u2013 skrivehastighed. Dette er korrekt, men kun indtil vi ruller systemet ud i produktion.<\/p>\n

Lad os overveje et scenario.<\/p>\n

Antag, at vi har sikret hardware til den nuv\u00e6rende belastning, og nu gradvist implementerer caching. Antallet af brugere stiger lidt, belastningen vokser \u2013 vi tilf\u00f8jer lidt caching, tilslutter det her og der. Dette forts\u00e6tter i noget tid, og nu bliver de tunge funktioner n\u00e6sten ikke kaldt \u2013 al den prim\u00e6re belastning ligger p\u00e5 cachen. Antallet af brugere er steget med N gange i denne periode.<\/p>\n

Og hvis det oprindelige hardware-boost var 2-5 gange, s\u00e5 har vi med caching kunnet tr\u00e6kke ydeevnen op til 10 gange eller, i bedste fald, 100 gange, og nogle steder endda 1000 gange. Det vil sige, p\u00e5 den samme hardware \u2013 behandler vi 100 gange flere foresp\u00f8rgsler. Fantastisk, vi har fortjent en bel\u00f8nning!<\/p>\n

Men nu, i et pludseligt \u00f8jeblik, gik systemet i st\u00e5, og cachen kollapsede. Ikke noget s\u00e6rligt \u2013 for cache blev valgt efter kriteriet \"h\u00f8j l\u00e6se- og skrivehastighed, resten er ikke vigtigt\".<\/p>\n

I forhold til den startbelastning havde vi en hardwaremargin p\u00e5 2-5 gange, mens belastningen i mellemtiden var steget 10-100 gange. Ved hj\u00e6lp af cachen undgik vi kald til tunge funktioner, og derfor fungerede alt gnidningsfrit. Men nu, uden cache \u2013 hvor meget vil vores system falde? Hvad vil der ske? Systemet vil g\u00e5 ned.<\/p>\n

Selv hvis vores cache ikke er kollapset, men kun er blevet t\u00f8mt i et stykke tid \u2013 skal den varmes op, og det vil tage noget tid. Og i denne tid vil den prim\u00e6re belastning ligge p\u00e5 funktionaliteten.<\/p>\n

Konklusion: h\u00f8jbelastede projekter i produktion kr\u00e6ver af systemet, at caching ikke kun har h\u00f8j l\u00e6se- og skrivehastighed, men ogs\u00e5 databevaring og modstandsdygtighed over for fejl.<\/p>\n

Valgets kvaler<\/h2>\n

\nI projektet med administrationspanelet blev valgprocessen s\u00e5ledes: f\u00f8rst installerede vi Hazelcast, da vi allerede var bekendt med dette produkt gennem erfaringen fra hovedwebsitet. Men her viste denne beslutning sig at v\u00e6re uheldig \u2013 under vores belastningsprofil arbejder Hazelcast ikke bare langsomt, men ekstremt langsomt. Og med de frister for at g\u00e5 i produktion, havde vi allerede skrevet under p\u00e5 det.<\/p>\n

Spoiler: hvordan omst\u00e6ndighederne udfoldede sig, s\u00e5 vi overs\u00e5 en s\u00e5dan faldgrube og havnede i en akut og ansp\u00e6ndt situation \u2013 vil jeg fort\u00e6lle i del to \u2014 og hvordan vi endte, og hvordan vi kom ud af det. Men lige nu \u2013 vil jeg kun sige, at det var en st\u00e6rk stress, og \"at t\u00e6nke \u2013 det er sv\u00e6rt, vi ryster flasken\". \"Vi ryster flasken\" \u2013 det er ogs\u00e5 en spoiler, om dette senere.<\/p>\n

Hvad vi gjorde:<\/p>\n

    \n
  1. Vi laver en liste over alle systemer, som Google og StackOverflow foresl\u00e5r. Lidt over 30<\/li>\n
  2. Vi skriver testcases med en belastning, der er karakteristisk for produktionen. Til dette har vi optaget data, der passerer gennem systemet i produktionsmilj\u00f8et \u2013 en slags sniffer for data ikke i netv\u00e6rket, men inde i systemet. I testene k\u00f8rte vi netop disse data.<\/li>\n
  3. Hele teamet, hver v\u00e6lger det n\u00e6ste system fra listen, konfigurerer og k\u00f8rer testene. Bestandstest, der ikke klarer belastningen \u2013 kasserer vi og g\u00e5r videre til den n\u00e6ste i k\u00f8en.<\/li>\n
  4. Ved det 17. system blev det klart, at alt var h\u00e5bl\u00f8st. Nok med at \"ryst flasken\", tid til seri\u00f8s refleksion.<\/li>\n<\/ol>\n

    \nMen dette er et valg, n\u00e5r man skal v\u00e6lge et system, der \"kan klare sig hastighedsm\u00e6ssigt\" i de forberedte tests. Men hvad hvis der ikke findes s\u00e5danne tests, og man \u00f8nsker at v\u00e6lge hurtigere?<\/p>\n

    Lad os modellere et s\u00e5dant scenarie (det er sv\u00e6rt at forestille sig, at en mid-level udvikler lever i et vakuum, og p\u00e5 tidspunktet for valget ikke har angivet pr\u00e6ferencer for, hvilket produkt man \u00f8nsker at pr\u00f8ve f\u00f8rst - derfor er de videre overvejelser mere teoretiske\/filosofiske\/om juniordevs).<\/p>\n

    N\u00e5r kravene er fastlagt, begynder vi at v\u00e6lge en out-of-the-box l\u00f8sning. Der er ingen grund til at opfinde hjulet: vi vil tage et f\u00e6rdiglavet cache-system.<\/p>\n

    Hvis du lige er startet og vil google, s\u00e5 kan r\u00e6kkef\u00f8lgen v\u00e6re plus-minus, men generelt vil pejlem\u00e6rkerne v\u00e6re s\u00e5danne. F\u00f8rst vil du st\u00f8de p\u00e5 Redis, det er overalt. S\u00e5 vil du finde ud af, at der er EhCache som det \u00e6ldste og mest p\u00e5lidelige system. Derefter vil Tarantool komme p\u00e5 tale - en indenlandsk udvikling med et unikt aspekt. Og selvf\u00f8lgelig Ignite, fordi det lige nu er i h\u00f8j popularitet og underst\u00f8ttes af SberTech. Til sidst vil Hazelcast ogs\u00e5 blive n\u00e6vnt, for det dukker ofte op i enterprise-verdenen blandt store virksomheder.<\/p>\n

    Dette er ikke en udt\u00f8mmende liste, der findes dusinvis af systemer. Men vi vil kun tage \u00e9t. Vi vil tage de valgte 5 systemer til en \"sk\u00f8nhedskonkurrence\" og lave en udv\u00e6lgelse. Hvem vil v\u00e6re vinderen?<\/p>\n

    Redis<\/h3>\n

    \nLad os l\u00e6se, hvad der st\u00e5r p\u00e5 den officielle hjemmeside.
    \n    Redis<\/a><\/noindex> \u2013 et open-source projekt. Tilbyder et in-memory datalager, mulighed for on-disk lagring, automatisk partitionering, h\u00f8j tilg\u00e6ngelighed og genopretning efter netv\u00e6rksbrud.<\/p>\n

    Det ser ud til, at alt er i orden, man kan tage det og integrere det - alt hvad der er n\u00f8dvendigt, g\u00f8r det. Men lad os lige af ren nysgerrighed se p\u00e5 de andre kandidater.<\/p>\n

    EhCache<\/h3>\n

    \nEhCache<\/a><\/noindex> \u2013 \"den mest udbredte cache til Java\" (overs\u00e6ttelse af sloganet fra den officielle hjemmeside). Ogs\u00e5 open-source. Her forst\u00e5r vi, at Redis ikke er til Java, men er generelt, og for at interagere med det kr\u00e6ves der et wrapper. EhCache vil v\u00e6re mere praktisk. Hvad mere lover systemet? P\u00e5lidelighed, afpr\u00f8vethed, fuld funktionalitet. Og s\u00e5 er det det mest udbredte. Og det cacher terabytes af data.<\/p>\n

    Redis er glemt, jeg er klar til at v\u00e6lge EhCache.<\/p>\n

    Men patriotismen f\u00e5r mig til at se p\u00e5, hvad der er godt ved Tarantool.<\/p>\n

    Tarantool<\/h3>\n

    \nTarantool<\/a><\/noindex> \u2014 m\u00f8der betegnelsen \u00abData Integrationsplatform i realtid\u00bb. Det lyder meget kompliceret, s\u00e5 lad os l\u00e6se siden grundigt og finde den st\u00e6rke p\u00e5stand: \u00abCache lagrer 100% af dataene i den prim\u00e6re hukommelse\u00bb. Dette skal v\u00e6kke sp\u00f8rgsm\u00e5l \u2013 for dataene kan v\u00e6re betydeligt mere end hukommelsen. Forklaringen er, at n\u00e5r data skal skrives til disken fra hukommelsen, bruger Tarantool ikke serialisering. I stedet bruger det lavniveau egenskaber i systemet, hvor hukommelsen blot kortl\u00e6gges til filsystemet med meget gode I\/O pr\u00e6stationer. Alt i alt, de har gjort det p\u00e5 en bem\u00e6rkelsesv\u00e6rdig og smart m\u00e5de.<\/p>\n

    Lad os se p\u00e5 implementeringerne: Mail.ru korporativet, Avito, Beeline, Megafon, Alfa-Bank, Gazprom\u2026<\/p>\n

    Hvis der stadig er nogen tvivl om Tarantool, s\u00e5 nedk\u00e6mper implementeringscasen i Mastercard mig. Jeg v\u00e6lger Tarantool.<\/p>\n

    Men alligevel\u2026<\/p>\n

    Ignite<\/h3>\n

    \n\u2026 er der ogs\u00e5 Ignite<\/a><\/noindex>, pr\u00e6senteret som \u00abin-memory beregningsplatform\u2026 in-memory hastigheder p\u00e5 petabyte data\u00bb. Her er der ogs\u00e5 mange fordele: distribueret in-memory cache, det hurtigste key-value lager og cache, horisontal skalerbarhed, h\u00f8j tilg\u00e6ngelighed, strengt dataintegritet. S\u00e5 viser det sig, at den hurtigste er Ignite.<\/p>\n

    Implementeringer: Sberbank, American Airlines, Yahoo! Japan. Og s\u00e5 finder jeg ud af, at Ignite ikke kun er implementeret i Sberbank, men at SberTech-teamet sender deres folk til Ignite-teamet for at udvikle produktet. Det overbeviser mig helt, og jeg er klar til at v\u00e6lge Ignite.<\/p>\n

    Hele femte punkt er helt uforst\u00e5eligt for mig.<\/p>\n

    Hazelcast<\/h3>\n

    \nJeg g\u00e5r ind p\u00e5 hjemmesiden Hazelcast<\/a><\/noindex>, l\u00e6ser. Og det viser sig, at den hurtigste l\u00f8sning til distribueret caching er Hazelcast. Det er mange gange hurtigere end alle andre l\u00f8sninger og faktisk lederen inden for in-memory data grids. I lyset af dette ville det v\u00e6re en skam at v\u00e6lge noget andet. Og det bruger ogs\u00e5 redundant datalagring for at sikre, at klyngen fungerer kontinuerligt uden datatab.<\/p>\n

    Det er det, jeg er klar til at v\u00e6lge Hazelcast.<\/p>\n

    Sammenligning<\/h2>\n

    \nMen hvis man ser efter, s\u00e5 er alle fem kandidater s\u00e5 beskrevet, at hver af dem er den bedste. Hvordan v\u00e6lger man? Vi kan se, hvilken af dem der er mest popul\u00e6r, s\u00f8ge efter sammenligninger, s\u00e5 forsvinder hovedpinen.<\/p>\n

    Vi finder en s\u00e5dan gennemgang<\/a><\/noindex>, v\u00e6lger vores 5 systemer.<\/p>\n

    \"Hvordan
    \n
    \nHer er de sorteret: \u00f8verst Redis, p\u00e5 andenpladsen \u2014 Hazelcast, Tarantool og Ignite vinder popularitet, mens EhCache forbliver den samme. <\/p>\n

    Men lad os se p\u00e5 beregningsmetode<\/a><\/noindex>: links til hjemmesider, generel interesse for systemet, jobtilbud \u2014 fantastisk! S\u00e5 n\u00e5r mit system g\u00e5r ned, kan jeg sige: \u00abNej, det er jo p\u00e5lideligt! Der er mange jobtilbud...\u00bb. En s\u00e5 simpel sammenligning vil ikke holde.<\/p>\n

    Alle disse systemer er ikke bare caching-systemer. De har ogs\u00e5 mange funktioner, herunder - hvor ikke data sendes til klienten til behandling, men i stedet: koden, der skal k\u00f8res p\u00e5 dataene, flyttes til serveren, hvor den udf\u00f8res, og resultatet returneres. Som en separat caching-l\u00f8sning bliver de ikke s\u00e5 ofte betragtet.<\/p>\n

    Okay, vi giver ikke op, lad os finde en direkte sammenligning af systemerne. Lad os tage de to bedste muligheder - Redis og Hazelcast. Vi interesserer os for hastigheden, s\u00e5 vi sammenligner dem ud fra dette parameter.<\/p>\n

    Hz vs Redis<\/h3>\n

    \nLad os finde s\u00e5dan en sammenligning<\/a><\/noindex>:
    \n\"Hvordan
    \n
    \nBl\u00e5 er Redis, r\u00f8d er Hazelcast. Hazelcast vinder overalt, og der er en grund til det: det er multitr\u00e5dede, h\u00f8jt optimerede, hver tr\u00e5d arbejder med sin partition, s\u00e5 der er ingen blokeringer. Redis er derimod entr\u00e5det og drager ikke fordel af moderne flerkernede CPU'er. Hazelcast bruger asynkront I\/O, mens Redis-Jedis bruger blokerende sockets. I sidste ende bruger Hazelcast et bin\u00e6rt protokol, mens Redis er tekstbaseret, hvilket g\u00f8r det ineffektivt.<\/p>\n

    Til information vil vi se p\u00e5 endnu en kilde til sammenligning. Hvad vil den vise os?<\/p>\n

    Redis vs Hz<\/h3>\n

    \nEn anden sammenligning<\/a><\/noindex>:
    \n\"Hvordan
    \n
    \nHer er det omvendt, r\u00f8d er Redis. Det vil sige, Redis vinder i ydeevne over Hazelcast. I den f\u00f8rste sammenligning vandt Hazelcast, i den anden vandt Redis.     Her<\/a><\/noindex> forklarede de meget pr\u00e6cist, hvorfor Hazelcast vandt i den tidligere sammenligning.<\/p>\n

    Det viser sig, at resultatet af den f\u00f8rste faktisk var manipuleret: Redis blev taget i sin grundl\u00e6ggende form, mens Hazelcast blev tilpasset til testtilf\u00e6ldet. Det betyder: for det f\u00f8rste, man kan ikke stole p\u00e5 nogen, for det andet, n\u00e5r vi endelig v\u00e6lger et system, skal vi ogs\u00e5 konfigurere det korrekt. Disse indstillinger omfatter dusinvis, n\u00e6sten hundrede parametre.<\/p>\n

    Ryst flasken<\/h2>\n

    \nOg hele den proces, vi netop har gennemg\u00e5et, kan jeg forklare med den metafor \u00abRyst flasken\u00bb. Det vil sige, lige nu kan man ikke programmere, det vigtigste er at kunne l\u00e6se stackoverflow. Og jeg har en person p\u00e5 mit team, en professionel, der netop arbejder s\u00e5dan i kritiske \u00f8jeblikke.<\/p>\n

    Hvad g\u00f8r han? Han ser en defekt ting, ser stack trace, tager nogle af ordene derfra (hvilke pr\u00e6cist \u2014 det er hans ekspertise i programmet), s\u00f8ger p\u00e5 Google, finder Stack Overflow blandt svarene. Uden at l\u00e6se grundigt, uden at overveje, blandt svarene v\u00e6lger han noget, der ligner en s\u00e6tning som \"g\u00f8r dette og andet\" (det er hans talent at v\u00e6lge s\u00e5dan et svar, for det er ikke altid det svar, der har f\u00e5et flest likes), anvender det, kigger: hvis noget har \u00e6ndret sig, s\u00e5 er det fantastisk. Hvis der ikke er \u00e6ndret noget \u2014 ruller vi tilbage. Og vi gentager k\u00f8rsel-kontrol-s\u00f8gning. Og p\u00e5 denne intuitive m\u00e5de n\u00e5r han til, at koden efter noget tid virker. Han ved ikke hvorfor, han ved ikke hvad han har gjort, han kan ikke forklare det. Men! Det virker. Og \"branden er slukket\". Nu lad os finde ud af, hvad vi gjorde. N\u00e5r programmet virker \u2014 er det meget lettere. Og sparer betydeligt tid.<\/p>\n

    Denne metode forklares meget godt med et s\u00e5dant eksempel.<\/p>\n

    Engang var det meget popul\u00e6rt at samle et skib i en flaske. Skibet er stort og skr\u00f8beligt, og flaskehalsen er meget smal, det kan ikke presses indenfor. Hvordan samler man det?<\/p>\n

    \"Hvordan
    \n
    \nDer er en metode, meget hurtig og meget effektiv.<\/p>\n

    Skibet best\u00e5r af en masse sm\u00e5ting: tr\u00e6stykker, reb, sejl, lim. Alt dette l\u00e6gger vi i flasken.
    \nVi tager flasken med to h\u00e6nder og begynder at ryste. Vi ryster den og ryster den. Og normalt \u2014 bliver det naturligvis noget skrammel. Men nogle gange. Nogle gange bliver det et skib! Mere pr\u00e6cist, noget der ligner et skib.<\/p>\n

    Vi viser dette noget til nogen: \"Sergio, ser du!?\". Og faktisk, fra afstand \u2013 ligner det et skib. Men l\u00e6ngere skal det ikke sendes.<\/p>\n

    Der er en anden metode. De mere avancerede fyre bruger, s\u00e5danne hackere.<\/p>\n

    Jeg gav s\u00e5dan en fyr en opgave, han gjorde alt og gik. Og man kigger \u2013 det ser ud til at v\u00e6re gjort. Men efter noget tid, n\u00e5r der skal arbejdes videre med koden \u2014 s\u00e5 begynder der s\u00e5dan noget fra ham\u2026 Godt for ham, at han allerede har l\u00f8bet langt v\u00e6k. Det er s\u00e5danne fyre, der p\u00e5 eksemplet med flasken g\u00f8r s\u00e5dan: ser du, hvor bunden er \u2013 b\u00f8jer glasset. Og det er ikke helt klart, om det er klart eller ej. S\u00e5 \"hackere\" saver bunden af, inds\u00e6tter skibet indeni, bunden limes s\u00e5 tilbage, og det ser ud til, at det altid har v\u00e6ret s\u00e5dan.<\/p>\n

    N\u00e5r det kommer til opgaveformuleringen, ser alt ud til at v\u00e6re korrekt. Men n\u00e5r vi ser p\u00e5 eksemplet med skibene: hvorfor overhovedet lave denne skib, og hvem har brug for det? Det har ingen funktionalitet. Normalt er s\u00e5danne skibe gaver til meget h\u00f8jtst\u00e5ende personer, der placerer det p\u00e5 en hylde over sig selv som en visuel symbolik. Og hvis en s\u00e5dan person, en leder af en stor virksomhed eller en h\u00f8jtst\u00e5ende embedsmand, har en s\u00e5dan amat\u00f8rarbejde som flag, hvor halsen er sk\u00e5ret af? Det ville v\u00e6re bedre, hvis han aldrig fik nys om det. S\u00e5 hvordan bliver disse skibe, der kan gives til en vigtig person, faktisk lavet?<\/p>\n

    Det eneste sted, der virkelig ikke kan \u00e6ndres, er skroget. Og skroget passer netop gennem halsen. Skibet samles dog uden for flasken. Men det er ikke bare at samle skibet; det er et \u00e6gte h\u00e5ndv\u00e6rk. Der tilf\u00f8jes specielle h\u00e5ndtag til de sammensatte dele, s\u00e5 de senere kan l\u00f8ftes. For eksempel foldes sejlene forsigtigt ind, og derefter bruges en pincet til meget pr\u00e6cist at tr\u00e6kke og h\u00e6ve dem. Resultatet bliver et kunstv\u00e6rk, som kan gives med god samvittighed og stolthed.<\/p>\n

    Og hvis vi vil, at projektet skal v\u00e6re succesfuldt, skal der v\u00e6re mindst \u00e9n juveler p\u00e5 holdet. En, der bekymrer sig om produktkvaliteten og tager h\u00f8jde for alle aspekter uden at g\u00e5 p\u00e5 kompromis, selv i stressede \u00f8jeblikke, hvor omst\u00e6ndighederne kr\u00e6ver hurtige beslutninger p\u00e5 bekostning af det vigtige. Alle succesfulde projekter, der er b\u00e6redygtige og har best\u00e5et tidens pr\u00f8ve, er bygget p\u00e5 dette princip. De har noget meget pr\u00e6cist og unikt, noget der udnytter alle tilg\u00e6ngelige muligheder. I eksemplet med skibet i flasken spilles der med det faktum, at skroget passer gennem halsen.<\/p>\n

    N\u00e5r vi vender tilbage til opgaven med at v\u00e6lge vores caching-server, hvordan kunne denne tilgang s\u00e5 anvendes? Jeg foresl\u00e5r en metode, der ikke inkluderer at ryste flasken eller v\u00e6lge, men snarere at se, hvad der i bund og grund er v\u00e6rd at bem\u00e6rke ved valget af system.<\/p>\n

    Hvor skal man lede efter flaskehalse?<\/h2>\n

    \nLad os pr\u00f8ve ikke at ryste flasken, ikke gennemg\u00e5 alt i r\u00e6kkef\u00f8lge, men se p\u00e5, hvilke opgaver der opst\u00e5r, hvis vi pludselig skal designe et s\u00e5dant system selv. Vi vil selvf\u00f8lgelig ikke samle cyklen, men vi vil bruge dette skema til at orientere os om, hvilke aspekter vi skal v\u00e6re opm\u00e6rksomme p\u00e5 i produktbeskrivelserne. Lad os skitsere et s\u00e5dant skema.<\/p>\n

    \"Hvordan
    \n
    \nHvis systemet er distribueret, s\u00e5 vil vi have flere servere (6). Lad os antage, at der er fire (praktisk at visualisere, men der kan selvf\u00f8lgelig v\u00e6re s\u00e5 mange, man vil). Hvis serverne er p\u00e5 forskellige noder, s\u00e5 k\u00f8rer der noget kode p\u00e5 dem alle, der s\u00f8rger for, at disse noder danner et cluster og i tilf\u00e6lde af brud \u2013 kan forbinde og genkende hinanden.<\/p>\n

    Der kr\u00e6ves ogs\u00e5 kode-logik (2) specifikt til cache-h\u00e5ndtering. Denne kode interagerer med klienterne gennem et bestemt API. Klientkoden (1) kan v\u00e6re inden for den samme JVM eller kontakte den over netv\u00e6rket. Logikken, der implementeres internt, handler om, hvilke objekter der skal forblive i cachen, og hvilke der skal smides v\u00e6k. Vi bruger hukommelse (3) til at opbevare cachen, men hvis det er n\u00f8dvendigt, kan vi ogs\u00e5 gemme nogle data p\u00e5 disk (4).<\/p>\n

    Lad os se, hvilke dele der vil opleve belastning. Faktisk vil hver pil og hver node v\u00e6re belastet. For det f\u00f8rste, mellem klientkoden og API'en, hvis det er en netv\u00e6rksinteraktion, kan der v\u00e6re en betydelig forsinkelse. For det andet, inden for selve API'en \u2014 hvis logikken bliver for kompleks, kan vi st\u00f8de p\u00e5 CPU-begr\u00e6nsninger. Og det ville v\u00e6re godt, hvis logikken ikke un\u00f8digt bruger hukommelse. Og der er ogs\u00e5 interaktionen med filsystemet \u2013 i en almindelig situation er det at serialisere \/ gendanne og skrive \/ l\u00e6se.<\/p>\n

    Dern\u00e6st interaktionen med clustret. Det vil sandsynligvis v\u00e6re inden for dette samme system, men det kan ogs\u00e5 v\u00e6re separat. Her skal vi ogs\u00e5 tage h\u00f8jde for dataoverf\u00f8rslen til det, hastigheden for data-serialisering og interaktionen mellem clustret.<\/p>\n

    Nu kan vi dels forestille os, \u201ehvilke tandhjul der vil dreje\u201c i cache-systemet ved behandlingen af foresp\u00f8rgsler fra vores kode, og p\u00e5 den anden side kan vi estimere, hvilke og hvor mange foresp\u00f8rgsler vores kode vil generere til dette system. Dette er tilstr\u00e6kkeligt til at tr\u00e6ffe et mere eller mindre rationelt valg \u2013 at v\u00e6lge et system, der passer til vores brugssituation.<\/p>\n

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

    Lad os se p\u00e5, hvordan s\u00e5dan en opdeling kan anvendes p\u00e5 vores liste. For eksempel, Hazelcast.<\/p>\n

    For at gemme\/hente data fra Hazelcast henvender klientkode sig (1) til API'en. Hz g\u00f8r det muligt at k\u00f8re serveren som embedded, og i s\u00e5 fald er henvendelsen til API'en et metodekald inden for JVM, noget man kan betragte som gratis.<\/p>\n

    For at logikken fungerer i (2), baserer Hz sig p\u00e5 en hash af en byte-array af den serialiserede n\u00f8gle \u2013 det vil sige, at serialiseringen af n\u00f8glen vil ske uanset hvad. Dette er en uundg\u00e5elig overhead for Hz.
    \nEviction-strategierne er godt implementeret, men til s\u00e6rlige tilf\u00e6lde kan man tilslutte sine egne. Man skal ikke bekymre sig om denne del.<\/p>\n

    Lagringen (4) kan tilsluttes. Fremragende. Interaktionen (5) for embedded kan betragtes som \u00f8jeblikkelig. Dataudvekslingen mellem noderne i klyngen (6) \u2013 ja, den findes. Det er et bidrag til fejltolerance p\u00e5 bekostning af hastigheden. Hertz-funktionaliteten Near-cache g\u00f8r det muligt at reducere prisen \u2013 data, der er hentet fra andre noder i klyngen, vil blive cachet.<\/p>\n

    Hvad kan man g\u00f8re under s\u00e5danne betingelser for at \u00f8ge hastigheden?<\/p>\n

    For eksempel, for at undg\u00e5 at serialisere n\u00f8glen i (2) \u2013 tilf\u00f8je endnu en cache oven p\u00e5 Hazelcast for de mest varme data. Hos Sportmaster valgte de Caffeine til dette form\u00e5l.<\/p>\n

    For at justere p\u00e5 niveau (6), tilbydes to typer lagring i Hz: IMap og ReplicatedMap.
    \n\"Hvordan
    \n
    \nDet er v\u00e6rd at n\u00e6vne, hvordan Hazelcast kom ind i teknologi-stakken hos Sportmaster.<\/p>\n

    I 2012, da vi arbejdede p\u00e5 det allerf\u00f8rste pilotprojekt til den kommende hjemmeside, var det faktisk Hazelcast, der var det f\u00f8rste link, som s\u00f8gemaskinen viste. Bekendtskabet begyndte 'fra f\u00f8rste gang' \u2013 vi blev charmeret over, at allerede to timer efter, at vi integrerede Hz i systemet, \u2013 s\u00e5 fungerede det. Og det virkede godt. Inden dagen var omme, havde vi skrevet nogle tests og blev glade. Og denne energi var nok til at overvinde de overraskelser, som Hz gav med tiden. Lige nu har Sportmaster-teamet ingen grunde til at opgive Hazelcast.<\/p>\n

    Men s\u00e5danne argumenter som 'f\u00f8rste link i s\u00f8gemaskinen' og 'hurtigt oprettet HelloWorld' \u2013 er selvf\u00f8lgelig undtagelsen og et s\u00e6rligt \u00f8jeblik i valget. De virkelige udfordringer for det valgte system starter, n\u00e5r man g\u00e5r i produktion, og det er netop i denne fase, man skal l\u00e6gge m\u00e6rke til ved valget af ethvert system, inklusive cache. Egentlig kan man sige, at vi valgte Hazelcast ved en tilf\u00e6ldighed, men senere viste det sig, at vi valgte rigtigt.<\/p>\n

    For production, monitoring, handling failures on individual nodes, data replication, and the cost of scaling are much more important. That is, it's essential to pay attention to the challenges that will arise during system maintenance \u2013 when the load exceeds what was planned by dozens of times, when we unintentionally upload something inappropriate, when we need to roll out a new version of code, replace data, and do it without customers noticing.<\/p>\n

    For all these requirements, Hazelcast is certainly suitable.<\/p>\n

    To be continued<\/h2>\n

    \nBut Hazelcast is not a panacea. In 2017, we chose Hazelcast for caching in the admin, purely based on a positive impression from past experience. This played a key role in a very nasty joke that put us in a tough situation, from which we 'heroically' extricated ourselves for 60 days. But more about that in the next part.<\/p>\n

    For now\u2026 Happy New Code!
    \n
    Kilde:     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\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\udd47How we at Sportmaster chose a caching system. Part 1 | ProHoster","description":"Hello! My name is Alexey Pyankov, I am a developer at Sportmaster.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/73949","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=73949"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/73949\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/73950"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=73949"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=73949"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=73949"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}