Hur vi på Sportmaster valde ett cachingsystem. Del 1

Hallå! Jag heter Alexey Pyankov, jag är utvecklare på företaget Sportmaster. I den posta Jag berättade hur arbetet med Sportmaster-webbplatsen började 2012, vilka initiativ vi lyckades "driva igenom" och vice versa, vilken rake vi samlade in.

Idag vill jag dela tankar som följer ett annat ämne - att välja ett cachingsystem för java-backend i webbplatsens adminpanel. Den här handlingen har en speciell betydelse för mig - även om historien utspelade sig i bara 2 månader, arbetade vi under dessa 60 dagar 12-16 timmar och utan en enda ledig dag. Jag hade aldrig trott eller föreställt mig att det var möjligt att jobba så hårt.

Därför delar jag upp texten i 2 delar för att inte ladda den helt. Tvärtom kommer den första delen att vara väldigt lätt - förberedelse, introduktion, några funderingar om vad cachning är. Om du redan är en erfaren utvecklare eller har arbetat med cacher, från den tekniska sidan kommer det med största sannolikhet inte finnas något nytt i den här artikeln. Men för en junior kan en så liten recension tala om för honom åt vilket håll han ska titta om han befinner sig vid ett sådant vägskäl.

När den nya versionen av Sportmaster-webbplatsen sattes i produktion togs uppgifterna emot på ett sätt som var milt uttryckt inte särskilt bekvämt. Grunden var tabeller förberedda för den tidigare versionen av sajten (Bitrix), som måste dras in i ETL, föras till en ny form och berikas med olika småsaker från ett dussin fler system. För att en ny bild eller produktbeskrivning skulle dyka upp på sajten var man tvungen att vänta till nästa dag – uppdateringar endast på natten, en gång om dagen.

Till en början var det så många bekymmer från de första veckorna av produktion att sådana besvär för innehållshanterare var en bagatell. Men så fort allt ordnade sig fortsatte utvecklingen av projektet - några månader senare, i början av 2015, började vi aktivt utveckla adminpanelen. Under 2015 och 2016 går allt bra, vi släpper regelbundet, adminpanelen täcker mer och mer av dataförberedelserna, och vi förbereder oss för det faktum att snart kommer vårt team att anförtros det viktigaste och mest komplexa - produkten krets (fullständig förberedelse och underhåll av data på alla produkter). Men sommaren 2017, strax före lanseringen av råvarukretsen, kommer projektet att hamna i en mycket svår situation – just på grund av problem med cachning. Jag vill prata om det här avsnittet i den andra delen av denna tvådelade publikation.

Men i det här inlägget kommer jag att börja på långt håll, jag kommer att presentera några tankar - idéer om cachning, vilket skulle vara ett bra steg att scrolla igenom inför ett stort projekt.

När en cachningsuppgift inträffar

Cachningsuppgiften visas inte bara. Vi är utvecklare, skriver en mjukvaruprodukt och vill att den ska vara efterfrågad. Om produkten är efterfrågad och framgångsrik kommer användare. Och fler och fler kommer. Och så är det många användare och då blir produkten högt laddad.

I de första stegen tänker vi inte på optimering och kodprestanda. Huvudsaken är funktionalitet, att snabbt rulla ut en pilot och testa hypoteser. Och om belastningen ökar pumpar vi upp järnet. Vi ökar den två eller tre gånger, fem gånger, kanske 10 gånger. Någonstans här – ekonomin tillåter det inte längre. Hur många gånger kommer antalet användare att öka? Det blir inte som 2-5-10, men om det lyckas blir det från 100-1000 till 100 tusen gånger. Det vill säga, förr eller senare måste du göra optimering.

Låt oss säga att en del av koden (låt oss kalla den här delen en funktion) tar anständigt lång tid, och vi vill minska exekveringstiden. En funktion kan vara tillgång till en databas, eller så kan det vara exekvering av någon komplex logik - huvudsaken är att den tar lång tid att exekvera. Hur mycket kan du minska utförandetiden? I gränsen kan du minska den till noll, inte längre. Hur kan du minska exekveringstiden till noll? Svar: eliminera exekveringen helt och hållet. Returnera istället resultatet omedelbart. Hur kan du ta reda på resultatet? Svar: antingen räkna ut det eller leta någonstans. Det tar lång tid att räkna ut. Och att spionera är till exempel att komma ihåg resultatet som funktionen gav senast när den anropades med samma parametrar.

