Kuidas me Sportmasteris valisime vahemälusüsteemi. Osa 1

Tere! Minu nimi on Aleksei Pjankov, ma olen arendaja ettevõttes Sportmaster. Selles postituses räägin, kuidas Sportmasteri veebisaidi tegemine 2012. aastal algas, milliseid algatusi õnnestus "läbi viia" ja vastupidi, milliseid tõkkeid me kogusime.

Täna tahan jagada mõtteid, mis järgivad teist teemat – Java tagaplaneerimise vahemälu süsteemi valimine saidi administreerimiseks. See teema on minu jaoks eriti oluline – kuigi lugu kestis vaid 2 kuud, töötasime nendel 60 päeval 12-16 tundi ja ei saanud ühtki vaba päeva. Paar korda ei olnud ma kunagi varem mõelnud ega kujutlenud, et saab nii palju tööd teha.

Seetõttu jagan teksti kaheks osaks, et mitte liiga koormata. Vastupidi, esimene osa saab olema väga kerge – ettevalmistus, sissejuhatus, mõned mõtted, mis on vahemälu. Kui olete juba kogenud arendaja või töötanud vahemäludega – tehniliselt ei pakkuda see artikkel tõenäoliselt midagi uut. Siiski, väikese ülevaate alla algajale võib see anda suuniseid, kuhu pöörduda, kui ta satub sellele teele.

Kui Sportmasteri uue veebiversiooni tootmise käivitamine toimus, toimusid andmete edastamine, ütleme nii, mitte just mugavalt. Aluseks olid tabelid, mis olid ette valmistatud eelmise veebiversiooni (Bitrix) jaoks, mida tuli laadida ETL-i, viia uuele kujule ja rikastada erinevate uhkustega veel erinevatest süsteemidest. Et uus pilt või tootekirjeldus veebis ilmuks, tuli oodata järgmise päevani — uuendamine toimus ainult öösel, üks kord ööpäevas.

Alguses oli esimesel nädalal pärast tootmisse minekut nii palju muresid, et sisu haldajate ebamugavused tundusid tühised. Kuid niipea, kui kõik rahunes, jätkus projekti areng — 2015. aasta alguses, pärast mitmeid kuud, hakkasime aktiivselt arendama administraatori paneeli. Aastal 2015 ja 2016 läks kõik hästi, me teostasime regulaarselt versioone, administraatori paneel hõlmas üha suuremat osa andmete ettevalmistamisest ja valmistusime selleks, et peagi usaldatakse meie meeskonnale kõige tähtsam ja keerulisem — toote kontuur (täielik andmete ettevalmistamine ja haldamine kõigi toodete osas). Kuid suvel 2017, just enne toote kontuuri käivitamist, sattus projekt väga keerulisse olukorda — just seoses probleemidega vahemäluga. Sellest episoodist ma tahangi rääkida selle kaheosalisest publikatsioonist teises osas.

Kuid selles postituses alustan kaugelt, kogudes teatud mõtteid — ettekujutusi vahemälust, mille üle oleks olnud hea enne suurt projekti eelnevalt mõelda.

Kui tekib vahemäluga seotud ülesanne

Cache'i ülesanne ei teki lihtsalt nii. Me oleme arendajad, kirjutame tarkvaratoote ja tahame, et see oleks nõutud. Kui toode on nõutud ja edukas — kasutajad tulevad. Ja nad tulevad taas ja taas. Ning lõpuks on kasutajaid väga palju, ja siis muutub toode suure koormuse all olevaks.

Esimestel etappidel ei mõtle me koodi optimeerimisele ja tootlikkusele. Peamine on funktsionaalsus, kiiresti piloot välja viia ja hüpoteese testida. Ja kui koormus kasvab – me uuendame riistvara. Suurendame selle mahutavust kaks, kolm, viis või isegi kümme korda. Siin võib rahandus rohkem ei lubada. Ja kui palju kasutajate arv kasvab? See ei ole 2-5-10, vaid edusammude korral — see võib ulatuda 100-1000 ja kuni 100 000 korda. Seega, varem või hiljem tuleb optimeerimisega tegelema hakata.

