Helló! A nevem Alexey Pyankov, fejlesztő vagyok a Sportmaster cégnél. Abban Elmeséltem, hogyan kezdődött a munka a Sportmaster honlapján 2012-ben, milyen kezdeményezéseket sikerült „átütnünk” és fordítva, milyen gereblyét gyűjtöttünk.
Ma olyan gondolatokat szeretnék megosztani, amelyek egy másik témát követnek - gyorsítótárazási rendszer kiválasztása a java háttérrendszerhez a webhely adminisztrációs területén. Ez a cselekmény számomra különleges jelentéssel bír - bár a történet mindössze 2 hónapig bontakozott ki, ezalatt a 60 nap alatt 12-16 órát dolgoztunk, egyetlen szabadnap nélkül. Soha nem gondoltam volna és nem is gondoltam volna, hogy lehet ilyen keményen dolgozni.
Ezért a szöveget 2 részre osztottam, hogy ne töltsem be teljesen. Ellenkezőleg, az első rész nagyon könnyű lesz - előkészítés, bevezetés, néhány megfontolás a gyorsítótárazásról. Ha már tapasztalt fejlesztő vagy, vagy dolgozott gyorsítótárral, akkor technikai oldalról valószínűleg semmi újdonság nem lesz ebben a cikkben. De egy juniornak egy ilyen kis áttekintés megmondhatja, melyik irányba nézzen, ha ilyen válaszút elé kerül.
Amikor a Sportmaster weboldal új verzióját gyártásba helyezték, az adatok finoman szólva nem túl kényelmes módon érkeztek. Az alapot az oldal előző verziójához (Bitrix) készített táblázatok képezték, amelyeket ETL-be kellett húzni, új formába hozni és további tucatnyi rendszerből különféle apróságokkal gazdagítani. Ahhoz, hogy új kép vagy termékleírás megjelenhessen az oldalon, másnapig kellett várni - frissítés csak éjszaka, naponta egyszer.
Eleinte annyi gond volt a gyártás első heteiben, hogy a tartalomkezelők ilyen kellemetlenségei csekélységnek számítottak. De amint minden rendeződött, a projekt fejlesztése folytatódott - néhány hónappal később, 2015 elején megkezdtük az adminisztrációs panel aktív fejlesztését. 2015-ben és 2016-ban minden jól megy, rendszeresen adunk ki, az adminisztrációs panel egyre többet fed le az adatok előkészítéséről, és készülünk arra, hogy hamarosan csapatunkra bízzák a legfontosabb és legösszetettebb dolgot - a terméket áramkör (az összes termékre vonatkozó adatok teljes előkészítése és karbantartása). De 2017 nyarán, közvetlenül az áruáramkör elindítása előtt, a projekt nagyon nehéz helyzetbe kerül - pontosan a gyorsítótárazási problémák miatt. Erről az epizódról szeretnék beszélni a kétrészes kiadvány második részében.
De ebben a bejegyzésben messziről kezdem, bemutatok néhány gondolatot - ötletet a gyorsítótárazásról, amit egy nagy projekt előtt jó lépés lenne végiglapozni.
Gyorsítótárazási feladat esetén
A gyorsítótárazási feladat nem csak megjelenik. Fejlesztők vagyunk, szoftverterméket írunk, és szeretnénk, ha kereslet lenne rá. Ha a termék keresett és sikeres, akkor jönnek a felhasználók. És egyre többen jönnek. És akkor sok a felhasználó, és akkor a termék nagyon terheltté válik.
Az első szakaszokban nem gondolunk az optimalizálásra és a kódteljesítményre. A lényeg a funkcionalitás, a pilot gyors bevezetése és a hipotézisek tesztelése. Ha pedig nő a terhelés, felpumpáljuk a vasat. Kétszer-háromszorosára, ötszörösére, esetleg 10-szeresére növeljük. Valahol itt – a pénzügyek ezt már nem teszik lehetővé. Hányszorosára nő a felhasználók száma? Nem olyan lesz, mint 2-5-10, hanem ha sikerül, akkor 100-1000-től 100 ezerig. Vagyis előbb-utóbb optimalizálni kell.
Tegyük fel, hogy a kód egy része (nevezzük ezt a részt függvénynek) méltatlanul sok időt vesz igénybe, és szeretnénk csökkenteni a végrehajtási időt. Egy függvény lehet hozzáférés egy adatbázishoz, vagy lehet valamilyen összetett logika végrehajtása – a lényeg az, hogy hosszú időt vesz igénybe. Mennyivel csökkentheti a végrehajtási időt? A limitben nullára csökkentheti, tovább nem. Hogyan lehet nullára csökkenteni a végrehajtási időt? Válasz: a végrehajtást teljesen meg kell szüntetni. Ehelyett azonnal küldje vissza az eredményt. Hogyan lehet megtudni az eredményt? Válasz: vagy számold ki, vagy nézz meg valahol. Sok időt vesz igénybe a számítás. A kémkedés pedig azt jelenti, hogy például emlékezünk arra az eredményre, amelyet a függvény utoljára produkált, amikor ugyanazokkal a paraméterekkel hívták meg.
Vagyis számunkra nem fontos a funkció megvalósítása. Elég csak tudni, hogy milyen paraméterektől függ az eredmény. Ezután, ha a paraméterértékek egy objektum formájában vannak ábrázolva, amely kulcsként használható valamilyen tárolóban, akkor a számítás eredménye elmenthető, és a következő hozzáféréskor kiolvasható. Ha az eredménynek ez az írása és kiolvasása gyorsabb, mint a függvény végrehajtása, akkor a sebesség szempontjából nyereségünk van. A haszon mértéke elérheti a 100, 1000 és 100 ezerszeresét (a 10^5 inkább kivétel, de egy eléggé lemaradó bázis esetén ez teljesen lehetséges).
A gyorsítótárazó rendszer alapvető követelményei
Az első dolog, ami a gyorsítótárazó rendszer követelményévé válhat, a gyors olvasási sebesség, és valamivel kisebb mértékben az írási sebesség. Ez igaz, de csak addig, amíg a rendszert ki nem állítjuk a termelésbe.
Játsszuk ezt az esetet.
Tegyük fel, hogy a jelenlegi terhelést hardverrel láttuk el, és most fokozatosan bevezetjük a gyorsítótárazást. Kicsit nő a felhasználók száma, nő a terhelés - adunk hozzá egy kis gyorsítótárat, csavarjuk be ide-oda. Ez egy ideig folytatódik, és a nehéz funkciókat gyakorlatilag már nem hívják meg - a teljes fő terhelés a gyorsítótárra esik. A felhasználók száma ezalatt N-szeresére nőtt.
Ha pedig a kezdeti hardverkészlet 2-5-szöröse lehet, akkor a gyorsítótár segítségével 10-szeresére, jó esetben 100-szorosára, néhol talán szorzósára is javíthatnánk a teljesítményt. Azaz ugyanazon a hardveren – 1000-szor több kérést dolgozunk fel. Szuper, megérdemled a mézeskalácsot!
De most, egy szép pillanatban, véletlenül a rendszer összeomlott, és a gyorsítótár összeomlott. Semmi különös - végül is a gyorsítótárat a „nagy olvasási és írási sebesség, a többi nem számít” követelmény alapján választották ki.
A kiindulási terheléshez viszonyítva 2-5-szörös volt a vastartalékunk, és ez idő alatt a terhelés 10-100-szorosára nőtt. A gyorsítótár használatával kiküszöböltük a nehéz funkciókra vonatkozó hívásokat, így minden működött. És most, gyorsítótár nélkül, hányszor fog lelassulni a rendszerünk? Mi lesz velünk? A rendszer bukni fog.
Még ha a gyorsítótárunk nem is összeomlott, hanem csak egy ideig törlődött, akkor is fel kell melegíteni, és ez eltart egy ideig. És ez idő alatt a fő teher a funkcionalitásra hárul.
Következtetés: A nagy terhelésű gyártási projektek gyorsítótárazási rendszert igényelnek, nemcsak nagy olvasási és írási sebességgel, hanem az adatok biztonságának és a hibákkal szembeni ellenálló képességnek a biztosítására is.
A választás kínja
Egy adminisztrációs panellel rendelkező projektben a választás így zajlott: először telepítettük a Hazelcastot, mert Ezt a terméket már a főoldal tapasztalataiból ismertük. De itt ez a választás sikertelennek bizonyult - a mi terhelési profilunk alatt a Hazelcast nem csak lassú, hanem rettenetesen lassú. És akkor már feliratkoztunk a megjelenési dátumra.
Spoiler: pontosan hogyan alakultak a körülmények, hogy ekkora ügyet kihagytunk, és éles, feszült helyzetbe kerültünk - a második részben elmesélem -, és hogyan kötöttünk ki és hogyan jutottunk ki. De most csak annyit mondok, hogy sok stressz volt, és "gondolkodni - valahogy nem tudok gondolkodni, rázzuk az üveget." A „shaking the palack” is spoiler, erről majd később.
Mit tettünk:
- Listát készítünk a Google és a StackOverflow által javasolt összes rendszerről. Kicsit több mint 30
- Gyártásra jellemző terheléssel írunk teszteket. Ennek érdekében olyan adatokat rögzítettünk, amelyek éles környezetben haladnak át a rendszeren - egyfajta szippantásként nem a hálózaton, hanem a rendszeren belül. Pontosan ezeket az adatokat használták fel a tesztek során.
- Az egész csapattal mindenki kiválasztja a listából a következő rendszert, beállítja és lefuttatja a teszteket. Nem megy át a próbán, nem viseli a terhelést – kidobjuk, és továbblépünk a sorban következőre.
- A 17. rendszeren világossá vált, hogy minden reménytelen. Hagyd abba a palack rázását, ideje komolyan gondolni.
De ez egy lehetőség, ha olyan rendszert kell választania, amely „átvészeli a sebességet” az előre elkészített teszteken. Mi van, ha még nincsenek ilyen tesztek, és gyorsan szeretne választani?
Modellezzük ezt a lehetőséget (nehéz elképzelni, hogy egy közepes+ fejlesztő légüres térben él, és a kiválasztáskor még nem formálissá tette, hogy melyik terméket próbálja ki először – ezért a további érvelés inkább elméleti/filozófia/ egy juniorról).
Miután eldöntöttük a követelményeket, megkezdjük a megoldás kiválasztását. Miért kell újra feltalálni a kereket: megyünk és veszünk egy kész gyorsítótár-rendszert.
Ha még csak most kezded, és rákeresel a google-ra, akkor adj vagy vedd fel a rendelést, de az irányelvek általában ilyenek lesznek. Először is Redisszel fog találkozni, mindenhol hallható. Akkor megtudja, hogy az EhCache a legrégebbi és leginkább bevált rendszer. Legközelebb a Tarantoolról írunk, egy hazai fejlesztésről, amelynek egyedi aspektusa van a megoldásban. És az Ignite is, mert mostanra egyre népszerűbb, és élvezi a SberTech támogatását. A végén ott van még a Hazelcast, mert a nagyvállalatok körében gyakran megjelenik a nagyvállalatok körében.
A lista nem teljes, több tucat rendszer létezik. És csak egy dolgot csesztünk el. Vegyük a kiválasztott 5 rendszert a „szépségversenyre”, és válogassunk. Ki lesz a győztes?
Feleinek
Elolvastuk, mit írnak a hivatalos weboldalon.
- nyílt forráskódú projekt. Memórián belüli adattárolást, lemezre mentést, automatikus particionálást, magas rendelkezésre állást és hálózati kimaradások utáni helyreállítást kínál.
Úgy tűnik, minden rendben van, felveheti és felcsavarja - minden, amire szüksége van, megteszi. De csak a móka kedvéért nézzük meg a többi jelöltet.
EhCache
- „a legszélesebb körben használt gyorsítótár a Java számára” (a szlogen fordítása a hivatalos webhelyről). Nyílt forráskódú is. És akkor megértjük, hogy a Redis nem java-hoz való, hanem általános, és a vele való interakcióhoz szükség van egy wrapperre. És az EhCache kényelmesebb lesz. Mit ígér még a rendszer? Megbízhatóság, bevált, teljes funkcionalitás. Nos, ez is a leggyakoribb. És gyorsítótáraz terabájtnyi adatot.
Redis feledésbe merült, készen állok az EhCache választására.
De a hazaszeretet érzése arra késztet, hogy lássam, mi a jó Tarantoolban.
Tarantool
- megfelel a „valós idejű adatintegrációs platform” elnevezésnek. Nagyon bonyolultnak hangzik, ezért részletesen elolvassuk az oldalt, és hangos kijelentést találunk: „Az adatok 100%-át a RAM-ban tárolja.” Ez kérdéseket vet fel – elvégre sokkal több adat lehet, mint a memória. A magyarázat az, hogy ez azt jelenti, hogy a Tarantool nem futtatja a szerializálást, hogy adatokat írjon a lemezre a memóriából. Ehelyett a rendszer alacsony szintű szolgáltatásait használja, amikor a memória egyszerűen le van képezve egy nagyon jó I/O teljesítménnyel rendelkező fájlrendszerre. Általában valami csodálatos és klassz dolgot csináltak.
Nézzük a megvalósításokat: Mail.ru vállalati autópálya, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...
Ha még mindig voltak kétségek a Tarantool-lal kapcsolatban, akkor a Mastercard implementációs esete befejez engem. Tarantoolt szedek.
De egyébként is…
Meggyullad
… van még néhány , „memórián belüli számítástechnikai platformként… a memórián belüli sebesség petabájtnyi adaton” van számlázva. Ezen kívül számos előnye van: elosztott memórián belüli gyorsítótár, leggyorsabb kulcsérték-tárolás és gyorsítótár, vízszintes méretezés, magas rendelkezésre állás, szigorú integritás. Általában kiderül, hogy a leggyorsabb az Ignite.
Megvalósítások: Sberbank, American Airlines, Yahoo! Japán. Aztán rájövök, hogy az Ignite-ot nem csak a Sberbankban vezették be, hanem a SberTech csapata maga az Ignite csapathoz küldi az embereit, hogy finomítsák a terméket. Ez teljesen magával ragadó, és készen állok az Ignite-ra.
Teljesen homályos, hogy miért, az ötödik pontot nézem.
Hazelcast
megyek az oldalra , olvasás. És kiderül, hogy az elosztott gyorsítótárazás leggyorsabb megoldása a Hazelcast. Nagyságrendekkel gyorsabb, mint az összes többi megoldás, és általában véve is vezető szerepet tölt be a memórián belüli adatrácsok területén. Ennek fényében, ha mást veszünk, nem tiszteli magát. Redundáns adattárolást is használ a fürt folyamatos, adatvesztés nélküli működéséhez.
Ez az, készen állok a Hazelcastra.
Сравнение
De ha megnézzük, mind az öt jelöltet úgy írják le, hogy mindegyik a legjobb. Hogyan válasszunk? Megnézhetjük, melyik a legnépszerűbb, keressük az összehasonlításokat, és elmúlik a fejfájás.
Találunk egy ilyet , válassza ki az 5 rendszerünket.
Itt vannak válogatva: Redis az élen, a Hazelcast a második helyen, a Tarantool és az Ignite egyre népszerűbb, az EhCache ugyanaz volt és marad.
De nézzük : weboldalakra mutató linkek, általános érdeklődés a rendszer iránt, állásajánlatok – remek! Vagyis amikor a rendszerem meghibásodik, azt mondom: „Nem, megbízható! Sok állásajánlat van..." Egy ilyen egyszerű összehasonlítás nem megy.
Mindezek a rendszerek nem csak gyorsítótárazó rendszerek. Ezen kívül rengeteg funkcionalitással rendelkeznek, például amikor nem a klienshez pumpálják az adatokat feldolgozásra, hanem fordítva: az adatokon végrehajtandó kód átkerül a szerverre, ott lefutják, és az eredményt visszaküldik. És nem olyan gyakran tekintik őket a gyorsítótárazás különálló rendszerének.
Oké, ne adjuk fel, keressük a rendszerek közvetlen összehasonlítását. Vegyük a két legjobb lehetőséget - Redis és Hazelcast. Minket a sebesség érdekel, és e paraméter alapján fogjuk összehasonlítani őket.
Hz vs Redis
Ezt találjuk :
A kék a Redis, a piros a Hazelcast. A Hazelcast mindenhol nyer, ennek meg is van az indoka: többszálas, erősen optimalizált, minden szál saját partícióval működik, így nincs blokkolás. A Redis egyszálú, nem használ a modern többmagos CPU-k előnyeit. A Hazelcast aszinkron I/O-val rendelkezik, a Redis-Jedis blokkoló aljzatokkal rendelkezik. Végül is a Hazelcast bináris protokollt használ, a Redis pedig szövegközpontú, vagyis nem hatékony.
Minden esetre forduljunk egy másik összehasonlítási forráshoz. Mit fog mutatni nekünk?
Redis vs Hz
másik :
Itt éppen ellenkezőleg, a vörös Redis. Vagyis a Redis a teljesítmény tekintetében felülmúlja a Hazelcastot. Az első összehasonlítást Hazelcast, a másodikat Redis nyerte. nagyon pontosan elmagyarázta, hogy a Hazelcast miért nyerte meg az előző összehasonlítást.
Kiderült, hogy az első eredményét valójában meghamisították: Redist az alapdobozba vitték, a Hazelcastot pedig egy tesztesetre szabták. Aztán kiderül: egyrészt nem bízhatunk senkiben, másrészt amikor végre választunk egy rendszert, akkor is helyesen kell konfigurálnunk. Ezek a beállítások több tucat, majdnem száz paramétert tartalmaznak.
Az üveg megrázása
És az egész folyamatot, amit most csináltunk, a következő metaforával tudom megmagyarázni: „Az üveg megrázása”. Vagyis most nem kell programozni, most az a lényeg, hogy tudd olvasni a stackoverflow-t. És van egy ember a csapatomban, egy szakember, aki a kritikus pillanatokban pontosan így dolgozik.
Mit csinál? Lát egy törött dolgot, lát egy veremnyomot, kivesz belőle néhány szót (melyik az ő szakértelme a programban), keres a Google-ben, stackoverflow-t talál a válaszok között. Olvasás, gondolkodás nélkül a kérdésre adott válaszok közül választ valami leginkább a „csináld ezt és azt” mondathoz (ilyen választ választani az ő tehetsége, mert nem mindig ez kapta a legtöbb lájkot), vonatkozik, úgy néz ki: ha valami megváltozott, akkor nagyszerű. Ha nem változott, tekerje vissza. És ismételje meg az indítás-ellenőrzés-keresést. És ezen az intuitív módon biztosítja, hogy a kód egy idő után működjön. Nem tudja miért, nem tudja, mit tett, nem tudja megmagyarázni. De! Ez a fertőzés működik. És "a tűz kialudt". Most nézzük meg, mit csináltunk. Amikor a program működik, egy nagyságrenddel könnyebb. És sok időt takarít meg.
Ez a módszer nagyon jól magyarázható ezzel a példával.
Valaha nagyon népszerű volt a vitorlás palackba gyűjtése. Ugyanakkor a vitorlás nagy és törékeny, a palack nyaka pedig nagyon keskeny, nem lehet betolni. Hogyan kell összeszerelni?
Van egy ilyen módszer, nagyon gyors és nagyon hatékony.
A hajó egy csomó apróságból áll: botok, kötelek, vitorlák, ragasztó. Mindezt üvegbe töltjük.
Két kézzel fogjuk az üveget, és elkezdjük rázni. Megrázzuk és megrázzuk. És általában persze teljes szemétnek bizonyul. De néha. Néha kiderül, hogy hajó! Pontosabban valami hajóhoz hasonló.
Ezt mutatjuk valakinek: "Seryoga, látod!?" És valóban, messziről úgy néz ki, mint egy hajó. De ezt nem szabad megengedni.
Van más mód is. Fejlettebb srácok, például hackerek használják őket.
Feladatot adtam ennek a srácnak, mindent megtett és elment. És nézed – úgy tűnik, kész. És egy idő után, amikor véglegesíteni kell a kódot, ez beindul miatta... Még jó, hogy már sikerült messzire elszaladnia. Ők azok a srácok, akik egy palack példáján ezt teszik: látod, ahol a fenék, ott meghajlik az üveg. És nem teljesen világos, hogy átlátszó-e vagy sem. Aztán a „hackerek” levágják ezt az alját, beszúrnak egy hajót, majd újra visszaragasztják az alját, és olyan, mintha ennek így kellene lennie.
A probléma felállítása szempontjából úgy tűnik, hogy minden rendben van. De a hajókkal példálózva: minek egyáltalán ezt a hajót készíteni, kinek van szüksége rá? Nem biztosít semmilyen funkciót. Általában az ilyen hajókat nagyon magas rangú embereknek adják ajándékba, akik föléjük rakják egy polcra, valamiféle szimbólumként, jelként. És ha egy ilyen ember, egy nagy üzlet vezetője vagy egy magas rangú hivatalnok, hogyan áll majd a zászló egy ilyen csapásra, amelynek levágták a nyakát? Jobb lenne, ha soha nem tudna róla. Szóval, hogyan készítik el ezeket a hajókat, amelyeket egy fontos személynek adhatnak?
Az egyetlen kulcsfontosságú hely, amivel tényleg nem tudsz mit kezdeni, az a test. És a hajótest pontosan beleillik a nyakba. Míg a hajót a palackon kívül szerelik össze. De ez nem csak egy hajó összeszerelése, hanem egy igazi ékszermesterség. Az alkatrészekhez speciális karok vannak hozzáadva, amelyek lehetővé teszik azok felemelését. Például a vitorlákat összehajtják, óvatosan beviszik, majd csipesz segítségével nagyon precízen, precízen húzzák és emelik fel. Az eredmény egy tiszta lelkiismerettel és büszkeséggel ajándékozható műalkotás.
És ha azt akarjuk, hogy a projekt sikeres legyen, legalább egy ékszerésznek kell lennie a csapatban. Valaki, aki törődik a termék minőségével, és minden szempontot figyelembe vesz, anélkül, hogy bármit feláldozna, még stresszes pillanatokban is, amikor a körülmények megkövetelik, hogy a sürgős dolgot a fontos rovására tegye. Minden sikeres projekt, amely fenntartható, kiállta az idő próbáját, erre az elvre épül. Van bennük valami nagyon precíz és egyedi, valami, ami minden rendelkezésre álló lehetőséget kihasznál. A példában a hajóval a palackban az a tény, hogy a hajó törzse áthalad a nyakon, kijátszott.
Visszatérve a gyorsítótárazó szerverünk kiválasztásának feladatához, hogyan alkalmazható ez a módszer? Felajánlom ezt a választási lehetőséget az összes létező rendszer közül - ne rázza a palackot, ne válasszon, hanem nézze meg, mi van elvileg, mire kell figyelni a rendszer kiválasztásakor.
Hol keressünk szűk keresztmetszetet
Igyekezzünk nem rázni az üveget, nem egyenként végigmenni mindenen, ami ott van, de nézzük meg, milyen problémák merülnek fel, ha hirtelen, a feladatunkra mi magunk tervezünk egy ilyen rendszert. Természetesen nem szereljük össze a kerékpárt, de ennek a diagramnak a segítségével kitaláljuk, hogy a termékleírásokban milyen pontokra kell figyelni. Vázoljunk fel egy ilyen diagramot.
Ha a rendszer elosztott, akkor több szerverünk lesz (6). Tegyük fel, hogy négy van (kényelmes elhelyezni őket a képen, de természetesen tetszőleges számú lehet). Ha a kiszolgálók különböző csomópontokon vannak, az azt jelenti, hogy mindegyikük valamilyen kódot futtat, amely felelős azért, hogy ezek a csomópontok egy klasztert alkossanak, és szakadás esetén csatlakozzanak és felismerjék egymást.
Szükségünk van kódlogikára is (2), ami tulajdonképpen a gyorsítótárazásról szól. Az ügyfelek valamilyen API-n keresztül lépnek kapcsolatba ezzel a kóddal. Az ügyfélkód (1) lehet ugyanazon a JVM-en belül, vagy elérheti a hálózaton keresztül. A belül megvalósított logika annak eldöntése, hogy mely objektumokat hagyjuk a gyorsítótárban és melyeket dobjuk ki. A gyorsítótár tárolására memóriát (3) használunk, de szükség esetén az adatok egy részét a (4) lemezre is elmenthetjük.
Nézzük meg, mely részeken fog bekövetkezni a terhelés. Valójában minden nyíl és minden csomópont betöltődik. Először is, a kliens kód és az api között, ha ez hálózati kommunikáció, akkor a süllyedés elég észrevehető lehet. Másodszor, magának az api-nak a keretein belül - ha túlzásba viszi a bonyolult logikát, akkor problémákba ütközhetünk a CPU-val. És jó lenne, ha a logika nem vesztegeti az időt a memóriára. És továbbra is interakció marad a fájlrendszerrel - a szokásos verzióban ez a sorozatosítás / visszaállítás és az írás / olvasás.
A következő lépés a klaszterrel való interakció. Valószínűleg ugyanabban a rendszerben lesz, de lehet külön is. Itt figyelembe kell venni az adatátvitelt, az adatsorosodás sebességét és a fürtök közötti interakciókat is.
Most egyrészt el tudjuk képzelni, hogy „milyen fogaskerekek fognak fordulni” a cache rendszerben a kódunkból érkező kérések feldolgozásakor, másrészt megbecsülhetjük, hogy a kódunk milyen és hány kérést fog generálni ehhez a rendszerhez. Ez elég ahhoz, hogy többé-kevésbé józan döntést hozzunk – hogy a mi használati esetünknek megfelelő rendszert válasszunk.
Hazelcast
Nézzük meg, hogyan alkalmazzuk ezt a dekompozíciót a listánkra. Például Hazelcast.
A Hazelcast adatok elhelyezése/vétele érdekében az ügyfélkód hozzáfér (1) az API-hoz. A Hz lehetővé teszi a szerver beágyazottként történő futtatását, és ebben az esetben az api elérése egy metódushívás a JVM-en belül, ami ingyenesnek tekinthető.
Annak érdekében, hogy a (2)-ben szereplő logika működjön, a Hz a sorosított kulcs bájttömbjének hash-ére támaszkodik - vagyis a kulcs minden esetben szerializálva lesz. Ez elkerülhetetlen Hz-nél többletköltség.
A kilakoltatási stratégiákat jól alkalmazzák, de speciális esetekre felveheti a sajátját. Nem kell aggódnia emiatt a rész miatt.
Tároló (4) csatlakoztatható. Nagy. Az interakció (5) beágyazott esetén azonnalinak tekinthető. Adatcsere a (6) fürt csomópontjai között – igen, létezik. Ez befektetés a hibatűrésbe a sebesség rovására. A Hz-es Near-cache funkció lehetővé teszi az ár csökkentését - a fürt többi csomópontjától kapott adatok gyorsítótárazásra kerülnek.
Mit lehet ilyen körülmények között tenni a sebesség növelésére?
Például, hogy elkerülje a (2) kulcs szerializálását, csatoljon egy másik gyorsítótárat a Hazelcast tetejére a legforróbb adatokért. A Sportmaster a koffeint választotta erre a célra.
A (6) szintű csavaráshoz a Hz kétféle tárolót kínál: IMap és ReplicatedMap.
Érdemes megemlíteni, hogyan került a Hazelcast a Sportmaster technológiai halmazba.
2012-ben, amikor a leendő oldal legelső pilotján dolgoztunk, a Hazelcast volt az első link, amelyet a kereső visszaadott. Az ismerkedés „első alkalommal” indult – elbűvölt bennünket, hogy alig két órával később, amikor a Hz-t csavartuk a rendszerbe, működött. És jól működött. A nap végére számos tesztet teljesítettünk, és elégedettek voltunk. Ez az erőtartalék pedig elég volt ahhoz, hogy leküzdje azokat a meglepetéseket, amelyeket a Hz hányt az idő múlásával. A Sportmaster csapatának most nincs oka elhagyni Hazelcastot.
De az olyan érvek, mint „az első link a keresőmotorban” és a „HelloWorld gyorsan összeállt”, természetesen kivételt képeznek, és annak a pillanatnak a jellemzői, amikor a választás megtörtént. A kiválasztott rendszer valódi tesztjei a termelésbe való kiadással kezdődnek, és ebben a szakaszban kell figyelni a rendszer kiválasztásakor, beleértve a gyorsítótárat is. Igazából a mi esetünkben azt mondhatjuk, hogy véletlenül a Hazelcastot választottuk, de aztán kiderült, hogy jól választottunk.
A termelés szempontjából sokkal fontosabb: figyelés, meghibásodások kezelése az egyes csomópontokon, adatreplikáció, méretezési költség. Vagyis érdemes odafigyelni a rendszer karbantartása során felmerülő feladatokra - amikor a tervezettnél több tízszeres a terhelés, ha véletlenül rossz helyre rakunk fel valamit, amikor új verziót kell kigurítani cserélje ki az adatokat, és tegye ezt észrevétlenül az ügyfelek számára.
Mindezen követelmények mellett a Hazelcast minden bizonnyal megfelel a számnak.
Folytatjuk
De a Hazelcast nem csodaszer. 2017-ben a Hazelcastot választottuk az adminisztrációs gyorsítótárnak, egyszerűen a múltbeli tapasztalatok jó benyomásai alapján. Ez kulcsszerepet játszott egy nagyon kegyetlen viccben, ami miatt nehéz helyzetbe kerültünk és „hősiesen” 60 napra kiszálltunk belőle. De erről bővebben a következő részben.
Addig is... Boldog új kódot!
Forrás: will.com