Det vill säga implementeringen av funktionen är inte viktig för oss. Det räcker bara att veta vilka parametrar resultatet beror på. Sedan, om parametervärdena representeras i form av ett objekt som kan användas som en nyckel i någon lagring, kan resultatet av beräkningen sparas och läsas ut nästa gång det öppnas. Om denna skrivning och läsning av resultatet går snabbare än att exekvera funktionen har vi en vinst i form av hastighet. Vinstmängden kan nå 100, 1000 och 100 tusen gånger (10^5 är snarare ett undantag, men i fallet med en ganska eftersläpande bas är det fullt möjligt).

Grundkrav för ett cachningssystem

Det första som kan bli ett krav för ett cachningssystem är snabb läshastighet och i något mindre utsträckning skrivhastighet. Detta är sant, men bara tills vi rullar ut systemet till produktion.

Låt oss spela det här fallet.

Låt oss säga att vi har försett den nuvarande belastningen med hårdvara och nu gradvis introducerar cachning. Antalet användare växer lite, belastningen växer - vi lägger till lite cacher, skruvar in här och där. Detta fortsätter ett tag, och nu kallas tunga funktioner praktiskt taget inte längre - hela huvudbelastningen faller på cachen. Antalet användare under denna tid har ökat N gånger.

Och om det initiala utbudet av hårdvara kunde vara 2-5 gånger, så skulle vi med hjälp av cachen kunna förbättra prestandan med en faktor 10 eller, i ett bra fall, med en faktor 100, på vissa ställen kanske med en faktor på 1000. Det vill säga på samma hårdvara – vi behandlar 100 gånger fler förfrågningar. Jättebra, du förtjänar pepparkakan!

Men nu, vid ett vackert ögonblick, av en slump kraschade systemet och cachen kollapsade. Inget speciellt - trots allt valdes cachen baserat på kravet "hög läs- och skrivhastighet, resten spelar ingen roll."

I förhållande till startbelastningen var vår järnreserv 2-5 gånger, och belastningen ökade under denna tid 10-100 gånger. Med hjälp av cachen eliminerade vi anrop för tunga funktioner och därför fungerade allt. Och nu, utan cache, hur många gånger kommer vårt system att sakta ner? Vad kommer att hända med oss? Systemet kommer att falla.

Även om vår cache inte kraschade, utan bara rensades ett tag, kommer den att behöva värmas upp, och det kommer att ta lite tid. Och under denna tid kommer huvudbördan att falla på funktionalitet.

Slutsats: högt belastade produktionsprojekt kräver att ett cachningssystem inte bara har höga läs- och skrivhastigheter, utan också för att säkerställa datasäkerhet och motståndskraft mot fel.

Valets vånda

I ett projekt med en adminpanel gick valet så här: först installerade vi Hazelcast, eftersom Vi var redan bekanta med den här produkten från erfarenheten från huvudsidan. Men här visade sig detta val vara misslyckat - under vår belastningsprofil är Hazelcast inte bara långsam, utan fruktansvärt långsam. Och vid den tiden hade vi redan anmält oss till releasedatumet.

Spoiler: hur exakt omständigheterna utvecklades att vi missade en så stor grej och hamnade i en akut och spänd situation – jag ska berätta i andra delen – och hur vi hamnade och hur vi tog oss ur. Men nu - jag ska bara säga att det var mycket stress, och "att tänka - på något sätt kan jag inte tänka, vi skakar flaskan." "Shaking the bottle" är också en spoiler, mer om det senare.

Vad vi gjorde:

1. Vi gör en lista över alla system som Google och StackOverflow föreslår. Lite över 30
2. Vi skriver tester med en belastning typisk för produktion. För att göra detta spelade vi in ​​data som passerar genom systemet i en produktionsmiljö - ett slags sniffer för data inte på nätverket, utan inne i systemet. Exakt dessa data användes i testerna.
3. Med hela teamet väljer alla nästa system från listan, konfigurerar det och kör tester. Den klarar inte testet, den bär inte lasten – vi kastar den och går vidare till nästa i raden.
4. På det 17:e systemet stod det klart att allt var hopplöst. Sluta skaka flaskan, det är dags att tänka på allvar.

Men det här är ett alternativ när du behöver välja ett system som kommer att "ta sig igenom hastigheten" i förberedda tester. Tänk om det inte finns några sådana test än och du vill välja snabbt?