Kujutame ette, et mingi koodi osa (nimetame seda funktsiooniks) töötab ebamugavalt kaua ja me tahame täitmisaja vähendada. Funktsioon võib olla näiteks juurdepääs andmebaasile või mõne keeruka loogika täitmine — peamine on see, et see kestab kaua. Kuidas saaksime täitmisaja nulli viia? Teoreetiliselt on võimalus vähendada selle aega kuni nullini, ei kaugemale. Kuidas aga viia täitmise aeg nulli? Vastus: üldse mitte täita. Selle asemel — tagastada kohe tulemus. Kuidas aga tulemus teada saada? Vastus: kas arvutada see välja või vaadata kuskilt. Välja arvutamine — see on pikk protsess. Aga vaatamine — see tähendab näiteks meeles pidada tulemust, mille funktsioon eelmisel korral andis, kui seda sama koosseisu parametritega kutsuti.

See, rakenduse funktsioon ei ole meile oluline. Piisab ainult teada, millistest parameetritest tulemus sõltub. Kui aga esitada parameetrite väärtused objekti kujul, mida saab kasutada võtmena mingis salvestuses – siis saame arvutamise tulemuse salvestada ja järgmiste päringute korral seda lugeda. Kui need kirje-lugemise protsessid toimuvad kiiremini kui funktsiooni täitmine – saavutame kiirusel kasu. Kasu suurus võib ulatuda 100, 1000 ja isegi 100 000 korda (10^5 on pigem erand, kuid korralikult laguneva andmebaasi puhul on see täiesti võimalik).

Peamised nõuded vahemällu salvestamise süsteemile

Esimene, mis võib olla nõudmine vahemällu salvestamise süsteemile — kiire lugemisekiirus ja veidi vähem – kirjutamise kiirus. See on tõsi, kuid ainult seni, kuni me süsteemi tootmisse toome.

Loome sellise juhtumi.

Oletame, et me oleme praegu koormuse jaoks riistvara taganud ja nüüd alustame järk-järgult vahemälu kasutuselevõttu. Kasutajate arv kasvab järk-järgult, koormus suureneb — lisame veidi vahemälusid, ühendame neid siin-seal. Nii jätkub see mõnda aega, ja nüüd kutsutakse juba raske funktsioonide täitmine täpselt harva — kogu peamine koormus lasub vahemälu. Selle aja jooksul on kasutajate arv kasvanud N korda.

Ja kui algne riistvara varu võis olla 2-5 korda, siis vahemälu abil saime tõsta jõudlust isegi 10 korda või, heas olukorras, 100 korda, kohati isegi 1000 korda. See tähendab, et samas riistvara peal — töötleme 100 korda rohkem päringuid. Suurepärane, oleme prääniku ära teeninud!

Aga nüüd, ühel kenal hetkel, juhtus süsteemis viga ja vahemälu kukkus kokku. Miski erilist — oleneb ju sellest, et vahemälu valiti nõudmisel "kõrge lugemise ja kirjutamise kiirus, muu pole oluline."

Algselt oli meie riistvaral koormus 2-5 korda, aga selle aja jooksul on koormus kasvanud 10-100 korda. Vahefilter elimineeris raskeid funktsioonide kutsungite laadimist, seega kõik töötas sujuvalt. Aga nüüd, ilma vahefilterita – kui palju meie süsteem kannatab? Mis meiega juhtub? Süsteem kukub kokku.

Isegi kui meie vahefilter ei ole kokku kukkunud, vaid lihtsalt puhastatud mõneks ajaks – tuleb seda uuesti soojendada, ja see võtab aega. Selle aja jooksul kukub peamine koormus funktsionaalsusele.

Kokkuvõte: kõrge koormusega projektid tootmisprotsessis nõuavad süsteemilt vahefilterit mitte ainult kiire lugemise ja kirjutamise osas, vaid ka andmete säilitamise ja tõrgete suhtes vastupidavust.

Valikute vaev

Adminpaneeli projektis kujunes valik selliseks: esmalt paigaldasime Hazelcasti, kuna olime selle tootega juba põhisaidi kogemuse kaudu tuttavad. Kuid siin osutus selline valik ebaõnnestunuks – meie koormuse profiili puhul töötab Hazelcast mitte lihtsalt aeglaselt, vaid äärmiselt aeglaselt. Ja tootmisprotsessi tähtaegade osas olime tol hetkel juba allkirjastanud.

