{"id":73949,"date":"2020-03-13T02:42:07","date_gmt":"2020-03-12T23:42:07","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1"},"modified":"2020-03-13T02:42:07","modified_gmt":"2020-03-12T23:42:07","slug":"kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1","title":{"rendered":"Kuidas me Spordimeisters valisime vahem\u00e4lu s\u00fcsteemi. Osa 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Tere! Minu nimi on Alexey Pjankov, olen arendaja ettev\u00f5ttes Sportmaster. Sel postitusest<\/a><\/noindex> jagasime, kuidas Sportmasteri veebisaidi arendamine 2012. aastal algas, millised algatused \u00f5nnestus \"edendada\" ja vastupidi, milliseid takistusi me kogusime.<\/p>\n

T\u00e4na tahan jagada m\u00f5tteid, mis j\u00e4rgivad teistsugust teemat \u2013 jaotuss\u00fcsteemi valimist Java-taustal saidi administreerimiseks. See teema on mulle eriti t\u00e4htis \u2013 kuigi lugu kestis vaid 2 kuud, t\u00f6\u00f6tasime nendel 60 p\u00e4eval 12\u201316 tundi p\u00e4evas ja ilma \u00fchegi puhkep\u00e4evata. Ma pole kunagi varem m\u00f5elnud ega kujutlenud, et on v\u00f5imalik nii palju t\u00f6\u00f6tada.<\/p>\n

Seet\u00f5ttu jagan teksti kaheks osaks, et mitte \u00fcle koormata. Vastupidi, esimene osa on v\u00e4ga kerge \u2014 ettevalmistus, sissejuhatus, m\u00f5ned m\u00f5tted, mis on vahem\u00e4lu. Kui olete juba kogenud arendaja v\u00f5i olete t\u00f6\u00f6tanud vahem\u00e4ludega \u2014 tehnilisest k\u00fcljest ei leia te t\u00f5en\u00e4oliselt selles artiklis midagi uut. Siiski v\u00f5ib noorele arendajale see v\u00e4ike \u00fclevaade anda suuna, kuhu vaadata, kui ta satub sellisesse olukorda.<\/p>\n

\"Kuidas<\/a><\/noindex>
\n<\/a><\/noindex>
\nKui Sportmasteri uus veebiversioon lansseeriti, toimusid andmete edastamine viisil, pehmelt \u00f6eldes, mitte v\u00e4ga mugavalt. P\u00f5hialuseks olid tabelid, mis olid ette valmistatud eelmise veebiversiooni (Bitrix) jaoks, mida tuli ETL-sse t\u00f5mmata, uue vormi saavutamiseks muudatusi teha ja rikastada erinevate \u201es\u00fc\u017eeede\u201d abil veel k\u00fcmnest s\u00fcsteemist. Et uus pilt v\u00f5i tootekirjeldus veebilehele j\u00f5uaks, tuli oodata j\u00e4rgmise p\u00e4evani \u2014 uuendamine toimus ainult \u00f6\u00f6sel, \u00fcks kord p\u00e4evas.<\/p>\n

Alguses oli esimestel n\u00e4dalatel p\u00e4rast tootmisse minekut nii palju muresid, et sellised ebamugavused sisuhalduritele tundusid pisiasjadena. Kuid kui k\u00f5ik paika loksus, j\u00e4tkus projekti areng \u2014 m\u00f5ne kuu p\u00e4rast, 2015. aasta alguses, hakkasime aktiivselt arendama administreerimissektorit. 2015. ja 2016. aastatel l\u00e4ks k\u00f5ik h\u00e4sti, avaldasime regulaarselt uusi versioone, administreerimissektor h\u00f5lmas \u00fcha suuremat osa andmete ettevalmistamisest ja valmistusime selleks, et varsti usaldatakse meie meeskonnale k\u00f5ige t\u00e4htsam ja keerulisem \u00fclesanne \u2013 tootejoon (kogu tooteandmete ettevalmistamine ja haldamine). Kuid suvel 2017, just enne tootejoone k\u00e4ivitamist, sattus projekt v\u00e4ga keerulisse olukorda \u2013 just seoses vahem\u00e4lu probleemidega. Sellest episoodist tahangi r\u00e4\u00e4kida teises osas sellest kaheteisest avaldamisest.<\/p>\n

Kuid selles postituses alustan kaugelt, tuues v\u00e4lja m\u00f5ned m\u00f5tted \u2013 arusaamad vahem\u00e4llu salvestamisest, mille \u00fcle oleks enne suurt projekti hea ette m\u00f5elda.<\/p>\n

Kuidas vahem\u00e4lustamine tekib<\/h2>\n

\nVahem\u00e4lustamise \u00fclesanne ei teki lihtsalt niisama. Me oleme arendajad, kirjutame tarkvaratooteid ja soovime, et need oleksid n\u00f5utud. Kui toode on n\u00f5utud ja edukas \u2013 saabub \u00fcha rohkem kasutajaid. Ja aina rohkem ja rohkem. Ja siis on kasutajaid juba palju ning toode muutub suure koormusega.<\/p>\n

Esimestel etappidel me ei m\u00f5tle koodi optimeerimisele ja j\u00f5udlusele. Peamine on funktsionaalsus, kiiresti v\u00e4lja visata eskiis ja testida h\u00fcpoteese. Ja kui koormus kasvab \u2013 suurendame riistvara. Suurendame seda kaks-kolm-k\u00fcmme korda, olgu. Kusagil siin ei luba rahade t\u00f5us rohkem edasi minna. Ja mitu korda kasutajate hulk siis suureneb? See ei ole 2-5-10, vaid juhul, kui \u00f5nnestub \u2013 siis v\u00f5ib see kasvada 100-1000 ja kuni 100 000 korda. See t\u00e4hendab, et varem v\u00f5i hiljem tuleb optimeerimisega tegeleda.<\/p>\n

Oletame, et mingi osa koodist (nimetame seda osaks funktsiooniks) t\u00f6\u00f6tab h\u00e4biv\u00e4\u00e4rselt kaua ja me soovime v\u00e4hendada t\u00e4itmise aega. Funktsioon \u2013 see v\u00f5ib olla andmebaasi juurde p\u00e4\u00e4semine v\u00f5i mingi keerulise loogika t\u00e4itmine \u2013 oluline on, et see kestab kaua. Kui palju saame t\u00e4itmise aega v\u00e4hendada? Piiri\u00fcleselt \u2013 saame v\u00e4hendada nullini, mitte kaugemale. Kuidas saame t\u00e4itmise aja nullini v\u00e4hendada? Vastus: v\u00e4listada t\u00e4itmine \u00fcldse. Selle asemel saame kohe tagastada tulemuse. Kuidas teada saada tulemus? Vastus: kas arvutada v\u00f5i kuskil peegeldada. Arvutamine \u2013 see on pikk protsess. Ja peegeldamine \u2013 see t\u00e4hendab n\u00e4iteks meeles pidada, milline tulemus funktsioon eelmisel korral sama parameetritega andis.<\/p>\n

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

Main requirements for the caching system<\/h2>\n

\nThe first requirement for a caching system could be fast read speed and slightly less so for write speed. This is true, but only until we deploy the system into production.<\/p>\n

Let's consider such a case.<\/p>\n

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

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

But now, at one point, accidentally, the system failed and the cache crashed. Nothing special \u2014 we chose the cache based on the requirement of 'high read and write speed, the rest doesn't matter.'<\/p>\n

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

Even if our cache hasn\u2019t crashed but just cleared for a while \u2014 it will need to be warmed up, which will take some time. During this time, the main load will fall on the functionality.<\/p>\n

V\u00e4ljund: k\u00f5rge koormusega projektid tootmises n\u00f5uavad s\u00fcsteemilt mitte ainult kiiret lugemist ja kirjutamist, vaid ka andmete s\u00e4ilitamist ja t\u00f5rgeteta toimimist.<\/p>\n

Valikute vaev<\/h2>\n

\nProjektis, kus on administraatori paneel, l\u00e4ks valik nii: k\u00f5igepealt paigaldasime Hazelcasti, kuna olime selle tootega juba tuttavad meie p\u00f5hisaidi kogemuste kaudu. Kuid siin osutus selline valik eba\u00f5nnestumiseks \u2013 meie koormuse profiili juures t\u00f6\u00f6tab Hazelcast mitte lihtsalt aeglaselt, vaid kohutavalt aeglaselt. Ja tootmisse mineku t\u00e4htaegade osas olime me sel hetkel juba allkirjastanud.<\/p>\n

Spoiler: kuidas t\u00e4pselt tingimused kokku langesid, et me j\u00e4tsime sellise v\u00f5imaluse maha ja saime terava ning pingelise olukorra \u2014 r\u00e4\u00e4gin sellest teises osas \u2014 ja kuidas me sattusime, ja kuidas v\u00e4lja tulime. Kuid praegu \u2014 \u00fctlen ainult, et see oli suur stress, ja \"m\u00f5elda - kuidagi ei m\u00f5tle, raputame pudelit.\" \"Raputame pudelit\" \u2014 see on samuti spoiler, sellest veidi hiljem.<\/p>\n

Mida me tegime:<\/p>\n

    \n
  1. Koostame loendi k\u00f5igist s\u00fcsteemidest, mida Google ja StackOverflow soovitavad. Veidi rohkem kui 30<\/li>\n
  2. Kirjutame koormustestisid, mis on iseloomulikud tootmiskeskkonnale. Selleks salvestasime andmed, mis l\u00e4bivad s\u00fcsteemi tootmiskeskkonnas \u2014 omamoodi sniffer andmete jaoks, mis ei ole v\u00f5rgus, vaid s\u00fcsteemi sees. Testides k\u00e4ivitasime just need andmed.<\/li>\n
  3. Kogu tiim, iga\u00fcks valib j\u00e4rgmise s\u00fcsteemi loendist, seadistab, k\u00e4ivitab testid. Kui test ei l\u00e4he l\u00e4bi, ei suuda koormust taluda \u2013 viskame v\u00e4lja, liigume j\u00e4rgmise juurde.<\/li>\n
  4. 17. s\u00fcsteemis sai selgeks, et k\u00f5ik on lootusetu. Aeg on l\u00f5petada \"pudeli raputamine\", on aeg t\u00f5siselt j\u00e4rele m\u00f5elda.<\/li>\n<\/ol>\n

    \nKuid see on variant, kui tuleb valida s\u00fcsteem, mis \"mahub kiirusest\" ette valmistatud testides. Aga kui selliseid teste veel ei ole ja tahaks kiiremini valida?<\/p>\n

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

    Otsustades n\u00f5udmised, alustame valmis lahenduse valimist. Miks jalgratast uuesti leiutada: l\u00e4heme ja v\u00f5tame valmis vahem\u00e4lus\u00fcsteemi.<\/p>\n

    Kui te alles alustate ja Google'ist otsite, siis j\u00e4rjestus on enam-v\u00e4hem selline, kuid suunised j\u00e4\u00e4vad samaks. Esiteks satute Redis'e peale, see on igal pool teemaks. Siis saate teada, et on olemas EhCache, mis on \u00fcks vanimaid ja k\u00f5ige usaldusv\u00e4\u00e4rsemaid s\u00fcsteeme. J\u00e4rgmisena r\u00e4\u00e4gitakse Tarantoolist \u2014 kohalikust arendusest, millel on ainulaadne lahenduse aspekt. Ja samuti Ignite, kuna see on praegu populaarsuse t\u00f5usu teel ja saavad toetust SberTechi poolt. L\u00f5puks veel Hazelcast, kuna see tihti esineb ettev\u00f5tte maailmas suurte firmade seas.<\/p>\n

    See nimekiri ei ole l\u00f5plik, s\u00fcsteeme on k\u00fcmneid. Me k\u00e4sitleme ainult \u00fchte. Vaatame valitud 5 s\u00fcsteemi \u201eilu v\u00f5istlusele\u201d ja viime l\u00e4bi valiku. Kes saab v\u00f5itjaks?<\/p>\n

    Redis<\/h3>\n

    \nLoomulikult vaatame, mida ametlikul saidil kirjutatakse.
    \n    Redis<\/a><\/noindex> \u2014 avatud allikas projekt. Pakub andmete in-memory salvestust, v\u00f5imalust salvestada andmeid kettale, automaatset jagamist partiideks, k\u00f5rget k\u00e4ttesaadavust ja taastumist v\u00f5rgu katkemise j\u00e4rel.<\/p>\n

    Tundub, et k\u00f5ik on suurep\u00e4rane, seda v\u00f5ib v\u00f5tta ja kasutada \u2014 k\u00f5ik, mis vajalik, see teeb. Kuid vaatame lihtsalt huvi p\u00e4rast teisi kandidaate.<\/p>\n

    EhCache<\/h3>\n

    \nEhCache<\/a><\/noindex> \u2014 \u201ek\u00f5ige laialdasemalt kasutatav vahem\u00e4lu Java jaoks\u201d (ametliku saidi slogan t\u00f5lgituna). Samuti avatud allikas. Ja siit m\u00f5istame, et Redis ei ole Java jaoks, vaid \u00fcldine, ja selleks, et sellega suhelda, on vajalik wrapper. Kuid EhCache on mugavam. Mida veel s\u00fcsteem lubab? Usaldusv\u00e4\u00e4rsust, t\u00f5estatud tulemusi, t\u00e4isfunktsionaalsust. Ja pealegi on see k\u00f5ige levinum. Ja see cache'ib terabaiti andmeid.<\/p>\n

    Redis on unustatud, ma olen valmis valima EhCache'i.<\/p>\n

    Aga patriotismi tunne sunnib mind vaatama, millised omadused on Tarantoolil.<\/p>\n

    Tarantool<\/h3>\n

    \nTarantool<\/a><\/noindex> \u2014 esitleb end kui \u201eReaalajas andmete integreerimisplatvorm\u201d. Tundub v\u00e4ga keeruline, seega loeme lehte p\u00f5hjalikult ja leiame k\u00f5lava v\u00e4ite: \u201eCache'ib 100% andmeid operatiivm\u00e4lu.\u201d See peaks tekitama k\u00fcsimusi \u2014 sest andmeid v\u00f5ib olla oluliselt rohkem kui m\u00e4lu. Selgitus on selles, et Tarantool ei tee m\u00e4lu andmete kettale salvestamisel serialiseerimist. Selle asemel kasutab see madala taseme s\u00fcsteemi omadusi, kui m\u00e4lu lihtsalt kaardistatakse failis\u00fcsteemile, millel on v\u00e4ga head I\/O n\u00e4itajad. \u00dcldiselt, tehti kuidagi suurep\u00e4raselt ja toredalt.<\/p>\n

    Vaadakem rakendusi: Mail.ru ettev\u00f5tte taristu, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...<\/p>\n

    Kui Tarantooli osas oli veel mingeid kahtlusi, siis Mastercardi rakenduse juhtum on mind maha l\u00f6\u00f6nud. Valin Tarantooli.<\/p>\n

    Aga sellegipoolest\u2026<\/p>\n

    Ignite<\/h3>\n

    \n\u2026 on veel Ignite<\/a><\/noindex>, mida kirjeldatakse kui \u201ein-memory arvutusplatvorm\u2026 in-memory kiirus petabaidides andmetes\u201c. Siin on ka palju plusse: jaotatud in-memory vahem\u00e4lu, k\u00f5ige kiirem key-value salvestus ja vahem\u00e4lu, horisontaalne skaleeritavus, k\u00f5rge saadavus, range terviklikkus. Kokkuv\u00f5ttes, tundub, et k\u00f5ige kiirem ongi Ignite.<\/p>\n

    Rakendused: Sberbank, American Airlines, Yahoo! Japan. Ja siis ma veel avastan, et Ignite ei ole lihtsalt Sberbankis kasutusele v\u00f5etud, vaid SberTechi meeskond saadab oma inimesi Ignite\u2019i meeskonda toodet t\u00e4iustama. See ostab mind t\u00e4ielikult ja olen valmis Ignite\u2019i v\u00f5tma.<\/p>\n

    T\u00e4iesti arusaamatult vaatan viiendat punkti.<\/p>\n

    Hazelcast<\/h3>\n

    \nK\u00fclastan veebisaiti Hazelcast<\/a><\/noindex>, loen. Ja selgub, et k\u00f5ige kiirem lahendus jaotatud vahem\u00e4lu jaoks on Hazelcast. See on oluliselt kiirem kui k\u00f5ik teised lahendused ja on \u00fcldiselt liider in-memory andmev\u00f5rgu valdkonnas. Sellise taustaga on midagi muud v\u00f5tta enda mitte austamisele.<\/p>\n

    K\u00f5ik, olen valmis Hazelcasti v\u00f5tma.<\/p>\n

    V\u00f5rdlus<\/h2>\n

    \nAga kui vaadata, siis k\u00f5ik viis kandidaati on nii kirja pandud, et iga\u00fches neist \u2013 parim. Kuidas valida? V\u00f5ime vaadata, milline neist on k\u00f5ige populaarsem, otsida v\u00f5rreldes ja peavalu kaob.<\/p>\n

    Leidsime sellise \u00fclevaade<\/a><\/noindex>, valime meie 5 s\u00fcsteemi.<\/p>\n

    \"Kuidas
    \n
    \nSiin on nad j\u00e4rjestatud: eespool Redis, teisel kohal \u2014 Hazelcast, populaarsust koguvad Tarantool ja Ignite, EhCache j\u00e4\u00e4b endiseks. <\/p>\n

    Aga vaatame arvutusmeetodit<\/a><\/noindex>: lingid veebisaitidele, s\u00fcsteemi \u00fcldine huvi, t\u00f6\u00f6pakkumised \u2014 tore! Siis, kui minu s\u00fcsteem kokku kukub, \u00fctlen: \u201eEi, see on ju usaldusv\u00e4\u00e4rne! Siin on palju t\u00f6\u00f6pakkumisi\u2026\u201d. Selline lihtne v\u00f5rdlus ei sobi.<\/p>\n

    K\u00f5ik need s\u00fcsteemid ei ole lihtsalt vahem\u00e4llu salvestamise s\u00fcsteemid. Neil on veel palju funktsioone, sealhulgas \u2013 kui mitte andmeid edastatakse kliendile t\u00f6\u00f6tluseks, vaid vastupidiselt: kood, mida peab andmete \u00fcle t\u00f6\u00f6tlema, liigub serverisse, seal k\u00e4ivitatakse ja tulemus tagastatakse. Ja kui eraldi vahem\u00e4lu s\u00fcsteemina ei vaadata neid nii sageli.<\/p>\n

    Hea, ei anname alla, leiame otsese v\u00f5rdluse s\u00fcsteemide vahel. V\u00f5tame kaks \u00fclemist varianti \u2014 Redis ja Hazelcast. Meid huvitab kiirus, selle parameetri p\u00f5hjal neid ka v\u00f5rreldakse.<\/p>\n

    Hz vs Redis<\/h3>\n

    \nLeidsime sellise v\u00f5rdlus<\/a><\/noindex>:
    \n\"Kuidas
    \n
    \nSinine on Redis, punane Hazelcast. Hazelcast v\u00f5idab k\u00f5ikides v\u00f5rdlustes ning sellel on oma p\u00f5hjused: see on mitme l\u00f5imega, tugevalt optimeeritud, iga l\u00f5im t\u00f6\u00f6tab oma partiiga, seega ei toimu ummikuid. Redis on aga \u00fche l\u00f5imega, seega ei suuda see t\u00e4nap\u00e4evastelt mitme tuumalistelt CPU-delt v\u00f5itu saada. Hazelcast kasutab as\u00fcnkroonset I\/O-d, Redis-Jedis aga blokeerivaid socket-e. L\u00f5ppude l\u00f5puks kasutab Hazelcast binaarset protokolli, samas kui Redis on suunatud tekstile, mis t\u00e4hendab, et see on ebaefektiivne.<\/p>\n

    Igaks juhuks viidates veel \u00fchele v\u00f5rdluse allikale. Mida see meile n\u00e4itab?<\/p>\n

    Redis vs Hz<\/h3>\n

    \nVeel \u00fcks v\u00f5rdlus<\/a><\/noindex>:
    \n\"Kuidas
    \n
    \nSiin on vastupidi, punane on Redis. See t\u00e4hendab, et Redis v\u00f5idab Hazelcasti tootlikkuses. Esimeses v\u00f5rdluses v\u00f5itis Hazelcast, teises aga Redis.     Siin<\/a><\/noindex> on v\u00e4ga t\u00e4pselt selgitatud, miks eelnevas v\u00f5rdluses v\u00f5itis Hazelcast.<\/p>\n

    Selgub, et esimese tulemus oli faktiliselt vale: Redis v\u00f5eti p\u00f5hiversioonis, samas kui Hazelcast kohandati testjuhtumi jaoks. Nii et kokkuv\u00f5ttes: esiteks, kellelegi ei saa usaldada, teiseks, kui me ikkagi valime s\u00fcsteemi, siis peame selle ka \u00f5igesti seadistama. Need seaded h\u00f5lmavad k\u00fcmneid, peaaegu sadu parameetreid.<\/p>\n

    Raputame pudelit<\/h2>\n

    \nJa kogu protsessi, mida me praegu l\u00e4bime, saan ma selgitada sellise metafooriga \u00abRaputame pudelit\u00bb. See t\u00e4hendab, et praegu ei ole vaja programmeerida, praegu on peamine osata lugeda stackoverflow-d. Ja minu meeskonnas on inimene, professionaal, kes t\u00f6\u00f6tab just niimoodi kriitilistel hetkedel.<\/p>\n

    Mida ta teeb? Ta n\u00e4eb mitte t\u00f6\u00f6tavat asja, n\u00e4eb stack trace'i, v\u00f5tab sealt s\u00f5nu (milli just \u2014 see on tema ekspertiis programmis), otsib Googlest, leiab stackoverflow vastuste seast. Mitte lugedes, mitte m\u00f5eldes, vastuste seas valib ta midagi, mis on k\u00f5ige sarnasem v\u00e4ljendiga \u00abteha seda ja toda\u00bb (selle vastuse valimine on tema talent, kuna see ei pruugi alati olla see vastus, mis on saanud rohkem h\u00e4\u00e4li), rakendab, vaatab: kui midagi on muutunud, siis on k\u00f5ik korras. Kui ei ole muutunud \u2014 tagastame. Ja kordame k\u00e4ivitamist-kontrollimist-otsimist. Ja niimoodi intuitsiooniga saavutab ta selle, et mingil hetkel kood t\u00f6\u00f6tab. Ta ei tea, miks, ta ei tea, mida ta tegi, ta ei oska selgitada. Kuid! See jama t\u00f6\u00f6tab. Ja \u00abtuli on kustutatud\u00bb. N\u00fc\u00fcd saame aru, mida me tegime. Kui programm t\u00f6\u00f6tab \u2014 on see kordades lihtsam. Ja s\u00e4\u00e4stab oluliselt aega.<\/p>\n

    See, this method is very well explained with such an example.<\/p>\n

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

    \"Kuidas
    \n
    \nThere is a method, very quick and very effective.<\/p>\n

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

    We show this something to someone: \"Seryoga, see!?\". And indeed, from a distance \u2013 it looks like a ship. But you can't let it go further.<\/p>\n

    There's another way. More advanced guys, like hackers, use it.<\/p>\n

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

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

    Ainult \u00fcks koht, v\u00f5tmekoht, millega t\u00f5eliselt midagi ei saa ette v\u00f5tta, on korpus. Ja laeva korpus l\u00e4heb justkui kaela kaudu l\u00e4bi. Samas kui laev ehitatakse pudelist v\u00e4lja. Kuid see ei ole lihtsalt laeva kokku panemine, see on t\u00f5eline kullaomaniku k\u00e4sit\u00f6\u00f6. Koos komponentidega lisatakse spetsiaalsed k\u00e4epidemed, mis v\u00f5imaldavad neid hiljem \u00fcles t\u00f5sta. N\u00e4iteks volditakse purjed ettevaatlikult sisse ja seej\u00e4rel t\u00f5mmatakse ja t\u00f5stetakse neid v\u00e4ga t\u00e4pselt pintsettidega. Tulemusena saadakse kunstiteos, mida saab puhta s\u00fcdametunnistuse ja uhkusega kinkida.<\/p>\n

    Ja kui me tahame, et projekt oleks edukas \u2013 peab meeskonnas olema v\u00e4hemalt \u00fcks kuldsep. See, kes hoolib toote kvaliteedist ja arvestab k\u00f5iki aspekte, mitte \u00fchtegi ohverdades isegi stressi hetkedel, kui olud n\u00f5uavad kiiret, mis tuleb olulise arvelt. K\u00f5ik edukad projektid, mis on vastupidavad ja mis on aja katsumuse vastu pidanud, on selle p\u00f5him\u00f5tte p\u00f5hjal ehitatud. Neis on midagi v\u00e4ga t\u00e4pset ja ainulaadset, midagi, mis kasutab k\u00f5iki saadaval olevaid v\u00f5imalusi. N\u00e4ites pudelilaeva kohta - m\u00e4ngitakse v\u00e4lja see, et laeva korpus l\u00e4heb l\u00e4bi kaela.<\/p>\n

    Tagasi tulles \u00fclesande juurde, kuidas valida meie vahem\u00e4lu serverit, kuidas seda meetodit v\u00f5iks rakendada? Ma pakun v\u00e4lja sellise valiku k\u00f5igist olemasolevatest s\u00fcsteemidest - mitte pudelit raputada, mitte valida, vaid vaadata, mis seal tegelikult on, millele t\u00e4helepanu p\u00f6\u00f6rata s\u00fcsteemi valimisel.<\/p>\n

    Kus otsida pudelikaela<\/h2>\n

    \nProovime mitte pudelit raputada, mitte j\u00e4rjest k\u00f5ike l\u00e4bi vaadata, vaid vaatame, millised \u00fclesanded v\u00f5ivad tekkida, kui peaksime oma \u00fclesande jaoks iseseisvalt sellise s\u00fcsteemi projekteerima. Jalgratast me loomulikult ei leiuta, kuid kasutame seda skeemi, et orienteeruda, millele t\u00e4helepanu p\u00f6\u00f6rata toodete kirjeldustes. Joonistame v\u00e4lja sellise skeemi.<\/p>\n

    \"Kuidas
    \n
    \nKui s\u00fcsteem on jagatud, siis on meil mitmeid servereid (6). Oletame, et neli (mugav joonistada pildile, kuid neid v\u00f5ib olla igasugune hulk). Kui serverid asuvad erinevates s\u00f5lmedes, siis t\u00f6\u00f6tab neis k\u00f5igis mingi kood, mis vastutab selle eest, et need s\u00f5lmed moodustaksid klastri ja katkestamise korral - \u00fchenduksid, tunneksid \u00fcksteist.<\/p>\n

    Vajame ka koodilogikat (2), mis sisuliselt tegeleb vahenduse vahem\u00e4llu salvestamisega. Selle koodiga suhtlevad kliendid teatud API kaudu. Klientide kood (1) v\u00f5ib olla nii sellesama JVM raames kui ka sellele v\u00f5rgu kaudu juurde p\u00e4\u00e4seda. Sees rakendatud loogika m\u00e4\u00e4rab, millised objektid j\u00e4\u00e4vad vahem\u00e4llu ja millised visatakse v\u00e4lja. Vahem\u00e4lu hoidmiseks kasutame m\u00e4lu (3), kuid vajadusel saame osa andmeid ka kettale salvestada (4).<\/p>\n

    Vaatame, millistes osades koormus tekib. Tegelikult koormatakse iga noolt ja igat s\u00f5lme. Esiteks klientide koodi ja API vahel, kui see on v\u00f5rguvaheline suhtlemine, v\u00f5ib allasurumine olla \u00fcsna m\u00e4rgatav. Teiseks, API enda raames - kui keerukaks loogikaks minna, v\u00f5ime j\u00f5uda CPU piirini. Ja oleks hea, kui loogika ei sunniks m\u00e4lu liigset kasutama. J\u00e4\u00e4b veel suhtlemine failis\u00fcsteemiga \u2013 tavap\u00e4rasel juhul tuleb see serialiseerida \/ taastada ja kirjutada \/ lugeda.<\/p>\n

    Edasi liikudes klastriga suhtlemine. T\u00f5en\u00e4oliselt on see samas s\u00fcsteemis, kuid v\u00f5ib olla ka eraldi. Siin tuleb samuti arvesse v\u00f5tta andmete edastamist, andmete serialiseerimise kiirus ja suhtlemine klastriga.<\/p>\n

    N\u00fc\u00fcd, \u00fchelt poolt - saame m\u00f5elda, \"millised hammasrattad p\u00f6\u00f6rlevad\" vahem\u00e4lu s\u00fcsteemis meie koodi p\u00e4ringute t\u00f6\u00f6tlemisel, ja teiselt poolt - saame hinnata, kui palju ja milliseid p\u00e4ringuid meie kood sellele s\u00fcsteemile genereerib. Seda on piisavalt, et teha enam-v\u00e4hem tasakaalustatud valik - valida s\u00fcsteem vastavalt meie kasutusvariandile.<\/p>\n

    Hazelcast<\/b><\/p>\n

    Vaatame, kuidas sellist jaotust oma nimekirjale rakendada. N\u00e4iteks Hazelcast.<\/p>\n

    Kuna andmete lisamiseks \/ v\u00f5tmiseks Hazelcastist p\u00f6\u00f6rdub kliendi kood (1) API poole. Hz v\u00f5imaldab k\u00e4ivitada serverit kui embedded, ja sellisel juhul on API-le p\u00f6\u00f6rdumine meetodi kutsumine JVM sees, mida v\u00f5ib pidada tasuta.<\/p>\n

    Kuna loogika (2) t\u00f6\u00f6tamiseks toetub Hz serialiseeritud v\u00f5tme baitmassiivist saadud hash'ile \u2013 see t\u00e4hendab, et v\u00f5tme serialiseerimine toimub igal juhul. See on Hz jaoks v\u00e4ltimatu \u00fclej\u00e4\u00e4k.
    \nEemaldamisstrateegiad on h\u00e4sti rakendatud, kuid erijuhtudel \u2013 saab lisada oma. Selle osa p\u00e4rast ei ole vaja muretseda.<\/p>\n

    Salvestust (4) saab \u00fchendada. Suurep\u00e4rane. Interaktsioon (5) embedded jaoks v\u00f5ib pidada koheseks. Andmete vahetamine s\u00f5lmede vahel klastris (6) \u2013 jah, see on olemas. See on panus s\u00fcsteemi t\u00f6\u00f6kindluse nimel, ohverdatud kiirusel. Hinna langetamine on v\u00f5imalik Hz-funktsiooniga Near-cache \u2013 andmed, mis saadakse teistelt klastrinoodidelt, salvestatakse vahem\u00e4lu.<\/p>\n

    Mida sellistes tingimustes teha kiiruselise t\u00f5usu saavutamiseks?<\/p>\n

    N\u00e4iteks, et v\u00e4ltida v\u00f5tme serialiseerimist (2) \u2013 lisada Hazelcastile veel \u00fcks vahem\u00e4lu, k\u00f5ige kuumemate andmete jaoks. Sportmasteris v\u00e4lja valitud Caffeine.<\/p>\n

    Selle taseme (6) optimeerimiseks pakub Hz kahte t\u00fc\u00fcpi salvestamist: IMap ja ReplicatedMap.
    \n\"Kuidas
    \n
    \nTuleb mainida, kuidas Hazelcast sattus Sportmasteri tehnoloogia virna.<\/p>\n

    Aastal 2012, kui t\u00f6\u00f6tasime tulevase saidi esimeses pilotprojektis, osutus Hazelcast just esimeseks lingiks, mille otsingumootor v\u00e4ljastas. Kohtumine algas \"esimese korraga\" \u2013 meid v\u00f5lus see, et vaid kahe tunni p\u00e4rast, kui me Hz s\u00fcsteemi lisasime \u2013 see t\u00f6\u00f6tas. Ja t\u00f6\u00f6tas h\u00e4sti. P\u00e4rast seda p\u00e4eva lisasime palju teste, olime r\u00f5\u00f5msad. Ja see energiat\u00e4idetus piisavalt, et \u00fcletada need \u00fcllatused, mida Hz aja jooksul k\u00fclvas. Praeguseks pole Sportmasteri meeskonnal p\u00f5hjuseid Hazelcastist loobuda.<\/p>\n

    Kuid sellised argumendid nagu \u201eesimene link otsingumootoris\u201c ja \u201ekiirelt kokkupanek HelloWorld'ile\u201c on muidugi erand ja hetkeomadus, milles valik toimus. T\u00f5elised katsed valitud s\u00fcsteemi jaoks algavad tootmisfaasis, ja just sellele etapile tasub t\u00e4helepanu p\u00f6\u00f6rata iga s\u00fcsteemi, kaasa arvatud vahem\u00e4lu, valimisel. Tegelikult v\u00f5ib meie puhul \u00f6elda, et valisime Hazelcast juhuslikult, kuid hiljem selgus, et tegime \u00f5ige valiku.<\/p>\n

    Tootmises on palju olulisemad: j\u00e4lgimine, vigade k\u00e4sitsemine eraldi s\u00f5lmedes, andmete replikatsioon, skaleerimise kulud. Seega tasub p\u00f6\u00f6rata t\u00e4helepanu \u00fclesannetele, mis tekivad just s\u00fcsteemi haldamisel \u2013 siis, kui koormus \u00fcletab korduvalt planeeritud taset, kui juhuslikult laadime midagi vale ja valesse kohta, kui on vajalik uue koodiversiooni v\u00e4ljat\u00f6\u00f6tamine, andmete asendamine ja selle tegemine klientidele m\u00e4rkamatuks.<\/p>\n

    K\u00f5ikide nende n\u00f5udmiste jaoks sobib Hazelcast kindlasti.<\/p>\n

    J\u00e4tkub<\/h2>\n

    \nKuid Hazelcast ei ole imevahend. 2017. aastal valisime Hazelcasti administreerimise vahem\u00e4lu jaoks, tuginedes lihtsalt varasemate kogemuste heale muljele. See m\u00e4ngis v\u00f5tmerolli v\u00e4ga halvas naljas, mis viis meid keerulisse olukorda, millest ''kangelaslikult'' p\u00e4\u00e4sesime 60 p\u00e4evaga. Kuid sellest r\u00e4\u00e4gime j\u00e4rgmises osas.<\/p>\n

    Ja seni\u2026 Head uut koodi!
    \n
    Allikas:     habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

    \u041f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041f\u044c\u044f\u043d\u043a\u043e\u0432, \u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440. \u0412 \u044d\u0442\u043e\u043c \u043f\u043e\u0441\u0442\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b, \u043a\u0430\u043a \u043d\u0430\u0447\u0438\u043d\u0430\u043b\u0430\u0441\u044c \u0440\u0430\u0431\u043e\u0442\u0430 \u043d\u0430\u0434 \u0441\u0430\u0439\u0442\u043e\u043c \u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440 \u0432 2012 \u0433\u043e\u0434\u0443, \u043a\u0430\u043a\u0438\u0435 \u0438\u043d\u0438\u0446\u0438\u0430\u0442\u0438\u0432\u044b \u0443\u0434\u0430\u043b\u043e\u0441\u044c \u00ab\u043f\u0440\u043e\u0442\u043e\u043b\u043a\u043d\u0443\u0442\u044c\u00bb \u0438 \u043d\u0430\u043e\u0431\u043e\u0440\u043e\u0442, \u043a\u0430\u043a\u0438\u0435 \u0433\u0440\u0430\u0431\u043b\u0438 \u043c\u044b \u0441\u043e\u0431\u0440\u0430\u043b\u0438. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u044f \u0445\u043e\u0447\u0443 \u043f\u043e\u0434\u0435\u043b\u0438\u0442\u044c\u0441\u044f \u043c\u044b\u0441\u043b\u044f\u043c\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0441\u043b\u0435\u0434\u0443\u044e\u0442 \u0437\u0430 \u0434\u0440\u0443\u0433\u0438\u043c \u0441\u044e\u0436\u0435\u0442\u043e\u043c \u2013 \u0432\u044b\u0431\u043e\u0440 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u043a\u0435\u0448\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0434\u043b\u044f java-\u0431\u044d\u043a\u0435\u043d\u0434\u0430 \u0432 \u0430\u0434\u043c\u0438\u043d\u043a\u0435 \u0441\u0430\u0439\u0442\u0430. \u042d\u0442\u043e\u0442 \u0441\u044e\u0436\u0435\u0442 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":73950,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-73949","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Kuidas me Sportmasteris valisime vahem\u00e4lu s\u00fcsteemi. Osa 1 | ProHoster","description":"Tere! Minu nimi on Aleksei Pjankov, ma olen arendaja ettev\u00f5ttes Sportmaster.","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u0430\u043a \u043c\u044b \u0432 \u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440\u0435 \u0432\u044b\u0431\u0438\u0440\u0430\u043b\u0438 \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u043a\u0435\u0448\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f. \u0427\u0430\u0441\u0442\u044c 1 | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041f\u044c\u044f\u043d\u043a\u043e\u0432, \u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440.","og:url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-03-12T23:42:07+00:00","article:modified_time":"2020-03-12T23:42:07+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"73949","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 18:23:51","updated":"2022-09-28 05:05:57","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/73949","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=73949"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/73949\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media\/73950"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=73949"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=73949"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=73949"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}