Zdravo! Moje ime je Alexey Pyankov, sem razvijalec v podjetju Sportmaster. V tem Povedal sem, kako se je začelo delo na spletni strani Sportmaster leta 2012, katere pobude smo uspeli »preriniti« in obratno, kakšne rake smo zbrali.
Danes želim deliti misli, ki sledijo drugi temi - izbiri sistema predpomnjenja za zaledje java na skrbniški plošči spletnega mesta. Ta zaplet ima zame poseben pomen - čeprav se je zgodba odvijala le 2 meseca, smo v teh 60 dneh delali 12-16 ur in brez enega prostega dne. Nikoli si nisem mislil ali predstavljal, da je mogoče tako trdo delati.
Zato sem besedilo razdelil na 2 dela, da ga ne naložim v celoti. Ravno nasprotno, prvi del bo zelo lahek - priprava, uvod, nekaj razmislekov o tem, kaj je predpomnjenje. Če ste že izkušen razvijalec ali ste delali s predpomnilniki, s tehnične strani v tem članku najverjetneje ne bo nič novega. Toda mladincu lahko tako majhen pregled pove, v katero smer naj pogleda, če se znajde na takšnem razpotju.
Ob zagonu nove različice spletne strani Sportmaster so bili podatki prejeti na milo rečeno neprimeren način. Osnova so bile tabele, pripravljene za prejšnjo različico strani (Bitrix), ki jih je bilo treba potegniti v ETL, spraviti v novo obliko in obogatiti z raznimi malenkostmi iz še ducata sistemov. Da bi se na spletnem mestu pojavila nova slika ali opis izdelka, ste morali počakati do naslednjega dne - posodobitve samo ponoči, enkrat na dan.
Sprva je bilo od prvih tednov po začetku proizvodnje toliko skrbi, da so bile tovrstne nevšečnosti za vsebinske upravitelje malenkost. Toda takoj, ko se je vse uredilo, se je razvoj projekta nadaljeval - nekaj mesecev kasneje, v začetku leta 2015, smo začeli aktivno razvijati skrbniško ploščo. V letih 2015 in 2016 gre vse dobro, izdajamo redno, skrbniška plošča pokriva vedno več priprave podatkov in pripravljamo se na to, da bo naši ekipi kmalu zaupana najpomembnejša in kompleksna stvar - produkt krog (celotna priprava in vzdrževanje podatkov o vseh izdelkih). Toda poleti 2017, tik pred zagonom blagovnega kroga, se bo projekt znašel v zelo težkem položaju - prav zaradi težav s predpomnjenjem. O tej epizodi želim govoriti v drugem delu te publikacije v dveh delih.
Toda v tem prispevku bom začel od daleč, predstavil bom nekaj misli – idej o predpomnjenju, ki bi bil dober korak za listanje pred velikim projektom.
Ko pride do opravila predpomnjenja
Naloga predpomnjenja se ne pojavi kar tako. Smo razvijalci, pišemo programski izdelek in želimo, da je povpraševanje po njem. Če je izdelek povpraševan in uspešen, bodo uporabniki prišli. In prihaja jih vedno več. In potem je veliko uporabnikov in potem postane izdelek zelo obremenjen.
Na prvih stopnjah ne razmišljamo o optimizaciji in uspešnosti kode. Glavna stvar je funkcionalnost, hitro uvajanje pilota in testiranje hipotez. In če se obremenitev poveča, črpamo železo. Povečamo dvakrat ali trikrat, petkrat, morda 10-krat. Tu nekje – finance tega ne dopuščajo več. Kolikokrat se bo povečalo število uporabnikov? Ne bo kot 2-5-10, ampak če bo uspešen, bo od 100-1000 do 100 tisočkrat. Se pravi, prej ali slej boste morali narediti optimizacijo.
Recimo, da nek del kode (recimo temu delu funkcija) traja nespodobno dolgo in želimo skrajšati čas izvajanja. Funkcija je lahko dostop do podatkovne baze, lahko pa je izvajanje neke zapletene logike - glavno je, da traja dolgo, da se dokonča. Koliko lahko skrajšate čas izvedbe? V limitu ga lahko zmanjšate na nič, nič več. Kako lahko skrajšate čas izvajanja na nič? Odgovor: popolna odprava izvršbe. Namesto tega takoj vrnite rezultat. Kako lahko ugotovite rezultat? Odgovor: ali izračunajte ali poglejte kje. Izračun traja dolgo časa. In vohunjenje pomeni na primer zapomniti si rezultat, ki ga je funkcija zadnjič ustvarila, ko je bila poklicana z istimi parametri.
Se pravi, izvajanje funkcije nam ni pomembno. Dovolj je samo vedeti, od katerih parametrov je odvisen rezultat. Potem, če so vrednosti parametrov predstavljene v obliki predmeta, ki se lahko uporablja kot ključ v nekem pomnilniku, se lahko rezultat izračuna shrani in prebere ob naslednjem dostopu. Če je to pisanje in branje rezultata hitrejše od izvajanja funkcije, imamo dobiček glede na hitrost. Znesek dobička lahko doseže 100, 1000 in 100 tisočkrat (10^5 je precej izjema, vendar je v primeru precej zaostajajoče baze povsem mogoče).
Osnovne zahteve za sistem predpomnjenja
Prva stvar, ki lahko postane zahteva za sistem predpomnjenja, je visoka hitrost branja in v nekoliko manjši meri hitrost pisanja. To je res, vendar le dokler sistema ne uvedemo v proizvodnjo.
Igrajmo ta primer.
Recimo, da smo s strojno opremo zagotovili trenutno obremenitev in zdaj postopoma uvajamo predpomnjenje. Število uporabnikov malo raste, obremenitev raste - dodamo malo predpomnilnikov, tu in tam privijemo. To se nadaljuje nekaj časa in zdaj se težke funkcije praktično ne kličejo več - celotna glavna obremenitev pade na predpomnilnik. Število uporabnikov se je v tem času povečalo N-krat.
In če bi lahko bila začetna dobava strojne opreme 2- do 5-kratna, potem bi lahko s pomočjo predpomnilnika izboljšali zmogljivost za faktor 10 ali, v dobrem primeru, za faktor 100, ponekod morda za faktor od 1000. Se pravi na isti strojni opremi – obdelamo 100-krat več zahtev. Super, zaslužiš si medenjake!
Toda zdaj se je v nekem lepem trenutku po naključju sistem zrušil in predpomnilnik se je sesul. Nič posebnega - navsezadnje je bil predpomnilnik izbran na podlagi zahteve "visoka hitrost branja in pisanja, ostalo ni pomembno."
Glede na začetno obremenitev je bila naša rezerva železa 2-5-krat, obremenitev pa se je v tem času povečala 10-100-krat. Z uporabo predpomnilnika smo odpravili klice težkih funkcij in zato je vse delovalo. In zdaj, brez predpomnilnika, kolikokrat se bo naš sistem upočasnil? Kaj bo z nami? Sistem bo padel.
Tudi če se naš predpomnilnik ni zrušil, ampak je bil samo za nekaj časa počiščen, ga bo treba ogreti, kar bo trajalo nekaj časa. In v tem času bo glavno breme padlo na funkcionalnost.
Zaključek: visoko obremenjeni produkcijski projekti zahtevajo sistem predpomnjenja ne le za visoke hitrosti branja in pisanja, ampak tudi za zagotavljanje varnosti podatkov in odpornosti na napake.
Moka po izbiri
Pri projektu z skrbniško ploščo je izbira potekala takole: najprej smo namestili Hazelcast, ker Ta izdelek smo že poznali iz izkušenj z glavne strani. Toda tukaj se je ta izbira izkazala za neuspešno - pod našim profilom obremenitve Hazelcast ni le počasen, ampak strašno počasen. In takrat smo se že prijavili na datum izida.
Spoiler: kako točno so se razvile okoliščine, da smo zamudili tako velik posel in se znašli v akutni in napeti situaciji - vam bom povedal v drugem delu - in kako smo končali in kako smo se izvlekli. Ampak zdaj - rekel bom samo, da je bilo veliko stresa in "misliti - nekako ne morem razmišljati, stresamo steklenico." "Stresanje steklenice" je tudi spojler, več o tem kasneje.
Kaj smo storili:
- Naredimo seznam vseh sistemov, ki jih predlagata Google in StackOverflow. Nekaj čez 30
- Pišemo teste z obremenitvijo, tipično za proizvodnjo. Da bi to naredili, smo posneli podatke, ki gredo skozi sistem v produkcijskem okolju - nekakšen vohljalec za podatke ne v omrežju, ampak znotraj sistema. Točno ta podatek je bil uporabljen pri testiranju.
- S celotno ekipo vsak izbere naslednji sistem s seznama, ga konfigurira in izvaja teste. Ne prestane preizkusa, ne prenese bremena - zavržemo ga in preidemo na naslednjega v vrsti.
- 17. sistemu je postalo jasno, da je vse brezupno. Nehajte tresti steklenico, čas je, da resno razmislite.
Toda to je možnost, ko morate izbrati sistem, ki bo "prebil hitrost" v vnaprej pripravljenih testih. Kaj pa, če teh testov še ni in želite hitro izbrati?
Modelirajmo to možnost (težko si je predstavljati, da srednje+ razvijalec živi v vakuumu in v času izbire še ni formaliziral svojih preferenc glede tega, kateri izdelek naj najprej preizkusi – zato je nadaljnje razmišljanje bolj teoretik/filozofija/ o mladincu).
Ko smo se odločili za zahteve, se lotimo izbire rešitve iz škatle. Zakaj bi znova izumljali kolo: vzeli bomo že pripravljen sistem za predpomnjenje.
Če šele začenjate in googlate, potem povejte ali sprejmite, a na splošno bodo smernice takšne. Najprej boste naleteli na Redis, sliši se povsod. Potem boste ugotovili, da je EhCache najstarejši in najbolj preverjen sistem. Nato bomo pisali o Tarantoolu, domačem razvoju, ki ima edinstven vidik rešitve. In tudi Ignite, ker je zdaj v porastu priljubljenosti in uživa podporo SberTecha. Na koncu še Hazelcast, saj se v podjetniškem svetu pogosto pojavlja med velikimi podjetji.
Seznam ni izčrpen; sistemov je na desetine. In zajebali bomo samo eno stvar. Vzemimo izbranih 5 sistemov za “lepotno tekmovanje” in naredimo izbor. Kdo bo zmagovalec?
Redis
Beremo, kaj pišejo na uradni spletni strani.
- odprtokodni projekt. Ponuja shranjevanje podatkov v pomnilniku, možnost shranjevanja na disk, samodejno particioniranje, visoko razpoložljivost in obnovitev po izpadih omrežja.
Zdi se, da je vse v redu, lahko ga vzamete in privijete - vse, kar potrebujete, naredi. Ampak samo za šalo, poglejmo druge kandidate.
EhCache
- "najpogosteje uporabljen predpomnilnik za Javo" (prevod slogana z uradne spletne strani). Tudi odprtokodni. In potem razumemo, da Redis ni za Javo, ampak splošen, in za interakcijo z njim potrebujete ovoj. In EhCache bo bolj priročen. Kaj še obljublja sistem? Zanesljivost, preverjeno, popolna funkcionalnost. No, tudi najpogostejši je. In predpomni terabajte podatkov.
Redis je pozabljen, pripravljen sem izbrati EhCache.
Toda občutek domoljubja me žene, da vidim, kaj je dobrega v Tarantoolu.
Tarantool
- ustreza oznaki “Platforma za integracijo podatkov v realnem času”. Sliši se zelo zapleteno, zato podrobno preberemo stran in najdemo glasno izjavo: "Caches 100% of the data in RAM." To bi moralo sprožiti vprašanja - navsezadnje je lahko veliko več podatkov kot pomnilnika. Razlaga je, da to pomeni, da Tarantool ne izvaja serializacije za pisanje podatkov na disk iz pomnilnika. Namesto tega uporablja nizkonivojske funkcije sistema, ko je pomnilnik preprosto preslikan v datotečni sistem z zelo dobro V/I zmogljivostjo. Na splošno so naredili nekaj čudovitega in kul.
Poglejmo izvedbe: Mail.ru korporativna avtocesta, Avito, Beeline, Megafon, Alfa-Bank, Gazprom ...
Če so še bili kakršni koli dvomi o Tarantoolu, me primer implementacije pri Mastercardu pokonča. Vzamem Tarantool.
Ampak vseeno…
Ignite
… je še kaj , se zaračunava kot "računalniška platforma v pomnilniku ... hitrosti v pomnilniku na petabajtih podatkov." Tu je tudi veliko prednosti: porazdeljen predpomnilnik v pomnilniku, najhitrejši ključ-vrednost shranjevanje in predpomnilnik, horizontalno skaliranje, visoka razpoložljivost, stroga celovitost. Na splošno se izkaže, da je najhitrejši Ignite.
Implementacije: Sberbank, American Airlines, Yahoo! Japonska. In potem ugotovim, da Ignite ni samo implementiran v Sberbank, ampak ekipa SberTech pošilja svoje ljudi v samo ekipo Ignite, da izpopolnijo izdelek. To je popolnoma privlačno in pripravljen sem sprejeti Ignite.
Povsem nejasno, zakaj, gledam peto točko.
lešnik
Grem na stran , branje. In izkazalo se je, da je najhitrejša rešitev za porazdeljeno predpomnjenje Hazelcast. Je za velikostne rede hitrejši od vseh drugih rešitev in na splošno je vodilni na področju podatkovnega omrežja v pomnilniku. V tem ozadju vzeti nekaj drugega ne pomeni spoštovati sebe. Uporablja tudi redundantno shranjevanje podatkov za neprekinjeno delovanje gruče brez izgube podatkov.
To je to, pripravljen sem vzeti Hazelcast.
Primerjava
Ampak če pogledate, je vseh pet kandidatov opisanih tako, da je vsak najboljši. Kako izbrati? Vidimo lahko, katera je najbolj priljubljena, poiščemo primerjave in glavobol bo minil.
Najdemo enega takega , izberite naših 5 sistemov.
Tukaj so razvrščeni: Redis je na vrhu, Hazelcast na drugem mestu, Tarantool in Ignite pridobivata na priljubljenosti, EhCache je bil in ostaja isti.
Ampak poglejmo : povezave do spletnih strani, splošno zanimanje za sistem, ponudbe za delo - odlično! Se pravi, ko moj sistem odpove, bom rekel: »Ne, zanesljiv je! Ponudb za delo je veliko ...« Tako preprosta primerjava ne bo zadostovala.
Vsi ti sistemi niso le sistemi za predpomnjenje. Imajo tudi veliko funkcionalnosti, tudi kadar se podatki ne črpajo k odjemalcu za obdelavo, ampak obratno: koda, ki jo je treba izvesti na podatkih, se premakne na strežnik, se tam izvede in rezultat se vrne. In niso tako pogosto obravnavani kot ločen sistem za predpomnjenje.
V redu, ne obupajmo, poiščimo neposredno primerjavo sistemov. Vzemimo zgornji dve možnosti - Redis in Hazelcast. Zanima nas hitrost in na podlagi tega parametra jih bomo primerjali.
Hz proti Redisu
To najdemo :
Modra je Redis, rdeča je Hazelcast. Hazelcast zmaga povsod in za to obstaja utemeljitev: je večniten, visoko optimiziran, vsaka nit deluje s svojo particijo, tako da ni blokiranja. In Redis je enoniten; nima koristi od sodobnih večjedrnih procesorjev. Hazelcast ima asinhroni V/I, Redis-Jedis ima blokirajoče vtičnice. Navsezadnje Hazelcast uporablja binarni protokol, Redis pa je osredotočen na besedilo, kar pomeni, da je neučinkovit.
Za vsak slučaj se obrnimo še na drug vir primerjave. Kaj nam bo pokazal?
Redis proti Hz
Še eno :
Tukaj je, nasprotno, rdeča Redis. To pomeni, da Redis po zmogljivosti prekaša Hazelcast. V prvi primerjavi je zmagal Hazelcast, v drugi Redis. je zelo natančno pojasnil, zakaj je Hazelcast zmagal v prejšnji primerjavi.
Izkazalo se je, da je bil rezultat prvega dejansko prirejen: Redis je bil vzet v osnovni škatli, Hazelcast pa prilagojen za testni primer. Potem se izkaže: prvič, nikomur ne moremo zaupati, in drugič, ko končno izberemo sistem, ga moramo še vedno pravilno konfigurirati. Te nastavitve vključujejo na desetine, skoraj na stotine parametrov.
Stresanje steklenice
Celoten proces, ki smo ga zdaj izvedli, lahko razložim z naslednjo metaforo: "Pretresanje steklenice." Se pravi, zdaj vam ni treba programirati, zdaj je glavna stvar, da lahko berete stackoverflow. In v svoji ekipi imam človeka, profesionalca, ki v kritičnih trenutkih dela točno tako.
Kaj dela? Vidi pokvarjeno stvar, vidi sled sklada, vzame iz nje nekaj besed (katere so njegovo strokovno znanje v programu), išče v Googlu, med odgovori najde stackoverflow. Brez branja, brez razmišljanja med odgovori na vprašanje izbere nekaj najbolj podobnega stavku »naredi to in to« (izbira takega odgovora je njegov talent, saj ni vedno tisti odgovor, ki dobi največ všečkov), velja , izgleda: če se je kaj spremenilo, potem super. Če se ni spremenil, ga vrnite nazaj. In ponovi zagon-preverjanje-iskanje. In na ta intuitiven način poskrbi, da koda čez nekaj časa deluje. Ne ve, zakaj, ne ve, kaj je naredil, ne zna razložiti. Ampak! Ta okužba deluje. In "ogenj je ugasnil." Zdaj pa ugotovimo, kaj smo naredili. Ko program deluje, je za red velikosti lažje. In prihrani veliko časa.
Ta metoda je zelo dobro razložena s tem primerom.
Nekoč je bilo zelo priljubljeno zbiranje jadrnice v steklenici. Hkrati je jadrnica velika in krhka, vrat steklenice pa je zelo ozek, nemogoče ga je potisniti v notranjost. Kako ga sestaviti?
Obstaja taka metoda, zelo hitra in zelo učinkovita.
Ladjo sestavlja kup malenkosti: palice, vrvi, jadra, lepilo. Vse to damo v steklenico.
Steklenico primemo z obema rokama in začnemo tresti. Tresemo jo in stresamo. In ponavadi se izkaže, da je seveda popolna smeti. Ampak včasih. Včasih se izkaže, da je ladja! Natančneje, nekaj podobnega ladji.
To nekaj pokažemo nekomu: "Serjoga, ali vidiš!?" In res, od daleč je videti kot ladja. Vendar se to ne sme nadaljevati.
Obstaja še en način. Uporabljajo jih naprednejši fantje, na primer hekerji.
Temu tipu sem dal nalogo, naredil je vse in odšel. In pogledaš - zdi se, kot da je končano. In čez nekaj časa, ko je treba kodo dodelati, se to začne zaradi njega ... Še dobro, da mu je že uspelo pobegniti daleč stran. To so fantje, ki bodo na primeru steklenice naredili tole: vidite, kjer je dno, se steklo upogne. In ni povsem jasno, ali je pregleden ali ne. Potem "hekerji" to dno odrežejo, tja vstavijo ladjo, potem dno spet prilepijo in je tako, kot da bi moralo biti.
Z vidika postavitve problema se zdi vse pravilno. Ampak na primeru ladij: zakaj sploh delati to ladjo, kdo jo sploh potrebuje? Ne zagotavlja nobene funkcionalnosti. Običajno so takšne ladje darilo zelo visokim ljudem, ki jih postavijo na polico nad njimi kot nekakšen simbol, kot znak. In če je taka oseba, vodja velikega podjetja ali visok uradnik, kako bo zastava stala za tak hack, ki mu je bil odrezan vrat? Bolje bi bilo, če za to nikoli ne bi vedel. Torej, kako na koncu naredijo te ladje, ki jih lahko podarijo pomembni osebi?
Edino ključno mesto, s katerim res ne morete storiti ničesar, je telo. In ladijski trup se prilega naravnost v vrat. Medtem ko je ladja sestavljena zunaj steklenice. Vendar to ni samo sestavljanje ladje, to je prava nakitna obrt. Komponentam so dodane posebne ročice, ki nato omogočajo dvig. Jadra se na primer zložijo, previdno prinesejo noter, nato pa jih s pomočjo pincete zelo natančno, natančno potegnejo in dvignejo. Rezultat je umetnina, ki jo lahko mirne vesti in ponosa podarimo.
In če želimo, da je projekt uspešen, mora biti v ekipi vsaj en draguljar. Nekdo, ki mu je mar za kakovost izdelka in upošteva vse vidike, brez odrekanja, tudi v trenutkih stresa, ko okoliščine zahtevajo, da naredimo nujno na račun pomembnega. Vsi uspešni projekti, ki so trajnostni, ki so prestali preizkus časa, so zgrajeni na tem principu. Na njih je nekaj zelo natančnega in edinstvenega, nekaj, kar izkorišča vse razpoložljive možnosti. V primeru z ladjo v steklenici se igra dejstvo, da gre trup ladje skozi vrat.
Če se vrnemo k nalogi izbire našega strežnika za predpomnjenje, kako bi lahko uporabili to metodo? Ponujam to možnost izbire med vsemi sistemi, ki obstajajo - ne stresajte steklenice, ne izbirajte, ampak poglejte, kaj načeloma imajo, na kaj morate biti pozorni pri izbiri sistema.
Kje iskati ozko grlo
Poskusimo, da ne pretresemo steklenice, da ne gremo skozi vse, kar je tam, enega za drugim, ampak poglejmo, kakšne težave se bodo pojavile, če bomo nenadoma za svojo nalogo sami oblikovali tak sistem. Kolesa seveda ne bomo sestavili, ampak si bomo s tem diagramom pomagali ugotoviti, na katere točke moramo biti pozorni pri opisih izdelkov. Narišimo takšen diagram.
Če je sistem porazdeljen, potem bomo imeli več strežnikov (6). Recimo, da so štirje (priročno jih je postaviti na sliko, seveda pa jih je lahko kolikor želite). Če so strežniki na različnih vozliščih, to pomeni, da vsi poganjajo neko kodo, ki je odgovorna za to, da ta vozlišča tvorijo gručo in se v primeru preloma med seboj povežejo in prepoznajo.
Potrebujemo tudi kodno logiko (2), pri kateri gre pravzaprav za predpomnjenje. Stranke komunicirajo s to kodo prek nekega API-ja. Odjemalska koda (1) je lahko znotraj istega JVM ali pa do nje dostopa prek omrežja. Logika, implementirana znotraj, je odločitev, katere predmete pustiti v predpomnilniku in katere vreči ven. Za shranjevanje predpomnilnika uporabljamo pomnilnik (3), po potrebi pa lahko del podatkov shranimo na disk (4).
Poglejmo, v katerih delih bo prišlo do obremenitve. Pravzaprav bo naložena vsaka puščica in vsako vozlišče. Prvič, med odjemalsko kodo in api, če je to omrežna komunikacija, je lahko pogrezanje precej opazno. Drugič, v okviru samega api-ja - če pretiravamo s kompleksno logiko, lahko naletimo na težave s procesorjem. In bilo bi lepo, če logika ne bi izgubljala časa s spominom. In ostaja interakcija z datotečnim sistemom - v običajni različici je to serializiranje / obnovitev in pisanje / branje.
Sledi interakcija z grozdom. Najverjetneje bo v istem sistemu, lahko pa ločeno. Pri tem je treba upoštevati tudi prenos podatkov vanj, hitrost serializacije podatkov in interakcije med gručo.
Sedaj si lahko po eni strani predstavljamo, »kakšna zobnika se bo vrtelo« v predpomnilniškem sistemu pri obdelavi zahtev iz naše kode, po drugi strani pa lahko ocenimo, katere in koliko zahtev bo naša koda generirala za ta sistem. To je dovolj za bolj ali manj trezno izbiro - izbiro sistema za naš primer uporabe.
lešnik
Poglejmo, kako to razgradnjo uporabiti na našem seznamu. Na primer, Hazelcast.
Za prenos/prevzem podatkov iz Hazelcast koda odjemalca dostopa do (1) API-ja. Hz omogoča zagon strežnika kot vdelanega in v tem primeru je dostop do API-ja klic metode znotraj JVM, ki se lahko šteje za brezplačno.
Da bi logika v (2) delovala, se Hz zanaša na zgoščenost niza bajtov serializiranega ključa - to pomeni, da bo ključ v vsakem primeru serializiran. To je neizogibna obremenitev za Hz.
Strategije izselitve se dobro izvajajo, vendar lahko za posebne primere dodate svojo. Za ta del vam ni treba skrbeti.
Shrambo (4) lahko priključite. Super. Interakcija (5) za vgrajene se lahko šteje za takojšnjo. Izmenjava podatkov med vozlišči v gruči (6) – ja, obstaja. To je naložba v toleranco napak na račun hitrosti. Funkcija Hz Near-cache vam omogoča znižanje cene - podatki, prejeti iz drugih vozlišč v gruči, bodo shranjeni v predpomnilniku.
Kaj storiti v takšnih razmerah za povečanje hitrosti?
Na primer, da se izognete serializaciji ključa v (2) - pripnite še en predpomnilnik na vrh Hazelcasta za najbolj vroče podatke. Sportmaster je za ta namen izbral Kofein.
Za zvijanje na ravni (6) ponuja Hz dve vrsti shranjevanja: IMap in ReplicatedMap.
Omeniti velja, kako je Hazelcast prišel v tehnološki sklop Sportmaster.
Leta 2012, ko smo delali na prvem pilotnem projektu prihodnje strani, se je prav Hazelcast izkazal za prvo povezavo, ki jo je vrnil iskalnik. Spoznavanje se je začelo "prvič" - očaralo nas je dejstvo, da je samo dve uri kasneje, ko smo Hz privili v sistem, delovalo. In dobro je delovalo. Do konca dneva smo opravili številne teste in bili zadovoljni. In ta rezerva moči je bila dovolj, da je premagal presenečenja, ki jih je Hz sčasoma povzročil. Zdaj ekipa Sportmaster nima razloga, da bi opustila Hazelcast.
Toda argumenti, kot sta "prva povezava v iskalniku" in "HelloWorld je bil hitro sestavljen", so seveda izjema in značilnost trenutka, v katerem je prišlo do izbire. Pravi testi za izbrani sistem se začnejo z izdajo v produkcijo in na tej stopnji morate biti pozorni pri izbiri katerega koli sistema, vključno s predpomnilnikom. Pravzaprav lahko v našem primeru rečemo, da smo Hazelcast izbrali po naključju, potem pa se je izkazalo, da smo izbrali pravilno.
Za proizvodnjo veliko bolj pomembno: spremljanje, obravnavanje napak na posameznih vozliščih, replikacija podatkov, stroški skaliranja. To pomeni, da je vredno biti pozoren na naloge, ki se bodo pojavile med vzdrževanjem sistema - ko je obremenitev desetkrat večja od načrtovane, ko pomotoma naložimo nekaj na napačno mesto, ko moramo uvesti novo različico kode, zamenjajte podatke in to storite neopaženo za stranke.
Za vse te zahteve Hazelcast zagotovo ustreza.
Se nadaljuje
Toda Hazelcast ni zdravilo. Leta 2017 smo za skrbniški predpomnilnik izbrali Hazelcast preprosto na podlagi dobrih vtisov iz preteklih izkušenj. To je odigralo ključno vlogo v zelo kruti šali, zaradi katere smo se znašli v težki situaciji in se iz nje »junaško« izvlekli 60 dni. A več o tem v naslednjem delu.
Medtem ... Srečna nova koda!
Vir: www.habr.com