{"id":73949,"date":"2020-03-13T02:42:07","date_gmt":"2020-03-12T23:42:07","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1"},"modified":"2020-03-13T02:42:07","modified_gmt":"2020-03-12T23:42:07","slug":"kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1","title":{"rendered":"Come abbiamo scelto il sistema di caching in Sportmaster. Parte 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ciao! Mi chiamo Alexey P'yankov e sono uno sviluppatore per l'azienda Sportmaster. In questo post<\/a><\/noindex> ho raccontato come \u00e8 iniziato il lavoro sul sito di Sportmaster nel 2012, quali iniziative siamo riusciti a \"spingere\" e, al contrario, quali difficolt\u00e0 abbiamo affrontato.<\/p>\n

Oggi voglio condividere alcune riflessioni che seguono un'altra trama: la scelta del sistema di caching per il backend Java nell'amministratore del sito. Questo tema ha un significato speciale per me: sebbene la storia si sia sviluppata in soli 2 mesi, in questi 60 giorni abbiamo lavorato 12-16 ore al giorno senza un giorno di riposo. Non avevo mai pensato n\u00e9 immaginato di poter lavorare cos\u00ec tanto.<\/p>\n

Pertanto, divider\u00f2 il testo in 2 parti per non sovraccaricare. Anzi, la prima parte sar\u00e0 molto leggera: una preparazione, un'introduzione, alcune riflessioni su cosa sia il caching. Se siete gi\u00e0 sviluppatori esperti o avete lavorato con i cache, dal punto di vista tecnico probabilmente non troverete nulla di nuovo in questo articolo. Ma per un junior, una piccola panoramica del genere potrebbe suggerire in quale direzione orientarsi, qualora si trovasse a un bivio del genere.<\/p>\n

\"Come<\/a><\/noindex>
\n<\/a><\/noindex>
\nQuando la nuova versione del sito di Sportmaster \u00e8 stata lanciata in produzione, i dati venivano forniti in un modo, per cos\u00ec dire, non molto conveniente. Erano utilizzate tabelle preparate per la versione precedente del sito (Bitrix), che dovevano essere integrate in ETL, ristrutturate e arricchite con vari dettagli provenienti da una decina di sistemi. Per far s\u00ec che una nuova immagine o una descrizione del prodotto apparissero sul sito, bisognava aspettare fino al giorno dopo \u2014 l'aggiornamento avveniva solo di notte, una volta al giorno.<\/p>\n

All'inizio c'erano cos\u00ec tante preoccupazioni nelle prime settimane di lancio in produzione che tali disagi per i content manager erano un dettaglio trascurabile. Ma, non appena tutto si \u00e8 stabilizzato, lo sviluppo del progetto \u00e8 continuato \u2014 dopo alcuni mesi, all'inizio del 2015, abbiamo iniziato a sviluppare attivamente il pannello di amministrazione. Nel 2015 e 2016 tutto andava bene, pubblicavamo regolarmente, il pannello di amministrazione copriva una parte sempre maggiore della preparazione dei dati e ci preparavamo a ci\u00f2 che presto sarebbe stato affidato al nostro team: la gestione completa dei prodotti (preparazione e monitoraggio dei dati su tutti i prodotti). Ma nell'estate del 2017, proprio prima del lancio della gestione dei prodotti, il progetto si trov\u00f2 in una situazione molto difficile \u2014 proprio a causa di problemi di caching. Questo episodio \u00e8 quello di cui voglio parlare nella seconda parte di questa pubblicazione in due serie.<\/p>\n

Ma in questo post voglio partire da lontano, riassumendo alcune riflessioni \u2014 idee sul caching, che sarebbe stato utile approfondire prima di avviare un grande progetto.<\/p>\n

Quando si presenta la necessit\u00e0 di caching<\/h2>\n

\nIl problema della cache non si presenta da solo. Noi siamo sviluppatori, creiamo un prodotto software e desideriamo che sia richiesto. Se il prodotto \u00e8 richiesto e ha successo, gli utenti arrivano. E arrivano ancora e ancora. E cos\u00ec, ci sono molti utenti e il prodotto diventa ad alta capacit\u00e0 di carico.<\/p>\n

Nelle fasi iniziali non pensiamo all'ottimizzazione e alle prestazioni del codice. La cosa pi\u00f9 importante \u00e8 la funzionalit\u00e0, lanciare rapidamente un prototipo e testare le ipotesi. E se il carico aumenta, potenziamo l'hardware. Aumentiamo di due, tre, cinque, lasciate che sia dieci volte. A un certo punto, le finanze non lo permetteranno pi\u00f9. E di quanto aumenter\u00e0 il numero di utenti? Non sar\u00e0 solo 2-5-10, ma nel caso di successo, sar\u00e0 da 100-1000 fino a 100.000 volte. Quindi, prima o poi, dovremo affrontare l'ottimizzazione.<\/p>\n

Supponiamo che una parte di codice (chiamiamola funzione) stia impiegando un tempo incredibilmente lungo per l'esecuzione e vogliamo ridurre il tempo necessario. La funzione pu\u00f2 essere un accesso a un database, un\u2019esecuzione di una logica complessa: l'importante \u00e8 che sia quello a risultare lungo. Di quanto possiamo ridurre il tempo di esecuzione? Teoricamente, fino a zero, non oltre. Ma come possiamo ridurre il tempo di esecuzione a zero? Risposta: eliminando completamente l'esecuzione. Invece, restituiamo immediatamente il risultato. Ma come possiamo sapere qual \u00e8 il risultato? Risposta: o calcolandolo o osservandolo da qualche parte. Calcolarlo richiede tempo. E osservarlo significa, ad esempio, ricordare il risultato fornito dalla funzione l'ultima volta che \u00e8 stata chiamata con gli stessi parametri.<\/p>\n

Cio\u00e8, l'implementazione della funzione non \u00e8 importante per noi. \u00c8 sufficiente sapere da quali parametri dipende il risultato. Allora, se i valori dei parametri vengono presentati come un oggetto che pu\u00f2 essere utilizzato come chiave in un certo archivio, possiamo salvare il risultato del calcolo e al prossimo accesso leggerlo. Se queste operazioni di scrittura e lettura del risultato avvengono pi\u00f9 rapidamente dell'esecuzione della funzione, abbiamo un guadagno in termini di velocit\u00e0. L'entit\u00e0 del guadagno pu\u00f2 arrivare a 100, 1000, e anche 100.000 volte (10^5 \u00e8 pi\u00f9 un'eccezione, ma nel caso di un database che lagga significativamente, \u00e8 del tutto possibile).<\/p>\n

