{"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\/sv\/blog\/administrirovanie\/kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1","title":{"rendered":"S\u00e5 valde vi cache-systemet p\u00e5 Sportmaster. Del 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hej! Jag heter Alexey Pyankov, jag \u00e4r utvecklare p\u00e5 f\u00f6retaget Sportmaster. I detta inl\u00e4gg<\/a><\/noindex> ber\u00e4ttade jag om hur arbetet med Sportmasters webbplats b\u00f6rjade 2012, vilka initiativ vi lyckades \"trycka igenom\" och tv\u00e4rtom, vilka fallgropar vi st\u00f6tte p\u00e5.<\/p>\n

Idag vill jag dela med mig av tankar som f\u00f6ljer ett annat \u00e4mne \u2013 valet av cache-system f\u00f6r java-backenden i webbplatsens adminpanel. Detta \u00e4mne har en s\u00e4rskild betydelse f\u00f6r mig \u2013 \u00e4ven om historien utspelade sig under bara 2 m\u00e5nader, arbetade vi dessa 60 dagar 12-16 timmar om dagen utan en enda ledig dag. Jag har aldrig tidigare t\u00e4nkt eller f\u00f6rest\u00e4llt mig att man kan arbeta s\u00e5 mycket.<\/p>\n

D\u00e4rf\u00f6r delar jag texten i 2 delar f\u00f6r att inte \u00f6verbelasta helt. Tv\u00e4rtom, f\u00f6rsta delen kommer att vara mycket l\u00e4tt \u2013 en f\u00f6rberedelse, en introduktion, n\u00e5gra tankar om vad caching \u00e4r. Om du redan \u00e4r en erfaren utvecklare eller har arbetat med cachar, kommer det troligtvis inte finnas n\u00e5got nytt ur teknisk synpunkt i denna artikel. Men f\u00f6r en junior kan en liten \u00f6versikt ge en vink om vilken riktning man ska titta i, om man befinner sig vid en s\u00e5dan korsning.<\/p>\n

\"S\u00e5<\/a><\/noindex>
\n<\/a><\/noindex>
\nN\u00e4r den nya versionen av Sportmasters webbplats lanserades i produktion, kom data p\u00e5 ett s\u00e4tt som, milt sagt, inte var s\u00e4rskilt praktiskt. Grunden var tabeller som f\u00f6rberetts f\u00f6r den tidigare versionen av webbplatsen (Bitrix), som beh\u00f6vde dras in i ETL, omformas och berikas med olika till\u00e4gg \u00e4ven fr\u00e5n ett dussin andra system. F\u00f6r att den nya bilden eller produktbeskrivningen skulle dyka upp p\u00e5 webbplatsen, var man tvungen att v\u00e4nta till n\u00e4sta dag \u2013 uppdateringen skedde bara p\u00e5 natten, en g\u00e5ng om dagen.<\/p>\n

I b\u00f6rjan var det s\u00e5 m\u00e5nga bekymmer under de f\u00f6rsta veckorna av produktlanseringen att content managers' besv\u00e4r k\u00e4ndes som struntsaker. Men s\u00e5 snart allt hade stabiliserat sig fortsatte projektet att utvecklas \u2014 n\u00e5gra m\u00e5nader senare, i b\u00f6rjan av 2015, b\u00f6rjade vi aktivt utveckla administrationsgr\u00e4nssnittet. Under 2015 och 2016 gick allt bra, vi sl\u00e4ppte regelbundet nya versioner, administrationsgr\u00e4nssnittet t\u00e4ckte allt st\u00f6rre delar av databehandlingen och vi f\u00f6rberedde oss p\u00e5 att snart f\u00e5 det mest viktiga och utmanande \u2013 produktfl\u00f6det (fullst\u00e4ndig hantering och underh\u00e5ll av data f\u00f6r alla produkter). Men sommaren 2017, precis innan lanseringen av produktfl\u00f6det, befann sig projektet i en mycket sv\u00e5r situation \u2013 just p\u00e5 grund av problem med cachehantering. Om detta avsnitt vill jag ber\u00e4tta i den andra delen av denna tv\u00e5delade publikation.<\/p>\n

Men i detta inl\u00e4gg b\u00f6rjar jag fr\u00e5n b\u00f6rjan, sammanfattar n\u00e5gra tankar \u2013 f\u00f6rest\u00e4llningar om caching, som det skulle vara bra att ha f\u00f6rhandsgranskat innan ett stort projekt.<\/p>\n

N\u00e4r cachingproblematiken uppst\u00e5r<\/h2>\n

\nCachingproblematiken uppst\u00e5r inte av sig sj\u00e4lv. Vi \u00e4r utvecklare, vi skriver mjukvaruprodukter och vill att de ska vara efterfr\u00e5gade. Om produkten \u00e4r efterfr\u00e5gad och framg\u00e5ngsrik \u2014 s\u00e5 kommer anv\u00e4ndarna. De kommer och kommer, och pl\u00f6tsligt har vi en stor m\u00e4ngd anv\u00e4ndare, och produkten blir h\u00f6gt belastad.<\/p>\n

I de tidiga stadierna t\u00e4nker vi inte p\u00e5 kodens optimering och prestanda. Det viktigaste \u00e4r funktionaliteten, att snabbt rulla ut en pilotversion och testa hypoteser. Och om belastningen \u00f6kar \u2013 f\u00f6rb\u00e4ttrar vi h\u00e5rdvaran. Vi \u00f6kar kapaciteten med tv\u00e5 till tre, fem, kanske tio g\u00e5nger. Vid en viss punkt kommer ekonomin att s\u00e4tta stopp. Men hur mycket kommer antalet anv\u00e4ndare att \u00f6ka? Det kommer inte bara vara 2-5-10, utan i h\u00e4ndelse av framg\u00e5ng \u2013 kan det g\u00e5 fr\u00e5n 100-1000 upp till 100 000 g\u00e5nger. S\u00e5 f\u00f6rr eller senare kommer vi att beh\u00f6va ta itu med optimering.<\/p>\n

Anta att en viss del av koden (l\u00e5t oss kalla den h\u00e4r delen f\u00f6r en funktion) tar orimligt l\u00e5ng tid att k\u00f6ra, och vi vill minska exekveringstiden. En funktion kan vara \u00e5tkomst till databas, det kan vara att utf\u00f6ra n\u00e5gon komplex logik - huvudsaken \u00e4r att det tar l\u00e5ng tid. Hur mycket kan vi minska exekveringstiden? I teorin kan vi minska den till noll, inte l\u00e4ngre. Men hur kan vi minska exekveringstiden till noll? Svaret: helt enkelt hoppa \u00f6ver exekveringen. Ist\u00e4llet kan vi direkt returnera resultatet. Hur vet vi resultatet? Svaret: antingen ber\u00e4kna det eller kolla n\u00e5gonstans. Att ber\u00e4kna det \u00e4r l\u00e5ngsamt. Att kolla betyder till exempel att komma ih\u00e5g det resultat som funktionen gav vid senaste anropet med samma parametrar.<\/p>\n

Det betyder att implementationen av funktionen \u00e4r irrelevant f\u00f6r oss. Det \u00e4r tillr\u00e4ckligt att veta vilka parametrar som resultatet beror p\u00e5. Om vi d\u00e5 kan representera v\u00e4rdena f\u00f6r parametrarna som ett objekt som kan anv\u00e4ndas som nyckel i n\u00e5got lagringsutrymme - kan vi spara resultatet av ber\u00e4kningen och vid n\u00e4sta anrop h\u00e4mta det. Om dessa skrivning-och-l\u00e4sning av resultatet g\u00e5r snabbare \u00e4n att k\u00f6ra funktionen - har vi en hastighetsf\u00f6rdel. Styrkan i f\u00f6rdelen kan n\u00e5 upp till 100, 1000 eller 100 000 g\u00e5nger (10^5 - det \u00e4r mer av en undantag, men i ett fall med en ordentligt sl\u00f6 databas - helt m\u00f6jligt).<\/p>\n

Huvudkraven f\u00f6r ett cache-system<\/h2>\n

\nDet f\u00f6rsta som kan bli ett krav f\u00f6r ett cache-system \u00e4r snabb l\u00e4shastighet och i n\u00e5got mindre grad - skrivhastighet. Det \u00e4r sant, men bara tills vi rullar ut systemet i produktion.<\/p>\n

L\u00e5t oss ta ett s\u00e5dant scenario.<\/p>\n

Anta att vi har s\u00e4kerst\u00e4llt h\u00e5rdvaran f\u00f6r den nuvarande belastningen och nu l\u00e5ngsamt b\u00f6rjar inf\u00f6ra caching. Antalet anv\u00e4ndare \u00f6kar n\u00e5got, belastningen v\u00e4xer - vi l\u00e4gger till n\u00e5gra cache-poster, kopplar in dem h\u00e4r och d\u00e4r. S\u00e5 forts\u00e4tter det ett tag, och nu anropas de tunga funktionerna i stort sett inte l\u00e4ngre - hela den huvudsakliga belastningen faller p\u00e5 cachen. Antalet anv\u00e4ndare har under denna tid \u00f6kat N g\u00e5nger.<\/p>\n

Och om den initiala h\u00e5rdvarureserven kunde vara 2-5 g\u00e5nger, s\u00e5 kunde vi med caching dra upp prestandan 10 g\u00e5nger eller, i b\u00e4sta fall, 100 g\u00e5nger, ibland kanske \u00e4ven 1000 g\u00e5nger. Det vill s\u00e4ga, p\u00e5 samma h\u00e5rdvara - behandlar vi 100 g\u00e5nger fler f\u00f6rfr\u00e5gningar. Fantastiskt, vi f\u00f6rtj\u00e4nar en bel\u00f6ning!<\/p>\n

Men nu, pl\u00f6tsligt, gav systemet upp och cachen kraschade. Inget speciellt \u2013 cachen valdes efter kravet \"h\u00f6g l\u00e4shastighet och skrivhastighet, resten spelar ingen roll\".<\/p>\n

Vad g\u00e4ller den initiala belastningen hade vi en h\u00e5rdvarumarginal p\u00e5 2-5 g\u00e5nger, medan belastningen under den tiden \u00f6kade 10-100 g\u00e5nger. Med hj\u00e4lp av cachen utesl\u00f6t vi anrop f\u00f6r tunga funktioner och d\u00e4rf\u00f6r fl\u00f6t allt p\u00e5. Men nu, utan cache \u2013 hur mycket kommer v\u00e5r system att sjunka? Vad kommer att h\u00e4nda? Systemet kommer att g\u00e5 ner.<\/p>\n

\u00c4ven om v\u00e5r cache inte kraschade, utan bara rensades under en tid \u2013 m\u00e5ste den v\u00e4rmas upp, och det kommer att ta tid. Och under den tiden kommer den huvudsakliga belastningen att ligga p\u00e5 funktionaliteten.<\/p>\n

Slutsats: h\u00f6gbelastade projekt i produktion kr\u00e4ver att systemet f\u00f6r caching inte bara har h\u00f6g l\u00e4shastighet och skrivhastighet, utan ocks\u00e5 dataskydd och stabilitet mot st\u00f6rningar.<\/p>\n

Valets pl\u00e5gor<\/h2>\n

\nI projektet med adminpanelen gjordes valet s\u00e5 h\u00e4r: f\u00f6rst installerades Hazelcast, eftersom vi redan var bekanta med denna produkt fr\u00e5n erfarenheten av huvudwebbplatsen. Men h\u00e4r visade sig detta val vara olyckligt \u2013 f\u00f6r v\u00e5r belastningsprofil arbetar Hazelcast inte bara l\u00e5ngsamt, utan fruktansv\u00e4rt l\u00e5ngsamt. Och med tidsramarna f\u00f6r att f\u00e5 ut det i produktion hade vi redan skrivit p\u00e5.<\/p>\n

Spoiler: hur omst\u00e4ndigheterna utvecklade sig till att vi missade en s\u00e5dan \u00f6verraskning och hamnade i en akut och sp\u00e4nd situation \u2013 kommer jag att ber\u00e4tta i del tv\u00e5 \u2014 och hur vi hamnade d\u00e4r, och hur vi kom ut. Men just nu \u2013 s\u00e4ger jag bara att det var en stor stress, och \"att t\u00e4nka \u2013 g\u00e5r liksom inte, vi skakar flaskan\". \"Vi skakar flaskan\" \u2013 det \u00e4r ocks\u00e5 en spoiler, om det lite l\u00e4ngre fram.<\/p>\n

Vad vi gjorde:<\/p>\n

    \n
  1. Vi sammanst\u00e4ller en lista \u00f6ver alla system som Google och StackOverflow f\u00f6resl\u00e5r. Lite mer \u00e4n 30.<\/li>\n
  2. Vi skriver tester med belastning som \u00e4r typisk f\u00f6r produktion. F\u00f6r detta har vi spelat in data som passerar genom systemet i produktionsmilj\u00f6n \u2013 en typ av sniffer f\u00f6r data som inte \u00e4r p\u00e5 n\u00e4tet, men inom systemet. Dessa data k\u00f6rde vi i testerna.<\/li>\n
  3. Hela teamet, var och en v\u00e4ljer n\u00e4sta system fr\u00e5n listan, konfigurerar och k\u00f6r tester. G\u00e5r inte testet, klarar inte belastningen \u2013 sl\u00e4nger vi det och g\u00e5r vidare till n\u00e4sta p\u00e5 tur.<\/li>\n
  4. Vid det 17:e systemet blev det klart att allt var hoppl\u00f6st. Dags att sluta med \"att skaka flaskan\", vi m\u00e5ste t\u00e4nka allvarligt.<\/li>\n<\/ol>\n

    \nMen detta \u00e4r ett alternativ n\u00e4r man beh\u00f6ver v\u00e4lja ett system som \"klarar hastighetskraven\" i f\u00f6rberedda tester. Men om s\u00e5dana tester inte finns och man vill v\u00e4lja n\u00e5got snabbare?<\/p>\n

    Vi modellerar ett s\u00e5dant alternativ (det \u00e4r sv\u00e5rt att f\u00f6rest\u00e4lla sig att en medelniv\u00e5+ utvecklare lever i vakuum, och vid valet \u00e4nnu inte har best\u00e4mt vilket produkt de vill prova f\u00f6rst \u2014 d\u00e4rf\u00f6r \u00e4r de f\u00f6ljande resonemangen mer teoretiska\/filosofiska\/om en junior).<\/p>\n

    N\u00e4r vi har fastst\u00e4llt kraven b\u00f6rjar vi v\u00e4lja en f\u00e4rdig l\u00f6sning. Varf\u00f6r \u00e5teruppfinna hjulet: vi g\u00e5r och plockar en f\u00e4rdig cachel\u00f6sning.<\/p>\n

    Om du just har b\u00f6rjat och kommer att googla, s\u00e5 \u00e4r ordningen ungef\u00e4r densamma, men \u00f6verlag kommer riktlinjerna att vara som f\u00f6ljer. F\u00f6rst kommer du att st\u00f6ta p\u00e5 Redis, som \u00e4r allm\u00e4nt k\u00e4nt. Sedan f\u00e5r du veta att det finns EhCache, som \u00e4r det \u00e4ldsta och mest bepr\u00f6vade systemet. Sedan f\u00f6ljer Tarantool \u2014 en inhemsk utveckling med unika l\u00f6sningar. Och \u00e4ven Ignite, eftersom det nu \u00e4r p\u00e5 uppg\u00e5ng och st\u00f6ds av SberTech. Slutligen kommer Hazelcast, som ofta dyker upp i f\u00f6retagsv\u00e4rlden bland stora f\u00f6retag.<\/p>\n

    Denna lista \u00e4r inte utt\u00f6mmande, det finns m\u00e5nga system. Men vi kommer att fokusera p\u00e5 ett enda. Vi tar de utvalda 5 systemen till en \"sk\u00f6nhetst\u00e4vling\" och g\u00f6r en urval. Vem blir vinnaren?<\/p>\n

    Redis<\/h3>\n

    \nL\u00e5t oss l\u00e4sa vad som st\u00e5r p\u00e5 den officiella hemsidan.
    \n    Redis<\/a><\/noindex> \u2014 ett opensource-projekt. Erbjuder ett in-memory datalagringssystem, m\u00f6jlighet till on-disk lagring, automatisk partitionering, h\u00f6g tillg\u00e4nglighet och \u00e5terst\u00e4llning efter n\u00e4tverksavbrott.<\/p>\n

    Det verkar bra, man kan ta det och koppla in \u2014 allt vad som beh\u00f6vs g\u00f6rs. Men l\u00e5t oss titta p\u00e5 de andra kandidaterna av ren nyfikenhet.<\/p>\n

    EhCache<\/h3>\n

    \nEhCache<\/a><\/noindex> \u2014 \"den mest anv\u00e4nda cachen f\u00f6r Java\" (\u00f6vers\u00e4ttning av slogan fr\u00e5n den officiella hemsidan). \u00c4ven detta \u00e4r opensource. H\u00e4r f\u00f6rst\u00e5r vi att Redis inte \u00e4r f\u00f6r Java, utan allm\u00e4nt, och f\u00f6r att interagera med det beh\u00f6vs en wrapper. EhCache kommer att vara bekv\u00e4mare. Vad lovar systemet mer? Tillf\u00f6rlitlighet, bepr\u00f6vadhet, fullst\u00e4ndighet. Och det \u00e4r den mest spridda. Och cachen hanterar terabyte av data.<\/p>\n

    Redis \u00e4r gl\u00f6mt, jag \u00e4r redo att v\u00e4lja EhCache.<\/p>\n

    Men min patriotism driver mig att kolla vad som \u00e4r bra med Tarantool.<\/p>\n

    Tarantool<\/h3>\n

    \nTarantool<\/a><\/noindex> \u2014 m\u00f6ter beteckningen \"Plattform f\u00f6r realtidsintegration av data\". Det l\u00e5ter mycket komplicerat, s\u00e5 vi l\u00e4ser sidan noggrant och hittar det stora p\u00e5st\u00e5endet: \"Cachar 100% av data i RAM\". Detta b\u00f6r v\u00e4cka fr\u00e5gor \u2013 eftersom datan kan vara betydligt mer \u00e4n minnet. F\u00f6rklaringen \u00e4r att h\u00e4r syftas det p\u00e5 att f\u00f6r att skriva data till disken fr\u00e5n minnet, anv\u00e4nder Tarantool inte serialization. Ist\u00e4llet anv\u00e4nder den l\u00e5gniv\u00e5funktioner i systemet, d\u00e4r minnet helt enkelt mappas p\u00e5 filsystemet med mycket bra I\/O-prestanda. S\u00e5, det har gjorts p\u00e5 ett fantastiskt och smart s\u00e4tt.<\/p>\n

    L\u00e5t oss titta p\u00e5 implementationerna: Mail.ru f\u00f6retagsbackbone, Avito, Beeline, Megafon, Alfa-Bank, Gazprom\u2026<\/p>\n

    Om det fortfarande finns n\u00e5gra tvivel kring Tarantool, s\u00e5 \u00f6vertygar mig fallet med Mastercard. Jag v\u00e4ljer Tarantool.<\/p>\n

    Men \u00e4nd\u00e5\u2026<\/p>\n

    Ignite<\/h3>\n

    \n\u2026 finns det mer Ignite<\/a><\/noindex>, som anges som \"in-memory ber\u00e4kningsplattform... in-memory hastigheter p\u00e5 petabyte data\". H\u00e4r finns ocks\u00e5 m\u00e5nga f\u00f6rdelar: distribuerad in-memory cache, den snabbaste key-value lagring och cache, horisontell skalbarhet, h\u00f6g tillg\u00e4nglighet, strikt integritet. S\u00e5 det visar sig att den snabbaste \u00e4r Ignite.<\/p>\n

    Implementationer: Sberbank, American Airlines, Yahoo! Japan. Och sedan f\u00e5r jag ocks\u00e5 veta att Ignite inte bara har implementerats i Sberbank, utan att SberTech-teamets medlemmar skickas till Ignite-teamet f\u00f6r att f\u00f6rb\u00e4ttra produkten. Det h\u00e4r \u00f6vertygar mig helt och jag \u00e4r redo att v\u00e4lja Ignite.<\/p>\n

    Helt oklart varf\u00f6r, jag ser p\u00e5 den femte punkten.<\/p>\n

    Hazelcast<\/h3>\n

    \nJag g\u00e5r in p\u00e5 webbplatsen Hazelcast<\/a><\/noindex>, l\u00e4ser. Och det visar sig att den snabbaste l\u00f6sningen f\u00f6r distribuerad caching \u00e4r Hazelcast. Det \u00e4r m\u00e5nga g\u00e5nger snabbare \u00e4n alla andra l\u00f6sningar och \u00e4r verkligen ledande inom in-memory data grid. I ljuset av detta, att v\u00e4lja n\u00e5got annat \u2013 att inte respektera sig sj\u00e4lv. Dessutom anv\u00e4nder den redundant datalagring f\u00f6r att s\u00e4kerst\u00e4lla att klustret forts\u00e4tter att fungera utan datal\u00e4ckage.<\/p>\n

    Det \u00e4r klart, jag \u00e4r redo att v\u00e4lja Hazelcast.<\/p>\n

    J\u00e4mf\u00f6relse<\/h2>\n

    \nMen om vi ser p\u00e5 det, s\u00e5 \u00e4r alla fem kandidater s\u00e5 beskrivna att var och en av dem \u00e4r den b\u00e4sta. Hur v\u00e4ljer man? Vi kan titta p\u00e5 vilken av dem som \u00e4r mest popul\u00e4r, leta efter j\u00e4mf\u00f6relser, och huvudv\u00e4rken f\u00f6rsvinner.<\/p>\n

    Vi hittar en s\u00e5dan \u00f6versyn<\/a><\/noindex>, vi v\u00e4ljer v\u00e5ra 5 system.<\/p>\n

    \"S\u00e5
    \n
    \nH\u00e4r \u00e4r de sorterade: h\u00f6gst upp Redis, tv\u00e5a \u00e4r Hazelcast, Tarantool och Ignite vinner popularitet, EhCache f\u00f6rblir som det var. <\/p>\n

    Men l\u00e5t oss titta p\u00e5 ber\u00e4kningsmetoden<\/a><\/noindex>: l\u00e4nkar till webbplatser, allm\u00e4n intresse f\u00f6r systemet, jobbannonser \u2013 fantastiskt! S\u00e5, n\u00e4r mitt system g\u00e5r ner, kommer jag att s\u00e4ga: \u00abNej, den \u00e4r ju p\u00e5litlig! H\u00e4r \u00e4r m\u00e5nga jobb erbjudanden...\u00bb. En s\u00e5dan enkel j\u00e4mf\u00f6relse fungerar inte.<\/p>\n

    Dessa system \u00e4r inte bara cachingsystem. De har mycket mer funktionalitet, inklusive \u2013 n\u00e4r inte data \u00f6verf\u00f6rs till klienten f\u00f6r bearbetning, utan tv\u00e4rtom: koden som m\u00e5ste utf\u00f6ras p\u00e5 data flyttas till servern, d\u00e4r den k\u00f6rs och resultatet returneras. Och som ett separat cachingsystem \u00f6verv\u00e4gs de inte s\u00e5 ofta.<\/p>\n

    Okej, vi ger inte upp, vi ska hitta en direkt j\u00e4mf\u00f6relse av systemen. Vi tar de tv\u00e5 b\u00e4sta alternativen \u2013 Redis och Hazelcast. Vi \u00e4r intresserade av hastighet, och vi ska j\u00e4mf\u00f6ra dem efter detta kriterium.<\/p>\n

    Hz vs Redis<\/h3>\n

    \nVi hittar n\u00e5got s\u00e5dant j\u00e4mf\u00f6relsen<\/a><\/noindex>:
    \n\"S\u00e5
    \n
    \nBl\u00e5tt \u00e4r Redis, r\u00f6tt \u00e4r Hazelcast. Hazelcast vinner \u00f6verallt, och detta har en f\u00f6rklaring: det \u00e4r fl\u00f6desbaserat, h\u00f6goptimerat, varje tr\u00e5d arbetar med sin partition, s\u00e5 det finns inga l\u00e5s. Redis \u00e4r fl\u00f6desbaserat, fr\u00e5n moderna flerprocessorer tar det inte n\u00e5gra vinster. Hazelcast har asynkron I\/O, hos Redis-Jedis \u00e4r socketarna blockerande. I slut\u00e4ndan anv\u00e4nder Hazelcast ett bin\u00e4rt protokoll, medan Redis \u00e4r textorienterat, vilket inneb\u00e4r att det \u00e4r ineffektivt.<\/p>\n

    F\u00f6r s\u00e4kerhets skull ska vi v\u00e4nda oss till en annan k\u00e4lla f\u00f6r j\u00e4mf\u00f6relse. Vad kommer den att visa oss?<\/p>\n

    Redis vs Hz<\/h3>\n

    \n\u00c4nnu en j\u00e4mf\u00f6relsen<\/a><\/noindex>:
    \n\"S\u00e5
    \n
    \nH\u00e4r \u00e4r det tv\u00e4rtom, r\u00f6tt \u00e4r Redis. Det inneb\u00e4r att Redis prestanda vinner \u00f6ver Hazelcast. I den f\u00f6rsta j\u00e4mf\u00f6relsen vann Hazelcast, i den andra \u2013 Redis.     H\u00e4r \u00e4r<\/a><\/noindex> det mycket noggrant f\u00f6rklarat varf\u00f6r Hazelcast vann i den f\u00f6reg\u00e5ende j\u00e4mf\u00f6relsen.<\/p>\n

    Det visar sig att resultatet fr\u00e5n den f\u00f6rsta j\u00e4mf\u00f6relsen faktiskt var manipulerat: Redis togs i sin grundl\u00e4ggande version, medan Hazelcast anpassades f\u00f6r testscenariot. S\u00e5 det visar sig: f\u00f6r det f\u00f6rsta, ingen kan man lita p\u00e5, f\u00f6r det andra, n\u00e4r vi \u00e4nd\u00e5 v\u00e4ljer ett system, m\u00e5ste vi ocks\u00e5 konfigurera det korrekt. Dessa inst\u00e4llningar inkluderar dussintals, n\u00e4stan hundra parametrar.<\/p>\n

    Skakar flaskan<\/h2>\n

    \nOch hela processen som vi just har genomf\u00f6rt kan jag f\u00f6rklara med metaforen \u00abSkakar flaskan\u00bb. Det vill s\u00e4ga, just nu beh\u00f6ver man inte programmera, det viktigaste \u00e4r att kunna l\u00e4sa stackoverflow. Och jag har en professionell person i mitt team som just arbetar s\u00e5 i kritiska stunder.<\/p>\n

    Vad g\u00f6r han? Han ser en trasig grej, ser stack trace, tar n\u00e5gra ord fr\u00e5n den (vilka exakt \u2014 det \u00e4r hans expertis i programmet), s\u00f6ker p\u00e5 Google, hittar stackoverflow bland svaren. Utan att l\u00e4sa, utan att t\u00e4nka, bland svaren p\u00e5 fr\u00e5gan \u2014 v\u00e4ljer han n\u00e5got som liknar f\u00f6rslaget \"g\u00f6r det h\u00e4r och det h\u00e4r\" (att v\u00e4lja ett s\u00e5dant svar \u2014 det \u00e4r hans talang, f\u00f6r det \u00e4r inte alltid den svar som f\u00e5tt flest gilla). Han till\u00e4mpar det, tittar: om n\u00e5got har f\u00f6r\u00e4ndrats, bra. Om inget har f\u00f6r\u00e4ndrats \u2014 vi backar. Och vi upprepar k\u00f6rning-kontroll-s\u00f6kning. P\u00e5 det intuitiva s\u00e4ttet lyckas han f\u00e5 koden att fungera efter ett tag. Han vet inte varf\u00f6r, han vet inte vad han gjorde, han kan inte f\u00f6rklara. Men! Den fungerar. Och \"branden \u00e4r sl\u00e4ckt\". Nu g\u00e5r vi igenom vad vi har gjort. N\u00e4r programmet fungerar \u2014 \u00e4r det mycket l\u00e4ttare. Och sparar betydligt tid.<\/p>\n

    Det h\u00e4r s\u00e4ttet f\u00f6rklaras mycket bra med ett exempel.<\/p>\n

    Det var en g\u00e5ng mycket popul\u00e4rt att bygga en segelb\u00e5t i en flaska. Segelb\u00e5ten \u00e4r stor och sk\u00f6r, medan flaskans hals \u00e4r v\u00e4ldigt smal, man kan inte pressa in den. Hur ska man bygga den?<\/p>\n

    \"S\u00e5
    \n
    \nDet finns en metod som \u00e4r v\u00e4ldigt snabb och effektiv.<\/p>\n

    B\u00e5ten best\u00e5r av massor av sm\u00e5delar: pinnar, sn\u00f6ren, segel, lim. Allt detta l\u00e4gger vi i flaskan.
    \nVi tar flaskan med b\u00e5da h\u00e4nderna och b\u00f6rjar skaka. Vi skakar den och skakar. Och oftast blir det en total katastrof, s\u00e5klart. Men ibland. Ibland blir det en b\u00e5t! N\u00e4rmare best\u00e4mt, n\u00e5got som liknar en b\u00e5t.<\/p>\n

    Vi visar detta n\u00e5got f\u00f6r n\u00e5gon: \"Sergej, ser du!?\". Och faktiskt, p\u00e5 avst\u00e5nd \u2014 ser det ut som en b\u00e5t. Men l\u00e4ngre \u00e4n s\u00e5 kan man inte g\u00e5.<\/p>\n

    Det finns ocks\u00e5 ett annat s\u00e4tt. Mer avancerade killar, s\u00e5dana hackare, anv\u00e4nder det.<\/p>\n

    Jag gav en s\u00e5dan kille en uppgift, han gjorde allt och gick. Och man ser \u2013 det ser ut som gjort. Men efter ett tag, n\u00e4r man beh\u00f6ver justera koden \u2014 d\u00e5 b\u00f6rjar det h\u00e4nda konstiga saker p\u00e5 grund av honom\u2026 Tur att han redan har lyckats springa l\u00e5ngt bort. Det \u00e4r s\u00e5dana killar som, p\u00e5 exempel med flaskan, g\u00f6r s\u00e5: ser ni, d\u00e4r botten \u00e4r \u2013 glaset b\u00f6jer sig. Och det \u00e4r inte helt klart, \u00e4r det genomskinligt eller inte. D\u00e5 \"hackarna\" s\u00e5gar av botten, s\u00e4tter in b\u00e5ten, s\u00e4tter sedan tillbaka botten med lim, och s\u00e5 ser det ut som det alltid ska vara.<\/p>\n

    Ur ett uppgiftsformuleringsperspektiv verkar allt r\u00e4tt. Men n\u00e4r det g\u00e4ller b\u00e5tar: varf\u00f6r i hela v\u00e4rlden skulle man ens g\u00f6ra denna b\u00e5t, vem beh\u00f6ver den ens? Den har ingen funktionalitet. Vanligtvis \u00e4r s\u00e5dana b\u00e5tar g\u00e5vor till mycket h\u00f6gst\u00e5ende personer, som st\u00e4ller dem p\u00e5 en hyllan ovanf\u00f6r sig, som en symbol, som ett tecken. Och om en s\u00e5dan person, en ledare f\u00f6r ett stort f\u00f6retag eller en h\u00f6g tj\u00e4nsteman, har s\u00e5dan v\u00e4rdel\u00f6shet som flagga, vars hals \u00e4r avskuren? Det \u00e4r b\u00e4ttre att han aldrig f\u00e5r veta det. S\u00e5 hur g\u00f6r man dessa b\u00e5tar som kan ges till viktiga personer?<\/p>\n

    Det enda st\u00e4llet, det enda viktiga, som man verkligen inte kan \u00e4ndra p\u00e5, \u00e4r skrovet. Och skrovet p\u00e5 b\u00e5ten g\u00e5r just genom halsen. Men b\u00e5ten s\u00e4tts ihop utanf\u00f6r flaskan. Men det \u00e4r inte bara att s\u00e4tta ihop en b\u00e5t, det \u00e4r ett riktigt hantverk. I delarna l\u00e4ggs speciella spakar till, som g\u00f6r det m\u00f6jligt att senare lyfta dem. Till exempel, seglen viks ihop, f\u00f6rs varsamt in, och sedan, med pincett, lyfts de mycket noggrant och exakt. Resultatet blir ett konstverk som man kan ge bort med gott samvete och stolthet.<\/p>\n

    Och om vi vill att projektet ska bli framg\u00e5ngsrikt \u2013 m\u00e5ste det finnas minst en juvelerare i teamet. Den som bryr sig om produktens kvalitet och tar h\u00e4nsyn till alla aspekter, utan att offra n\u00e5got, inte ens i stressiga stunder n\u00e4r omst\u00e4ndigheterna kr\u00e4ver snabba \u00e5tg\u00e4rder p\u00e5 bekostnad av det viktiga. Alla framg\u00e5ngsrika projekt som \u00e4r h\u00e5llbara och har st\u00e5tt tidens prov bygger p\u00e5 denna princip. De har n\u00e5got v\u00e4ldigt exakt och unikt, n\u00e5got som utnyttjar alla tillg\u00e4ngliga m\u00f6jligheter. I exemplet med b\u00e5ten i en flaska beskrivs hur skrovet p\u00e5 b\u00e5ten passerar genom halsen.<\/p>\n

    \u00c5terkommande till uppgiften att v\u00e4lja v\u00e5r cache-server, hur skulle denna metod kunna till\u00e4mpas? Jag f\u00f6resl\u00e5r ett s\u00e4tt att g\u00f6ra urval fr\u00e5n alla system som finns \u2013 att inte skaka flaskan, inte v\u00e4lja, utan att se vad som egentligen finns d\u00e4r som man borde t\u00e4nka p\u00e5 n\u00e4r man v\u00e4ljer system.<\/p>\n

    Var ska man leta efter flaskhalsar<\/h2>\n

    \nVi f\u00f6rs\u00f6ker att inte skaka flaskan, inte g\u00e5 igenom allt en och en, men vi ser vilka uppgifter som dyker upp om vi helt pl\u00f6tsligt, f\u00f6r v\u00e5r uppgift - att designa ett s\u00e5dant system p\u00e5 egen hand. Vi kommer givetvis inte att bygga en cykel, utan vi ska anv\u00e4nda detta schema f\u00f6r att orientera oss om vilka punkter vi ska uppm\u00e4rksamma i produktbeskrivningarna. Vi skissar p\u00e5 ett s\u00e5dant schema.<\/p>\n

    \"S\u00e5
    \n
    \nOm systemet \u00e4r distribuerat, inneb\u00e4r det att vi kommer att ha flera servrar (6). L\u00e5t oss anta att det \u00e4r fyra (det \u00e4r bekv\u00e4mt att placera i bilden, men det kan f\u00f6rst\u00e5s vara hur m\u00e5nga som helst). Om servrarna \u00e4r p\u00e5 olika noder, inneb\u00e4r det att det k\u00f6rs viss kod p\u00e5 dem alla, som ansvarar f\u00f6r att dessa noder bildar ett kluster och vid avbrott - ansluter, k\u00e4nner igen varandra.<\/p>\n

    Vi beh\u00f6ver ocks\u00e5 koden-logik (2), som handlar om cachelagring. Denna kod interagerar med klienterna via ett visst API. Klientkoden (1) kan antingen vara inom samma JVM eller kontakta den \u00f6ver n\u00e4tverket. Logiken som \u00e4r implementerad internt handlar om att fatta beslut om vilka objekt som ska beh\u00e5llas i cachen och vilka som ska sl\u00e4ngas. F\u00f6r att lagra cachen anv\u00e4nder vi minne (3), men om det beh\u00f6vs kan vi ocks\u00e5 spara delar av data p\u00e5 disken (4).<\/p>\n

    Vi ska se var belastningen kommer att uppst\u00e5. Faktiskt kommer varje pil och varje nod att belastas. F\u00f6rst och fr\u00e4mst, mellan klientkoden och API:et, om det \u00e4r en n\u00e4tverksinteraktion, kan nedg\u00e5ngen vara ganska m\u00e4rkbar. F\u00f6r det andra, inom sj\u00e4lva API:et - om vi \u00f6verdriver med komplicerad logik kan vi st\u00f6ta p\u00e5 CPU-problem. Det skulle vara bra om logiken inte beh\u00f6ver hantera minnet i on\u00f6dan. Och kvarst\u00e5r \u00e4r interaktionen med filsystemet - i det vanliga fallet handlar det om att serialisera \/ \u00e5terst\u00e4lla och skriva \/ l\u00e4sa.<\/p>\n

    Vidare interaktion med klustret. Troligtvis kommer den att finnas i samma system, men den kan ocks\u00e5 vara separat. H\u00e4r m\u00e5ste man ocks\u00e5 ta h\u00e4nsyn till data\u00f6verf\u00f6ringen till det, hastigheten f\u00f6r dataserialisering och interaktionen mellan klustret.<\/p>\n

    Nu, \u00e5 ena sidan - kan vi f\u00f6rest\u00e4lla oss \"vilka kugghjul som kommer att snurra\" i cachen-systemet vid behandling av f\u00f6rfr\u00e5gningar fr\u00e5n v\u00e5r kod, och \u00e5 andra sidan - kan vi uppskatta hur m\u00e5nga och vilka f\u00f6rfr\u00e5gningar v\u00e5r kod kommer att generera till detta system. Det \u00e4r tillr\u00e4ckligt f\u00f6r att g\u00f6ra ett mer eller mindre rationellt val - att v\u00e4lja ett system som passar v\u00e5r anv\u00e4ndning.<\/p>\n

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

    L\u00e5t oss se hur vi kan till\u00e4mpa en s\u00e5dan uppdelning p\u00e5 v\u00e5r lista. Till exempel, Hazelcast.<\/p>\n

    F\u00f6r att lagra\/h\u00e4mta data fr\u00e5n Hazelcast, interagerar klientkoden (1) med API:et. Hz till\u00e5ter att k\u00f6r servern som inb\u00e4ddad, och i det fallet \u00e4r interaktionen med API:et ett metodanrop inom JVM, vilket kan anses vara kostnadsfritt.<\/p>\n

    F\u00f6r att logiken ska fungera i (2), f\u00f6rlitar sig Hz p\u00e5 en hash av byte-arrayen av den serialiserade nyckeln \u2013 det vill s\u00e4ga, serialiseringen av nyckeln kommer att ske oavsett. Detta \u00e4r en oundviklig overhead f\u00f6r Hz.
    \nEvictionsstrategierna \u00e4r v\u00e4l implementerade, men f\u00f6r speciella fall kan egna kopplas in. F\u00f6r denna del kan man vara lugn.<\/p>\n

    Lagringen (4) kan kopplas in. Utm\u00e4rkt. Interaktionen (5) f\u00f6r inb\u00e4ddad kan ses som omedelbar. Datautbyte mellan noder i klustret (6) \u2013 ja, det finns. Detta bidrar till motst\u00e5ndskraftighet p\u00e5 bekostnad av hastighet. Kostnaden kan s\u00e4nkas genom Hz-funktionen Near-cache \u2013 data som erh\u00e5llits fr\u00e5n andra noder i klustret kommer att cachas.<\/p>\n

    Vad kan man g\u00f6ra i s\u00e5dana omst\u00e4ndigheter f\u00f6r att \u00f6ka hastigheten?<\/p>\n

    Till exempel, f\u00f6r att undvika serialisering av nyckeln i (2) \u2013 kan man l\u00e4gga till ytterligare en cache ovanp\u00e5 Hazelcast, f\u00f6r de hetaste data. P\u00e5 Sportmaster valde man f\u00f6r detta \u00e4ndam\u00e5l Caffeine.<\/p>\n

    F\u00f6r justeringar p\u00e5 niv\u00e5 (6), erbjuder Hz tv\u00e5 typer av lagring: IMap och ReplicatedMap.
    \n\"S\u00e5
    \n
    \nDet \u00e4r v\u00e4rt att n\u00e4mna hur Hazelcast kom in i Sportmasters teknikstack.<\/p>\n

    \u00c5r 2012, n\u00e4r vi arbetade med den f\u00f6rsta piloten av framtida webbplatsen, var det faktiskt Hazelcast som visade sig vara den f\u00f6rsta l\u00e4nken s\u00f6kmotorn gav. Bekantskapen inleddes 'fr\u00e5n f\u00f6rsta taget' \u2014 vi blev imponerade av att bara tv\u00e5 timmar efter att vi kopplat in Hz i systemet \u2014 fungerade det. Och fungerade bra. Fram till slutet av dagen skrev vi n\u00e5gra tester, blev glada. Och det lilla lagret av energi r\u00e4ckte f\u00f6r att \u00f6vervinna de \u00f6verraskningar som Hz gav \u00f6ver tid. Nu har Sportmasters team inga sk\u00e4l att avst\u00e5 fr\u00e5n Hazelcast.<\/p>\n

    Men s\u00e5dana argument som 'f\u00f6rsta l\u00e4nken i s\u00f6kmotorn' och 'snabbt satte ihop HelloWorld' \u00e4r sj\u00e4lvklart undantag och egenskaper hos det \u00f6gonblick d\u00e5 valet gjordes. De verkliga pr\u00f6vningarna f\u00f6r det valda systemet b\u00f6rjar n\u00e4r man g\u00e5r produktionsv\u00e4gen, och det \u00e4r just p\u00e5 det h\u00e4r steget man b\u00f6r fokusera vid valet av vilket system som helst, inklusive cache. I v\u00e5rt fall kan man s\u00e4ga att vi valde Hazelcast av en slump, men det visade sig senare att vi valde r\u00e4tt.<\/p>\n

    F\u00f6r produktion \u00e4r mycket viktigare: \u00f6vervakning, hantering av fel p\u00e5 enskilda noder, datareplication, kostnad f\u00f6r skalning. Det vill s\u00e4ga, man b\u00f6r uppm\u00e4rksamma de utmaningar som kan uppst\u00e5 just under systemets drift \u2013 n\u00e4r belastningen tio g\u00e5nger \u00f6verstiger den planerade, n\u00e4r vi av misstag laddar upp fel saker p\u00e5 fel st\u00e4llen, n\u00e4r det beh\u00f6vs en ny version av koden rullas ut, byta data och g\u00f6ra detta osynligt f\u00f6r kunderna.<\/p>\n

    F\u00f6r alla dessa krav passar Hazelcast definitivt.<\/p>\n

    Forts\u00e4ttning f\u00f6ljer<\/h2>\n

    \nMen Hazelcast \u00e4r ingen universall\u00f6sning. \u00c5r 2017 valde vi Hazelcast f\u00f6r cache i adminpanelen, helt enkelt baserat p\u00e5 tidigare positiva erfarenheter. Detta spelade en avg\u00f6rande roll i ett v\u00e4ldigt intrikat sk\u00e4mt, vilket ledde till att vi hamnade i en sv\u00e5r situation och \"hj\u00e4lted\u00e5digt\" k\u00e4mpade oss ur den p\u00e5 60 dagar. Men mer om detta i n\u00e4sta del.<\/p>\n

    Och tills dess\u2026 Happy New Code!
    \n
    K\u00e4lla:     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\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\udd47Hur vi p\u00e5 Sportmaster valde ett cache-system. Del 1 | ProHoster","description":"Hej! Jag heter Aleksej Pjankov och jag \u00e4r utvecklare p\u00e5 f\u00f6retaget Sportmaster.","canonical_url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sv_SE","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\/sv\/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\/sv\/wp-json\/wp\/v2\/posts\/73949","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/comments?post=73949"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/73949\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media\/73950"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media?parent=73949"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/categories?post=73949"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/tags?post=73949"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}