Kuidas me Spordimeisters valisime vahemälu süsteemi. Osa 1

Tere! Minu nimi on Alexey Pjankov, olen arendaja ettevõttes Sportmaster. Sel postitusest jagasime, kuidas Sportmasteri veebisaidi arendamine 2012. aastal algas, millised algatused õnnestus "edendada" ja vastupidi, milliseid takistusi me kogusime.

Täna tahan jagada mõtteid, mis järgivad teistsugust teemat – jaotussüsteemi valimist Java-taustal saidi administreerimiseks. See teema on mulle eriti tähtis – kuigi lugu kestis vaid 2 kuud, töötasime nendel 60 päeval 12–16 tundi päevas ja ilma ühegi puhkepäevata. Ma pole kunagi varem mõelnud ega kujutlenud, et on võimalik nii palju töötada.

Seetõttu jagan teksti kaheks osaks, et mitte üle koormata. Vastupidi, esimene osa on väga kerge — ettevalmistus, sissejuhatus, mõned mõtted, mis on vahemälu. Kui olete juba kogenud arendaja või olete töötanud vahemäludega — tehnilisest küljest ei leia te tõenäoliselt selles artiklis midagi uut. Siiski võib noorele arendajale see väike ülevaade anda suuna, kuhu vaadata, kui ta satub sellisesse olukorda.

Kui Sportmasteri uus veebiversioon lansseeriti, toimusid andmete edastamine viisil, pehmelt öeldes, mitte väga mugavalt. Põhialuseks olid tabelid, mis olid ette valmistatud eelmise veebiversiooni (Bitrix) jaoks, mida tuli ETL-sse tõmmata, uue vormi saavutamiseks muudatusi teha ja rikastada erinevate „süžeede” abil veel kümnest süsteemist. Et uus pilt või tootekirjeldus veebilehele jõuaks, tuli oodata järgmise päevani — uuendamine toimus ainult öösel, üks kord päevas.

Alguses oli esimestel nädalatel pärast tootmisse minekut nii palju muresid, et sellised ebamugavused sisuhalduritele tundusid pisiasjadena. Kuid kui kõik paika loksus, jätkus projekti areng — mõne kuu pärast, 2015. aasta alguses, hakkasime aktiivselt arendama administreerimissektorit. 2015. ja 2016. aastatel läks kõik hästi, avaldasime regulaarselt uusi versioone, administreerimissektor hõlmas üha suuremat osa andmete ettevalmistamisest ja valmistusime selleks, et varsti usaldatakse meie meeskonnale kõige tähtsam ja keerulisem ülesanne – tootejoon (kogu tooteandmete ettevalmistamine ja haldamine). Kuid suvel 2017, just enne tootejoone käivitamist, sattus projekt väga keerulisse olukorda – just seoses vahemälu probleemidega. Sellest episoodist tahangi rääkida teises osas sellest kaheteisest avaldamisest.

Kuid selles postituses alustan kaugelt, tuues välja mõned mõtted – arusaamad vahemällu salvestamisest, mille üle oleks enne suurt projekti hea ette mõelda.

Kuidas vahemälustamine tekib

Vahemälustamise ülesanne ei teki lihtsalt niisama. Me oleme arendajad, kirjutame tarkvaratooteid ja soovime, et need oleksid nõutud. Kui toode on nõutud ja edukas – saabub üha rohkem kasutajaid. Ja aina rohkem ja rohkem. Ja siis on kasutajaid juba palju ning toode muutub suure koormusega.

Esimestel etappidel me ei mõtle koodi optimeerimisele ja jõudlusele. Peamine on funktsionaalsus, kiiresti välja visata eskiis ja testida hüpoteese. Ja kui koormus kasvab – suurendame riistvara. Suurendame seda kaks-kolm-kümme korda, olgu. Kusagil siin ei luba rahade tõus rohkem edasi minna. Ja mitu korda kasutajate hulk siis suureneb? See ei ole 2-5-10, vaid juhul, kui õnnestub – siis võib see kasvada 100-1000 ja kuni 100 000 korda. See tähendab, et varem või hiljem tuleb optimeerimisega tegeleda.

