Ciao! Mi chiamo Alexey Pyankov, sono uno sviluppatore presso l'azienda Sportmaster. In ciò Ho raccontato come sono iniziati i lavori sul sito Sportmaster nel 2012, quali iniziative siamo riusciti a “portare avanti” e viceversa, quale rake abbiamo raccolto.
Oggi voglio condividere riflessioni che seguono un altro argomento: la scelta di un sistema di memorizzazione nella cache per il backend Java nel pannello di amministrazione del sito. Questa trama ha un significato speciale per me: sebbene la storia si sia svolta in soli 2 mesi, durante questi 60 giorni abbiamo lavorato 12-16 ore e senza un solo giorno libero. Non avevo mai pensato o immaginato che fosse possibile lavorare così duramente.
Pertanto ho diviso il testo in 2 parti per non caricarlo completamente. La prima parte, invece, sarà molto leggera: preparazione, introduzione, alcune considerazioni su cosa sia il caching. Se sei già uno sviluppatore esperto o hai lavorato con le cache, dal punto di vista tecnico molto probabilmente non ci sarà nulla di nuovo in questo articolo. Ma per un giovane, una recensione così piccola può dirgli in quale direzione guardare se si trova a un bivio del genere.
Quando è stata messa in produzione la nuova versione del sito Sportmaster, i dati sono stati ricevuti in un modo, per usare un eufemismo, poco conveniente. La base erano le tabelle preparate per la versione precedente del sito (Bitrix), che dovevano essere inserite in ETL, portate in una nuova forma e arricchite con varie piccole cose da una dozzina di sistemi in più. Per far apparire sul sito una nuova immagine o una descrizione del prodotto, dovevi attendere fino al giorno successivo: gli aggiornamenti vengono eseguiti solo di notte, una volta al giorno.
Inizialmente, le preoccupazioni fin dalle prime settimane di messa in produzione erano così tante che tali inconvenienti per i gestori dei contenuti erano insignificanti. Ma non appena tutto si è sistemato, lo sviluppo del progetto è continuato: pochi mesi dopo, all'inizio del 2015, abbiamo iniziato a sviluppare attivamente il pannello di amministrazione. Nel 2015 e nel 2016 tutto sta andando bene, rilasciamo regolarmente, il pannello di amministrazione si occupa sempre di più della preparazione dei dati e ci stiamo preparando al fatto che presto al nostro team verrà affidata la cosa più importante e complessa: il prodotto circuito (preparazione completa e mantenimento dei dati su tutti i prodotti). Ma nell'estate del 2017, poco prima del lancio del circuito delle materie prime, il progetto si troverà in una situazione molto difficile, proprio a causa di problemi con il caching. Di questo episodio voglio parlare nella seconda parte di questa pubblicazione in due parti.
Ma in questo post inizierò da lontano, presenterò alcune riflessioni: idee sul caching, che sarebbe un buon passo da scorrere prima di un grande progetto.
Quando si verifica un'attività di memorizzazione nella cache
L'attività di memorizzazione nella cache non viene semplicemente visualizzata. Siamo sviluppatori, scriviamo un prodotto software e vogliamo che sia richiesto. Se il prodotto è richiesto e ha successo, gli utenti arriveranno. E ne arrivano sempre di più. E poi ci sono molti utenti e quindi il prodotto diventa molto carico.
Nelle prime fasi non pensiamo all'ottimizzazione e alle prestazioni del codice. La cosa principale è la funzionalità, lanciare rapidamente un progetto pilota e testare le ipotesi. E se il carico aumenta, pompiamo il ferro. Lo aumentiamo due o tre volte, cinque volte, forse 10 volte. Da qualche parte qui – le finanze non lo permetteranno più. Quante volte aumenterà il numero di utenti? Non sarà come 2-5-10, ma in caso di successo, sarà da 100-1000 a 100mila volte. Cioè, prima o poi dovrai fare l'ottimizzazione.
Diciamo che una parte del codice (chiamiamola funzione) impiega un tempo indecentemente lungo e vogliamo ridurre il tempo di esecuzione. Una funzione può essere l'accesso a un database o l'esecuzione di una logica complessa: la cosa principale è che richiede molto tempo per essere eseguita. Quanto puoi ridurre i tempi di esecuzione? Nel limite, puoi ridurlo a zero, non oltre. Come ridurre a zero i tempi di esecuzione? Risposta: eliminare del tutto l'esecuzione. Invece, restituisci immediatamente il risultato. Come puoi scoprire il risultato? Risposta: o calcolalo o guarda da qualche parte. Ci vuole molto tempo per calcolare. E spiare significa, ad esempio, ricordare il risultato che la funzione ha prodotto l'ultima volta quando è stata chiamata con gli stessi parametri.
Cioè, l'implementazione della funzione non è importante per noi. Basta solo sapere da quali parametri dipende il risultato. Quindi, se i valori dei parametri vengono rappresentati sotto forma di un oggetto che può essere utilizzato come chiave in qualche archivio, il risultato del calcolo può essere salvato e letto al successivo accesso. Se questa scrittura e lettura del risultato è più veloce dell’esecuzione della funzione, abbiamo un profitto in termini di velocità. L'importo del profitto può raggiungere 100, 1000 e 100mila volte (10^5 è piuttosto un'eccezione, ma nel caso di una base abbastanza ritardata è del tutto possibile).
Requisiti di base per un sistema di caching
La prima cosa che potrebbe diventare un requisito per un sistema di memorizzazione nella cache è l'elevata velocità di lettura e, in misura leggermente minore, la velocità di scrittura. Questo è vero, ma solo fino a quando non metteremo il sistema in produzione.
Giochiamo a questo caso.
Diciamo che abbiamo fornito l'hardware al carico attuale e ora stiamo introducendo gradualmente la memorizzazione nella cache. Il numero di utenti cresce un po ', il carico cresce: aggiungiamo un po' di cache, lo avviciniamo qua e là. Ciò continua per un po 'di tempo e ora le funzioni pesanti non vengono praticamente più richiamate: l'intero carico principale ricade sulla cache. Il numero di utenti durante questo periodo è aumentato N volte.
E se la fornitura iniziale di hardware potesse essere 2-5 volte, con l'aiuto della cache potremmo migliorare le prestazioni di un fattore 10 o, nel migliore dei casi, di un fattore 100, in alcuni punti forse di un fattore di 1000. Cioè, sullo stesso hardware, elaboriamo 100 volte più richieste. Fantastico, ti meriti il pan di zenzero!
Ma ora, in un bel momento, per caso, il sistema si è bloccato e la cache è crollata. Niente di speciale: dopo tutto, la cache è stata scelta in base al requisito "elevata velocità di lettura e scrittura, il resto non conta".
Rispetto al carico iniziale, la nostra riserva di ferro era di 2-5 volte e il carico durante questo periodo è aumentato di 10-100 volte. Usando la cache abbiamo eliminato le chiamate a funzioni pesanti e quindi tutto ha funzionato. E ora, senza cache, quante volte il nostro sistema rallenterà? Cosa ci succederà? Il sistema cadrà.
Anche se la nostra cache non si è bloccata, ma è stata svuotata solo per un po', dovrà essere riscaldata e ciò richiederà del tempo. E durante questo periodo, l'onere principale ricadrà sulla funzionalità.
Conclusione: i progetti di produzione ad alto carico richiedono un sistema di caching non solo per avere velocità di lettura e scrittura elevate, ma anche per garantire la sicurezza dei dati e la resistenza ai guasti.
L'agonia della scelta
In un progetto con pannello di amministrazione, la scelta è stata questa: prima abbiamo installato Hazelcast, perché Conoscevamo già questo prodotto dall'esperienza del sito principale. Ma qui questa scelta si è rivelata infruttuosa: sotto il nostro profilo di carico, Hazelcast non è solo lento, ma terribilmente lento. E in quel momento avevamo già prenotato la data di uscita.
Spoiler: come si sono sviluppate esattamente le circostanze per cui ci siamo persi un evento così importante e ci siamo ritrovati in una situazione acuta e tesa - ve lo dirò nella seconda parte - e come siamo finiti e come ne siamo usciti. Ma ora - dirò solo che è stato molto stressante e "pensare - in qualche modo non riesco a pensare, stiamo scuotendo la bottiglia". Anche “Shaking the Bottle” è uno spoiler, ne parleremo più avanti.
Cosa abbiamo fatto:
- Facciamo un elenco di tutti i sistemi suggeriti da Google e StackOverflow. Poco più di 30
- Scriviamo test con un carico tipico per la produzione. Per fare ciò, abbiamo registrato i dati che passano attraverso il sistema in un ambiente di produzione, una sorta di sniffer di dati non sulla rete, ma all'interno del sistema. Nei test sono stati utilizzati esattamente questi dati.
- Con l'intero team, ognuno seleziona il sistema successivo dall'elenco, lo configura ed esegue i test. Non supera il test, non regge il carico: lo buttiamo via e passiamo a quello successivo.
- Il 17 sistema divenne chiaro che tutto era senza speranza. Smettila di agitare la bottiglia, è ora di pensare seriamente.
Ma questa è un'opzione quando è necessario scegliere un sistema che "superi la velocità" nei test pre-preparati. Cosa succede se non esistono ancora tali test e vuoi scegliere rapidamente?
Simuliamo questa opzione (è difficile immaginare che uno sviluppatore di livello medio+ viva nel vuoto e al momento della selezione non abbia ancora formalizzato la sua preferenza su quale prodotto provare per primo - pertanto, ulteriori ragionamenti sono più di tipo teorico/filosofico/ circa un junior).
Dopo aver deciso i requisiti, inizieremo a selezionare una soluzione pronta all'uso. Perché reinventare la ruota: andremo a prendere un sistema di caching già pronto.
Se hai appena iniziato e lo cerchi su Google, dai o prendi l'ordine, ma in generale le linee guida saranno così. Prima di tutto, incontrerai Redis, lo senti ovunque. Allora scoprirai che EhCache è il sistema più vecchio e collaudato. Successivamente scriveremo di Tarantool, uno sviluppo domestico che ha un aspetto unico della soluzione. E anche Ignite, perché ora sta diventando sempre più popolare e gode del supporto di SberTech. Alla fine c'è anche Hazelcast, perché nel mondo enterprise compare spesso tra le grandi aziende.
L’elenco non è esaustivo; esistono decine di sistemi. E rovineremo solo una cosa. Prendiamo i 5 sistemi selezionati per il “concorso di bellezza” e facciamo una selezione. chi sarà il vincitore?
Redis
Leggiamo cosa scrivono sul sito ufficiale.
-progetto open source. Offre archiviazione dei dati in memoria, possibilità di salvare su disco, partizionamento automatico, disponibilità elevata e ripristino in caso di interruzioni della rete.
Sembra che vada tutto bene, puoi prenderlo e avvitarlo: tutto ciò di cui hai bisogno, lo fa. Ma giusto per divertirci, diamo un’occhiata agli altri candidati.
Eh Cache
- "la cache per Java più utilizzata" (traduzione dello slogan dal sito ufficiale). Anche opensource. E poi capiamo che Redis non è per Java, ma generale, e per interagire con esso è necessario un wrapper. Ed EhCache sarà più conveniente. Cos’altro promette il sistema? Affidabilità, comprovata, piena funzionalità. Bene, è anche il più comune. E memorizza nella cache terabyte di dati.
Redis è stato dimenticato, sono pronto a scegliere EhCache.
Ma un senso di patriottismo mi spinge a vedere cosa c’è di buono nel Tarantoolo.
Tarantoolo
- soddisfa la designazione "Piattaforma di integrazione dei dati in tempo reale". Sembra molto complicato, quindi leggiamo la pagina in dettaglio e troviamo una forte affermazione: "Memorizza nella cache il 100% dei dati nella RAM". Ciò dovrebbe sollevare interrogativi: dopo tutto, possono esserci molti più dati che memoria. La spiegazione è che ciò significa che Tarantool non esegue la serializzazione per scrivere i dati su disco dalla memoria. Utilizza invece funzionalità di basso livello del sistema, quando la memoria viene semplicemente mappata su un file system con ottime prestazioni di I/O. In generale, hanno fatto qualcosa di meraviglioso e interessante.
Diamo un'occhiata alle implementazioni: Mail.ru corporate Highway, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...
Se ci fossero ancora dubbi su Tarantool, allora il caso di implementazione presso Mastercard mi mette fine. Prendo il Tarantolo.
Ma in ogni caso…
infiammare
…c’è dell’altro , viene pubblicizzato come una "piattaforma informatica in-memory...velocità in-memory su petabyte di dati". Ci sono anche molti vantaggi qui: cache in memoria distribuita, archiviazione e cache di valori-chiave più veloci, scalabilità orizzontale, disponibilità elevata, integrità rigorosa. In generale, risulta che il più veloce è Ignite.
Implementazioni: Sberbank, American Airlines, Yahoo! Giappone. E poi scopro che Ignite non è solo implementato in Sberbank, ma il team SberTech invia le sue persone al team Ignite stesso per perfezionare il prodotto. Questo è completamente accattivante e sono pronto per prendere Ignite.
Non è del tutto chiaro il motivo, sto guardando il quinto punto.
Nocciola
Vado al sito , lettura. E risulta che la soluzione più veloce per il caching distribuito è Hazelcast. È ordini di grandezza più veloce di tutte le altre soluzioni e in generale è leader nel campo della griglia dati in-memory. In questo contesto, prendere qualcos'altro non significa rispettare te stesso. Utilizza inoltre l'archiviazione dati ridondante per il funzionamento continuo del cluster senza perdita di dati.
Questo è tutto, sono pronto per prendere Hazelcast.
Confronto
Ma se guardi, tutti e cinque i candidati sono descritti in modo tale che ognuno di loro è il migliore. Come scegliere? Possiamo vedere qual è il più popolare, cercare confronti e il mal di testa se ne andrà.
Ne troviamo uno così , scegli i nostri 5 sistemi.
Eccoli ordinati: Redis è al primo posto, Hazelcast è al secondo posto, Tarantool e Ignite stanno guadagnando popolarità, EhCache è stato e rimane lo stesso.
Ma guardiamo : link a siti web, interesse generale per il sistema, offerte di lavoro - fantastico! Cioè, quando il mio sistema fallisce, dirò: “No, è affidabile! Ci sono molte offerte di lavoro..." Un confronto così semplice non va bene.
Tutti questi sistemi non sono solo sistemi di memorizzazione nella cache. Hanno anche molte funzionalità, anche quando i dati non vengono inviati al client per l'elaborazione, ma viceversa: il codice che deve essere eseguito sui dati si sposta sul server, viene eseguito lì e il risultato viene restituito. E non sono spesso considerati un sistema separato per la memorizzazione nella cache.
Ok, non molliamo, troviamo un confronto diretto dei sistemi. Prendiamo le prime due opzioni: Redis e Hazelcast. A noi interessa la velocità e li confronteremo in base a questo parametro.
Hz contro Redis
Troviamo questo :
Il blu è Redis, il rosso è Hazelcast. Hazelcast vince ovunque e c'è una logica per questo: è multi-thread, altamente ottimizzato, ogni thread funziona con la propria partizione, quindi non ci sono blocchi. E Redis è a thread singolo; non beneficia delle moderne CPU multi-core. Hazelcast ha I/O asincrono, Redis-Jedis ha socket di blocco. Dopotutto, Hazelcast utilizza un protocollo binario e Redis è incentrato sul testo, il che significa che è inefficiente.
Per ogni evenienza, passiamo a un'altra fonte di confronto. Cosa ci mostrerà?
Redis vs Hz
altro :
Qui invece il rosso è Redis. Cioè, Redis supera Hazelcast in termini di prestazioni. Hazelcast ha vinto il primo confronto, Redis ha vinto il secondo. ha spiegato in modo molto preciso perché Hazelcast ha vinto il confronto precedente.
Si scopre che il risultato del primo era effettivamente truccato: Redis è stato preso nella scatola base e Hazelcast è stato adattato per un caso di prova. Poi si scopre: in primo luogo, non possiamo fidarci di nessuno e, in secondo luogo, quando finalmente scegliamo un sistema, dobbiamo ancora configurarlo correttamente. Queste impostazioni includono dozzine, quasi centinaia di parametri.
Agitare la bottiglia
E posso spiegare l’intero processo che abbiamo svolto ora con la seguente metafora: “Agitare la bottiglia”. Cioè ora non devi programmare, ora l'importante è saper leggere lo stackoverflow. E ho una persona nel mio team, un professionista, che lavora proprio così nei momenti critici.
Cosa sta facendo? Vede una cosa rotta, vede uno stack trace, ne prende alcune parole (quali sono le sue competenze nel programma), cerca su Google, trova stackoverflow tra le risposte. Senza leggere, senza pensare, tra le risposte alla domanda sceglie qualcosa di più simile alla frase “fai questo e quello” (scegliere una risposta del genere è il suo talento, perché non è sempre la risposta che ha ricevuto più like), si applica, sembra: se qualcosa è cambiato, allora bene. Se non è cambiato, ripristinalo. E ripeti launch-check-search. E in questo modo intuitivo si assicura che il codice funzioni dopo un po' di tempo. Non sa perché, non sa cosa ha fatto, non riesce a spiegarlo. Ma! Questa infezione funziona. E «il fuoco è spento». Ora scopriamo cosa abbiamo fatto. Quando il programma funziona, è molto più semplice. E fa risparmiare molto tempo.
Questo metodo è spiegato molto bene con questo esempio.
Un tempo era molto popolare raccogliere una barca a vela in una bottiglia. Allo stesso tempo, la barca a vela è grande e fragile, e il collo della bottiglia è molto stretto, è impossibile spingerla dentro. Come assemblarlo?
Esiste un metodo del genere, molto veloce e molto efficace.
La nave è composta da un mucchio di piccole cose: bastoncini, corde, vele, colla. Mettiamo tutto questo in una bottiglia.
Prendiamo la bottiglia con entrambe le mani e iniziamo a tremare. La scuotiamo e la scuotiamo. E di solito si rivela tutta spazzatura, ovviamente. Ma a volte. A volte risulta essere una nave! Più precisamente, qualcosa di simile a una nave.
Mostriamo questo qualcosa a qualcuno: "Seryoga, vedi!?" E in effetti da lontano sembra una nave. Ma non si può permettere che ciò continui.
C'è un altro modo. Sono utilizzati da ragazzi più avanzati, come gli hacker.
Ho dato un compito a questo ragazzo, ha fatto tutto e se n'è andato. E guarda: sembra che sia finito. E dopo un po', quando il codice deve essere finalizzato, tutto inizia a causa sua... Meno male che è già riuscito a scappare lontano. Questi sono i ragazzi che, usando l'esempio di una bottiglia, faranno questo: vedi, dove c'è il fondo, il vetro si piega. E non è del tutto chiaro se sia trasparente o meno. Poi gli "hacker" hanno tagliato questo fondo, vi hanno inserito una nave, poi hanno incollato di nuovo il fondo, ed è come se fosse così che dovrebbe essere.
Dal punto di vista dell'impostazione del problema, tutto sembra essere corretto. Ma usando le navi come esempio: perché costruire questa nave, chi ne ha bisogno comunque? Non fornisce alcuna funzionalità. Di solito tali navi sono regali a persone di alto rango, che le mettono su uno scaffale sopra di loro, come una sorta di simbolo, come un segno. E se una persona del genere, il capo di una grande azienda o un funzionario di alto rango, come rappresenterà la bandiera per un simile hack, il cui collo è stato tagliato? Sarebbe meglio se non lo sapesse mai. Allora, come finiscono per realizzare queste navi che possono essere regalate a una persona importante?
L'unico posto chiave per il quale non puoi davvero fare nulla è il corpo. E lo scafo della nave si adatta perfettamente al collo. Mentre la nave è assemblata fuori dalla bottiglia. Ma non si tratta solo di assemblare una nave, è un vero e proprio mestiere di gioielleria. Ai componenti vengono aggiunte leve speciali che ne consentono poi il sollevamento. Ad esempio, le vele vengono piegate, portate con cura all'interno e poi, con l'aiuto di una pinzetta, vengono tirate e sollevate in modo molto preciso, con precisione. Il risultato è un'opera d'arte che può essere donata con coscienza pulita e orgoglio.
E se vogliamo che il progetto abbia successo, deve esserci almeno un gioielliere nel team. Qualcuno che ha a cuore la qualità del prodotto e tiene conto di tutti gli aspetti, senza sacrificare nulla, anche nei momenti di stress, quando le circostanze richiedono di fare l'urgente a scapito dell'importante. Tutti i progetti di successo, sostenibili e che hanno resistito alla prova del tempo, si basano su questo principio. C'è qualcosa di molto preciso e unico in loro, qualcosa che sfrutta tutte le possibilità disponibili. Nell'esempio con la nave nella bottiglia viene messo in scena il fatto che lo scafo della nave passa attraverso il collo.
Tornando al compito di scegliere il nostro server di caching, come potrebbe essere applicato questo metodo? Offro questa opzione di scelta tra tutti i sistemi esistenti: non agitare la bottiglia, non scegliere, ma guarda cosa hanno in linea di principio, cosa cercare quando si sceglie un sistema.
Dove cercare il collo di bottiglia
Cerchiamo di non agitare la bottiglia, di non esaminare tutto quello che c'è uno per uno, ma vediamo quali problemi sorgeranno se all'improvviso, per il nostro compito, progettiamo noi stessi un sistema del genere. Ovviamente non monteremo la bici, ma utilizzeremo questo schema per capire a quali punti prestare attenzione nelle descrizioni dei prodotti. Disegniamo un diagramma del genere.
Se il sistema è distribuito, avremo diversi server (6). Diciamo che ce ne sono quattro (è conveniente inserirli nella foto, ma ovviamente possono essercene quanti vuoi). Se i server si trovano su nodi diversi, significa che tutti eseguono del codice che è responsabile di garantire che questi nodi formino un cluster e, in caso di interruzione, si connettano e si riconoscano a vicenda.
Abbiamo anche bisogno della logica del codice (2), che in realtà riguarda la memorizzazione nella cache. I client interagiscono con questo codice tramite alcune API. Il codice client (1) può trovarsi all'interno della stessa JVM o accedervi tramite la rete. La logica implementata all'interno è la decisione di quali oggetti lasciare nella cache e quali buttare fuori. Usiamo la memoria (3) per archiviare la cache, ma se necessario possiamo salvare alcuni dati su disco (4).
Vediamo in quali parti avverrà il carico. In realtà, ogni freccia e ogni nodo verranno caricati. Innanzitutto, tra il codice client e l'API, se si tratta di comunicazione di rete, il cedimento può essere abbastanza evidente. In secondo luogo, nell'ambito dell'API stessa, se esageriamo con la logica complessa, possiamo riscontrare problemi con la CPU. E sarebbe bello se la logica non perdesse tempo con la memoria. E rimane l'interazione con il file system: nella versione normale si tratta di serializzare / ripristinare e scrivere / leggere.
La prossima è l'interazione con il cluster. Molto probabilmente sarà nello stesso sistema, ma potrebbe essere separato. Qui è anche necessario tenere conto del trasferimento dei dati ad esso, della velocità di serializzazione dei dati e delle interazioni tra il cluster.
Ora, da un lato, possiamo immaginare “quali ingranaggi gireranno” nel sistema di cache durante l'elaborazione delle richieste dal nostro codice e, dall'altro, possiamo stimare quali e quante richieste genererà il nostro codice per questo sistema. Questo è sufficiente per fare una scelta più o meno sobria: scegliere un sistema per il nostro caso d'uso.
Nocciola
Vediamo come applicare questa scomposizione alla nostra lista. Ad esempio, Hazelcast.
Per inserire/prendere dati da Hazelcast, il codice client accede (1) all'api. Hz consente di eseguire il server come incorporato e, in questo caso, l'accesso all'API è una chiamata di metodo all'interno della JVM, che può essere considerata gratuita.
Affinché la logica in (2) funzioni, Hz si basa sull'hash dell'array di byte della chiave serializzata, ovvero la chiave verrà serializzata in ogni caso. Questo è un sovraccarico inevitabile per Hz.
Le strategie di sfratto sono implementate bene, ma per casi speciali puoi aggiungerne di tue. Non devi preoccuparti di questa parte.
È possibile collegare il contenitore (4). Grande. L'interazione (5) per embedded può essere considerata istantanea. Scambio di dati tra i nodi del cluster (6) - sì, esiste. Questo è un investimento nella tolleranza agli errori a scapito della velocità. La funzionalità Hz Near-cache ti consente di ridurre il prezzo: i dati ricevuti da altri nodi nel cluster verranno memorizzati nella cache.
Cosa si può fare in tali condizioni per aumentare la velocità?
Ad esempio, per evitare la serializzazione della chiave in (2), collega un'altra cache sopra Hazelcast, per i dati più importanti. Sportmaster ha scelto Caffeine per questo scopo.
Per la torsione al livello (6), Hz offre due tipi di archiviazione: IMap e ReplicatedMap.
Vale la pena ricordare come Hazelcast sia entrato nello stack tecnologico di Sportmaster.
Nel 2012, quando stavamo lavorando al primissimo progetto pilota del futuro sito, è stato Hazelcast a rivelarsi il primo collegamento restituito dal motore di ricerca. La conoscenza è iniziata "la prima volta": siamo rimasti affascinati dal fatto che solo due ore dopo, quando abbiamo avvitato Hz nel sistema, ha funzionato. E ha funzionato bene. Alla fine della giornata avevamo completato una serie di test ed eravamo soddisfatti. E questa riserva di vigore è bastata per superare le sorprese che Hz ha riservato nel tempo. Ora il team Sportmaster non ha motivo di abbandonare Hazelcast.
Ma argomenti come "il primo collegamento nel motore di ricerca" e "HelloWorld è stato raccolto rapidamente" sono, ovviamente, un'eccezione e una caratteristica del momento in cui è avvenuta la scelta. I veri test per il sistema scelto iniziano con il rilascio in produzione, ed è in questa fase che dovresti prestare attenzione nella scelta di qualsiasi sistema, compresa la cache. In realtà, nel nostro caso possiamo dire di aver scelto Hazelcast per caso, ma poi si è scoperto che abbiamo scelto correttamente.
Per la produzione, molto più importante: monitoraggio, gestione dei guasti sui singoli nodi, replica dei dati, costi di scalabilità. Cioè, vale la pena prestare attenzione ai compiti che si presenteranno durante la manutenzione del sistema: quando il carico è decine di volte superiore al previsto, quando carichiamo accidentalmente qualcosa nel posto sbagliato, quando dobbiamo lanciare una nuova versione del codice, sostituire i dati e farlo inosservato per i clienti.
Per tutti questi requisiti, Hazelcast è sicuramente all'altezza.
Continua
Ma Hazelcast non è una panacea. Nel 2017 abbiamo scelto Hazelcast per la cache di amministrazione, semplicemente basandoci sulle buone impressioni derivanti dall'esperienza passata. Ciò ha avuto un ruolo chiave in uno scherzo molto crudele, a causa del quale ci siamo trovati in una situazione difficile e ne siamo usciti “eroicamente” per 60 giorni. Ma ne parleremo più avanti nella parte successiva.
Nel frattempo... Buon Nuovo Codice!
Fonte: habr.com