Låt oss modellera detta alternativ (det är svårt att föreställa sig att en medelhög utvecklare lever i ett vakuum och vid tidpunkten för urvalet ännu inte har formaliserat sin preferens om vilken produkt som ska testas först - därför är ytterligare resonemang mer av en teoretiker/filosofi/ ungefär en junior).

Efter att ha beslutat om kraven, låt oss börja välja en lösning direkt. Varför uppfinna hjulet på nytt: vi går och tar ett färdigt cachingsystem.

Om du precis har börjat och googla, ge eller ta beställningen, men generellt sett kommer riktlinjerna att vara så här. Först och främst kommer du att stöta på Redis, det hörs överallt. Då får du reda på att EhCache är det äldsta och mest beprövade systemet. Därefter kommer vi att skriva om Tarantool, en inhemsk utveckling som har en unik aspekt av lösningen. Och även Ignite, eftersom det nu ökar i popularitet och åtnjuter stöd från SberTech. I slutet finns också Hazelcast, för i företagsvärlden dyker det ofta upp bland stora företag.

Listan är inte uttömmande, det finns dussintals system. Och vi ska bara skruva på en sak. Låt oss ta de utvalda 5 systemen för "skönhetstävlingen" och göra ett urval. Vem blir vinnaren?

Redis

Vi läser vad de skriver på den officiella hemsidan.
Redis - opensource-projekt. Erbjuder datalagring i minnet, möjlighet att spara på disk, automatisk partitionering, hög tillgänglighet och återställning från nätverksavbrott.

Det verkar som att allt är bra, du kan ta det och skruva på det - allt du behöver, det gör det. Men bara för skojs skull, låt oss titta på de andra kandidaterna.

EhCache

EhCache - "den mest använda cachen för Java" (översättning av sloganen från den officiella webbplatsen). Även öppen källkod. Och då förstår vi att Redis inte är för java, utan generellt, och för att interagera med det behöver du ett omslag. Och EhCache kommer att vara bekvämare. Vad mer lovar systemet? Tillförlitlighet, beprövad, full funktionalitet. Tja, det är också det vanligaste. Och cachar terabyte med data.

Redis är bortglömd, jag är redo att välja EhCache.

Men en känsla av patriotism driver mig att se vad som är bra med Tarantool.

Tarantool

Tarantool - uppfyller beteckningen "Realtidsdataintegrationsplattform". Det låter väldigt komplicerat, så vi läser sidan i detalj och hittar ett högt uttalande: "Cachelagrar 100 % av datan i RAM." Detta borde väcka frågor – trots allt kan det finnas mycket mer data än minne. Förklaringen är att det betyder att Tarantool inte kör serialisering för att skriva data till disk från minnet. Istället använder den lågnivåfunktioner i systemet, när minnet helt enkelt mappas till ett filsystem med mycket bra I/O-prestanda. I allmänhet gjorde de något underbart och coolt.

Låt oss titta på implementeringarna: Mail.ru corporate highway, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...

Om det fortfarande fanns några tvivel om Tarantool, så avslutar implementeringsfallet på Mastercard mig. Jag tar Tarantool.

Men ändå…

Tänd

… finns det några fler Tänd, faktureras som en "in-memory computing platform...in-memory speeds on petabyte of data." Det finns också många fördelar här: distribuerad cache i minnet, den snabbaste nyckel-värdelagringen och cachen, horisontell skalning, hög tillgänglighet, strikt integritet. I allmänhet visar det sig att snabbast är Ignite.

Implementeringar: Sberbank, American Airlines, Yahoo! Japan. Och så får jag reda på att Ignite inte bara är implementerat i Sberbank, utan SberTech-teamet skickar sina medarbetare till själva Ignite-teamet för att förfina produkten. Det här är helt fängslande och jag är redo att ta Ignite.

Det är helt oklart varför, jag tittar på den femte punkten.

Hasselcast

Jag går till sidan Hasselcast, läsa. Och det visar sig att den snabbaste lösningen för distribuerad caching är Hazelcast. Det är storleksordningar snabbare än alla andra lösningar och i allmänhet är det ledande inom området för in-memory data grid. Mot denna bakgrund är att ta något annat inte att respektera sig själv. Den använder också redundant datalagring för kontinuerlig drift av klustret utan dataförlust.

Det var allt, jag är redo att ta Hazelcast.

jämförelse

Men om man tittar så beskrivs alla fem kandidaterna på ett sådant sätt att var och en av dem är bäst. Hur ska man välja? Vi kan se vilken som är mest populär, leta efter jämförelser och huvudvärken försvinner.