Oletame, et mingi osa koodist (nimetame seda osaks funktsiooniks) töötab häbiväärselt kaua ja me soovime vähendada täitmise aega. Funktsioon – see võib olla andmebaasi juurde pääsemine või mingi keerulise loogika täitmine – oluline on, et see kestab kaua. Kui palju saame täitmise aega vähendada? Piiriüleselt – saame vähendada nullini, mitte kaugemale. Kuidas saame täitmise aja nullini vähendada? Vastus: välistada täitmine üldse. Selle asemel saame kohe tagastada tulemuse. Kuidas teada saada tulemus? Vastus: kas arvutada või kuskil peegeldada. Arvutamine – see on pikk protsess. Ja peegeldamine – see tähendab näiteks meeles pidada, milline tulemus funktsioon eelmisel korral sama parameetritega andis.

See, the implementation of the function doesn't matter to us. It's enough to know what parameters affect the result. Therefore, if we represent the parameter values as an object that can be used as a key in some storage, we can save the calculation result and retrieve it the next time. If these read-write operations are faster than executing the function, we gain speed profit. The profit can reach 100, 1000, or even 100,000 times (10^5 is more of an exception, but in the case of a significantly lagging database, it is quite possible).

Main requirements for the caching system

The first requirement for a caching system could be fast read speed and slightly less so for write speed. This is true, but only until we deploy the system into production.

Let's consider such a case.

Suppose we have ensured the current load with hardware and are now gradually implementing caching. User numbers are slightly increasing, the load is growing – we add caches here and there. This goes on for some time, and now the heavy functions are hardly called anymore — the main load is handled by the cache. The number of users has increased N times during this period.

If the initial hardware capacity was 2-5 times, then with caching we could boost performance by 10 times or, in a good case, 100 times, sometimes even 1000. In other words, on the same hardware, we process 100 times more requests. Great, we've earned a reward!

But now, at one point, accidentally, the system failed and the cache crashed. Nothing special — we chose the cache based on the requirement of 'high read and write speed, the rest doesn't matter.'

In relation to the initial load, our hardware capacity was 2-5 times, and the load during this time has grown 10-100 times. With caching, we eliminated calls to heavy functions, so everything was running smoothly. But now, without caching – how much will our system drop? What will happen to us? The system will crash.

Even if our cache hasn’t crashed but just cleared for a while — it will need to be warmed up, which will take some time. During this time, the main load will fall on the functionality.

Väljund: kõrge koormusega projektid tootmises nõuavad süsteemilt mitte ainult kiiret lugemist ja kirjutamist, vaid ka andmete säilitamist ja tõrgeteta toimimist.

Valikute vaev

Projektis, kus on administraatori paneel, läks valik nii: kõigepealt paigaldasime Hazelcasti, kuna olime selle tootega juba tuttavad meie põhisaidi kogemuste kaudu. Kuid siin osutus selline valik ebaõnnestumiseks – meie koormuse profiili juures töötab Hazelcast mitte lihtsalt aeglaselt, vaid kohutavalt aeglaselt. Ja tootmisse mineku tähtaegade osas olime me sel hetkel juba allkirjastanud.

Spoiler: kuidas täpselt tingimused kokku langesid, et me jätsime sellise võimaluse maha ja saime terava ning pingelise olukorra — räägin sellest teises osas — ja kuidas me sattusime, ja kuidas välja tulime. Kuid praegu — ütlen ainult, et see oli suur stress, ja "mõelda - kuidagi ei mõtle, raputame pudelit." "Raputame pudelit" — see on samuti spoiler, sellest veidi hiljem.

Mida me tegime:

1. Koostame loendi kõigist süsteemidest, mida Google ja StackOverflow soovitavad. Veidi rohkem kui 30
2. Kirjutame koormustestisid, mis on iseloomulikud tootmiskeskkonnale. Selleks salvestasime andmed, mis läbivad süsteemi tootmiskeskkonnas — omamoodi sniffer andmete jaoks, mis ei ole võrgus, vaid süsteemi sees. Testides käivitasime just need andmed.
3. Kogu tiim, igaüks valib järgmise süsteemi loendist, seadistab, käivitab testid. Kui test ei lähe läbi, ei suuda koormust taluda – viskame välja, liigume järgmise juurde.
4. 17. süsteemis sai selgeks, et kõik on lootusetu. Aeg on lõpetada "pudeli raputamine", on aeg tõsiselt järele mõelda.

Kuid see on variant, kui tuleb valida süsteem, mis "mahub kiirusest" ette valmistatud testides. Aga kui selliseid teste veel ei ole ja tahaks kiiremini valida?

Simuleerime sellist varianti (raske on ette kujutada, et keskmise taseme arendaja elab vaakumis, ja valiku tegemise hetkel ei ole veel oma eelistust väljendanud, millist toodet esmajoones proovida — seega edasised arutlused on pigem teoreetilised/filosoofilised/noore arendaja teemad).

Otsustades nõudmised, alustame valmis lahenduse valimist. Miks jalgratast uuesti leiutada: läheme ja võtame valmis vahemälusüsteemi.

Kui te alles alustate ja Google'ist otsite, siis järjestus on enam-vähem selline, kuid suunised jäävad samaks. Esiteks satute Redis'e peale, see on igal pool teemaks. Siis saate teada, et on olemas EhCache, mis on üks vanimaid ja kõige usaldusväärsemaid süsteeme. Järgmisena räägitakse Tarantoolist — kohalikust arendusest, millel on ainulaadne lahenduse aspekt. Ja samuti Ignite, kuna see on praegu populaarsuse tõusu teel ja saavad toetust SberTechi poolt. Lõpuks veel Hazelcast, kuna see tihti esineb ettevõtte maailmas suurte firmade seas.

See nimekiri ei ole lõplik, süsteeme on kümneid. Me käsitleme ainult ühte. Vaatame valitud 5 süsteemi „ilu võistlusele” ja viime läbi valiku. Kes saab võitjaks?

Redis

Loomulikult vaatame, mida ametlikul saidil kirjutatakse.
Redis — avatud allikas projekt. Pakub andmete in-memory salvestust, võimalust salvestada andmeid kettale, automaatset jagamist partiideks, kõrget kättesaadavust ja taastumist võrgu katkemise järel.

Tundub, et kõik on suurepärane, seda võib võtta ja kasutada — kõik, mis vajalik, see teeb. Kuid vaatame lihtsalt huvi pärast teisi kandidaate.

EhCache

EhCache — „kõige laialdasemalt kasutatav vahemälu Java jaoks” (ametliku saidi slogan tõlgituna). Samuti avatud allikas. Ja siit mõistame, et Redis ei ole Java jaoks, vaid üldine, ja selleks, et sellega suhelda, on vajalik wrapper. Kuid EhCache on mugavam. Mida veel süsteem lubab? Usaldusväärsust, tõestatud tulemusi, täisfunktsionaalsust. Ja pealegi on see kõige levinum. Ja see cache'ib terabaiti andmeid.

Redis on unustatud, ma olen valmis valima EhCache'i.

Aga patriotismi tunne sunnib mind vaatama, millised omadused on Tarantoolil.

Tarantool

Tarantool — esitleb end kui „Reaalajas andmete integreerimisplatvorm”. Tundub väga keeruline, seega loeme lehte põhjalikult ja leiame kõlava väite: „Cache'ib 100% andmeid operatiivmälu.” See peaks tekitama küsimusi — sest andmeid võib olla oluliselt rohkem kui mälu. Selgitus on selles, et Tarantool ei tee mälu andmete kettale salvestamisel serialiseerimist. Selle asemel kasutab see madala taseme süsteemi omadusi, kui mälu lihtsalt kaardistatakse failisüsteemile, millel on väga head I/O näitajad. Üldiselt, tehti kuidagi suurepäraselt ja toredalt.

