Kako smo mi u Sportmasteru izabrali sistem za keširanje. Dio 1

Zdravo! Moje ime je Alexey Pyankov, ja sam programer u kompaniji Sportmaster. U tome pošta Ispričao sam kako je počeo rad na sajtu Sportmaster 2012. godine, koje smo inicijative uspjeli “progurati” i obrnuto, koje smo grablje prikupili.

Danas želim da podelim misli koje prate drugu temu - odabir sistema za keširanje za java backend u admin oblasti sajta. Ovaj zaplet za mene ima posebno značenje - iako se priča odvijala samo 2 mjeseca, u ovih 60 dana radili smo po 12-16 sati i bez ijednog slobodnog dana. Nikada nisam mislio niti zamišljao da je moguće tako naporno raditi.

Stoga sam podijelio tekst na 2 dijela kako ga ne bih učitao u potpunosti. Naprotiv, prvi dio će biti vrlo lagan - priprema, uvod, neka razmatranja o tome šta je keširanje. Ako ste već iskusni programer ili ste radili s kešovima, s tehničke strane najvjerovatnije neće biti ništa novo u ovom članku. Ali za juniora tako mali osvrt može mu reći u kom pravcu da gleda ako se nađe na takvoj raskrsnici.

Kada je nova verzija sajta Sportmaster puštena u proizvodnju, podaci su primljeni na način koji je, blago rečeno, bio ne baš zgodan. Osnova su bile tabele pripremljene za prethodnu verziju sajta (Bitrix), koje je trebalo uvući u ETL, dovesti u novu formu i obogatiti raznim sitnicama sa još desetak sistema. Da bi se nova slika ili opis proizvoda pojavila na stranici, morali ste čekati do sljedećeg dana - ažuriranje samo noću, jednom dnevno.

U početku je bilo toliko briga od prvih sedmica ulaska u produkciju da su takve neugodnosti za menadžere sadržaja bile sitnica. No, čim se sve posložilo, razvoj projekta je nastavljen - nekoliko mjeseci kasnije, početkom 2015., počeli smo aktivno razvijati admin panel. U 2015. i 2016. godini sve ide dobro, objavljujemo redovno, admin panel pokriva sve više priprema podataka, a mi se pripremamo da uskoro našem timu bude povjerena najvažnija i najkompleksnija stvar - proizvod sklop (potpuna priprema i održavanje podataka o svim proizvodima). Ali u ljeto 2017., neposredno prije pokretanja robnog kruga, projekt će se naći u vrlo teškoj situaciji – upravo zbog problema s keširanjem. O ovoj epizodi želim govoriti u drugom dijelu ove dvodijelne publikacije.

Ali u ovom postu ću početi izdaleka, iznijet ću neke misli - ideje o keširanju, što bi bio dobar korak za skrolovanje prije velikog projekta.

Kada se pojavi zadatak keširanja

Zadatak keširanja se ne pojavljuje samo. Mi smo programeri, pišemo softverski proizvod i želimo da bude tražen. Ako je proizvod tražen i uspješan, korisnici će doći. I dolazi sve više i više. A onda ima puno korisnika i onda proizvod postaje visoko opterećen.

U prvim fazama ne razmišljamo o optimizaciji i performansama koda. Glavna stvar je funkcionalnost, brzo pokretanje pilota i testiranje hipoteza. A ako se opterećenje poveća, pumpamo željezo. Povećamo dva ili tri puta, pet puta, možda 10 puta. Negdje ovdje - finansije to više ne dozvoljavaju. Koliko će se puta povećati broj korisnika? Neće biti kao 2-5-10, ali ako bude uspješan, bit će od 100-1000 do 100 hiljada puta. Odnosno, prije ili kasnije, morat ćete obaviti optimizaciju.