Vi hittar en sådan här översikt, välj våra 5 system.

Här är de sorterade: Redis ligger i topp, Hazelcast ligger på andra plats, Tarantool och Ignite vinner popularitet, EhCache har varit och förblir densamma.

Men låt oss titta på beräkningsmetod: länkar till hemsidor, allmänt intresse för systemet, jobberbjudanden - bra! Det vill säga, när mitt system misslyckas, kommer jag att säga: "Nej, det är pålitligt! Det finns många jobberbjudanden..." En sådan enkel jämförelse räcker inte.

Alla dessa system är inte bara cachningssystem. De har också en hel del funktionalitet, bland annat när data inte pumpas till klienten för bearbetning, men vice versa: koden som behöver exekveras på datan flyttas till servern, exekveras där och resultatet returneras. Och de betraktas inte så ofta som ett separat system för cachning.

Okej, låt oss inte ge upp, låt oss hitta en direkt jämförelse av systemen. Låt oss ta de två översta alternativen - Redis och Hazelcast. Vi är intresserade av hastighet, och vi kommer att jämföra dem baserat på denna parameter.

Hz vs Redis

Vi hittar detta jämförelse:


Blått är Redis, rött är Hazelcast. Hazelcast vinner överallt, och det finns ett skäl till detta: den är flertrådad, mycket optimerad, varje tråd fungerar med sin egen partition, så det finns ingen blockering. Och Redis är entrådig, den drar inte nytta av moderna flerkärniga processorer. Hazelcast har asynkron I/O, Redis-Jedis har blockerande uttag. När allt kommer omkring använder Hazelcast ett binärt protokoll, och Redis är textcentrerad, vilket betyder att det är ineffektivt.

För säkerhets skull, låt oss vända oss till en annan källa för jämförelse. Vad kommer han att visa oss?

Redis vs Hz

annan jämförelse:


Här är tvärtom Redis rött. Det vill säga att Redis överträffar Hazelcast när det gäller prestanda. Hazelcast vann den första jämförelsen, Redis vann den andra. Precis här förklarade mycket exakt varför Hazelcast vann den tidigare jämförelsen.

Det visar sig att resultatet av den första faktiskt var riggat: Redis togs i baslådan och Hazelcast skräddarsyddes för ett testfall. Sedan visar det sig: för det första kan vi inte lita på någon, och för det andra, när vi äntligen väljer ett system, måste vi fortfarande konfigurera det korrekt. Dessa inställningar inkluderar dussintals, nästan hundratals parametrar.

Skakar flaskan

Och jag kan förklara hela processen som vi nu har gjort med följande metafor: "Skaka flaskan." Det vill säga, nu behöver du inte programmera, nu är det viktigaste att kunna läsa stackoverflow. Och jag har en person i mitt team, ett proffs, som arbetar precis så här i kritiska ögonblick.

Vad gör han? Han ser en trasig sak, ser ett stackspår, tar några ord från det (vilka är hans expertis i programmet), söker på Google, hittar stackoverflow bland svaren. Utan att läsa, utan att tänka, bland svaren på frågan väljer han något som mest liknar meningen "gör det och det" (att välja ett sådant svar är hans talang, eftersom det inte alltid är svaret som fick flest likes), gäller , utseende: om något har förändrats, så bra. Om det inte har ändrats, rulla tillbaka det. Och upprepa start-kontroll-sökning. Och på detta intuitiva sätt ser han till att koden fungerar efter en tid. Han vet inte varför, han vet inte vad han gjorde, han kan inte förklara. Men! Denna infektion fungerar. Och "branden är släckt". Nu ska vi ta reda på vad vi gjorde. När programmet fungerar är det en storleksordning lättare. Och det sparar mycket tid.

Denna metod förklaras mycket väl med detta exempel.

Det var en gång väldigt populärt att samla en segelbåt på flaska. Samtidigt är segelbåten stor och ömtålig, och flaskans hals är väldigt smal, det är omöjligt att trycka in den. Hur sätter man ihop det?

Det finns en sådan metod, mycket snabb och mycket effektiv.

Skeppet består av en massa småsaker: pinnar, rep, segel, lim. Vi lägger allt detta i en flaska.
Vi tar flaskan med båda händerna och börjar skaka. Vi skakar och skakar henne. Och oftast visar det sig vara komplett skräp förstås. Men ibland. Ibland visar det sig vara ett skepp! Närmare bestämt något som liknar ett fartyg.

