{"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 Aleksej P'jankov, sono uno sviluppatore presso l'azienda Sportmaster. In questo posto<\/a><\/noindex> ho raccontato come \u00e8 iniziata la lavorazione del sito Sportmaster nel 2012, quali iniziative siamo riusciti a \"spingere\" e, al contrario, quali ostacoli abbiamo incontrato.<\/p>\n

Oggi voglio condividere alcune riflessioni che seguono un'altra trama: la scelta del sistema di caching per il backend Java nell'admin del sito. Questa trama ha un significato particolare per me: anche se la storia si \u00e8 sviluppata in appena 2 mesi, in questi 60 giorni abbiamo lavorato per 12-16 ore al giorno senza un solo giorno di riposo. Non avevo mai pensato n\u00e9 immaginato che si potesse lavorare cos\u00ec tanto.<\/p>\n

Pertanto, divider\u00f2 il testo in due parti, per non sovraccaricare. Al contrario, la prima parte sar\u00e0 molto leggera: una preparazione, un'introduzione, alcune considerazioni su cosa sia il caching. Se sei gi\u00e0 un sviluppatore esperto o hai lavorato con i cache, dal punto di vista tecnico non ci sar\u00e0 nulla di nuovo in questo articolo. Ma per un junior, una piccola panoramica pu\u00f2 suggerire verso quale direzione guardare, qualora si trovasse in una situazione simile.<\/p>\n

\"Come<\/a><\/noindex>
\n<\/a><\/noindex>
\nQuando la nuova versione del sito Sportmaster \u00e8 stata lanciata in produzione, i dati venivano forniti in un modo, per usare un eufemismo, non molto comodo. La base era costituita da tabelle preparate per la precedente versione del sito (Bitrix), che dovevano essere caricate in ETL, adeguate al nuovo formato e arricchite con vari dettagli da una decina di sistemi. Affinch\u00e9 una nuova immagine o descrizione del prodotto apparisse sul sito, era necessario aspettare fino al giorno successivo: aggiornamento solo di notte, una volta al giorno.<\/p>\n

Inizialmente c'erano cos\u00ec tante preoccupazioni nelle prime settimane dopo il lancio in produzione, che tali disagi per i content manager erano considerati una questione minore. Ma, non appena tutto si \u00e8 sistemato, lo sviluppo del progetto \u00e8 continuato: dopo alcuni mesi, all'inizio del 2015 abbiamo iniziato a sviluppare attivamente l'admin. Nel 2015 e 2016 tutto andava bene, pubblicavamo regolarmente, l'admin copriva una parte sempre maggiore della preparazione dei dati e ci preparavamo al fatto che presto alla nostra squadra sarebbe stato affidato il compito pi\u00f9 importante e complesso: il contorno del prodotto (preparazione completa e gestione dei dati su tutti i prodotti). Ma nell'estate del 2017, proprio prima del lancio del contorno del prodotto, il progetto si trover\u00e0 in una situazione molto difficile: proprio a causa dei problemi con il caching. Di questo episodio voglio parlare nella seconda parte di questa pubblicazione in due episodi.<\/p>\n

Ma in questo post inizier\u00f2 da lontano, riassumendo alcune idee \u2013 concezioni sulla cache, scorrere le quali prima di un grande progetto sarebbe un buon passo.<\/p>\n

Quando si presenta il compito di caching<\/h2>\n

\nIl compito di caching non appare cos\u00ec senza motivo. Noi sviluppatori scriviamo un prodotto software e vogliamo che sia richiesto. Se il prodotto \u00e8 richiesto e ha successo, gli utenti aumentano. E ancora e ancora. Ecco che gli utenti diventano molti e allora il prodotto diventa ad alta intensit\u00e0 di utilizzo.<\/p>\n

Nelle fasi iniziali non pensiamo all'ottimizzazione e alle prestazioni del codice. L'importante \u00e8 la funzionalit\u00e0, rilasciare rapidamente un pilota e testare le ipotesi. E se il carico cresce, potenziamo l'hardware. Aumentiamo le risorse di due o tre volte, cinque, magari dieci. Qui i costi potrebbero non permetterselo pi\u00f9. E quante volte aumenter\u00e0 il numero degli utenti? Non saranno solo 2-5-10, ma in caso di successo potrebbe variare da 100 a 1000 fino a 100.000 volte. Quindi, prima o poi, dovremo occuparci dell'ottimizzazione.<\/p>\n

Supponiamo che una certa parte del codice (chiamiamo questa parte funzione) richieda un tempo inaccettabilmente lungo e vogliamo ridurre il tempo di esecuzione. La funzione pu\u00f2 essere un accesso al database, pu\u00f2 essere l'esecuzione di una logica complessa \u2013 l'importante \u00e8 che richieda tempo. Di quanto possiamo ridurre il tempo di esecuzione? In teoria, possiamo ridurlo a zero, non oltre. E come possiamo ridurre il tempo di esecuzione a zero? Risposta: escludendo completamente l'esecuzione. Invece di ci\u00f2, restituiamo subito il risultato. E come possiamo conoscere il risultato? Risposta: o lo calcoliamo, oppure lo controlliamo da qualche parte. Calcolare richiede tempo. Controllare significa, per esempio, memorizzare il risultato che la funzione ha restituito l'ultima volta che \u00e8 stata chiamata con gli stessi parametri.<\/p>\n

Cio\u00e8, l'implementazione della funzione non \u00e8 rilevante per noi. \u00c8 sufficiente sapere da quali parametri dipende il risultato. Quindi, se rappresentiamo i valori dei parametri come un oggetto da utilizzare come chiave in un certo storage, possiamo memorizzare il risultato del calcolo e, alla successiva richiesta, considerarlo. Se queste operazioni di scrittura e lettura del risultato avvengono pi\u00f9 velocemente dell'esecuzione della funzione, otteniamo un vantaggio in termini di velocit\u00e0. L'entit\u00e0 del vantaggio pu\u00f2 arrivare a 100, 1000 o anche 100.000 volte (10^5 \u00e8 piuttosto un'eccezione, ma nel caso di un database che lagga notevolmente, \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 velocit\u00e0 di lettura rapida e, in misura leggermente minore, la velocit\u00e0 di scrittura. \u00c8 vero, ma solo finch\u00e9 non implementiamo il sistema in produzione.<\/p>\n

Immaginiamo un caso del genere.<\/p>\n

Supponiamo di aver garantito l'hardware per il carico attuale e ora iniziamo lentamente a implementare il caching. Il numero di utenti cresce leggermente, aumenta il carico: aggiungiamo un po' di cache, la colleghiamo qua e l\u00e0. Cos\u00ec va avanti per un po', e adesso le funzioni pesanti praticamente non vengono pi\u00f9 chiamate: tutto il carico principale ricade sul cache. Nel frattempo, il numero di utenti \u00e8 aumentato di N volte.<\/p>\n

E se la riserva iniziale di hardware era di 2-5 volte, con l'aiuto del caching abbiamo potuto aumentare le prestazioni di 10 volte, o, nel miglior caso, di 100, e a volte anche di 1000. Cio\u00e8, con lo stesso hardware, elaboriamo 100 volte pi\u00f9 richieste. Ottimo, meritiamo un premio!<\/p>\n

Ma ora, a un certo punto, per caso, il sistema ha fallito e il cache \u00e8 crollato. Niente di speciale: abbiamo scelto il cache in base al requisito di \"alta velocit\u00e0 di lettura e scrittura, il resto non \u00e8 importante\".<\/p>\n

Relativamente al carico iniziale, avevamo una riserva di hardware di 2-5 volte, mentre il carico nel frattempo \u00e8 aumentato di 10-100 volte. Con l'aiuto del caching escludevamo le chiamate per le funzioni pesanti e quindi tutto volava. E ora, senza cache, di quanto il nostro sistema caler\u00e0? Cosa succeder\u00e0? Il sistema si fermer\u00e0.<\/p>\n

Anche se il nostro cache non \u00e8 crollato, ma solo svuotato per un certo periodo, sar\u00e0 necessario riscaldarlo, e questo richieder\u00e0 del tempo. E per quel periodo, il carico principale ricadr\u00e0 sulla funzionalit\u00e0.<\/p>\n

Conclusione: i progetti ad alta richiesta in produzione richiedono al sistema di caching non solo alta velocit\u00e0 di lettura e scrittura, ma anche integrit\u00e0 dei dati e resilienza ai guasti.<\/p>\n

Le difficolt\u00e0 della scelta<\/h2>\n

\nNel progetto con il pannello di amministrazione, la scelta \u00e8 andata cos\u00ec: inizialmente abbiamo installato 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 estremamente lentamente. E con le scadenze per la produzione, a quel punto ci eravamo gi\u00e0 impegnati.<\/p>\n

Spoiler: come si sono svolte le circostanze, che ci hanno fatto perdere un'opportunit\u00e0 e abbiamo ottenuto una situazione critica e tesa \u2013 lo racconter\u00f2 nella seconda parte \u2014 come siamo finiti, e come siamo usciti. Ma al momento, dir\u00f2 solo che \u00e8 stato un grande stress, e \"pensare \u2013 \u00e8 difficile pensare, scuotiamo la bottiglia\". \"Scuotiamo la bottiglia\" \u2014 \u00e8 anche uno spoiler, di questo parler\u00f2 pi\u00f9 avanti.<\/p>\n

Cosa abbiamo fatto:<\/p>\n

    \n
  1. Abbiamo compilato un elenco di tutti i sistemi suggeriti da Google e StackOverflow. Poco pi\u00f9 di 30.<\/li>\n
  2. Scriviamo test di carico, caratteristici per la produzione. Per questo abbiamo registrato i dati che passano attraverso il sistema nell'ambiente di produzione \u2014 una sorta di sniffing per i dati che non sono in rete, ma all'interno del sistema. Nei test abbiamo utilizzato esattamente questi dati.<\/li>\n
  3. Tutta la squadra, ciascuno sceglie il successivo sistema dall'elenco, lo configura e esegue i test. Se un test non passa, non regge il carico \u2013 lo scartiamo e passiamo al successivo in coda.<\/li>\n
  4. Alla 17esima sistema \u00e8 diventato chiaro che era tutto senza speranza. Basta \"scuotere la bottiglia\", \u00e8 ora di riflettere seriamente.<\/li>\n<\/ol>\n

    \nMa questo \u00e8 un caso in cui \u00e8 necessario scegliere un sistema che \"regga la velocit\u00e0\" nei test preimpostati. E se quei test non esistono ancora e si vuole scegliere pi\u00f9 rapidamente?<\/p>\n

    Simuliamo questo scenario (\u00e8 difficile immaginare che uno sviluppatore di livello intermedio+ viva nel vuoto, e al momento della scelta non abbia ancora messo a punto una preferenza su quale prodotto provare per primo \u2014 quindi, le ulteriori riflessioni sono, piuttosto, teoria \/ filosofia \/ riguardo a un junior).<\/p>\n

    Stabilite le esigenze, iniziamo a scegliere una soluzione pronta all'uso. Perch\u00e9 reinventare la ruota: andremo e prenderemo un sistema di caching gi\u00e0 pronto.<\/p>\n

    Se stai iniziando e cerchi su Google, l'ordine \u00e8 pi\u00f9 o meno casuale, ma in generale i riferimenti saranno questi. Prima di tutto ti imbatterai in Redis, che \u00e8 molto pubblicizzato. Poi scoprirai che c'\u00e8 EhCache, il sistema pi\u00f9 longevo e collaudato. Successivamente si parler\u00e0 di Tarantool - una creazione nazionale che ha un aspetto unico nella sua soluzione. E anche Ignite, perch\u00e9 al momento sta guadagnando popolarit\u00e0 e riceve supporto da SberTech. Infine parleremo di Hazelcast, poich\u00e9 nel mondo enterprise \u00e8 spesso citato tra le grandi aziende.<\/p>\n

    Ma la lista non si esaurisce qui, esistono decine di sistemi. E noi ne considereremo solo uno. Prenderemo cinque sistemi selezionati per un 'concorso di bellezza' e faremo una 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 una soluzione di archiviazione dati in memoria, con possibilit\u00e0 di salvataggio su disco, partizionamento automatico, alta disponibilit\u00e0 e recupero da interruzioni di rete.<\/p>\n

    Tutto sembra ottimo, \u00e8 possibile adoperarlo \u2014 fa esattamente ci\u00f2 di cui hai bisogno. Ma daremo un'occhiata anche agli altri candidati per pura curiosit\u00e0.<\/p>\n

    EhCache<\/h3>\n

    \nEhCache<\/a><\/noindex> \u2014 \"il cache pi\u00f9 ampiamente usato per Java\" (traduzione dello slogan dal sito ufficiale). Anch'esso open source. E qui ci rendiamo conto che Redis non \u00e8 specifico per Java, ma \u00e8 generico, e per interagire con esso \u00e8 necessaria un'astrazione. EhCache si presenta quindi pi\u00f9 comodo. Cosa promette il sistema? Affidabilit\u00e0, collaudato, funzionalit\u00e0 completa. E inoltre \u00e8 il pi\u00f9 diffuso. Cache centinaia di terabyte di dati.<\/p>\n

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

    Ma il mio senso di patriottismo mi spinge a considerare cosa ha di buono Tarantool.<\/p>\n

    Tarantool<\/h3>\n

    \nTarantool<\/a><\/noindex> \u2014 si presenta come \"Piattaforma di integrazione dei dati in tempo reale\". Suona molto complesso, quindi leggiamo attentamente la pagina e troviamo una dichiarazione audace: \"Cache il 100% dei dati in memoria\". Questo dovrebbe sollevare domande \u2014 poich\u00e9 i dati possono essere significativamente pi\u00f9 del disponibile nella memoria. Il significato \u00e8 che per scrivere dati su disco dalla memoria, Tarantool non esegue la serializzazione. Invece, utilizza caratteristiche a basso livello del sistema, in cui la memoria \u00e8 semplicemente mappata al file system con ottime prestazioni I\/O. In generale, hanno fatto un buon lavoro.<\/p>\n

    Diamo un'occhiata alle implementazioni: Mail.ru, 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 \"piattaforma di calcolo in-memory\u2026 velocit\u00e0 in-memory su petabyte di dati\". Qui ci sono anche molti vantaggi: cache distribuita in-memory, il pi\u00f9 veloce sistema di archiviazione e cache key-value, scalabilit\u00e0 orizzontale, alta disponibilit\u00e0, integrit\u00e0 rigorosa. In generale, si scopre 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 manda i propri membri nel team di Ignite per migliorare il prodotto. Questo mi convince completamente e sono pronto a prendere Ignite.<\/p>\n

    \u00c8 completamente incomprensibile perch\u00e9, guardo il quinto punto.<\/p>\n

    Hazelcast<\/h3>\n

    \nVado sul sito Hazelcast<\/a><\/noindex>, leggo. E si scopre che la soluzione pi\u00f9 veloce per la cache distribuita \u00e8 Hazelcast. \u00c8 di parecchie volte pi\u00f9 veloce di tutte le altre soluzioni e in effetti \u00e8 il leader nel campo dei data grid in-memory. A fronte di ci\u00f2, prendere qualcos'altro sarebbe mancarsi di rispetto. Inoltre, utilizza la memorizzazione dei dati ridondante per garantire il funzionamento continuo del cluster senza perdita di dati.<\/p>\n

    Va bene, sono pronto a prendere Hazelcast.<\/p>\n

    Confronto<\/h2>\n

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

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

    \"Come
    \n
    \nQui sono ordinati: in cima Redis, al secondo posto Hazelcast, Tarantool e Ignite stanno guadagnando popolarit\u00e0, EhCache \u00e8 rimasto tale e quale. <\/p>\n

    Ma diamo un'occhiata al metodo di calcolo<\/a><\/noindex>: links ai siti web, interesse generale per il sistema, offerte di lavoro \u2014 fantastico! Cio\u00e8, quando il mio sistema va in crash, dir\u00f2: \"No, \u00e8 affidabile! Ecco molte offerte di lavoro...\". Un confronto cos\u00ec semplice non \u00e8 adatto.<\/p>\n

    Tutti questi sistemi non sono semplicemente sistemi per la cache. Hanno anche molte altre funzionalit\u00e0, tra cui \u2014 quando non sono i dati a essere trasferiti al cliente per l'elaborazione, ma viceversa: il codice da eseguire sui dati si sposta sul server, viene eseguito l\u00ec e il risultato viene restituito. E come sistema separato per la cache, non vengono spesso considerati.<\/p>\n

    Va bene, non ci arrendiamo, troviamo un confronto diretto dei sistemi. Prendiamo le due opzioni superiori \u2014 Redis e Hazelcast. Ci interessa la velocit\u00e0, su questo parametro li confronteremo.<\/p>\n

    Hz vs Redis<\/h3>\n

    \nTroviamo tale un confronto<\/a><\/noindex>:
    \n\"Come
    \n
    \nIl blu \u00e8 Redis, il rosso Hazelcast. Hazelcast vince ovunque, e questo \u00e8 giustificato: \u00e8 multithreaded, altamente ottimizzato, ogni thread lavora con la propria partizione, quindi non ci sono blocchi. Redis \u00e8 invece monothreaded, e non sfrutta i moderni processori multicore. Hazelcast utilizza I\/O asincrono, mentre Redis-Jedis usa socket bloccanti. Alla fine, Hazelcast utilizza un protocollo binario, mentre Redis \u00e8 orientato al testo, il che significa che \u00e8 inefficiente.<\/p>\n

    Per ogni evenienza, rivolgiamoci a un'altra fonte di confronto. Cosa ci mostrer\u00e0?<\/p>\n

    Redis vs Hz<\/h3>\n

    \nUn'altra un confronto<\/a><\/noindex>:
    \n\"Come
    \n
    \nQui al contrario, il rosso \u00e8 Redis. Cio\u00e8, Redis ha prestazioni migliori rispetto a Hazelcast. Nel primo confronto vinceva Hazelcast, nel secondo invece vince Redis.     Qui<\/a><\/noindex> \u00e8 stato spiegato molto bene perch\u00e9 nel confronto precedente ha vinto Hazelcast.<\/p>\n

    Si scopre che il risultato del primo confronto era praticamente truccato: Redis \u00e8 stato preso nella sua configurazione base, mentre Hazelcast \u00e8 stato ottimizzato per il caso di test. Quindi, innanzitutto, non ci si pu\u00f2 fidare di nessuno; in secondo luogo, quando alla fine scegliamo un sistema, dobbiamo anche configurarlo correttamente. Queste impostazioni comprendono decine, quasi centinaia di parametri.<\/p>\n

    Agitiamo la bottiglia<\/h2>\n

    \nE tutto il processo che abbiamo appena svolto posso spiegare con questa metafora: \"Agitiamo la bottiglia\". Cio\u00e8, ora non \u00e8 necessario programmare, ci\u00f2 che conta \u00e8 sapere come leggere Stackoverflow. Ho in team una persona, un professionista, che lavora proprio in questo modo nei momenti critici.<\/p>\n

    Cosa sta facendo? Vede un aggeggio che non funziona, osserva il 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, senza riflettere, tra le risposte alla domanda - sceglie qualcosa di simile alla frase \u00abfare questo e quello\u00bb (scegliere quella risposta - \u00e8 il suo talento, perch\u00e9 non \u00e8 sempre quella la risposta che ha raccolto pi\u00f9 like), applica, guarda: se qualcosa \u00e8 cambiato, allora bene. Se non \u00e8 cambiato - annulliamo. E ripetiamo avvio-controllo-ricerca. E in questo modo intuitivo riesce ad ottenere che dopo un po' di tempo il codice funzioni. Non sa perch\u00e9, non sa cosa ha fatto, non riesce a spiegare. Ma! Quello funziona. E \u00abil fuoco \u00e8 spento\u00bb. Adesso analizziamo cosa abbiamo fatto. Quando il programma funziona - \u00e8 di gran lunga pi\u00f9 facile. E risparmia significativamente tempo.<\/p>\n

    Questo metodo \u00e8 molto bene spiegato con un esempio.<\/p>\n

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

    \"Come
    \n
    \nEsiste un metodo, molto rapido e molto efficace.<\/p>\n

    La nave \u00e8 composta da un sacco di piccole cose: bastoncini, cordicelle, vele, colla. Mettiamo tutto nella bottiglia.
    \nPrendiamo la bottiglia con entrambe le mani e iniziamo a scuoterla. La scuotiamo e la scuotiamo. E di solito - risulta un disastro, certo. Ma a volte. A volte esce una nave! Pi\u00f9 precisamente, qualcosa che assomiglia a una nave.<\/p>\n

    Mostriamo questo qualcosa a qualcuno: \u00abSerjoga, vedi!?\u00bb. E in effetti, da lontano - sembra una nave. Ma non si pu\u00f2 lasciarla cos\u00ec.<\/p>\n

    Esiste anche un altro modo. Lo usano ragazzi pi\u00f9 esperti, come i hacker.<\/p>\n

    Ho dato a un ragazzo cos\u00ec un compito, ha fatto tutto e se ne \u00e8 andato. E guardi - sembra fatto. Ma dopo un po', quando bisogna rifinire il codice - iniziano a succedere cose a causa sua... Per fortuna, \u00e8 gi\u00e0 riuscito a scappare lontano. Sono ragazzi che prendono l'esempio della bottiglia e fanno cos\u00ec: vedete, dove c'\u00e8 il fondo - il vetro si piega. E non \u00e8 del tutto chiaro, se sia trasparente o meno. Allora i \u00abhacker\u00bb segano quel fondo, inseriscono dentro la nave, poi riattaccano il fondo, e sembra che debba essere cos\u00ec.<\/p>\n

    Sotto il profilo della formulazione del problema sembra che sia tutto corretto. Ma prendo l'esempio delle navi: a cosa serve fare questa nave, a chi serve davvero? Non ha alcuna funzionalit\u00e0. Di solito, queste navi sono regali per persone di grande rilievo, che la mettono su uno scaffale, come un simbolo, un segno. E se a una persona del genere, un dirigente d'azienda o un funzionario di alto rango, si presentasse una nave realizzata malamente, con il collo spezzato? \u00c8 meglio che non lo scopra mai. Quindi, come si fanno alla fine queste navi che si possono regalare a una persona importante?<\/p>\n

    L'unico posto, chiave, su cui realmente non si pu\u00f2 intervenire, \u00e8 lo scafo. E lo scafo della nave passa proprio attraverso il collo. Mentre la nave viene assemblata al di fuori della bottiglia. Ma non \u00e8 semplice assemblare una nave, \u00e8 un vero e proprio lavoro di precisione. A pezzi vengono aggiunti speciali leve che permettono poi di sollevarli. Ad esempio, le vele vengono piegate, portate delicatamente all'interno e poi, con l'aiuto di una pinzetta, vengono sollevate con grande cura e precisione. Ne risulta un'opera d'arte che si pu\u00f2 regalare con la coscienza pulita e con orgoglio.<\/p>\n

    E se vogliamo che il progetto abbia successo, nel team deve esserci almeno una persona artigiana. Quella che si preoccupa della qualit\u00e0 del prodotto e considera tutti gli aspetti, senza sacrificare nulla, anche nei momenti di stress, quando le circostanze richiedono di fare una cosa urgente a scapito di un aspetto importante. Tutti i progetti di successo, che sono solidi e che hanno resistito alla prova del tempo, si basano su questo principio. Contengono qualcosa di molto preciso e unico, qualcosa che sfrutta tutte le possibilit\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 approccio? Propongo un modo di scegliere tra tutti i sistemi esistenti: non agitare la bottiglia, non scegliere a caso, ma guardare cosa c'\u00e8 in essi da considerare durante la scelta del sistema.<\/p>\n

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

    \nCercheremo di non scuotere la bottiglia, di non esaminare tutto ci\u00f2 che c'\u00e8 in ordine, ma vedremo quali problemi sorgeranno se, nel caso, decidessimo di progettare un sistema simile da soli. Non costruiremo una bicicletta, ma utilizzeremo questo schema per orientarci su quali aspetti prestare attenzione nelle descrizioni dei prodotti. Disegneremo tale schema.<\/p>\n

    \"Come
    \n
    \nSe il sistema \u00e8 distribuito, avremo diversi server (6). Supponiamo quattro (comodo da posizionare nell'immagine, ma in realt\u00e0 possono essercene quanti ne vogliamo). Se i server sono su nodi diversi, significa che su di essi gira un certo codice che si occupa di far formare un cluster a questi nodi e, in caso di interruzione, di riconnetterli e fargli riconoscere l'un l'altro.<\/p>\n

    Serve anche un codice-logica (2) che si occupa effettivamente della memorizzazione nella cache. Con questo codice interagiscono i client tramite un certo API. Il codice client (1) pu\u00f2 trovarsi all'interno della stessa JVM oppure pu\u00f2 essere interpellato tramite rete. La logica implementata internamente riguarda quali oggetti mantenere nella cache e quali scartare. Utilizziamo la memoria (3) per memorizzare la cache, ma se necessario possiamo anche salvare parte dei dati su disco (4).<\/p>\n

    Diamo un'occhiata a quali parti genereranno il carico. In effetti, ogni freccia e ogni nodo subiranno un carico. In primo luogo, tra il codice client e l'API, se si tratta di un'interazione di rete, le perdite possono essere abbastanza evidenti. In secondo luogo, all'interno dell'API stessa, se esageriamo con logiche complesse, possiamo trovarci a dover gestire il CPU. E sarebbe meglio che la logica non utilizzi la memoria inutilmente. Infine, rimane l'interazione con il file system: nel caso normale si tratta di serializzare \/ ripristinare e scrivere \/ leggere.<\/p>\n

    Proseguiamo con l'interazione con il cluster. Probabilmente sar\u00e0 nella stessa sistema, ma potrebbe anche essere separato. Qui dobbiamo anche considerare il passaggio dei dati, la velocit\u00e0 di serializzazione dei dati e l'interazione tra il cluster.<\/p>\n

    Ora, da un lato, possiamo immaginare \"quali ingranaggi si muoveranno\" nel sistema di cache durante l'elaborazione delle richieste dal nostro codice, e dall'altro lato, possiamo stimare quali e quante richieste generer\u00e0 il nostro codice per questo sistema. Questo \u00e8 sufficiente per fare una scelta abbastanza razionale \u2013 scegliere un sistema adatto al nostro caso d'uso.<\/p>\n

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

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

    Per inserire o prelevare dati da Hazelcast, il codice client accede (1) all'api. Hz consente di avviare il server come embedded, e in questo caso l'accesso all'api \u00e8 una chiamata di metodo all'interno della JVM, che pu\u00f2 essere considerata gratuita.<\/p>\n

    Per far funzionare la logica in (2), Hz si basa sul hash di un byte array del chiave serializzata \u2013 cio\u00e8, la serializzazione della chiave avverr\u00e0 in ogni caso. Questo \u00e8 un overhead inevitabile per Hz.
    \nLe strategie di Eviction sono ben implementate, ma per casi particolari \u00e8 possibile collegare le proprie. Non c'\u00e8 bisogno di preoccuparsi per questa parte.<\/p>\n

    Il repository (4) pu\u00f2 essere configurato. Eccellente. L'interazione (5) per embedded pu\u00f2 essere considerata istantanea. Lo scambio di dati tra i nodi nel cluster (6) - s\u00ec, esiste. Questo contribuisce alla ridondanza a costo di velocit\u00e0. Hz ha una funzione chiamata Near-cache che permette di ridurre i costi: i dati ottenuti da altri nodi del cluster saranno 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'altra cache, per i dati pi\u00f9 caldi. In Sportmaster per questo scopo \u00e8 stata scelta Caffeine.<\/p>\n

    Per la configurazione a livello di (6), in Hz sono offerti due tipi di memorizzazione: IMap e ReplicatedMap.
    \n\"Come
    \n
    \n\u00c8 importante dire come Hazelcast sia entrato nello stack tecnologico di Sportmaster.<\/p>\n

    Nel 2012, quando stavamo lavorando sul primo pilota del futuro sito, Hazelcast \u00e8 stato il primo link fornito dal motore di ricerca. L'incontro \u00e8 avvenuto 'al primo colpo' \u2014 ci ha colpito il fatto che dopo sole due ore, quando abbiamo integrato Hz nel sistema \u2014 funzionava. E funzionava bene. Fino alla fine della giornata abbiamo scritto alcuni test, ci siamo congratulati. E questa energia \u00e8 stata sufficiente per affrontare le sorprese che Hz ha riservato nel tempo. Ora il team di Sportmaster non ha motivi per rinunciare a Hazelcast.<\/p>\n

    Ma argomenti come 'primo link nel motore di ricerca' e 'abbiamo rapidamente assemblato HelloWorld' sono, ovviamente, un'eccezione e una peculiarit\u00e0 del momento in cui \u00e8 avvenuta la scelta. Le vere prove per il sistema scelto iniziano con il passaggio alla produzione, ed \u00e8 proprio su questo stadio che bisogna prestare attenzione quando si sceglie qualsiasi sistema, incluso il caching. In sostanza, nel nostro caso si pu\u00f2 dire che abbiamo scelto Hazelcast per caso, ma poi si \u00e8 rivelato di aver scelto correttamente.<\/p>\n

    Per la produzione, ci\u00f2 che conta di pi\u00f9 \u00e8: monitoraggio, gestione delle anomalie sui singoli nodi, replica dei dati, costi di scalabilit\u00e0. Cio\u00e8, \u00e8 importante prestare attenzione alle attivit\u00e0 che emergeranno durante la gestione del sistema \u2013 quando il carico superer\u00e0 di dieci volte quello pianificato, quando caricheremo accidentalmente qualcosa di sbagliato nel posto sbagliato, quando sar\u00e0 necessario distribuire una nuova versione del codice, sostituire i dati e farlo senza che i clienti se ne accorgano.<\/p>\n

    Per tutti questi requisiti, Hazelcast \u00e8 sicuramente adatto.<\/p>\n

    Continua...<\/h2>\n

    \nMa Hazelcast non \u00e8 una panacea. Nel 2017 abbiamo scelto Hazelcast per la cache nell'interfaccia di amministrazione, semplicemente basandoci su una buona impressione del passato. Questo ha giocato un ruolo chiave in uno scherzo devastante, che ci ha portato in una situazione difficile e ci ha visto \"eroicamente\" combattere per uscirne per 60 giorni. Ma di questo parleremo nella prossima parte.<\/p>\n

    E nel frattempo\u2026 Buon codice nuovo!
    \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\udd47 Come abbiamo scelto un sistema di caching in Sportmaster. Parte 1 | ProHoster","description":"Ciao! Mi chiamo Alexey Pyankov, sono sviluppatore presso Sportmaster.","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.","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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"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}]}}