Spoiler: how exactly the circumstances unfolded that led us to miss such a blunder and ended up in a tense situation – I will explain in the second part — how we got there and how we got out. But for now, I'll just say that it was a significant stress, and 'thinking – somehow, does not come to mind, we shake the bottle.' 'Shake the bottle' is also a spoiler, more on that later.

What we did:

1. We compile a list of all systems suggested by Google and StackOverflow. A little more than 30.
2. We write load tests typical for production. For this, we recorded data that passes through the system in the production environment — a kind of sniffer for data not on the network but within the system. We ran exactly these data in the tests.
3. As a team, each member selects the next system from the list, configures it, and runs the tests. If the test fails, can't handle the load – we discard it and move on to the next one in line.
4. By the 17th system, it became clear that all was hopeless. Enough with 'shaking the bottle', it was time to think seriously.

See on valik, kus tuleb valida süsteem, mis "mahtus kiiruskatsetest" läbi. Aga kui selliseid katseid veel pole ja on soov valida kiiremat?

Simuleerime sellist varianti (raske on ette kujutada, et arendaja, kelle oskused on keskmised ja kõrgemad, elab vaakumis, ning valiku hetkel pole ta veel otsustanud, millist toodet esimesena proovida — seega, edasised arutlused on pigem teoreetilised/filosoofilised/juniortaseme suhtes).

Kui oleme nõuded selgeks teinud, alustame lahenduse valimist välja pakutud variandi hulgast. Miks peaks jalgratast leiutama: me võtame valmis vahemälu süsteemi.

Kui alles alustate ja hakkate guugeldama, siis järjekord on pluss-miinus sama, kuid üldiselt on suunised sellised. Esiteks satute kindlasti Redis'esse, see on kõikjal tuntud. Siis saate teada, et on olemas EhCache, mis on vanim ja usaldusväärne süsteem. Edasi kirjutatakse Tarantoolist — kodumaine arendus, milles on ainulaadne lahenduse aspekt. Ja samuti Ignite, kuna see on praegu populaarsuse tõusuteel ja naudib SberTechi toetust. Lõpuks veel Hazelcast, kuna ettevõtte maailmas on see sageli suurte ettevõtete seas silma jäänud.

See on vaid väike valik, süsteeme on kümneid. Meie valime neist vaid ühe. Vaatame viit valitud süsteemi "ilu konkurssile" ja teeme valiku. Kes on võitja?

Redis

Loe, mida ametlikul veebilehel kirjutatakse.
Redis — avatud lähtekoodiga projekt. Pakub andmete salvestamist mälu (in-memory) ja võimalust salvestada kettale (on-disk), automaatset osade moodustamist, kõrget kättesaadavust ning taastumist võrgukatkestuste korral.

Tundub, et kõik on suurepärane, saab võtta ja kasutama hakata — kõik, mis vajalik, see töötab. Kuid vaatame lihtsalt huvi pärast ka teisi kandidaate.

EhCache

EhCache — "kõige laialdasemalt kasutatav Java vahemälu" (tõlge ametlikult veebilehelt). Ka avatud lähtekoodiga. Ja siin saame aru, et Redis ei ole Java jaoks, vaid universaalne, ning selleks, et sellega suhestuda, on vaja katet. EhCache tundub mugavam. Mida veel süsteem lubab? Usaldusväärsus, testitud tootmine, täielik funktsionaalsus. Ja on ka kõige levinum. Salvestab terabaitide ulatuses andmeid.

Redis on unustanud, olen valmis valima EhCache.

Aga patriootlik tunne ajendab mind vaatama, millega on hea Tarantool.

Tarantool