Vi visar det här något för någon: "Seryoga, ser du!?" Och faktiskt, på långt håll ser det ut som ett skepp. Men detta kan inte tillåtas fortsätta.

Det finns ett annat sätt. De används av mer avancerade killar, som hackare.

Jag gav den här killen en uppgift, han gjorde allt och gick. Och du ser - det ser ut som det är gjort. Och efter ett tag, när koden måste slutföras, börjar detta på grund av honom... Det är bra att han redan har lyckats springa långt bort. Det här är killarna som, med exemplet med en flaska, kommer att göra detta: du ser, var botten är, böjs glaset. Och det är inte helt klart om det är transparent eller inte. Sedan skär "hackerna" av den här botten, sätter in ett skepp där, limma sedan fast botten igen, och det är som om det är så det ska vara.

Ur synvinkeln att ställa in problemet verkar allt vara korrekt. Men med fartyg som exempel: varför göra det här fartyget överhuvudtaget, vem behöver det egentligen? Det ger ingen funktionalitet. Vanligtvis är sådana fartyg gåvor till mycket högt uppsatta personer, som lägger det på en hylla ovanför dem, som någon form av symbol, som ett tecken. Och om en sådan person, chef för ett stort företag eller en högt uppsatt tjänsteman, hur kommer flaggan att stå för ett sådant hack, vars hals är avskuren? Det vore bättre om han aldrig visste om det. Så, hur gör de dessa fartyg som kan ges till en viktig person?

Den enda nyckelplatsen som du egentligen inte kan göra något åt ​​är kroppen. Och fartygets skrov passar rakt in i halsen. Medan skeppet är monterat utanför flaskan. Men det är inte bara att montera ett skepp, det är ett riktigt smyckeshantverk. Speciella spakar läggs till komponenterna som sedan gör att de kan lyftas. Till exempel viks seglen, förs försiktigt in, och sedan, med hjälp av pincett, dras och höjs de mycket exakt, med precision. Resultatet är ett konstverk som kan begåvas med gott samvete och stolthet.

Och om vi vill att projektet ska bli framgångsrikt måste det finnas minst en juvelerare i laget. Någon som bryr sig om produktens kvalitet och tar hänsyn till alla aspekter, utan att offra något, även i stunder av stress, när omständigheterna kräver att man gör det brådskande på bekostnad av det viktiga. Alla framgångsrika projekt som är hållbara, som har bestått tidens tand, bygger på denna princip. Det är något väldigt exakt och unikt med dem, något som utnyttjar alla tillgängliga möjligheter. I exemplet med skeppet i flaskan spelas det upp att skeppets skrov passerar genom halsen.

För att återgå till uppgiften att välja vår cachingserver, hur kan denna metod tillämpas? Jag erbjuder det här alternativet att välja bland alla system som finns - skaka inte flaskan, välj inte, utan titta på vad de har i princip, vad du ska titta efter när du väljer ett system.

Var man ska leta efter flaskhals

Låt oss försöka att inte skaka flaskan, inte gå igenom allt som finns där en efter en, men låt oss se vilka problem som kommer att uppstå om vi plötsligt, för vår uppgift, designar ett sådant system själva. Naturligtvis kommer vi inte att montera cykeln, men vi kommer att använda det här diagrammet för att hjälpa oss att ta reda på vilka punkter vi ska vara uppmärksamma på i produktbeskrivningarna. Låt oss skissera ett sådant diagram.

Om systemet är distribuerat kommer vi att ha flera servrar (6). Låt oss säga att det finns fyra (det är bekvämt att placera dem på bilden, men det kan naturligtvis vara så många som du vill). Om servrarna finns på olika noder betyder det att de alla kör någon kod som ansvarar för att dessa noder bildar ett kluster och i händelse av ett avbrott ansluter och känner igen varandra.

Vi behöver också kodlogik (2), som egentligen handlar om cachning. Klienter interagerar med den här koden via något API. Klientkod (1) kan antingen finnas inom samma JVM eller komma åt den över nätverket. Logiken som implementeras inuti är beslutet om vilka objekt som ska lämnas i cachen och vilka som ska kastas ut. Vi använder minne (3) för att lagra cachen, men vid behov kan vi spara en del av datan på disk (4).