Recimo da neki dio koda (nazovimo ovaj dio funkcija) traje nepristojno dugo, a mi želimo smanjiti vrijeme izvršenja. Funkcija može biti pristup bazi podataka, ili može biti izvršavanje neke složene logike - glavna stvar je da je potrebno mnogo vremena da se završi. Koliko možete smanjiti vrijeme izvršenja? U limitu, možete ga smanjiti na nulu, ne dalje. Kako možete smanjiti vrijeme izvršenja na nulu? Odgovor: potpuno eliminirati izvršenje. Umjesto toga, odmah vratite rezultat. Kako možete saznati rezultat? Odgovor: ili izračunaj ili potraži negdje. Potrebno je mnogo vremena da se izračuna. A špijunirati znači, na primjer, zapamtiti rezultat koji je funkcija proizvela zadnji put kada je pozvana s istim parametrima.

Odnosno, implementacija funkcije nam nije bitna. Dovoljno je samo znati o kojim parametrima ovisi rezultat. Zatim, ako su vrijednosti parametara predstavljene u obliku objekta koji se može koristiti kao ključ u nekom skladištu, tada se rezultat izračuna može pohraniti i pročitati sljedeći put kada mu se pristupi. Ako je ovo pisanje i čitanje rezultata brže od izvršavanja funkcije, imamo profit u smislu brzine. Iznos profita može doseći 100, 1000 i 100 hiljada puta (10^5 je prilično izuzetak, ali u slučaju prilično zaostale baze, sasvim je moguće).

Osnovni zahtjevi za sistem keširanja

Prva stvar koja može postati uslov za sistem keširanja je velika brzina čitanja i, u nešto manjoj mjeri, brzina pisanja. To je tačno, ali samo dok sistem ne uvedemo u proizvodnju.

Hajde da igramo ovaj slučaj.

Recimo da smo trenutno opterećenje obezbedili hardverom i sada postepeno uvodimo keširanje. Broj korisnika malo raste, opterećenje raste - dodamo malo kešova, uvrnemo tu i tamo. To se nastavlja neko vrijeme, a sada se teške funkcije praktički više ne pozivaju - cijelo glavno opterećenje pada na keš memoriju. Broj korisnika tokom ovog vremena se povećao N puta.

A ako bi početna nabavka hardvera mogla biti 2-5 puta, onda bismo uz pomoć keša mogli poboljšati performanse za faktor 10 ili, u dobrom slučaju, za faktor 100, na nekim mjestima možda za faktor od 1000. Odnosno na istom hardveru – obrađujemo 100 puta više zahtjeva. Odlično, zaslužili ste medenjake!

Ali sada, u jednom lijepom trenutku, igrom slučaja, sistem se srušio i keš se srušio. Ništa posebno - na kraju krajeva, keš memorija je odabrana na osnovu zahtjeva "velika brzina čitanja i pisanja, ostalo nije važno."

U odnosu na početno opterećenje, naša rezerva gvožđa je bila 2-5 puta, a opterećenje se za to vreme povećalo 10-100 puta. Koristeći keš memoriju, eliminirali smo pozive za teške funkcije i stoga je sve funkcioniralo. A sada, bez keša, koliko puta će se naš sistem usporiti? Šta će biti sa nama? Sistem će pasti.

Čak i ako se naša keš memorija nije srušila, već je obrisana samo neko vrijeme, morat će se zagrijati, a to će potrajati. A za to vrijeme glavni teret će pasti na funkcionalnost.

Zaključak: visoko opterećeni proizvodni projekti zahtijevaju sistem keširanja ne samo da bi imao velike brzine čitanja i pisanja, već i da bi osigurao sigurnost podataka i otpornost na kvarove.

Agonija izbora

U projektu sa admin panelom izbor je išao ovako: prvo smo instalirali Hazelcast, jer Već smo bili upoznati sa ovim proizvodom iz iskustva sa glavnog sajta. Ali ovdje se ovaj izbor pokazao neuspjelim - pod našim profilom opterećenja, Hazelcast nije samo spor, već užasno spor. I u to vrijeme smo se već prijavili za datum izlaska.

