Zdravo! Moje ime je Alexey Pyankov, ja sam programer u tvrtki Sportmaster. U tome Ispričao sam kako je 2012. počeo rad na web stranici Sportmaster, koje smo inicijative uspjeli “progurati” i obrnuto, koje smo rake skupili.
Danas želim podijeliti razmišljanja koja prate drugu temu - odabir sustava predmemoriranja za Java pozadinu u administratorskom području stranice. Ovaj zaplet za mene ima posebno značenje - iako se priča odvijala samo 2 mjeseca, u tih 60 dana radili smo 12-16 sati i bez ijednog slobodnog dana. Nikada nisam mislio niti zamišljao da je moguće toliko raditi.
Stoga sam tekst podijelio na 2 dijela da ga ne opterećujem do kraja. Naprotiv, prvi dio će biti vrlo lagan - priprema, uvod, neka razmatranja o tome što je caching. Ako ste već iskusni programer ili ste radili s predmemorijama, s tehničke strane u ovom članku najvjerojatnije neće biti ništa novo. Ali junioru tako mali pregled može reći u kojem smjeru treba gledati ako se nađe na takvom raskrižju.
Prilikom puštanja u produkciju nove verzije portala Sportmaster podaci su zaprimljeni na, blago rečeno, ne baš zgodan način. Osnova su bile tablice pripremljene za prethodnu verziju stranice (Bitrix) koje je trebalo uvući u ETL, dovesti u novi oblik i obogatiti raznim sitnicama iz još desetak sustava. Da bi se nova slika ili opis proizvoda pojavio na stranici, morali ste čekati sljedeći dan - ažuriranja samo noću, jednom dnevno.
Isprva je od prvih tjedana ulaska u produkciju bilo toliko briga da su takve neugodnosti za content managere 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 u najboljem redu, redovito objavljujemo, admin panel pokriva sve veći dio pripreme podataka, a mi se pripremamo da će uskoro našem timu biti povjerena najvažnija i najsloženija stvar - proizvod krug (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 predmemorijom. O ovoj epizodi želim govoriti u drugom dijelu ove dvodijelne publikacije.
Ali u ovom ću postu krenuti izdaleka, iznijet ću neke misli - ideje o predmemoriranju, što bi bio dobar korak za listanje prije velikog projekta.
Kada se dogodi zadatak predmemoriranja
Zadatak predmemoriranja ne pojavljuje se 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 ih sve više i više. A onda ima puno korisnika i onda proizvod postaje jako opterećen.
U prvim fazama ne razmišljamo o optimizaciji i izvedbi koda. Glavna stvar je funkcionalnost, brzo pokretanje pilota i testiranje hipoteza. A ako se opterećenje poveća, pumpamo željezo. Povećavamo dva ili tri puta, pet puta, možda 10 puta. Negdje ovdje - financije to više ne dopuštaju. Koliko puta će se povećati broj korisnika? Neće biti kao 2-5-10, ali ako bude uspješno, bit će od 100-1000 do 100 tisuća puta. Odnosno, prije ili kasnije, morat ćete napraviti optimizaciju.
Recimo da neki dio koda (nazovimo taj dio funkcijom) 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 - glavno je da je potrebno puno vremena da se završi. Koliko možete smanjiti vrijeme izvršenja? U ograničenju, možete ga smanjiti na nulu, ne dalje. Kako možete smanjiti vrijeme izvršenja na nulu? Odgovor: potpuno ukinuti ovrhu. Umjesto toga, odmah vratite rezultat. Kako možete saznati rezultat? Odgovor: ili izračunajte ili potražite negdje. Dugo se rač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 nekoj pohrani, tada se rezultat izračuna može spremiti 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 dobiti može doseći 100, 1000 i 100 tisuća puta (10^5 je prilično iznimka, ali u slučaju prilično zaostale baze, sasvim je moguće).
Osnovni zahtjevi za sustav za predmemoriju
Prva stvar koja može postati zahtjev za sustav predmemoriranja je velika brzina čitanja i, u nešto manjoj mjeri, brzina pisanja. To je istina, ali samo dok sustav ne pustimo u proizvodnju.
Pustimo ovaj slučaj.
Recimo da smo hardverom osigurali trenutno opterećenje i sada postupno uvodimo caching. Malo raste broj korisnika, raste opterećenje - dodamo malo predmemorije, zašrafimo 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 predmemoriju. Broj korisnika za to vrijeme povećao se N puta.
A ako bi početna opskrba hardverom mogla biti 2-5 puta veća, tada bismo uz pomoć predmemorije 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. Super, zaslužili ste medenjake!
Ali sada, u jednom lijepom trenutku, slučajno, sustav se srušio i predmemorija se srušila. Ništa posebno - uostalom, predmemorija je odabrana na temelju zahtjeva "visoka brzina čitanja i pisanja, ostalo nije važno."
U odnosu na početno opterećenje, naša rezerva željeza bila je 2-5 puta, a opterećenje se za to vrijeme povećalo 10-100 puta. Korištenjem predmemorije eliminirali smo pozive za teške funkcije i stoga je sve radilo. I sada, bez predmemorije, koliko puta će se naš sustav usporiti? Što će biti s nama? Sustav će pasti.
Čak i ako nam se predmemorija nije srušila, nego je bila samo neko vrijeme očišćena, trebat će je zagrijati, a to će potrajati neko vrijeme. I za to vrijeme, glavni teret će pasti na funkcionalnost.
Zaključak: visoko opterećeni proizvodni projekti zahtijevaju sustav predmemoriranja ne samo da ima velike brzine čitanja i pisanja, već i da osigura sigurnost podataka i otpornost na kvarove.
Agonija izbora
U projektu s admin panelom izbor je išao ovako: prvo smo instalirali Hazelcast, jer Već smo bili upoznati s ovim proizvodom iz iskustva s glavne stranice. Ali ovdje se ovaj izbor pokazao neuspješnim - pod našim profilom opterećenja, Hazelcast nije samo spor, već užasno spor. A u to vrijeme smo se već bili prijavili za datum izlaska.
Spoiler: kako su se točno okolnosti razvile da smo propustili tako veliki posao i završili s akutnom i napetom situacijom - 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 razmišljam - nekako ne mogu razmišljati, mućkamo bocu." "Protresanje boce" također je spojler, više o tome kasnije.
Što smo učinili:
- Pravimo popis svih sustava koje predlažu Google i StackOverflow. Nešto više od 30
- Pišemo testove s opterećenjem tipičnim za proizvodnju. Da bismo to učinili, zabilježili smo podatke koji prolaze kroz sustav u produkcijskom okruženju - svojevrsnom njuškalu za podatke ne na mreži, već unutar sustava. Upravo su ti podaci korišteni u testovima.
- S cijelim timom svatko odabire sljedeći sustav s popisa, konfigurira ga i pokreće testove. Ne prolazi test, ne nosi teret - bacamo ga i prelazimo na sljedeći na redu.
- 17. sustava postalo je jasno da je sve beznadno. Prestanite tresti bocu, vrijeme je da ozbiljno razmislite.
Ali ovo je opcija kada trebate odabrati sustav koji će se “progurati na brzinu” u unaprijed pripremljenim testovima. Što ako još nema takvih testova, a želite brzo odabrati?
Modelirajmo ovu opciju (teško je zamisliti da srednji+ programer živi u vakuumu, au trenutku odabira još nije formalizirao svoju preferenciju koji će proizvod prvi isprobati - stoga je daljnje razmišljanje više teoretičar/filozofija/ o junioru).
Odlučivši se o zahtjevima, počet ćemo birati rješenje iz okvira. Zašto izmišljati kotač: otići ćemo i uzeti gotov sustav predmemoriranja.
Ako tek počinjete i guglate, onda dajte ili uzmite nalog, ali općenito, smjernice će biti ovakve. Prije svega, naići ćete na Redis, čuje se na sve strane. Tada ćete saznati da je EhCache najstariji i najprovjereniji sustav. Zatim ćemo pisati o Tarantoolu, domaćem razvoju koji ima jedinstven aspekt rješenja. I također Ignite, jer je sada u porastu popularnosti i uživa podršku SberTecha. Na kraju tu je i Hazelcast, jer se u poslovnom svijetu često pojavljuje među velikim tvrtkama.
Popis nije konačan; postoje deseci sustava. I zeznut ćemo samo jednu stvar. Uzmimo odabranih 5 sustava za “natjecanje ljepote” i napravimo odabir. Tko će biti pobjednik?
Redis
Čitamo što pišu na službenim stranicama.
- opensource projekt. Nudi pohranu podataka u memoriji, mogućnost spremanja na disk, automatsko particioniranje, visoku dostupnost i oporavak od prekida mreže.
Čini se da je sve u redu, možete ga uzeti i zavrnuti - sve što trebate, radi. Ali samo zabave radi, pogledajmo ostale kandidate.
EhCache
- “najčešće korištena predmemorija za Javu” (prijevod slogana sa službene web stranice). Također opensource. I onda shvaćamo da Redis nije za Javu, već općenito, a za interakciju s njim potreban vam je omot. I EhCache će biti praktičniji. Što još sustav obećava? Pouzdanost, dokazano, puna funkcionalnost. Pa, to je i najčešće. I sprema terabajte podataka.
Redis je zaboravljen, spreman sam odabrati EhCache.
Ali osjećaj patriotizma tjera me da vidim što je dobro u Tarantoolu.
Tarantool
- ispunjava oznaku “Platforma za integraciju podataka u stvarnom vremenu”. Zvuči vrlo komplicirano, pa detaljno čitamo stranicu i nalazimo glasnu izjavu: “Kešira 100% podataka u RAM.” Ovo bi trebalo pokrenuti pitanja - na kraju krajeva, podataka može biti puno 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 značajke niske razine sustava, kada se memorija jednostavno preslikava na datotečni sustav s vrlo dobrim I/O performansama. Općenito, napravili su nešto divno i cool.
Pogledajmo implementacije: Mail.ru korporativna autocesta, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...
Ako je još bilo ikakvih nedoumica oko Tarantoola, onda me slučaj implementacije u Mastercardu dokrajčio. Uzimam Tarantool.
Ali svejedno…
Zapaliti
…ima li još nešto , naplaćuje se kao "in-memory računalna platforma...in-memory brzine na petabajtima podataka." Ovdje također postoje mnoge prednosti: distribuirana predmemorija u memoriji, najbrža pohrana ključeva i predmemorija, 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 samo implementiran u Sberbanku, nego SberTech tim šalje svoje ljude u sam Ignite tim da dorade proizvod. Ovo je potpuno zadivljujuće i spreman sam preuzeti Ignite.
Potpuno je nejasno zašto, gledam petu točku.
lješnjak
idem na stranicu , čitanje. I ispada da je najbrže rješenje za distribuirano predmemoriranje Hazelcast. Za red veličine je brži od svih drugih rješenja i općenito je vodeći u području podatkovne mreže u memoriji. U tom kontekstu, uzeti nešto drugo ne poštuje sebe. Također koristi redundantnu pohranu podataka za kontinuirani rad klastera bez gubitka podataka.
To je to, spreman sam preuzeti Hazelcast.
usporedba
Ali ako pogledate, svih pet kandidata opisano je tako da je svaki od njih najbolji. Kako odabrati? Možemo vidjeti koji je najpopularniji, potražiti usporedbe i glavobolja će nestati.
Nalazimo jednu ovakvu , odaberite naših 5 sustava.
Ovdje su poredani: Redis je na vrhu, Hazelcast je na drugom mjestu, Tarantool i Ignite dobivaju popularnost, EhCache je bio i ostao isti.
Ali pogledajmo : poveznice na web stranice, opće zanimanje za sustav, ponude poslova - super! Odnosno, kad moj sustav zakaže, reći ću: "Ne, pouzdan je! Mnogo je ponuda za posao..." Takva jednostavna usporedba neće poslužiti.
Svi ovi sustavi nisu samo sustavi za predmemoriju. Također imaju puno funkcionalnosti, uključujući slučajeve kada se podaci ne upumpavaju klijentu radi obrade, već obrnuto: kod koji se treba izvršiti na podacima seli na poslužitelj, tamo se izvršava i rezultat se vraća. I ne smatraju se tako često zasebnim sustavom za predmemoriju.
U redu, nemojmo odustati, idemo pronaći izravnu usporedbu sustava. Uzmimo prve dvije opcije - Redis i Hazelcast. Zanima nas brzina, pa ćemo ih uspoređivati na temelju tog parametra.
Hz protiv Redisa
Nalazimo ovo :
Plava je Redis, crvena je Hazelcast. Hazelcast posvuda pobjeđuje, a za to postoji razlog: višenitni je, visoko optimiziran, svaka nit radi sa svojom particijom, tako da nema blokiranja. A Redis je jednonitni; nema koristi od modernih višejezgrenih procesora. Hazelcast ima asinkroni I/O, Redis-Jedis ima blokirajuće utičnice. Uostalom, Hazelcast koristi binarni protokol, a Redis je tekstualno usmjeren, što znači da je neučinkovit.
Za svaki slučaj, okrenimo se drugom izvoru usporedbe. Što će nam pokazati?
Redis protiv Hz
Još :
Ovdje je, naprotiv, crveno Redis. Odnosno, Redis nadmašuje Hazelcast u pogledu performansi. Hazelcast je pobijedio u prvoj usporedbi, Redis u drugoj. vrlo precizno objasnio zašto je Hazelcast pobijedio u prethodnoj usporedbi.
Ispostavilo se da je rezultat prvog zapravo bio namješten: Redis je uzet u osnovnoj kutiji, a Hazelcast je prilagođen za testni slučaj. Tada se ispostavlja: prvo, nikome ne možemo vjerovati, a drugo, kada konačno odaberemo sustav, još ga moramo ispravno konfigurirati. Ove postavke uključuju desetke, gotovo stotine parametara.
Protresajući bocu
I mogu objasniti cijeli proces koji smo sada napravili sljedećom metaforom: "Protresanje boce." Odnosno, sada ne morate programirati, sada je glavna stvar moći čitati stackoverflow. A ja u svom timu imam osobu, profesionalca, koja upravo tako radi u kritičnim trenucima.
Što on radi? Vidi pokvarenu stvar, vidi stack trace, uzme neke riječi iz toga (koje su njegova ekspertiza u programu), traži na Googleu, nađe stackoverflow među odgovorima. Bez čitanja, bez razmišljanja, među odgovorima na pitanje bira nešto što je najsličnije rečenici „učini to i to“ (odabrati takav odgovor njegov je talent, jer nije uvijek taj odgovor dobio najviše lajkova), primjenjuje se , izgleda: ako se nešto promijenilo, onda super. Ako se nije promijenio, vratite ga. I ponovi pokretanje-provjera-pretraga. I na ovaj intuitivan način osigurava da kod nakon nekog vremena radi. Ne zna zašto, ne zna što je učinio, ne zna objasniti. Ali! Ova infekcija djeluje. I "vatra je ugašena." Sada shvatimo što smo učinili. Kada program radi, to je red veličine lakše. I štedi puno vremena.
Ova metoda je vrlo dobro objašnjena ovim primjerom.
Nekada je bilo vrlo popularno skupljati jedrilicu u bocu. U isto vrijeme, jedrilica je velika i krhka, a vrat boce je vrlo uzak, nemoguće ga je gurnuti unutra. Kako ga sastaviti?
Postoji takva metoda, vrlo brza i vrlo učinkovita.
Brod se sastoji od gomile sitnica: štapova, konopa, jedara, ljepila. Sve to stavimo u bocu.
Uzimamo bocu objema rukama i počinjemo tresti. Tresemo je i tresemo. I obično ispadne potpuno smeće, naravno. Ali ponekad. Ponekad se ispostavi da je to brod! Točnije, nešto slično brodu.
Ovo nešto pokazujemo nekome: "Serjoga, vidiš li!?" I doista, izdaleka izgleda kao brod. Ali to se ne može nastaviti.
Postoji još jedan način. Koriste ih napredniji tipovi, poput hakera.
Dao sam ovom momku zadatak, on je sve napravio i otišao. I pogledate - izgleda kao da je gotovo. I nakon nekog vremena, kad treba šifru doraditi, ovo počinje zbog njega... Dobro da je već uspio daleko pobjeći. To su tipovi koji će na primjeru boce napraviti ovo: vidite, gdje je dno, staklo se savija. I nije sasvim jasno je li transparentan ili ne. Onda “hakeri” odrežu ovo dno, ubace brod, pa opet zalijepe dno i kao da tako treba biti.
Sa stajališta postavljanja problema sve se čini točnim. Ali na primjeru brodova: čemu uopće praviti ovaj brod, kome on uopće treba? Ne pruža nikakvu funkcionalnost. Obično su takvi brodovi darovi ljudima na visokom položaju, koji ih stavljaju na policu iznad sebe, kao nekakav simbol, kao znak. A ako je takva osoba, šef velikog poduzeća ili visoki dužnosnik, kako će zastava stajati za takav hack, čiji je vrat odrezan? Bilo bi bolje da nikad ne sazna za to. Dakle, kako na kraju naprave te brodove koji se mogu dati važnoj osobi?
Jedino ključno mjesto s kojim zapravo ne možete ništa učiniti je tijelo. I trup broda stane točno u vrat. Dok se brod sastavlja izvan boce. Ali to nije samo sastavljanje broda, to je pravi draguljarski zanat. Komponentama se dodaju posebne poluge koje zatim omogućuju njihovo podizanje. Recimo, jedra se sklope, pažljivo unesu unutra, a zatim se uz pomoć pincete povuku i podignu vrlo precizno, precizno. Rezultat je umjetničko djelo koje se može darovati mirne savjesti i ponosa.
A ako želimo da projekt bude uspješan, u timu mora biti barem jedan draguljar. Netko tko brine o kvaliteti proizvoda i vodi računa o svim aspektima, ne žrtvujući ništa, čak ni u trenucima stresa, kada okolnosti zahtijevaju da se učini 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. Postoji nešto vrlo precizno i jedinstveno u njima, nešto što iskorištava sve dostupne mogućnosti. U primjeru s brodom u boci igra se činjenica da trup broda prolazi kroz grlić.
Vraćajući se na zadatak odabira našeg poslužitelja za predmemoriju, kako se ova metoda može primijeniti? Nudim ovu mogućnost izbora od svih sustava koji postoje - ne tresti bocu, ne birati, nego pogledati što imaju u principu, na što treba obratiti pozornost pri izboru sustava.
Gdje tražiti usko grlo
Pokušajmo ne tresti bocu, ne prolaziti kroz sve što je tamo jedno po jedno, ali da vidimo koji će problemi nastati ako odjednom, za naš zadatak, sami dizajniramo takav sustav. Naravno, nećemo sastaviti bicikl, ali ćemo koristiti ovaj dijagram da nam pomogne shvatiti na koje točke treba obratiti pozornost u opisu proizvoda. Nacrtajmo takav dijagram.
Ako je sustav distribuiran, tada ćemo imati nekoliko servera (6). Recimo da ih ima četiri (prikladno ih je staviti na sliku, ali, naravno, može ih biti koliko god želite). Ako su poslužitelji na različitim čvorovima, to znači da svi pokreću neki kod koji je odgovoran da ti čvorovi tvore klaster i da se u slučaju prekida međusobno povežu i prepoznaju.
Potrebna nam je i logika koda (2), koja se zapravo odnosi na predmemoriju. Klijenti komuniciraju s ovim kodom putem nekog API-ja. Kôd klijenta (1) može biti unutar istog JVM-a ili mu pristupiti preko mreže. Logika implementirana unutra je odluka koje objekte ostaviti u predmemoriji, a koje izbaciti. Za pohranjivanje predmemorije koristimo memoriju (3), ali ako je potrebno, neke podatke možemo spremiti na disk (4).
Pogledajmo u kojim dijelovima će se pojaviti opterećenje. Zapravo će se učitati svaka strelica i svaki čvor. Prvo, između koda klijenta i API-ja, ako je ovo mrežna komunikacija, popuštanje može biti prilično vidljivo. Drugo, u okviru samog api-ja - ako pretjeramo sa složenom logikom, možemo naići na probleme s CPU-om. I bilo bi lijepo da logika ne gubi vrijeme na pamćenje. I ostaje interakcija s datotečnim sustavom - u uobičajenoj verziji to je serijalizacija / vraćanje i pisanje / čitanje.
Sljedeća je interakcija s klasterom. Najvjerojatnije će biti u istom sustavu, ali može i zasebno. Ovdje također morate uzeti u obzir prijenos podataka u njega, brzinu serijalizacije podataka i interakcije između klastera.
Sada, s jedne strane, možemo zamisliti “kakvi će se zupčanici okretati” u cache sustavu prilikom obrade zahtjeva našeg koda, a s druge strane, možemo procijeniti koje će i koliko zahtjeva naš kod generirati ovom sustavu. Ovo je dovoljno da donesemo koliko-toliko trezven izbor - da odaberemo sustav za naš slučaj upotrebe.
lješnjak
Pogledajmo kako primijeniti ovu dekompoziciju na naš popis. Na primjer, Hazelcast.
Kako bi stavio/uzeo podatke iz Hazelcasta, kod klijenta pristupa (1) API-ju. Hz vam omogućuje pokretanje poslužitelja kao ugrađenog, au ovom slučaju pristup API-ju je poziv metode unutar JVM-a, što se može smatrati besplatnim.
Da bi logika u (2) radila, Hz se oslanja na hash 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 dobro se provode, ali za posebne slučajeve možete dodati vlastitu. Ne morate brinuti o ovom dijelu.
Spremište (4) se može spojiti. Sjajno. Interakcija (5) za ugrađene se može smatrati trenutnom. Razmjena podataka između čvorova u klasteru (6) - da, postoji. Ovo je ulaganje u toleranciju na pogreške nauštrb brzine. Hz značajka Near-cache omogućuje vam smanjenje cijene - podaci primljeni od drugih čvorova u klasteru bit će predmemorirani.
Što se u takvim uvjetima može učiniti da se poveća brzina?
Na primjer, da biste izbjegli serijalizaciju ključa u (2) - priložite drugu predmemoriju na vrh Hazelcasta, za najtoplije podatke. Sportmaster je za ovu svrhu odabrao Kofein.
Za uvijanje na razini (6), Hz nudi dvije vrste pohrane: IMap i ReplicatedMap.
Vrijedno je spomenuti kako je Hazelcast ušao u Sportmaster tehnologiju.
Godine 2012., kada smo radili na prvom pilotu buduće stranice, upravo se Hazelcast pokazao kao prva poveznica koju je tražilica vratila. Upoznavanje je krenulo “iz prve” - fasciniralo nas je da je samo dva sata kasnije, kad smo uvrnuli Hz u sustav, proradio. I dobro je funkcioniralo. Do kraja dana obavili smo brojne testove i bili smo zadovoljni. I ta rezerva snage bila je dovoljna da nadvlada iznenađenja koja je Hz s vremenom priredio. Sada tim Sportmaster nema razloga napustiti Hazelcast.
Ali takvi argumenti kao što su "prva poveznica u tražilici" i "HelloWorld je brzo sastavljen" su, naravno, iznimka i obilježje trenutka u kojem se izbor dogodio. Pravi testovi za odabrani sustav počinju s puštanjem u proizvodnju, au ovoj fazi treba obratiti pozornost pri odabiru bilo kojeg sustava, uključujući i predmemoriju. Zapravo, u našem slučaju možemo reći da smo slučajno odabrali Hazelcast, no onda se pokazalo da smo odabrali ispravno.
Za proizvodnju, puno važnije: praćenje, rukovanje kvarovima na pojedinačnim čvorovima, replikacija podataka, troškovi skaliranja. Odnosno, vrijedi obratiti pozornost na zadatke koji će se pojaviti tijekom održavanja sustava - kada je opterećenje desetke puta veće od planiranog, kada slučajno učitamo nešto na krivom mjestu, kada trebamo izbaciti novu verziju koda, zamijenite podatke i učinite to neprimjetno za klijente.
Za sve ove zahtjeve, Hazelcast sigurno odgovara zahtjevima.
Nastavit će se
Ali Hazelcast nije lijek za sve. Godine 2017. odabrali smo Hazelcast za admin cache, jednostavno na temelju dobrih dojmova iz prošlih iskustava. To je odigralo ključnu ulogu u jednoj vrlo okrutnoj šali, zbog koje smo se našli u teškoj situaciji i “junački” se iz nje izvlačili 60 dana. Ali o tome više u sljedećem dijelu.
U međuvremenu... Sretan novi kod!
Izvor: www.habr.com