Requisiti principali per il sistema di caching<\/h2>\n

\nLa prima cosa che pu\u00f2 diventare un requisito per il sistema di caching \u00e8 la rapida velocit\u00e0 di lettura e, in misura leggermente minore, la velocit\u00e0 di scrittura. \u00c8 vero, ma solo fino a quando non distribuiamo il sistema in produzione.<\/p>\n

Giocando un caso come questo.<\/p>\n

Supponiamo di aver attrezzato l'hardware per il carico attuale e ora stiamo gradualmente implementando la cache. Il numero di utenti cresce lentamente, aumentando il carico: aggiungiamo un po' di cache qui e l\u00e0. Questo continua per un certo periodo, e ora le funzioni pesanti praticamente non vengono pi\u00f9 chiamate: tutto il carico principale ricade sulla cache. Durante questo tempo, il numero di utenti \u00e8 aumentato di N volte.<\/p>\n

E se l'approvvigionamento iniziale dell'hardware poteva essere 2-5 volte, grazie alla cache possiamo aumentare le prestazioni fino a 10 volte o, nei migliori casi, anche 100 volte, a volte, forse anche 1000. Cio\u00e8, con lo stesso hardware, gestiamo 100 volte pi\u00f9 richieste. Fantastico, meritato un premio!<\/p>\n

Ma ora, a un certo punto, per caso, il sistema ha subito un guasto e la cache \u00e8 crollata. Niente di particolare: infatti, la cache \u00e8 stata scelta con la richiesta di 'alta velocit\u00e0 di lettura e scrittura, il resto non importa'.<\/p>\n

Rispetto al carico di avvio, la nostra capacit\u00e0 hardware era 2-5 volte superiore, mentre nel frattempo il carico \u00e8 aumentato di 10-100 volte. Con la cache abbiamo evitato le chiamate per le funzioni pesanti e quindi tutto funzionava senza problemi. Ora, senza cache, di quanto si ridurr\u00e0 il nostro sistema? Cosa succeder\u00e0? Il sistema va in crash.<\/p>\n

Anche se la nostra cache non \u00e8 crollata, ma si \u00e8 solo svuotata temporaneamente, sar\u00e0 necessario riscaldarla, e questo richieder\u00e0 un certo tempo. Durante questo periodo, il carico principale ricadr\u00e0 sulle funzionalit\u00e0.<\/p>\n

Conclusione: i progetti a elevato carico in produzione richiedono dal sistema di caching non solo un'elevata velocit\u00e0 di lettura e scrittura, ma anche integrit\u00e0 dei dati e resilienza ai guasti.<\/p>\n

Il tormento della scelta<\/h2>\n

\nNel progetto con l'interfaccia di amministrazione, la scelta \u00e8 stata la seguente: inizialmente abbiamo implementato Hazelcast, poich\u00e9 eravamo gi\u00e0 familiari con questo prodotto grazie all'esperienza del sito principale. Tuttavia, questa scelta si \u00e8 rivelata infelice: per il nostro profilo di carico, Hazelcast non solo funziona lentamente, ma \u00e8 incredibilmente lento. E per i tempi di rilascio in produzione, a quel punto avevamo gi\u00e0 firmato.<\/p>\n