Spojler: kako su se tačno razvile okolnosti da smo propustili tako veliki posao i završili u akutnoj i napetoj situaciji - reći ću vam u drugom dijelu - i kako smo završili i kako smo se izvukli. Ali sada - samo ću reći da je to bio veliki stres, i "da razmislim - nekako ne mogu da razmišljam, tresemo flašu." “Protresanje boce” je takođe spojler, o tome kasnije.

Šta smo uradili:

1. Pravimo listu svih sistema koje predlažu Google i StackOverflow. Malo preko 30
2. Pišemo testove sa opterećenjem tipičnim za proizvodnju. Da bismo to učinili, snimili smo podatke koji prolaze kroz sistem u proizvodnom okruženju - svojevrsni njuškalo za podatke ne na mreži, već unutar sistema. Upravo ti podaci su korišteni u testovima.
3. Sa cijelim timom, svi biraju sljedeći sistem sa liste, konfigurišu ga i pokreću testove. Ne prolazi test, ne nosi opterećenje - bacamo ga i prelazimo na sljedeći u redu.
4. Na 17. sistemu je postalo jasno da je sve beznadežno. Prestanite da tresete flašu, vreme je da ozbiljno razmislite.

Ali ovo je opcija kada treba da izaberete sistem koji će „proći kroz brzinu“ u unapred pripremljenim testovima. Što ako još nema takvih testova, a želite brzo izabrati?

Hajde da modeliramo ovu opciju (teško je zamisliti da srednji+ programer živi u vakuumu, a u trenutku odabira još nije formalizirao svoju sklonost prema tome koji proizvod će prvi isprobati - stoga je dalje razmišljanje više teoretičarsko/filozofsko/ o junioru).

Nakon što smo se odlučili za zahtjeve, počet ćemo birati rješenje iz kutije. Zašto ponovo izmisliti točak: otići ćemo i uzeti gotov sistem za keširanje.

Ako tek počinjete i guglate, onda dajte ili uzmite narudžbu, ali općenito, smjernice će biti ovakve. Prije svega, naići ćete na Redis, čuje se svuda. Tada ćete saznati da je EhCache najstariji i najprovjereniji sistem. U nastavku ćemo pisati o Tarantoolu, domaćem razvoju koji ima jedinstven aspekt rješenja. I Ignite, jer je sada u porastu popularnosti i uživa podršku SberTech-a. Na kraju je i Hazelcast, jer se u poslovnom svijetu često pojavljuje među velikim kompanijama.

Lista nije konačna; postoji na desetine sistema. I zeznućemo samo jednu stvar. Uzmimo odabranih 5 sistema za “takmičenje ljepote” i napravimo selekciju. Ko će biti pobjednik?

Redis

Čitamo šta pišu na zvaničnom sajtu.
Redis - opensource projekat. Nudi skladištenje podataka u memoriji, mogućnost čuvanja na disku, automatsko particioniranje, visoku dostupnost i oporavak od prekida mreže.

Čini se da je sve u redu, možete to uzeti i zeznuti - sve što vam treba, radi. Ali samo iz zabave, pogledajmo ostale kandidate.

EhCache

EhCache - „najviše korišćena keš memorija za Javu“ (prevod slogana sa službene web stranice). Takođe opensource. I onda shvatimo da Redis nije za Javu, već općenito, i za interakciju s njim potreban vam je omotač. I EhCache će biti praktičniji. Šta još sistem obećava? Pouzdanost, dokazana, puna funkcionalnost. Pa, ujedno je i najčešći. I kešira terabajte podataka.

Redis je zaboravljen, spreman sam da izaberem EhCache.

Ali osjećaj patriotizma me tjera da vidim šta je dobro u Tarantoolu.

Tarantool

Tarantool - zadovoljava oznaku “Platforma za integraciju podataka u realnom vremenu”. Zvuči vrlo komplikovano, tako da detaljno pročitamo stranicu i nađemo glasnu izjavu: “Kešira 100% podataka u RAM-u.” Ovo bi trebalo da izazove pitanja – na kraju krajeva, podataka može biti mnogo više od memorije. Objašnjenje je da to znači da Tarantool ne pokreće serijalizaciju za pisanje podataka na disk iz memorije. Umjesto toga, koristi funkcije niskog nivoa sistema, kada je memorija jednostavno mapirana u sistem datoteka sa vrlo dobrim I/O performansama. Generalno, uradili su nešto divno i cool.

