Ahoj! Volám sa Alexey Pyankov, som vývojár v spoločnosti Sportmaster. V tom Rozprával som, ako sa v roku 2012 začalo pracovať na webe Sportmaster, aké iniciatívy sa nám podarilo „pretlačiť“ a naopak, aké rake sme vyzbierali.
Dnes sa chcem podeliť o myšlienky, ktoré sledujú inú tému – výber vyrovnávacieho systému pre java backend na paneli správcu stránky. Táto zápletka má pre mňa zvláštny význam – hoci sa dej odvíjal len 2 mesiace, počas týchto 60 dní sme pracovali 12-16 hodín a bez jediného dňa voľna. Nikdy som si ani nepredstavoval, že je možné tak tvrdo pracovať.
Preto som text rozdelil na 2 časti, aby som ho nenačítal úplne. Naopak, prvá časť bude veľmi odľahčená – príprava, úvod, nejaké úvahy o tom, čo je to kešovanie. Ak ste už skúsený vývojár alebo ste pracovali s cache, po technickej stránke s najväčšou pravdepodobnosťou nebude v tomto článku nič nové. Ale juniorovi môže taká malá recenzia napovedať, ktorým smerom sa má pozerať, ak sa ocitne na takejto križovatke.
Pri uvedení novej verzie webu Sportmaster do produkcie sa dáta dostávali mierne povedané nie príliš pohodlným spôsobom. Základom boli tabuľky pripravené pre predchádzajúcu verziu stránky (Bitrix), ktoré bolo treba stiahnuť do ETL, priniesť do novej podoby a obohatiť o rôzne drobnosti z desiatky ďalších systémov. Aby sa na stránke objavil nový obrázok alebo popis produktu, museli ste počkať do druhého dňa – aktualizácie len v noci, raz denne.
Najprv bolo z prvých týždňov spustenia výroby toľko starostí, že takéto nepríjemnosti pre obsahových manažérov boli maličkosti. Akonáhle sa však všetko ustálilo, vývoj projektu pokračoval - o niekoľko mesiacov neskôr, začiatkom roka 2015, sme začali aktívne rozvíjať admin panel. V rokoch 2015 a 2016 ide všetko ako má, vydávame pravidelne, admin panel pokrýva stále viac a viac z prípravy dát a pripravujeme sa na to, že čoskoro bude náš tím poverený tým najdôležitejším a najkomplexnejším - produktom okruhu (úplná príprava a údržba údajov o všetkých produktoch). No v lete 2017, tesne pred spustením komoditného okruhu, sa projekt ocitne vo veľmi zložitej situácii – práve pre problémy s cachovaním. O tejto epizóde chcem hovoriť v druhej časti tejto dvojdielnej publikácie.
Ale v tomto príspevku začnem z diaľky, predstavím niekoľko myšlienok - nápadov o kešovaní, ktoré by bolo dobrým krokom na prelistovanie pred veľkým projektom.
Keď sa vyskytne úloha ukladania do vyrovnávacej pamäte
Úloha ukladania do vyrovnávacej pamäte sa len tak neobjaví. Sme vývojári, píšeme softvérový produkt a chceme, aby bol žiadaný. Ak je produkt žiadaný a úspešný, používatelia prídu. A prichádzajú ďalší a ďalší. A potom je tu veľa používateľov a potom je produkt veľmi zaťažený.
V prvých fázach nemyslíme na optimalizáciu a výkon kódu. Hlavná je funkčnosť, rýchle uvedenie pilota a testovanie hypotéz. A ak sa záťaž zvýši, žehličku napumpujeme. Zvyšujeme to dvakrát alebo trikrát, päťkrát, možno 10-krát. Niekde tu – financie to už nedovolia. Koľkokrát sa zvýši počet používateľov? Nebude to ako 2-5-10, ale v prípade úspechu to bude od 100-1000 do 100 tisíc krát. To znamená, že skôr či neskôr budete musieť vykonať optimalizáciu.
Povedzme, že nejaká časť kódu (nazvime túto časť funkcia) trvá neslušne dlho a my chceme skrátiť čas vykonávania. Funkciou môže byť prístup k databáze, alebo to môže byť vykonanie nejakej zložitej logiky – hlavná vec je, že jej vykonanie trvá dlho. O koľko môžete skrátiť čas vykonania? V limite ho môžete znížiť na nulu, ďalej nie. Ako môžete skrátiť čas vykonania na nulu? Odpoveď: úplne odstráňte popravu. Namiesto toho okamžite vráťte výsledok. Ako zistíte výsledok? Odpoveď: buď si to vypočítajte, alebo sa niekam pozrite. Výpočet trvá dlho. A špehovať je napríklad zapamätať si výsledok, ktorý funkcia vyprodukovala naposledy pri volaní s rovnakými parametrami.
To znamená, že implementácia funkcie nie je pre nás dôležitá. Stačí vedieť, od akých parametrov závisí výsledok. Potom, ak sú hodnoty parametrov reprezentované vo forme objektu, ktorý možno použiť ako kľúč v nejakom úložisku, výsledok výpočtu možno uložiť a prečítať pri ďalšom prístupe. Ak je tento zápis a čítanie výsledku rýchlejšie ako vykonanie funkcie, máme z hľadiska rýchlosti zisk. Výška zisku môže dosiahnuť 100, 1000 a 100 tisíc krát (10^5 je skôr výnimkou, ale v prípade dosť zaostávajúceho základu je to celkom možné).
Základné požiadavky na systém vyrovnávacej pamäte
Prvá vec, ktorá sa môže stať požiadavkou pre systém vyrovnávacej pamäte, je vysoká rýchlosť čítania a v o niečo menšej miere rýchlosť zápisu. To je pravda, ale len dovtedy, kým systém nezavedieme do výroby.
Zahrajme si tento prípad.
Povedzme, že sme aktuálne zaťaženie zabezpečili hardvérom a teraz postupne zavádzame ukladanie do vyrovnávacej pamäte. Počet používateľov trochu rastie, záťaž rastie - pridávame trochu vyrovnávacích pamätí, sem-tam to zaskrutkujeme. Toto pokračuje nejaký čas a ťažké funkcie sa už prakticky nevyvolávajú - celé hlavné zaťaženie padá na vyrovnávaciu pamäť. Počet používateľov sa počas tejto doby N-krát zvýšil.
A ak by počiatočná zásoba hardvéru mohla byť 2- až 5-násobná, potom pomocou vyrovnávacej pamäte by sme mohli zvýšiť výkon o faktor 10 alebo v dobrom prípade o faktor 100, na niektorých miestach možno o faktor 1000. To znamená na rovnakom hardvéri – spracovávame 100-krát viac požiadaviek. Skvelé, zaslúžiš si perník!
Ale teraz, v jednom peknom momente, náhodou systém spadol a vyrovnávacia pamäť sa zrútila. Nič zvláštne – vyrovnávacia pamäť bola napokon vybraná na základe požiadavky „vysoká rýchlosť čítania a zápisu, na zvyšku nezáleží“.
V porovnaní s počiatočným zaťažením bola naša železná rezerva 2-5 krát a záťaž sa počas tejto doby zvýšila 10-100 krát. Pomocou vyrovnávacej pamäte sme eliminovali volania ťažkých funkcií a preto všetko fungovalo. A teraz, bez vyrovnávacej pamäte, koľkokrát sa náš systém spomalí? Čo sa s nami stane? Systém padne.
Aj keď sa naša vyrovnávacia pamäť nezrútila, ale bola vymazaná iba na chvíľu, bude potrebné ju zahriať, čo bude chvíľu trvať. A počas tejto doby bude hlavná záťaž padať na funkčnosť.
Záver: vysoko zaťažené produkčné projekty vyžadujú systém vyrovnávacej pamäte nielen na to, aby mal vysokú rýchlosť čítania a zápisu, ale aj na zaistenie bezpečnosti údajov a odolnosti voči zlyhaniam.
Voľba múky
V projekte s admin panelom bola voľba takto: najprv sme nainštalovali Hazelcast, pretože Tento produkt sme už poznali zo skúseností z hlavnej stránky. Tu sa však táto voľba ukázala ako neúspešná - pod naším profilom zaťaženia je Hazelcast nielen pomalý, ale strašne pomalý. A v tom čase sme už mali zapísaný dátum vydania.
Spoiler: ako presne sa vyvinuli okolnosti, že sme zmeškali takú veľkú vec a skončili sme akútnou a napätou situáciou - poviem vám v druhej časti - a ako sme dopadli a ako sme sa dostali von. Ale teraz - poviem len, že to bol veľký stres, a "myslieť - nejako nemôžem myslieť, trasieme fľašou." „Zatriasť fľašou“ je tiež spoiler, o tom neskôr.
Čo sme urobili:
- Vytvárame zoznam všetkých systémov, ktoré navrhujú Google a StackOverflow. Niečo cez 30
- Píšeme testy so záťažou typickou pre výrobu. Aby sme to dosiahli, zaznamenávali sme dáta, ktoré prechádzajú systémom v produkčnom prostredí – akýsi sniffer dát nie na sieti, ale vo vnútri systému. Presne tieto údaje boli použité v testoch.
- S celým tímom si každý vyberie ďalší systém zo zoznamu, nakonfiguruje ho a spustí testy. Neprejde testom, neunesie záťaž – vyhodíme ju a ideme na ďalšiu v poradí.
- Na 17. systéme sa ukázalo, že všetko je beznádejné. Prestaňte triasť fľašou, je čas myslieť vážne.
Toto je však možnosť, keď si potrebujete vybrať systém, ktorý „prekoná rýchlosť“ vo vopred pripravených testoch. Čo ak takéto testy ešte nie sú a chcete si rýchlo vybrať?
Poďme si túto možnosť nasimulovať (ťažko si predstaviť, že middle+ developer žije vo vzduchoprázdne a v čase selekcie ešte nemá formalizovanú preferenciu, ktorý produkt vyskúšať ako prvý – preto ďalšie uvažovanie je skôr teoretik/filozofia/ o juniorovi).
Po rozhodnutí o požiadavkách začneme vyberať riešenie z krabice. Prečo znovu vynájsť koleso: pôjdeme a vezmeme si hotový systém ukladania do vyrovnávacej pamäte.
Ak ešte len začínate a vygooglite si, tak dajte alebo prijmite príkaz, ale vo všeobecnosti budú pokyny takéto. V prvom rade natrafíte na Redis, ten je počuť všade. Potom zistíte, že EhCache je najstarší a najosvedčenejší systém. Ďalej budeme písať o Tarantool, domácom vývoji, ktorý má jedinečný aspekt riešenia. A tiež Ignite, pretože je teraz na vzostupe popularity a teší sa podpore SberTech. Na konci je aj Hazelcast, pretože v podnikovom svete sa často objavuje medzi veľkými spoločnosťami.
Zoznam nie je úplný, existujú desiatky systémov. A pokazíme len jednu vec. Zoberme si vybraných 5 systémov do „súťaže krásy“ a urobme výber. Kto bude víťaz?
Redis
Čítame, čo píšu na oficiálnej stránke.
- opensource projekt. Ponúka ukladanie dát v pamäti, možnosť ukladania na disk, automatické delenie na oddiely, vysokú dostupnosť a obnovu po výpadkoch siete.
Zdá sa, že je všetko v poriadku, môžete to vziať a priskrutkovať - všetko, čo potrebujete, to robí. Ale len pre zaujímavosť, pozrime sa na ostatných kandidátov.
EhCache
- „najpoužívanejšia cache pre Javu“ (preklad sloganu z oficiálnej stránky). Tiež opensource. A potom chápeme, že Redis nie je pre java, ale pre všeobecnú, a na interakciu s ňou potrebujete obal. A EhCache bude pohodlnejšie. Čo ešte systém sľubuje? Spoľahlivosť, overená, plná funkčnosť. No je aj najbežnejšia. A ukladá do vyrovnávacej pamäte terabajty údajov.
Redis je zabudnutý, som pripravený vybrať si EhCache.
Ale pocit vlastenectva ma núti vidieť, čo je na Tarantole dobré.
Tarantool
- spĺňa označenie „Platforma integrácie údajov v reálnom čase“. Znie to veľmi komplikovane, preto si podrobne prečítame stránku a nájdeme hlasné vyhlásenie: „Ukladá 100 % údajov do pamäte RAM.“ To by malo vyvolať otázky – veď dát môže byť oveľa viac ako pamäte. Vysvetlenie je, že to znamená, že Tarantool nespúšťa serializáciu na zapisovanie údajov na disk z pamäte. Namiesto toho využíva nízkoúrovňové funkcie systému, keď je pamäť jednoducho namapovaná na súborový systém s veľmi dobrým I/O výkonom. Vo všeobecnosti urobili niečo úžasné a skvelé.
Pozrime sa na implementácie: korporátna diaľnica Mail.ru, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...
Ak by ešte existovali nejaké pochybnosti o Tarantole, tak prípad implementácie v Mastercard ma končí. Beriem Tarantool.
Ale aj tak…
Zapáliť
...je tam ešte niečo , sa účtuje ako „in-memory computing platform...in-memory speeds petabajtov dát“. Je tu tiež veľa výhod: distribuovaná vyrovnávacia pamäť v pamäti, najrýchlejšie úložisko kľúč-hodnota a vyrovnávacia pamäť, horizontálne škálovanie, vysoká dostupnosť, prísna integrita. Vo všeobecnosti sa ukazuje, že najrýchlejší je Ignite.
Implementácie: Sberbank, American Airlines, Yahoo! Japonsko. A potom zistím, že Ignite nie je implementovaný len v Sberbank, ale tím SberTech posiela svojich ľudí do samotného tímu Ignite, aby produkt vylepšili. To je úplne podmanivé a som pripravený vziať Ignite.
Nie je úplne jasné prečo, pozerám sa na piaty bod.
lieskový oriešok
Idem na stránku , čítanie. A ukázalo sa, že najrýchlejším riešením pre distribuované ukladanie do vyrovnávacej pamäte je Hazelcast. Je rádovo rýchlejší ako všetky ostatné riešenia a vo všeobecnosti je lídrom v oblasti in-memory dátových sietí. Na tomto pozadí vziať niečo iné znamená nerešpektovať seba. Taktiež využíva redundantné dátové úložisko pre nepretržitú prevádzku klastra bez straty dát.
To je všetko, som pripravený vziať Hazelcast.
Сравнение
Ale keď sa pozriete, všetkých päť kandidátov je opísaných tak, že každý z nich je najlepší. Ako si vybrať? Môžeme vidieť, ktorý z nich je najobľúbenejší, hľadať porovnania a bolesť hlavy zmizne.
Takého nájdeme , vyberte si našich 5 systémov.
Tu sú zoradené: Redis je na vrchole, Hazelcast je na druhom mieste, Tarantool a Ignite získavajú na popularite, EhCache bol a zostáva rovnaký.
Ale pozrime sa : odkazy na webové stránky, všeobecný záujem o systém, pracovné ponuky - super! To znamená, že keď môj systém zlyhá, poviem: „Nie, je spoľahlivý! Pracovných ponúk je veľa...“ Takéto jednoduché porovnanie neobstojí.
Všetky tieto systémy nie sú len systémy ukladania do vyrovnávacej pamäte. Majú tiež veľa funkcií vrátane prípadov, keď sa údaje neprenášajú na klienta na spracovanie, ale naopak: kód, ktorý je potrebné vykonať na údajoch, sa presunie na server, tam sa spustí a vráti sa výsledok. A nie sú tak často považované za samostatný systém na ukladanie do vyrovnávacej pamäte.
Dobre, nevzdávajme sa, nájdime si priame porovnanie systémov. Zoberme si dve najvyššie možnosti - Redis a Hazelcast. Zaujíma nás rýchlosť a na základe tohto parametra ich budeme porovnávať.
Hz vs Redis
Toto nájdeme :
Modrá je Redis, červená je Hazelcast. Hazelcast vyhráva všade a má to svoje opodstatnenie: je viacvláknový, vysoko optimalizovaný, každé vlákno pracuje s vlastným oddielom, takže nedochádza k blokovaniu. A Redis je jednovláknový, nevyužíva moderné viacjadrové CPU. Hazelcast má asynchrónne I/O, Redis-Jedis má blokovacie zásuvky. Koniec koncov, Hazelcast používa binárny protokol a Redis je textovo orientovaný, čo znamená, že je neefektívny.
Pre každý prípad sa obráťme na iný zdroj porovnania. Čo nám ukáže?
Redis vs Hz
ďalšie :
Tu je naopak červená Redis. To znamená, že Redis výkonom prevyšuje Hazelcast. Prvé porovnanie vyhral Hazelcast, druhé Redis. veľmi presne vysvetlil, prečo Hazelcast vyhral predchádzajúce porovnanie.
Ukazuje sa, že výsledok prvého bol skutočne zmanipulovaný: Redis bol odobratý v základnej krabici a Hazelcast bol prispôsobený pre testovací prípad. Potom sa ukáže: po prvé, nemôžeme nikomu dôverovať a po druhé, keď si konečne vyberieme systém, stále ho musíme správne nakonfigurovať. Tieto nastavenia zahŕňajú desiatky, takmer stovky parametrov.
Pretrepávanie fľaše
A celý proces, ktorý sme teraz urobili, môžem vysvetliť nasledujúcou metaforou: „Potriasť fľašou.“ To znamená, že teraz nemusíte programovať, teraz je hlavnou vecou vedieť čítať stackoverflow. A v tíme mám človeka, profesionála, ktorý presne takto funguje v kritických momentoch.
Čo robí? Vidí rozbitú vec, vidí stopu zásobníka, preberá z nej nejaké slová (ktoré sú jeho odbornosťou v programe), vyhľadáva na Googli a medzi odpoveďami nájde stackoverflow. Bez čítania, bez rozmýšľania si spomedzi odpovedí na otázku vyberá niečo, čo sa najviac podobá vete „urob to a to“ (výber takejto odpovede je jeho talent, pretože nie vždy je odpoveď, ktorá získala najviac lajkov), platí , vyzerá: ak sa niečo zmenilo, tak super. Ak sa nezmenil, vráťte ho späť. A zopakujte spustenie-kontrolu-vyhľadávanie. A týmto intuitívnym spôsobom zaisťuje, že kód po určitom čase funguje. Nevie prečo, nevie čo urobil, nevie si to vysvetliť. Ale! Táto infekcia funguje. A "oheň je uhasený." Teraz poďme zistiť, čo sme urobili. Keď program funguje, je to rádovo jednoduchšie. A to šetrí veľa času.
Táto metóda je veľmi dobre vysvetlená na tomto príklade.
Kedysi bolo veľmi populárne zbierať plachetnicu do fľaše. Plachetnica je zároveň veľká a krehká a hrdlo fľaše je veľmi úzke, nedá sa zatlačiť dovnútra. Ako ho zložiť?
Existuje taká metóda, veľmi rýchla a veľmi účinná.
Loď sa skladá z hromady drobností: palice, laná, plachty, lepidlo. To všetko dáme do fľaše.
Vezmeme fľašu oboma rukami a začneme triasť. Trepeme a trasieme ňou. A zvyčajne sa z toho, samozrejme, stane úplný odpad. Ale niekedy. Niekedy sa ukáže, že je to loď! Presnejšie niečo podobné ako loď.
Toto niekomu ukážeme: "Seryoga, vidíš!?" A skutočne, z diaľky to vyzerá ako loď. Ale toto nemôže pokračovať.
Existuje aj iný spôsob. Používajú ich pokročilejší chlapi, napríklad hackeri.
Dal som tomuto chlapíkovi úlohu, urobil všetko a odišiel. A vidíte - vyzerá to, že je to hotové. A po chvíli, keď treba doladiť kód, to kvôli nemu začína... Je dobré, že už stihol utiecť ďaleko. Toto sú chlapci, ktorí na príklade fľaše urobia toto: vidíte, kde je dno, sklo sa ohýba. A nie je úplne jasné, či je to transparentné alebo nie. Potom „hackeri“ toto dno odrežú, vložia tam loď, potom dno znova prilepia a je to, ako keby to tak malo byť.
Z pohľadu nastavenia problému sa zdá byť všetko správne. Ale ak použijeme lode ako príklad: prečo vôbec vyrábať túto loď, kto ju vôbec potrebuje? Neposkytuje žiadnu funkčnosť. Zvyčajne sú takéto lode darom pre vysokopostavených ľudí, ktorí ich kladú na policu nad seba, ako nejaký symbol, ako znamenie. A ak takýto človek, šéf veľkého podniku alebo vysoký úradník, ako bude stáť vlajka takémuto hacku, ktorému odrezali krk? Bolo by lepšie, keby o tom nikdy nevedel. Ako teda nakoniec vyrobili tieto lode, ktoré môžu byť odovzdané dôležitej osobe?
Jediné kľúčové miesto, s ktorým naozaj nemôžete nič urobiť, je telo. A trup lode zapadá presne do krku. Zatiaľ čo loď je zostavená mimo fľaše. Ale nie je to len skladanie lode, je to skutočné šperkárske remeslo. Ku komponentom sú pridané špeciálne páky, ktoré následne umožňujú ich zdvihnutie. Plachty sa napríklad zložia, opatrne vnesú dovnútra a potom sa pomocou pinzety veľmi presne a presne vytiahnu a zdvihnú. Výsledkom je umelecké dielo, ktoré možno obdarovať s čistým svedomím a hrdosťou.
A ak chceme, aby bol projekt úspešný, v tíme musí byť aspoň jeden klenotník. Niekoho, komu záleží na kvalite produktu a berie do úvahy všetky aspekty, bez toho, aby čokoľvek obetoval, dokonca aj vo chvíľach stresu, keď si okolnosti vyžadujú robiť súrne na úkor dôležitého. Na tomto princípe sú postavené všetky úspešné projekty, ktoré sú udržateľné, preverené časom. Je v nich niečo veľmi presné a jedinečné, niečo, čo využíva všetky dostupné možnosti. V príklade s loďou vo fľaši sa hrá s tým, že trup lode prechádza cez krk.
Keď sa vrátime k úlohe výberu nášho servera na ukladanie do vyrovnávacej pamäte, ako by sa táto metóda dala použiť? Ponúkam túto možnosť výberu zo všetkých systémov, ktoré existujú - netrepať fľašu, nevyberať, ale pozerať sa na to, čo v zásade majú, čo hľadať pri výbere systému.
Kde hľadať hrdlo fľaše
Pokúsme sa netriasť fľašou, neprechádzať všetko, čo tam je, jednu po druhej, ale pozrime sa, aké problémy nastanú, ak zrazu, pre našu úlohu, sami navrhneme takýto systém. Samozrejme, nebudeme montovať bicykel, ale použijeme tento diagram, ktorý nám pomôže zistiť, ktorým bodom treba venovať pozornosť v popisoch produktov. Načrtneme takýto diagram.
Ak je systém distribuovaný, potom budeme mať niekoľko serverov (6). Povedzme, že sú štyri (je vhodné umiestniť ich na obrázok, ale samozrejme ich môže byť toľko, koľko chcete). Ak sú servery na rôznych uzloch, znamená to, že všetky bežia nejaký kód, ktorý je zodpovedný za zabezpečenie toho, aby tieto uzly vytvorili klaster a v prípade prerušenia sa navzájom spojili a rozpoznali.
Potrebujeme aj logiku kódu (2), ktorá je vlastne o cachovaní. Klienti interagujú s týmto kódom cez nejaké API. Klientsky kód (1) môže byť v rámci toho istého JVM alebo k nemu pristupovať cez sieť. Logikou implementovanou vo vnútri je rozhodnutie, ktoré objekty nechať v cache a ktoré vyhodiť. Na ukladanie vyrovnávacej pamäte používame pamäť (3), ale v prípade potreby môžeme časť údajov uložiť na disk (4).
Pozrime sa, v ktorých častiach dôjde k zaťaženiu. V skutočnosti sa načíta každá šípka a každý uzol. Po prvé, medzi klientskym kódom a rozhraním API, ak ide o sieťovú komunikáciu, môže byť pokles značne viditeľný. Po druhé, v rámci samotného api – ak to preženieme so zložitou logikou, môžeme naraziť na problémy s CPU. A bolo by pekné, keby logika nestrácala čas pamäťou. A zostáva interakcia so súborovým systémom - v bežnej verzii je to serializácia / obnovenie a zápis / čítanie.
Ďalej je interakcia s klastrom. S najväčšou pravdepodobnosťou to bude v rovnakom systéme, ale mohlo by to byť aj samostatne. Tu treba brať do úvahy aj prenos dát do neho, rýchlosť serializácie dát a interakcie medzi klastrom.
Teraz si vieme na jednej strane predstaviť, „aké ozubené kolesá sa budú otáčať“ v cache systéme pri spracovávaní požiadaviek z nášho kódu, a na druhej strane vieme odhadnúť, aké a koľko požiadaviek náš kód vygeneruje tomuto systému. To stačí na viac-menej triezvy výber – výber systému pre náš prípad použitia.
lieskový oriešok
Pozrime sa, ako aplikovať tento rozklad na náš zoznam. Napríklad Hazelcast.
Aby bolo možné vložiť/prevziať údaje z Hazelcast, klientsky kód pristupuje (1) k api. Hz vám umožňuje spustiť server ako vstavaný a v tomto prípade je prístup k api volanie metódy vnútri JVM, ktoré možno považovať za bezplatné.
Aby logika v (2) fungovala, Hz sa spolieha na hash bajtového poľa serializovaného kľúča - to znamená, že kľúč bude v každom prípade serializovaný. Toto je nevyhnutná réžia pre Hz.
Stratégie vysťahovania sú implementované dobre, ale pre špeciálne prípady môžete pridať svoje vlastné. Tejto časti sa báť nemusíte.
Je možné pripojiť úložný priestor (4). Skvelé. Interakciu (5) pre embedded možno považovať za okamžitú. Výmena dát medzi uzlami v klastri (6) - áno, existuje. Ide o investíciu do odolnosti voči chybám na úkor rýchlosti. Funkcia Hz Near-cache vám umožní znížiť cenu – dáta prijaté z iných uzlov v klastri budú uložené do vyrovnávacej pamäte.
Čo sa dá v takýchto podmienkach urobiť na zvýšenie rýchlosti?
Napríklad, aby ste sa vyhli serializácii kľúča v (2) - pripojte ďalšiu vyrovnávaciu pamäť na vrch Hazelcast pre najhorúcejšie údaje. Sportmaster si na tento účel vybral kofeín.
Pre krútenie na úrovni (6) ponúka Hz dva typy ukladania: IMap a ReplicatedMap.
Stojí za zmienku, ako sa Hazelcast dostal do technologického zásobníka Sportmaster.
V roku 2012, keď sme pracovali na úplne prvom pilote budúcej stránky, sa ako prvý odkaz, ktorý vyhľadávač vrátil, ukázal práve Hazelcast. Zoznámenie začalo „prvýkrát“ - uchvátila nás skutočnosť, že len o dve hodiny neskôr, keď sme do systému zaskrutkovali Hz, to fungovalo. A fungovalo to dobre. Do konca dňa sme absolvovali niekoľko testov a boli sme spokojní. A táto rezerva elánu stačila na to, aby prekonala prekvapenia, ktoré Hz v priebehu času vyvolalo. Teraz tím Sportmaster nemá dôvod opustiť Hazelcast.
Ale argumenty ako „prvý odkaz vo vyhľadávači“ a „HelloWorld bol rýchlo zostavený“ sú, samozrejme, výnimkou a črtou momentu, v ktorom sa výber uskutočnil. Skutočné testy zvoleného systému začínajú vydaním do produkcie a práve v tejto fáze by ste mali venovať pozornosť výberu akéhokoľvek systému vrátane cache. Vlastne v našom prípade môžeme povedať, že sme si Hazelcast vybrali náhodou, no potom sa ukázalo, že sme si vybrali správne.
Pre produkciu je to oveľa dôležitejšie: monitorovanie, riešenie porúch na jednotlivých uzloch, replikácia dát, náklady na škálovanie. To znamená, že stojí za to venovať pozornosť úlohám, ktoré sa vyskytnú pri údržbe systému - keď je zaťaženie niekoľko desiatokkrát vyššie, ako sa plánovalo, keď náhodou niečo nahráme na nesprávne miesto, keď potrebujeme spustiť novú verziu kódu, nahraďte údaje a urobte to pre klientov bez povšimnutia.
Pre všetky tieto požiadavky Hazelcast určite vyhovuje.
Pokračovanie nabudúce
Hazelcast však nie je všeliekom. V roku 2017 sme si vybrali Hazelcast ako vyrovnávaciu pamäť správcu, jednoducho na základe dobrých dojmov z minulých skúseností. To zohralo kľúčovú úlohu vo veľmi krutom vtipe, kvôli ktorému sme sa ocitli v ťažkej situácii a „hrdinsky“ sa z nej dostali na 60 dní. Ale o tom viac v ďalšej časti.
Medzitým... Šťastný nový kód!
Zdroj: hab.com