Campo di codice della Florida meridionale 2017
Ridimensionamento di applicazioni .NET con cache distribuita
Di Iqbal Khan
Presidente ed evangelista tecnologico
Le tue applicazioni .NET potrebbero riscontrare colli di bottiglia nel database o nell'archiviazione a causa dell'aumento del carico delle transazioni. Scopri come rimuovere i colli di bottiglia e ridimensionare le tue applicazioni .NET usando la cache distribuita. Questo discorso copre:
- Panoramica rapida dei colli di bottiglia della scalabilità nelle applicazioni .NET
- Descrizione della cache distribuita e di come risolve i problemi di prestazioni
- Dove puoi utilizzare la cache distribuita nelle tue applicazioni
- Alcune caratteristiche importanti in una cache distribuita
- Esempi pratici utilizzando una cache distribuita
Oggi parlerò di come ridimensionare le app .NET con la memorizzazione nella cache distribuita. Questo discorso non riguarda NCache. Anche se mi riferirò a NCache ma lo scopo principale è quello di istruirti su quali sono i problemi e come risolverli con la memorizzazione nella cache.
Cos'è la scalabilità
Bene! Solo per motivi di completezza, esaminiamo alcune delle definizioni che sono sicuro che le conosci già, ma prima definiamo cos'è la scalabilità. La scalabilità non è ad alte prestazioni. Le alte prestazioni sarebbero qualcosa se avessi cinque utenti, avresti un tempo di risposta davvero buono, è un'alta prestazione. La scalabilità è se è possibile mantenere le stesse prestazioni elevate con carichi di picco. Quindi, se la tua applicazione non ha prestazioni elevate con cinque utenti, hai altri problemi. Più di quanto possiamo risolvere lì.
Scalabilità lineare
In secondo luogo, cos'è la scalabilità lineare. La scalabilità lineare è più una definizione di distribuzione.
Quando distribuisci la tua applicazione in un ambiente multi-server, diciamo, se hai un ambiente con bilanciamento del carico, la tua applicazione è linearmente scalabile se puoi semplicemente aggiungere più server per ottenere ulteriore capacità di transazione. Quindi, se avevi mille utenti con due server, avevi un terzo server ottieni, diciamo, 1500 utenti e poi aggiungendo più server ottieni 500 utenti ciascuno. Sto solo dicendo in modo ipotetico, ma questa è una scalabilità lineare. Se riesci a raggiungere questo obiettivo, allora questo è l'obiettivo perché in tal caso non ti imbatti mai in problemi, per i quali sono sicuro che eri qui per affrontare.
Scalabilità non lineare
La scalabilità non lineare è esattamente l'opposto di quella che è che hai un'architettura dell'applicazione in cui non puoi semplicemente acquistare hardware più costoso o più server per risolvere quel problema.
Hai alcuni colli di bottiglia fondamentali quindi quando aggiungi più server, la tua applicazione, per un certo tempo, le prestazioni o la capacità di transazione aumentano ma, dopodiché, in realtà rallenta anche se aggiungi più server. Quindi, sicuramente non vuoi la scalabilità non lineare.
Che tipo di applicazioni necessitano di scalabilità?
Di solito si tratta di applicazioni lato server.
Queste sono applicazioni Web, ASP.NET, potrebbero essere servizi Web WCF, potrebbero essere il back-end per qualsiasi applicazione IOT. Abbiamo molti dispositivi IOT diversi che parlano con una sorta di back-end. Potrebbero trattarsi di applicazioni di elaborazione di big data, sebbene l'elaborazione di big data sia più un'attività Java. A causa di Hadoop, .NET non è un'elaborazione di big data molto grande, ma se stavi eseguendo l'elaborazione di big data, avresti sicuramente bisogno di ridimensionare e qualsiasi altra applicazione server che non rientra in questa categoria. Voglio dire, potresti avere molte elaborazioni batch, se sei una grande azienda, potresti dover aggiornare un certo numero di cose entro mezzanotte o entro, prima del giorno lavorativo successivo e, poiché hai sempre più clienti, hai milioni e milioni di clienti che, ovviamente, devi ridimensionare.
Quindi, anche quelle applicazioni di back-end, un buon esempio potrebbe essere che i clienti, la tua banca e i clienti stanno trasferendo fondi da un conto all'altro, che di solito viene elaborato nel back-end in modalità batch di notte. Quindi, devi farlo contrattualmente entro un certo periodo di tempo. Quindi, tutte queste applicazioni, se non hanno scalabilità, hai grossi problemi.
Qual è il problema della scalabilità?
Il livello dell'applicazione fortunatamente non è dove si trova il problema. Se hai la maggior parte di queste applicazioni, il livello dell'applicazione puoi aggiungere più server, non è un grosso problema. È l'archiviazione dei dati il problema. E, quando uso la parola data storage, intendo database relazionali, dati legacy mainframe. È lì che risiede la maggior parte dei tuoi dati e sono quelli che non possono scalare allo stesso modo delle applicazioni. Adesso, NoSQL databases esiste per uno dei casi d'uso è la scalabilità, ma il problema con NoSQL databases, e ancora, abbiamo a NoSQL database dei nostri chiamati NosDB. È un database open source. Quindi, la limitazione di NoSQL database è che semplicemente non puoi spostare tutti i dati su di esso perché richiedono che tu sposti i dati dal tuo mainframe o dai tuoi database relazionali che per una serie di motivi, forse tecnici, forse commerciali, potresti non essere in grado di fare.
Pertanto, i database relazionali continueranno a essere la principale fonte di dati anagrafici. Ci sono molti casi d'uso in cui puoi inserire molti dei nuovi dati NoSQL databasese quando lo fai, risolvono il collo di bottiglia della scalabilità. Ma, nella maggior parte dei casi, puoi farlo solo per un sottoinsieme dei tuoi dati. La maggior parte dei dati deve ancora rimanere nei tuoi database relazionali o nelle tue origini dati mainframe legacy. Quindi, qualunque problema tu debba risolvere, questa scalabilità, devi risolverla continuando a lavorare con database relazionali o con il tuo mainframe legacy. Ed è qui che una cache distribuita risolve effettivamente il problema. Ti consente di continuare a utilizzare i dati del mainframe dei database relazionali rimuovendo tutto quel collo di bottiglia.
Distribuzione cache distribuita
Quindi, ecco un'immagine, se lo avessi, se questi sono i dati legacy dei tuoi database relazionali, puoi inserire un livello di memorizzazione nella cache tra l'applicazione e il database.
Quando lo fai, ciò che accade, inizi a memorizzare nella cache i dati che utilizzerai frequentemente. Inoltre, circa l'80% delle volte non è nemmeno necessario accedere al database. E la cache, poiché è una cache distribuita, puoi aggiungere sempre più server, si ridimensiona allo stesso modo del livello dell'applicazione. Quindi, hai un minimo di due server cache qui e, quindi, mantieni un rapporto di quattro a uno o cinque a uno tra il livello dell'applicazione e il livello di memorizzazione nella cache. Ora, quel rapporto può cambiare a seconda della natura delle tue operazioni. Se ognuno dei tuoi, diciamo, se avessi un'applicazione web, per ogni clic dell'utente esegui centinaia di chiamate cache, ovviamente il rapporto cambierebbe ma, la maggior parte delle volte non effettui centinaia di chiamate cache.
Un tipico server cache è solo un server a basso costo. È un tipo di server Web di una configurazione, doppia CPU, tipo quad-core di una scatola, ha solo molta memoria. Molta memoria significa che da 16 a 32 giga sono piuttosto standard, più di 32 giga che di solito non devi fare. Tuttavia, abbiamo molti clienti che arrivano fino a 64 giga, ma consigliamo che invece di avere molta più memoria in ogni scatola, aggiungi più scatole. E il motivo è perché più memoria hai in ogni scatola, più potente è il processore che devi avere e quindi la tua scatola inizia a sembrare sempre più simile a un database, il che non è l'intenzione. Vuoi mantenerlo il più basso possibile.
Ora, una cache distribuita è un'infrastruttura che vuoi mettere per tutte le tue applicazioni. Quindi, proprio come si dispone di un database che è praticamente un'infrastruttura comune, la nuova procedura consigliata consiste nell'avere una cache distribuita in memoria. Viene anche chiamato in-memory NoSQL archivio di valori chiave. E fallo come parte della tua infrastruttura e delle tue applicazioni di architettura in modo da andare sempre in questo negozio. Quindi, controlli il negozio prima di accedere al database. Una volta che hai quell'infrastruttura, tutte le tue applicazioni diventano automaticamente scalabili. Quindi, non devi mai preoccuparti che i database diventino un collo di bottiglia. Inoltre, il problema più grande con la scalabilità o l'impossibilità di scalare è che è in quel momento che la tua azienda svolge molte attività.
Diciamo che sei una compagnia aerea e hai appena fatto una promozione speciale per le Hawaii. Tutti accedono al tuo sito Web, non lo so, mercoledì per iniziare ad acquistare i biglietti. Quindi, cercheranno voli e compreranno i biglietti e tu hai circa cinque volte più traffico di prima e all'improvviso il sito rallenta, forse si blocca e può andare in crash, ovviamente , se il tuo database viene sovraccaricato ma, anche se rallenta oltre i limiti accettabili, il tuo costo per l'azienda è molto alto perché le persone se ne andranno. Quindi, devi davvero assicurarti di pianificare la scalabilità in modo da non avere mai quella situazione in cui la tua azienda vuole fare più attività, sono in grado di generare affari ma non sei in grado di elaborare all'interno dell'applicazione. E, se hai l'infrastruttura giusta, non avrai mai questo problema.
Sto solo configurando il caso sul perché dovresti usare una cache distribuita? Quale problema viene risolto e poi entreremo nei dettagli di come lo usi effettivamente. Oltre ad avere più memoria, di solito hai, come ho detto, doppia CPU, configurazione quad core, 2 schede di rete da un gigabit o più ciascuna. In caso di NCache queste sono scatole di Windows, in caso di Redis queste sono scatole Linux, a seconda che tu abbia un'applicazione .NET o Java. Il mio obiettivo qui è .NET ma per Java hai anche cache distribuite. Li chiamano griglia dati in memoria, sul lato .NET si chiama cache distribuita.
Casi d'uso comuni della cache distribuita
Bene! Quindi, ora che abbiamo costruito il caso sul motivo per cui è necessario disporre della cache distribuita come parte dell'infrastruttura delle migliori pratiche, sia dal punto di vista IT ma soprattutto dal punto di vista dello sviluppo, si desidera progettare l'applicazione. La prima domanda che viene anche in mente, come si usa questa cache? Quali sono i casi d'uso? Dove li uso? Voglio dire, so che tipo di applicazioni le userò, ma che tipo di dati memorizzerò nella cache?
Quindi, ci sono tre categorie principali. Il numero uno è ciò che tutti capiscono, ovvero la memorizzazione nella cache dei dati dell'applicazione.
Memorizzazione nella cache dei dati dell'applicazione
Quindi, nella memorizzazione nella cache dei dati dell'applicazione, stai memorizzando nella cache i dati che esistono nel tuo database, li stai memorizzando nella cache, questo è ciò di cui abbiamo appena parlato. Quindi, quando lo fai, stai effettivamente creando due copie dei dati. Uno è nel database per il master e uno è nella cache che è la copia temporanea. Quando ciò accade, qual è la preoccupazione principale? Cosa potrebbe andare storto quando hai due copie? Potrebbero perdere la sincronizzazione. In effetti, questa è una paura così grande nella mente delle persone è che la maggior parte delle persone quando chiedi loro per cosa usi la memorizzazione nella cache, dicono bene per i dati di sola lettura, non posso rischiare con i miei dati transazionali, con dati che cambia perché cosa succede se va storto. Cosa succede se il mio cliente preleva quei soldi due volte dallo stesso conto, cosa accadrà?
Ebbene, se non è possibile memorizzare nella cache i dati transazionali, il valore di una cache distribuita diminuisce parecchio perché i dati di riferimento sono solo il venti percento o il trenta percento dei dati. L'80 percento o dal 70 all'80 percento dei dati sono i tuoi clienti, i tuoi account, le attività, i tuoi dati transazionali, i dati che cambiano ogni forse 30 secondi, ogni minuto, dati che potresti essere in grado di conservare nella cache per un tempo molto molto breve. Quindi, se non sei in grado di utilizzare una cache per i dati transazionali, ti sei davvero limitato. Quindi, una buona cache distribuita deve garantire che la cache e il database siano sempre sincronizzati. In modo che una volta che hai quel conforto, quella tranquillità che la cache è sempre sincronizzata con il database, puoi memorizzare nella cache praticamente tutto e quando lo fai vedi davvero molti giochi.
E andrò in molti più dettagli su questo.
Memorizzazione nella cache specifica di ASP.NET
Il secondo caso d'uso è quando si dispone di un'applicazione ASP.NET, ci sono alcune cose specifiche di ASP.NET che è possibile memorizzare nella cache. E la cosa bella di questa categoria è che non c'è bisogno di programmazione da parte tua perché Microsoft ha un framework in cui si collegherà semplicemente una cache. Il numero uno è lo stato della sessione. Ogni applicazione ASP.NET deve avere lo stato della sessione, praticamente. Alcune persone appositamente programmate per non usarlo, il che non è una buona idea. Dovresti usare una sessione che ti rende la vita molto più facile.
Una sessione è un ottimo candidato per la memorizzazione nella cache perché se si archivia una sessione nel database, si verificano gli stessi problemi per cui i database non sono progettati per l'archiviazione di BLOB, che è ciò che è una sessione. Quindi, le prestazioni sono davvero lente e, soprattutto, la scalabilità scompare. Per lo stesso motivo per cui si desidera eseguire la memorizzazione nella cache dei dati dell'applicazione, si desidera inserire anche le sessioni non nel database. Vuoi metterli nella cache distribuita.
Il secondo è uno stato di visualizzazione. Se non stai utilizzando il framework MVC, se sei ancora sul vecchio ASP.NET framework quindi visualizza lo stato. Per quelli di voi che non sanno cos'è uno stato di visualizzazione, uno stato di visualizzazione è una stringa crittografata che potrebbe essere piccola come un centinaio di byte o potrebbe essere di centinaia di kilobyte che viene generata e inviata al browser solo per tornare indietro quando fai un post indietro. Quindi, è un viaggio piuttosto costoso. Ovviamente, rallenta le tue prestazioni perché stanno andando molti più dati. Inoltre, aumenta anche i costi della larghezza di banda perché quando ospiti la tua applicazione, la pipe sopra non è gratuita. Quindi, quando i tuoi clienti accedono alla tua applicazione web, stai pagando per la larghezza di banda qui. Quindi, uno stato di visualizzazione, quando lo moltiplichi per i milioni e milioni di richieste o le transazioni che i tuoi utenti o clienti faranno, è un sacco di costi aggiuntivi che non vuoi sostenere. Quindi, questo è un ottimo candidato per la memorizzazione nella cache. Quindi, l'hai memorizzato nella cache sul server e invii semplicemente una piccola chiave che la prossima volta che si verifica un messaggio errato, la chiave ritorna e prima che la pagina venga eseguita, lo stato di visualizzazione viene recuperato dalla cache.
Il terzo è la cache di output che è un'altra parte di ASP.NET framework che se l'output della tua pagina non cambia, perché eseguirlo la prossima volta? Perché ogni volta che esegui la pagina consumerà CPU, memoria e tutte le altre risorse inclusi i tuoi database. Quindi, è molto meglio restituire semplicemente l'output dell'ultima esecuzione che potrebbe essere l'intera pagina o potrebbe essere parte della pagina. Quindi, per tutti questi tre è sufficiente collegare una cache distribuita senza alcuna programmazione. Ora te lo mostro. Ma la natura di questo problema è molto diversa dall'applicazione.
Nei dati dell'applicazione avevamo due copie dei dati, giusto? Quindi, il problema era la sincronizzazione. Qui hai solo una copia e quella viene conservata in un archivio in memoria. Quindi, qual è la preoccupazione più grande quando tieni qualcosa del genere in un negozio in memoria e quella è l'unica copia. Anche quello! Oppure, se un server si interrompe, hai appena perso quella cache. Quindi, per tutto questo da archiviare nella cache. Immagina la stessa compagnia aerea che ho appena attraversato e ho passato mezz'ora a trovare la combinazione perfetta di compagnie aeree e sto per premere Invia e la sessione è persa, non è stata una buona esperienza perché il server web si è appena interrotto.
Quindi, per questo, come risolvi quel problema quando hai una memoria interna e hai quella preoccupazione? Hai ridondanza. Hai più di una copia dei dati. Quindi, una buona cache distribuita deve consentire di eseguire la replica dei dati. Senza la replica dei dati in modo intelligente e ad alte prestazioni, la tua cache diventa di nuovo molto meno utile.
Condivisione dei dati di runtime tramite eventi
Il terzo caso d'uso è qualcosa che la maggior parte delle persone non conosce o che sta iniziando a diventare più popolare è che puoi usare, hai questa infrastruttura in-memory molto scalabile. Puoi usarlo per la condivisione dei dati di runtime tramite eventi, dice una specie di messaggistica ma una versione molto semplificata di esso ed è in un unico tipo di data center di un ambiente in cui puoi fare in modo che più applicazioni utilizzino la cache come un modo per fare Tipo Pub/Sub di una condivisione dati. Quindi, un'applicazione mette qualcosa nella cache, attiva un evento e i consumatori interessati a quei dati hanno ricevuto quell'evento e possono andare a consumare quei dati.
Quindi, invece di inserirlo nel database o metterlo in una coda MSM, tipo una situazione che ha il suo scopo. Una cache non è disponibile per sostituire la coda MSM ma, in molte situazioni, è un'infrastruttura molto più semplice e soprattutto molto più veloce e scalabile per eseguire la condivisione dei dati basata su eventi. Quindi, se hai la necessità di avere più applicazioni che devono condividere i dati tra loro in fase di esecuzione, dovresti assolutamente considerare questa come una funzionalità, una funzionalità molto importante.
Memorizzazione nella cache specifica di ASP.NET
Ti mostrerò rapidamente la memorizzazione nella cache di ASP.NET, come lo fai. È molto molto semplice e lo userò davvero... Quindi, ho del codice di esempio. Quindi, per esempio, se dovessi... Quindi, ho questa applicazione ASP.NET. Tutto quello che devi fare è andare su web.config, in caso di NCache e di nuovo sarà praticamente lo stesso per tutte le cache. La prima cosa che devi fare è aggiungere un assembly. Quindi, questo assembly è il provider dello stato della sessione. Quindi, ASP.NET framework dispone di un'interfaccia del provider dello stato della sessione che deve essere implementata da una cache distribuita. NCache lo ha implementato e questo carica l'assembly nell'applicazione.
Quindi, una volta che l'hai fatto, la prossima cosa che devi fare è andare al tag di stato della sessione. In effetti, assicurati che la modalità sia personalizzata e che il timeout sia quello che vuole essere il tuo timeout. In caso di NCache quindi metti solo questa riga. Altre cache hanno un tipo simile di informazioni. Quindi, devi solo.. In caso di NCache tutto ciò che devi fare è assicurarti che la tua cache abbia un nome e ti mostrerò effettivamente cosa significa. Ma, con solo questo cambiamento nella tua applicazione, puoi praticamente iniziare a memorizzare le tue sessioni. Quindi, apporti quella modifica in ogni web.config nel livello dell'applicazione, ovviamente, ti assicuri che esista una cache. E poi, una volta fatto, puoi effettivamente iniziare a mettere le sessioni nella cache.
Demo pratica
Ti mostrerò rapidamente un cluster di cache. Quindi, ad esempio, ho queste... uh, ho queste VM di Azure in cui ho demo1 e demo2 così come le mie VM del server cache e il client demo è come il server dell'applicazione. Quindi, questi sono i clienti. Un client cache è la tua casella del server delle applicazioni. Quindi, ho intenzione di...
Crea un cluster di cache
E, ho effettuato l'accesso, diciamo, ho effettuato l'accesso al client demo e lo userò, in caso di NCache e di nuovo userò questo strumento chiamato NCache gestore. È uno strumento grafico. Consente di configurare le cache da un'unica posizione. Verrò qui e dirò di creare una nuova cache in cluster. Tutte le cache sono nominate in NCache. Quindi, chiamerò la mia cache come cache demo. Non entrerò nei dettagli di queste proprietà.Sceglierò la mia strategia di replica per essere replica partizionata. E sceglierò una replica asincrona. Faccio il mio primo server cache. Farò il mio secondo server cache qui. Quindi, creerò un cluster di cache a due nodi. Sto solo andando a scegliere tutto. Quindi, questa è la porta TCP su cui è formato il cluster di cache, puoi cambiarla se c'è un conflitto di porte. Specifica la quantità di memoria che il mio server cache utilizzerà per la cache. Ce l'ho come un concerto, ovviamente, il tuo sarà molto di più.
Quindi, per esempio, lascia che ti mostri rapidamente cosa significa. Vado solo a questa parte.
Quindi, pensa a questo come a un server cache e questo ha un altro server cache. Quindi, la partizione 1 esiste qui. La partizione 1 è essenzialmente una raccolta di bucket. La partizione 2 ha la sua scatola. Quindi, c'è un caso di NCache sono circa mille secchi che vengono distribuiti tra quante partizioni hai. Ogni server ha una partizione e ogni server la partizione viene replicata su un server diverso. Quindi, se avevi tre server, vedrai che la partizione 1 è stata salvata qui. Qui viene eseguito il backup della partizione 2. Qui viene eseguito il backup della partizione 3. Le repliche non sono attive in caso di NCache. Diventano attivi solo se la partizione principale è inattiva.
Quindi, quello che sto specificando è la dimensione di una partizione. Quindi, in caso di replica della partizione, se specifico, diciamo, 1 gig qui, utilizzerà effettivamente 1 gig per la partizione e 1 gig per la replica. Quindi, un totale di 2 concerti. Quindi, se hai, diciamo, 16 giga di memoria, quello che vuoi fare è lasciare circa due o due giga e mezzo per il sistema operativo e altri processi e il resto che puoi usare. Quindi, per 16 giga puoi facilmente usare 13 giga. Quindi, fai una metà e metà. Quindi, è una dimensione della partizione di sei giga e mezzo e, ovviamente, puoi avere 32 giga e di nuovo lasci fuori tre giga e hai una dimensione della partizione di 29 giga mezzo e mezzo, 14 giga e mezzo. E poi, se vuoi più spazio di archiviazione, invece di aggiungere più memoria solo per aggiungere più server perché è più facile da gestire. Mantiene le cose molto più scalabili. Quindi, ho intenzione di colpire il prossimo qui.
La prossima è la mia politica di sfratto. Non entrerò in quei dettagli. E ora aggiungerò il nodo client. Una volta fatto, avvierò una cache. Sto per aprire una cache e volevo mostrarti questa parte perché è ciò che avrà senso nel resto del discorso. Quindi, sta avviando questi due nodi della cache.
Simula lo stress e monitora le statistiche della cache
Quindi, aprirò una serie di strumenti di monitoraggio ed eseguirò effettivamente questo strumento chiamato strumento di stress test.
È una riga di comando. È una console che inizia effettivamente a fare attività sulla cache. Ora, è come se stesse simulando la tua applicazione. Quindi, se lo guardi, la tua applicazione sta mettendo sessioni nella cache ogni sessione è un oggetto. Quindi stai aggiungendo. Quindi, il conteggio della cache è arrivato a 177, su questa casella 172 e 35. Quindi, sarà quasi pari e quindi è meglio eseguire il backup su un altro...
Questo è il backup qui, questo è il backup qui. Quindi, come puoi vedere, la replica avviene automaticamente. La tua applicazione non deve preoccuparsi. Tutto quello che hai fatto è creare questo cluster e sul livello dell'applicazione devi semplicemente modificare il Web.config e tutto il resto avviene automaticamente. Ovviamente puoi monitorare questa roba ma la cache è denominata. Quindi, nel nostro caso ho chiamato la cache come cache demo. Puoi nominarlo, infatti puoi avere più cache. La configurazione più comune che abbiamo visto con i nostri clienti è che hanno tre cache. Una cache la chiameranno, diciamo, cache degli oggetti. Quindi, è la loro principale cache transazionale. Una cache la chiameranno cache di sessione. Quindi, metterà tutte le sessioni in quella cache. La terza cache la chiameranno cache di riferimento. Quindi, inseriranno più dati di riferimento nella cache di riferimento.
E il motivo per cui creano una cache separata per i dati transazionali rispetto ai dati di riferimento è perché per i dati di riferimento si desidera utilizzare questa funzione chiamata Client Cache in cui si desidera memorizzare nella cache.
Cache client per prestazioni ancora migliori
In realtà sto saltando dappertutto quindi per favore perdonami se sto confondendo le cose. Se hai dati di riferimento, in realtà fammi fare un altro passo indietro. prima di distribuire le cache, le persone avevano questo oggetto cache ASP.NET. L'oggetto cache ASP.NET era una cache InProc locale. Era all'interno del processo di richiesta, super veloce, giusto? Se tieni le cose nel tuo mucchio, niente può eguagliare quella performance. Non appena entri in una cache distribuita, è diverso, è una cache di elaborazione automatica. Quello che la gente non si rende conto è che le tue prestazioni in realtà diminuiscono.
Abbiamo molti clienti che inizialmente sono rimasti sconcertati e hanno detto, beh, avrei dovuto ottenere un aumento delle prestazioni e le mie prestazioni sono diminuite da una cache ASP.NET lassù ora è molto più lenta, perché devono serializzare l'oggetto. Se hai un oggetto di grandi dimensioni, la serializzazione è un costo piuttosto significativo e questo è un costo che devi sostenere indipendentemente da qualsiasi cache specifica. E, non appena si esce dalla cache di processo, le prestazioni sono molto più lente di una cache InProc locale. Ma è ancora più veloce del database. È quasi 10 volte più veloce del database, ma si può dire quasi 10 volte più lento della cache di InProc.
Quindi, quello che succede è che le persone vogliono ottenere quel vantaggio di quella cache InProc. Bene, per i dati che non cambiano molto frequentemente, c'è una funzione chiamata Client Cache. Alcune persone lo chiamano Near Cache soprattutto sul lato Java.
Questa funzione, essenzialmente, è una cache locale. È come la cache di InProc ASP.NET. Si trova all'interno del processo dell'applicazione o può essere solo la cache OutProc locale che non è veloce come InProc ma comunque più veloce rispetto al livello di memorizzazione nella cache. Ma la differenza è che questa cache conosce il livello di memorizzazione nella cache. Questa cache client è la cache in cima alla cache ed è sincronizzata. Quindi, non devi preoccuparti del problema più grande di cui abbiamo parlato, ovvero come mantenere la cache sincronizzata con il database. Bene, ora hai tre copie dei dati. Uno nel database, uno nel livello di memorizzazione nella cache, uno nella cache del client. Naturalmente, la Client Cache è un sottoinsieme del livello di memorizzazione nella cache. Il livello di memorizzazione nella cache è un sottoinsieme del database. Ma qualunque cosa sia, deve essere sincronizzata. Quindi, avendo una cache client, è di nuovo un InProc, mantiene le cose in un modulo oggetto anziché in un modulo serializzato. Lo tiene sul tuo mucchio. Quindi, ottieni lo stesso vantaggio dell'oggetto cache InProc ASP.NET locale ma con tutti gli altri vantaggi della scalabilità perché questa cache client sarà un piccolo sottoinsieme. Puoi specificare quanto dovrebbe essere grande. Non varcherà mai quella soglia.
Quindi, potresti avere un gig in ogni cache del client e potresti avere 32 giga nel livello di memorizzazione nella cache e il database probabilmente ne ha molto di più. Comunque, quindi anche avendo un concerto perché è una finestra mobile, giusto? Quindi, qualunque cosa tu stia facendo, tieni. Alcuni dei dati rimarranno a lungo, alcuni dei dati rimarranno forse per alcuni minuti ma entro quel tempo farai centinaia di chiamate e non dovrai passare al livello di memorizzazione nella cache e, ovviamente, non dovrai vai alla banca dati. Quindi, una cache client è una funzionalità davvero potente quando è attivata. Lo fai per ulteriori dati di riferimento. Quindi, in caso di NCache, è possibile specificare una cache client tramite la modifica della configurazione. Non c'è programmazione aggiuntiva ma è mappata su una cache specifica. Quindi, ecco perché i nostri clienti in genere hanno tre cache; cache oggetti, cache di sessione e cache di riferimento. Per la cache di riferimento usano una cache client, per le altre due no.
Cache client facile da configurare
Ora, perché non eseguono una cache client con la cache di sessione? In realtà, perché le prestazioni rallentano. Il motivo è perché questo è solo meglio se fai molte più letture e scritture. Perché, cosa succede in caso di scrittura? Fai una scrittura qui e poi scrivi qui e poi fai una scrittura sul database. Quindi stai scrivendo in tre punti. Quindi, non aggiunge alcun valore se devi fare più scritture. Aggiorna la tua copia e quindi aggiorni solo questa e quindi questo notifica a tutte le altre cache client di andare ad aggiornarsi. È un aggiornamento ritardato, non che sia solo uno o due millisecondi in ritardo, ma è comunque un aggiornamento ritardato nel caso di una cache client. Non c'è replica tra le cache client. La cache del client si sincronizza solo con il livello di memorizzazione nella cache e il livello di memorizzazione nella cache, quindi propaga gli aggiornamenti ad altre cache del client. Solo se l'altra cache ha quei dati. Perché, in caso di Client Cache, ogni Client Cache ha dati diversi in base al tuo modello di utilizzo.
Dove utilizzare la cache del cliente
Quindi, facciamo un passo indietro, in caso di dati di riferimento, ogni Client Cache ha il proprio set di dati Quindi, diciamo da 1 a 1000, da 500 a 1500 e così via. Quindi, c'è una certa sovrapposizione tra ciascuno, ma non sono copie identiche. Ciò che è comune è che sono tutti sottoinsiemi di questa cache. Quindi, quando aggiorno il numero dell'elemento, diciamo, 700 in questa cache, verrà aggiornato nella cache e la cache saprà quali altre cache client hanno quegli elementi e verranno immediatamente aggiornati nelle loro altre cache. Ma solo se ce l'hanno tutti. Quindi, non è realmente replicato perché non sono copie identiche in caso di Client Cache. In caso di sessioni, quello che stavo effettivamente cercando di spiegare è che, in caso di sessione, dovrai aggiornare la Client Cache e la cache cluster, due posti senza valore aggiunto perché per le sessioni ne fai una lettura e una scrittura. Quindi, al momento della richiesta web, fai la lettura alla fine della pagina e fai la scrittura.
Quindi, la scrittura ora deve essere eseguita in due punti e la lettura verrà eseguita nella cache del client. Pertanto, le prestazioni in realtà diminuiscono se si utilizza Client Cache con sessioni o con altre operazioni ad alta intensità di scrittura, ma le prestazioni migliorano enormemente se la si utilizza per operazioni ad alta intensità di lettura. Aveva senso?
Quindi, il valore più grande di una cache distribuita, più veloce è il più veloce e il più grande è lo stato della sessione. Quasi tutte le applicazioni ce l'hanno. Ho appena creato un cluster di cache a due nodi e hai visto quanto tempo ci è voluto, forse due minuti, in caso di a NCache. Quindi, è davvero facile creare un cluster di cache, ovviamente, vuoi fare i tuoi test e cose del genere. Ma è davvero facile. Non c'è alcuno sforzo ingegneristico. Quando non c'è alcuno sforzo ingegneristico, i tuoi programmi sono molto più facili da gestire. Devi solo fare un test di sanità mentale per passare. Consiglio vivamente, se hai intenzione di iniziare a utilizzare una cache distribuita, usala per lo stato delle sessioni all'inizio come primo passaggio e quindi salta nella cache degli oggetti di cui parleremo tra un minuto.
Memorizzazione nella cache dei dati dell'applicazione
Quindi, abbiamo parlato della cache di sessione. Entriamo rapidamente nella cache dei dati dell'applicazione. Ecco cosa è un tipico NCache L'API sembra molto simile alla cache ASP.NET se noti che c'è una connessione.
Cache cache = NCache.InitializeCache("myCache");
cache.Dispose();Employee employee = (Employee) cache.Get("Employee:1000");
Employee employee = (Employee) cache["Employee:1000"];
bool isPresent = cache.Contains("Employee:1000");cache.Add("Employee:1000", employee);
cache.AddAsync("Employee:1000", employee);
cache.Insert("Employee:1000", employee);
cache.InsertAsync("Employee:1000", employee);
cache["Employee:1000"] = employee;
Employee employee = (Employee) cache.Remove("Employee:1000");
cache.RemoveAsync("Employee:1000");Quindi, ti connetti alla cache in base al nome e crei semplicemente una cache con il nome. Ecco perché ti ho dato quella dimostrazione in modo che tu capissi cosa significasse. E questo handle di cache è qualcosa che conservi solo per preservare un handle di database. E poi usi quell'handle della cache per fare un Cache.Get. Ogni Get, ogni operazione, ha una chiave. Una chiave è una stringa in caso di NCache e quindi formatti la chiave in base a ciò che stai facendo con essa. Quindi, nel caso di un singolo oggetto, una buona pratica è specificare semplicemente il nome della classe, magari il nome dell'attributo e il valore. E poi puoi ottenerlo. Quindi, c'è un Get e Get.Contains, Add, AddAsync. Asincrono significa non aspettare.
Bene, quello che succede è che, sotto, c'è la deserializzazione sul lato client. Quindi, il client, faremo un Cache.Add, diciamo, gli stai dando un oggetto, è un oggetto dipendente, lo serializzerà in base alla serializzazione .NET standard o al custom NCache serializzazione. E, quindi, crealo nell'array di byte e invia l'array di byte alla cache. NCache fa di più perché potrebbe essere necessario indicizzare determinati attributi. Estrae i valori di quelli. Sì, lo farà. Lo farà. Subito. Sì! Ogni oggetto memorizzato nella cache deve passare attraverso la serializzazione.
Quindi, non appena accendi l'applicazione, genererà eccezioni. Se stai usando l'oggetto cache ASP.NET, non devi serializzare. Quindi, puoi praticamente memorizzare nella cache tutto e la maggior parte delle volte ciò che accade è che i tuoi oggetti potrebbero essere più facili da serializzare ma potresti utilizzare terze parti. Diciamo che in precedenza l'oggetto tabella dati non veniva serializzato, ma ora lo è. Quindi, se stai utilizzando oggetti di terze parti che non sono serializzabili, non hai alcun controllo. Quindi, non puoi catturarli se hai intenzione di utilizzare una cache distribuita. In caso di NCache, abbiamo la nostra serializzazione personalizzata in cui puoi identificare quegli oggetti. NCache quindi crea il codice di serializzazione per te in fase di esecuzione e lo compila in memoria. Quindi, ciò ti consente di utilizzare anche quegli oggetti che non sono serializzabili. Ma questa serializzazione avviene immediatamente. Pertanto, la tua applicazione non funzionerà se non utilizza la serializzazione corretta.
Async dice essenzialmente di non aspettare che la cache venga aggiornata. Quindi, posso continuare. Confido che la cache aggiungerà questa cosa. Pertanto, non sbloccano il database in cui gli aggiornamenti possono fallire per problemi di integrità dei dati. Una cache non presenta problemi di integrità dei dati. Fallisce solo quando si verificano arresti anomali. Quando sei a corto di memoria o succede qualcos'altro. Quindi, puoi praticamente essere certo che qualunque cosa tu stia aggiungendo, molto probabilmente la aggiungerai nella cache. Quindi, Async ti dà ancora un'ulteriore spinta. Quindi, l'API sembra molto semplice come puoi vedere.
Mantenere la cache fresca
Quindi, quando esegui la memorizzazione nella cache dei dati dell'applicazione, come mantieni la cache fresca? Questo è davvero molto importante. Esistono diversi modi per memorizzare nella cache.
Utilizzo delle scadenze basate sul tempo
Scadenze, quasi tutte le cache supportano le scadenze. C'è una scadenza assoluta in cui ottieni questo specifico per ogni elemento, ecco per quanto tempo mi sento a mio agio per farlo rimanere nella cache, questo potrebbe essere ovunque da 15 secondi a, ore, giorni e settimane. E questo è per la memorizzazione nella cache dei dati dell'applicazione. C'è un'altra scadenza chiamata scadenza scorrevole che non serve per sincronizzare la cache con il database. È per la pulizia. Quindi, quell'ASP.NET, tutti i dati transitori di cui abbiamo parlato, beh, cosa succede quando hai finito con quei dati? Non dovresti preoccuparti di pulirlo. Quindi, puoi specificare una scadenza scorrevole e dire se nessuno usa questi dati per così tanto tempo, diciamo, in caso di sessioni di 20 minuti, se nessuno usa la sessione per quei 20 minuti, rimuovilo dalla cache. Quindi, questa è più una pulizia.
Quali sono i rischi in scadenza? La scadenza è in realtà, stai facendo un'ipotesi. Stai dicendo che penso di essere d'accordo con cinque minuti, ma non c'è alcuna garanzia che nessuno aggiornerà quei dati nel database in quel momento, specialmente se hai altre applicazioni o altri processi che aggiornano il database. Quindi, le scadenze sono buone solo in casi d'uso limitati.
Utilizzo delle dipendenze del database
Un'altra caratteristica molto importante è che potresti avere aggiornamenti imprevisti o imprevedibili nel database. In tal caso, la cache dovrebbe essere in grado di sincronizzarsi con il database. Quindi, la cache dovrebbe conoscere il tuo database. Dovrebbe diventare un client del tuo database e monitorare il tuo database per eventuali modifiche. C'è una funzionalità in ADO.NET chiamata dipendenza SQL. Qualcuno l'ha visto?
Quindi, la dipendenza SQL è cosa NCache utilizza per diventare un client del tuo server SQL o del tuo database Oracle. Quindi, in caso di server SQL, puoi utilizzare la dipendenza SQL del server SQL ADO.NET Feature that NCache utilizza per ottenere eventi dal database. La cache, NCache diventa un cliente del tuo database. Riceve eventi e quindi in base a ciò fa le sue cose. In alcuni casi non hai eventi. Quindi, diciamo, se avessi db2 o MySQL, non hanno eventi. Quindi, la cache dovrebbe essere in grado di eseguire il polling. NCache supporta anche il polling basato. Quindi, fai la stessa cosa, metti nella cache questo elemento nella cache e hai detto che questo corrisponde a questa riga in questa tabella e poi NCache eseguirà il polling e quindi, se i dati cambiano, li rimuoverà nuovamente dalla cache o ricaricherà una nuova copia. Ma, questa caratteristica, ti dà molto comfort.
Ancora una volta, la stessa cosa di cui stavo parlando, ovvero che vuoi assicurarti che la cache sia sempre sincronizzata con il database. La scadenza è abbastanza buona solo per un piccolo sottoinsieme dei casi d'uso.
Quindi, ti perderai la cache se non esegui un ricaricamento automatico. Quindi, quando si attiva la dipendenza SQL, rimuove, NCache rimuove l'elemento dalla cache. Quindi, se la tua applicazione lo desidera, mancherà la cache e quindi sarai costretto ad andare a prendere una nuova copia dal database. Se non vuoi perdere una cache che si trova in molte delle applicazioni di e-commerce perché leggono i dati così frequentemente che non vogliono che nulla aumenti il carico sul database, quindi dovresti effettivamente utilizzare la dipendenza SQL con questa funzione chiamata read through.
In realtà, ho bisogno di mostrarti del codice altrimenti inizia a diventare molto noioso. Quindi, lascia che te lo mostri rapidamente. Quindi, ho solo un'applicazione console molto semplice. In caso di NCache, tutto ciò che devi fare è aggiungere alcuni assembly qui. Quindi, c'è NCache.Runtime e NCache.Ragnatela. Quindi specifichi alcuni spazi dei nomi questi due e quindi ti connetti alla cache e hai il tuo handle della cache e, quindi crei un oggetto e quindi esegui Cache.Add. E tu specifichi la chiave. Questa non è una buona chiave. Volevo cambiarlo, ma la tua chiave dovrebbe avere il valore effettivo in essa. Quindi, fai un Cache.Add e specifichi l'oggetto.
In questo caso, sto usando anche una scadenza assoluta di un minuto. Quindi, specifichi la scadenza assoluta e il gioco è fatto. Questo è tutto ciò che fai per aggiungerlo alla cache. La prossima volta che ne avrai bisogno, eseguirai semplicemente un Cache.Get, specifica la stessa chiave e riavrai l'oggetto. Molto molto semplice per una scadenza assoluta. Potresti fare la stessa cosa per la scadenza scorrevole. Sebbene, invece di specificare un valore assoluto, devi specificare un intervallo come 10 minuti o 20 minuti. La dipendenza SQL è ciò che volevo mostrarti. Cosa sembra. Là! Quindi, lo stesso tipo di applicazione. Devi solo aggiungere questi due qui e specificare gli spazi dei nomi e quindi quando vai e aggiungi le cose alla cache è quando specifichi la dipendenza SQL.
Mi permetta solo di andare alla definizione di esso. Quindi, lo aggiungerò alla cache qui. Allora, ho la mia chiave che è quella che ti ho mostrato l'ultima volta. Ora invece di aggiungere l'oggetto, aggiungerò un elemento Cache. Questo è un NCache struttura. Quindi, memorizza l'oggetto effettivo e memorizzerà anche una dipendenza SQL. Così, NCache ha un oggetto dipendenza Cache. Quindi, faccio una nuova dipendenza dalla cache di SQL. Questo è un NCache classe che esegue il mapping internamente alla dipendenza SQL dei server SQL. Quindi, gli passi una stringa di connessione e la stringa di connessione è la stringa di connessione del tuo server SQL e le passi un'istruzione SQL. Quindi, qui nel mio caso, ho specificato seleziona questo dove l'ID prodotto è qualunque sia il mio valore. Quindi, lo sto solo mappando su una riga nella tabella del prodotto. E, specificando così tanto, ora l'ho appena detto NCache diventare un client del server SQL. E rimuovere questo elemento se questo cambia, se questa riga cambia nel database.
Quindi, dipende da quale sia l'istruzione SQL. Quindi, se il metodo della sequenza contiene solo una riga, viene mappato per eseguire solo una riga ed è quello che sarà. Di solito non puoi fare join in questo e questa è la limitazione della funzione di dipendenza SQL in ADO.NET ma, per una singola tabella puoi farlo facilmente. Quindi, è così che faresti il...
Quindi, il server SQL ha questa cosa chiamata broker SQL. Quindi, in realtà, crea un set di dati o una struttura di dati sull'estremità del server SQL per monitorare questi set di dati. Quindi, tutte le dipendenze SQL che crei, SQL Server crea strutture di dati per monitorare i set di dati. E, in base a ciò, ti invia una notifica SQL.
Quindi, devi configurarlo sull'estremità del server SQL perché è anche una questione di sicurezza, quindi il tuo DB deve essere coinvolto nella configurazione del server SQL ma è piuttosto semplice. Voglio dire, non c'è alcuna programmazione o altro necessario sul server e solo una configurazione. Tutte le cose sono curate dal lato cliente.
Read-through & Write-through
Bene! Quindi, abbiamo creato la dipendenza SQL. Volevo mostrarti che se non vuoi rimuovere questo elemento dalla cache, puoi ricaricare attraverso un read-through. Quindi, il read-through è un'altra funzionalità molto molto potente.
Il read-through è un codice lato server. In realtà, read-through è il codice che viene eseguito sul cluster di cache. Quindi, in realtà registri il tuo codice e viene eseguito sul cluster di cache. Si chiama bi NCache. E, il valore di un read-through ... lascia che ti mostri prima che aspetto ha il read-through e ti mostrerò qual è il valore, voglio dire perché vuoi eseguire il read-through. Quindi, ecco come appare un tipico read-through. È un'interfaccia IReadThrough. Fai un InIt in modo da poterti connettere alle tue origini dati. Fai uno smaltimento, ovviamente, e poi c'è un carico dalla fonte. Passa la tua chiave e si aspetta e gli elementi della cache indietro. Quindi, l'elemento cache contiene il tuo oggetto e un sacco di altre cose che puoi specificare scadenze e altre cose al suo interno. Interfaccia molto semplice.
Questo è chiamato da NCache Quindi, implementi questa interfaccia e registri il tuo assembly. In caso di NCache, registri il tuo assembly con la cache e ora quando esegui un Cache.Get e quell'elemento non esiste nella cache, la cache in realtà, NCache chiamerà il tuo read-through per andare a prenderlo dalle tue origini dati. La tua origine dati potrebbe essere un database, potrebbe essere un mainframe, qualsiasi origine dati. Quindi, avendo un read-through puoi assicurarti che una cache abbia sempre i dati e per quanto riguarda ciò che vede l'applicazione. Quindi, questo è un vantaggio.
Il secondo vantaggio è la ricarica che... Quindi, puoi effettivamente combinare la lettura. Quindi, puoi alla scadenza e alla sincronizzazione del database, quando l'elemento sarebbe stato altrimenti rimosso dalla cache e non vuoi che venga rimosso perché lo ricarichi comunque di nuovo. Quindi, perché non fare in modo che la cache non la ricarichi in questo modo perché se, pensa a questo, hai milioni di elementi nella cache e scadono tutti continuamente, giusto? Perché è così che l'hai configurato. E hai un e-commerce e un'applicazione ad alto traffico e ogni volta che qualcosa scade, hai molte richieste simultanee per esso. Andranno tutti al database. Quindi, improvvisamente il traffico del database è aumentato senza motivo, anche se non ne hai comunque bisogno nella cache.
Quindi, poiché ciò continua a succedere tutto il tempo, vedrai molti picchi nel traffico del database nonostante la cache. Quindi, ecco dove, avendo una ricarica significa che non viene mai rimosso dalla cache. Viene solo aggiornato. Quindi, le tue applicazioni non andranno mai al database. Continueranno a recuperare la vecchia copia e fino al punto in cui non la aggiornerai. Quindi, hai improvvisamente rimosso o risolto quel problema in cui, anche se avevi la cache, vedevi molti picchi nel traffico del database a causa delle scadenze o della sincronizzazione del database. Quindi, facendo ricaricare la cache attraverso il read-through, lo rende davvero molto potente.
L'altro vantaggio del read-through, ovviamente, è che stai centralizzando, stai semplificando il livello dell'applicazione perché sempre più accesso al database viene eseguito dalla cache. Quindi, se hai più applicazioni che accedono agli stessi dati, puoi davvero centralizzare l'accesso ai dati all'interno del livello di memorizzazione nella cache. Ovviamente, non puoi farlo per tutti i dati, ma per molti dati puoi farlo.
Il write-through funziona allo stesso modo del read-through. Mi permetta solo di andare alla scrittura. Funziona allo stesso modo. Ha un provider di scrittura, ancora InIt, eliminato e ora invece di caricare è una scrittura sull'origine dati e ha un altro tipo di scrittura di massa. Write-through, un vantaggio è lo stesso della lettura che consiste nel centralizzare tutto. Il secondo vantaggio è che puoi eseguire un write- behind, ovvero aggiornare la cache che è, come ho detto, dieci volte più veloce del database e quindi chiedere alla cache di aggiornare il database. E il write-behind è essenzialmente lo stesso del write-through, ma eseguito in modo asincrono. È una coda che viene creata e viene elaborata. Tale coda viene replicata anche in caso di NCache. Quindi, nessuno degli aggiornamenti viene perso se un server si interrompe. Ma il write- behind velocizza davvero l'applicazione perché, voglio dire, l'hai già resa più veloce memorizzando nella cache tutte le letture, giusto? Quindi, circa il 70-80 percento delle letture sono ora o le transazioni vanno comunque nella cache. Perché non velocizzare anche le scritture? Se puoi farlo in modo write-behind, se puoi permetterti di fare una scrittura asincrona. Se i dati sono troppo sensibili dove non puoi permetterti, allora esegui un write-through, quindi ottieni solo il primo vantaggio che è la centralizzazione del codice. Il secondo vantaggio di prestazioni più veloci arriva solo se puoi eseguire l'asincrono.
Conclusione
L'idea è che quando inizi a fare la memorizzazione nella cache, non pensare a una cache che è solo un semplice valore chiave qui, voglio dire, il mio intero scopo era innanzitutto convincerti che hai davvero bisogno di una cache distribuita come parte di la tua infrastruttura e l'architettura dell'applicazione. Se vuoi che le applicazioni siano scalabili, devi incorporare questo indipendentemente dal prodotto di memorizzazione nella cache che usi, voglio dire, dovresti solo averlo. Attualmente per le persone .NET, le opzioni sul mercato sono NCache che è un open source e anche commerciale. C'è Redis che Microsoft ha reso disponibile almeno su Azure. In Azure è un servizio di cache gestito, al di fuori di esso è necessario installarlo e si installa principalmente su Linux a meno che non si utilizzi la versione open source non supportata. Sul lato Java, ci sono molte più opzioni per la memorizzazione nella cache. Quindi, questo è stato il primo di tutto.
Secondo obiettivo che dovresti capire, non è un semplice valore chiave. Vuoi assicurarti di poter memorizzare nella cache tutti i tipi di dati e gestire tutti i tipi di situazioni ed è qui che ottieni il vero vantaggio. E non sono nemmeno arrivato all'altra parte perché in realtà sto esaurendo il tempo che era, ad esempio, come fai la condivisione dei dati di runtime e quali sono alcune delle cose architetturali che vuoi assicurarti che la cache è sempre dinamica in modo da poter configurare le cose. Fa parte del tuo data center, fa parte del tuo ambiente di produzione. Quindi, qualsiasi cache che non ti consenta di apportare modifiche in fase di esecuzione non è una buona cache da scegliere perché. Quindi rimarrai bloccato con molti tempi di fermo, quindi abbiamo clienti che hanno programmato tempi di fermo una volta all'anno, sai. Quindi, alcuni dei nostri clienti non lo hanno nemmeno perché hanno una disponibilità così elevata.
Vogliono persino aggiornare la cache stessa di una nuova versione senza tempi di inattività. Quindi, voglio dire, dipende da quali sono le tue esigenze aziendali. Ma tutte queste cose devono essere prese in considerazione, molte persone ora hanno più data center. Almeno per scopi di ripristino di emergenza e quindi anche per il bilanciamento del carico geografico, se lo hai, ti aspetti che il tuo database si replichi, giusto?
Quindi, perché la cache non dovrebbe essere in grado di supportare più data center? Perché, meno una cache può fare, più dovresti fare. Questa è la linea di fondo. Poiché le esigenze dell'applicazione non cambieranno, la cache deve adattarsi. Quindi, tieni tutto questo a mente.
Quindi, c'è un confronto tra NCache ed Redis.
Sono entrambi open source. NCache ha anche Enterprise Edition. Quindi, in pratica, se il tuo .NET, NCache si adatta molto bene. Nel NCache, N sta per .NET, in conclusione, voglio dire che è così che siamo impegnati in .NET.