Pogledajmo implementacije: Mail.ru korporativni autoput, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...

Ako još uvijek postoje sumnje u vezi s Tarantool-om, onda me slučaj implementacije u Mastercard-u dokrajči. Ja uzimam Tarantool.

Ali svejedno…

zapaliti

… ima li još zapaliti, se naplaćuje kao "računarska platforma u memoriji... brzine u memoriji na petabajtima podataka." Ovdje također postoje mnoge prednosti: distribuirana keš memorija, najbrže skladištenje ključ/vrijednost i keš memorija, horizontalno skaliranje, visoka dostupnost, strogi integritet. Općenito, ispada da je najbrži Ignite.

Implementacije: Sberbank, American Airlines, Yahoo! Japan. I onda saznam da Ignite nije implementiran samo u Sberbanku, već tim SberTecha šalje svoje ljude u sam Ignite tim da usavrše proizvod. Ovo je potpuno zadivljujuće i spreman sam da uzmem Ignite.

Potpuno je nejasno zašto, gledam na petu tačku.

hazelcast

Idem na sajt hazelcast, čitanje. I pokazalo se da je najbrže rješenje za distribuirano keširanje Hazelcast. Brži je za redove veličine od svih drugih rješenja i općenito je lider u području mreže podataka u memoriji. U tom kontekstu, uzeti nešto drugo ne znači poštovati sebe. Također koristi redundantno skladištenje podataka za kontinuirani rad klastera bez gubitka podataka.

To je to, spreman sam da uzmem Hazelcast.

Upoređivanje

Ali ako pogledate, svih pet kandidata je opisano na način da je svaki od njih najbolji. Kako odabrati? Možemo vidjeti koji je najpopularniji, potražiti poređenja i glavobolja će nestati.

Pronašli smo jedan ovakav обзор, izaberite naših 5 sistema.

Ovdje su poređani: Redis je na vrhu, Hazelcast je na drugom mjestu, Tarantool i Ignite postaju sve popularniji, EhCache je bio i ostao isti.

Ali pogledajmo metoda proračuna: linkovi na web stranice, opći interes za sistem, ponude za posao - odlično! Odnosno, kada mi sistem pokvari, reći ću: „Ne, pouzdan je! Ima mnogo ponuda za posao..." Ovakvo jednostavno poređenje neće raditi.

Svi ovi sistemi nisu samo sistemi za keširanje. Imaju i dosta funkcionalnosti, uključujući kada se podaci ne upumpavaju klijentu na obradu, već obrnuto: kod koji treba da se izvrši na podacima prelazi na server, tamo se izvršava i rezultat se vraća. I ne smatraju se tako često zasebnim sistemom za keširanje.

Dobro, nemojmo odustati, nađimo direktno poređenje sistema. Uzmimo dvije gornje opcije - Redis i Hazelcast. Nas zanima brzina i uporedićemo ih na osnovu ovog parametra.

Hz vs Redis

Nalazimo ovo poređenje:


Plava je Redis, crvena je Hazelcast. Hazelcast pobjeđuje posvuda, i postoji razlog za to: višenit je, visoko optimiziran, svaka nit radi sa svojom particijom, tako da nema blokiranja. A Redis je jednonitni; nema koristi od modernih višejezgrenih CPU-a. Hazelcast ima asinhroni I/O, Redis-Jedis ima blokirajuće utičnice. Na kraju krajeva, Hazelcast koristi binarni protokol, a Redis je usmjeren na tekst, što znači da je neefikasan.

Za svaki slučaj, okrenimo se drugom izvoru poređenja. Šta će nam pokazati?

Redis vs Hz

Još jedan poređenje:


Ovdje je, naprotiv, crvena Redis. To jest, Redis nadmašuje Hazelcast u pogledu performansi. Hazelcast je pobijedio u prvom poređenju, Redis u drugom. Upravo ovdje je vrlo precizno objasnio zašto je Hazelcast pobijedio u prethodnom poređenju.

Ispostavilo se da je rezultat prvog zapravo bio namješten: Redis je uzet u osnovnoj kutiji, a Hazelcast je skrojen za testni slučaj. Onda se ispostavi: prvo, ne možemo nikome vjerovati, a drugo, kada konačno odaberemo sistem, još uvijek ga moramo ispravno konfigurirati. Ove postavke uključuju desetine, gotovo stotine parametara.

Protresanje boce

A cijeli proces koji smo sada obavili mogu objasniti sljedećom metaforom: “Protresanje boce”. Odnosno, sada ne morate programirati, sada je glavna stvar moći čitati stackoverflow. A u svom timu imam osobu, profesionalca, koja upravo ovako radi u kritičnim trenucima.

Šta on radi? On vidi pokvarenu stvar, vidi stack trace, uzima neke riječi iz nje (koje su njegove ekspertize u programu), traži na Google-u, pronalazi stackoverflow među odgovorima. Bez čitanja, bez razmišljanja, među odgovorima na pitanje bira nešto najsličnije rečenici „uradi to i to“ (odabir takvog odgovora je njegov talenat, jer nije uvijek odgovor koji dobije najviše lajkova), primjenjuje, izgleda: ako se nešto promijenilo, onda odlično. Ako se nije promijenio, vratite ga. I ponovite pokretanje-provjera-pretraga. I na ovaj intuitivan način osigurava da kod radi nakon nekog vremena. Ne zna zašto, ne zna šta je uradio, ne zna da objasni. Ali! Ova infekcija djeluje. I "vatra je ugašena." Hajde sada da shvatimo šta smo uradili. Kada program radi, to je za red veličine lakše. I štedi puno vremena.

Ova metoda je vrlo dobro objašnjena na ovom primjeru.

Nekada je bilo veoma popularno sakupljati jedrilicu u boci. U isto vrijeme, jedrilica je velika i krhka, a vrat boce je vrlo uzak, nemoguće ga je ugurati unutra. Kako ga sastaviti?

Postoji takva metoda, vrlo brza i vrlo efikasna.

Brod se sastoji od gomile sitnica: štapova, užadi, jedara, ljepila. Sve ovo stavljamo u flašu.
Uzimamo bocu objema rukama i počinjemo tresti. Drmamo je i drmamo. I obično ispadne potpuno smeće, naravno. Ali ponekad. Ponekad se ispostavi da je to brod! Tačnije, nešto slično brodu.

Nekome pokazujemo ovo: "Serjoga, vidiš li!?" I zaista, izdaleka izgleda kao brod. Ali ne može se dozvoliti da se ovo nastavi.

Postoji još jedan način. Koriste ih napredniji momci, poput hakera.

Dao sam ovom tipu zadatak, uradio je sve i otišao. A ti gledaš - izgleda kao da je gotovo. I nakon nekog vremena, kada kod treba da se finalizira, ovo počinje zbog njega... Dobro je da je već uspio pobjeći daleko. Ovo su momci koji će na primjeru flaše uraditi ovo: vidite, gdje je dno, staklo se savija. I nije sasvim jasno da li je transparentan ili ne. Onda "hakeri" odseku ovo dno, ubace brod, pa ponovo zalepe dno i kao da tako treba da bude.

Sa stanovišta postavljanja problema, čini se da je sve ispravno. Ali koristeći brodove kao primjer: zašto uopće praviti ovaj brod, kome on uopće treba? Ne pruža nikakvu funkcionalnost. Obično su takvi brodovi pokloni vrlo visokim ljudima, koji ih stave na policu iznad sebe, kao nekakav simbol, kao znak. A ako takva osoba, šef velikog biznisa ili visoki funkcioner, kako će zastava predstavljati takav hak kojem je odsječen vrat? Bilo bi bolje da nikad nije znao za to. Pa, kako na kraju naprave ove brodove koji se mogu dati važnoj osobi?

