Halló! Ég heiti Alexey Pyankov, ég er verktaki hjá Sportmaster fyrirtækinu. Í því Ég sagði frá því hvernig vinna við Sportmaster vefsíðuna hófst árið 2012, hvaða frumkvæði okkur tókst að „ýta í gegn“ og öfugt, hvaða hrífu við söfnuðum.
Í dag vil ég deila hugsunum sem fylgja öðru efni - að velja skyndiminni kerfi fyrir java bakendann á síðustjórnunarsvæðinu. Þessi söguþráður hefur sérstaka þýðingu fyrir mig - þó sagan hafi aðeins runnið út í 2 mánuði, þá unnum við á þessum 60 dögum 12-16 tíma og án eins einasta frídags. Ég hafði aldrei hugsað eða ímyndað mér að það væri hægt að vinna svona mikið.
Þess vegna skipti ég textanum í 2 hluta til að hlaða hann ekki alveg. Þvert á móti verður fyrsti hlutinn mjög léttur - undirbúningur, kynning, nokkrar hugleiðingar um hvað skyndiminni er. Ef þú ert nú þegar reyndur verktaki eða hefur unnið með skyndiminni, frá tæknilegu hliðinni mun líklega ekkert nýtt vera í þessari grein. En fyrir yngri getur svo lítil upprifjun sagt honum í hvaða átt hann á að leita ef hann lendir á slíkum tímamótum.
Þegar nýja útgáfan af Sportmaster vefsíðunni var tekin í notkun barst gögnunum á þann hátt að það var vægast sagt ekki sérlega þægilegt. Grunnurinn var töflur útbúnar fyrir fyrri útgáfu síðunnar (Bitrix), sem þurfti að draga inn í ETL, koma í nýtt form og auðga með ýmsum smáhlutum úr tugi kerfa í viðbót. Til þess að ný mynd eða vörulýsing kæmi fram á síðunni þurfti að bíða til næsta dags - uppfærslur aðeins á nóttunni, einu sinni á dag.
Í fyrstu voru svo miklar áhyggjur frá fyrstu vikum framleiðslunnar að slík óþægindi fyrir efnisstjóra voru smáræði. En um leið og allt var komið í lag hélt þróun verkefnisins áfram - nokkrum mánuðum síðar, í byrjun árs 2015, fórum við að þróa stjórnborðið með virkum hætti. Árið 2015 og 2016 gengur allt vel, við gefum út reglulega, stjórnborðið tekur yfir sífellt meira af undirbúningi gagna og við erum að búa okkur undir þá staðreynd að bráðum verður teyminu okkar falið það mikilvægasta og flóknasta - vöruna hringrás (fullur undirbúningur og viðhald gagna um allar vörur). En sumarið 2017, rétt áður en hrávöruhringrásin er hafin, mun verkefnið lenda í mjög erfiðum aðstæðum - einmitt vegna vandamála með skyndiminni. Mig langar að tala um þennan þátt í seinni hluta þessa tveggja hluta rits.
En í þessari færslu mun ég byrja úr fjarska, ég mun kynna nokkrar hugsanir - hugmyndir um skyndiminni, sem væri gott skref til að fletta í gegnum fyrir stórt verkefni.
Þegar skyndiminni verkefni á sér stað
Skyndiminnisverkefnið birtist ekki bara. Við erum verktaki, skrifum hugbúnaðarvöru og viljum að hún sé eftirsótt. Ef varan er eftirsótt og árangursrík koma notendur. Og fleiri og fleiri koma. Og svo eru margir notendur og þá verður varan mjög hlaðin.
Á fyrstu stigum hugsum við ekki um hagræðingu og afköst kóða. Aðalatriðið er virkni, fljótt að rúlla út flugmaður og prófa tilgátur. Og ef álagið eykst dælum við upp járninu. Við aukum það tvisvar eða þrisvar sinnum, fimm sinnum, kannski 10 sinnum. Einhvers staðar hér - fjármál leyfa það ekki lengur. Hversu oft mun notendum fjölga? Það verður ekki eins og 2-5-10, en ef vel tekst, verður það frá 100-1000 til 100 þúsund sinnum. Það er, fyrr eða síðar verður þú að gera hagræðingu.
Segjum að einhver hluti kóðans (köllum þennan hluta fall) taki ósæmilega langan tíma og við viljum stytta framkvæmdartímann. Fall getur verið aðgangur að gagnagrunni, eða hún getur verið framkvæmd einhverrar flókinnar rökfræði - aðalatriðið er að það tekur langan tíma að framkvæma. Hversu mikið er hægt að stytta framkvæmdartímann? Í mörkunum geturðu lækkað það í núll, ekki lengra. Hvernig er hægt að stytta framkvæmdartímann niður í núll? Svar: útrýma framkvæmd með öllu. Í staðinn skaltu skila niðurstöðunni strax. Hvernig geturðu fundið út niðurstöðuna? Svar: annað hvort reiknaðu það eða leitaðu einhvers staðar. Það tekur langan tíma að reikna út. Og að njósna er til dæmis að muna niðurstöðuna sem aðgerðin gaf síðast þegar hún var kölluð með sömu breytur.
Það er að segja að framkvæmd aðgerðarinnar er okkur ekki mikilvæg. Það er nóg bara að vita á hvaða breytum niðurstaðan fer. Síðan, ef færibreytugildin eru táknuð í formi hlutar sem hægt er að nota sem lykil í einhverri geymslu, þá er hægt að vista niðurstöðu útreikningsins og lesa út næst þegar farið er í hana. Ef þessi ritun og lestur niðurstöðunnar er hraðari en að framkvæma aðgerðina, höfum við hagnað miðað við hraða. Hagnaðarupphæðin getur orðið 100, 1000 og 100 þúsund sinnum (10^5 er frekar undantekning, en ef um er að ræða frekar seinlegan grunn er það alveg mögulegt).
Grunnkröfur fyrir skyndiminniskerfi
Það fyrsta sem gæti orðið krafa fyrir skyndiminniskerfi er hraður leshraði og í aðeins minna mæli skrifhraði. Þetta er satt, en aðeins þar til við rúllum kerfinu út í framleiðslu.
Við skulum spila þetta mál.
Segjum að við höfum útvegað núverandi álag með vélbúnaði og erum nú smám saman að kynna skyndiminni. Notendafjöldinn eykst aðeins, álagið vex - við bætum við smá skyndiminni, skrúfum það inn hér og þar. Þetta heldur áfram í nokkurn tíma og nú eru þungar aðgerðir nánast ekki kallaðar lengur - allt aðalálagið fellur á skyndiminni. Fjöldi notenda á þessum tíma hefur aukist N sinnum.
Og ef upphafsframboð vélbúnaðar gæti verið 2-5 sinnum, þá gætum við með hjálp skyndiminni bætt afköst um 10 eða, í góðu tilfelli, um 100, sums staðar kannski um stuðul af 1000. Það er, á sama vélbúnaði - við vinnum 100 sinnum fleiri beiðnir. Frábært, þú átt piparkökuna skilið!
En núna, á einni fallegri stundu, fyrir tilviljun, hrundi kerfið og skyndiminni hrundi. Ekkert sérstakt - þegar öllu er á botninn hvolft var skyndiminni valið út frá kröfunni „hár les- og skrifhraði, restin skiptir ekki máli.
Miðað við upphafsálagið var járnforði okkar 2-5 sinnum og álagið á þessum tíma jókst 10-100 sinnum. Með því að nota skyndiminni eyddum við köllum fyrir þungar aðgerðir og því virkaði allt. Og núna, án skyndiminni, hversu oft mun kerfið okkar hægja á sér? Hvað verður um okkur? Kerfið mun falla.
Jafnvel þótt skyndiminni okkar hafi ekki hrunið, heldur hafi verið hreinsað aðeins um stund, þarf að hita það upp og það mun taka nokkurn tíma. Og á þessum tíma mun aðalbyrðin falla á virkni.
Ályktun: mjög hlaðin framleiðsluverkefni krefjast skyndiminniskerfis til að hafa ekki aðeins háan les- og skrifhraða, heldur einnig til að tryggja öryggi gagna og viðnám gegn bilunum.
Mjöl að eigin vali
Í verkefni með stjórnendaborði fór valið svona: fyrst settum við upp Hazelcast, vegna þess Við þekktum þessa vöru þegar af reynslu aðalsíðunnar. En hér reyndist þetta val misheppnað - undir hleðslusniði okkar er Hazelcast ekki bara hægt heldur hræðilega hægt. Og á þeim tíma vorum við þegar búin að skrá okkur fyrir útgáfudaginn.
Spoiler: hvernig nákvæmlega þær aðstæður þróuðust að við misstum af svona stóru máli og lentum í bráðri og spennuþrungnu ástandi - ég segi þér það í seinni hlutanum - og hvernig við enduðum og hvernig við komumst út. En núna - ég segi bara að þetta var mikið stress, og "að hugsa - einhvern veginn get ég ekki hugsað, við hristum flöskuna." „Shaking the bottle“ er líka spoiler, meira um það síðar.
Það sem við gerðum:
- Við gerum lista yfir öll þau kerfi sem Google og StackOverflow stinga upp á. Rúmlega 30
- Við skrifum próf með álagi sem er dæmigert fyrir framleiðslu. Til að gera þetta tókum við upp gögn sem fara í gegnum kerfið í framleiðsluumhverfi - eins konar sniffer fyrir gögn ekki á netinu, heldur inni í kerfinu. Nákvæmlega þessi gögn voru notuð í prófunum.
- Með öllu teyminu velja allir næsta kerfi af listanum, stilla það og keyra próf. Það stenst ekki mátið, það ber ekki byrðina - við hendum því og höldum áfram í næsta í röðinni.
- Á 17. kerfi varð ljóst að allt var vonlaust. Hættu að hrista flöskuna, það er kominn tími til að hugsa alvarlega.
En þetta er valkostur þegar þú þarft að velja kerfi sem mun „komast í gegnum hraðann“ í fyrirfram undirbúnum prófum. Hvað ef það eru engin slík próf ennþá og þú vilt velja fljótt?
Við skulum líkja eftir þessum valmöguleika (það er erfitt að ímynda sér að miðlungs+ þróunaraðili búi í tómarúmi, og á þeim tíma sem valið er valið hefur hann ekki enn formfest val sitt á því hvaða vöru á að prófa fyrst - þess vegna er frekari rökstuðningur frekar kenningasmiður/heimspeki/ um yngri).
Eftir að hafa ákveðið kröfurnar munum við byrja að velja lausn úr kassanum. Af hverju að finna upp hjólið aftur: við förum og tökum tilbúið skyndiminnikerfi.
Ef þú ert rétt að byrja og googla það, gefðu eða taktu pöntunina, en almennt séð verða leiðbeiningarnar svona. Fyrst af öllu muntu rekjast á Redis, það heyrist alls staðar. Þá muntu komast að því að EhCache er elsta og sannaðasta kerfið. Næst munum við skrifa um Tarantool, innlenda þróun sem hefur einstaka hlið á lausninni. Og einnig Ignite, því það er nú að aukast í vinsældum og nýtur stuðnings SberTech. Í lokin er líka Hazelcast, því í fyrirtækjaheiminum birtist það oft meðal stórfyrirtækja.
Listinn er ekki tæmandi; það eru heilmikið af kerfum. Og við munum aðeins klúðra einu. Við skulum taka 5 valin kerfi fyrir „fegurðarsamkeppnina“ og velja. Hver verður sigurvegari?
Redis
Við lesum það sem þeir skrifa á opinberu vefsíðunni.
- opinn uppspretta verkefni. Býður upp á gagnageymslu í minni, getu til að vista á diski, sjálfvirk skipting, mikið framboð og endurheimt eftir netleysi.
Það virðist sem allt sé í lagi, þú getur tekið það og skrúfað það á - allt sem þú þarft, það gerir það. En til gamans skulum við líta á hina frambjóðendurna.
EhCache
- „mest notaða skyndiminni fyrir Java“ (þýðing á slagorðinu af opinberu vefsíðunni). Einnig opinn uppspretta. Og þá skiljum við að Redis er ekki fyrir Java, heldur almennt, og til að hafa samskipti við það þarftu umbúðir. Og EhCache verður þægilegra. Hverju lofar kerfið annars? Áreiðanleiki, sannað, full virkni. Jæja, það er líka algengast. Og geymir terabæta af gögnum.
Redis er gleymt, ég er tilbúinn að velja EhCache.
En tilfinning um ættjarðarást knýr mig til að sjá hvað er gott við Tarantool.
Tarantool
- uppfyllir tilnefninguna „gagnasamþættingarvettvangur í rauntíma“. Það hljómar mjög flókið, þannig að við lesum síðuna í smáatriðum og finnum háværa fullyrðingu: „Skimar 100% af gögnunum í vinnsluminni. Þetta ætti að vekja upp spurningar - þegar allt kemur til alls geta verið miklu fleiri gögn en minni. Skýringin er sú að það þýðir að Tarantool keyrir ekki serialization til að skrifa gögn á disk úr minni. Þess í stað notar það lág-stigi eiginleika kerfisins, þegar minni er einfaldlega kortlagt á skráarkerfi með mjög góða I/O frammistöðu. Almennt séð gerðu þeir eitthvað dásamlegt og flott.
Við skulum skoða útfærslurnar: Mail.ru fyrirtækjahraðbraut, Avito, Beeline, Megafon, Alfa-Bank, Gazprom ...
Ef það voru enn einhverjar efasemdir um Tarantool, þá klárar framkvæmdamálið hjá Mastercard mig. Ég tek Tarantool.
En allavega…
Kveikja
… er eitthvað fleira , er innheimt sem "tölvuvettvangur í minni ... í minni hraða á petabætum af gögnum." Það eru líka margir kostir hér: Dreift skyndiminni í minni, hraðasta lykilgildi geymsla og skyndiminni, lárétt stærðarstærð, mikið framboð, ströng heilindi. Almennt séð kemur í ljós að fljótast er Ignite.
Útfærslur: Sberbank, American Airlines, Yahoo! Japan. Og svo kemst ég að því að Ignite er ekki bara innleitt í Sberbank, heldur sendir SberTech teymið sitt fólk til Ignite teymisins sjálfs til að betrumbæta vöruna. Þetta er alveg grípandi og ég er tilbúin að taka Ignite.
Það er algjörlega óljóst hvers vegna, ég er að horfa á fimmta atriðið.
hazelcast
Ég fer á síðuna , lestur. Og það kemur í ljós að fljótlegasta lausnin fyrir dreifða skyndiminni er Hazelcast. Það er stærðargráðum hraðar en allar aðrar lausnir og almennt er það leiðandi á sviði gagnanets í minni. Með hliðsjón af þessu, að taka eitthvað annað er ekki að bera virðingu fyrir sjálfum sér. Það notar einnig óþarfa gagnageymslu fyrir stöðugan rekstur þyrpingarinnar án gagnataps.
Það er það, ég er tilbúinn að taka Hazelcast.
Samanburður
En ef þú skoðar þá er öllum fimm frambjóðendum lýst þannig að hver þeirra sé bestur. Hvernig á að velja? Við getum séð hver er vinsælastur, leitað að samanburði og höfuðverkurinn hverfur.
Við finnum einn svona , veldu 5 kerfin okkar.
Hér er þeim raðað: Redis er á toppnum, Hazelcast er í öðru sæti, Tarantool og Ignite njóta vinsælda, EhCache hefur verið og er óbreytt.
En lítum á : tenglar á vefsíður, almennur áhugi á kerfinu, atvinnutilboð - frábært! Það er, þegar kerfið mitt bilar mun ég segja: „Nei, það er áreiðanlegt! Það eru mörg atvinnutilboð...“ Svo einfaldur samanburður mun ekki duga.
Öll þessi kerfi eru ekki bara skyndiminniskerfi. Þeir hafa líka mikla virkni, þar á meðal þegar gögnum er ekki dælt til viðskiptavinarins til vinnslu, heldur öfugt: kóðinn sem þarf að keyra á gögnunum færist á netþjóninn, er keyrður þar og niðurstaðan er skilað. Og þeir eru ekki svo oft álitnir sem sérstakt kerfi fyrir skyndiminni.
Allt í lagi, við skulum ekki gefast upp, við skulum finna beinan samanburð á kerfunum. Við skulum taka tvo efstu valkostina - Redis og Hazelcast. Við höfum áhuga á hraða og við munum bera þá saman út frá þessari breytu.
Hz vs Redis
Við finnum þetta :
Blár er Redis, rauður er Hazelcast. Hazelcast vinnur alls staðar, og það er rök fyrir þessu: það er margþráður, mjög bjartsýni, hver þráður vinnur með sína eigin skiptingu, svo það er engin hindrun. Og Redis er einþráður; það nýtur ekki góðs af nútíma fjölkjarna örgjörvum. Hazelcast er með ósamstillt I/O, Redis-Jedis er með blokkandi innstungur. Þegar öllu er á botninn hvolft notar Hazelcast tvíundarsamskiptareglur og Redis er textamiðuð, sem þýðir að hún er óhagkvæm.
Svona til öryggis skulum við snúa okkur að annarri uppsprettu samanburðar. Hvað mun hann sýna okkur?
Redis vs Hz
Annar :
Hér er þvert á móti rautt Redis. Það er, Redis er betri en Hazelcast hvað varðar frammistöðu. Hazelcast vann fyrri samanburðinn, Redis vann þann seinni. útskýrði mjög nákvæmlega hvers vegna Hazelcast vann fyrri samanburðinn.
Það kemur í ljós að niðurstaðan úr þeirri fyrri var í raun týnd: Redis var tekin í grunnkassann og Hazelcast var sniðin fyrir prófunartilfelli. Þá kemur í ljós: í fyrsta lagi getum við ekki treyst neinum, og í öðru lagi, þegar við loksins veljum kerfi, þurfum við samt að stilla það rétt. Þessar stillingar innihalda heilmikið, næstum hundruð breytur.
Að hrista flöskuna
Og ég get útskýrt allt ferlið sem við höfum nú gert með eftirfarandi myndlíkingu: "Hrista flöskuna." Það er, nú þarftu ekki að forrita, nú er aðalatriðið að geta lesið stackoverflow. Og ég er með manneskju í teyminu mínu, fagmann, sem vinnur nákvæmlega svona á mikilvægum augnablikum.
Hvað er hann að gera? Hann sér brotinn hlut, sér staflaspor, tekur nokkur orð úr því (hver eru sérfræðiþekking hans í forritinu), leitar á Google, finnur staflaflæði meðal svara. Án þess að lesa, án þess að hugsa, meðal svara við spurningunni, velur hann eitthvað sem líkist mest setningunni "gerðu þetta og hitt" (að velja slíkt svar er hæfileiki hans, því það er ekki alltaf svarið sem fékk mest líka við), á við , útlit: ef eitthvað hefur breyst, þá frábært. Ef það hefur ekki breyst skaltu snúa því til baka. Og endurtaktu ræsingu-athugaðu-leit. Og á þennan leiðandi hátt tryggir hann að kóðinn virki eftir nokkurn tíma. Hann veit ekki hvers vegna, hann veit ekki hvað hann gerði, hann getur ekki útskýrt. En! Þessi sýking virkar. Og „eldurinn er slökktur“. Nú skulum við reikna út hvað við gerðum. Þegar forritið virkar er það stærðargráðu auðveldara. Og það sparar mikinn tíma.
Þessi aðferð er mjög vel útskýrð með þessu dæmi.
Það var einu sinni mjög vinsælt að safna seglbát í flösku. Á sama tíma er seglbáturinn stór og viðkvæmur, og hálsinn á flöskunni er mjög þröngur, það er ómögulegt að ýta því inn. Hvernig á að setja það saman?
Það er til slík aðferð, mjög hröð og mjög áhrifarík.
Skipið samanstendur af fullt af litlum hlutum: prik, reipi, segl, lím. Við setjum þetta allt í flösku.
Við tökum flöskuna með báðum höndum og byrjum að hrista. Við hristum hana og hristum hana. Og yfirleitt reynist þetta auðvitað algjört sorp. En stundum. Stundum kemur í ljós að þetta er skip! Nánar tiltekið eitthvað svipað og skip.
Við sýnum einhverjum þetta eitthvað: "Seryoga, sérðu!?" Og reyndar, úr fjarska lítur það út eins og skip. En þetta má ekki halda áfram.
Það er önnur leið. Þeir eru notaðir af lengra komnum krökkum, eins og tölvuþrjótum.
Ég gaf þessum gaur verkefni, hann gerði allt og fór. Og þú lítur út - það lítur út fyrir að það sé búið. Og eftir smá stund, þegar þarf að klára kóðann, byrjar þetta hans vegna... Það er gott að hann hefur þegar náð að hlaupa langt í burtu. Þetta eru krakkar sem, með því að nota dæmi um flösku, munu gera þetta: þú sérð, hvar botninn er, beygir glerið. Og það er ekki alveg ljóst hvort það er gegnsætt eða ekki. Svo klipptu „hakkararnir“ botninn af, settu skip þar inn, líma svo botninn aftur á, og það er eins og það eigi að vera þannig.
Frá sjónarhóli að stilla vandamálið virðist allt vera rétt. En með skipum sem dæmi: hvers vegna búa þetta skip til, hver þarf það samt? Það veitir enga virkni. Yfirleitt eru slík skip gjafir til mjög háttsettra manna, sem leggja það á hillu fyrir ofan sig, sem einhvers konar tákn, til merkis. Og ef slíkur maður, yfirmaður stórfyrirtækis eða háttsettur embættismaður, hvernig mun fáninn standa fyrir slíkt hakk, sem hálsinn hefur verið skorinn af? Það væri betra ef hann vissi aldrei af því. Svo, hvernig enda þeir á því að búa til þessi skip sem hægt er að gefa mikilvægum einstaklingi?
Eini lykilstaðurinn sem þú getur í raun ekki gert neitt við er líkaminn. Og skipsskrokkurinn passar beint í hálsinn. En skipið er sett saman fyrir utan flöskuna. En það er ekki bara að setja saman skip, það er alvöru skartgripahandverk. Sérstakar stangir eru bættar við íhlutina, sem síðan gera kleift að lyfta þeim. Sem dæmi má nefna að seglin eru brotin saman, þau færð varlega inn í og síðan, með töppum, eru þau dregin og lyft mjög nákvæmlega, af nákvæmni. Útkoman er listaverk sem hægt er að gefa með góðri samvisku og stolti.
Og ef við viljum að verkefnið gangi vel verður að vera að minnsta kosti einn skartgripasmiður í liðinu. Einhver sem er annt um gæði vörunnar og tekur tillit til allra þátta, án þess að fórna neinu, jafnvel á streitustundum, þegar aðstæður krefjast þess að gera hið brýna á kostnað þess mikilvæga. Öll árangursrík verkefni sem eru sjálfbær, sem hafa staðist tímans tönn, eru byggð á þessari reglu. Það er eitthvað mjög nákvæmt og einstakt við þá, eitthvað sem nýtir alla möguleika. Í dæminu með skipið í flöskunni er leikið út að skrokkur skipsins fari í gegnum hálsinn.
Þegar við snúum aftur að því verkefni að velja skyndiminnisþjóninn okkar, hvernig væri hægt að beita þessari aðferð? Ég býð upp á þennan möguleika að velja úr öllum kerfum sem eru til - ekki hrista flöskuna, ekki velja, en skoða hvað þau hafa í grundvallaratriðum, hvað á að leita að þegar þú velur kerfi.
Hvar á að leita að flöskuhálsi
Við skulum reyna að hrista ekki flöskuna, ekki fara í gegnum allt sem er þar eitt af öðru, en við skulum sjá hvaða vandamál munu koma upp ef við skyndilega, fyrir verkefni okkar, hönnum slíkt kerfi sjálf. Auðvitað munum við ekki setja saman hjólið, en við munum nota þessa skýringarmynd til að hjálpa okkur að finna út hvaða atriði þarf að huga að í vörulýsingum. Við skulum skissa upp slíka skýringarmynd.
Ef kerfinu er dreift, þá munum við hafa nokkra netþjóna (6). Segjum að þeir séu fjórir (það er þægilegt að setja þá á myndina, en auðvitað geta þeir verið eins margir og þú vilt). Ef netþjónarnir eru á mismunandi hnútum þýðir það að þeir keyra allir einhvern kóða sem er ábyrgur fyrir því að þessir hnútar mynda þyrping og, ef bilun verður, tengjast og þekkja hver annan.
Við þurfum líka kóða rökfræði (2), sem snýst í raun um skyndiminni. Viðskiptavinir hafa samskipti við þennan kóða í gegnum forritaskil. Viðskiptavinakóði (1) getur annað hvort verið innan sama JVM eða fengið aðgang að honum í gegnum netið. Rökfræðin sem er útfærð inni er ákvörðun um hvaða hluti á að skilja eftir í skyndiminni og hverjum á að henda út. Við notum minni (3) til að geyma skyndiminni, en ef nauðsyn krefur getum við vistað hluta af gögnunum á diski (4).
Við skulum sjá í hvaða hlutum álagið verður. Reyndar verður hver ör og hver hnút hlaðinn. Í fyrsta lagi, á milli viðskiptavinakóðans og API, ef þetta eru netsamskipti, getur sigið verið nokkuð áberandi. Í öðru lagi, innan ramma forritsins sjálfs - ef við ofgerum því með flókinni rökfræði, getum við lent í vandræðum með CPU. Og það væri gaman ef rökfræðin sóaði ekki tíma í minnið. Og það er áfram samspil við skráarkerfið - í venjulegri útgáfu er þetta serialize / endurheimta og skrifa / lesa.
Næst er samskipti við klasann. Líklegast mun það vera í sama kerfi, en það gæti verið sérstaklega. Hér þarf líka að taka tillit til flutnings gagna til þess, hraða raðgreiningar gagna og samskipta milli klasans.
Nú getum við annars vegar ímyndað okkur „hvaða gír munu snúast“ í skyndiminnikerfinu þegar unnið er úr beiðnum úr kóðanum okkar, og hins vegar getum við áætlað hvað og hversu margar beiðnir kóðinn okkar mun búa til í þetta kerfi. Þetta er nóg til að gera meira eða minna edrú val - að velja kerfi fyrir notkunartilvik okkar.
hazelcast
Við skulum sjá hvernig á að beita þessari niðurbroti á listann okkar. Til dæmis, Hazelcast.
Til þess að setja/taka gögn frá Hazelcast, opnar viðskiptavinarkóðinn (1) API. Hz gerir þér kleift að keyra þjóninn eins og embed in, og í þessu tilfelli er aðgangur að API aðferðarkall inni í JVM, sem getur talist ókeypis.
Til þess að rökfræðin í (2) virki, treystir Hz á kjötkássa bætafylkis raðnúmerslykillsins - það er að segja, lykillinn verður raðnúmeraður í öllum tilvikum. Þetta er óhjákvæmilegt kostnaður fyrir Hz.
Útrýmingaraðferðir eru vel útfærðar, en í sérstökum tilvikum geturðu bætt við þínu eigin. Þú þarft ekki að hafa áhyggjur af þessum hluta.
Hægt er að tengja geymslu (4). Frábært. Samskipti (5) fyrir embed in geta talist tafarlaus. Gagnaskipti milli hnúta í þyrpingunni (6) - já, það er til. Þetta er fjárfesting í bilanaþoli á kostnað hraða. Hz eiginleikinn Near-cache gerir þér kleift að lækka verðið - gögn sem berast frá öðrum hnútum í þyrpingunni verða vistuð í skyndiminni.
Hvað er hægt að gera við slíkar aðstæður til að auka hraðann?
Til dæmis, til að forðast raðgreiningu á lyklinum í (2) - festu annað skyndiminni ofan á Hazelcast, fyrir heitustu gögnin. Sportmaster valdi koffín í þessum tilgangi.
Fyrir snúning á stigi (6), býður Hz upp á tvær tegundir af geymslu: IMap og ReplicatedMap.
Það er þess virði að minnast á hvernig Hazelcast komst í Sportmaster tæknistaflann.
Árið 2012, þegar við vorum að vinna að fyrsta tilraunaverkefni framtíðarsíðunnar, var það Hazelcast sem reyndist vera fyrsti hlekkurinn sem leitarvélin skilaði. Kynnin byrjuðu „í fyrsta skiptið“ - við heilluðumst af þeirri staðreynd að aðeins tveimur tímum síðar, þegar við skrúfuðum Hz inn í kerfið, virkaði það. Og það virkaði vel. Í lok dags höfðum við lokið nokkrum prófum og vorum ánægð. Og þessi kraftaforði var nóg til að sigrast á óvart sem Hz kastaði upp með tímanum. Nú hefur Sportmaster liðið enga ástæðu til að yfirgefa Hazelcast.
En slík rök eins og „fyrsti hlekkurinn í leitarvélinni“ og „HelloWorld var fljótt settur saman“ eru auðvitað undantekning og einkenni augnabliksins þegar valið átti sér stað. Raunverulegar prófanir fyrir valið kerfi byrja með útgáfu í framleiðslu, og það er á þessu stigi sem þú ættir að fylgjast með þegar þú velur hvaða kerfi sem er, þar með talið skyndiminni. Reyndar má segja í okkar tilviki að við völdum Hazelcast óvart, en svo kom í ljós að við völdum rétt.
Fyrir framleiðslu, miklu mikilvægara: eftirlit, meðhöndlun bilana á einstökum hnútum, afritun gagna, kostnaður við skala. Það er að segja, það er þess virði að borga eftirtekt til verkefna sem munu koma upp við viðhald kerfisins - þegar álagið er tugfalt hærra en áætlað var, þegar við hleðum óvart upp einhverju á röngum stað, þegar við þurfum að rúlla út nýja útgáfu kóðans, skipta um gögn og gera það óséður fyrir viðskiptavini.
Fyrir allar þessar kröfur passar Hazelcast vissulega reikninginn.
Framhald
En Hazelcast er engin töfralyf. Árið 2017 völdum við Hazelcast fyrir stjórnanda skyndiminni, einfaldlega byggt á góðum birtingum frá fyrri reynslu. Þetta gegndi lykilhlutverki í mjög grimmilegum brandara, vegna þess að við lentum í erfiðri stöðu og komumst „hetjulega“ út úr henni í 60 daga. En meira um það í næsta hluta.
Í millitíðinni... Gleðilegan nýjan kóða!
Heimild: www.habr.com