Spoiler: vi racconter\u00f2 nella seconda parte come si sono svolti gli eventi che ci hanno portato a perdere una tale opportunit\u00e0 e come ci siamo ritrovati in una situazione difficile e tesa \u2013 e come ne siamo usciti. Ma per ora dir\u00f2 solo che \u00e8 stato un grande stress, e 'pensare \u2013 non si riesce a pensare, scuotiamo la bottiglia'. 'Scuotiamo la bottiglia' \u00e8 anche uno spoiler, di questo parler\u00f2 pi\u00f9 avanti.<\/p>\n

Cosa abbiamo fatto:<\/p>\n

    \n
  1. Abbiamo stilato un elenco di tutti i sistemi suggeriti da Google e StackOverflow. Un po' pi\u00f9 di 30.<\/li>\n
  2. Scriviamo test con un carico tipico per l'ambiente di produzione. Per questo abbiamo registrato dati che passano attraverso il sistema in un ambiente di produzione \u2014 una sorta di sniffer per dati non in rete, ma all'interno del sistema. Nei test abbiamo utilizzato proprio questi dati.<\/li>\n
  3. Tutta la squadra, ognuno sceglie il prossimo sistema dall'elenco, lo configura, esegue i test. Se il test non va a buon fine, non regge il carico \u2013 lo scartiamo e passiamo al successivo in coda.<\/li>\n
  4. Alla 17\u00aa sistemazione \u00e8 diventato chiaro che tutto era senza speranza. Basta 'scuotere la bottiglia', \u00e8 tempo di pensare seriamente.<\/li>\n<\/ol>\n

    \nQuesta \u00e8 l'opzione quando si deve scegliere un sistema che \u00abeccelle in velocit\u00e0\u00bb nei test preparati. Ma se non ci sono ancora test e si desidera scegliere qualcosa di pi\u00f9 veloce?<\/p>\n

    Immaginiamo un tale scenario (\u00e8 difficile pensare che uno sviluppatore di livello intermedio viva in un vacuum, e al momento della scelta non abbia gi\u00e0 espresso una preferenza su quale prodotto provare per primo \u2014 quindi, le riflessioni successive sono pi\u00f9 teoriche\/filosofiche\/riguardanti un junior).<\/p>\n

    Dopo aver definito i requisiti, cominciamo a scegliere una soluzione out-of-the-box. Perch\u00e9 reinventare la ruota: andremo a prendere un sistema di caching gi\u00e0 pronto.<\/p>\n

    Se stai appena cominciando a cercare su Google, avrai un'idea generale dell'ordine, ma in sostanza, i riferimenti saranno questi. Per prima cosa, ti imbatterai in Redis, che \u00e8 molto noto. Poi scoprirai che esiste EhCache, come il sistema pi\u00f9 longevo e collaudato. Successivamente si parler\u00e0 di Tarantool \u2014 una soluzione nazionale con un aspetto unico. E ci sar\u00e0 anche Ignite, poich\u00e9 attualmente sta guadagnando popolarit\u00e0 e gode del supporto di SberTech. Infine, Hazelcast, poich\u00e9 nel mondo enterprise spesso appare tra le grandi aziende.<\/p>\n

    Questo elenco non \u00e8 esaustivo, esistono decine di sistemi. Ne prenderemo solo uno. Selezioniamo 5 sistemi per un \"concorso di bellezza\" e procederemo con la selezione. Chi sar\u00e0 il vincitore?<\/p>\n

    Redis<\/h3>\n

    \nLeggiamo cosa scrivono sul sito ufficiale.
    \n    Redis<\/a><\/noindex> \u2014 progetto open-source. Offre uno storage dei dati in memoria, la possibilit\u00e0 di salvataggio su disco, partizionamento automatico, alta disponibilit\u00e0 e ripristino dopo interruzioni di rete.<\/p>\n

    Sembra tutto fantastico, possiamo prenderlo e integrarlo \u2014 fa tutto ci\u00f2 di cui hai bisogno. Ma daremo un'occhiata anche agli altri candidati, per curiosit\u00e0.<\/p>\n

    EhCache<\/h3>\n

    \nEhCache<\/a><\/noindex> \u2014 \"il cache pi\u00f9 ampiamente utilizzato per Java\" (traduzione dello slogan dal sito ufficiale). Anche questo \u00e8 open-source. Qui comprendiamo che Redis non \u00e8 specifico per Java, \u00e8 generico, e ha bisogno di un wrapper per interagire con esso. EhCache risulta essere pi\u00f9 comodo. Cosa promette ancora il sistema? Affidabilit\u00e0, comprovata esperienza, funzionalit\u00e0 complete. Inoltre, \u00e8 anche il pi\u00f9 diffuso. E cachea terabyte di dati.<\/p>\n

    Redis \u00e8 dimenticato, sono pronto a scegliere EhCache.<\/p>\n

    Ma un senso di patriottismo mi spinge a scoprire perch\u00e9 Tarantool sia buono.<\/p>\n

    Tarantool<\/h3>\n

    \nTarantool<\/a><\/noindex> \u2014 si presenta come \"Piattaforma di integrazione dati in tempo reale\". Suona molto complicato, quindi leggiamo la pagina con attenzione per trovare l'affermazione audace: \"Memorizza il 100% dei dati nella RAM\". Questo dovrebbe sollevare domande, poich\u00e9 i dati possono essere significativamente pi\u00f9 numerosi della memoria disponibile. La spiegazione \u00e8 che qui si intende che per registrare i dati su disco dalla memoria, Tarantool non esegue la serializzazione. Invece, sfrutta caratteristiche a basso livello del sistema, in cui la memoria \u00e8 semplicemente mappata sul file system con indicatori di I\/O piuttosto buoni. Insomma, hanno fatto qualcosa di davvero straordinario e interessante.<\/p>\n

    Guardiamo le implementazioni: Mail.ru, la rete aziendale, Avito, Beeline, MegaFon, Alfa-Bank, Gazprom\u2026<\/p>\n

    Se ci fossero ancora dei dubbi riguardo a Tarantool, il caso di implementazione in Mastercard mi convince del tutto. Prendo Tarantool.<\/p>\n

    Ma comunque\u2026<\/p>\n

    Ignite<\/h3>\n

    \n\u2026 c'\u00e8 ancora Ignite<\/a><\/noindex>, dichiarato come \u00abpiattaforma di calcolo in-memory... velocit\u00e0 in-memory su petabyte di dati\u00bb. Ci sono anche molti vantaggi: caching in-memory distribuito, il pi\u00f9 veloce sistema di memorizzazione chiave-valore e caching, scalabilit\u00e0 orizzontale, alta disponibilit\u00e0, integrit\u00e0 rigorosa. In sostanza, si rivela che il pi\u00f9 veloce \u00e8 Ignite.<\/p>\n

    Implementazioni: Sberbank, American Airlines, Yahoo! Japan. E poi scopro anche che Ignite non \u00e8 solo implementato in Sberbank, ma il team di SberTech invia le proprie persone nel team di Ignite per migliorare il prodotto. Questo mi conquista completamente e sono pronto a scegliere Ignite.<\/p>\n

    Non capisco affatto perch\u00e9, guardo il quinto punto.<\/p>\n

    Hazelcast<\/h3>\n

    \nVisito il sito Hazelcast<\/a><\/noindex>, leggo. E si scopre che la soluzione pi\u00f9 veloce per la memorizzazione cache distribuita \u00e8 Hazelcast. \u00c8 di gran lunga pi\u00f9 veloce rispetto a tutte le altre soluzioni ed \u00e8, in effetti, il leader nel campo dei data grid in-memory. In questo contesto, scegliere qualcos'altro sarebbe mancarsi di rispetto. Inoltre, utilizza la memorizzazione ridondante dei dati per garantire il funzionamento continuo del cluster senza perdita di dati.<\/p>\n

    Bene, sono pronto a scegliere Hazelcast.<\/p>\n

    Confronto<\/h2>\n

    \nMa se guardiamo, tutti e cinque i candidati sono presentati in modo tale che ognuno di loro \u00e8 il migliore. Come scegliere? Possiamo vedere quale \u00e8 il pi\u00f9 popolare, cercare confronti e cos\u00ec il mal di testa svanisce.<\/p>\n

    Troviamo questo panoramica<\/a><\/noindex>, scegliamo i nostri 5 sistemi.<\/p>\n

    \"Come
    \n
    \nQui sono ordinati: in cima Redis, al secondo posto \u2014 Hazelcast, stanno guadagnando popolarit\u00e0 Tarantool e Ignite, EhCache rimane com'era. <\/p>\n

    Ma diamo un'occhiata al metodo di calcolo<\/a><\/noindex>: link ai siti web, interesse generale per il sistema, offerte di lavoro \u2014 fantastico! Cio\u00e8, quando il mio sistema fallir\u00e0, dir\u00f2: \u00abNo, \u00e8 affidabile! Ecco quante offerte di lavoro\u2026\u00bb. Un confronto cos\u00ec semplice non basta.<\/p>\n

    Tutti questi sistemi non sono solo sistemi di caching. Hanno anche molte altre funzionalit\u00e0, compreso il caso in cui non siano i dati a essere trasferiti al cliente per l'elaborazione, ma viceversa: il codice che deve essere eseguito sui dati si sposta sul server, viene eseguito l\u00ec e il risultato viene restituito. E come sistema separato per il caching non viene considerato molto spesso.<\/p>\n

    Bene, non ci arrendiamo, troviamo un confronto diretto tra i sistemi. Prendiamo i due primi varianti \u2014 Redis e Hazelcast. Siamo interessati alla velocit\u00e0, confronteremo in base a questo parametro.<\/p>\n

    Hz vs Redis<\/h3>\n

    \nTroviamo qualcosa confronto<\/a><\/noindex>:
    \n\"Come
    \n
    \nBlu \u00e8 Redis, rosso \u00e8 Hazelcast. Hazelcast vince ovunque, e questo \u00e8 giustificato: \u00e8 multithreading, altamente ottimizzato, ogni thread lavora con la propria partizione, quindi non ci sono blocchi. Redis, invece, \u00e8 monothread, e non sfrutta i moderni CPU multicore. Hazelcast utilizza I\/O asincrono, mentre Redis-Jedis ha socket bloccanti. Infine, Hazelcast utilizza un protocollo binario, mentre Redis \u00e8 orientato al testo, il che significa che \u00e8 inefficiente.<\/p>\n

    Per sicurezza, diamo un'occhiata a un'altra fonte di confronto. Cosa ci mostrer\u00e0?<\/p>\n

    Redis vs Hz<\/h3>\n

    \nUn'altra cosa confronto<\/a><\/noindex>:
    \n\"Come
    \n
    \nQui \u00e8 il contrario, rosso \u00e8 Redis. Cio\u00e8, Redis ha prestazioni migliori rispetto a Hazelcast. Nel primo confronto ha vinto Hazelcast, nel secondo Redis.     Qui<\/a><\/noindex> hanno spiegato esattamente perch\u00e9 nel precedente confronto ha vinto Hazelcast.<\/p>\n

    Si scopre che il risultato del primo \u00e8 stato in realt\u00e0 manipolato: Redis \u00e8 stato preso in un pacchetto base, mentre Hazelcast \u00e8 stato ottimizzato per il caso di test. Quindi, in primo luogo, non si pu\u00f2 credere a nessuno, in secondo luogo, quando infine scegliamo un sistema, dobbiamo ancora configurarlo correttamente. Queste configurazioni comprendono decine, quasi centinaia di parametri.<\/p>\n

    Scuotiamo la bottiglia<\/h2>\n

    \nE l'intero processo che abbiamo appena svolto lo posso spiegare usando la metafora \"Scuotere la bottiglia\". In altre parole, in questo momento non \u00e8 necessario programmare, ci\u00f2 che conta \u00e8 sapere leggere stackoverflow. E nella mia squadra c'\u00e8 una persona, un professionista, che lavora esattamente in questo modo nei momenti critici.<\/p>\n

    Cosa fa? Vede un oggetto non funzionante, osserva lo stack trace, prende alcune parole da esso (quali esattamente \u00e8 la sua competenza nel programma), cerca su Google, trova Stack Overflow tra le risposte. Senza leggere n\u00e9 riflettere, tra le risposte alla domanda, sceglie qualcosa di simile alla proposta \u00abfare questo e quello\u00bb (scegliere una risposta del genere \u00e8 il suo talento, poich\u00e9 non sempre \u00e8 quella che ha ricevuto il maggior numero di like), applica, osserva: se qualcosa \u00e8 cambiato, ottimo. Se non \u00e8 cambiato, ripristiniamo. E ripetiamo l'esecuzione-verifica-ricerca. E in questo modo intuitivo, riesce a far funzionare il codice dopo un certo tempo. Non sa perch\u00e9, non sa cosa ha fatto, non riesce a spiegare. Ma! Questa cosa funziona. E \u00abl'incendio \u00e8 spento\u00bb. Ora cerchiamo di capire cosa abbiamo fatto. Quando il programma funziona, \u00e8 molto pi\u00f9 facile. E fa risparmiare un sacco di tempo.<\/p>\n

    Questo metodo \u00e8 ben spiegato con un esempio del genere.<\/p>\n

    Un tempo era molto popolare costruire una nave in bottiglia. La nave \u00e8 grande e fragile, mentre il collo della bottiglia \u00e8 molto stretto, non pu\u00f2 essere spinto dentro. Come si pu\u00f2 assemblare?<\/p>\n

    \"Come
    \n
    \nC'\u00e8 un metodo, molto veloce e molto efficace.<\/p>\n

    La nave \u00e8 composta da tante piccole cose: bastoncini, corde, vele, colla. Tutto questo lo mettiamo nella bottiglia.
    \nPrendiamo la bottiglia con entrambe le mani e iniziamo a scuoterla. La scuotiamo e scuotiamo. E di solito \u2013 viene fuori un pasticcio, certo. Ma a volte. A volte esce una nave! Piuttosto, qualcosa che assomiglia a una nave.<\/p>\n

    Mostriamo questa cosa a qualcuno: \u00abSerjoga, vedi!?\u00bb. E davvero, da lontano \u2013 sembra una nave. Ma oltre a questo non si pu\u00f2 andare.<\/p>\n

    C'\u00e8 un altro modo. I ragazzi pi\u00f9 esperti, tipo i 'hacker', lo usano.<\/p>\n

    Ho dato a un tipo come questo un compito, ha fatto tutto ed \u00e8 andato. E guardi \u2013 sembra fatto. Ma dopo un po', quando bisogna rielaborare il codice \u2013 le cose iniziano a complicarsi a causa sua... Buono che era gi\u00e0 lontano. Sono quei ragazzi che prendono l'esempio della bottiglia e fanno cos\u00ec: vedete, dove c'\u00e8 il fondo \u2013 il vetro si piega. E non \u00e8 proprio chiaro se \u00e8 trasparente o meno. Allora i 'hacker' tagliano via quel fondo, infilano la nave, poi riattaccano il fondo e sembra che sia cos\u00ec che deve essere.<\/p>\n

    Dal punto di vista della formulazione del problema sembra tutto corretto. Ma prendiamo l'esempio delle navi: perch\u00e9 realizzare questa nave, a chi serve davvero? Non ha alcuna funzionalit\u00e0 pratica. Di solito, queste navi sono regali per persone di alto rango, che le posizionano su uno scaffale come simbolo o segno distintivo. E se una tale persona, un grande imprenditore o un alto funzionario, dovesse avere come vessillo un lavoro di questo tipo, con il collo rotto? \u00c8 meglio che non lo scopra mai. Ma come vengono davvero realizzate queste navi che possono essere donate a persone importanti?<\/p>\n

    L'unico aspetto, cruciale, su cui non si pu\u00f2 fare nulla \u00e8 il corpo della nave. Ed \u00e8 proprio il corpo della nave a passare attraverso il collo della bottiglia. Mentre la nave viene assemblata al di fuori della bottiglia. Ma non si tratta semplicemente di assemblare la nave, \u00e8 un vero e proprio lavoro di precisione artigianale. Si aggiungono leve speciali ai componenti, che permettono poi di sollevarli. Ad esempio, le vele vengono piegate, inserite con cura all'interno e poi, con l'aiuto di pinzette, vengono tirate su con grande precisione. Alla fine, si ottiene un'opera d'arte che pu\u00f2 essere regalata con grande orgoglio e senza esitazione.<\/p>\n

    E se vogliamo che il progetto abbia successo, nella squadra deve esserci almeno una persona artigiana. Qualcuno che si prende cura della qualit\u00e0 del prodotto e considera tutti gli aspetti, senza sacrificare nulla, nemmeno nei momenti di stress, quando \u00e8 necessario fare qualcosa di urgente a discapito dell'importante. Tutti i progetti di successo, quelli che sono resistenti, che hanno superato la prova del tempo, sono basati su questo principio. In essi c'\u00e8 qualcosa di molto preciso e unico, qualcosa che utilizza tutte le opportunit\u00e0 disponibili. Nell'esempio della nave nella bottiglia si gioca sul fatto che lo scafo della nave passa attraverso il collo.<\/p>\n

    Tornando al compito di scegliere il nostro server di caching, come si potrebbe applicare questo metodo? Propongo di non scuotere la bottiglia, non di selezionare, ma di guardare cosa c'\u00e8 in esse che merita attenzione nella scelta del sistema.<\/p>\n

    Dove cercare il collo di bottiglia<\/h2>\n

    \nProviamo a non scuotere la bottiglia e non a esaminare tutto quello che abbiamo uno dopo l'altro, ma vediamo quali problemi potrebbero sorgere se dovessimo progettare un sistema del genere da soli. Certo, non ci metteremo a costruire una bicicletta, ma utilizzeremo questo schema per orientarci sui punti da considerare nelle descrizioni dei prodotti. Creiamo uno schema del genere.<\/p>\n

    \"Come
    \n
    \nSe il sistema \u00e8 distribuito, avremo diversi server (6). Supponiamo quattro (\u00e8 comodo rappresentarli in un'immagine, ma ovviamente possono essere quanti ne vogliamo). Se i server sono su nodi diversi, significa che su di essi gira il codice che fa in modo che questi nodi formino un cluster e, in caso di disconnessione, si ricolleghino e riconoscano tra loro.<\/p>\n

    Abbiamo anche bisogno di codice-logica (2) per il caching. Con questo codice interagiscono i clienti attraverso un certo API. Il codice client (1) pu\u00f2 trovarsi all'interno della stessa JVM o accedervi tramite rete. La logica implementata internamente riguarda quali oggetti mantenere nella cache e quali eliminare. Per memorizzare la cache utilizziamo la memoria (3), ma se necessario, possiamo anche salvare parte dei dati su disco (4).<\/p>\n

    Vediamo in quali parti si andr\u00e0 a generare il carico. In effetti, ogni freccia e ogni nodo saranno sotto pressione. Prima di tutto, tra il codice client e l'API, se si tratta di interazione di rete, il calo delle prestazioni pu\u00f2 essere piuttosto evidente. In secondo luogo, all'interno dell'API stessa \u2014 se si esagera con logiche complesse, possiamo incappare nel CPU. Sarebbe meglio se la logica non usasse la memoria inutilmente. Rimane poi l'interazione con il file system \u2013 in una situazione normale si tratta di serializzare \/ ripristinare e scrivere \/ leggere.<\/p>\n

    Poi c'\u00e8 l'interazione con il cluster. Probabilmente sar\u00e0 nella stessa infrastruttura, ma potrebbe anche essere separata. Anche qui \u00e8 necessario considerare il trasferimento dei dati, la velocit\u00e0 di serializzazione e l'interazione tra i cluster.<\/p>\n

    Ora, da un lato \u2013 possiamo immaginare \"quali ingranaggi gireranno\" nel sistema di cache durante l'elaborazione delle richieste dal nostro codice, e dall'altro lato \u2013 possiamo stimare quante e quali richieste il nostro codice generer\u00e0 verso questo sistema. Queste informazioni sono sufficienti per fare una scelta ragionata \u2013 selezionare un sistema adatto al nostro caso d'uso.<\/p>\n

    Hazelcast<\/b><\/p>\n

    Vediamo come applicare questa decomposizione alla nostra lista. Ad esempio, Hazelcast.<\/p>\n

    Per inserire\/recuperare dati da Hazelcast, il codice client si riferisce (1) all'api. Hz consente di avviare il server come embedded e, in questo caso, la chiamata all'api \u00e8 una chiamata a un metodo all'interno della JVM, quindi pu\u00f2 essere considerata gratuita.<\/p>\n

    Per il funzionamento della logica in (2), Hz si basa sull'hash di un array di byte serializzato della chiave, ovvero la serializzazione della chiave avverr\u00e0 in ogni caso. Questo \u00e8 un overhead inevitabile per Hz.
    \nLe strategie di eviction sono ben implementate, ma in casi particolari \u00e8 possibile collegare le proprie. Non \u00e8 necessario preoccuparsi di questa parte.<\/p>\n

    Il repository (4) pu\u00f2 essere collegato. Ottimo. L'interazione (5) per l'embedded pu\u00f2 essere considerata istantanea. Lo scambio di dati tra i nodi nel cluster (6) \u2013 s\u00ec, c'\u00e8. Questo contribuisce alla resilienza sacrificando la velocit\u00e0. Hz ha la funzionalit\u00e0 Near-cache che riduce i costi: i dati ottenuti da altri nodi del cluster verranno memorizzati nella cache.<\/p>\n

    Cosa si pu\u00f2 fare in queste condizioni per aumentare la velocit\u00e0?<\/p>\n

    Ad esempio, per evitare la serializzazione della chiave in (2) \u2013 sopra Hazelcast si pu\u00f2 aggiungere un altro cache, per i dati pi\u00f9 critici. In Sportmaster, per questo scopo, \u00e8 stato scelto Caffeine.<\/p>\n

    Per la configurazione a livello (6), in Hz sono disponibili due tipi di archiviazione: IMap e ReplicatedMap.
    \n\"Come
    \n
    \n\u00c8 interessante vedere come Hazelcast sia entrato nel stack tecnologico di Sportmaster.<\/p>\n

    Nel 2012, mentre lavoravamo al primo prototipo del futuro sito, Hazelcast \u00e8 stato il primo risultato fornito dal motore di ricerca. Il suo utilizzo \u00e8 stato immediato \u2014 ci ha colpito il fatto che dopo solo due ore dall'integrazione di Hz nel sistema, funzionava. E funzionava bene. Entro la fine della giornata avevamo scritto un certo numero di test e ci eravamo soddisfatti. Quella spinta iniziale \u00e8 stata sufficiente per superare le sorprese che Hz ha presentato nel tempo. Ora il team di Sportmaster non ha motivi per rinunciare a Hazelcast.<\/p>\n

    Tuttavia, argomenti come \u2018primo link nel motore di ricerca\u2019 e \u2018abbiamo rapidamente creato HelloWorld\u2019 sono, naturalmente, eccezioni e particolarit\u00e0 del momento in cui \u00e8 avvenuta la scelta. Le vere sfide per il sistema scelto iniziano con il passaggio alla produzione, ed \u00e8 a questo stadio che bisogna prestare attenzione quando si sceglie qualsiasi sistema, incluso il caching. In effetti, nel nostro caso si pu\u00f2 dire che abbiamo scelto Hazelcast per caso, ma alla fine si \u00e8 rivelato essere la scelta giusta.<\/p>\n

    Per il production, \u00e8 molto pi\u00f9 importante: monitoraggio, gestione dei guasti su nodi singoli, replicazione dei dati e costo di scalabilit\u00e0. Vale a dire, \u00e8 fondamentale prestare attenzione alle sfide che emergeranno durante la gestione del sistema: quando il carico superer\u00e0 di decine di volte le previsioni, quando caricheremo accidentalmente qualcosa di sbagliato e in un posto sbagliato, e quando sar\u00e0 necessario rilasciare una nuova versione del codice, sostituire i dati, e farlo senza che i clienti se ne accorgano.<\/p>\n

    Per tutte queste esigenze, Hazelcast \u00e8 senza dubbio adatto.<\/p>\n

    Continua...<\/h2>\n

    \nMa Hazelcast non \u00e8 una panacea. Nel 2017 abbiamo scelto Hazelcast per la cache nell'interfaccia amministrativa, semplicemente basandoci sulla buona impressione del passato. Questo ha giocato un ruolo chiave in una spiacevole situazione, dalla quale siamo emersi \"eroicamente\" dopo 60 giorni. Ma di questo parleremo nella prossima parte.<\/p>\n

    Nel frattempo\u2026 Happy New Code!
    \n
    Fonte:     habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

    \u041f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041f\u044c\u044f\u043d\u043a\u043e\u0432, \u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440. \u0412 \u044d\u0442\u043e\u043c \u043f\u043e\u0441\u0442\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b, \u043a\u0430\u043a \u043d\u0430\u0447\u0438\u043d\u0430\u043b\u0430\u0441\u044c \u0440\u0430\u0431\u043e\u0442\u0430 \u043d\u0430\u0434 \u0441\u0430\u0439\u0442\u043e\u043c \u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440 \u0432 2012 \u0433\u043e\u0434\u0443, \u043a\u0430\u043a\u0438\u0435 \u0438\u043d\u0438\u0446\u0438\u0430\u0442\u0438\u0432\u044b \u0443\u0434\u0430\u043b\u043e\u0441\u044c \u00ab\u043f\u0440\u043e\u0442\u043e\u043b\u043a\u043d\u0443\u0442\u044c\u00bb \u0438 \u043d\u0430\u043e\u0431\u043e\u0440\u043e\u0442, \u043a\u0430\u043a\u0438\u0435 \u0433\u0440\u0430\u0431\u043b\u0438 \u043c\u044b \u0441\u043e\u0431\u0440\u0430\u043b\u0438. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u044f \u0445\u043e\u0447\u0443 \u043f\u043e\u0434\u0435\u043b\u0438\u0442\u044c\u0441\u044f \u043c\u044b\u0441\u043b\u044f\u043c\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0441\u043b\u0435\u0434\u0443\u044e\u0442 \u0437\u0430 \u0434\u0440\u0443\u0433\u0438\u043c \u0441\u044e\u0436\u0435\u0442\u043e\u043c \u2013 \u0432\u044b\u0431\u043e\u0440 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u043a\u0435\u0448\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0434\u043b\u044f java-\u0431\u044d\u043a\u0435\u043d\u0434\u0430 \u0432 \u0430\u0434\u043c\u0438\u043d\u043a\u0435 \u0441\u0430\u0439\u0442\u0430. \u042d\u0442\u043e\u0442 \u0441\u044e\u0436\u0435\u0442 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":73950,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-73949","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Come abbiamo scelto il sistema di caching in Sportmaster. Parte 1 | ProHoster","description":"Ciao! Mi chiamo Alexey Pyankov e sono uno sviluppatore presso Sportmaster. In questo post, ho raccontato come \u00e8 iniziato il lavoro sul sito di Sportmaster nel 2012, quali iniziative siamo riusciti a \"spingere\" e, al contrario, quali problemi abbiamo incontrato. Oggi voglio condividere alcuni pensieri che seguono un'altra storia: la scelta del sistema di caching per il backend Java nel pannello di amministrazione del sito.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u0430\u043a \u043c\u044b \u0432 \u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440\u0435 \u0432\u044b\u0431\u0438\u0440\u0430\u043b\u0438 \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u043a\u0435\u0448\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f. \u0427\u0430\u0441\u0442\u044c 1 | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041f\u044c\u044f\u043d\u043a\u043e\u0432, \u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440. \u0412 \u044d\u0442\u043e\u043c \u043f\u043e\u0441\u0442\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b, \u043a\u0430\u043a \u043d\u0430\u0447\u0438\u043d\u0430\u043b\u0430\u0441\u044c \u0440\u0430\u0431\u043e\u0442\u0430 \u043d\u0430\u0434 \u0441\u0430\u0439\u0442\u043e\u043c \u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440 \u0432 2012 \u0433\u043e\u0434\u0443, \u043a\u0430\u043a\u0438\u0435 \u0438\u043d\u0438\u0446\u0438\u0430\u0442\u0438\u0432\u044b \u0443\u0434\u0430\u043b\u043e\u0441\u044c \u00ab\u043f\u0440\u043e\u0442\u043e\u043b\u043a\u043d\u0443\u0442\u044c\u00bb \u0438 \u043d\u0430\u043e\u0431\u043e\u0440\u043e\u0442, \u043a\u0430\u043a\u0438\u0435 \u0433\u0440\u0430\u0431\u043b\u0438 \u043c\u044b \u0441\u043e\u0431\u0440\u0430\u043b\u0438. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u044f \u0445\u043e\u0447\u0443 \u043f\u043e\u0434\u0435\u043b\u0438\u0442\u044c\u0441\u044f \u043c\u044b\u0441\u043b\u044f\u043c\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0441\u043b\u0435\u0434\u0443\u044e\u0442 \u0437\u0430 \u0434\u0440\u0443\u0433\u0438\u043c \u0441\u044e\u0436\u0435\u0442\u043e\u043c \u2013 \u0432\u044b\u0431\u043e\u0440 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u043a\u0435\u0448\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0434\u043b\u044f java-\u0431\u044d\u043a\u0435\u043d\u0434\u0430 \u0432 \u0430\u0434\u043c\u0438\u043d\u043a\u0435 \u0441\u0430\u0439\u0442\u0430. \u042d\u0442\u043e\u0442 \u0441\u044e\u0436\u0435\u0442","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-03-12T23:42:07+00:00","article:modified_time":"2020-03-12T23:42:07+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"73949","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 18:23:51","updated":"2022-09-28 05:05:57"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/73949","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=73949"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/73949\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/73950"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=73949"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=73949"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=73949"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}