Tere! Minu nimi on Aleksei Pyankov, olen arendaja ettevõttes Sportmaster. Selles Rääkisin, kuidas 2012. aastal töö Sportmasteri veebilehel alguse sai, milliseid algatusi õnnestus “läbi suruda” ja vastupidi, mis reha kogusime.
Täna tahan jagada mõtteid, mis järgivad teist teemat – vahemälusüsteemi valimine java taustaprogrammi jaoks saidi administraatorialas. Sellel süžeel on minu jaoks eriline tähendus - kuigi lugu rullus lahti vaid 2 kuud, siis selle 60 päeva jooksul töötasime 12-16 tundi ja ilma ühegi puhkepäevata. Ma polnud kunagi mõelnud ega ette kujutanud, et on võimalik nii palju tööd teha.
Seetõttu jagasin teksti kaheks osaks, et mitte täielikult laadida. Vastupidi, esimene osa tuleb väga kerge – ettevalmistus, sissejuhatus, mõned kaalutlused selle kohta, mis vahemällu salvestamine on. Kui olete juba kogenud arendaja või vahemäludega töötanud, pole tehnilisest küljest selles artiklis tõenäoliselt midagi uut. Kuid juuniori jaoks võib selline väike ülevaade öelda, millises suunas vaadata, kui ta sellisele ristteele satub.
Kui Sportmasteri veebilehe uus versioon tootmisse pandi, saadi andmed kätte nii, et see polnud pehmelt öeldes kuigi mugav. Aluseks olid saidi eelmise versiooni (Bitrix) jaoks koostatud tabelid, mis tuli tõmmata ETL-i, viia uuele kujule ja rikastada erinevate pisiasjadega veel kümnekonnast süsteemist. Selleks, et uus pilt või tootekirjeldus saidile ilmuks, tuli oodata järgmise päevani - uuendused ainult öösel, kord päevas.
Esialgu oli esimestest tootmisnädalatest muret nii palju, et sisuhaldurite jaoks olid sellised ebamugavused tühiasi. Kuid niipea, kui kõik lahenes, jätkus projekti arendamine - paar kuud hiljem, 2015. aasta alguses, hakkasime aktiivselt arendama administraatoripaneeli. Aastatel 2015 ja 2016 läheb kõik hästi, avaldame regulaarselt, administraatoripaneel katab üha rohkem andmete ettevalmistamist ja valmistume selleks, et peagi usaldatakse meie meeskonnale kõige olulisem ja keerulisem - toode ahel (kõikide toodete andmete täielik ettevalmistamine ja hooldus). Kuid 2017. aasta suvel, vahetult enne kaubaahela käivitamist, satub projekt väga keerulisse olukorda - just vahemällu salvestamise probleemide tõttu. Ma tahan sellest episoodist rääkida selle kaheosalise väljaande teises osas.
Aga selles postituses alustan kaugemalt, esitan mõned mõtted - ideed cachingu kohta, mida oleks hea samm enne suurt projekti kerida.
Kui toimub vahemällu salvestamise ülesanne
Vahemällu salvestamise ülesanne ei ilmu lihtsalt. Oleme arendajad, kirjutame tarkvaratoodet ja tahame, et selle järele oleks nõudlus. Kui toode on nõutud ja edukas, tulevad kasutajad. Ja neid tuleb aina juurde. Ja siis on palju kasutajaid ja siis on toode väga koormatud.
Esimestel etappidel me ei mõtle optimeerimisele ja koodi jõudlusele. Peaasi on funktsionaalsus, pilootprojekti kiire väljatöötamine ja hüpoteeside testimine. Ja kui koormus suureneb, pumpame raua üles. Suurendame seda kaks või kolm korda, viis korda, võib-olla 10 korda. Kuskil siin – rahandus seda enam ei võimalda. Mitu korda kasvab kasutajate arv? See ei ole nagu 2-5-10, kuid kui see õnnestub, on see 100-1000 kuni 100 tuhat korda. See tähendab, et varem või hiljem peate optimeerima.
Oletame, et mingi osa koodist (nimetagem seda osa funktsiooniks) võtab sündsusetult kaua aega ja me tahame täitmisaega lühendada. Funktsioon võib olla juurdepääs andmebaasile või mõne keerulise loogika täitmine – peaasi, et selle täitmine võtab kaua aega. Kui palju saate täitmisaega lühendada? Limiidi korral saate selle nullini vähendada, mitte rohkem. Kuidas saate täitmisaega nullini vähendada? Vastus: täitmine üldse ära kaotada. Selle asemel tagastage tulemus kohe. Kuidas tulemust teada saada? Vastus: kas arvuta või vaata kuskilt. Arvutamine võtab kaua aega. Ja nuhkimine tähendab näiteks tulemuse meeldejätmist, mille funktsioon viimati samade parameetritega kutsudes andis.
See tähendab, et funktsiooni rakendamine pole meie jaoks oluline. Piisab lihtsalt teadmisest, millistest parameetritest tulemus sõltub. Seejärel, kui parameetrite väärtused on esitatud objekti kujul, mida saab mõnes salvestusruumis võtmena kasutada, saab arvutuse tulemuse salvestada ja järgmisel korral välja lugeda. Kui see tulemuse kirjutamine ja lugemine on kiirem kui funktsiooni täitmine, on meil kiiruse mõttes kasum. Kasumi suurus võib ulatuda 100, 1000 ja 100 tuhande korrani (10^5 on pigem erand, kuid üsna mahajäänud baasi puhul on see täiesti võimalik).
Vahemälusüsteemi põhinõuded
Esimene asi, mis vahemällu salvestamisel võib nõudeks saada, on kiire lugemiskiirus ja veidi vähemal määral ka kirjutamiskiirus. See on tõsi, kuid ainult seni, kuni me süsteemi tootmisse laseme.
Mängime seda juhtumit.
Oletame, et oleme varustanud praeguse koormuse riistvaraga ja võtame nüüd järk-järgult kasutusele vahemälu. Kasutajate arv kasvab veidi, koormus kasvab - lisame veidi vahemälu, keerame siia-sinna sisse. See jätkub mõnda aega ja nüüd raskeid funktsioone praktiliselt enam ei kutsuta - kogu põhikoormus langeb vahemällu. Kasutajate arv on selle aja jooksul kasvanud N korda.
Ja kui algne riistvara varu võiks olla 2-5 korda, siis vahemälu abil saaksime jõudlust parandada 10 korda või heal juhul 100 korda, mõnel pool ehk kordagi 1000. See tähendab, et samal riistvaral – töötleme 100 korda rohkem taotlusi. Suurepärane, sa väärid piparkooke!
Nüüd aga kukkus ühel ilusal hetkel süsteem juhuslikult kokku ja vahemälu varises kokku. Ei midagi erilist - lõppude lõpuks valiti vahemälu nõudest "suur lugemis- ja kirjutamiskiirus, muul pole tähtsust."
Võrreldes stardikoormusega oli meie rauavaru 2-5 korda ja koormus kasvas selle aja jooksul 10-100 korda. Vahemälu kasutades kõrvaldasime raskete funktsioonide kõned ja seetõttu kõik töötas. Ja nüüd, ilma vahemäluta, mitu korda meie süsteem aeglustub? Mis meist saab? Süsteem kukub.
Isegi kui meie vahemälu ei jooksnud kokku, vaid kustutati vaid mõneks ajaks, tuleb seda soojendada ja see võtab natuke aega. Ja selle aja jooksul langeb põhikoormus funktsionaalsusele.
Järeldus: suure koormusega tootmisprojektid nõuavad vahemällu salvestamise süsteemi mitte ainult suure lugemis- ja kirjutamiskiiruse tagamiseks, vaid ka selleks, et tagada andmete turvalisus ja vastupidavus tõrgetele.
Valik jahu
Administraatoripaneeliga projektis läks valik nii: esmalt paigaldasime Hazelcasti, sest Oleme selle tootega juba põhisaidi kogemusest tuttavad. Kuid siin osutus see valik ebaõnnestunuks - meie koormusprofiili all ei ole Hazelcast lihtsalt aeglane, vaid kohutavalt aeglane. Ja sel ajal olime juba ilmumiskuupäevaks registreerunud.
Spoiler: kuidas täpselt kujunesid asjaolud, et me nii suurest asjast ilma jäime ja ägeda ja pingelise olukorrani sattusime - räägin teile teises osas - ning kuidas me sattusime ja kuidas välja pääsesime. Aga nüüd - ma ütlen lihtsalt, et see oli palju stressi ja "mõelda - ma ei suuda kuidagi mõelda, me raputame pudelit." “Pudeli raputamine” on samuti spoiler, sellest hiljem.
Mida me tegime:
- Koostame nimekirja kõigist süsteemidest, mida Google ja StackOverflow soovitavad. Natuke üle 30
- Kirjutame testid tootmisele omase koormusega. Selleks salvestasime tootmiskeskkonnas süsteemi läbivad andmed – omamoodi andmete nuusutaja mitte võrgus, vaid süsteemi sees. Täpselt neid andmeid kasutati testides.
- Kogu meeskonnaga valivad kõik loendist järgmise süsteemi, konfigureerivad selle ja testivad. See ei läbi testi, ei kanna koormust – viskame selle minema ja liigume järjekorras järgmise juurde.
- 17. süsteemil sai selgeks, et kõik on lootusetu. Lõpetage pudeli raputamine, on aeg tõsiselt mõelda.
Kuid see on valik, kui peate valima süsteemi, mis eelnevalt ettevalmistatud testides "kiiruse ületab". Mis siis, kui selliseid teste veel pole ja soovite kiiresti valida?
Simuleerime seda võimalust (raske on ette kujutada, et keskmine+ arendaja elab vaakumis ja ei ole valiku hetkel veel vormistanud oma eelistust, millist toodet esimesena proovida – seetõttu on edasine arutluskäik pigem teoreetik/filosoofia/ juuniori kohta).
Olles otsustanud nõuete üle, hakkame välja valima lahendust. Miks ratast uuesti leiutada: me läheme ja võtame valmis vahemälusüsteemi.
Kui sa alles alustad ja googeldad, siis anna või võta tellimus, aga üldiselt on juhised sellised. Esiteks satute Redisega kokku, seda kuuleb igal pool. Siis saate teada, et EhCache on vanim ja end tõestanud süsteem. Järgmisena kirjutame Tarantoolist, kodumaisest arendusest, millel on lahenduse unikaalne aspekt. Ja ka Ignite, sest see on nüüd populaarsuse tõusuteel ja naudib SberTechi tuge. Lõpus on ka Hazelcast, sest ettevõtlusmaailmas esineb see sageli suurettevõtete seas.
Loetelu ei ole ammendav, süsteeme on kümneid. Ja me rikume ainult ühe asja. Võtame “iludusvõistluse” jaoks valitud 5 süsteemi ja teeme valiku. Kes saab võitjaks?
Redis
Lugesime, mida nad ametlikul veebisaidil kirjutavad.
- avatud lähtekoodiga projekt. Pakub mälusisest andmesalvestust, kettale salvestamise võimalust, automaatset partitsiooni, kõrget kättesaadavust ja võrgukatkestuste taastumist.
Tundub, et kõik on korras, võid võtta ja kruvida - kõik, mis vaja, teeb. Aga nalja pärast vaatame teisi kandidaate.
EhCache
- "Java jaoks kõige laialdasemalt kasutatav vahemälu" (loosungi tõlge ametlikult veebisaidilt). Samuti avatud lähtekoodiga. Ja siis saame aru, et Redis pole mitte Java jaoks, vaid üldine ja sellega suhtlemiseks on vaja ümbrist. Ja EhCache on mugavam. Mida süsteem veel lubab? Usaldusväärsus, tõestatud, täielik funktsionaalsus. Noh, see on ka kõige levinum. Ja salvestab vahemällu terabaite andmeid.
Redis on unustatud, olen valmis EhCache'i valima.
Kuid patriotismi tunne sunnib mind nägema, mis on Tarantoolis head.
Tarantool
- vastab tähistusele “Reaalajas andmete integreerimise platvorm”. See kõlab väga keeruliselt, nii et lugesime lehte üksikasjalikult ja leiame valju lause: "Häilib 100% RAM-i andmetest." See peaks tekitama küsimusi – lõppude lõpuks võib andmeid olla palju rohkem kui mälu. Seletus seisneb selles, et see tähendab, et Tarantool ei käivita serialiseerimist andmete mälust kettale kirjutamiseks. Selle asemel kasutab see süsteemi madala taseme funktsioone, kui mälu on lihtsalt vastendatud failisüsteemiga, millel on väga hea I/O jõudlus. Üldiselt tegid nad midagi imelist ja lahedat.
Vaatame rakendusi: Mail.ru ettevõtte kiirtee, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...
Kui Tarantooli osas oli veel kahtlusi, siis Mastercardi juurutusjuhtum lõpetab mind. Ma võtan Tarantooli.
Aga igatahes…
Süttima
… kas on veel , on arveldatud kui "mälusisene andmetöötlusplatvorm... mälusisene kiirus petabaitide andmetel." Siin on ka palju eeliseid: hajutatud mälu vahemälu, kiireim võtmeväärtuste salvestus ja vahemälu, horisontaalne skaleerimine, kõrge kättesaadavus, range terviklikkus. Üldiselt selgub, et kõige kiirem on Ignite.
Rakendused: Sberbank, American Airlines, Yahoo! Jaapan. Ja siis avastan, et Ignite ei ole lihtsalt Sberbankis juurutatud, vaid SberTechi meeskond saadab oma inimesed ise Ignite'i meeskonda toodet täiustama. See on täiesti kütkestav ja ma olen valmis Ignite'i võtma.
On täiesti ebaselge, miks, ma vaatan viiendat punkti.
sarapuu
Ma lähen saidile , lugemine. Ja selgub, et kiireim lahendus hajutatud vahemällu salvestamiseks on Hazelcast. See on suurusjärgus kiirem kui kõik teised lahendused ja üldiselt on see liider mälusiseste andmevõrgustike valdkonnas. Selle taustal millegi muu võtmine ei tähenda ennast austada. Samuti kasutab see üleliigset andmesalvestust klastri pidevaks tööks ilma andmete kadumiseta.
See on kõik, ma olen valmis Hazelcasti võtma.
Võrdlus
Aga kui vaadata, siis kõik viis kandidaati on kirjeldatud nii, et igaüks neist on parim. Kuidas valida? Saame vaadata, milline neist on populaarseim, otsida võrdlusi ja peavalu kaob.
Leiame ühe sellise , valige meie 5 süsteemi.
Siin on need sorteeritud: Redis on tipus, Hazelcast teisel kohal, Tarantool ja Ignite koguvad populaarsust, EhCache on olnud ja jääb samaks.
Aga vaatame : lingid veebisaitidele, üldine huvi süsteemi vastu, tööpakkumised – suurepärane! See tähendab, et kui mu süsteem ebaõnnestub, ütlen: "Ei, see on usaldusväärne! Tööpakkumisi on palju..." Selline lihtne võrdlus ei aita.
Kõik need süsteemid ei ole ainult vahemällu salvestavad süsteemid. Neil on ka palju funktsionaalsust, sealhulgas siis, kui andmeid ei pumbata kliendile töötlemiseks, vaid vastupidi: kood, mis tuleb andmetel täita, liigub serverisse, käivitatakse seal ja tulemus tagastatakse. Ja neid ei peeta nii sageli vahemällu salvestamiseks eraldi süsteemiks.
Olgu, ärgem heitkem alla, leidkem otsene süsteemide võrdlus. Võtame kaks parimat varianti – Redis ja Hazelcast. Meid huvitab kiirus ja me võrdleme neid selle parameetri alusel.
Hz vs Redis
Leiame selle :
Sinine on Redis, punane on Hazelcast. Hazelcast võidab kõikjal ja sellel on ka põhjus: see on mitme lõimega, väga optimeeritud, iga lõim töötab oma partitsiooniga, seega pole blokeerimist. Ja Redis on ühe keermega; see ei saa kasu kaasaegsetest mitmetuumalistest protsessoritest. Hazelcastil on asünkroonne I/O, Redis-Jedis on blokeerivad pesad. Lõppude lõpuks kasutab Hazelcast binaarprotokolli ja Redis on tekstikeskne, mis tähendab, et see on ebaefektiivne.
Pöördume igaks juhuks mõne teise võrdlusallika juurde. Mida ta meile näitab?
Redis vs Hz
Teine :
Siin, vastupidi, punane on Redis. See tähendab, et Redis edestab jõudluse poolest Hazelcasti. Esimese võrdluse võitis Hazelcast, teise Redis. selgitas väga täpselt, miks Hazelcast eelmise võrdluse võitis.
Selgub, et esimese tulemus oli tegelikult võltsitud: Redis võeti aluskasti ja Hazelcast kohandati katsejuhtumi jaoks. Siis selgub: esiteks ei saa me kedagi usaldada ja teiseks, kui me lõpuks süsteemi valime, peame selle ikkagi õigesti konfigureerima. Need seaded sisaldavad kümneid, peaaegu sadu parameetreid.
Pudelit raputades
Ja ma saan seletada kogu protsessi, mille oleme nüüd teinud järgmise metafooriga: "Pudeli raputamine". See tähendab, et nüüd ei pea te programmeerima, nüüd on peamine, et saaksite stackoverflow't lugeda. Ja minu meeskonnas on inimene, professionaal, kes töötab kriitilistel hetkedel täpselt nii.
Mida ta teeb? Ta näeb katkist asja, näeb virna jälge, võtab sealt mõned sõnad (millised on tema asjatundlikkus programmis), otsib Google'ist, leiab vastuste hulgast stackoverflow. Lugemata, mõtlemata valib ta küsimuse vastuste hulgast midagi, mis on kõige sarnasem lausele “tee seda ja teist” (sellise vastuse valimine on tema talent, sest mitte alati pole see vastus, mis sai kõige rohkem meeldimisi), kehtib , näeb välja: kui midagi on muutunud, siis suurepärane. Kui see pole muutunud, keerake see tagasi. Ja korrake käivitamist-kontrolli-otsingut. Ja sel intuitiivsel viisil tagab ta, et kood mõne aja pärast töötab. Ta ei tea, miks, ta ei tea, mida ta tegi, ta ei oska seletada. Aga! See infektsioon toimib. Ja "tuli on kustunud." Nüüd mõtleme välja, mida me tegime. Kui programm töötab, on see suurusjärgu võrra lihtsam. Ja see säästab palju aega.
Seda meetodit selgitatakse selle näitega väga hästi.
Kunagi oli väga populaarne koguda purjekat pudelisse. Samas on purjekas suur ja habras ning pudelikael väga kitsas, sisse lükata ei saa. Kuidas seda kokku panna?
On selline meetod, väga kiire ja väga tõhus.
Laev koosneb hunnikust pisiasjadest: pulgad, köied, purjed, liim. Panime kõik selle pudelisse.
Võtame pudeli kahe käega ja hakkame raputama. Me raputame ja raputame teda. Ja tavaliselt osutub see muidugi täielikuks prügiks. Aga mõnikord. Mõnikord osutub see laevaks! Täpsemalt midagi laeva sarnast.
Näitame seda kellelegi: "Seryoga, kas näete!?" Ja tõepoolest, kaugelt näeb see välja nagu laev. Kuid sellel ei saa lubada jätkuda.
On veel üks viis. Neid kasutavad arenenumad mehed, näiteks häkkerid.
Andsin sellele tüübile ülesande, ta tegi kõik ära ja lahkus. Ja sa vaatad – tundub, et see on tehtud. Ja mõne aja pärast, kui kood vajab lõplikku viimistlemist, algab see tema pärast... Hea, et ta on juba suutnud kaugele joosta. Need on poisid, kes pudeli näitel teevad seda: näete, kus on põhi, seal klaas paindub. Ja pole täiesti selge, kas see on läbipaistev või mitte. Siis lõikavad “häkkerid” selle põhja ära, torkavad sinna laeva, siis liimivad põhja uuesti kinni ja nii see peakski olema.
Probleemi püstitamise seisukohalt tundub kõik õige olevat. Aga näitena laevu kasutades: milleks seda laeva üldse teha, kellele seda ikkagi vaja on? See ei paku ühtegi funktsiooni. Tavaliselt on sellised laevad kingituseks väga kõrgetele inimestele, kes panevad selle enda kohale riiulile, mingisuguseks sümboliks, märgiks. Ja kui selline inimene, suurettevõtte juht või kõrge ametnik, siis kuidas lipp sellisele häkkimisele, mille kael on ära lõigatud? Parem oleks, kui ta sellest kunagi ei teaks. Niisiis, kuidas nad lõpuks teevad neid laevu, mida saab kinkida olulisele inimesele?
Ainus võtmekoht, millega te tõesti midagi peale hakata ei saa, on keha. Ja laeva kere mahub otse kaela. Kusjuures laev on kokku pandud väljaspool pudelit. Kuid see pole lihtsalt laeva kokkupanek, see on tõeline ehtekunst. Komponentidele on lisatud spetsiaalsed hoovad, mis võimaldavad neid seejärel tõsta. Näiteks purjed volditakse kokku, tuuakse ettevaatlikult sisse ja siis pintsettide abil tõmmatakse ja tõstetakse need väga täpselt, täpselt üles. Tulemuseks on kunstiteos, mille saab kinkida puhta südametunnistuse ja uhkusega.
Ja kui tahame, et projekt õnnestuks, peab meeskonnas olema vähemalt üks juveliir. Keegi, kes hoolib toote kvaliteedist ja arvestab kõigi aspektidega, ilma midagi ohverdamata, isegi stressihetkedel, kui asjaolud nõuavad kiireloomulist tegemist olulise arvelt. Sellel põhimõttel on üles ehitatud kõik edukad projektid, mis on jätkusuutlikud, mis on ajaproovile vastu pidanud. Nendes on midagi väga täpset ja ainulaadset, midagi, mis kasutab ära kõik olemasolevad võimalused. Näites, kus laev on pudelis, mängitakse läbi asjaolu, et laeva kere läbib kaela.
Tulles tagasi meie vahemällu salvestamise serveri valimise ülesande juurde, kuidas seda meetodit rakendada? Pakun seda võimalust valida kõigi olemasolevate süsteemide hulgast - ära raputa pudelit, ära vali, vaid vaata, mis neil põhimõtteliselt on, mida süsteemi valikul otsida.
Kust pudelikaela otsida
Püüdkem mitte pudelit raputada, mitte ükshaaval kõike, mis seal on, läbi käia, vaid vaatame, millised probleemid tekivad, kui äkki oma ülesande jaoks ise sellise süsteemi kujundame. Loomulikult me jalgratast kokku ei pane, kuid kasutame seda diagrammi, mis aitab meil välja selgitada, millistele punktidele tootekirjelduses tähelepanu pöörata. Visandame sellise diagrammi.
Kui süsteem on hajutatud, on meil mitu serverit (6). Oletame, et neid on neli (neid on mugav pildile paigutada, kuid loomulikult võib neid olla nii palju, kui soovite). Kui serverid asuvad erinevates sõlmedes, tähendab see, et nad kõik käitavad mingit koodi, mis vastutab selle eest, et need sõlmed moodustaksid klastri ning katkemise korral ühenduse loovad ja üksteist ära tunnevad.
Vajame ka koodiloogikat (2), mis on tegelikult seotud vahemällu salvestamisega. Kliendid suhtlevad selle koodiga mõne API kaudu. Kliendikood (1) võib asuda kas samas JVM-is või pääseda sellele juurde võrgu kaudu. Sees rakendatav loogika on otsus, millised objektid jätta vahemällu ja millised välja visata. Vahemälu salvestamiseks kasutame mälu (3), kuid vajadusel saame salvestada osa andmetest kettale (4).
Vaatame, millistes osades koormus tekib. Tegelikult laaditakse iga nool ja iga sõlm. Esiteks, kliendi koodi ja api vahel, kui see on võrguühendus, võib vajumine olla üsna märgatav. Teiseks, api enda raames – kui keerulise loogikaga liialdada, võib tekkida probleeme protsessoriga. Ja oleks tore, kui loogika ei raiskaks aega mälule. Ja failisüsteemiga suhtlemine jääb alles - tavalises versioonis on see järjestamine / taastamine ja kirjutamine / lugemine.
Järgmine on interaktsioon klastriga. Tõenäoliselt on see samas süsteemis, kuid see võib olla eraldi. Siin peate arvestama ka andmete edastamisega sellele, andmete serialiseerimise kiirusega ja klastri vaheliste interaktsioonidega.
Nüüd saame ühest küljest ette kujutada, “millised käigud pöörduvad” vahemälusüsteemis, kui töötleme meie koodist päringuid, ja teisest küljest saame hinnata, milliseid ja kui palju päringuid meie kood sellele süsteemile genereerib. Sellest piisab, et teha enam-vähem kaine valik – valida meie kasutusjuhule sobiv süsteem.
sarapuu
Vaatame, kuidas seda lagunemist meie loendis rakendada. Näiteks Hazelcast.
Hazelcastist andmete panemiseks/võtmiseks pääseb kliendikood juurde (1) API-le. Hz võimaldab teil serverit sisseehitatud kujul käivitada ja sel juhul on API-le juurdepääs JVM-i sees meetodikõne, mida võib pidada tasuta.
Et loogika punktis (2) töötaks, toetub Hz jadavõtme baidimassiivi räsi - see tähendab, et võti jadatakse igal juhul. See on Hz jaoks paratamatu.
Väljatõstmisstrateegiaid rakendatakse hästi, kuid erijuhtudel saate lisada oma. Te ei pea selle osa pärast muretsema.
Salvesti (4) saab ühendada. Suurepärane. Manustatud interaktsiooni (5) võib pidada koheseks. Andmevahetus klastri (6) sõlmede vahel – jah, see on olemas. See on investeering veataluvusse kiiruse arvelt. Hz funktsioon Near-cache võimaldab hinda alandada – klastri teistelt sõlmedelt saadud andmed salvestatakse vahemällu.
Mida saab sellistes tingimustes teha kiiruse suurendamiseks?
Näiteks võtme (2) järjestamise vältimiseks - lisage kuumimate andmete jaoks teine vahemälu Hazelcasti peale. Sportmaster valis selleks otstarbeks Caffeine.
Tasemel (6) keeramiseks pakub Hz kahte tüüpi salvestusruumi: IMap ja ReplicatedMap.
Tasub mainida, kuidas Hazelcast sattus Sportmasteri tehnoloogiavirna.
2012. aastal, kui töötasime tulevase saidi esimese pilootprojekti kallal, osutus Hazelcast esimeseks lingiks, mille otsingumootor tagastas. Tutvus algas “esimest korda” – meid köitis tõsiasi, et vaid kaks tundi hiljem, kui Hz süsteemi keerasime, see töötas. Ja see töötas hästi. Päeva lõpuks olime läbinud mitmeid teste ja olime rahul. Ja sellest jõuvarust piisas, et saada üle ootamatustest, mida Hz aja jooksul õhku pani. Nüüd pole Sportmasteri meeskonnal põhjust Hazelcasti hüljata.
Kuid sellised argumendid nagu "otsingumootori esimene link" ja "HelloWorld pandi kiiresti kokku" on loomulikult erand ja valiku tegemise hetke tunnus. Valitud süsteemi tegelikud testid algavad tootmisse vabastamisega ja just selles etapis peaksite pöörama tähelepanu mis tahes süsteemi, sealhulgas vahemälu, valimisel. Tegelikult võib meie puhul öelda, et valisime Hazelcasti juhuslikult, aga siis selgus, et valisime õigesti.
Tootmise jaoks palju olulisem: jälgimine, üksikute sõlmede rikete käsitlemine, andmete replikatsioon, skaleerimise maksumus. See tähendab, et tasub pöörata tähelepanu ülesannetele, mis tekivad süsteemi hoolduse käigus - kui koormus on kümneid kordi suurem kui planeeritud, kui laadime midagi kogemata valesse kohta, kui vajame uut versiooni. koodi, asendage andmed ja tehke seda klientide jaoks märkamatult.
Kõigi nende nõuete puhul sobib Hazelcast kindlasti selle arvega.
Jätkub
Kuid Hazelcast pole imerohi. 2017. aastal valisime administraatori vahemällu Hazelcasti, tuginedes lihtsalt varasemast kogemusest saadud headele muljetele. See mängis võtmerolli ühes väga julmas naljas, mille tõttu sattusime raskesse olukorda ja pääsesime sellest “kangelaslikult” 60 päevaks välja. Aga sellest pikemalt järgmises osas.
Seniks aga... Head uut koodi!
Allikas: www.habr.com