Ahoj! Jmenuji se Alexey Pyankov, jsem vývojář ve společnosti Sportmaster. V tomto Vyprávěl jsem, jak v roce 2012 začaly práce na webu Sportmaster, jaké iniciativy se nám podařilo „prosadit“ a naopak, jaké rake jsme nasbírali.
Dnes se chci podělit o myšlenky, které následují po jiném tématu – výběru cachovacího systému pro java backend v oblasti správy webu. Tato zápletka má pro mě zvláštní význam - ačkoli se příběh odvíjel pouhé 2 měsíce, během těchto 60 dnů jsme pracovali 12-16 hodin a bez jediného dne volna. Nikdy jsem si ani nepředstavoval, že je možné pracovat tak tvrdě.
Text jsem proto rozdělila na 2 části, abych jej nenačetla celý. Naopak první část bude velmi odlehčená – příprava, úvod, nějaké úvahy o tom, co je to kešování. Pokud jste již zkušený vývojář nebo jste s cachemi pracovali, po technické stránce v tomto článku nejspíš nebude nic nového. Ale juniorovi může taková malá recenze napovědět, kterým směrem se má dívat, pokud se ocitne na takové křižovatce.
Při uvedení nové verze webu Sportmaster do výroby byla data přijímána mírně řečeno nepříliš pohodlným způsobem. Základem byly tabulky připravené pro předchozí verzi stránek (Bitrix), které bylo nutné natáhnout do ETL, dovést do nové podoby a obohatit o různé drobnosti z desítky dalších systémů. Aby se na stránkách objevil nový obrázek nebo popis produktu, museli jste počkat do druhého dne – aktualizace pouze v noci, jednou denně.
Nejprve bylo z prvních týdnů nástupu do výroby tolik starostí, že takové nepříjemnosti pro správce obsahu byly maličkosti. Jakmile se ale vše ustálilo, vývoj projektu pokračoval – o pár měsíců později, začátkem roku 2015, jsme začali aktivně vyvíjet admin panel. V letech 2015 a 2016 jde vše dobře, pravidelně uvolňujeme, admin panel pokrývá stále více a více z přípravy dat a připravujeme se na to, že brzy bude našemu týmu svěřeno to nejdůležitější a nejsložitější - produkt okruhu (úplná příprava a údržba dat o všech produktech). Jenže v létě 2017, těsně před spuštěním komoditního okruhu, se projekt ocitne ve velmi složité situaci – právě kvůli problémům s cachováním. O této epizodě chci mluvit v druhé části této dvoudílné publikace.
Ale v tomto příspěvku začnu zpovzdálí, představím několik myšlenek - nápadů o cachování, které by bylo dobrým krokem k procházení před velkým projektem.
Když dojde k úloze ukládání do mezipaměti
Úloha ukládání do mezipaměti se jen tak neobjeví. Jsme vývojáři, píšeme softwarový produkt a chceme, aby byl žádaný. Pokud je produkt žádaný a úspěšný, uživatelé přijdou. A přicházejí další a další. A pak je tu spousta uživatelů a pak se produkt stává vysoce zatíženým.
V prvních fázích nepřemýšlíme o optimalizaci a výkonu kódu. Hlavní je funkčnost, rychlé spuštění pilotu a testování hypotéz. A pokud se zátěž zvýší, napumpujeme žehličku. Zvyšujeme to dvakrát nebo třikrát, pětkrát, možná 10krát. Někde tady – finance už to nedovolí. Kolikrát se zvýší počet uživatelů? Nebude to jako 2-5-10, ale v případě úspěchu to bude 100-1000 až 100 tisíckrát. To znamená, že dříve nebo později budete muset provést optimalizaci.
Řekněme, že nějaká část kódu (říkejme této části funkce) trvá neslušně dlouho a my chceme zkrátit dobu provádění. Funkce může být přístup k databázi, nebo to může být provedení nějaké složité logiky – hlavní je, že její dokončení trvá dlouho. Jak moc můžete zkrátit dobu realizace? V limitu to můžete snížit na nulu, dále ne. Jak můžete zkrátit dobu provádění na nulu? Odpověď: exekuci zcela odstranit. Místo toho okamžitě vraťte výsledek. Jak zjistíte výsledek? Odpověď: buď si to spočítejte, nebo se někde podívejte. Výpočet trvá dlouho. A špehovat znamená například zapamatovat si výsledek, který funkce naposledy vyprodukovala při volání se stejnými parametry.
To znamená, že implementace funkce pro nás není důležitá. Stačí vědět, na jakých parametrech závisí výsledek. Pokud jsou pak hodnoty parametrů reprezentovány ve formě objektu, který lze použít jako klíč v nějakém úložišti, lze výsledek výpočtu uložit a přečíst při příštím přístupu. Pokud je tento zápis a čtení výsledku rychlejší než provedení funkce, máme z hlediska rychlosti zisk. Výše zisku může dosáhnout 100, 1000 a 100 tisíckrát (10^5 je spíše výjimka, ale v případě poměrně zaostávající základny je to docela možné).
Základní požadavky na cachovací systém
První věcí, která se může stát požadavkem pro systém ukládání do mezipaměti, je vysoká rychlost čtení a v o něco menší míře rychlost zápisu. To je pravda, ale pouze do doby, než systém zavedeme do výroby.
Pojďme si zahrát tento případ.
Řekněme, že jsme aktuální zátěž zajistili hardwarem a nyní postupně zavádíme cachování. Trochu roste počet uživatelů, roste zátěž – přidáváme trochu mezipaměti, sem tam to zašroubujeme. To pokračuje nějakou dobu a nyní se těžké funkce již prakticky nevolají - celé hlavní zatížení připadá na mezipaměť. Počet uživatelů se během této doby Nkrát zvýšil.
A pokud by počáteční zásoba hardwaru mohla být 2-5krát, pak s pomocí mezipaměti bychom mohli zlepšit výkon o faktor 10 nebo v dobrém případě o faktor 100, na některých místech možná o faktor 1000. Tedy na stejném hardwaru – zpracováváme 100x více požadavků. Skvělé, zasloužíš si perník!
Ale teď, v jednu krásnou chvíli, náhodou systém spadl a mezipaměť se zhroutila. Nic zvláštního – mezipaměť byla nakonec vybrána na základě požadavku „vysoká rychlost čtení a zápisu, na zbytku nezáleží“.
V poměru k počátečnímu zatížení byla naše železná rezerva 2-5krát a zatížení během této doby vzrostlo 10-100krát. Pomocí mezipaměti jsme eliminovali volání těžkých funkcí a proto vše fungovalo. A teď, bez mezipaměti, kolikrát se náš systém zpomalí? co se s námi stane? Systém padne.
I když se naše mezipaměť nezhroutila, ale byla vymazána jen na chvíli, bude potřeba ji zahřát, a to nějakou dobu potrvá. A během této doby bude hlavní zátěž dopadat na funkčnost.
Závěr: vysoce zatížené produkční projekty vyžadují systém ukládání do mezipaměti nejen proto, aby měl vysokou rychlost čtení a zápisu, ale také aby zajistil bezpečnost dat a odolnost proti selhání.
Mouka volby
V projektu s administrátorským panelem byla volba takto: nejprve jsme nainstalovali Hazelcast, protože Tento produkt jsme již znali ze zkušenosti hlavního webu. Zde se ale tato volba ukázala jako neúspěšná – pod naším profilem zátěže je Hazelcast nejen pomalý, ale strašně pomalý. A v té době jsme již měli zapsaný termín vydání.
Spoiler: jak přesně se vyvíjely okolnosti, že jsme tak velkou věc propásli a skončili akutní a napjatou situací – to vám povím ve druhém díle – a jak jsme dopadli a jak jsme se dostali ven. Ale teď - řeknu jen, že to byl velký stres, a "přemýšlet - nějak nemůžu myslet, třepeme lahví." „Shaking the bottle“ je také spoiler, o tom později.
Co jsme udělali:
- Vytváříme seznam všech systémů, které Google a StackOverflow navrhují. Něco málo přes 30
- Testy píšeme se zátěží typickou pro výrobu. K tomu jsme zaznamenávali data, která procházejí systémem v produkčním prostředí – jakýsi sniffer pro data nikoli v síti, ale uvnitř systému. Přesně tato data byla použita v testech.
- S celým týmem si každý vybere další systém ze seznamu, nakonfiguruje ho a spustí testy. Neprojde testem, neunese zátěž – vyhodíme ho a přejdeme k dalšímu v řadě.
- Na 17. systému se ukázalo, že vše je beznadějné. Přestaňte třepat lahvičkou, je čas se vážně zamyslet.
Toto je však možnost, když potřebujete vybrat systém, který „projde rychlostí“ v předem připravených testech. Co když takové testy ještě nejsou a chcete si rychle vybrat?
Pojďme si tuto možnost namodelovat (těžko si představit, že vývojář middle+ žije ve vzduchoprázdnu a v době výběru ještě nemá formalizovanou preferenci, který produkt vyzkoušet jako první - proto je další uvažování spíše teoretik/filosofie/ o juniorce).
Poté, co jsme se rozhodli pro požadavky, začněme s výběrem řešení z krabice. Proč znovu vynalézat kolo: půjdeme a vezmeme si hotový systém ukládání do mezipaměti.
Pokud teprve začínáte a googlujete, pak dejte nebo přijměte příkaz, ale obecně budou pokyny takové. V první řadě narazíte na Redis, je slyšet všude. Pak zjistíte, že EhCache je nejstarší a nejosvědčenější systém. Dále budeme psát o Tarantool, domácím vývoji, který má jedinečný aspekt řešení. A také Ignite, protože je nyní na vzestupu popularity a těší se podpoře SberTech. Na konci je také Hazelcast, protože v podnikovém světě se často objevuje mezi velkými společnostmi.
Seznam není vyčerpávající, existují desítky systémů. A pokazíme jen jednu věc. Vezměme vybraných 5 systémů pro „soutěž krásy“ a udělejme výběr. Kdo bude vítěz?
Redestilát
Čteme, co píší na oficiálních stránkách.
- opensource projekt. Nabízí ukládání dat v paměti, možnost ukládání na disk, automatické dělení, vysokou dostupnost a obnovu po výpadcích sítě.
Zdá se, že je vše v pořádku, můžete to vzít a přišroubovat - vše, co potřebujete, to dělá. Ale jen pro zajímavost, podívejme se na další kandidáty.
EhCache
- „nejrozšířenější cache pro Javu“ (překlad sloganu z oficiálních stránek). Také opensource. A pak chápeme, že Redis není pro java, ale obecný, a k interakci s ním potřebujete obal. A EhCache bude pohodlnější. Co dalšího systém slibuje? Spolehlivost, osvědčená, plná funkčnost. No, to je také nejčastější. A ukládá do mezipaměti terabajty dat.
Redis je zapomenut, jsem připraven zvolit EhCache.
Ale pocit vlastenectví mě nutí vidět, co je na Tarantool dobré.
Tarantool
- splňuje označení „platforma pro integraci dat v reálném čase“. Zní to velmi složitě, a tak si stránku podrobně přečteme a najdeme hlasité prohlášení: „Ukládá 100 % dat do mezipaměti RAM.“ To by mělo vyvolávat otázky – vždyť dat může být mnohem více než paměti. Vysvětlení je, že to znamená, že Tarantool nespouští serializaci pro zápis dat na disk z paměti. Místo toho využívá nízkoúrovňové funkce systému, kdy je paměť jednoduše namapována na souborový systém s velmi dobrým I/O výkonem. Obecně udělali něco úžasného a skvělého.
Podívejme se na implementace: Firemní dálnice Mail.ru, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...
Pokud by stále existovaly nějaké pochybnosti o Tarantool, pak mě dokončuje případ implementace v Mastercard. Beru Tarantool.
Ale stejně…
Zapálit
…je tam ještě něco , je účtován jako „výpočetní platforma v paměti...rychlosti v paměti na petabajtech dat“. Zde je také mnoho výhod: distribuovaná mezipaměť, nejrychlejší úložiště klíč-hodnota a mezipaměť, horizontální škálování, vysoká dostupnost, přísná integrita. Obecně se ukazuje, že nejrychlejší je Ignite.
Realizace: Sberbank, American Airlines, Yahoo! Japonsko. A pak zjistím, že Ignite není implementován jen ve Sberbank, ale tým SberTech posílá své lidi do samotného týmu Ignite, aby produkt vylepšili. To je naprosto uchvacující a jsem připraven vzít Ignite.
Není úplně jasné proč, dívám se na pátý bod.
hazelcast
Jdu na stránky , čtení. A ukazuje se, že nejrychlejším řešením distribuovaného ukládání do mezipaměti je Hazelcast. Je řádově rychlejší než všechna ostatní řešení a obecně je lídrem v oblasti in-memory datových mřížek. Na tomto pozadí brát něco jiného znamená nerespektovat sám sebe. Využívá také redundantní úložiště dat pro nepřetržitý provoz clusteru bez ztráty dat.
To je vše, jsem připraven vzít Hazelcast.
Porovnání
Ale když se podíváte, všech pět kandidátů je popsáno tak, že každý z nich je nejlepší. Jak si vybrat? Můžeme vidět, který z nich je nejoblíbenější, hledat srovnání a bolest hlavy zmizí.
Najdeme jednu takovou , vyberte si našich 5 systémů.
Zde jsou seřazeny: Redis je na vrcholu, Hazelcast je na druhém místě, Tarantool a Ignite získávají na popularitě, EhCache byl a zůstává stejný.
Ale podívejme se : odkazy na webové stránky, obecný zájem o systém, pracovní nabídky - skvělé! To znamená, že když můj systém selže, řeknu: „Ne, je spolehlivý! Pracovních nabídek je spousta...“ Takové jednoduché srovnání neobstojí.
Všechny tyto systémy nejsou pouze systémy ukládání do mezipaměti. Mají také mnoho funkcí, včetně případů, kdy data nejsou pumpována ke klientovi ke zpracování, ale naopak: kód, který je třeba na datech provést, se přesune na server, tam se spustí a vrátí se výsledek. A nejsou tak často považovány za samostatný systém pro ukládání do mezipaměti.
Dobře, nevzdávejme se, najdeme přímé srovnání systémů. Vezměme si dvě nejlepší možnosti – Redis a Hazelcast. Zajímá nás rychlost a na základě tohoto parametru je budeme porovnávat.
Hz vs Redis
Najdeme toto :
Modrá je Redis, červená je Hazelcast. Hazelcast vítězí všude a má to své opodstatnění: je vícevláknový, vysoce optimalizovaný, každé vlákno pracuje s vlastním oddílem, takže nedochází k blokování. A Redis je jednovláknový a netěží z moderních vícejádrových CPU. Hazelcast má asynchronní I/O, Redis-Jedis má blokovací zásuvky. Koneckonců, Hazelcast používá binární protokol a Redis je textově orientovaný, což znamená, že je neefektivní.
Pro každý případ se podívejme na jiný zdroj srovnání. Co nám ukáže?
Redis vs Hz
Jiný :
Zde je naopak červená Redis. To znamená, že Redis výkonem překonává Hazelcast. Hazelcast vyhrál první srovnání, Redis vyhrál druhé. vysvětlil velmi přesně, proč Hazelcast vyhrál předchozí srovnání.
Ukazuje se, že výsledek prvního z nich byl ve skutečnosti zmanipulovaný: Redis byl pořízen v základní krabici a Hazelcast byl přizpůsoben pro testovací případ. Pak se ukáže: zaprvé nemůžeme nikomu věřit a zadruhé, když si konečně vybereme systém, musíme ho stále správně nakonfigurovat. Tato nastavení zahrnují desítky, téměř stovky parametrů.
Zatřepání lahví
A mohu vysvětlit celý proces, který jsme nyní provedli, pomocí následující metafory: „Zatřesení lahví“. To znamená, že nyní nemusíte programovat, nyní je hlavní věcí umět číst stackoverflow. A ve svém týmu mám člověka, profesionála, který přesně takhle funguje v kritických chvílích.
Co dělá? Vidí rozbitou věc, vidí stopu zásobníku, vezme si z toho nějaká slova (která jsou jeho odborností v programu), vyhledává na Googlu a mezi odpověďmi najde stackoverflow. Bez přečtení, bez přemýšlení si mezi odpověďmi na otázku vybere něco, co se nejvíce podobá větě „udělej to a to“ (výběr takové odpovědi je jeho talent, protože ne vždy je to odpověď, která získala nejvíce lajků), platí , vypadá: jestli se něco změnilo, tak super. Pokud se nezměnila, vraťte ji zpět. A opakujte spuštění-kontrola-hledání. A tímto intuitivním způsobem zajišťuje, že kód po nějaké době funguje. Neví proč, neví, co udělal, neumí to vysvětlit. Ale! Tato infekce funguje. A "oheň je uhašen." Teď pojďme zjistit, co jsme udělali. Když program funguje, je to o řád jednodušší. A ušetří to spoustu času.
Tato metoda je velmi dobře vysvětlena na tomto příkladu.
Kdysi bylo velmi oblíbené sbírat plachetnici do láhve. Plachetnice je přitom velká a křehká a hrdlo láhve je velmi úzké, nelze ji zatlačit dovnitř. Jak to sestavit?
Existuje taková metoda, velmi rychlá a velmi účinná.
Loď se skládá z hromady maličkostí: hůlky, lana, plachty, lepidlo. To vše dáme do láhve.
Vezmeme lahvičku oběma rukama a začneme třást. Třeseme a třepeme s ní. A většinou se z toho samozřejmě vyklube úplný odpad. Ale někdy. Někdy se ukáže, že je to loď! Přesněji něco podobného jako loď.
Někomu něco ukážeme: "Seryoga, vidíš!?" A skutečně, zdálky to vypadá jako loď. Ale nelze dovolit, aby to pokračovalo.
Existuje i jiný způsob. Používají je pokročilejší kluci, jako jsou hackeři.
Dal jsem tomu chlapovi úkol, udělal všechno a odešel. A vidíte – vypadá to, že je hotovo. A po chvíli, když je potřeba dodělat kód, to kvůli němu začíná... Je dobře, že už stihl utéct daleko. To jsou kluci, kteří na příkladu láhve udělají toto: vidíte, kde je dno, sklo se ohýbá. A není zcela jasné, zda je transparentní či nikoliv. Pak „hackeři“ toto dno odříznou, vloží tam loď, pak dno znovu přilepí a je to, jako by to tak mělo být.
Z hlediska nastavení problému se zdá být vše v pořádku. Ale na příkladu lodí: proč tuto loď vůbec vyrábět, kdo ji vůbec potřebuje? Neposkytuje žádnou funkcionalitu. Obvykle jsou takové lodě dary velmi vysoce postaveným lidem, kteří je dávají na polici nad sebou jako nějaký symbol, jako znamení. A když takový člověk, šéf velkého podniku nebo vysoký úředník, jak bude stát vlajka takovému hacku, kterému byl uříznut krk? Bylo by lepší, kdyby o tom nikdy nevěděl. Jak tedy nakonec vyrobili tyto lodě, které mohou být předány důležité osobě?
Jediné klíčové místo, se kterým opravdu nemůžete nic dělat, je tělo. A trup lodi zapadá přímo do krku. Zatímco loď je sestavena mimo láhev. Ale není to jen sestavení lodi, je to skutečné šperkařské řemeslo. Ke komponentám jsou přidány speciální páky, které pak umožňují jejich zvedání. Plachty se například složí, opatrně vnesou dovnitř a pak se pomocí pinzety velmi přesně a přesně vytáhnou a zvednou. Výsledkem je umělecké dílo, které lze obdarovat s čistým svědomím a hrdostí.
A pokud chceme, aby byl projekt úspěšný, musí být v týmu alespoň jeden klenotník. Někoho, komu záleží na kvalitě produktu a bere v úvahu všechny aspekty, aniž by cokoliv obětoval, a to i ve chvílích stresu, kdy okolnosti vyžadují udělat naléhavé na úkor důležitého. Na tomto principu jsou postaveny všechny úspěšné projekty, které jsou udržitelné, které prošly zkouškou času. Je v nich něco velmi precizního a jedinečného, něco, co využívá všech dostupných možností. V příkladu s lodí v láhvi se hraje to, že trup lodi prochází krkem.
Vrátíme-li se k úloze výběru našeho serveru pro ukládání do mezipaměti, jak lze tuto metodu použít? Nabízím tuto možnost výběru ze všech systémů, které existují - lahví netřepat, nevybírat, ale podívat se, co v zásadě mají, na co si dát při výběru systému pozor.
Kde hledat hrdlo láhve
Zkusme netřepat lahví, neprocházet všechno, co tam je, jednu po druhé, ale podívejme se, jaké problémy nastanou, když si najednou pro svůj úkol takový systém sami navrhneme. Kolo samozřejmě nesestavíme, ale tento diagram nám pomůže zjistit, na které body v popisech produktů věnovat pozornost. Pojďme si načrtnout takové schéma.
Pokud je systém distribuován, budeme mít několik serverů (6). Řekněme, že jsou čtyři (je vhodné je umístit na obrázek, ale samozřejmě jich může být tolik, kolik chcete). Pokud jsou servery na různých uzlech, znamená to, že na všech běží nějaký kód, který je zodpovědný za to, že tyto uzly vytvoří cluster a v případě přerušení se spojí a vzájemně se poznají.
Potřebujeme také logiku kódu (2), která je vlastně o ukládání do mezipaměti. Klienti komunikují s tímto kódem přes nějaké API. Klientský kód (1) může být buď v rámci stejného JVM, nebo k němu přistupovat přes síť. Logika implementovaná uvnitř je rozhodnutí o tom, které objekty ponechat v mezipaměti a které vyhodit. K uložení cache používáme paměť (3), ale v případě potřeby můžeme některá data uložit na disk (4).
Podívejme se, ve kterých částech dojde k zatížení. Ve skutečnosti se načte každá šipka a každý uzel. Za prvé, mezi klientským kódem a rozhraním API, pokud se jedná o síťovou komunikaci, může být pokles docela patrný. Za druhé, v rámci samotného api – pokud to přeženeme se složitou logikou, můžeme narazit na problémy s CPU. A bylo by hezké, kdyby logika neztrácela čas pamětí. A zůstává interakce se systémem souborů - v obvyklé verzi je to serializace / obnovení a zápis / čtení.
Další je interakce s clusterem. S největší pravděpodobností to bude ve stejném systému, ale mohlo by to být samostatně. Zde je také potřeba vzít v úvahu přenos dat do něj, rychlost serializace dat a interakce mezi clusterem.
Nyní si na jedné straně dokážeme představit, „jaká ozubená kola se otočí“ v cache systému při zpracování požadavků z našeho kódu, a na druhou stranu můžeme odhadnout, jaké a kolik požadavků náš kód pro tento systém vygeneruje. To stačí k víceméně střízlivé volbě – k výběru systému pro náš případ použití.
hazelcast
Podívejme se, jak tento rozklad aplikovat na náš seznam. Například Hazelcast.
Aby bylo možné vložit/vzít data z Hazelcast, klientský kód přistupuje (1) k rozhraní API. Hz vám umožňuje spouštět server jako vestavěný a v tomto případě je přístup k rozhraní API voláním metody uvnitř JVM, které lze považovat za bezplatné.
Aby logika v (2) fungovala, spoléhá Hz na hash bajtového pole serializovaného klíče - to znamená, že klíč bude v každém případě serializován. To je nevyhnutelná režie pro Hz.
Strategie vystěhování jsou implementovány dobře, ale pro speciální případy můžete přidat vlastní. O tuto část se nemusíte starat.
Lze připojit úložiště (4). Skvělý. Interakce (5) pro embedded lze považovat za okamžitou. Výměna dat mezi uzly v clusteru (6) - ano, existuje. Jde o investici do odolnosti proti chybám na úkor rychlosti. Funkce Hz Near-cache umožňuje snížit cenu – data přijatá z jiných uzlů v clusteru budou ukládána do mezipaměti.
Co lze v takových podmínkách udělat pro zvýšení rychlosti?
Chcete-li se například vyhnout serializaci klíče v (2) - připojte na Hazelcast další mezipaměť pro nejžhavější data. Sportmaster si pro tento účel vybral kofein.
Pro kroucení na úrovni (6) nabízí Hz dva typy úložiště: IMap a ReplicatedMap.
Za zmínku stojí, jak se Hazelcast dostal do technologického zásobníku Sportmaster.
V roce 2012, kdy jsme pracovali na úplně prvním pilotu budoucího webu, se právě Hazelcast ukázal jako první odkaz, který vyhledávač vrátil. Seznámení začalo „poprvé“ – zaujalo nás, že jen o dvě hodiny později, když jsme do systému našroubovali Hz, to fungovalo. A fungovalo to dobře. Do konce dne jsme dokončili řadu testů a byli šťastní. A tato rezerva elánu stačila k překonání překvapení, která Hz v průběhu času vyvolalo. Nyní tým Sportmaster nemá důvod opustit Hazelcast.
Ale takové argumenty jako „první odkaz ve vyhledávači“ a „HelloWorld byl rychle sestavený“ jsou samozřejmě výjimkou a rysem okamžiku, kdy došlo k výběru. Skutečné testy zvoleného systému začínají vydáním do výroby a právě v této fázi byste měli věnovat pozornost výběru jakéhokoli systému, včetně cache. Vlastně v našem případě můžeme říci, že jsme Hazelcast vybrali náhodou, ale pak se ukázalo, že jsme zvolili správně.
Pro produkci mnohem důležitější: monitorování, řešení poruch na jednotlivých uzlech, replikace dat, náklady na škálování. To znamená, že stojí za to věnovat pozornost úkolům, které se vyskytnou při údržbě systému - když je zatížení desítkykrát vyšší, než bylo plánováno, když omylem nahrajeme něco na špatné místo, když potřebujeme spustit novou verzi kódu, nahraďte data a udělejte to pro klienty bez povšimnutí.
Pro všechny tyto požadavky Hazelcast rozhodně vyhovuje.
Pokračování příště
Hazelcast ale není všelék. V roce 2017 jsme zvolili Hazelcast pro mezipaměť správce, jednoduše na základě dobrých dojmů z minulých zkušeností. To sehrálo klíčovou roli ve velmi krutém vtipu, kvůli kterému jsme se ocitli ve složité situaci a „hrdinsky“ se z ní dostali na 60 dní. Ale o tom více v příštím díle.
Mezitím... Šťastný nový kód!
Zdroj: www.habr.com