Vaadakem rakendusi: Mail.ru ettevõtte taristu, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...

Kui Tarantooli osas oli veel mingeid kahtlusi, siis Mastercardi rakenduse juhtum on mind maha löönud. Valin Tarantooli.

Aga sellegipoolest…

Ignite

… on veel Ignite, mida kirjeldatakse kui „in-memory arvutusplatvorm… in-memory kiirus petabaidides andmetes“. Siin on ka palju plusse: jaotatud in-memory vahemälu, kõige kiirem key-value salvestus ja vahemälu, horisontaalne skaleeritavus, kõrge saadavus, range terviklikkus. Kokkuvõttes, tundub, et kõige kiirem ongi Ignite.

Rakendused: Sberbank, American Airlines, Yahoo! Japan. Ja siis ma veel avastan, et Ignite ei ole lihtsalt Sberbankis kasutusele võetud, vaid SberTechi meeskond saadab oma inimesi Ignite’i meeskonda toodet täiustama. See ostab mind täielikult ja olen valmis Ignite’i võtma.

Täiesti arusaamatult vaatan viiendat punkti.

Hazelcast

Külastan veebisaiti Hazelcast, loen. Ja selgub, et kõige kiirem lahendus jaotatud vahemälu jaoks on Hazelcast. See on oluliselt kiirem kui kõik teised lahendused ja on üldiselt liider in-memory andmevõrgu valdkonnas. Sellise taustaga on midagi muud võtta enda mitte austamisele.

Kõik, olen valmis Hazelcasti võtma.

Võrdlus

Aga kui vaadata, siis kõik viis kandidaati on nii kirja pandud, et igaühes neist – parim. Kuidas valida? Võime vaadata, milline neist on kõige populaarsem, otsida võrreldes ja peavalu kaob.

Leidsime sellise ülevaade, valime meie 5 süsteemi.

Siin on nad järjestatud: eespool Redis, teisel kohal — Hazelcast, populaarsust koguvad Tarantool ja Ignite, EhCache jääb endiseks.

Aga vaatame arvutusmeetodit: lingid veebisaitidele, süsteemi üldine huvi, tööpakkumised — tore! Siis, kui minu süsteem kokku kukub, ütlen: „Ei, see on ju usaldusväärne! Siin on palju tööpakkumisi…”. Selline lihtne võrdlus ei sobi.

Kõik need süsteemid ei ole lihtsalt vahemällu salvestamise süsteemid. Neil on veel palju funktsioone, sealhulgas – kui mitte andmeid edastatakse kliendile töötluseks, vaid vastupidiselt: kood, mida peab andmete üle töötlema, liigub serverisse, seal käivitatakse ja tulemus tagastatakse. Ja kui eraldi vahemälu süsteemina ei vaadata neid nii sageli.

Hea, ei anname alla, leiame otsese võrdluse süsteemide vahel. Võtame kaks ülemist varianti — Redis ja Hazelcast. Meid huvitab kiirus, selle parameetri põhjal neid ka võrreldakse.

Hz vs Redis

Leidsime sellise võrdlus:


Sinine on Redis, punane Hazelcast. Hazelcast võidab kõikides võrdlustes ning sellel on oma põhjused: see on mitme lõimega, tugevalt optimeeritud, iga lõim töötab oma partiiga, seega ei toimu ummikuid. Redis on aga ühe lõimega, seega ei suuda see tänapäevastelt mitme tuumalistelt CPU-delt võitu saada. Hazelcast kasutab asünkroonset I/O-d, Redis-Jedis aga blokeerivaid socket-e. Lõppude lõpuks kasutab Hazelcast binaarset protokolli, samas kui Redis on suunatud tekstile, mis tähendab, et see on ebaefektiivne.

Igaks juhuks viidates veel ühele võrdluse allikale. Mida see meile näitab?

Redis vs Hz

Veel üks võrdlus:


Siin on vastupidi, punane on Redis. See tähendab, et Redis võidab Hazelcasti tootlikkuses. Esimeses võrdluses võitis Hazelcast, teises aga Redis. Siin on väga täpselt selgitatud, miks eelnevas võrdluses võitis Hazelcast.

Selgub, et esimese tulemus oli faktiliselt vale: Redis võeti põhiversioonis, samas kui Hazelcast kohandati testjuhtumi jaoks. Nii et kokkuvõttes: esiteks, kellelegi ei saa usaldada, teiseks, kui me ikkagi valime süsteemi, siis peame selle ka õigesti seadistama. Need seaded hõlmavad kümneid, peaaegu sadu parameetreid.

Raputame pudelit

Ja kogu protsessi, mida me praegu läbime, saan ma selgitada sellise metafooriga «Raputame pudelit». See tähendab, et praegu ei ole vaja programmeerida, praegu on peamine osata lugeda stackoverflow-d. Ja minu meeskonnas on inimene, professionaal, kes töötab just niimoodi kriitilistel hetkedel.

Mida ta teeb? Ta näeb mitte töötavat asja, näeb stack trace'i, võtab sealt sõnu (milli just — see on tema ekspertiis programmis), otsib Googlest, leiab stackoverflow vastuste seast. Mitte lugedes, mitte mõeldes, vastuste seas valib ta midagi, mis on kõige sarnasem väljendiga «teha seda ja toda» (selle vastuse valimine on tema talent, kuna see ei pruugi alati olla see vastus, mis on saanud rohkem hääli), rakendab, vaatab: kui midagi on muutunud, siis on kõik korras. Kui ei ole muutunud — tagastame. Ja kordame käivitamist-kontrollimist-otsimist. Ja niimoodi intuitsiooniga saavutab ta selle, et mingil hetkel kood töötab. Ta ei tea, miks, ta ei tea, mida ta tegi, ta ei oska selgitada. Kuid! See jama töötab. Ja «tuli on kustutatud». Nüüd saame aru, mida me tegime. Kui programm töötab — on see kordades lihtsam. Ja säästab oluliselt aega.

See, this method is very well explained with such an example.

Once, it was very popular to build a ship in a bottle. The ship is large and fragile, while the neck of the bottle is very narrow, making it impossible to push it inside. How to assemble it?

There is a method, very quick and very effective.

The ship consists of a bunch of small parts: sticks, strings, sails, glue. We put all this into the bottle.
We take the bottle with both hands and start shaking. We shake it and shake it. And usually – it turns out to be a complete mess, of course. But sometimes, just sometimes, it turns into a ship! Or rather, something that resembles a ship.

We show this something to someone: "Seryoga, see!?". And indeed, from a distance – it looks like a ship. But you can't let it go further.

There's another way. More advanced guys, like hackers, use it.

I gave such a guy a task, he completed it and left. And you see – it seems done. But after a while, when you need to modify the code — that's when the trouble starts… Good thing he has already run far away. These are the kinds of guys who can take the example of the bottle and do this: see, where the bottom is – the glass bends. And it’s not quite clear if it’s transparent or not. Then the 'hackers' cut off this bottom, insert the ship inside, glue the bottom back, and it looks like it's meant to be.

From the perspective of task assignment, everything seems right. But taking the example of ships: why make this ship at all, who needs it? It doesn't serve any functionality. Usually, such ships are gifts for very high-ranking people, who place them on a shelf above themselves, as a symbol, as a sign. And if such a person, a leader of a large business or a high-ranking official, has a shabby artifact with its neck cut off standing as a flag? It would be better if he never finds out about it. So how do they ultimately make these ships that can be gifted to an important person?

Ainult üks koht, võtmekoht, millega tõeliselt midagi ei saa ette võtta, on korpus. Ja laeva korpus läheb justkui kaela kaudu läbi. Samas kui laev ehitatakse pudelist välja. Kuid see ei ole lihtsalt laeva kokku panemine, see on tõeline kullaomaniku käsitöö. Koos komponentidega lisatakse spetsiaalsed käepidemed, mis võimaldavad neid hiljem üles tõsta. Näiteks volditakse purjed ettevaatlikult sisse ja seejärel tõmmatakse ja tõstetakse neid väga täpselt pintsettidega. Tulemusena saadakse kunstiteos, mida saab puhta südametunnistuse ja uhkusega kinkida.

