Hallo! Mijn naam is Alexey Pyankov, ik ben een ontwikkelaar bij het bedrijf Sportmaster. In dat Ik vertelde hoe het werk aan de Sportmaster-website in 2012 begon, welke initiatieven we erin slaagden “door te drukken” en vice versa, welke hark we verzamelden.
Vandaag wil ik gedachten delen die volgen op een ander onderwerp: het kiezen van een cachingsysteem voor de Java-backend in het sitebeheergebied. Dit plot heeft voor mij een speciale betekenis - hoewel het verhaal zich slechts 2 maanden afspeelde, werkten we gedurende deze 60 dagen 12-16 uur en zonder een enkele vrije dag. Ik had nooit gedacht of gedacht dat het mogelijk was om zo hard te werken.
Daarom heb ik de tekst in twee delen gesplitst om deze niet volledig te laden. Integendeel, het eerste deel zal heel licht zijn: voorbereiding, introductie, enkele overwegingen over wat caching is. Als je al een ervaren ontwikkelaar bent of met caches hebt gewerkt, zal er technisch gezien waarschijnlijk niets nieuws in dit artikel staan. Maar voor een junior kan zo'n kleine recensie hem vertellen in welke richting hij moet kijken als hij zich op zo'n kruispunt bevindt.
Toen de nieuwe versie van de Sportmaster-website in productie werd genomen, werden de gegevens ontvangen op een manier die, op zijn zachtst gezegd, niet erg handig was. De basis waren tabellen die waren voorbereid voor de vorige versie van de site (Bitrix), die in ETL moesten worden getrokken, naar een nieuwe vorm moesten worden gebracht en verrijkt met verschillende kleine dingen uit nog een tiental systemen. Om een nieuwe foto of productbeschrijving op de site te laten verschijnen, moest je wachten tot de volgende dag - updates alleen 's nachts, één keer per dag.
In het begin waren er zoveel zorgen vanaf de eerste weken na de ingebruikname dat dergelijke ongemakken voor contentmanagers een kleinigheid waren. Maar zodra alles tot rust was gekomen, ging de ontwikkeling van het project door - een paar maanden later, begin 2015, begonnen we het beheerderspaneel actief te ontwikkelen. In 2015 en 2016 gaat alles goed, we geven regelmatig vrij, het beheerderspaneel beslaat steeds meer van de gegevensvoorbereiding en we bereiden ons voor op het feit dat ons team binnenkort het belangrijkste en meest complexe zal worden toevertrouwd: het product circuit (volledige voorbereiding en onderhoud van gegevens over alle producten). Maar in de zomer van 2017, vlak voor de lancering van het grondstoffencircuit, zal het project zich in een zeer moeilijke situatie bevinden - juist vanwege problemen met caching. Over deze aflevering wil ik het hebben in het tweede deel van deze tweedelige publicatie.
Maar in dit bericht zal ik van ver beginnen, ik zal enkele gedachten presenteren - ideeën over caching, wat een goede stap zou zijn om doorheen te scrollen vóór een groot project.
Wanneer er een cachetaak plaatsvindt
De cachetaak verschijnt niet zomaar. Wij zijn ontwikkelaars die een softwareproduct schrijven en willen dat er veel vraag naar is. Als er veel vraag naar het product is en het succesvol is, zullen er gebruikers komen. En er komen er steeds meer. En dan zijn er veel gebruikers en dan wordt het product hoogbeladen.
In de eerste fasen denken we niet na over optimalisatie en codeprestaties. Het belangrijkste is functionaliteit, snel een pilot uitrollen en hypotheses testen. En als de belasting toeneemt, pompen we het strijkijzer op. We verhogen het twee of drie keer, vijf keer, misschien tien keer. Ergens hier laten de financiën het niet meer toe. Hoe vaak zal het aantal gebruikers toenemen? Het zal niet zo zijn als 10-2-5, maar als het lukt, zal het 10-100 tot 1000 duizend keer zijn. Dat wil zeggen dat u vroeg of laat aan optimalisatie zult moeten doen.
Laten we zeggen dat een deel van de code (laten we dit een functie noemen) onfatsoenlijk lang duurt, en we willen de uitvoeringstijd verkorten. Een functie kan toegang tot een database zijn, of de uitvoering van een complexe logica. Het belangrijkste is dat de uitvoering ervan lang duurt. Hoeveel kunt u de uitvoeringstijd verkorten? Binnen de limiet kun je het terugbrengen tot nul, niet verder. Hoe kunt u de uitvoeringstijd tot nul terugbrengen? Antwoord: elimineer de uitvoering helemaal. Geef in plaats daarvan het resultaat onmiddellijk terug. Hoe kun je het resultaat achterhalen? Antwoord: bereken het of kijk ergens. Het duurt lang om te berekenen. En spioneren is bijvoorbeeld het resultaat onthouden dat de functie de laatste keer opleverde toen deze met dezelfde parameters werd aangeroepen.
Dat wil zeggen dat de implementatie van de functie voor ons niet belangrijk is. Het volstaat om te weten van welke parameters het resultaat afhangt. Als de parameterwaarden vervolgens worden weergegeven in de vorm van een object dat als sleutel in een bepaalde opslag kan worden gebruikt, kan het resultaat van de berekening worden opgeslagen en uitgelezen de volgende keer dat het wordt geopend. Als dit schrijven en lezen van het resultaat sneller gaat dan het uitvoeren van de functie, hebben we winst in termen van snelheid. Het winstbedrag kan 100, 1000 en 100 duizend keer bedragen (10^5 is eerder een uitzondering, maar in het geval van een tamelijk achterblijvende basis is het heel goed mogelijk).
Basisvereisten voor een cachingsysteem
Het eerste dat een vereiste kan worden voor een cachingsysteem is een hoge leessnelheid en, in iets mindere mate, schrijfsnelheid. Dat is waar, maar alleen totdat we het systeem in productie nemen.
Laten we deze zaak spelen.
Laten we zeggen dat we de huidige belasting van hardware hebben voorzien en nu geleidelijk caching introduceren. Het aantal gebruikers groeit een beetje, de belasting groeit - we voegen wat caches toe, schroeven het hier en daar in. Dit gaat nog een tijdje door, en nu worden zware functies praktisch niet meer aangeroepen - de volledige hoofdbelasting valt op de cache. Het aantal gebruikers is in deze periode N keer toegenomen.
En als de initiële levering van hardware 2-5 keer zou kunnen zijn, dan zouden we met behulp van de cache de prestaties met een factor 10 kunnen verbeteren of, in een goed geval, met een factor 100, op sommige plaatsen misschien met een factor van 1000. Dat wil zeggen, op dezelfde hardware verwerken we 100 keer meer verzoeken. Geweldig, je verdient de peperkoek!
Maar nu, op een mooi moment, crashte het systeem bij toeval en stortte de cache in. Niets bijzonders - de cache is immers gekozen op basis van de eis "hoge lees- en schrijfsnelheid, de rest doet er niet toe."
Ten opzichte van de startbelasting was onze ijzerreserve 2-5 keer, en de belasting nam gedurende deze tijd 10-100 keer toe. Met behulp van de cache hebben we oproepen voor zware functies geëlimineerd en daarom werkte alles. En nu, hoe vaak zal ons systeem vertragen zonder cache? Wat zal er met ons gebeuren? Het systeem zal vallen.
Zelfs als onze cache niet is gecrasht, maar slechts een tijdje is gewist, moet deze worden opgewarmd, en dit zal enige tijd duren. En gedurende deze tijd zal de grootste last op functionaliteit vallen.
Conclusie: zwaarbelaste productieprojecten vereisen een cachingsysteem niet alleen om hoge lees- en schrijfsnelheden te hebben, maar ook om de gegevensveiligheid en weerstand tegen fouten te garanderen.
De kwelling van kiezen
In een project met een beheerderspaneel ging de keuze als volgt: eerst installeerden we Hazelcast, omdat We kenden dit product al uit de ervaring van de hoofdsite. Maar hier bleek deze keuze niet succesvol: volgens ons belastingprofiel is Hazelcast niet alleen traag, maar ook vreselijk traag. En op dat moment hadden we ons al aangemeld voor de releasedatum.
Spoiler: hoe precies de omstandigheden zich hebben ontwikkeld waardoor we zo’n grote deal hebben gemist en in een acute en gespannen situatie terecht zijn gekomen – dat vertel ik je in het tweede deel – en hoe we daar terecht zijn gekomen en hoe we eruit zijn gekomen. Maar nu - ik zal alleen zeggen dat het veel stress was, en "om na te denken - op de een of andere manier kan ik niet denken, we schudden de fles." “Shaking the bottle” is ook een spoiler, daarover later meer.
Wat we gedaan hebben:
- We maken een lijst van alle systemen die Google en StackOverflow voorstellen. Iets meer dan 30
- Wij schrijven tests met een voor productie typische belasting. Om dit te doen, hebben we gegevens vastgelegd die door het systeem gaan in een productieomgeving - een soort sniffer voor gegevens die niet op het netwerk staan, maar binnen het systeem. Precies deze gegevens zijn gebruikt in de tests.
- Met het hele team selecteert iedereen het volgende systeem uit de lijst, configureert het en voert tests uit. Hij doorstaat de test niet, hij draagt de last niet – we gooien hem weg en gaan door naar de volgende in de rij.
- Op het 17e systeem werd duidelijk dat alles hopeloos was. Stop met het schudden van de fles, het is tijd om serieus na te denken.
Maar dit is een optie als u een systeem moet kiezen dat "de snelheid doorbreekt" in vooraf voorbereide tests. Wat als zulke testen nog niet bestaan en je snel wilt kiezen?
Laten we deze optie modelleren (het is moeilijk voor te stellen dat een midden+-ontwikkelaar in een vacuüm leeft en op het moment van selectie zijn voorkeur nog niet heeft geformaliseerd over welk product hij als eerste wil proberen - daarom is verdere redenering meer een theoreticus/filosofie/ over een junior).
Nadat we de vereisten hebben bepaald, beginnen we met het selecteren van een kant-en-klare oplossing. Waarom het wiel opnieuw uitvinden: we gaan voor een kant-en-klaar cachingsysteem.
Als je net begint en het googlet, geef of neem dan de bestelling, maar over het algemeen zullen de richtlijnen als volgt zijn. Allereerst kom je Redis tegen, het is overal te horen. Dan zul je ontdekken dat EhCache het oudste en meest beproefde systeem is. Vervolgens zullen we schrijven over Tarantool, een binnenlandse ontwikkeling die een uniek aspect van de oplossing heeft. En ook Ignite, omdat het inmiddels steeds populairder wordt en de steun geniet van SberTech. Tenslotte is er ook Hazelcast, omdat het in de zakenwereld vaak voorkomt bij grote bedrijven.
De lijst is niet uitputtend; er zijn tientallen systemen. En we zullen maar één ding verpesten. Laten we de 5 geselecteerde systemen voor de “schoonheidswedstrijd” nemen en een selectie maken. Wie wordt de winnaar?
Redis
We lezen wat ze schrijven op de officiële website.
- open source-project. Biedt gegevensopslag in het geheugen, de mogelijkheid om op schijf op te slaan, automatisch partitioneren, hoge beschikbaarheid en herstel na netwerkstoringen.
Het lijkt erop dat alles in orde is, je kunt het pakken en vastschroeven - alles wat je nodig hebt, doet het. Maar laten we voor de lol eens kijken naar de andere kandidaten.
EhCache
- “de meest gebruikte cache voor Java” (vertaling van de slogan van de officiële website). Ook open source. En dan begrijpen we dat Redis niet voor Java is, maar algemeen, en om ermee te communiceren heb je een wrapper nodig. En EhCache zal handiger zijn. Wat belooft het systeem nog meer? Betrouwbaarheid, bewezen, volledige functionaliteit. Nou ja, het is ook de meest voorkomende. En slaat terabytes aan gegevens op in de cache.
Redis is vergeten, ik ben klaar om EhCache te kiezen.
Maar een gevoel van patriottisme dwingt me om te zien wat er goed is aan Tarantool.
Tarantool
- voldoet aan het predicaat “Real-time data-integratieplatform”. Het klinkt erg ingewikkeld, dus we lezen de pagina in detail en vinden een luide verklaring: "Slaat 100% van de gegevens op in RAM." Dit zou vragen moeten oproepen; er kunnen immers veel meer gegevens zijn dan geheugen. De verklaring is dat dit betekent dat Tarantool geen serialisatie uitvoert om gegevens vanuit het geheugen naar schijf te schrijven. In plaats daarvan maakt het gebruik van functies op laag niveau van het systeem, waarbij het geheugen eenvoudigweg wordt toegewezen aan een bestandssysteem met zeer goede I/O-prestaties. Over het algemeen hebben ze iets geweldigs en cools gedaan.
Laten we eens kijken naar de implementaties: Mail.ru corporate snelweg, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...
Mochten er nog twijfels zijn over Tarantool, dan maakt de implementatiecasus bij Mastercard mij af. Ik neem Tarantool.
Maar in ieder geval…
Toepassen
…is er nog meer , wordt aangekondigd als een “in-memory computerplatform...in-memory snelheden op petabytes aan gegevens.” Er zijn hier ook veel voordelen: gedistribueerde in-memory cache, de snelste sleutelwaarde-opslag en cache, horizontale schaling, hoge beschikbaarheid, strikte integriteit. Over het algemeen blijkt dat Ignite de snelste is.
Implementaties: Sberbank, American Airlines, Yahoo! Japan. En dan kom ik erachter dat Ignite niet alleen in Sberbank is geïmplementeerd, maar dat het SberTech-team zijn mensen naar het Ignite-team zelf stuurt om het product te verfijnen. Dit is volkomen boeiend en ik ben klaar om Ignite te nemen.
Het is volkomen onduidelijk waarom, ik kijk naar het vijfde punt.
Hazelcast
Ik ga naar de site , lezing. En het blijkt dat Hazelcast de snelste oplossing voor gedistribueerde caching is. Het is een orde van grootte sneller dan alle andere oplossingen en is over het algemeen toonaangevend op het gebied van in-memory data grid. Tegen deze achtergrond betekent iets anders nemen niet hetzelfde als respect voor jezelf. Het maakt ook gebruik van redundante gegevensopslag voor een continue werking van het cluster zonder gegevensverlies.
Dat is alles, ik ben klaar om Hazelcast te nemen.
Сравнение
Maar als je kijkt, worden alle vijf de kandidaten zo beschreven dat ze allemaal de beste zijn. Hoe te kiezen? We kunnen zien welke het populairst is, zoeken naar vergelijkingen en de hoofdpijn zal verdwijnen.
Wij vinden er zo één , kies onze 5 systemen.
Hier zijn ze gesorteerd: Redis staat bovenaan, Hazelcast staat op de tweede plaats, Tarantool en Ignite winnen aan populariteit, EhCache is en blijft hetzelfde.
Maar laten we eens kijken : links naar websites, algemene interesse in het systeem, vacatures - geweldig! Dat wil zeggen, als mijn systeem faalt, zal ik zeggen: “Nee, het is betrouwbaar! Er zijn veel vacatures..." Zo'n simpele vergelijking volstaat niet.
Al deze systemen zijn niet alleen caching-systemen. Ze hebben ook veel functionaliteit, ook wanneer gegevens niet naar de client worden gepompt voor verwerking, maar omgekeerd: de code die op de gegevens moet worden uitgevoerd, wordt naar de server verplaatst, wordt daar uitgevoerd en het resultaat wordt geretourneerd. En ze worden niet zo vaak beschouwd als een afzonderlijk systeem voor caching.
Oké, laten we niet opgeven, laten we een directe vergelijking van de systemen zoeken. Laten we de twee beste opties nemen: Redis en Hazelcast. We zijn geïnteresseerd in snelheid en we zullen ze vergelijken op basis van deze parameter.
Hz versus Redis
Wij vinden dit :
Blauw is Redis, rood is Hazelcast. Hazelcast wint overal, en daar is een reden voor: het is multi-threaded, sterk geoptimaliseerd, elke thread werkt met zijn eigen partitie, dus er zijn geen blokkeringen. En Redis is single-threaded; het profiteert niet van moderne multi-core CPU's. Hazelcast heeft asynchrone I/O, Redis-Jedis heeft blokkerende sockets. Hazelcast gebruikt tenslotte een binair protocol en Redis is tekstgericht, wat betekent dat het inefficiënt is.
Laten we voor het geval een andere vergelijkingsbron gebruiken. Wat zal hij ons laten zien?
Redis versus Hz
Ander :
Hier is rood daarentegen Redis. Dat wil zeggen, Redis presteert beter dan Hazelcast qua prestaties. Hazelcast won de eerste vergelijking, Redis won de tweede. legde heel precies uit waarom Hazelcast de vorige vergelijking won.
Het blijkt dat het resultaat van de eerste feitelijk vervalst was: Redis werd in de basisdoos genomen en Hazelcast werd op maat gemaakt voor een testcase. Dan blijkt: ten eerste kunnen we niemand vertrouwen, en ten tweede, als we uiteindelijk een systeem kiezen, moeten we het nog steeds correct configureren. Deze instellingen omvatten tientallen, bijna honderden parameters.
Het schudden van de fles
En ik kan het hele proces dat we nu hebben gedaan uitleggen met de volgende metafoor: ‘Het schudden van de fles.’ Dat wil zeggen, nu hoef je niet te programmeren, nu is het belangrijkste om StackOverflow te kunnen lezen. En ik heb iemand in mijn team, een professional, die op kritieke momenten precies zo werkt.
Wat is hij aan het doen? Hij ziet een kapot ding, ziet een stacktrace, haalt er een paar woorden uit (welke zijn zijn expertise in het programma), zoekt op Google, vindt stackoverflow tussen de antwoorden. Zonder te lezen, zonder na te denken, kiest hij tussen de antwoorden op de vraag iets dat het meest lijkt op de zin "doe dit en dat" (het kiezen van een dergelijk antwoord is zijn talent, omdat het niet altijd het antwoord is dat de meeste likes kreeg), geldt, ziet eruit: als er iets is veranderd, dan is dat prima. Als het niet is veranderd, draait u het terug. En herhaal de start-check-zoekopdracht. En op deze intuïtieve manier zorgt hij ervoor dat de code na verloop van tijd werkt. Hij weet niet waarom, hij weet niet wat hij heeft gedaan, hij kan het niet uitleggen. Maar! Deze infectie werkt. En “het vuur is gedoofd.” Laten we nu eens kijken wat we hebben gedaan. Als het programma werkt, is het een orde van grootte eenvoudiger. En het bespaart veel tijd.
Deze methode wordt heel goed uitgelegd met dit voorbeeld.
Ooit was het heel populair om een zeilboot in een fles te verzamelen. Tegelijkertijd is de zeilboot groot en kwetsbaar en is de hals van de fles erg smal, het is onmogelijk om hem naar binnen te duwen. Hoe moet je het monteren?
Er is zo'n methode, heel snel en zeer effectief.
Het schip bestaat uit een heleboel kleine dingen: stokken, touwen, zeilen, lijm. Dit alles stoppen we in een fles.
We pakken de fles met beide handen en beginnen te schudden. We schudden en schudden haar. En meestal blijkt het natuurlijk complete rommel te zijn. Maar soms. Soms blijkt het een schip te zijn! Om precies te zijn, iets dat lijkt op een schip.
We laten dit iets aan iemand zien: “Seryoga, zie je het!?” En inderdaad, van veraf lijkt het op een schip. Maar dit mag niet blijven voortduren.
Er is een andere manier. Ze worden gebruikt door meer geavanceerde jongens, zoals hackers.
Ik gaf deze man een taak, hij deed alles en vertrok. En je kijkt - het lijkt erop dat het klaar is. En na een tijdje, als de code moet worden afgerond, begint dit door hem... Het is goed dat hij er al in is geslaagd ver weg te rennen. Dit zijn de jongens die, aan de hand van het voorbeeld van een fles, dit gaan doen: zie je, waar de bodem is, buigt het glas. En het is niet helemaal duidelijk of het transparant is of niet. Vervolgens sneden de ‘hackers’ deze bodem af, plaatsten er een schip in en lijmden de bodem er weer op, en het is alsof het zo hoort te zijn.
Vanuit het oogpunt van het instellen van het probleem lijkt alles correct te zijn. Maar met schepen als voorbeeld: waarom zou je dit schip überhaupt maken, wie heeft het überhaupt nodig? Het biedt geen enkele functionaliteit. Meestal zijn dergelijke schepen een geschenk aan zeer hooggeplaatste mensen, die het op een plank boven hen plaatsen, als een soort symbool, als teken. En als zo iemand, het hoofd van een groot bedrijf of een hoge functionaris, hoe zal de vlag dan staan voor zo'n hack waarvan de nek is afgesneden? Het zou beter zijn als hij er nooit van wist. Dus, hoe maken ze uiteindelijk deze schepen die aan een belangrijk persoon kunnen worden gegeven?
De enige sleutelplek waar je echt niets aan kunt doen, is het lichaam. En de scheepsromp past precies in de nek. Terwijl het schip buiten de fles wordt gemonteerd. Maar het is niet alleen het in elkaar zetten van een schip, het is een echt sieradenambacht. Er worden speciale hendels aan de componenten toegevoegd, waardoor ze vervolgens kunnen worden opgetild. De zeilen worden bijvoorbeeld opgevouwen, voorzichtig naar binnen gebracht en vervolgens met behulp van een pincet heel precies en met precisie omhoog getrokken en gehesen. Het resultaat is een kunstwerk dat met een zuiver geweten en trots kan worden geschonken.
En als we willen dat het project slaagt, moet er minstens één juwelier in het team zitten. Iemand die geeft om de kwaliteit van het product en rekening houdt met alle aspecten, zonder iets op te offeren, zelfs in momenten van stress, wanneer de omstandigheden vereisen dat het dringende ten koste gaat van het belangrijke. Alle succesvolle projecten die duurzaam zijn, die de tand des tijds hebben doorstaan, zijn op dit principe gebouwd. Er is iets heel preciess en unieks aan, iets dat gebruik maakt van alle beschikbare mogelijkheden. In het voorbeeld met het schip in de fles wordt uitgespeeld dat de romp van het schip door de nek gaat.
Terugkomend op de taak van het kiezen van onze caching-server: hoe kan deze methode worden toegepast? Ik bied deze mogelijkheid om te kiezen uit alle systemen die er zijn: schud niet met de fles, kies niet, maar kijk naar wat ze in principe hebben, waar je op moet letten bij het kiezen van een systeem.
Waar te zoeken naar knelpunten
Laten we proberen de fles niet te schudden, niet alles wat er is één voor één door te nemen, maar laten we eens kijken welke problemen zich zullen voordoen als we plotseling, voor onze taak, zelf zo'n systeem ontwerpen. Uiteraard gaan we de fiets niet in elkaar zetten, maar we gebruiken dit schema om uit te zoeken waar we op moeten letten bij de productbeschrijvingen. Laten we zo'n diagram schetsen.
Als het systeem gedistribueerd is, hebben we meerdere servers (6). Laten we zeggen dat het er vier zijn (het is handig om ze op de foto te plaatsen, maar het kunnen er natuurlijk zoveel zijn als je wilt). Als de servers zich op verschillende knooppunten bevinden, betekent dit dat ze allemaal een code uitvoeren die ervoor zorgt dat deze knooppunten een cluster vormen en, in het geval van een storing, verbinding maken en elkaar herkennen.
We hebben ook codelogica (2) nodig, die eigenlijk over caching gaat. Klanten communiceren met deze code via een API. Clientcode (1) kan zich binnen dezelfde JVM bevinden of er toegang toe krijgen via het netwerk. De logica die binnenin wordt geïmplementeerd, is de beslissing welke objecten in de cache moeten blijven en welke moeten worden weggegooid. We gebruiken geheugen (3) om de cache op te slaan, maar indien nodig kunnen we een deel van de gegevens op schijf (4) opslaan.
Laten we eens kijken in welke delen de belasting zal optreden. Eigenlijk wordt elke pijl en elk knooppunt geladen. Ten eerste kan de verzakking tussen de clientcode en de API behoorlijk merkbaar zijn als dit netwerkcommunicatie is. Ten tweede, binnen het raamwerk van de API zelf: als we het overdrijven met complexe logica, kunnen we problemen tegenkomen met de CPU. En het zou fijn zijn als logica geen tijd zou verspillen aan het geheugen. En er blijft interactie met het bestandssysteem - in de gebruikelijke versie is dit serialiseren / herstellen en schrijven / lezen.
Het volgende is de interactie met het cluster. Hoogstwaarschijnlijk zal dit in hetzelfde systeem zijn, maar het kan ook afzonderlijk zijn. Hier moet je ook rekening houden met de gegevensoverdracht ernaartoe, de snelheid van dataserialisatie en interacties tussen het cluster.
Nu kunnen we ons enerzijds voorstellen “welke versnellingen zullen draaien” in het cachesysteem bij het verwerken van verzoeken van onze code, en anderzijds kunnen we inschatten welke en hoeveel verzoeken onze code voor dit systeem zal genereren. Dit is voldoende om een min of meer nuchtere keuze te maken: een systeem te kiezen voor onze gebruikssituatie.
Hazelcast
Laten we eens kijken hoe we deze ontleding op onze lijst kunnen toepassen. Hazelcast bijvoorbeeld.
Om gegevens uit Hazelcast te halen/halen, heeft de clientcode toegang tot (1) de API. Met Hz kunt u de server als ingebed uitvoeren, en in dit geval is toegang tot de API een methodeaanroep binnen de JVM, die als gratis kan worden beschouwd.
Om de logica in (2) te laten werken, is Hz afhankelijk van de hash van de byte-array van de geserialiseerde sleutel - dat wil zeggen dat de sleutel hoe dan ook geserialiseerd zal zijn. Dit is onvermijdelijk overhead voor Hz.
Uitzettingsstrategieën worden goed geïmplementeerd, maar voor speciale gevallen kunt u uw eigen strategie toevoegen. Over dit onderdeel hoeft u zich geen zorgen te maken.
Opbergruimte (4) kan worden aangesloten. Geweldig. Interactie (5) voor embedded kan als onmiddellijk worden beschouwd. Gegevensuitwisseling tussen knooppunten in het cluster (6) - ja, het bestaat. Dit is een investering in fouttolerantie die ten koste gaat van de snelheid. Met de Hz-functie Near-cache kunt u de prijs verlagen: gegevens die worden ontvangen van andere knooppunten in het cluster worden in de cache opgeslagen.
Wat kan er onder dergelijke omstandigheden worden gedaan om de snelheid te verhogen?
Om bijvoorbeeld serialisatie van de sleutel in (2) te voorkomen, bevestigt u een andere cache bovenop Hazelcast, voor de populairste gegevens. Sportmaster heeft hiervoor Cafeïne gekozen.
Voor twisten op niveau (6) biedt Hz twee soorten opslag: IMap en ReplicatedMap.
Het is de moeite waard om te vermelden hoe Hazelcast in de Sportmaster-technologiestapel terechtkwam.
In 2012, toen we bezig waren met de allereerste pilot van de toekomstige site, bleek Hazelcast de eerste link te zijn die de zoekmachine retourneerde. De kennismaking begon "de eerste keer" - we waren gefascineerd door het feit dat het slechts twee uur later, toen we Hz in het systeem schroefden, werkte. En het werkte goed. Aan het einde van de dag hadden we een aantal tests voltooid en waren we tevreden. En deze reserve aan kracht was genoeg om de verrassingen te overwinnen die Hz in de loop van de tijd opleverde. Nu heeft het Sportmaster-team geen reden om Hazelcast in de steek te laten.
Maar argumenten als “de eerste link in de zoekmachine” en “HelloWorld was snel samengesteld” zijn uiteraard een uitzondering en een kenmerk van het moment waarop de keuze plaatsvond. De echte tests voor het gekozen systeem beginnen met de release in productie, en het is in dit stadium dat u op moet letten bij het kiezen van een systeem, inclusief cache. Eigenlijk kunnen we in ons geval zeggen dat we per ongeluk voor Hazelcast hebben gekozen, maar toen bleek dat we de juiste keuze hadden gemaakt.
Voor productie is veel belangrijker: monitoring, afhandeling van storingen op individuele knooppunten, datareplicatie, schaalkosten. Dat wil zeggen, het is de moeite waard om aandacht te besteden aan de taken die zullen optreden tijdens het onderhoud van het systeem - wanneer de belasting tientallen keren hoger is dan gepland, wanneer we per ongeluk iets op de verkeerde plaats uploaden, wanneer we een nieuwe versie moeten uitrollen van de code, vervang gegevens en doe het onopgemerkt voor klanten.
Voor al deze vereisten voldoet Hazelcast zeker aan de eisen.
Wordt vervolgd
Maar Hazelcast is geen wondermiddel. In 2017 kozen we Hazelcast voor de admin cache, simpelweg gebaseerd op goede indrukken uit eerdere ervaringen. Dit speelde een sleutelrol in een zeer wrede grap, waardoor we in een moeilijke situatie terechtkwamen en er 'heldhaftig' 60 dagen uit kwamen. Maar daarover meer in het volgende deel.
In de tussentijd... Fijne nieuwe code!
Bron: www.habr.com