Bonghjornu! Mi chjamu Alexey Pyankov, sò un sviluppatore in a cumpagnia Sportmaster. In questu Aghju dettu cumu u travagliu nantu à u situ di Sportmaster hà iniziatu in 2012, chì iniziative avemu sappiutu "push through" è vice versa, chì rake avemu cullatu.
Oghje vogliu sparte pinsamenti chì seguitanu un altru tema - scegliendu un sistema di caching per u backend java in u pannellu di amministrazione di u situ. Questa trama hà un significatu particulari per mè - ancu s'è a storia hà sviluppatu per solu 2 mesi, durante questi 60 ghjorni avemu travagliatu 12-16 ore è senza un ghjornu di ghjornu. Ùn avia mai pensatu o imaginatu chì era pussibule di travaglià cusì duru.
Dunque, aghju divisu u testu in 2 parti per ùn caricallu cumpletamente. À u cuntrariu, a prima parte serà assai ligera - preparazione, introduzione, qualchi considerazioni nantu à ciò chì u caching hè. Sè vo site digià un sviluppatore espertu o avete travagliatu cù cache, da u latu tecnicu ùn ci sarà assai prubabilmente nunda di novu in questu articulu. Ma per un junior, una rivista cusì chjuca pò dì à quale direzzione di circà s'ellu si trova in una tale crucivia.
Quandu a nova versione di u situ web di Sportmaster hè stata messa in produzzione, i dati sò stati ricevuti in una manera chì era, per dì, micca assai cunvene. A basa era tavule preparatu per a versione precedente di u situ (Bitrix), chì avia da esse tiratu in ETL, purtatu à una nova forma è arricchitu cù parechje cose da una decina di più sistemi. Per fà una nova stampa o una descrizzione di u produttu apparsu nantu à u situ, duvete aspittà finu à u ghjornu dopu - aghjurnamenti solu di notte, una volta à ghjornu.
À u principiu, ci sò stati tanti preoccupati da e prime simane d'andà in produzzione chì tali inconvenienze per i gestori di cuntenutu eranu un trifle. Ma, appena tuttu si stalla, u sviluppu di u prugettu cuntinuau - uni pochi di mesi dopu, à u principiu di 2015, avemu cuminciatu à sviluppà attivamente u panel admin. In 2015 è 2016, tuttu va bè, liberamu regularmente, u pannellu admin copre più è più di a preparazione di dati, è avemu preparatu per u fattu chì prestu a nostra squadra serà affidata cù a cosa più impurtante è cumplessa - u pruduttu. circuit (preparazione cumpleta è mantenimentu di dati nantu à tutti i prudutti). Ma in l'estiu di 2017, pocu prima di u lanciamentu di u circuitu di mercurie, u prughjettu si trova in una situazione assai difficiuli - precisamente per via di prublemi cù caching. Vogliu parlà di questu episodiu in a seconda parte di sta publicazione in dui parti.
Ma in questu post, principiaraghju da luntanu, vi prisintà qualchi pinsamenti - idee nantu à caching, chì saria un bonu passu per scroll through before a large project.
Quandu si verifica un compitu di caching
U compitu di caching ùn hè micca solu apparsu. Semu sviluppatori, scrivendu un pruduttu software è vulemu chì sia in dumanda. Se u pruduttu hè in dumanda è successu, l'utilizatori venenu. È venenu sempre più. E poi ci sò assai utilizatori è dopu u pruduttu diventa assai carricu.
À i primi tappe, ùn pensemu micca à l'ottimisazione è u rendiment di codice. A cosa principal hè a funziunalità, lanciate rapidamente un pilotu è teste ipotesi. È se a carica aumenta, pompemu u ferru. Aumentemu duie o trè volte, cinque volte, forse 10 volte. In qualchì locu quì - i finanzii ùn permettenu micca più. Quante volte cresce u numeru di utilizatori? Ùn serà micca cum'è 2-5-10, ma se successu, serà da 100-1000 à 100 mila volte. Questu hè, prima o dopu, avete da fà ottimisazione.
Dicemu chì una parte di u codice (chjamemu sta parte una funzione) piglia un tempu indecently long, è vulemu riduce u tempu d'esekzione. Una funzione pò esse accessu à una basa di dati, o pò esse l'esekzione di qualchì logica cumplessa - a cosa principal hè chì ci vole assai tempu per eseguisce. Quantu pudete riduce u tempu di esecuzione? In u limitu, pudete riduce à cero, micca più. Cumu pudete riduce u tempu di esecuzione à zero? Risposta: eliminà l'esekzione in tuttu. Invece, torna u risultatu immediatamente. Cumu pudete truvà u risultatu? Risposta: o calculate o cercate in qualchì locu. Ci vole assai tempu per calculà. E spia hè, per esempiu, di ricurdà u risultatu chì a funzione hà pruduttu l'ultima volta quandu chjamava cù i stessi paràmetri.
Questu hè, l'implementazione di a funzione ùn hè micca impurtante per noi. Basta à sapè da quali parametri dipende u risultatu. Allora, se i valori di i paràmetri sò rapprisentati in a forma di un oggettu chì pò esse usatu cum'è chjave in qualchì almacenamentu, u risultatu di u calculu pò esse salvatu è leghje a prossima volta chì si accede. Se questa scrittura è lettura di u risultatu hè più veloce di eseguisce a funzione, avemu un prufittu in termini di rapidità. A quantità di prufittu pò ghjunghje à 100, 1000 è 100 mila volte (10 ^ 5 hè piuttostu una eccezzioni, ma in u casu di una basa abbastanza lagging, hè abbastanza pussibule).
Requisiti basi per un sistema di cache
A prima cosa chì pò diventà un requisitu per un sistema di cache hè a veloce di lettura è, à un pocu menu, a velocità di scrittura. Questu hè veru, ma solu finu à chì stendemu u sistema à a produzzione.
Ghjuchemu stu casu.
Diciamu chì avemu furnitu a carica attuale cù hardware è avà introducemu gradualmente a cache. U numaru d'utilizatori cresce un pocu, a carica cresce - aghjunghjemu un pocu cache, vittite quì è quì. Questu cuntinueghja per qualchì tempu, è avà e funzioni pisanti sò praticamente micca chjamati più - tutta a carica principale casca nantu à u cache. U numaru di utilizatori durante stu tempu hà aumentatu N volte.
E se u suministru iniziale di hardware puderia esse 2-5 volte, allora cù l'aiutu di u cache pudemu migliurà u rendiment per un fattore di 10 o, in un bonu casu, per un fattore di 100, in certi lochi forsi per un fattore. di 1000. Questu hè, nantu à u stessu hardware - processemu 100 volte più richieste. Grande, vi meritate u gingerbread!
Ma avà, in un bellu mumentu, per casu, u sistema hà sbattutu è a cache hè colapsata. Nunda di speciale - dopu tuttu, u cache hè statu sceltu basatu annantu à u requisitu "alta velocità di lettura è scrittura, u restu ùn importa micca".
Riguardu à a carica iniziale, a nostra riserva di ferru era 2-5 volte, è a carica durante stu tempu hà aumentatu 10-100 volte. Utilizendu a cache, avemu eliminatu e chjama per e funzioni pesanti è per quessa tuttu hà travagliatu. È avà, senza cache, quante volte u nostru sistema rallentarà? Chì ci sarà ? U sistema cascarà.
Ancu s'è u nostru cache ùn hà micca sbulicatu, ma hè statu sbulicatu solu per un tempu, duverà esse riscaldatu, è questu duverà qualchì tempu. È duranti stu tempu, u pesu principale cascarà nantu à a funziunalità.
Conclusioni: i prughjetti di produzzione altamente caricati necessitanu un sistema di cache micca solu per avè una alta velocità di lettura è scrittura, ma ancu per assicurà a sicurezza di dati è a resistenza à i fallimenti.
L'agonia di a scelta
In un prughjettu cù un pannellu admin, a scelta hè stata cusì: prima avemu stallatu Hazelcast, perchè Avemu digià cunnisciutu stu pruduttu da l'esperienza di u situ principale. Ma quì sta scelta ùn hè micca successu - sottu u nostru prufilu di carica, Hazelcast ùn hè micca solu lento, ma terribilmente lento. È à quellu tempu avemu digià firmatu per a data di liberazione.
Spoiler: cumu si sò sviluppati esattamente e circustanze chì avemu mancatu un affare cusì grande è finisci cù una situazione aguda è tesa - vi dicu in a seconda parte - è cumu avemu finitu è cumu avemu esce. Ma avà - dicu solu chì era assai stress, è "per pensà - in qualchì manera ùn possu micca pensà, simu scuzzulate a buttiglia". "Shaking the bottle" hè ancu un spoiler, più nantu à questu dopu.
Ciò chì avemu fattu:
- Facemu una lista di tutti i sistemi chì Google è StackOverflow suggerenu. Un pocu più di 30
- Scrivemu testi cù una carica tipica per a produzzione. Per fà questu, avemu registratu dati chì passanu per u sistema in un ambiente di produzzione - un tipu di sniffer per i dati micca in a reta, ma in u sistema. Esattamente sta dati hè stata utilizata in i testi.
- Cù tutta a squadra, ognunu selezziunà u prossimu sistema da a lista, u cunfigurà, è eseguite teste. Ùn passa micca a prova, ùn porta micca a carica - l'avemu ghjittatu è andemu à u prossimu in linea.
- In u 17u sistema hè diventatu chjaru chì tuttu era senza speranza. Smetti di scuzzulate a buttiglia, hè ora di pensà seriamente.
Ma questu hè una opzione quandu avete bisognu di sceglie un sistema chì "attraversà a velocità" in testi pre-preparati. E s'ellu ùn ci hè micca ancu tali teste è vulete sceglie rapidamente?
Modelemu sta opzione (hè difficiuli d'imagine chì un sviluppatore mediu + vive in un vacuum, è à u mumentu di a selezzione ùn hà ancu formalizatu a so preferenza in quantu à quale pruduttu pruvà prima - per quessa, più ragiunamentu hè più un teoricu / filusufìa / circa un junior).
Dopu avè decisu nantu à e esigenze, avemu principiatu à selezziunà una suluzione fora di a scatula. Perchè reinventà a rota: andemu à piglià un sistema di cache prontu.
Sè vo site appena principiatu è google, allora dà o pigliate l'ordine, ma in generale, e linee guida seranu cusì. Prima di tuttu, truverete à Redis, si sente in ogni locu. Allora truverete chì EhCache hè u sistema più anticu è pruvucatu. Dopu scriveremu nantu à Tarantool, un sviluppu domesticu chì hà un aspettu unicu di a suluzione. È ancu Ignite, perchè avà hè in crescita di pupularità è gode di u sustegnu di SberTech. À a fine ci hè ancu Hazelcast, perchè in u mondu di l'impresa spessu appare trà e grande cumpagnie.
A lista ùn hè micca exhaustiva; ci sò decine di sistemi. È vàremu solu una cosa. Pigliemu i sistemi 5 selezziunati per u "cuncorsu di bellezza" è fate una selezzione. Quale sarà u vincitore ?
Redis
Avemu leghje ciò chì scrivenu nantu à u situ ufficiale.
- prughjettu opensource. Offre un almacenamentu di dati in memoria, a capacità di salvà nantu à u discu, auto-partitioning, alta dispunibilità è ricuperazione da interruzioni di a rete.
Sembra chì tuttu hè bè, pudete piglià è vite - tuttu ciò chì avete bisognu, faci. Ma solu per piacè, fighjemu l'altri candidati.
EhCache
- "u cache più utilizatu per Java" (traduzzione di u slogan da u situ ufficiale). Ancu opensource. E allora avemu capitu chì Redis ùn hè micca per java, ma generale, è per interagisce cun ellu avete bisognu di un wrapper. È EhCache serà più còmuda. Chì altru prumetti u sistema? Affidabilità, provata, piena funziunalità. Ebbè, hè ancu u più cumuni. È cache terabytes di dati.
Redis hè scurdatu, sò prontu à sceglie EhCache.
Ma un sensu di patriotismu mi spinge à vede ciò chì hè bonu di Tarantool.
Tarantool
- risponde à a designazione "piattaforma di integrazione di dati in tempu reale". Sembra assai cumplicatu, cusì leghjemu a pagina in dettagliu è truvamu una dichjarazione forte: "Cache 100% di e dati in RAM". Questu duverebbe suscitarà dumande - dopu à tuttu, pò esse assai più dati cà memoria. A spiegazione hè chì significa chì Tarantool ùn eseguisce micca a serializazione per scrive dati à u discu da a memoria. Invece, usa funziunalità di u sistema di livellu bassu, quandu a memoria hè simpricimenti mappata à un sistema di fugliale cù un rendimentu I / O assai bonu. In generale, anu fattu una cosa maravigliosa è fresca.
Fighjemu l'implementazioni: l'autostrada corporativa Mail.ru, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...
S'ellu ci era ancu dubbitu annantu à Tarantool, allora u casu di implementazione à Mastercard mi finisce. Pigliu Tarantool.
Ma in ogni modu…
Ignite
... ci hè un pocu di più , hè fatturatu cum'è una "piattaforma di computing in-memory... in-memory speeds on petabytes of data". Ci sò ancu assai vantaghji quì: cache distribuitu in memoria, u almacenamentu è u cache di valore chjave più veloce, scala horizontale, alta dispunibilità, integrità stretta. In generale, risulta chì u più veloce hè Ignite.
Implementazioni: Sberbank, American Airlines, Yahoo! Giappone. E poi scupriu chì Ignite ùn hè micca solu implementatu in Sberbank, ma a squadra SberTech manda a so ghjente à a squadra Ignite stessu per raffinà u pruduttu. Questu hè cumplettamente captivante è sò prontu à piglià Ignite.
Ùn hè micca chjaru perchè, aghju fighjulatu u quintu puntu.
avellana
Vaiu à u situ , lettura. È risulta chì a suluzione più veloce per u caching distribuitu hè Hazelcast. Hè ordini di grandezza più veloce di tutte l'altri suluzioni è in generale hè un capu in u campu di a rete di dati in memoria. In questu sfondate, per piglià qualcosa altru ùn hè micca di rispettà sè stessu. Utilizeghja ancu u almacenamentu di dati redundante per u funziunamentu cuntinuu di u cluster senza perdita di dati.
Eccu, sò prontu à piglià Hazelcast.
Comparaison
Ma s'è vo circate, tutti i cinqui candidati sò descritti in modu chì ognunu di elli hè u megliu. Comu sceglie ? Pudemu vede quale hè u più pupulare, cercate paraguni, è u malu di testa andarà.
Truvemu unu cusì , sceglite i nostri 5 sistemi.
Eccu sò ordinati: Redis hè in cima, Hazelcast hè in u sicondu postu, Tarantool è Ignite guadagnanu pupularità, EhCache hè stata è ferma u listessu.
Ma guardemu : ligami à i siti web, interessu generale in u sistema, offerte di travagliu - grande! Questu hè, quandu u mo sistema falla, diceraghju: "No, hè affidabile! Ci sò parechje offerte di travagliu ... " Un paragone cusì simplice ùn farà micca.
Tutti sti sistemi ùn sò micca solu sistemi di cache. Anu ancu assai funziunalità, ancu quandu i dati ùn sò micca pumped à u cliente per u processu, ma vice versa: u codice chì deve esse eseguitu nantu à e dati si move à u servitore, hè esecutatu quì, è u risultatu hè tornatu. È ùn sò micca spessu cunsiderate cum'è un sistema separatu per caching.
Va bè, ùn rinuncemu, truvamu un paragone direttu di i sistemi. Pigliemu e prime duie opzioni - Redis è Hazelcast. Semu interessate in a velocità, è avemu da paragunà nantu à stu paràmetru.
Hz vs Redis
Truvemu questu :
U blu hè Redis, u rossu hè Hazelcast. Hazelcast vince in ogni locu, è ci hè una logica per questu: hè multi-threaded, assai ottimizatu, ogni filu travaglia cù a so propria partizione, cusì ùn ci hè micca bluccatu. È Redis hè unicu filatu; ùn beneficia micca di CPU multi-core muderni. Hazelcast hà I / O asincronu, Redis-Jedis hà sockets di bloccu. Dopu tuttu, Hazelcast usa un protokollu binariu, è Redis hè testu-centric, chì significa chì hè inefficiente.
In casu, andemu à una altra fonte di paragone. Chì ci mostrarà ?
Redis vs Hz
Un più :
Quì, à u cuntrariu, u rossu hè Redis. Vale à dì, Redis supera Hazelcast in termini di prestazioni. Hazelcast hà vintu u primu paragone, Redis hà vintu u sicondu. spiegò assai precisamente perchè Hazelcast hà vintu u paragone precedente.
Risulta chì u risultatu di u primu hè statu veramente rigged: Redis hè stata presa in a casella di basa, è Hazelcast hè stata adattata per un casu di prova. Allora ci hè: prima, ùn pudemu micca fiducia in nimu, è in segundu, quandu avemu finalmente sceltu un sistema, avemu sempre bisognu di cunfigurà bè. Questi paràmetri includenu decine, quasi centinaie di parametri.
Scuzzulate a buttiglia
È possu spiegà tuttu u prucessu chì avemu fattu avà cù a metafora seguente: "Scuzzulate a buttiglia". Questu hè, avà ùn avete micca bisognu di prugramma, avà u principale hè di pudè leghje stackoverflow. È aghju una persona in a mo squadra, un prufessiunale, chì travaglia esattamente cusì in i mumenti critichi.
Chì faci ? Vede una cosa rotta, vede una traccia di stack, piglia qualchi parolle da ellu (quale sò a so cumpetenza in u prugramma), cerca in Google, trova stackoverflow trà e risposte. Senza leghje, senza pensà, trà e risposte à a quistione, ellu sceglie qualcosa più simili à a frase "fà questu è quellu" (scelta una risposta cusì hè u so talentu, perchè ùn hè micca sempre a risposta chì hà ricevutu u più piace). s'applica, pare: se qualcosa hè cambiatu, allora grande. S'ellu ùn hè micca cambiatu, rinviate. È ripetite launch-check-search. È in questu modu intuitivu, assicura chì u codice funziona dopu qualchì tempu. Ùn sà micca perchè, ùn sà micca ciò chì hà fattu, ùn pò micca spiegà. Ma! Sta infezzjoni travaglia. È "u focu hè spento". Avà capimu ciò chì avemu fattu. Quandu u prugramma travaglia, hè un ordine di grandezza più faciule. È risparmia assai tempu.
Stu metudu hè assai bè spiegatu cù stu esempiu.
Una volta era assai populari per cullà una barca à vela in una buttiglia. À u stessu tempu, a barca a vela hè grande è fragile, è u collu di l'buttiglia hè assai strettu, hè impussibile di spinghje in l'internu. Cumu assemblallu?
Ci hè un tali metudu, assai veloce è assai efficace.
U bastimentu hè custituitu da una mansa di picculi cose: bastoni, corde, vele, cola. Mettimu tuttu questu in una buttiglia.
Pigliemu a buttiglia cù e duie mani è cuminciamu à scuzzulate. Scuzzulemu è scuzzulemu. È di solitu risulta esse una basura cumpleta, sicuru. Ma qualchì volta. Calchì volta diventa una nave ! Più precisamente, qualcosa simile à una nave.
Mostremu questu qualcosa à qualchissia: "Seryoga, vedi!?" È veramente, da luntanu s'assumiglia à una nave. Ma questu ùn pò micca esse permessu di cuntinuà.
Ci hè un altru modu. Sò usati da i picciotti più avanzati, cum'è i pirate.
Aghju datu stu tippu un compitu, hà fattu tuttu è partì. E vi vede - pare chì hè fattu. È dopu un pocu tempu, quandu u codice deve esse finalizatu, questu principia per via di ellu... Hè bonu chì hà digià sappiutu scappà luntanu. Quessi sò i picciotti chì, usendu l'esempiu di una buttiglia, facenu questu: vede, induve u fondu hè, u vetru curve. È ùn hè micca sanu chjaru s'ellu hè trasparente o micca. Allora i "pirate" anu tagliatu stu fondu, inserisce una nave quì, poi cola u fondu di novu, è hè cum'è s'ellu hè cusì chì deve esse.
Da u puntu di vista di stabilisce u prublema, tuttu pare esse currettu. Ma aduprendu navi cum'è un esempiu: perchè fà sta nave in tuttu, chì ne hà bisognu? Ùn furnisce micca funziunalità. Di solitu tali navi sò rigali à e persone assai altu, chì u mettenu nantu à un scaffale sopra, cum'è un simbulu, cum'è un signu. E se una tale persona, u capu di una grande impresa o un ufficiale d'altu rangu, cumu serà a bandiera per un tali pirate, chì u collu hè statu tagliatu? Saria megliu s'ellu ùn sapia mai. Allora, cumu si finiscinu per fà sti navi chì ponu esse dati à una persona impurtante?
L'unicu locu chjave chì ùn pudete micca fà nunda hè u corpu. È u scafo di a nave si mette ghjustu in u collu. Mentre chì a nave hè assemblata fora di a buttiglia. Ma ùn hè micca solu assemblea una nave, hè un veru articuli di ghjuvelli. Lever spiciali sò aghjuntu à i cumpunenti, chì poi permettenu di esse elevati. Per esempiu, i veli sò plegati, purtati cù cura à l'internu, è dopu, cù l'aiutu di pinzette, sò tirati è elevati assai precisamente, cù precisione. U risultatu hè un travagliu d'arti chì pò esse rigalatu cù una cuscenza chjaru è orgogliu.
È se vulemu chì u prugettu sia successu, deve esse almenu un ghjuvellu in a squadra. Qualchissia chì si preoccupa di a qualità di u pruduttu è piglia in contu tutti l'aspetti, senza sacrificà nunda, ancu in i mumenti di stress, quandu e circustanze necessitanu di fà l'urgente à a spesa di l'impurtante. Tutti i prughjetti di successu chì sò sustinibili, chì sò stati a prova di u tempu, sò custruiti nantu à stu principiu. Ci hè qualcosa di assai precisu è unicu in elli, qualcosa chì sfrutta tutte e pussibulità dispunibili. In l'esempiu cù a nave in a buttiglia, u fattu chì u cascu di a nave passa per u collu hè ghjucatu.
Riturnendu à u compitu di sceglie u nostru servitore di caching, cumu puderia esse applicatu stu metudu? Offre sta opzione di scelta di tutti i sistemi chì esistenu - ùn scuzzulate micca l'buttiglia, ùn sceglie micca, ma fighjate ciò chì anu in principiu, ciò chì cercà quandu sceglie un sistema.
Induve circà u collu di buttiglia
Pruvate micca di scuzzulà l'buttiglia, per ùn passà per tuttu ciò chì ci hè unu per unu, ma vedemu chì prublemi nasceranu si di colpu, per u nostru compitu, cuncepemu un tali sistema. Di sicuru, ùn avemu micca assemblatu a bicicletta, ma avemu aduprà stu diagramma per aiutà à capisce ciò chì i punti per attente à e descrizzione di u produttu. Scupritemu un tali schema.
Se u sistema hè distribuitu, allora avemu parechji servitori (6). Diciamu chì ci sò quattru (hè cunvenutu di mette in a stampa, ma, sicuru, ci ponu esse quant'è quant'elli vulete). Sì i servitori sò in diversi nodi, significa chì tutti eseguinu qualchì codice chì hè rispunsevuli di assicurà chì questi nodi formanu un cluster è, in casu d'una pausa, cunnetta è ricunnosce l'altri.
Avemu ancu bisognu di logica di codice (2), chì hè in realtà di caching. I clienti interagiscenu cù stu codice via qualchì API. U codice cliente (1) pò esse sia in a stessa JVM sia accede à a reta. A logica implementata in l'internu hè a decisione di quale l'uggetti lascià in a cache è quale scaccià. Utilizemu a memoria (3) per almacenà a cache, ma se ne necessariu, pudemu salvà una parte di e dati nantu à u discu (4).
Videmu in quale parte a carica serà fatta. In verità, ogni freccia è ogni nodu seranu caricati. Prima, trà u codice di u cliente è l'api, s'ellu hè una cumunicazione di rete, a subsidenza pò esse abbastanza notevuli. Siconda, in u quadru di l'api stessu - se l'avemu eccessivu cù una logica cumplessa, pudemu avè prublemi cù u CPU. È saria bellu chì a logica ùn perde u tempu in memoria. È resta l'interazzione cù u sistema di fugliale - in a versione abituale, questu hè serializza / restaurà è scrive / leghje.
Dopu hè l'interazzione cù u cluster. Probabilmente, serà in u stessu sistema, ma puderia esse separatamente. Quì avete ancu bisognu di piglià in contu u trasferimentu di dati à questu, a vitezza di serializazione di dati è l'interazzione trà u cluster.
Avà, da una banda, pudemu imaginà "chì ingranaggi turnaranu" in u sistema di cache in u processu di e dumande da u nostru codice, è da l'altra banda, pudemu stimà quale è quante richieste u nostru codice generarà per stu sistema. Questu hè abbastanza per fà una scelta più o menu sobria - per sceglie un sistema per u nostru casu d'usu.
avellana
Videmu cumu applicà sta descomposizione à a nostra lista. Per esempiu, Hazelcast.
Per pudè mette / piglià dati da Hazelcast, u codice di u cliente accede à (1) l'api. Hz permette di eseguisce u servitore cum'è incrustatu, è in questu casu, accede à l'api hè un metudu chjamatu in u JVM, chì pò esse cunsideratu liberu.
Per chì a logica in (2) funziona, Hz s'appoghja nantu à l'hash di l'array di byte di a chjave serializzata - vale à dì, a chjave serà serializzata in ogni casu. Questu hè inevitabbile overhead per Hz.
Strategii di eviction sò implementati bè, ma per i casi speciali pudete aghjunghje u vostru propiu. Ùn avete micca à preoccupassi di sta parte.
U almacenamentu (4) pò esse cunnessu. Perfettu. L'interazzione (5) per l'embedded pò esse cunsiderata immediata. Scambiu di dati trà i nodi in u cluster (6) - sì, esiste. Questu hè un investimentu in a tolleranza di difetti à a spesa di a rapidità. A funzione Hz Near-cache permette di riduce u prezzu - i dati ricevuti da altri nodi in u cluster seranu cache.
Chì pò esse fattu in tali cundizioni per aumentà a velocità?
Per esempiu, per evitari a serializazione di a chjave in (2) - aghjunghje un altru cache nantu à Hazelcast, per i dati più caldi. Sportmaster hà sceltu Caffeine per questu scopu.
Per a torsione à u livellu (6), Hz offre dui tipi di almacenamiento: IMap è ReplicatedMap.
Hè da nutà cumu Hazelcast hè ghjuntu in a pila di tecnulugia Sportmaster.
In u 2012, quandu avemu travagliatu nantu à u primu pilotu di u futuru situ, era Hazelcast chì hè statu u primu ligame chì u mutore di ricerca hà tornatu. A cunniscenza hà cuminciatu "a prima volta" - eramu captivati da u fattu chì solu duie ore dopu, quandu avemu avvitatu Hz in u sistema, hà travagliatu. È hà travagliatu bè. À a fine di u ghjornu avemu finitu una quantità di teste è eramu felici. È sta riserva di vigori bastava per superà e sorprese chì Hz hà lanciatu cù u tempu. Avà a squadra Sportmaster ùn hà micca raghjone per abbandunà Hazelcast.
Ma tali argumenti cum'è "u primu ligame in u mutore di ricerca" è "HelloWorld hè statu assemblatu rapidamente" sò, sicuru, una eccezzioni è una caratteristica di u mumentu chì a scelta hà fattu. I testi veri per u sistema sceltu accumincianu cù a liberazione in a pruduzzione, è hè in questu stadiu chì deve esse attentu quandu sceglite qualsiasi sistema, cumpresa a cache. In attu, in u nostru casu, pudemu dì chì avemu sceltu Hazelcast per accidenti, ma dopu hè statu chì avemu sceltu currettamente.
Per a pruduzzione, assai più impurtante: monitoraghju, gestione di fallimenti nantu à i nodi individuali, replicazione di dati, costu di scala. Vale à dì, vale a pena attente à i travaglii chì si sviluppanu durante u mantenimentu di u sistema - quandu a carica hè decine di volte più altu ch'è previstu, quandu caricamu accidentalmente qualcosa in u locu sbagliatu, quandu avemu bisognu di sparghje una nova versione. di u codice, rimpiazzà i dati è fate insinuatu per i clienti.
Per tutti questi requisiti, Hazelcast certamente si adatta à u prugettu.
À seguità
Ma Hazelcast ùn hè micca una panacea. In 2017, avemu sceltu Hazelcast per a cache di amministratore, solu basatu nantu à impressioni boni da l'esperienza passata. Questu hà ghjucatu un rolu chjave in un scherzu assai crudele, per via di quale avemu trovu in una situazione difficiuli è "heroically" esce da ellu per 60 ghjorni. Ma più nantu à questu in a prossima parte.
Intantu... Felice New Code !
Source: www.habr.com