Ja kui me tahame, et projekt oleks edukas – peab meeskonnas olema vähemalt üks kuldsep. See, kes hoolib toote kvaliteedist ja arvestab kõiki aspekte, mitte ühtegi ohverdades isegi stressi hetkedel, kui olud nõuavad kiiret, mis tuleb olulise arvelt. Kõik edukad projektid, mis on vastupidavad ja mis on aja katsumuse vastu pidanud, on selle põhimõtte põhjal ehitatud. Neis on midagi väga täpset ja ainulaadset, midagi, mis kasutab kõiki saadaval olevaid võimalusi. Näites pudelilaeva kohta - mängitakse välja see, et laeva korpus läheb läbi kaela.

Tagasi tulles ülesande juurde, kuidas valida meie vahemälu serverit, kuidas seda meetodit võiks rakendada? Ma pakun välja sellise valiku kõigist olemasolevatest süsteemidest - mitte pudelit raputada, mitte valida, vaid vaadata, mis seal tegelikult on, millele tähelepanu pöörata süsteemi valimisel.

Kus otsida pudelikaela

Proovime mitte pudelit raputada, mitte järjest kõike läbi vaadata, vaid vaatame, millised ülesanded võivad tekkida, kui peaksime oma ülesande jaoks iseseisvalt sellise süsteemi projekteerima. Jalgratast me loomulikult ei leiuta, kuid kasutame seda skeemi, et orienteeruda, millele tähelepanu pöörata toodete kirjeldustes. Joonistame välja sellise skeemi.

Kui süsteem on jagatud, siis on meil mitmeid servereid (6). Oletame, et neli (mugav joonistada pildile, kuid neid võib olla igasugune hulk). Kui serverid asuvad erinevates sõlmedes, siis töötab neis kõigis mingi kood, mis vastutab selle eest, et need sõlmed moodustaksid klastri ja katkestamise korral - ühenduksid, tunneksid üksteist.

Vajame ka koodilogikat (2), mis sisuliselt tegeleb vahenduse vahemällu salvestamisega. Selle koodiga suhtlevad kliendid teatud API kaudu. Klientide kood (1) võib olla nii sellesama JVM raames kui ka sellele võrgu kaudu juurde pääseda. Sees rakendatud loogika määrab, millised objektid jäävad vahemällu ja millised visatakse välja. Vahemälu hoidmiseks kasutame mälu (3), kuid vajadusel saame osa andmeid ka kettale salvestada (4).

Vaatame, millistes osades koormus tekib. Tegelikult koormatakse iga noolt ja igat sõlme. Esiteks klientide koodi ja API vahel, kui see on võrguvaheline suhtlemine, võib allasurumine olla üsna märgatav. Teiseks, API enda raames - kui keerukaks loogikaks minna, võime jõuda CPU piirini. Ja oleks hea, kui loogika ei sunniks mälu liigset kasutama. Jääb veel suhtlemine failisüsteemiga – tavapärasel juhul tuleb see serialiseerida / taastada ja kirjutada / lugeda.

Edasi liikudes klastriga suhtlemine. Tõenäoliselt on see samas süsteemis, kuid võib olla ka eraldi. Siin tuleb samuti arvesse võtta andmete edastamist, andmete serialiseerimise kiirus ja suhtlemine klastriga.

Nüüd, ühelt poolt - saame mõelda, "millised hammasrattad pöörlevad" vahemälu süsteemis meie koodi päringute töötlemisel, ja teiselt poolt - saame hinnata, kui palju ja milliseid päringuid meie kood sellele süsteemile genereerib. Seda on piisavalt, et teha enam-vähem tasakaalustatud valik - valida süsteem vastavalt meie kasutusvariandile.