Tarantool — tutvustatakse kui „Reaalaja andmete integreerimise platvorm”. See kõlab keeruliselt, seega vaatame lehte põhjalikult ja leidke väide: „Cache’ib 100% andmeid mälu sees”. See peaks tekitama küsimusi — kuna andmeid võib olla märkimisväärselt rohkem kui mälu. Selgitus on selles, et andmete kirjutamisel ketta peale ei kasuta Tarantool serialiseerimist. Selle asemel kasutatakse madala taseme süsteemi omadusi, kui mälu kaardistatakse failisüsteemile väga hea I/O jõudlusega. Kokkuvõttes tehti see kuidagi suurepäraselt ja ägedalt.

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

Kui mul jäi veel kahtlusi Tarantooli osas, siis Mastercardi rakenduse juhtum veenab mind täielikult. Valin Tarantooli.

Aga siiski…

Ignite

… on veel Ignite, mis on deklareeritud kui „in-memory arvutusplatvorm… in-memory kiirus petabaidandmete osas”. Siin on ka palju eeliseid: jagatud in-memory vahemälu, kõige kiirem key-value salvestus ja vahemälu, horisontaalne skaleeritavus, kõrge kättesaadavus, range terviklikkus. Kokkuvõttes tundub, et kõige kiirem on Ignite.

Rakendused: Sberbank, American Airlines, Yahoo! Japan. Ja siis kuulen, et Ignite ei ole lihtsalt Sberbankis rakendatud, vaid SberTechi meeskond saadab oma inimesi Ignite'i meeskonda toodet täiustama. See on täiesti veenev ja ma olen valmis Ignite'i võtma.

Täiesti arusaamatu, miks ma vaatan viiendat punkti.

Hazelcast

Sisenen veebisaidile Hazelcast, loen. Ja selgub, et kiireim lahendus jagatud vahemälu jaoks on Hazelcast. See on kordades kiirem kui kõik muud lahendused ja ta on üldiselt liider in-memory andmevõrgus. Tänu sellele oleks midagi muud võtta nagu enda mitte austamine. Ja ta kasutab ka üleliigset andmete hoidmist klastrite pidevaks tööks ilma andmekadudeta.

Kõik, olen valmis Hazelcast'i võtma.

Võrdlus

Kuid kui vaadata, siis on kõik viis kandidaati nii esitatud, et igaühe seas on kõige parem. Kuidas valida? Võime vaadata, milline neist on kõige populaarsem, otsida võrdlusi ja peavalu kaob.

Leidke selline ülevaade, valime meie 5 süsteemi.

Siin on nad sorteeritud: ees Redis, teisel kohal — Hazelcast, populaarsust koguvad Tarantool ja Ignite, EhCache jääb endiselt samaks.

Kuid vaatame arvutusmeetodit: lingid veebisaitidele, üldine huvi süsteemi vastu, tööpakkumised — suurepärane! See tähendab, et kui minu süsteem kukub, ütlen: 'Ei, see on ju usaldusväärne! Siin on palju tööpakkumisi...'. Niisugune lihtne võrdlus ei sobi.

Kõik need süsteemid ei ole pelgalt vahemälu süsteemid. Neil on veel palju funktsioone, sealhulgas — kui mitte andmed edastatakse kliendile töötlemiseks, vaid vastupidi: kood, mis tuleb andmetega täita, liigub serverisse, seal täidetakse ja tulemus tagastatakse. Ja kui eraldi vahemälu süsteemina ei vaadata neid liiga sageli.

Hästi, ei anna alla, leidke süsteemide otse võrrelda. Võtame kaks ülejäänud varianti — Redis ja Hazelcast. Meid huvitab kiirus, selle parameetri järgi me neid ka võrdleme.

Hz vs Redis

Leidke selline võrdlus:


Sinine — see on Redis, punane — Hazelcast. Hazelcast võidab igal pool, ja sellele on põhjendus: see on mitmerealine, kõrgelt optimeeritud, iga lõime töötab oma partitsiooniga, seega pole lukustusi. Redis on aga üherealine, seega ei saa ta kasu kaasaegsetest mitme südamikuga CPU-dest. Hazelcast kasutab asünkroonset I/O, Redis-Jedis aga blokeerivaid socket’e. Lõppkokkuvõttes kasutab Hazelcast binaarprotokolli, Redis on suunatud tekstile, mis tähendab, et see on ebaefektiivne.

Igaks juhuks vaatame veel ühte võrdlusallikat. Mida see meile näitab?

