Hej! Jeg hedder Alexey P'yankov, jeg er udvikler hos Sportmaster. I dette har jeg fortalt, hvordan arbejdet med Sportmaster-websitet startede i 2012, hvilke initiativer vi kunne "skubbe igennem" og omvendt, hvilke fejl vi samlede op.
I dag vil jeg dele mine tanker, der fĂžlger et andet plot â valget af cache-system til java-backend i adminpanelet pĂ„ websitet. Dette plot har en sĂŠrlig betydning for mig â selvom historien kun strakte sig over 2 mĂ„neder, arbejdede vi 12-16 timer om dagen uden en eneste fridag. Jeg havde aldrig fĂžr tĂŠnkt eller forestillet mig, at man kunne arbejde sĂ„ meget.
Derfor opdeler jeg teksten i 2 dele, for ikke at overbelaste for meget. Omvendt vil den fĂžrste del vĂŠre meget let â en forberedelse, en introduktion, nogle overvejelser over, hvad caching er. Hvis du allerede er en erfaren udvikler eller har arbejdet med caches â vil der sandsynligvis ikke vĂŠre noget nyt pĂ„ det tekniske plan i denne artikel. Men for en junior kan en lille oversigt mĂ„ske indikere, hvilken vej man skal se, hvis man befinder sig i en sĂ„dan situation.
Da den nye version af Sportmaster-websitet blev lanceret i produktion, blev dataene indhentet pĂ„ en mĂ„de, vi mĂ„ sige, var temmelig uhĂ„ndterlig. Grundlaget var tabeller, der var forberedt til den tidligere version af websitet (Bitrix), som skulle trĂŠkkes 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Ă„ websitet, mĂ„tte man vente til nĂŠste dag â opdateringer kun om natten, 1 gang om dagen.
I begyndelsen var der sĂ„ mange bekymringer i de fĂžrste uger efter lanceringen, at content manageres ulemper virkede ubetydelige. Men sĂ„ snart det hele var faldet til ro, fortsatte projektets udvikling â i begyndelsen af 2015 begyndte vi aktivt at udvikle administrationspanelet. I 2015 og 2016 gik det godt, vi udgav regelmĂŠssigt, administrationspanelet dĂŠkkede en stadig stĂžrre del af dataforberedelsen, og vi forberedte os pĂ„, at vores team snart ville fĂ„ ansvaret for det vigtigste og mest komplekse â produktkonturen (den fulde forberedelse og vedligeholdelse af data for alle produkter). Men om sommeren 2017, lige fĂžr lanceringen af produktkonturen, kom projektet i en meget vanskelig situation â netop pĂ„ grund af problemer med caching. Om dette episode vil jeg gerne fortĂŠlle i den anden del af denne to-delte publikation.
Men i dette indlĂŠg vil jeg starte fra begyndelsen og opsummere nogle tanker â ideer om caching, som det ville vĂŠre en god idĂ© at overveje pĂ„ forhĂ„nd inden et stort projekt.
NÄr opgaven med caching opstÄr
Cache-opgaven opstĂ„r ikke bare sĂ„dan. Vi er udviklere, skriver softwareprodukter, og vi Ăžnsker, at de skal vĂŠre eftertragtede. Hvis produktet er eftertragtet og succesfuldt â kommer brugerne. Og endnu flere kommer, og sĂ„ videre. Og pludselig er der rigtig mange brugere, og sĂ„ bliver produktet hĂžjt belastet.
I de tidlige faser tĂŠnker vi ikke pĂ„ optimering og kodeydelse. Det vigtigste er funktionalitet, hurtigt at fĂ„ pilotversionen ud og teste hypoteser. Og hvis belastningen stiger â opgraderer vi hardwaren. Vi Ăžger den med to til tre, fem, lad os sige ti gange. Her begynder Ăžkonomien dog at sĂŠtte grĂŠnser. Og hvor mange brugere kan vi forvente i fremtiden? Det vil ikke kun vĂŠre 2-5-10, men i tilfĂŠlde af succes â fra 100 til 1000 og op til 100.000 gange. SĂ„dan at pĂ„ et tidspunkt mĂ„ vi tage os af optimering.
Lad os antage, at en del af koden (lad os kalde den funktion) kĂžrer bemĂŠrkelsesvĂŠrdigt langsomt, og vi Ăžnsker at reducere eksekveringstiden. En funktion kan vĂŠre adgang til en database eller udfĂžrelse af en kompleks logik â 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Ăžre 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.
Det vil sige, implementeringen af funktionen er ikke sĂ„ vigtig for os. Det er kun nĂždvendigt at vide, hvilke parametre resultatet afhĂŠnger af. Hvis vi sĂ„ prĂŠsenterer vĂŠrdierne for parametrene som et objekt, der kan bruges som en nĂžgle i et eller andet lager â kan vi gemme resultatet og ved nĂŠste anmodning hente det. Hvis disse opslag og hentninger gĂ„r hurtigere end at udfĂžre funktionen, sĂ„ fĂ„r vi en hastighedsfordel. Fordelen kan vĂŠre op til 100, 1000 eller endda 100.000 gange (10^5 er nĂŠppe normen, men i tilfĂŠlde af en betydeligt langsom database er det helt muligt).
De grundlĂŠggende krav til et cache-system
Det fĂžrste, der kan blive et krav til et cache-system, er hurtig lĂŠsehastighed og i lidt mindre grad â skrivehastighed. Dette er korrekt, men kun indtil vi ruller systemet ud i produktion.
Lad os overveje et scenario.
Antag, at vi har sikret hardware til den nuvĂŠrende belastning, og nu gradvist implementerer caching. Antallet af brugere stiger lidt, belastningen vokser â vi tilfĂžjer lidt caching, tilslutter det her og der. Dette fortsĂŠtter i noget tid, og nu bliver de tunge funktioner nĂŠsten ikke kaldt â al den primĂŠre belastning ligger pĂ„ cachen. Antallet af brugere er steget med N gange i denne periode.
Og hvis det oprindelige hardware-boost var 2-5 gange, sĂ„ har vi med caching kunnet trĂŠkke ydeevnen op til 10 gange eller, i bedste fald, 100 gange, og nogle steder endda 1000 gange. Det vil sige, pĂ„ den samme hardware â behandler vi 100 gange flere forespĂžrgsler. Fantastisk, vi har fortjent en belĂžnning!
Men nu, i et pludseligt Ăžjeblik, gik systemet i stĂ„, og cachen kollapsede. Ikke noget sĂŠrligt â for cache blev valgt efter kriteriet "hĂžj lĂŠse- og skrivehastighed, resten er ikke vigtigt".
I forhold til den startbelastning havde vi en hardwaremargin pĂ„ 2-5 gange, mens belastningen i mellemtiden var steget 10-100 gange. Ved hjĂŠlp af cachen undgik vi kald til tunge funktioner, og derfor fungerede alt gnidningsfrit. Men nu, uden cache â hvor meget vil vores system falde? Hvad vil der ske? Systemet vil gĂ„ ned.
Selv hvis vores cache ikke er kollapset, men kun er blevet tĂžmt i et stykke tid â skal den varmes op, og det vil tage noget tid. Og i denne tid vil den primĂŠre belastning ligge pĂ„ funktionaliteten.
Konklusion: hÞjbelastede projekter i produktion krÊver af systemet, at caching ikke kun har hÞj lÊse- og skrivehastighed, men ogsÄ databevaring og modstandsdygtighed over for fejl.
Valgets kvaler
I projektet med administrationspanelet blev valgprocessen sĂ„ledes: fĂžrst installerede vi Hazelcast, da vi allerede var bekendt med dette produkt gennem erfaringen fra hovedwebsitet. Men her viste denne beslutning sig at vĂŠre uheldig â under vores belastningsprofil arbejder Hazelcast ikke bare langsomt, men ekstremt langsomt. Og med de frister for at gĂ„ i produktion, havde vi allerede skrevet under pĂ„ det.
Spoiler: hvordan omstĂŠndighederne udfoldede sig, sĂ„ vi oversĂ„ en sĂ„dan faldgrube og havnede i en akut og anspĂŠndt situation â vil jeg fortĂŠlle i del to â og hvordan vi endte, og hvordan vi kom ud af det. Men lige nu â vil jeg kun sige, at det var en stĂŠrk stress, og "at tĂŠnke â det er svĂŠrt, vi ryster flasken". "Vi ryster flasken" â det er ogsĂ„ en spoiler, om dette senere.
Hvad vi gjorde:
- Vi laver en liste over alle systemer, som Google og StackOverflow foreslÄr. Lidt over 30
- Vi skriver testcases med en belastning, der er karakteristisk for produktionen. Til dette har vi optaget data, der passerer gennem systemet i produktionsmiljĂžet â en slags sniffer for data ikke i netvĂŠrket, men inde i systemet. I testene kĂžrte vi netop disse data.
- Hele teamet, hver vĂŠlger det nĂŠste system fra listen, konfigurerer og kĂžrer testene. Bestandstest, der ikke klarer belastningen â kasserer vi og gĂ„r videre til den nĂŠste i kĂžen.
- Ved det 17. system blev det klart, at alt var hÄblÞst. Nok med at "ryst flasken", tid til seriÞs refleksion.
Men dette er et valg, nÄr man skal vÊlge et system, der "kan klare sig hastighedsmÊssigt" i de forberedte tests. Men hvad hvis der ikke findes sÄdanne tests, og man Þnsker at vÊlge hurtigere?
Lad os modellere et sÄdant scenarie (det er svÊrt at forestille sig, at en mid-level udvikler lever i et vakuum, og pÄ tidspunktet for valget ikke har angivet prÊferencer for, hvilket produkt man Þnsker at prÞve fÞrst - derfor er de videre overvejelser mere teoretiske/filosofiske/om juniordevs).
NĂ„r kravene er fastlagt, begynder vi at vĂŠlge en out-of-the-box lĂžsning. Der er ingen grund til at opfinde hjulet: vi vil tage et fĂŠrdiglavet cache-system.
Hvis du lige er startet og vil google, sÄ kan rÊkkefÞlgen vÊre plus-minus, men generelt vil pejlemÊrkerne vÊre sÄdanne. FÞrst vil du stÞde pÄ Redis, det er overalt. SÄ vil du finde ud af, at der er EhCache som det Êldste og mest pÄlidelige system. Derefter vil Tarantool komme pÄ tale - en indenlandsk udvikling med et unikt aspekt. Og selvfÞlgelig Ignite, fordi det lige nu er i hÞj popularitet og understÞttes af SberTech. Til sidst vil Hazelcast ogsÄ blive nÊvnt, for det dukker ofte op i enterprise-verdenen blandt store virksomheder.
Dette er ikke en udtĂžmmende liste, der findes dusinvis af systemer. Men vi vil kun tage Ă©t. Vi vil tage de valgte 5 systemer til en "skĂžnhedskonkurrence" og lave en udvĂŠlgelse. Hvem vil vĂŠre vinderen?
Redis
Lad os lÊse, hvad der stÄr pÄ den officielle hjemmeside.
â et open-source projekt. Tilbyder et in-memory datalager, mulighed for on-disk lagring, automatisk partitionering, hĂžj tilgĂŠngelighed og genopretning efter netvĂŠrksbrud.
Det ser ud til, at alt er i orden, man kan tage det og integrere det - alt hvad der er nÞdvendigt, gÞr det. Men lad os lige af ren nysgerrighed se pÄ de andre kandidater.
EhCache
â "den mest udbredte cache til Java" (oversĂŠttelse af sloganet fra den officielle hjemmeside). OgsĂ„ open-source. Her forstĂ„r vi, at Redis ikke er til Java, men er generelt, og for at interagere med det krĂŠves der et wrapper. EhCache vil vĂŠre mere praktisk. Hvad mere lover systemet? PĂ„lidelighed, afprĂžvethed, fuld funktionalitet. Og sĂ„ er det det mest udbredte. Og det cacher terabytes af data.
Redis er glemt, jeg er klar til at vĂŠlge EhCache.
Men patriotismen fÄr mig til at se pÄ, hvad der er godt ved Tarantool.
Tarantool
â mĂžder betegnelsen «Data Integrationsplatform i realtid». Det lyder meget kompliceret, sĂ„ lad os lĂŠse siden grundigt og finde den stĂŠrke pĂ„stand: «Cache lagrer 100% af dataene i den primĂŠre hukommelse». Dette skal vĂŠkke spĂžrgsmĂ„l â for dataene kan vĂŠre betydeligt mere end hukommelsen. Forklaringen er, at nĂ„r data skal skrives til disken fra hukommelsen, bruger Tarantool ikke serialisering. I stedet bruger det lavniveau egenskaber i systemet, hvor hukommelsen blot kortlĂŠgges til filsystemet med meget gode I/O prĂŠstationer. Alt i alt, de har gjort det pĂ„ en bemĂŠrkelsesvĂŠrdig og smart mĂ„de.
Lad os se pĂ„ implementeringerne: Mail.ru korporativet, Avito, Beeline, Megafon, Alfa-Bank, GazpromâŠ
Hvis der stadig er nogen tvivl om Tarantool, sÄ nedkÊmper implementeringscasen i Mastercard mig. Jeg vÊlger Tarantool.
Men alligevelâŠ
Ignite
⊠er der ogsÄ , prÊsenteret som «in-memory beregningsplatform⊠in-memory hastigheder pÄ petabyte data». Her er der ogsÄ mange fordele: distribueret in-memory cache, det hurtigste key-value lager og cache, horisontal skalerbarhed, hÞj tilgÊngelighed, strengt dataintegritet. SÄ viser det sig, at den hurtigste er Ignite.
Implementeringer: Sberbank, American Airlines, Yahoo! Japan. Og sÄ 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Êlge Ignite.
Hele femte punkt er helt uforstÄeligt for mig.
Hazelcast
Jeg gÄr ind pÄ hjemmesiden , lÊser. Og det viser sig, at den hurtigste lÞsning til distribueret caching er Hazelcast. Det er mange gange hurtigere end alle andre lÞsninger og faktisk lederen inden for in-memory data grids. I lyset af dette ville det vÊre en skam at vÊlge noget andet. Og det bruger ogsÄ redundant datalagring for at sikre, at klyngen fungerer kontinuerligt uden datatab.
Det er det, jeg er klar til at vĂŠlge Hazelcast.
Sammenligning
Men hvis man ser efter, sÄ er alle fem kandidater sÄ beskrevet, at hver af dem er den bedste. Hvordan vÊlger man? Vi kan se, hvilken af dem der er mest populÊr, sÞge efter sammenligninger, sÄ forsvinder hovedpinen.
Vi finder en sÄdan , vÊlger vores 5 systemer.
Her er de sorteret: Ăžverst Redis, pĂ„ andenpladsen â Hazelcast, Tarantool og Ignite vinder popularitet, mens EhCache forbliver den samme.
Men lad os se pĂ„ : links til hjemmesider, generel interesse for systemet, jobtilbud â fantastisk! SĂ„ nĂ„r mit system gĂ„r ned, kan jeg sige: «Nej, det er jo pĂ„lideligt! Der er mange jobtilbud...». En sĂ„ simpel sammenligning vil ikke holde.
Alle disse systemer er ikke bare caching-systemer. De har ogsÄ mange funktioner, herunder - hvor ikke data sendes til klienten til behandling, men i stedet: koden, der skal kÞres pÄ dataene, flyttes til serveren, hvor den udfÞres, og resultatet returneres. Som en separat caching-lÞsning bliver de ikke sÄ ofte betragtet.
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Ä vi sammenligner dem ud fra dette parameter.
Hz vs Redis
Lad os finde sÄdan en :
BlÄ er Redis, rÞd er Hazelcast. Hazelcast vinder overalt, og der er en grund til det: det er multitrÄdede, hÞjt optimerede, hver trÄd arbejder med sin partition, sÄ der er ingen blokeringer. Redis er derimod entrÄdet 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Êrt protokol, mens Redis er tekstbaseret, hvilket gÞr det ineffektivt.
Til information vil vi se pÄ endnu en kilde til sammenligning. Hvad vil den vise os?
Redis vs Hz
En anden :
Her er det omvendt, rĂžd er Redis. Det vil sige, Redis vinder i ydeevne over Hazelcast. I den fĂžrste sammenligning vandt Hazelcast, i den anden vandt Redis. forklarede de meget prĂŠcist, hvorfor Hazelcast vandt i den tidligere sammenligning.
Det viser sig, at resultatet af den fÞrste faktisk var manipuleret: Redis blev taget i sin grundlÊggende form, mens Hazelcast blev tilpasset til testtilfÊldet. Det betyder: for det fÞrste, man kan ikke stole pÄ nogen, for det andet, nÄr vi endelig vÊlger et system, skal vi ogsÄ konfigurere det korrekt. Disse indstillinger omfatter dusinvis, nÊsten hundrede parametre.
Ryst flasken
Og hele den proces, vi netop har gennemgÄet, kan jeg forklare med den metafor «Ryst flasken». Det vil sige, lige nu kan man ikke programmere, det vigtigste er at kunne lÊse stackoverflow. Og jeg har en person pÄ mit team, en professionel, der netop arbejder sÄdan i kritiske Þjeblikke.
Hvad gĂžr han? Han ser en defekt ting, ser stack trace, tager nogle af ordene derfra (hvilke prĂŠcist â det er hans ekspertise i programmet), sĂžger pĂ„ Google, finder Stack Overflow blandt svarene. Uden at lĂŠse grundigt, uden at overveje, blandt svarene vĂŠlger han noget, der ligner en sĂŠtning som "gĂžr dette og andet" (det er hans talent at vĂŠlge sĂ„dan et svar, for det er ikke altid det svar, der har fĂ„et flest likes), anvender det, kigger: hvis noget har ĂŠndret sig, sĂ„ er det fantastisk. Hvis der ikke er ĂŠndret noget â ruller vi tilbage. Og vi gentager kĂžrsel-kontrol-sĂžgning. Og pĂ„ denne intuitive mĂ„de nĂ„r 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Ă„r programmet virker â er det meget lettere. Og sparer betydeligt tid.
Denne metode forklares meget godt med et sÄdant eksempel.
Engang var det meget populĂŠrt at samle et skib i en flaske. Skibet er stort og skrĂžbeligt, og flaskehalsen er meget smal, det kan ikke presses indenfor. Hvordan samler man det?
Der er en metode, meget hurtig og meget effektiv.
Skibet bestÄr af en masse smÄting: trÊstykker, reb, sejl, lim. Alt dette lÊgger vi i flasken.
Vi tager flasken med to hĂŠnder og begynder at ryste. Vi ryster den og ryster den. Og normalt â bliver det naturligvis noget skrammel. Men nogle gange. Nogle gange bliver det et skib! Mere prĂŠcist, noget der ligner et skib.
Vi viser dette noget til nogen: "Sergio, ser du!?". Og faktisk, fra afstand â ligner det et skib. Men lĂŠngere skal det ikke sendes.
Der er en anden metode. De mere avancerede fyre bruger, sÄdanne hackere.
Jeg gav sĂ„dan en fyr en opgave, han gjorde alt og gik. Og man kigger â det ser ud til at vĂŠre gjort. Men efter noget tid, nĂ„r der skal arbejdes videre med koden â sĂ„ begynder der sĂ„dan noget fra ham⊠Godt for ham, at han allerede har lĂžbet langt vĂŠk. Det er sĂ„danne fyre, der pĂ„ eksemplet med flasken gĂžr sĂ„dan: ser du, hvor bunden er â bĂžjer glasset. Og det er ikke helt klart, om det er klart eller ej. SĂ„ "hackere" saver bunden af, indsĂŠtter skibet indeni, bunden limes sĂ„ tilbage, og det ser ud til, at det altid har vĂŠret sĂ„dan.
NÄr det kommer til opgaveformuleringen, ser alt ud til at vÊre korrekt. Men nÄr vi ser pÄ eksemplet med skibene: hvorfor overhovedet lave denne skib, og hvem har brug for det? Det har ingen funktionalitet. Normalt er sÄdanne skibe gaver til meget hÞjtstÄende personer, der placerer det pÄ en hylde over sig selv som en visuel symbolik. Og hvis en sÄdan person, en leder af en stor virksomhed eller en hÞjtstÄende embedsmand, har en sÄdan amatÞrarbejde som flag, hvor halsen er skÄret af? Det ville vÊre bedre, hvis han aldrig fik nys om det. SÄ hvordan bliver disse skibe, der kan gives til en vigtig person, faktisk lavet?
Det eneste sted, der virkelig ikke kan Êndres, 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 Êgte hÄndvÊrk. Der tilfÞjes specielle hÄndtag til de sammensatte dele, sÄ de senere kan lÞftes. For eksempel foldes sejlene forsigtigt ind, og derefter bruges en pincet til meget prÊcist at trÊkke og hÊve dem. Resultatet bliver et kunstvÊrk, som kan gives med god samvittighed og stolthed.
Og hvis vi vil, at projektet skal vÊre succesfuldt, skal der vÊre mindst én juveler pÄ holdet. En, der bekymrer sig om produktkvaliteten og tager hÞjde for alle aspekter uden at gÄ pÄ kompromis, selv i stressede Þjeblikke, hvor omstÊndighederne krÊver hurtige beslutninger pÄ bekostning af det vigtige. Alle succesfulde projekter, der er bÊredygtige og har bestÄet tidens prÞve, er bygget pÄ dette princip. De har noget meget prÊcist og unikt, noget der udnytter alle tilgÊngelige muligheder. I eksemplet med skibet i flasken spilles der med det faktum, at skroget passer gennem halsen.
NÄr vi vender tilbage til opgaven med at vÊlge vores caching-server, hvordan kunne denne tilgang sÄ anvendes? Jeg foreslÄr en metode, der ikke inkluderer at ryste flasken eller vÊlge, men snarere at se, hvad der i bund og grund er vÊrd at bemÊrke ved valget af system.
Hvor skal man lede efter flaskehalse?
Lad os prÞve ikke at ryste flasken, ikke gennemgÄ alt i rÊkkefÞlge, men se pÄ, hvilke opgaver der opstÄr, hvis vi pludselig skal designe et sÄdant system selv. Vi vil selvfÞlgelig ikke samle cyklen, men vi vil bruge dette skema til at orientere os om, hvilke aspekter vi skal vÊre opmÊrksomme pÄ i produktbeskrivelserne. Lad os skitsere et sÄdant skema.
Hvis systemet er distribueret, sĂ„ vil vi have flere servere (6). Lad os antage, at der er fire (praktisk at visualisere, men der kan selvfĂžlgelig vĂŠre sĂ„ mange, man vil). Hvis serverne er pĂ„ forskellige noder, sĂ„ kĂžrer der noget kode pĂ„ dem alle, der sĂžrger for, at disse noder danner et cluster og i tilfĂŠlde af brud â kan forbinde og genkende hinanden.
Der krÊves ogsÄ kode-logik (2) specifikt til cache-hÄndtering. Denne kode interagerer med klienterne gennem et bestemt API. Klientkoden (1) kan vÊre inden for den samme JVM eller kontakte den over netvÊrket. Logikken, der implementeres internt, handler om, hvilke objekter der skal forblive i cachen, og hvilke der skal smides vÊk. Vi bruger hukommelse (3) til at opbevare cachen, men hvis det er nÞdvendigt, kan vi ogsÄ gemme nogle data pÄ disk (4).
Lad os se, hvilke dele der vil opleve belastning. Faktisk vil hver pil og hver node vĂŠre belastet. For det fĂžrste, mellem klientkoden og API'en, hvis det er en netvĂŠrksinteraktion, kan der vĂŠre en betydelig forsinkelse. For det andet, inden for selve API'en â hvis logikken bliver for kompleks, kan vi stĂžde pĂ„ CPU-begrĂŠnsninger. Og det ville vĂŠre godt, hvis logikken ikke unĂždigt bruger hukommelse. Og der er ogsĂ„ interaktionen med filsystemet â i en almindelig situation er det at serialisere / gendanne og skrive / lĂŠse.
DernÊst interaktionen med clustret. Det vil sandsynligvis vÊre inden for dette samme system, men det kan ogsÄ vÊre separat. Her skal vi ogsÄ tage hÞjde for dataoverfÞrslen til det, hastigheden for data-serialisering og interaktionen mellem clustret.
Nu kan vi dels forestille os, âhvilke tandhjul der vil drejeâ i cache-systemet ved behandlingen af forespĂžrgsler fra vores kode, og pĂ„ den anden side kan vi estimere, hvilke og hvor mange forespĂžrgsler vores kode vil generere til dette system. Dette er tilstrĂŠkkeligt til at trĂŠffe et mere eller mindre rationelt valg â at vĂŠlge et system, der passer til vores brugssituation.
Hazelcast
Lad os se pÄ, hvordan sÄdan en opdeling kan anvendes pÄ vores liste. For eksempel, Hazelcast.
For at gemme/hente data fra Hazelcast henvender klientkode sig (1) til API'en. Hz gÞr det muligt at kÞre serveren som embedded, og i sÄ fald er henvendelsen til API'en et metodekald inden for JVM, noget man kan betragte som gratis.
For at logikken fungerer i (2), baserer Hz sig pĂ„ en hash af en byte-array af den serialiserede nĂžgle â det vil sige, at serialiseringen af nĂžglen vil ske uanset hvad. Dette er en uundgĂ„elig overhead for Hz.
Eviction-strategierne er godt implementeret, men til sĂŠrlige tilfĂŠlde kan man tilslutte sine egne. Man skal ikke bekymre sig om denne del.
Lagringen (4) kan tilsluttes. Fremragende. Interaktionen (5) for embedded kan betragtes som Ăžjeblikkelig. Dataudvekslingen mellem noderne i klyngen (6) â ja, den findes. Det er et bidrag til fejltolerance pĂ„ bekostning af hastigheden. Hertz-funktionaliteten Near-cache gĂžr det muligt at reducere prisen â data, der er hentet fra andre noder i klyngen, vil blive cachet.
Hvad kan man gÞre under sÄdanne betingelser for at Þge hastigheden?
For eksempel, for at undgĂ„ at serialisere nĂžglen i (2) â tilfĂžje endnu en cache oven pĂ„ Hazelcast for de mest varme data. Hos Sportmaster valgte de Caffeine til dette formĂ„l.
For at justere pÄ niveau (6), tilbydes to typer lagring i Hz: IMap og ReplicatedMap.
Det er vĂŠrd at nĂŠvne, hvordan Hazelcast kom ind i teknologi-stakken hos Sportmaster.
I 2012, da vi arbejdede pĂ„ det allerfĂžrste pilotprojekt til den kommende hjemmeside, var det faktisk Hazelcast, der var det fĂžrste link, som sĂžgemaskinen viste. Bekendtskabet begyndte 'fra fĂžrste gang' â vi blev charmeret over, at allerede to timer efter, at vi integrerede Hz i systemet, â sĂ„ 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.
Men sĂ„danne argumenter som 'fĂžrste link i sĂžgemaskinen' og 'hurtigt oprettet HelloWorld' â er selvfĂžlgelig undtagelsen og et sĂŠrligt Ăžjeblik i valget. De virkelige udfordringer for det valgte system starter, nĂ„r man gĂ„r i produktion, og det er netop i denne fase, man skal lĂŠgge mĂŠrke til ved valget af ethvert system, inklusive cache. Egentlig kan man sige, at vi valgte Hazelcast ved en tilfĂŠldighed, men senere viste det sig, at vi valgte rigtigt.
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 â 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.
For all these requirements, Hazelcast is certainly suitable.
To be continued
But 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.
For now⊠Happy New Code!
Kilde: habr.com