Jedino ključno mjesto na kojem zaista ne možete ništa učiniti je tijelo. A trup broda stane pravo u vrat. Dok se brod sklapa izvan boce. Ali to nije samo sastavljanje broda, to je pravi zanat od nakita. Komponentama se dodaju posebne poluge koje zatim omogućavaju njihovo podizanje. Na primjer, jedra se sklapaju, pažljivo unose unutra, a zatim se uz pomoć pincete povlače i podižu vrlo precizno, precizno. Rezultat je umjetničko djelo koje se može podariti čistom savješću i ponosom.

A ako želimo da projekat bude uspješan, u timu mora biti barem jedan zlatar. Neko kome je stalo do kvaliteta proizvoda i vodi računa o svim aspektima, ne žrtvujući ništa, čak ni u trenucima stresa, kada okolnosti zahtevaju da se uradi hitno nauštrb važnog. Svi uspješni projekti koji su održivi, ​​koji su izdržali test vremena, izgrađeni su na ovom principu. U njima postoji nešto vrlo precizno i ​​jedinstveno, nešto što koristi sve raspoložive mogućnosti. U primjeru s brodom u boci, igra se činjenica da trup broda prolazi kroz vrat.

Vraćajući se na zadatak odabira našeg servera za keširanje, kako se ovaj metod može primijeniti? Nudim ovu opciju izbora između svih sistema koji postoje - ne tresite flašu, ne birajte, već pogledajte šta u principu imaju, na šta treba obratiti pažnju pri izboru sistema.

Gdje tražiti usko grlo

Pokušajmo da ne protresemo bocu, da ne prolazimo kroz sve što postoji jedan po jedan, ali da vidimo koji će problemi nastati ako odjednom, za naš zadatak, sami dizajniramo takav sistem. Naravno, nećemo sastavljati bicikl, ali ćemo koristiti ovaj dijagram da nam pomogne da shvatimo na koje točke treba obratiti pažnju u opisima proizvoda. Hajde da skiciramo takav dijagram.

Ako je sistem distribuiran, onda ćemo imati nekoliko servera (6). Recimo da ih ima četiri (zgodno je postaviti ih na sliku, ali, naravno, može ih biti koliko god želite). Ako su serveri na različitim čvorovima, to znači da svi pokreću neki kod koji je odgovoran da osigura da ovi čvorovi formiraju klaster i da se, u slučaju prekida, povežu i prepoznaju jedni druge.

Potrebna nam je i logika koda (2), koja se zapravo odnosi na keširanje. Klijenti komuniciraju s ovim kodom preko nekog API-ja. Klijentski kod (1) može biti ili unutar istog JVM-a ili mu pristupiti preko mreže. Logika implementirana unutra je odluka koje objekte ostaviti u kešu, a koje izbaciti. Koristimo memoriju (3) za pohranjivanje keš memorije, ali ako je potrebno, možemo pohraniti dio podataka na disk (4).

Da vidimo u kojim će dijelovima doći do opterećenja. Zapravo, svaka strelica i svaki čvor će biti učitani. Prvo, između klijentskog koda i API-ja, ako je riječ o mrežnoj komunikaciji, slijeganje može biti prilično primjetno. Drugo, u okviru samog API-ja - ako pretjeramo sa složenom logikom, možemo naići na probleme sa CPU-om. I bilo bi lijepo da logika ne gubi vrijeme na pamćenje. I ostaje interakcija sa datotečnim sistemom - u uobičajenoj verziji ovo je serijalizacija / vraćanje i pisanje / čitanje.

Sljedeća je interakcija sa klasterom. Najvjerovatnije će biti u istom sistemu, ali može biti odvojeno. Ovdje također morate uzeti u obzir prijenos podataka na njega, brzinu serijalizacije podataka i interakcije između klastera.

Sada, s jedne strane, možemo zamisliti “koji će se zupčanici okretati” u keš sistemu prilikom obrade zahtjeva iz našeg koda, a s druge strane možemo procijeniti koje će i koliko zahtjeva naš kod generirati ovom sistemu. Ovo je dovoljno da napravimo manje-više trezven izbor – da odaberemo sistem za naš slučaj upotrebe.