Redis vs Hz

Veel üks võrdlus:


Siin on vastupidi, punane — see on Redis. See tähendab, et Redis on jõudluses üle Hazelcasti. Esimeses võrdluses võitis Hazelcast, teises — Redis. Siin on väga täpselt selgitatud, miks eelnevas võrdluses võitis Hazelcast.

Selgub, et esimese tulemusi oli tegelikult manipuleeritud: Redis viidi sisse baasversioonis, samas kui Hazelcast kohandati testijuhtumi jaoks. Seega, kõigepealt: kellelegi ei saa usaldada, teiseks, kui me lõpuks valime süsteemi, peame seda veel õigesti seadistama. Need seadistused hõlmavad kümneid, peaaegu sadu parameetreid.

Raputame pudelit

Ja kogu protsessi, mille me praegu läbi rääkisime, saan ma seletada sellise metafooriga nagu 'Kõigutame pudelit'. See tähendab, et hetkel ei pea programmeerima, hetkel on peamine osata lugeda Stack Overflow'd. Ja mul on meeskonnas inimene, professionaal, kes just niimoodi töötab kriitilistel hetkedel.

Mida see teeb? Ta näeb, et seade ei tööta, näeb virhebaasi, võtab sealt mõned sõnad (millised täpselt — see on tema ekspertteadmised programmist), otsib Google'ist, leiab Stack Overflow vastuste hulgast. Lugemata ja süvenemata, valib ta vastustest midagi, mis sobib kõige rohkem ettepanekuga „teha seda ja toda“ (selle vastuse valimine on tema anne, sest see pole alati see vastus, mis on saanud kõige rohkem meeldimisi), rakendab seda, vaatab: kui midagi on muutunud, siis on suurepärane. Kui mitte — tagasi rullime. Ja kordame käivitamista ja kontrollimist ning otsimist. Nii intuitiivselt saavutab ta, et mingi aja pärast kood töötab. Ta ei tea, miks, ta ei tea, mida ta tegi, ta ei saa selgitada. Aga! See asi töötab. Ja „tuli on kustutatud“. Nüüd hakkame aru saama, mida me tegime. Kui programm töötab — on see kordades lihtsam. Ja see säästab märkimisväärselt aega.

Seda meetodit saab väga hästi illustreerida järgmise näitega.

Kord oli väga populaarne koguda purjekat pudelisse. Purjekas on suur ja habras, aga pudeli suu on väga kitsas, sealt sisse pääseda ei saa. Kuidas seda kokku panna?

On selline meetod, väga kiire ja väga tõhus.

Laev koosneb paljusid pisiasju: pulgad, nöörid, purjed, liim. Kõik need paneme pudelisse.
Võtame pudeli kahe käega ja hakkame raputama. Raputame-raputame. Ja tavaliselt – tulemuseks on täielik jama, muidugi. Aga mõnikord. Mõnikord tuleb laev! Täpsemalt, midagi, mis meenutab laeva.

Me näitame seda kuskile: «Serjega, näed!?». Ja tõesti, kaugelt – näeb välja nagu laev. Aga edasi seda lasta ei saa.

On veel üks meetod. Kasutavad sellised edasijõudnud tüübid, sellised häkkerid.

Andsin sellisele poisile ülesande, ta tegi kõik ära ja läks minema. Ja vaatad – nagu oleks tehtud. Aga mõne aja pärast, kui tuleb koodi täiendada — hakkab seal kohe midagi juhtuma... Hea, et ta on juba kaugele jooksnud. Sellised on need tüübid, kes teevad pudeli näitel nii: näete, seal, kus põhi – klaas kõverdub. Ja ei ole päris selge, kas see on läbipaistev või mitte. Siis «häkkerid» lõikavad selle põhjaga, panevad sinna laeva sisse, põhja liimivad pärast uuesti kinni ja nagu oleks nii olnudki.