Hazelcast

Vaatame, kuidas sellist jaotust oma nimekirjale rakendada. Näiteks Hazelcast.

Kuna andmete lisamiseks / võtmiseks Hazelcastist pöördub kliendi kood (1) API poole. Hz võimaldab käivitada serverit kui embedded, ja sellisel juhul on API-le pöördumine meetodi kutsumine JVM sees, mida võib pidada tasuta.

Kuna loogika (2) töötamiseks toetub Hz serialiseeritud võtme baitmassiivist saadud hash'ile – see tähendab, et võtme serialiseerimine toimub igal juhul. See on Hz jaoks vältimatu ülejääk.
Eemaldamisstrateegiad on hästi rakendatud, kuid erijuhtudel – saab lisada oma. Selle osa pärast ei ole vaja muretseda.

Salvestust (4) saab ühendada. Suurepärane. Interaktsioon (5) embedded jaoks võib pidada koheseks. Andmete vahetamine sõlmede vahel klastris (6) – jah, see on olemas. See on panus süsteemi töökindluse nimel, ohverdatud kiirusel. Hinna langetamine on võimalik Hz-funktsiooniga Near-cache – andmed, mis saadakse teistelt klastrinoodidelt, salvestatakse vahemälu.

Mida sellistes tingimustes teha kiiruselise tõusu saavutamiseks?

Näiteks, et vältida võtme serialiseerimist (2) – lisada Hazelcastile veel üks vahemälu, kõige kuumemate andmete jaoks. Sportmasteris välja valitud Caffeine.

Selle taseme (6) optimeerimiseks pakub Hz kahte tüüpi salvestamist: IMap ja ReplicatedMap.


Tuleb mainida, kuidas Hazelcast sattus Sportmasteri tehnoloogia virna.

Aastal 2012, kui töötasime tulevase saidi esimeses pilotprojektis, osutus Hazelcast just esimeseks lingiks, mille otsingumootor väljastas. Kohtumine algas "esimese korraga" – meid võlus see, et vaid kahe tunni pärast, kui me Hz süsteemi lisasime – see töötas. Ja töötas hästi. Pärast seda päeva lisasime palju teste, olime rõõmsad. Ja see energiatäidetus piisavalt, et ületada need üllatused, mida Hz aja jooksul külvas. Praeguseks pole Sportmasteri meeskonnal põhjuseid Hazelcastist loobuda.

Kuid sellised argumendid nagu „esimene link otsingumootoris“ ja „kiirelt kokkupanek HelloWorld'ile“ on muidugi erand ja hetkeomadus, milles valik toimus. Tõelised katsed valitud süsteemi jaoks algavad tootmisfaasis, ja just sellele etapile tasub tähelepanu pöörata iga süsteemi, kaasa arvatud vahemälu, valimisel. Tegelikult võib meie puhul öelda, et valisime Hazelcast juhuslikult, kuid hiljem selgus, et tegime õige valiku.

Tootmises on palju olulisemad: jälgimine, vigade käsitsemine eraldi sõlmedes, andmete replikatsioon, skaleerimise kulud. Seega tasub pöörata tähelepanu ülesannetele, mis tekivad just süsteemi haldamisel – siis, kui koormus ületab korduvalt planeeritud taset, kui juhuslikult laadime midagi vale ja valesse kohta, kui on vajalik uue koodiversiooni väljatöötamine, andmete asendamine ja selle tegemine klientidele märkamatuks.

Kõikide nende nõudmiste jaoks sobib Hazelcast kindlasti.

Jätkub

Kuid Hazelcast ei ole imevahend. 2017. aastal valisime Hazelcasti administreerimise vahemälu jaoks, tuginedes lihtsalt varasemate kogemuste heale muljele. See mängis võtmerolli väga halvas naljas, mis viis meid keerulisse olukorda, millest ''kangelaslikult'' pääsesime 60 päevaga. Kuid sellest räägime järgmises osas.

Ja seni… Head uut koodi!

Allikas: habr.com