Hei! Nimeni on Aleksei Pyankov, olen kehittäjä Sportmaster-yrityksessä. Siinä Kerroin, miten työ Sportmaster-verkkosivustolla alkoi vuonna 2012, mitä aloitteita onnistuimme "työntämään" ja päinvastoin, mitä rakea keräsimme.
Tänään haluan jakaa ajatuksia, jotka seuraavat toista aihetta - välimuistijärjestelmän valitsemista java-taustajärjestelmälle sivuston hallintapaneelissa. Tällä juonella on minulle erityinen merkitys - vaikka tarina eteni vain 2 kuukautta, teimme näiden 60 päivän aikana töitä 12-16 tuntia ja ilman ainuttakaan vapaapäivää. En ollut koskaan ajatellut tai kuvitellut, että on mahdollista tehdä niin paljon töitä.
Siksi jaoin tekstin kahteen osaan, jotta en lataa sitä kokonaan. Päinvastoin, ensimmäinen osa on erittäin kevyt - valmistelu, esittely, joitain huomioita siitä, mitä välimuisti on. Jos olet jo kokenut kehittäjä tai olet työskennellyt välimuistien kanssa, tekniseltä puolelta tässä artikkelissa ei todennäköisesti ole mitään uutta. Mutta juniorille tällainen pieni arvostelu voi kertoa, mihin suuntaan hänen pitää katsoa, jos hän joutuu sellaiseen risteykseen.
Kun Sportmaster-sivuston uusi versio otettiin tuotantoon, tiedot vastaanotettiin tavalla, joka ei ollut lievästi sanottuna kovin kätevää. Perustana olivat sivuston edelliseen versioon (Bitrix) valmistetut taulukot, jotka piti vetää ETL:ään, viedä uuteen muotoon ja rikastaa erilaisilla pikkuasioilla kymmenestä muusta järjestelmästä. Jotta uusi kuva tai tuotekuvaus ilmestyisi sivustolle, piti odottaa seuraavaan päivään - päivityksiä vain yöllä, kerran päivässä.
Aluksi tuotantoon siirtymisen ensimmäisistä viikoista lähtien oli niin paljon huolta, että tällaiset haitat sisällönhaltijoille olivat pikku juttu. Mutta heti kun kaikki ratkesi, projektin kehitys jatkui - muutamaa kuukautta myöhemmin, vuoden 2015 alussa, aloimme aktiivisesti kehittää hallintapaneelia. Vuosina 2015 ja 2016 kaikki menee hyvin, julkaisemme säännöllisesti, hallintapaneeli kattaa yhä enemmän tietojen valmistelua ja valmistaudumme siihen, että pian tiimiimme uskotaan tärkein ja monimutkaisin asia - tuote piiri (kaikkien tuotteiden tietojen täydellinen valmistelu ja ylläpito). Mutta kesällä 2017, juuri ennen hyödykepiirin käynnistämistä, projekti joutuu erittäin vaikeaan tilanteeseen - juuri välimuistiongelmien vuoksi. Haluan puhua tästä jaksosta tämän kaksiosaisen julkaisun toisessa osassa.
Mutta tässä postauksessa aloitan kaukaa, esitän ajatuksia - ideoita välimuistiin, joita olisi hyvä selata ennen isompaa projektia.
Kun välimuistitehtävä tapahtuu
Välimuistitehtävä ei vain näy. Olemme kehittäjiä, kirjoitamme ohjelmistotuotteen ja haluamme, että sillä on kysyntää. Jos tuotteelle on kysyntää ja se menestyy, käyttäjiä tulee. Ja lisää tulee. Ja sitten on paljon käyttäjiä, ja sitten tuote on erittäin kuormitettu.
Ensimmäisessä vaiheessa emme ajattele optimointia ja koodin suorituskykyä. Pääasia on toimivuus, pilotin nopea käyttöönotto ja hypoteesien testaus. Ja jos kuormitus kasvaa, pumppaamme raudan. Suurennamme sitä kaksi tai kolme kertaa, viisi kertaa, ehkä 10 kertaa. Jossain täällä – talous ei enää salli sitä. Kuinka monta kertaa käyttäjien määrä kasvaa? Se ei ole kuin 2-5-10, mutta onnistuessaan se on 100-1000 - 100 tuhatta kertaa. Eli ennemmin tai myöhemmin sinun on tehtävä optimointi.
Oletetaan, että jokin osa koodista (kutsutaanko tätä osaa funktioksi) kestää kohtuuttoman kauan ja haluamme lyhentää suoritusaikaa. Funktio voi olla pääsy tietokantaan tai se voi olla jonkin monimutkaisen logiikan suorittaminen - pääasia, että sen suorittaminen kestää kauan. Kuinka paljon voit lyhentää suoritusaikaa? Rajassa voit pienentää sen nollaan, ei enempää. Kuinka voit vähentää suoritusaikaa nollaan? Vastaus: poista toteutus kokonaan. Palauta sen sijaan tulos välittömästi. Kuinka voit selvittää tuloksen? Vastaus: joko laske se tai katso jostain. Laskeminen kestää kauan. Ja vakoilu on esimerkiksi sen tuloksen muistamista, jonka funktio tuotti viimeksi, kun sitä kutsuttiin samoilla parametreilla.
Eli toiminnon toteuttaminen ei ole meille tärkeää. Riittää, kun tietää, mistä parametreista tulos riippuu. Sitten, jos parametriarvot esitetään objektin muodossa, jota voidaan käyttää avaimena jossain muistissa, laskennan tulos voidaan tallentaa ja lukea seuraavan kerran, kun sitä käytetään. Jos tämä tuloksen kirjoittaminen ja lukeminen on nopeampaa kuin funktion suorittaminen, meillä on voittoa nopeuden suhteen. Voiton määrä voi olla 100, 1000 ja 100 tuhatta kertaa (10^5 on pikemminkin poikkeus, mutta melko jäljessä olevan pohjan tapauksessa se on täysin mahdollista).
Välimuistijärjestelmän perusvaatimukset
Ensimmäinen asia, josta voi tulla välimuistijärjestelmä, on nopea lukunopeus ja hieman pienemmässä määrin kirjoitusnopeus. Tämä on totta, mutta vain siihen asti, kunnes otamme järjestelmän käyttöön tuotantoon.
Pelataan tämä tapaus.
Oletetaan, että olemme toimittaneet nykyisen kuormituksen laitteistolla ja otamme nyt vähitellen käyttöön välimuistin. Käyttäjien määrä kasvaa hieman, kuormitus kasvaa - lisäämme vähän välimuistia, ruuvaamme sitä sinne tänne. Tämä jatkuu jonkin aikaa, ja nyt raskaita toimintoja ei käytännössä enää kutsuta - koko pääkuorma laskeutuu välimuistiin. Käyttäjien määrä tänä aikana on kasvanut N kertaa.
Ja jos laitteiston alkuperäinen tarjonta voisi olla 2-5-kertainen, niin välimuistin avulla voisimme parantaa suorituskykyä kertoimella 10 tai hyvässä tapauksessa kertoimella 100, paikoin ehkä kertoimella. 1000. Eli samalla laitteistolla – käsittelemme 100 kertaa enemmän pyyntöjä. Hienoa, olet piparkakkujen ansainnut!
Mutta nyt, yhdellä hienolla hetkellä, sattumalta järjestelmä kaatui ja välimuisti romahti. Ei mitään erikoista - loppujen lopuksi välimuisti valittiin vaatimuksen "korkea luku- ja kirjoitusnopeus, muulla ei ole väliä" perusteella.
Lähtökuormaan suhteutettuna rautavaramme oli 2-5-kertainen ja kuormitus tänä aikana kasvoi 10-100-kertaiseksi. Välimuistia käyttämällä poistimme raskaat toiminnot, joten kaikki toimi. Ja nyt, ilman välimuistia, kuinka monta kertaa järjestelmämme hidastuu? Mitä meille tapahtuu? Järjestelmä kaatuu.
Vaikka välimuistimme ei kaatunut, vaan tyhjennettiin vain hetkeksi, se on lämmitettävä, ja tämä kestää jonkin aikaa. Ja tänä aikana suurin taakka laskee toiminnallisuudelle.
Johtopäätös: erittäin kuormitetut tuotantoprojektit edellyttävät välimuistijärjestelmää paitsi korkeiden luku- ja kirjoitusnopeuksien takaamiseksi myös tietojen turvallisuuden ja virheiden kestävyyden takaamiseksi.
Valittu jauho
Projektissa, jossa oli hallintapaneeli, valinta meni näin: ensin asensimme Hazelcastin, koska Tämä tuote oli meille tuttu jo pääsivuston kokemuksesta. Mutta tässä tämä valinta osoittautui epäonnistuneeksi - kuormitusprofiilissamme Hazelcast ei ole vain hidas, vaan hirveän hidas. Ja tuolloin olimme jo ilmoittautuneet julkaisupäivään.
Spoileri: miten tarkalleen olosuhteet kehittyivät, että jätimme niin ison jutun väliin ja päädyimme akuuttiin ja jännittyneeseen tilanteeseen - kerron teille toisessa osassa - ja miten päädyimme ja miten pääsimme ulos. Mutta nyt - sanon vain, että se oli paljon stressiä, ja "ajatella - jotenkin en voi ajatella, me ravistelemme pulloa." "Pullon ravistaminen" on myös spoileri, siitä lisää myöhemmin.
Mitä me teimme:
- Teemme luettelon kaikista järjestelmistä, joita Google ja StackOverflow ehdottavat. Hieman yli 30
- Teemme testejä tuotannolle tyypillisellä kuormituksella. Tätä varten tallensimme dataa, joka kulkee järjestelmän läpi tuotantoympäristössä - eräänlainen haistelija tiedoille ei verkossa, vaan järjestelmän sisällä. Juuri näitä tietoja käytettiin testeissä.
- Koko tiimin kanssa jokainen valitsee luettelosta seuraavan järjestelmän, määrittää sen ja suorittaa testejä. Se ei läpäise koetta, se ei kanna kuormaa – heitämme sen pois ja siirrymme jonossa seuraavaan.
- 17. järjestelmässä kävi selväksi, että kaikki oli toivotonta. Lopeta pullon ravistelu, on aika ajatella vakavasti.
Mutta tämä on vaihtoehto, kun sinun on valittava järjestelmä, joka "pääsee läpi nopeuden" ennalta valmistetuissa testeissä. Entä jos tällaisia testejä ei vielä ole ja haluat valita nopeasti?
Mallitaan tämä vaihtoehto (on vaikea kuvitella, että keski+-kehittäjä asuu tyhjiössä, eikä valintahetkellä ole vielä virallisesti valinnut, mitä tuotetta kokeilla ensin - siksi jatkopäättely on enemmänkin teoreetikko/filosofia/ noin juniori).
Kun olemme päättäneet vaatimuksista, alamme valita ratkaisun heti alusta alkaen. Miksi keksiä pyörä uudelleen: otamme valmiin välimuistijärjestelmän.
Jos olet vasta aloittamassa ja googleta, niin anna tai ota tilaus, mutta pääsääntöisesti ohje on tällainen. Ensinnäkin kohtaat Rediksen, sitä kuullaan kaikkialla. Sitten huomaat, että EhCache on vanhin ja testatuin järjestelmä. Seuraavaksi kirjoitamme Tarantoolista, kotimaisesta kehityksestä, jolla on ainutlaatuinen näkökohta ratkaisussa. Ja myös Ignite, koska sen suosio on nyt nousussa ja nauttii SberTechin tuesta. Lopussa on myös Hazelcast, koska yritysmaailmassa se esiintyy usein suurten yritysten keskuudessa.
Lista ei ole tyhjentävä, järjestelmiä on kymmeniä. Ja me pilaamme vain yhden asian. Otetaan valitut 5 järjestelmää "kauneuskilpailuun" ja tehdään valinta. Kuka on voittaja?
Redis
Luemme, mitä he kirjoittavat virallisella verkkosivustolla.
- avoimen lähdekoodin projekti. Tarjoaa muistissa olevan tiedontallennustilan, mahdollisuuden tallentaa levylle, automaattisen osioinnin, korkean käytettävyyden ja palautumisen verkkokatkoksista.
Näyttää siltä, että kaikki on hyvin, voit ottaa sen ja ruuvata sen kiinni - kaikki mitä tarvitset, se tekee. Mutta huvin vuoksi katsotaanpa muita ehdokkaita.
EhCache
- "Javan yleisimmin käytetty välimuisti" (iskulauseen käännös viralliselta verkkosivustolta). Myös opensource. Ja sitten ymmärrämme, että Redis ei ole Javalle, vaan yleiselle, ja sen kanssa vuorovaikutukseen tarvitaan kääre. Ja EhCache on kätevämpi. Mitä muuta järjestelmä lupaa? Luotettavuus, todistettu, täysi toiminnallisuus. No, se on myös yleisin. Ja tallentaa välimuistiin teratavuja tietoa.
Redis on unohdettu, olen valmis valitsemaan EhCachen.
Mutta isänmaallisuuden tunne pakottaa minut näkemään, mitä hyvää Tarantoolissa on.
Tarantool
- täyttää nimityksen "Reaaliaikainen tietojen integrointialusta". Se kuulostaa erittäin monimutkaiselta, joten luemme sivun yksityiskohtaisesti ja löydämme kovan lausunnon: "Säilyttää 100 % RAM:n tiedoista." Tämän pitäisi herättää kysymyksiä - loppujen lopuksi dataa voi olla paljon enemmän kuin muistia. Selitys on, että se tarkoittaa, että Tarantool ei suorita sarjoitusta kirjoittaakseen tietoja levylle muistista. Sen sijaan se käyttää järjestelmän matalan tason ominaisuuksia, kun muisti yksinkertaisesti kartoitetaan tiedostojärjestelmään, jolla on erittäin hyvä I/O-suorituskyky. Yleensä he tekivät jotain upeaa ja siistiä.
Katsotaanpa toteutuksia: Mail.ru yritysvaltatie, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...
Jos Tarantoolista oli vielä epäilyksiä, Mastercardin käyttöönottotapaus lopettaa minut. Otan Tarantolia.
Mutta joka tapauksessa…
Sytyttää
…onko muita , laskutetaan "muistin sisäisenä laskenta-alustana... muistin sisäiset nopeudet datan petabyyteillä". Tässä on myös monia etuja: hajautettu muistin välimuisti, nopein avainarvojen tallennus ja välimuisti, vaakasuuntainen skaalaus, korkea saatavuus, tiukka eheys. Yleensä käy ilmi, että nopein on Ignite.
Toteutukset: Sberbank, American Airlines, Yahoo! Japani. Ja sitten saan selville, että Ignite ei ole vain otettu käyttöön Sberbankissa, vaan SberTech-tiimi lähettää ihmiset itse Ignite-tiimiin jalostamaan tuotetta. Tämä on täysin kiehtovaa, ja olen valmis ottamaan Igniten.
On täysin epäselvää, miksi, katson viidettä kohtaa.
Hazelcast
menen sivustolle , lukeminen. Ja käy ilmi, että nopein ratkaisu hajautettuun välimuistiin on Hazelcast. Se on suuruusluokkaa nopeampi kuin kaikki muut ratkaisut ja yleisesti ottaen se on edelläkävijä muistin sisäisen dataverkon alalla. Tätä taustaa vasten jonkun muun ottaminen ei tarkoita itsesi kunnioittamista. Se käyttää myös redundanttia datatallennusta klusterin jatkuvaan toimintaan ilman tietojen menetystä.
Siinä kaikki, olen valmis ottamaan Hazelcastin.
vertailu
Mutta jos katsot, kaikki viisi ehdokasta on kuvattu siten, että jokainen heistä on paras. Kuinka valita? Voimme nähdä, mikä on suosituin, etsiä vertailuja, ja päänsärky häviää.
Löydämme sellaisen , valitse 5 järjestelmäämme.
Tässä ne lajitellaan: Redis on kärjessä, Hazelcast toisella, Tarantool ja Ignite ovat kasvattamassa suosiotaan, EhCache on ollut ja pysyy samana.
Mutta katsotaanpa : linkit verkkosivuille, yleinen kiinnostus järjestelmää kohtaan, työtarjoukset - hienoa! Eli kun järjestelmäni epäonnistuu, sanon: "Ei, se on luotettava! Työtarjouksia on paljon..." Tällainen yksinkertainen vertailu ei kelpaa.
Kaikki nämä järjestelmät eivät ole vain välimuistijärjestelmiä. Niissä on myös paljon toimintoja, mukaan lukien kun dataa ei pumpata asiakkaalle käsittelyä varten, vaan päinvastoin: datalle suoritettava koodi siirtyy palvelimelle, suoritetaan siellä ja tulos palautetaan. Eikä niitä niin usein pidetä erillisenä välimuistijärjestelmänä.
Okei, älkää antako periksi, vaan etsitään suora vertailu järjestelmistä. Otetaan kaksi parasta vaihtoehtoa - Redis ja Hazelcast. Olemme kiinnostuneita nopeudesta, ja vertaamme niitä tämän parametrin perusteella.
Hz vs Redis
Löydämme tämän :
Sininen on Redis, punainen on Hazelcast. Hazelcast voittaa kaikkialla, ja tälle on syynsä: se on monisäikeinen, erittäin optimoitu, jokainen säie toimii oman osion kanssa, joten estoa ei ole. Ja Redis on yksisäikeinen; se ei hyödy moderneista moniytimisistä prosessoreista. Hazelcastissa on asynkroninen I/O, Redis-Jedisissä estoliitännät. Loppujen lopuksi Hazelcast käyttää binaariprotokollaa, ja Redis on tekstikeskeinen, mikä tarkoittaa, että se on tehoton.
Kääntykäämme varmuuden vuoksi toiseen vertailulähteeseen. Mitä hän näyttää meille?
Redis vs Hz
toinen :
Täällä päinvastoin punainen on Redis. Toisin sanoen Redis ylittää Hazelcastin suorituskyvyn suhteen. Hazelcast voitti ensimmäisen vertailun, Redis voitti toisen. selitti erittäin tarkasti, miksi Hazelcast voitti edellisen vertailun.
Osoittautuu, että ensimmäisen tulos oli todella väärennetty: Redis otettiin pohjalaatikkoon ja Hazelcast räätälöitiin testitapausta varten. Sitten käy ilmi: ensinnäkin emme voi luottaa keneenkään, ja toiseksi, kun lopulta valitsemme järjestelmän, meidän on silti määritettävä se oikein. Nämä asetukset sisältävät kymmeniä, lähes satoja parametreja.
Pulloa ravistamalla
Ja voin selittää koko prosessin, jonka olemme nyt tehneet seuraavalla metaforalla: "Pullon ravistaminen". Eli nyt sinun ei tarvitse ohjelmoida, nyt tärkeintä on pystyä lukemaan stackoverflow. Ja tiimissäni on henkilö, ammattilainen, joka toimii juuri näin kriittisinä hetkinä.
Mitä hän tekee? Hän näkee rikkinäisen asian, näkee pinon jäljen, ottaa siitä joitain sanoja (mitkä ovat hänen asiantuntemustaan ohjelmassa), etsii Googlesta, löytää vastausten joukosta stackoverflow. Lukematta, ajattelematta hän valitsee kysymyksen vastausten joukosta jotain, joka muistuttaa eniten lausetta "tee tämä ja tuo" (sellaisen vastauksen valinta on hänen lahjakkuutensa, koska se ei aina ole vastaus, joka sai eniten tykkäyksiä), pätee, näyttää: jos jokin on muuttunut, niin hienoa. Jos se ei ole muuttunut, kierrä se takaisin. Ja toista käynnistys-tarkistus-haku. Ja tällä intuitiivisella tavalla hän varmistaa, että koodi toimii jonkin ajan kuluttua. Hän ei tiedä miksi, hän ei tiedä mitä teki, hän ei osaa selittää. Mutta! Tämä infektio toimii. Ja "palo on sammutettu". Otetaan nyt selvää mitä teimme. Kun ohjelma toimii, se on suuruusluokkaa helpompaa. Ja se säästää paljon aikaa.
Tämä menetelmä on hyvin selitetty tässä esimerkissä.
Oli kerran hyvin suosittua kerätä purjevene pulloon. Samaan aikaan purjevene on suuri ja hauras, ja pullon kaula on erittäin kapea, sitä on mahdotonta työntää sisään. Kuinka koota se?
On olemassa sellainen menetelmä, erittäin nopea ja erittäin tehokas.
Laiva koostuu joukosta pieniä asioita: tikkuja, köysiä, purjeita, liimaa. Laitoimme tämän kaiken pulloon.
Otamme pullon molemmin käsin ja alamme ravistaa. Ravistelemme ja ravistelemme häntä. Ja yleensä se on tietysti täyttä roskaa. Mutta joskus. Joskus se osoittautuu laivaksi! Tarkemmin sanottuna jotain laivan kaltaista.
Näytämme tämän jollekin: "Seryoga, näetkö!?" Ja todellakin, kaukaa se näyttää laivalta. Mutta tämän ei voida antaa jatkua.
On toinenkin tapa. Niitä käyttävät edistyneemmät kaverit, kuten hakkerit.
Annoin tälle kaverille tehtävän, hän teki kaiken ja lähti. Ja sinä katsot - näyttää siltä, että se on tehty. Ja hetken kuluttua, kun koodia pitää viimeistellä, tämä alkaa hänen takiaan... Hyvä, että hän on jo ehtinyt paeta kauas. Nämä ovat ne kaverit, jotka pullon esimerkin avulla tekevät tämän: näet, missä pohja on, lasi taipuu. Eikä ole täysin selvää, onko se läpinäkyvä vai ei. Sitten "hakkerit" leikkaavat tämän pohjan irti, työntävät laivan sinne, sitten liimaavat pohjan takaisin kiinni, ja niin sen pitäisi olla.
Ongelman asettamisen näkökulmasta kaikki näyttää olevan oikein. Mutta laivoja esimerkkinä: miksi tätä laivaa ylipäätään tehdään, kuka sitä ylipäätään tarvitsee? Se ei tarjoa mitään toimintoja. Yleensä tällaiset laivat ovat lahjoja erittäin korkea-arvoisille ihmisille, jotka laittavat sen yläpuolelleen hyllylle, jonkinlaiseksi symboliksi, merkiksi. Ja jos tällainen henkilö, suuren yrityksen johtaja tai korkea-arvoinen virkamies, kuinka lippu seisoo sellaisella hakkerilla, jonka kaula on leikattu pois? Olisi parempi, jos hän ei koskaan tietäisi siitä. Joten miten he päätyvät tekemään näitä laivoja, jotka voidaan antaa tärkeälle henkilölle?
Ainoa keskeinen paikka, jolle et voi tehdä mitään, on keho. Ja laivan runko sopii suoraan kaulaan. Laiva on koottu pullon ulkopuolelle. Mutta se ei ole vain laivan kokoamista, se on todellinen korukäsityö. Komponentteihin on lisätty erityisiä vipuja, jotka mahdollistavat niiden nostamisen. Esimerkiksi purjeet taitetaan, tuodaan varovasti sisään ja sitten pinsettien avulla ne vedetään ja nostetaan erittäin tarkasti, tarkasti. Lopputuloksena on taideteos, joka voidaan lahjoittaa puhtaalla omallatunnolla ja ylpeydellä.
Ja jos haluamme projektin onnistuvan, tiimissä on oltava vähintään yksi kultaseppä. Joku, joka välittää tuotteen laadusta ja ottaa kaikki näkökohdat huomioon, tinkimättä mistään, myös stressin hetkinä, kun olosuhteet vaativat kiireellistä tekemistä tärkeän kustannuksella. Kaikki onnistuneet kestävät, ajan kokeen kestäneet hankkeet rakentuvat tälle periaatteelle. Niissä on jotain hyvin tarkkaa ja ainutlaatuista, jotain, joka hyödyntää kaikkia saatavilla olevia mahdollisuuksia. Esimerkissä, jossa laiva on pullossa, esitetään, että laivan runko kulkee kaulan läpi.
Palatakseni välimuistipalvelimemme valintaan, kuinka tätä menetelmää voitaisiin soveltaa? Tarjoan tämän vaihtoehdon valita kaikista olemassa olevista järjestelmistä - älä ravista pulloa, älä valitse, vaan katso mitä heillä on periaatteessa, mitä etsiä järjestelmää valittaessa.
Mistä etsiä pullonkaulaa
Yritetään olla ravistamatta pulloa, ei käydä läpi kaikkea siellä olevaa yksitellen, mutta katsotaan mitä ongelmia syntyy, jos yhtäkkiä, tehtäväämme varten suunnittelemme sellaisen järjestelmän itse. Emme tietenkään kokoa pyörää, mutta käytämme tätä kaaviota auttamaan meitä selvittämään, mihin kohtiin tuotekuvauksissa on kiinnitettävä huomiota. Piirretään tällainen kaavio.
Jos järjestelmä on hajautettu, meillä on useita palvelimia (6). Oletetaan, että niitä on neljä (ne on kätevää sijoittaa kuvaan, mutta niitä voi tietysti olla niin monta kuin haluat). Jos palvelimet ovat eri solmuissa, ne kaikki käyttävät jotain koodia, joka on vastuussa siitä, että nämä solmut muodostavat klusterin ja katkon sattuessa muodostavat yhteyden ja tunnistavat toisensa.
Tarvitsemme myös koodilogiikkaa (2), joka on itse asiassa välimuistista. Asiakkaat ovat vuorovaikutuksessa tämän koodin kanssa jonkin API:n kautta. Asiakaskoodi (1) voi olla joko samassa JVM:ssä tai käyttää sitä verkon kautta. Sisällä toteutettu logiikka on päätös siitä, mitkä esineet jätetään välimuistiin ja mitkä heitetään pois. Käytämme muistia (3) välimuistin tallentamiseen, mutta tarvittaessa voimme tallentaa osan tiedoista levylle (4).
Katsotaan missä osissa kuormitus tapahtuu. Itse asiassa jokainen nuoli ja jokainen solmu ladataan. Ensinnäkin asiakaskoodin ja api:n välillä, jos kyseessä on verkkoviestintä, vajoaminen voi olla varsin havaittavissa. Toiseksi itse api:n puitteissa - jos liioittelemme sitä monimutkaisen logiikan kanssa, voimme törmätä ongelmiin suorittimen kanssa. Ja olisi mukavaa, jos logiikka ei tuhlaa aikaa muistiin. Ja edelleen on vuorovaikutusta tiedostojärjestelmän kanssa - tavallisessa versiossa tämä on sarjoittaminen / palautus ja kirjoitus / lukeminen.
Seuraava on vuorovaikutus klusterin kanssa. Todennäköisesti se on samassa järjestelmässä, mutta se voi olla erikseen. Tässä on myös otettava huomioon tiedon siirto siihen, tietojen serialisoinnin nopeus ja klusterin väliset vuorovaikutukset.
Nyt voimme toisaalta kuvitella "mitä vaihteita kääntyy" välimuistijärjestelmässä käsitellessään pyyntöjä koodistamme, ja toisaalta voimme arvioida, mitä ja kuinka monta pyyntöä koodimme tuottaa tälle järjestelmälle. Tämä riittää tekemään enemmän tai vähemmän järkevän valinnan - valitsemaan järjestelmän käyttötapaamme.
Hazelcast
Katsotaanpa, kuinka tätä hajotusta käytetään luettelossamme. Esimerkiksi Hazelcast.
Datan sijoittamiseksi/ottamiseksi Hazelcastista asiakaskoodi käyttää (1) API:ta. Hz:n avulla voit käyttää palvelinta sulautetussa muodossa, ja tässä tapauksessa API:n käyttö on menetelmäkutsu JVM:n sisällä, jota voidaan pitää ilmaisena.
Jotta (2):n logiikka toimisi, Hz luottaa serialisoidun avaimen tavutaulukon hash-arvoon - eli avain sarjoitetaan joka tapauksessa. Tämä on väistämätöntä Hz:n ylärajaa.
Häätöstrategiat toteutetaan hyvin, mutta erikoistapauksia varten voit lisätä omasi. Sinun ei tarvitse huolehtia tästä osasta.
Varastointi (4) voidaan kytkeä. Loistava. Vuorovaikutusta (5) sulautetuille voidaan pitää välittömänä. Tiedonvaihto klusterin solmujen välillä (6) - kyllä, se on olemassa. Tämä on investointi vikasietoisuuteen nopeuden kustannuksella. Hz-ominaisuuden Near-cache avulla voit alentaa hintaa - klusterin muista solmuista saadut tiedot tallennetaan välimuistiin.
Mitä tällaisissa olosuhteissa voidaan tehdä nopeuden lisäämiseksi?
Esimerkiksi, jotta vältetään avaimen sarjoittaminen kohdassa (2) - liitä toinen välimuisti Hazelcastin päälle kuumimpien tietojen saamiseksi. Sportmaster valitsi kofeiinin tähän tarkoitukseen.
Tasolla (6) kiertämiseen Hz tarjoaa kahden tyyppisen tallennustilan: IMap ja ReplicatedMap.
On syytä mainita, kuinka Hazelcast pääsi Sportmaster-teknologiapinoon.
Vuonna 2012, kun työskentelimme tulevan sivuston ensimmäistä pilottia, Hazelcast osoittautui ensimmäiseksi linkiksi, jonka hakukone palautti. Tutustuminen alkoi "ensimmäisellä kerralla" - olimme innostuneet siitä, että vain kaksi tuntia myöhemmin, kun ruuvattiin Hz järjestelmään, se toimi. Ja se toimi hyvin. Päivän loppuun mennessä olimme suorittaneet useita testejä ja olimme tyytyväisiä. Ja tämä elinvoiman reservi riitti voittamaan yllätyksiä, joita Hz aiheutti ajan myötä. Nyt Sportmaster-tiimillä ei ole syytä hylätä Hazelcastia.
Mutta sellaiset argumentit kuin "ensimmäinen linkki hakukoneessa" ja "HelloWorld koottiin nopeasti" ovat tietysti poikkeus ja ominaisuus hetkessä, jolloin valinta tapahtui. Varsinaiset testit valitulle järjestelmälle alkavat tuotantoon julkaisusta, ja juuri tässä vaiheessa sinun tulee kiinnittää huomiota valittaessa mitä tahansa järjestelmää, mukaan lukien välimuisti. Itse asiassa meidän tapauksessamme voimme sanoa, että valitsimme Hazelcastin vahingossa, mutta sitten kävi ilmi, että valitsimme oikein.
Tuotannon kannalta paljon tärkeämpää: valvonta, yksittäisten solmujen vikojen käsittely, tietojen replikointi, skaalauskustannukset. Eli kannattaa kiinnittää huomiota niihin tehtäviin, joita syntyy järjestelmän ylläpidon aikana - kun kuormitus on kymmeniä kertoja suunniteltua suurempi, kun lataamme vahingossa jotain väärään paikkaan, kun joudumme ottamaan käyttöön uuden version koodin, korvaa tiedot ja tee se huomaamatta asiakkaille.
Kaikille näille vaatimuksille Hazelcast varmasti sopii laskuun.
Jatkuu
Mutta Hazelcast ei ole ihmelääke. Vuonna 2017 valitsimme Hazelcastin järjestelmänvalvojan välimuistiin yksinkertaisesti aiempien kokemusten hyvien vaikutelmien perusteella. Tämä oli avainroolissa erittäin julmassa vitsissä, jonka vuoksi jouduimme vaikeaan tilanteeseen ja selvisimme siitä "sankarillisesti" 60 päiväksi. Mutta siitä lisää seuraavassa osassa.
Sillä välin... Hyvää uutta koodia!
Lähde: will.com