Ülesande määratlemise seisukohalt näib kõik õige. Aga võtame näite laevad: miks üldse selline laev teha, kellele see vajalik on? Tal pole mingit funktsionaalsust. Tavaliselt on sellised laevad väga kõrgete ametnike kingitused, kes panevad selle endale riiulile nagu sümboli, märk. Kui sellise inimese, nagu suure ettevõtte juhi või kõrge ametniku, lipuna seisab midagi nii halba, mille kaela on lõigatud? Küll oleks parem, kui ta sellest kunagi ei angle. Nii et kuidas neid laevu siiski tehakse, et need saaks annetada olulisele inimesele?

Ainult üks koht, millega tõeliselt midagi teha ei saa, on korpus. Ja laeva korpus läbib just pudeli kaela. Samal ajal kui laev koostatakse pudelist väljaspool. Kuid laeva kokkupanemine ei ole lihtsalt asi, see on tõeline juveliiri käsitöö. Koosseisu lisatakse spetsiaalsed käepidemed, mis võimaldavad neid hiljem üles tõsta. Näiteks pannakse purjed kokku, kantakse ettevaatlikult sisse ja seejärel tõmmatakse neid pintsettide abil väga peenelt, täpselt üles. Tulemuseks on kunstiteos, mille võib puhta südamega ja uhkusega kingituseks anda.

Ja kui soovime, et projekt oleks edukas, peaks meeskonnas olema vähemalt üks kunstnik. Keegi, kes hoolib toote kvaliteedist ja arvestab kõiki aspekte, mitte ei ohverda ühtki isegi pingelistes olukordades, kui asjaolud nõuavad kiiret, kuid tähtsa arvelt. Kõik edukad projektid, mis on jätkusuutlikud ja ajaproovile vastu pidanud, on ehitatud selle põhimõtte peale. Neis on midagi väga täpset ja ainulaadset, midagi, mis kasutab kõiki võimalikke ressursse. Laevatootmise näites pudelis mängitakse sellega, et laeva korpus tuleb läbi kaela.

Tagasi tulles meie vahemäluserveri valiku ülesande juurde, kuidas saaks seda meetodit rakendada? Ma pakun sellist varianti kõigi süsteemide hulgast — mitte pudelit raputada ja mitte valida, vaid vaadata, mis neil üldiselt on, millele tähelepanu pöörata süsteemi valimisel.

Kus otsida pudeli kaela?

Proovime mitte pudelit raputada ega kõike ükshaaval üle vaadata, vaid vaatame, millised ülesanded tekivad, kui üritame disainida sellise süsteemi ise. Me ei hakka jalgratast leiutama, kuid kasutame seda skeemi, et suunata, millele toote kirjeldustes tähelepanu pöörata. Joonistame sellise skeemi.

Kui süsteem on jaotatud, siis on meil mitu serverit (6). Oletame, et neid on neli (mis on pildil mugavalt paigutatavad, kuid neid võib olla ka rohkem). Kui serverid asuvad erinevates sõlmedes, siis töötab kõigil mingisugune kood, mis vastutab selle eest, et need sõlmed moodustaksid klastri ja vajadusel ühenduksid ning üksteist tunneksid.

Vaja on ka koodiloogikat (2), mis tegelikult tegeleb vahemäljega. Selle koodiga suhtlevad kliendid teatud API kaudu. Kliendi kood (1) võib olla nii selle sama JVM-i raames, kui ka suhelda sellega võrgus. Siseselt rakendatud loogika tähendab, milliseid objekte vahemikus hoida ja milliseid välja visata. Vahemälu hoidmiseks kasutame mälu (3), kuid vajadusel saame osa andmeid ka kettale salvestada (4).

Vaadakem, millistes osades koormus tekkib. Tegelikult koormatakse iga nool ja iga sõlm. Esiteks, kui see on võrguühendus, siis kliendi koodi ja API vahel võib nähtav jõudluse langus olla märgatav. Teiseks, API enda raames — kui loogika läheb liiga keeruliseks, võime jõuda CPU piiri. Ja oleks hea, kui loogika ei ajaks mälu alusetult ringi. Jääb veel suhtlemine failisüsteemiga – tavalises variandis on see serialiseerimine/kordus ja kirjutamine/lugemine.

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