hazelcast

Pogledajmo kako primijeniti ovu dekompoziciju na našu listu. Na primjer, Hazelcast.

Da bi stavio/uzeo podatke iz Hazelcasta, klijentski kod pristupa (1) API-ju. Hz vam omogućava da pokrenete server kao ugrađen, a u ovom slučaju, pristup API-ju je poziv metode unutar JVM-a, koji se može smatrati besplatnim.

Da bi logika u (2) funkcionirala, Hz se oslanja na heš niza bajtova serijaliziranog ključa - to jest, ključ će u svakom slučaju biti serijaliziran. Ovo su neizbježni troškovi za Hz.
Strategije deložacije su dobro implementirane, ali za posebne slučajeve možete dodati svoje. Ne morate brinuti o ovom dijelu.

Skladište (4) se može spojiti. Odlično. Interakcija (5) za embedded može se smatrati trenutnom. Razmjena podataka između čvorova u klasteru (6) - da, postoji. Ovo je ulaganje u toleranciju grešaka na račun brzine. Hz funkcija Near-cache omogućava vam da smanjite cijenu - podaci primljeni od drugih čvorova u klasteru će biti keširani.

Šta se u takvim uslovima može učiniti da se brzina poveća?

Na primjer, da biste izbjegli serijalizaciju ključa u (2) - prikačite još jednu keš memoriju na Hazelcast, za najtoplije podatke. Sportmaster je u tu svrhu odabrao kofein.

Za uvijanje na nivou (6), Hz nudi dva tipa skladištenja: IMAp i ReplicatedMap.


Vrijedi spomenuti kako je Hazelcast ušao u tehnološku grupu Sportmaster.

2012. godine, kada smo radili na prvom pilotu buduće stranice, Hazelcast se pokazao kao prva veza koju je pretraživač vratio. Poznanstvo je počelo "prvi put" - bili smo očarani činjenicom da je samo dva sata kasnije, kada smo uvrnuli Hz u sistem, proradio. I dobro je funkcionisalo. Do kraja dana smo završili niz testova i bili smo zadovoljni. I ova rezerva snage bila je dovoljna da savlada iznenađenja koja je Hz bacio tokom vremena. Sada Sportmaster tim nema razloga da napusti Hazelcast.

Ali takvi argumenti kao što su „prva veza u pretraživaču“ i „HelloWorld je brzo sastavljena“ su, naravno, izuzetak i karakteristika trenutka u kojem je došlo do izbora. Pravi testovi za odabrani sistem počinju puštanjem u proizvodnju i upravo u ovoj fazi treba obratiti pažnju pri odabiru bilo kojeg sistema, uključujući keš memoriju. Zapravo, u našem slučaju možemo reći da smo slučajno odabrali Hazelcast, ali se onda pokazalo da smo odabrali ispravno.

Za proizvodnju, mnogo važnije: praćenje, rukovanje kvarovima na pojedinačnim čvorovima, replikacija podataka, troškovi skaliranja. Odnosno, vrijedi obratiti pažnju na zadatke koji će se pojaviti tokom održavanja sistema - kada je opterećenje desetine puta veće od planiranog, kada slučajno učitamo nešto na pogrešno mjesto, kada trebamo izbaciti novu verziju koda, zamijenite podatke i učinite to neprimjetno za klijente.

Za sve ove zahtjeve, Hazelcast svakako odgovara.

Nastavlja se

Ali Hazelcast nije panaceja. U 2017. smo odabrali Hazelcast za admin keš, jednostavno na osnovu dobrih utisaka iz prošlog iskustva. To je odigralo ključnu ulogu u veoma okrutnoj šali, zbog koje smo se našli u teškoj situaciji i “herojski” izlazili iz nje 60 dana. Ali o tome više u sljedećem dijelu.

U međuvremenu... Sretan novi kod!

izvor: www.habr.com