Låt oss se i vilka delar belastningen kommer att ske. Faktiskt kommer varje pil och varje nod att laddas. För det första, mellan klientkoden och api:n, om detta är nätverkskommunikation, kan sättningen vara ganska märkbar. För det andra, inom ramen för själva api:n - om vi överdriver det med komplex logik kan vi stöta på problem med CPU:n. Och det skulle vara trevligt om logiken inte slösade tid på minnet. Och det återstår interaktion med filsystemet - i den vanliga versionen är detta serialisera / återställa och skriva / läsa.

Nästa är interaktion med klustret. Troligtvis kommer det att vara i samma system, men det kan vara separat. Här måste du också ta hänsyn till överföringen av data till den, hastigheten för dataserialisering och interaktioner mellan klustret.

Nu kan vi å ena sidan föreställa oss "vilka växlar kommer att vända" i cachesystemet när vi behandlar förfrågningar från vår kod, och å andra sidan kan vi uppskatta vilka och hur många förfrågningar vår kod kommer att generera för detta system. Detta räcker för att göra ett mer eller mindre sobert val - att välja ett system för vårt användningsfall.

Hasselcast

Låt oss se hur man tillämpar denna nedbrytning på vår lista. Till exempel Hazelcast.

För att lägga/ta data från Hazelcast kommer klientkoden åt (1) api. Hz låter dig köra servern som inbäddad, och i det här fallet är åtkomst till api:n ett metodanrop inuti JVM, vilket kan anses vara gratis.

För att logiken i (2) ska fungera, förlitar sig Hz på hashen för byte-arrayen för den serialiserade nyckeln - det vill säga, nyckeln kommer att serialiseras i alla fall. Detta är oundvikligt overhead för Hz.
Vräkningsstrategier implementeras väl, men för speciella fall kan du lägga till egna. Du behöver inte oroa dig för den här delen.

Förråd (4) kan anslutas. Bra. Interaktion (5) för inbäddad kan betraktas som omedelbar. Datautbyte mellan noder i klustret (6) - ja, det finns. Detta är en investering i feltolerans på bekostnad av hastighet. Hz-funktionen Near-cache låter dig sänka priset - data som tas emot från andra noder i klustret kommer att cachelagras.

Vad kan man göra under sådana förhållanden för att öka hastigheten?

Till exempel, för att undvika serialisering av nyckeln i (2) - bifoga en annan cache ovanpå Hazelcast, för de hetaste data. Sportmaster valde koffein för detta ändamål.

För vridning på nivå (6) erbjuder Hz två typer av lagring: IMap och ReplicatedMap.


Det är värt att nämna hur Hazelcast hamnade i Sportmaster-teknologistacken.

2012, när vi arbetade med den allra första piloten av den framtida sajten, var det Hazelcast som visade sig vara den första länken som sökmotorn returnerade. Bekantskapen började "första gången" - vi hänfördes av det faktum att bara två timmar senare, när vi skruvade in Hz i systemet, fungerade det. Och det fungerade bra. Vid slutet av dagen hade vi genomfört ett antal tester och var nöjda. Och denna kraftreserve räckte för att övervinna överraskningarna som Hz slängde upp med tiden. Nu har Sportmaster-teamet ingen anledning att överge Hazelcast.

Men sådana argument som "den första länken i sökmotorn" och "HelloWorld var snabbt sammansatt" är naturligtvis ett undantag och ett inslag i det ögonblick då valet ägde rum. De riktiga testerna för det valda systemet börjar med lanseringen i produktion, och det är i detta skede du bör vara uppmärksam när du väljer vilket system som helst, inklusive cache. Egentligen kan vi i vårt fall säga att vi valde Hazelcast av en slump, men så visade det sig att vi valde rätt.

För produktion, mycket viktigare: övervakning, hantering av fel på enskilda noder, datareplikering, kostnad för skalning. Det vill säga, det är värt att uppmärksamma de uppgifter som kommer att uppstå under underhållet av systemet - när belastningen är tiotals gånger högre än planerat, när vi av misstag laddar upp något på fel plats, när vi behöver rulla ut en ny version av koden, ersätt data och gör det obemärkt för kunderna.

För alla dessa krav passar Hazelcast verkligen räkningen.

Fortsättning följer

Men Hazelcast är inget universalmedel. Under 2017 valde vi Hazelcast för admin-cachen, helt enkelt baserat på goda intryck från tidigare erfarenheter. Detta spelade en nyckelroll i ett mycket grymt skämt, på grund av vilket vi befann oss i en svår situation och "heroiskt" kom oss ur det i 60 dagar. Men mer om det i nästa del.

Under tiden... Glad ny kod!

Källa: will.com