Nüüd, ühest küljest – saame kujutada, "millised hammasrattaid pööratakse" vahemälu süsteemis meie koodi päringute töötlemisel, ja teisest küljest – saame hinnata, kui palju ja milliseid päringuid meie kood sellele süsteemile genereerib. Seda on piisavalt, et teha enam-vähem ratsionaalne valik – leida süsteem meie kasutusvariandi jaoks.

Hazelcast

Vaadake, kuidas seda jaotust meie loendile rakendada. Näiteks, Hazelcast.

Andmete paigutamiseks/saamiseks Hazelcastis pöördub klientkood (1) api poole. Hz võimaldab serveri käivitada embedded-režiimis, ja sel juhul on pöördumine api - meetodi väljakutse JVM-s, mida võib pidada tasuta.

Et loogika (2) toimiks, toetub Hz serialiseeritud võtme baitmassivale hash'ile - see tähendab, et võtme serialiseerimine toimub igal juhul. See on Hz jaoks vältimatu overhead.
Eviction-strateegiad on hästi ellu viidud, kuid erijuhtudel on võimalik lisada oma. Selle pärast muretsemine pole vajalik.

Salvestusruumi (4) saab ühendada. Suurepärane. Interaktsioon (5) embedded-režiimis võib pidada koheseks. Andmevahetus sõlmede vahel klastris (6) - jah, see on olemas. See on panus kõlblikkuse ja töökindluse nimel kiirusel. Hz-funktsioon Near-cache aitab vähendada kulusid - teistelt klastrisõlmedelt saadud andmed salvestatakse vahemällu.

Mida sellistes tingimustes kiirusetõstmiseks teha?

Näiteks, et vältida võtme serialiseerimist (2) - Hazelcasti peale lisada veel üks vahemälu kõige kuumemate andmete jaoks. Sportmasteris valiti selle eesmärgi saavutamiseks Caffeine.

Selleks, et kohandada tasemel (6) Hz-is, pakutakse kahte tüüpi salvestamist: IMap ja ReplicatedMap.


Oluline on rääkida, kuidas Hazelcast sattus Sportmasteri tehnoloogiastakisse.

2012. aastal, kui töötasime tulevase veebisaidi esimese prototüübi kallal, oli Hazelcast esimene link, mille otsingumootor väljastas. Meie tutvumine algas "esimesest korrast" — see, et ta töötas vaid kahe tunni pärast, kui olime Hz-süsteemi integreerinud, oli meie jaoks suur üllatus. Ja see töötas hästi. Päeva lõpuks olime kirjutanud mitu testi ja olime rahul. Seda energiat jätkus, et ületada aega jooksul ilmunud üllatused, mida Hz esitas. Nüüd ei ole Sportmasteri meeskonnal mingit põhjust Hazelcastist loobuda.

Kuid argumendid nagu "esimene link otsingumootoris" ja "kiire HelloWorldi kogumine" on muidugi erand ja hetkede eripära, milles valik toimus. Tõelised katsumused valitud süsteemi jaoks algavad, kui see jõuab tootmisesse, ja just sellele etapile tasub tähelepanu pöörata, valides mistahes süsteemi, sealhulgas vahemälu. Tegelikult võib öelda, et valisime Hazelcasti juhuslikult, kuid hiljem selgus, et tegime õigesti.

Tootmise erilise tähelepanuta: jälgimine, tõrgete töötlemine üksikutes sõlmedes, andmete replikatsioon ja skaleerimise kulud. Teisisõnu, tasub tähelepanu pöörata probleemidele, mis tekivad just süsteemi hooldamisel — kui koormus ületab korduvalt plaanitud taset, kui laadime kogemata sisse vale sisu ja vale koht, või kui on vaja väljendada uut koodiversiooni, andmeid vahetada ja teha seda klientidele märkamatuks.

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

Jätkub

Kuid Hazelcast ei ole imerohi. 2017. aastal valisime Hazelcasti administraatori vaates mälupuhvriks, tuginedes lihtsalt varasema hea kogemuse muljele. See mängis olulist rolli väga kurva nalja tõttu, mis viis meid keerulisse olukorda, millest väljumine kestis „kangelaslikult“ 60 päeva. Kuid sellest räägime järgmises osas.

Aga seni… Head uut koodi!

Allikas: habr.com