Hej! Mit navn er Alexey Pyankov, jeg er udvikler hos Sportmaster-firmaet. I det Jeg fortalte, hvordan arbejdet med Sportmaster-hjemmesiden begyndte i 2012, hvilke initiativer vi formåede at "skubbe igennem" og omvendt, hvilken rake vi indsamlede.
I dag vil jeg dele tanker, der følger et andet emne - at vælge et caching-system til java-backend i webstedets admin-panel. Dette plot har en særlig betydning for mig – selvom historien kun udspillede sig i 2 måneder, arbejdede vi i disse 60 dage 12-16 timer og uden en eneste fridag. Jeg havde aldrig troet eller forestillet mig, at det var muligt at arbejde så hårdt.
Derfor deler jeg teksten op i 2 dele for ikke at indlæse den helt. Tværtimod vil den første del være meget let - forberedelse, introduktion, nogle overvejelser om, hvad caching er. Hvis du allerede er en erfaren udvikler eller har arbejdet med caches, vil der fra den tekniske side højst sandsynligt ikke være noget nyt i denne artikel. Men for en junior kan sådan en lille anmeldelse fortælle ham, hvilken retning han skal kigge i, hvis han står ved sådan en skillevej.
Da den nye version af Sportmaster-hjemmesiden blev sat i produktion, blev data modtaget på en måde, der mildest talt ikke var særlig bekvem. Grundlaget var udarbejdet tabeller til den tidligere version af webstedet (Bitrix), som skulle trækkes ind i ETL, bringes til en ny form og beriges med forskellige småting fra et dusin flere systemer. For at et nyt billede eller produktbeskrivelse kunne dukke op på siden, skulle du vente til næste dag - opdateringer kun om natten, en gang om dagen.
Til at begynde med var der så mange bekymringer fra de første uger, da de gik i produktion, at sådanne gener for indholdsadministratorer var en bagatel. Men så snart alt faldt på plads, fortsatte udviklingen af projektet - et par måneder senere, i begyndelsen af 2015, begyndte vi aktivt at udvikle adminpanelet. I 2015 og 2016 går alt godt, vi frigiver regelmæssigt, adminpanelet dækker mere og mere af dataforberedelsen, og vi forbereder os på, at vores team snart vil blive betroet det vigtigste og mest komplekse - produktet kredsløb (fuldstændig klargøring og vedligeholdelse af data på alle produkter). Men i sommeren 2017, lige før lanceringen af råvarekredsløbet, vil projektet komme i en meget vanskelig situation – netop på grund af problemer med caching. Jeg vil gerne tale om denne episode i anden del af denne todelte publikation.
Men i dette indlæg vil jeg starte på afstand, jeg vil præsentere nogle tanker - ideer om caching, som ville være et godt skridt at scrolle igennem før et stort projekt.
Når en caching-opgave opstår
Caching-opgaven vises ikke kun. Vi er udviklere, skriver et softwareprodukt og ønsker, at det skal være efterspurgt. Hvis produktet er efterspurgt og succesfuldt, kommer brugerne. Og der kommer flere og flere. Og så er der mange brugere, og så bliver produktet meget belastet.
I de første faser tænker vi ikke på optimering og kodeydelse. Det vigtigste er funktionalitet, hurtig udrulning af en pilot og test af hypoteser. Og hvis belastningen stiger, pumper vi jernet op. Vi øger det to eller tre gange, fem gange, måske 10 gange. Et eller andet sted her - økonomien tillader det ikke længere. Hvor mange gange vil antallet af brugere stige? Det bliver ikke som 2-5-10, men hvis det lykkes, vil det være fra 100-1000 til 100 tusinde gange. Det vil sige, før eller siden skal du foretage optimering.
Lad os sige, at en del af koden (lad os kalde denne del en funktion) tager uanstændigt lang tid, og vi ønsker at reducere eksekveringstiden. En funktion kan være adgang til en database, eller det kan være udførelse af en eller anden kompleks logik - det vigtigste er, at det tager lang tid at gennemføre. Hvor meget kan du reducere udførelsestiden? I grænsen kan du reducere det til nul, ikke længere. Hvordan kan du reducere eksekveringstiden til nul? Svar: eliminer udførelse helt. Returner i stedet resultatet med det samme. Hvordan kan du finde ud af resultatet? Svar: enten beregne det eller se et sted. Det tager lang tid at beregne. Og at spionere er for eksempel at huske det resultat, som funktionen producerede sidste gang, da den blev kaldt med de samme parametre.
Det vil sige, at implementeringen af funktionen ikke er vigtig for os. Det er nok bare at vide, hvilke parametre resultatet afhænger af. Så, hvis parameterværdierne er repræsenteret i form af et objekt, der kan bruges som en nøgle i et eller andet lager, kan resultatet af beregningen gemmes og læses ud, næste gang det tilgås. Hvis denne skrivning og læsning af resultatet er hurtigere end at udføre funktionen, har vi et overskud i forhold til hastighed. Mængden af overskud kan nå op på 100, 1000 og 100 tusind gange (10^5 er snarere en undtagelse, men i tilfælde af en ret haltende base er det meget muligt).
Grundlæggende krav til et cachingsystem
Det første, der kan blive et krav til et cachingsystem, er hurtig læsehastighed og i lidt mindre grad skrivehastighed. Dette er sandt, men kun indtil vi ruller systemet ud til produktion.
Lad os spille denne sag.
Lad os sige, at vi har forsynet den nuværende belastning med hardware og nu gradvist introducerer caching. Antallet af brugere vokser lidt, belastningen vokser - vi tilføjer lidt caches, skruer det ind hist og her. Dette fortsætter i nogen tid, og nu kaldes tunge funktioner praktisk talt ikke længere - hele hovedbelastningen falder på cachen. Antallet af brugere i denne periode er steget N gange.
Og hvis den indledende forsyning af hardware kunne være 2-5 gange, så kunne vi ved hjælp af cachen forbedre ydeevnen med en faktor på 10 eller, i et godt tilfælde, med en faktor på 100, nogle steder måske med en faktor på 1000. Det vil sige på samme hardware – vi behandler 100 gange flere forespørgsler. Super, du fortjener honningkagerne!
Men nu, i et fint øjeblik, ved et tilfælde, styrtede systemet ned, og cachen kollapsede. Ikke noget særligt - cachen blev trods alt valgt ud fra kravet "høj læse- og skrivehastighed, resten er ligegyldigt."
I forhold til startbelastningen var vores jernreserve 2-5 gange, og belastningen i denne tid steg 10-100 gange. Ved at bruge cachen eliminerede vi opkald til tunge funktioner, og derfor fungerede alt. Og nu, uden en cache, hvor mange gange vil vores system bremse? Hvad vil der ske med os? Systemet vil falde.
Selvom vores cache ikke gik ned, men kun blev ryddet i et stykke tid, skal den varmes op, og det vil tage noget tid. Og i løbet af denne tid vil hovedbyrden falde på funktionalitet.
Konklusion: højt belastede produktionsprojekter kræver, at et cachingsystem ikke kun har høje læse- og skrivehastigheder, men også for at sikre datasikkerhed og modstand mod fejl.
Valgets kvaler
I et projekt med et adminpanel gik valget sådan her: Først installerede vi Hazelcast, pga Vi var allerede bekendt med dette produkt fra erfaringerne fra hovedsiden. Men her viste dette valg sig at være mislykket - under vores belastningsprofil er Hazelcast ikke bare langsom, men frygtelig langsom. Og på det tidspunkt havde vi allerede tilmeldt udgivelsesdatoen.
Spoiler: hvordan præcist de omstændigheder udviklede sig, at vi gik glip af så stort en ting og endte i en akut og anspændt situation - jeg fortæller i anden del - og hvordan vi endte, og hvordan vi kom ud. Men nu - jeg vil bare sige, at det var meget stress, og "at tænke - på en eller anden måde kan jeg ikke tænke, vi ryster flasken." "Shaking the bottle" er også en spoiler, mere om det senere.
Hvad vi gjorde:
- Vi laver en liste over alle de systemer, som Google og StackOverflow foreslår. Lidt over 30
- Vi skriver test med en belastning typisk for produktionen. For at gøre dette registrerede vi data, der passerer gennem systemet i et produktionsmiljø - en slags sniffer for data ikke på netværket, men inde i systemet. Netop disse data blev brugt i testene.
- Med hele teamet vælger alle det næste system fra listen, konfigurerer det og kører test. Den består ikke testen, den bærer ikke byrden - vi smider den væk og går videre til den næste i rækken.
- På det 17. system blev det klart, at alt var håbløst. Stop med at ryste flasken, det er tid til at tænke seriøst.
Men dette er en mulighed, når du skal vælge et system, der vil "komme igennem hastigheden" i forudforberedte tests. Hvad hvis der ikke er sådanne tests endnu, og du vil vælge hurtigt?
Lad os modellere denne mulighed (det er svært at forestille sig, at en mellem-+ udvikler lever i et vakuum, og på tidspunktet for udvælgelsen endnu ikke har formaliseret sin præference med hensyn til hvilket produkt, der skal prøves først - derfor er yderligere ræsonnement mere en teoretiker/filosofi/ om en junior).
Efter at have besluttet os for kravene, begynder vi at vælge en løsning ud af kassen. Hvorfor genopfinde hjulet: Vi tager et færdiglavet cachingsystem.
Hvis du lige er startet og googler det, så giv eller tag ordren, men generelt vil retningslinjerne være sådan her. Først og fremmest vil du støde på Redis, det høres overalt. Så vil du finde ud af, at EhCache er det ældste og mest gennemprøvede system. Dernæst vil vi skrive om Tarantool, en hjemlig udvikling, der har et unikt aspekt af løsningen. Og også Ignite, fordi det nu er stigende i popularitet og nyder godt af støtte fra SberTech. Til sidst er der også Hazelcast, for i virksomhedsverdenen optræder det ofte blandt store virksomheder.
Listen er ikke udtømmende; der er snesevis af systemer. Og vi vil kun skrue én ting. Lad os tage de udvalgte 5 systemer til "skønhedskonkurrencen" og foretage et valg. Hvem bliver vinderen?
Omfor
Vi læser, hvad de skriver på den officielle hjemmeside.
- opensource projekt. Tilbyder datalagring i hukommelsen, muligheden for at gemme på disken, automatisk partitionering, høj tilgængelighed og retablering fra netværksafbrydelser.
Det ser ud til, at alt er i orden, du kan tage det og skrue det på - alt hvad du behøver, det gør det. Men bare for sjov, lad os se på de andre kandidater.
EhCache
- "den mest udbredte cache til Java" (oversættelse af sloganet fra den officielle hjemmeside). Også opensource. Og så forstår vi, at Redis ikke er til java, men generelt, og for at interagere med det har du brug for en indpakning. Og EhCache vil være mere praktisk. Hvad lover systemet ellers? Pålidelighed, gennemprøvet, fuld funktionalitet. Nå, det er også det mest almindelige. Og cacher terabyte af data.
Redis er glemt, jeg er klar til at vælge EhCache.
Men en følelse af patriotisme skubber mig til at se, hvad der er godt ved Tarantool.
Tarantværktøj
- opfylder betegnelsen "Real-time data integration platform". Det lyder meget kompliceret, så vi læser siden i detaljer og finder en høj erklæring: "Caches 100% af dataene i RAM." Dette burde rejse spørgsmål – der kan trods alt være meget mere data end hukommelse. Forklaringen er, at det betyder, at Tarantool ikke kører serialisering for at skrive data til disk fra hukommelsen. I stedet bruger den systemets funktioner på lavt niveau, når hukommelsen blot er mappet til et filsystem med meget god I/O-ydelse. Generelt gjorde de noget vidunderligt og fedt.
Lad os se på implementeringerne: Mail.ru corporate highway, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...
Hvis der stadig var nogen tvivl om Tarantool, så afslutter implementeringssagen hos Mastercard mig. Jeg tager Tarantool.
Men alligevel…
Ignite
… er der noget mere , faktureres som "en in-memory computing platform...in-memory speeds on petabytes of data." Der er også mange fordele her: distribueret cache i hukommelsen, den hurtigste nøgleværdilagring og cache, horisontal skalering, høj tilgængelighed, streng integritet. Generelt 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 SberTech-teamet sender sine folk til Ignite-teamet selv for at forfine produktet. Dette er fuldstændig fængslende, og jeg er klar til at tage Ignite.
Det er helt uklart hvorfor, jeg ser på det femte punkt.
hasselstøbt
Jeg går til siden , læsning. Og det viser sig, at den hurtigste løsning til distribueret caching er Hazelcast. Det er størrelsesordener hurtigere end alle andre løsninger, og generelt er det førende inden for in-memory data grid. På denne baggrund er det at tage noget andet ikke at respektere sig selv. Den bruger også redundant datalagring til kontinuerlig drift af klyngen uden tab af data.
Det er det, jeg er klar til at tage Hazelcast.
sammenligning
Men hvis man ser efter, er alle fem kandidater beskrevet på en sådan måde, at hver af dem er den bedste. Hvordan vælger man? Vi kan se, hvilken der er den mest populære, kigge efter sammenligninger, og hovedpinen vil forsvinde.
Sådan en finder vi , vælg vores 5 systemer.
Her er de sorteret: Redis ligger i toppen, Hazelcast ligger på andenpladsen, Tarantool og Ignite vinder popularitet, EhCache har været og forbliver den samme.
Men lad os se på : links til hjemmesider, generel interesse for systemet, jobtilbud - fantastisk! Det vil sige, når mit system fejler, vil jeg sige: "Nej, det er pålideligt! Der er mange jobtilbud..." Sådan en simpel sammenligning duer ikke.
Alle disse systemer er ikke kun cachesystemer. De har også en masse funktionalitet, herunder når data ikke pumpes til klienten til behandling, men omvendt: den kode, der skal udføres på dataene, flytter til serveren, udføres der, og resultatet returneres. Og de betragtes ikke så ofte som et separat system til caching.
Okay, lad os ikke give op, lad os finde en direkte sammenligning af systemerne. Lad os tage de to øverste muligheder - Redis og Hazelcast. Vi er interesserede i hastighed, og vi vil sammenligne dem ud fra denne parameter.
Hz vs Redis
Vi finder dette :
Blå er Redis, rød er Hazelcast. Hazelcast vinder overalt, og der er en begrundelse for dette: den er multi-threaded, meget optimeret, hver tråd arbejder med sin egen partition, så der er ingen blokering. Og Redis er single-threaded; den nyder ikke godt af moderne multi-core CPU'er. Hazelcast har asynkron I/O, Redis-Jedis har blokerende stik. Når alt kommer til alt, bruger Hazelcast en binær protokol, og Redis er tekstcentreret, hvilket betyder, at den er ineffektiv.
For en sikkerheds skyld, lad os vende os til en anden kilde til sammenligning. Hvad vil han vise os?
Redis vs Hz
andet :
Her er der tværtimod rødt Redis. Det vil sige, at Redis overgår Hazelcast med hensyn til ydeevne. Hazelcast vandt den første sammenligning, Redis vandt den anden. forklarede meget præcist, hvorfor Hazelcast vandt den tidligere sammenligning.
Det viser sig, at resultatet af den første faktisk var rigget: Redis blev taget i baseboksen, og Hazelcast blev skræddersyet til en testcase. Så viser det sig: For det første kan vi ikke stole på nogen, og for det andet, når vi endelig vælger et system, skal vi stadig konfigurere det korrekt. Disse indstillinger omfatter snesevis, næsten hundredvis af parametre.
Ryster flasken
Og jeg kan forklare hele processen, som vi nu har gjort, med følgende metafor: "Ryster flasken." Det vil sige, nu skal du ikke programmere, nu er det vigtigste at kunne læse stackoverflow. Og jeg har en person på mit team, en professionel, som arbejder præcis sådan i kritiske øjeblikke.
Hvad laver han? Han ser en ødelagt ting, ser et stakspor, tager nogle ord fra det (hvilke er hans ekspertise i programmet), søger på Google, finder stackoverflow blandt svarene. Uden at læse, uden at tænke, vælger han blandt svarene på spørgsmålet noget, der ligner sætningen "gør det og det" (at vælge et sådant svar er hans talent, fordi det ikke altid er det svar, der fik flest likes), gælder , udseende: hvis noget har ændret sig, så fantastisk. Hvis det ikke har ændret sig, skal du rulle det tilbage. Og gentag start-tjek-søgning. Og på denne intuitive måde sikrer han, at koden virker efter noget tid. Han ved ikke hvorfor, han ved ikke hvad han gjorde, han kan ikke forklare. Men! Denne infektion virker. Og "ilden er slukket." Lad os nu finde ud af, hvad vi gjorde. Når programmet virker, er det en størrelsesorden nemmere. Og det sparer en masse tid.
Denne metode er meget godt forklaret med dette eksempel.
Det var engang meget populært at samle en sejlbåd på flaske. Samtidig er sejlbåden stor og skrøbelig, og flaskehalsen er meget smal, det er umuligt at skubbe den ind. Hvordan samles det?
Der er sådan en metode, meget hurtig og meget effektiv.
Skibet består af en masse småting: pinde, reb, sejl, lim. Vi putter alt dette i en flaske.
Vi tager flasken med begge hænder og begynder at ryste. Vi ryster og ryster hende. Og som regel viser det sig selvfølgelig at være komplet affald. Men nogle gange. Nogle gange viser det sig at være et skib! Mere præcist noget, der ligner et skib.
Vi viser dette noget til nogen: "Seryoga, kan du se!?" Og faktisk på afstand ligner det et skib. Men det kan ikke tillades at fortsætte.
Der er en anden måde. De bruges af mere avancerede fyre, såsom hackere.
Jeg gav denne fyr en opgave, han gjorde alt og gik. Og du ser - det ser ud som om det er færdigt. Og efter et stykke tid, når koden skal færdiggøres, starter dette på grund af ham... Det er godt, at han allerede har formået at løbe langt væk. Det er de fyre, der ved at bruge eksemplet med en flaske vil gøre dette: du ser, hvor bunden er, hvor glasset bøjer sig. Og det er ikke helt klart, om det er gennemsigtigt eller ej. Så skærer "hackerne" denne bund af, indsætter et skib der, og limer så bunden på igen, og det er, som om det er sådan, det skal være.
Fra synspunktet om at indstille problemet, ser alt ud til at være korrekt. Men ved at bruge skibe som eksempel: hvorfor lave dette skib overhovedet, hvem har brug for det? Det giver ingen funktionalitet. Normalt er sådanne skibe gaver til meget højtstående mennesker, som lægger det på en hylde over dem, som en slags symbol, som et tegn. Og hvis en sådan person, lederen af en stor virksomhed eller en højtstående embedsmand, hvordan vil flaget stå for sådan et hack, hvis hals er blevet skåret af? Det ville være bedre, hvis han aldrig vidste om det. Så hvordan ender de med at lave disse skibe, der kan gives til en vigtig person?
Det eneste nøglested, som du virkelig ikke kan gøre noget ved, er kroppen. Og skibets skrog passer lige ind i nakken. Hvorimod skibet er samlet uden for flasken. Men det er ikke kun at samle et skib, det er et rigtigt smykkehåndværk. Der er tilføjet specielle håndtag til komponenterne, som så tillader dem at blive løftet. For eksempel foldes sejlene, føres forsigtigt ind, og så trækkes og hæves de ved hjælp af en pincet meget præcist, med præcision. Resultatet er et kunstværk, der kan begaves med god samvittighed og stolthed.
Og hvis vi ønsker, at projektet skal lykkes, skal der være mindst én guldsmed på holdet. En person, der bekymrer sig om produktets kvalitet og tager højde for alle aspekter, uden at ofre noget, selv i stress-øjeblikke, hvor omstændighederne kræver at gøre det presserende på bekostning af det vigtige. Alle succesfulde projekter, der er bæredygtige, som har bestået tidens tand, er bygget på dette princip. Der er noget meget præcist og unikt over dem, noget der udnytter alle tilgængelige muligheder. I eksemplet med skibet i flasken udspilles det, at skibets skrog går gennem halsen.
For at vende tilbage til opgaven med at vælge vores caching-server, hvordan kan denne metode anvendes? Jeg tilbyder denne mulighed for at vælge blandt alle de systemer, der findes - ryst ikke flasken, vælg ikke, men se på, hvad de har i princippet, hvad du skal kigge efter, når du vælger et system.
Hvor skal man lede efter flaskehals
Lad os prøve ikke at ryste flasken, ikke at gennemgå alt, hvad der er der én efter én, men lad os se, hvilke problemer der vil opstå, hvis vi pludselig til vores opgave selv designer et sådant system. Selvfølgelig samler vi ikke cyklen, men vi vil bruge dette diagram til at hjælpe os med at finde ud af, hvilke punkter vi skal være opmærksomme på i produktbeskrivelserne. Lad os skitsere sådan et diagram.
Hvis systemet er distribueret, så vil vi have flere servere (6). Lad os sige, at der er fire (det er praktisk at placere dem på billedet, men der kan selvfølgelig være så mange af dem, som du vil). Hvis serverne er på forskellige noder, betyder det, at de alle kører en eller anden kode, der er ansvarlig for at sikre, at disse noder danner en klynge og i tilfælde af et brud forbinder og genkender hinanden.
Vi har også brug for kodelogik (2), som faktisk handler om caching. Klienter interagerer med denne kode via nogle API. Klientkode (1) kan enten være inden for samme JVM eller få adgang til den over netværket. Logikken implementeret indeni er beslutningen om, hvilke objekter der skal efterlades i cachen, og hvilke der skal smides ud. Vi bruger hukommelse (3) til at gemme cachen, men om nødvendigt kan vi gemme nogle af dataene på disk (4).
Lad os se i hvilke dele belastningen vil forekomme. Faktisk vil hver pil og hver node blive indlæst. For det første, mellem klientkoden og api'en, hvis dette er netværkskommunikation, kan nedsynkningen være ret mærkbar. For det andet, inden for rammerne af selve api'et - hvis vi overdriver det med kompleks logik, kan vi løbe ind i problemer med CPU'en. Og det ville være rart, hvis logikken ikke spildede tid på hukommelsen. Og der er stadig interaktion med filsystemet - i den sædvanlige version er dette serialisering / gendan og skriv / læs.
Dernæst er interaktion med klyngen. Mest sandsynligt vil det være i det samme system, men det kan være separat. Her skal du også tage hensyn til overførslen af data til den, hastigheden af dataserialisering og interaktioner mellem klyngen.
Nu kan vi på den ene side forestille os "hvilke gear vil dreje" i cachesystemet, når vi behandler anmodninger fra vores kode, og på den anden side kan vi estimere, hvilke og hvor mange anmodninger vores kode vil generere til dette system. Dette er nok til at træffe et mere eller mindre nøgternt valg - at vælge et system til vores use case.
hasselstøbt
Lad os se, hvordan du anvender denne nedbrydning på vores liste. For eksempel Hazelcast.
For at sætte/tage data fra Hazelcast, får klientkoden adgang til (1) api'en. Hz giver dig mulighed for at køre serveren som indlejret, og i dette tilfælde er adgang til api'en et metodekald inde i JVM, som kan betragtes som gratis.
For at logikken i (2) skal fungere, er Hz afhængig af hashen af byte-arrayet af den serialiserede nøgle - det vil sige, at nøglen vil blive serialiseret under alle omstændigheder. Dette er uundgåeligt overhead for Hz.
Fraflytningsstrategier implementeres godt, men i særlige tilfælde kan du tilføje din egen. Du behøver ikke bekymre dig om denne del.
Lager (4) kan tilsluttes. Store. Interaktion (5) for indlejret kan betragtes som øjeblikkelig. Dataudveksling mellem noder i klyngen (6) - ja, det findes. Dette er en investering i fejltolerance på bekostning af hastighed. Hz-funktionen Near-cache giver dig mulighed for at reducere prisen - data modtaget fra andre noder i klyngen vil blive cachelagret.
Hvad kan der gøres under sådanne forhold for at øge hastigheden?
For at undgå serialisering af nøglen i (2) - vedhæft en anden cache oven på Hazelcast for at få de hotteste data. Sportmaster valgte koffein til dette formål.
Til vridning på niveau (6) tilbyder Hz to typer lagring: IMap og ReplicatedMap.
Det er værd at nævne, hvordan Hazelcast kom ind i Sportmaster-teknologistakken.
I 2012, da vi arbejdede på den allerførste pilot af det fremtidige websted, var det Hazelcast, der viste sig at være det første link, som søgemaskinen returnerede. Bekendtskabet startede "første gang" - vi var betaget af, at det kun to timer senere, da vi skruede Hz ind i systemet, virkede. Og det fungerede godt. Ved slutningen af dagen havde vi gennemført en række tests og var glade. Og denne kraftreserve var nok til at overvinde de overraskelser, som Hz kastede op over tid. Nu har Sportmaster-holdet ingen grund til at opgive Hazelcast.
Men sådanne argumenter som "det første link i søgemaskinen" og "HelloWorld blev hurtigt samlet" er naturligvis en undtagelse og et træk ved det øjeblik, hvor valget fandt sted. De rigtige tests for det valgte system begynder med udgivelsen i produktion, og det er på dette stadium, du skal være opmærksom, når du vælger et hvilket som helst system, inklusive cache. Faktisk kan vi i vores tilfælde sige, at vi ved et tilfælde valgte Hazelcast, men så viste det sig, at vi valgte rigtigt.
For produktion, meget vigtigere: overvågning, håndtering af fejl på individuelle noder, datareplikering, omkostninger ved skalering. Det vil sige, det er værd at være opmærksom på de opgaver, der vil opstå under vedligeholdelsen af systemet - når belastningen er titusinder gange højere end planlagt, når vi ved et uheld uploader noget det forkerte sted, når vi skal udrulle en ny version af koden, udskift data og gør det ubemærket for kunderne.
For alle disse krav passer Hazelcast bestemt til regningen.
Fortsættes
Men Hazelcast er ikke et vidundermiddel. I 2017 valgte vi Hazelcast til admin-cachen, simpelthen baseret på gode indtryk fra tidligere erfaringer. Dette spillede en nøglerolle i en meget grusom vittighed, på grund af hvilken vi befandt os i en vanskelig situation og "heroisk" kom ud af det i 60 dage. Men mere om det i næste del.
I mellemtiden... Glædelig ny kode!
Kilde: www.habr.com