Campo del codice di Orlando
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
Il discorso di oggi non riguarda NCache, si tratta di cache distribuita. Mi riferirò a NCache ad esempio, ma i concetti sono generali, quindi si applicano a tutte le cache.
Cos'è la scalabilità
Bene! Cerchiamo prima alcune definizioni di mezzo. La prima definizione è Scalabilità. La scalabilità non è la prestazione dell'applicazione. Se hai cinque utenti e la tua applicazione funziona molto velocemente, la tua applicazione non è scalabile finché non può avere le stesse buone prestazioni con cinquemila utenti, cinquantamila o cinquecentomila. Quindi, la scalabilità riguarda prestazioni elevate con carichi di picco. Le persone a volte confondono le prestazioni con la scalabilità. La tua applicazione potrebbe non avere buone prestazioni con cinque utenti, nel qual caso la memorizzazione nella cache non ti sarebbe stata di aiuto, hai altri problemi da risolvere.
Scalabilità lineare
La scalabilità lineare è, se la tua applicazione è progettata in modo tale da poter aggiungere più server e aggiungendo più server puoi aumentare la capacità di transazione. Ancora una volta, la scalabilità che stiamo definendo in termini di capacità di transazione in termini di quanti utenti quante transazioni al secondo può gestire la tua applicazione. Quindi, se la tua applicazione è in grado di gestire più transazioni in modo più lineare man mano che aggiungi più server, allora la tua scalabilità lineare e il nostro obiettivo è quello di essere una scala lineare per avere una scalabilità lineare nella nostra applicazione.
Scalabilità non lineare
E sicuramente non vogliamo la scalabilità non lineare, ovvero che la tua applicazione sia progettata in modo tale che dopo un certo punto, non importa se aggiungi più server la tua applicazione non aumenterà, anzi probabilmente aumenterà far cadere. Ciò significa che ci sono alcuni colli di bottiglia da qualche parte che non sono stati risolti.
Quali app necessitano di scalabilità?
Quindi, perché vogliamo la scalabilità e quali applicazioni necessitano di scalabilità?
Di solito, si tratta di applicazioni che sono applicazioni lato server. Questi sono ASP.NET ora ASP.NET core, Web Services, backend IOT, elaborazione big data. Sebbene l'elaborazione di big data non sia comune sul lato .NET, è più legata ai fenomeni Java, ma dovrebbe essere in grado di farlo anche con .NET, ma anche le app di elaborazione di big data richiedono scalabilità e qualsiasi altra applicazione server. Ad esempio, potresti essere una banca e hai milioni di clienti e loro chiamano e cambiano indirizzo o magari emettono o chiedono una nuova carta o forse trasferiscono fondi e devi elaborare tutte quelle richieste in modalità batch su notte e ci sono alcuni requisiti di conformità che devi adempiere prima del giorno lavorativo successivo. Quindi, man mano che ne ottieni sempre di più, anche le altre applicazioni di elaborazione batch devono essere scalabili. Quindi, non sono solo queste applicazioni. Qualsiasi altra applicazione che deve semplicemente elaborare molte transazioni in un tempo compresso e quel tempo compresso in questi casi è transazioni al secondo e quel tempo compresso in questo caso potrebbe rientrare nel requisito di conformità. Quindi, se hai una di queste applicazioni ad alto traffico o transazioni elevate, sei arrivato al discorso giusto.
Problema di scalabilità
Allora, dov'è il problema della scalabilità? Perché abbiamo anche questa conversazione? Sicuramente non è nel livello dell'applicazione che il livello dell'applicazione si ridimensiona molto bene, hai un bilanciamento del carico e puoi aggiungere sempre più server. Tutto sembra molto bello. Il problema è davvero nel tuo database, nel tuo archivio dati. E con questo intendo database relazionali o dati legacy del mainframe. Inoltre, non puoi ridimensionarli nello stesso modo in cui puoi ridimensionare il livello dell'applicazione. Il motivo è perché i dati in questo non vengono distribuiti. La natura del database è che deve essere tutto messo insieme. E lo stesso vale con il mainframe. Quindi, il database potrebbe essere molto veloce. Potrebbe essere memorizzato nella cache sul lato server ma non si ridimensiona e NoSQL databases.
Sebbene sia uno dei motivi per cui le persone usano NoSQL è per la scalabilità delle transazioni, l'altro è per la scalabilità dei dati in termini, diciamo, hai terabyte e terabyte di dati che NoSQL è molto più adatto a questo. E il terzo motivo per cui le persone lo usano perché i documenti JSON offrono questa flessibilità di schema. Ma, NoSQL databases non sono sempre in grado di aiutarti e il motivo è perché richiedono di spostare i dati dai database relazionali in un NoSQL database. Cosa succede se non sei in grado di farlo per una serie di motivi, sia tecnici che commerciali. Alcuni dei dati devono rimanere nei tuoi database relazionali e nei tuoi dati mainframe legacy. Sebbene, NoSQL databasesono fantastici e abbiamo a NoSQL database che abbiamo lanciato noi stessi l'anno scorso chiamato NosDB, come ho già detto, ma non risolveranno il tuo problema a meno che tu non riesca a inserire i dati al loro interno. Quindi, se devi lavorare con database relazionali, devi risolvere il problema di scalabilità che pongono ed è qui che entra davvero in gioco una cache distribuita.
Distribuzione cache distribuita
In sostanza, una cache distribuita è un negozio distribuito in memoria.
Logicamente, è solo tra il livello dell'applicazione e il livello dei dati. Fisicamente, potrebbe essere un gruppo di VM separate o potrebbe trovarsi nella stessa scatola dell'applicazione o alcune di esse potrebbero essere qui, alcune potrebbero essere qui e queste sono le cose di cui parleremo. Ma logicamente, è tra il livello dell'applicazione e il livello del database. E l'argomento fondamentale è che se si memorizzano nella cache i dati non si accede al database con la stessa frequenza. Perché, non vai al database, non ottiene tutto quel carico, quindi non diventa un collo di bottiglia. Se l'80% delle volte puoi passare al livello di memorizzazione nella cache e il livello di memorizzazione nella cache non ha il collo di bottiglia che ha un database perché è anche distribuito proprio come un NoSQL database viene distribuito anche un livello di memorizzazione nella cache. È una chiave/valore. In realtà, un'altra parola per una cache distribuita è in-memory NoSQL key value store perché tutto ciò che metti nella cache di distribuzione c'è una chiave e c'è un valore che è il tuo oggetto. Quindi, facendo quell'80 percento delle volte andrai qui il 20 percento delle volte andrai al database. Quel 20 percento è per lo più aggiornamenti.
Ovviamente ci sono alcune letture e anche questi aggiornamenti funzionano più velocemente perché non c'è concorrenza con le transazioni di lettura e questo non è più un collo di bottiglia. Come mai? Perché una cache distribuita formerà un cluster di due o più server. Queste non sono scatole costose, non sono il tipo di scatole del tuo server di database. Si tratta di una configurazione tipica del server Web, proprio come una scatola a quattro o otto core, solo molta memoria. Lotti significa che da 16 a 32 giga è ciò che consigliamo ai nostri clienti. Alcuni dei nostri clienti hanno più di 32 ma non consigliamo quasi mai di andare più di 64. È meglio aggiungere un'altra casella che averne di più qui. Perché, se aggiungi più memoria, la potenza di elaborazione deve essere aggiornata. Come mai? Perché un'applicazione .NET ha questa cosa chiamata Garbage Collection e più memoria devi raccogliere, più Garbage Collector o GC deve funzionare e la CPU diventa un collo di bottiglia in quel caso e la tua applicazione inizia ad avere problemi. Quindi, il punto debole è compreso tra 16 e 32 giga di memoria in queste macchine virtuali o box fisici e la maggior parte dei nostri clienti utilizza le macchine virtuali qui. E, circa 8 core come configurazione hardware e solitamente due schede di rete, una scheda di rete è per il clustering e una è per i client per comunicare con essa. La parola client significa il tuo server delle applicazioni, quindi non sono i tuoi client. È il tuo server delle applicazioni che è il client della cache.
Quindi, un minimo di due server di cache e quindi un rapporto di quattro a uno o cinque a uno tra il livello dell'applicazione e il livello di memorizzazione nella cache. E quel rapporto si basa principalmente su ciò che abbiamo visto nel corso degli anni e siamo stati in questo spazio per oltre dieci anni, che se stai aggiungendo più server qui per aggiungere più attività, allora sopra il nostro quattro a uno o un rapporto di cinque a uno ti darà una capacità molto buona. E, naturalmente, aggiungi più server per uno dei tre motivi. O hai bisogno di più spazio di archiviazione perché hai esigenze di memoria come abbiamo appena parlato o hai bisogno di più capacità di transazione perché avevi due server con cui iniziare e hai continuato ad aggiungere caselle qui fino a quando lo scarto non è stato esaurito. In un database relazionale, se ciò accade sei bloccato. Sei incazzato. In questo caso, tutto ciò che devi fare è aggiungere una terza scatola fino a quando la capacità della terza scatola non si esaurisce e quindi aggiungerne una quarta e così via. Quindi, puoi avere tutte le scatole che vuoi qui. Abbiamo clienti che in media hanno da cinque a dieci scatole qui e alcuni dei nostri clienti hanno da 40 a 50 scatole qui nel livello dell'applicazione e quindi hanno di conseguenza. Quindi, per un livello di applicazione da dieci o dieci server, avresti circa tre server nel livello di memorizzazione nella cache. Quindi, è così che fai la tua pianificazione.
Quindi, l'obiettivo del discorso finora è convincerti che disponendo di un livello di memorizzazione nella cache non avrai più un collo di bottiglia della scalabilità. Pertanto, indipendentemente dal prodotto, dalla soluzione di memorizzazione nella cache utilizzata, è necessario incorporare un livello di memorizzazione nella cache nell'applicazione. Quindi, devi progettare la tua applicazione per avere una cache nella tua immagine e in questo modo non avrai mai colli di bottiglia.
Casi d'uso di cache distribuita
Quindi, ora che siamo convinti che dovresti usare la cache come sviluppatore .NET, la prossima domanda che viene in mente è dove dovresti usarla? Come dovresti usarlo?
E il primo caso d'uso è la memorizzazione nella cache dei dati dell'applicazione di cui ho parlato fino ad ora, ovvero hai i dati dell'applicazione in un database e li metti nella cache qui, quindi non devi andare al database, questa stessa cosa .
Memorizzazione nella cache dei dati dell'app
L'unica cosa da tenere a mente su questo caso d'uso è che i dati ora esistono in due posti uno è il master che è il database e uno è la cache che non è che è l'altro posto. Quindi, se i tuoi dati esistono in due posti, cosa andrà storto? Se ne hai due copie, la preoccupazione più grande è che la cache sarà fresca, la cache avrà la stessa versione dei dati del database perché se la cache non avrà la stessa versione dei dati, allora tu sarà costretto a memorizzare nella cache i dati di sola lettura. Inoltre, i dati di sola lettura rappresentano circa il 10-15% dei dati totali. Quindi, non stai davvero beneficiando bene. Ne stai beneficiando ma non nella misura in cui dovresti rendere davvero scalabile la tua applicazione.
Quindi, in effetti, è così tanto che se chiedi a una persona media a cosa serve una cache. Direbbero bene che ci inserirò i miei dati di sola lettura. Tutti hanno paura di memorizzare nella cache i dati transazionali. I tuoi clienti, i tuoi account o i dati delle tue attività che cambiano ogni 30 secondi, ogni minuto, ogni cinque minuti o in modo imprevedibile. Quindi, le persone hanno paura di memorizzarlo nella cache per questo motivo perché ci sono due copie di esso e cosa succede se la cache non sa che l'hai cambiata nel database. Quindi, teniamolo a mente mentre andiamo oltre.
Memorizzazione nella cache specifica di ASP.NET
Il secondo caso d'uso è, se si dispone di un'applicazione ASP.NET, il più comunemente noto è il stato della sessione. E questo è anche il nulla in questo, il primo esempio è lo stato della sessione. Le sessioni sono qualcosa che per impostazione predefinita hai due opzioni di archiviazione. Uno è InProc, l'altro è SQL, fornito da Microsoft. In un locale è presente anche un server di stato, ma tutte e tre le opzioni presentano problemi di scalabilità. Il server SQL presenta problemi di prestazioni. Lo stesso motivo per cui non avremo la memorizzazione nella cache per cominciare. Quando archivi sessioni in SQL, vengono archiviate come BLOB. La relazione è SQL come tutti i database relazionali non sono stati progettati per l'archiviazione BLOB, è per i dati strutturati. Quindi, non funziona. Ci sono molti problemi. La maggior parte dei nostri clienti quando vanno a NCache, il primo caso d'uso è lo stato della sessione. Questo perché questo ottiene il loro beneficio immediato. E la cosa davvero bella dello stato della sessione è che non c'è programmazione perché c'è un framework fornito da Microsoft che consente una cache di terze parti come NCache per collegare e tutto proprio qui è memorizzato nella cache.
L'altro aspetto di ASP.NET è se non hai il framework MVC, se sei nel framework pre MVC che sono ancora molte applicazioni ASP.NET, allora c'è una cosa chiamata stato di visualizzazione. E, per quelli di voi che non sanno quale sia lo stato di visualizzazione, è una stringa crittografata che viene inviata dal server Web al browser solo per essere riportata su un post. Quindi, potrebbero essere centinaia di kilobyte di forza crittografata che vanno e tornano. E, quando lo moltiplichi per milioni di transazioni che la tua applicazione elaborerà, è come minimo molta larghezza di banda. E la larghezza di banda non è gratuita tra l'altro è piuttosto costosa.
E, in secondo luogo, ovviamente, ma quando devi inviare un carico utile così pesante per le tue prestazioni, il tuo tempo di risposta è più lento. Quindi, sarebbe molto più bello se potessi semplicemente memorizzare nella cache lo stato di visualizzazione sul server inviando una piccola chiave, quindi quando si verifica il postback, la chiave torna e lo stato di visualizzazione viene recuperato dalla cache e presentato alla pagina. Quindi, questo è il secondo caso d'uso. Ancora una volta, allo stesso modo, non è coinvolta alcuna programmazione, basta collegare una cache di terze parti come NCache.
Il terzo caso d'uso è il Cache di output ASP.NET. Questa cache è l'output della pagina. Se l'output della pagina non cambia, Microsoft dispone già di un framework che lo memorizza nella cache in un InProc locale autonomo. È meglio inserire una terza cache distribuita al suo posto, in modo che in una web farm la prima volta che l'output di una pagina viene memorizzato nella cache, sia disponibile per l'intera web farm invece che per ogni server web che memorizza nella cache la propria copia.
Quindi, questi sono i tre casi d'uso per le applicazioni ASP.NET oltre alla memorizzazione nella cache dei dati dell'applicazione.
Ora la natura del problema qui è completamente diversa qui. In questo avevi due copie dei dati. Qui, la cache è il negozio principale. Quindi, non stai più archiviando le sessioni nel database. Non stai più memorizzando lo stato di visualizzazione da nessun'altra parte. Quindi, la cache è l'archivio principale ed è un archivio in memoria. Quindi, quando un negozio in memoria è un negozio principale, cosa potrebbe andare storto? la memoria è volatile! Sì. Quindi, non c'è persistenza. Quindi, una buona cache distribuita deve replicare i dati su più server per fornire l'affidabilità dei dati, in modo da non perdere quella sessione. Perché potresti essere una compagnia aerea e hai fatto questa promozione speciale per il fine settimana alle Hawaii e hai il doppio o il triplo del traffico sul tuo sito Web e sono persone che hanno fatto tutti i tipi di ricerche e stanno per premi il pulsante di invio e perdono la sessione. Potresti perdere quel cliente con migliaia di dollari di vendite per ogni cliente. Quindi, sicuramente non vuoi perdere la sessione. Quindi, non mettere le sessioni in una cache a meno che non esegua la replica.
Condivisione dei dati di runtime
Il terzo caso d'uso è una condivisione dei dati di runtime. Questo è qualcosa che molte persone non conoscevano da molto tempo. Le persone usano le code di messaggi per condividere gli eventi su più applicazioni. Ma una cache distribuita ti offre un meccanismo di eventi focalizzato sui dati molto semplice e potente in cui, pensa a questo ora come a un bus di servizio o come un bus di messaggi, queste sono le tue applicazioni che possono comunicare tra loro attraverso questo. Quindi, invece di usare MSMQ o RabbitMQ, che hanno i loro vantaggi, una cache non è qui per sostituirli. Tuttavia, se la tua esigenza riguarda maggiormente i dati o se la tua esigenza di messaggistica riguarda maggiormente i dati e all'interno dello stesso data center, una cache distribuita ti offre un'interfaccia più semplice ma soprattutto è più scalabile. Quindi, se hai un'applicazione di transazione più elevata e ancora, tutto questo discorso riguarda la scalabilità.
Quindi, anche se potresti fare tutte queste cose con queste normali code di messaggi. Quando si entra in un ambiente di transazione molto elevato, non vengono distribuiti nello stesso modo in cui lo è una cache distribuita. Quindi, una cache distribuita ti consentirà di fare tutto questo. Diciamo che tipo Pub/Sub di una condivisione dati, ci sono notifiche di eventi, c'è una funzione di query continua che NCache ha che hanno anche le cache Java, quello Redis no, con il quale puoi semplicemente condividere i dati tra le applicazioni in modo molto semplice. E anche qui il problema è simile all'applicazione, la memorizzazione nella cache specifica di ASP.NET perché sebbene questi dati probabilmente esistano in un database ma non nella forma in cui li stai condividendo.
Quindi, probabilmente l'hai trasformato in parte del modulo prima di provare a condividerlo in modo che il modulo trasformato venga mantenuto nella cache. Quindi, non vuoi perdere quei dati, quindi una cache deve replicare i dati. In realtà, anche per la memorizzazione nella cache dei dati dell'applicazione, anche se tecnicamente potresti, se perdi alcuni dati perché un server cache si interrompe e non hai replicato. Potresti tecnicamente ricaricare quei dati dal database. Non c'è problema tranne che c'è un colpo di performance perché, qualunque cosa diciamo, se sono stati 16 giga di dati che hai perso, ora devi passare attraverso 16 giga di colpi di database che non vuoi fare. Quindi, la maggior parte dei nostri clienti, anche per la memorizzazione nella cache dei dati delle applicazioni, sceglie di replicare perché la memoria è così economica. Non vogliono nemmeno prendere quel colpo di performance. Con questi due, ovviamente, devi averlo, ma in questo è una specie di è bello averlo.
Demo pratica
Ok, prima di andare avanti su come farlo, voglio prima mostrarti che aspetto ha una cache. lo userò NCache come l'esempio qui.
Creazione di un ambiente
Quindi, ho in azzurro ho tre VM demo1, demo2 e demo-client. demo1 e 2 saranno le mie VM del server cache e il client demo è la mia VM del server delle applicazioni. Nel tuo caso, supponiamo che tu abbia due VM cache e quindi un rapporto da quattro a cinque, da quattro a uno o da cinque a uno delle VM client.
Quindi, ho effettuato l'accesso al client demo e userò questo strumento NCache ha chiamato NCache gestore. Quindi, ho iniziato qui. Verrò qui e dirò di creare una nuova cache in cluster.
Crea una cache raggruppata
Tutte le cache in NCache sono nominati, quindi lo chiamerò semplicemente democache, non entrerò nei dettagli del significato di ciascuno di questi, ne parlerò tra un po' ma sceglierò un topologia di replica partizionata. In caso di NCache, una topologia significa come vengono archiviati e replicati i dati? Una topologia di replica partizionata è qualcosa che... se dovessi tornare se dovessi venire qui, pensa a questo come a un cluster di cache a due nodi che starebbe per creare.
Se si tratta di una replica partizionata, ogni server avrà una partizione. Quindi, ci saranno un totale di due partizioni. In caso di NCache, l'intera cache ha circa un migliaio di bucket, quindi circa la metà andrà alla partizione uno, metà alla partizione due.
Viene eseguito il backup di ogni partizione su un server diverso chiamato replica. La replica in caso di NCache è passivo, il che significa che nessun client comunica con le repliche, solo la partizione comunica con le repliche. Inoltre, la replica diventa attiva solo quando la sua partizione primaria o quando la partizione si interrompe.
Il che significa, diciamo, se questo server dovesse andare, diciamo, se avessimo un cluster a tre nodi e una partizione, diciamo che il server tre si è interrotto, la partizione tre ora è inattiva. Quindi, la replica tre diventerà automaticamente la partizione tre, in modo da non perdere alcun dato. Quindi, le repliche partizionate offrono queste strategie di archiviazione e replica. In sostanza ti dice che i dati devono essere replicati. C'è anche una replica sincrona e asincrona. Quindi, comunque, tornerò su questo, ma volevo solo mostrarti cosa significa. Quindi, sceglierò una replica asincrona tra la partizione e le repliche. Quindi specificherò il mio server cache, quindi il primo è demo1, il secondo è demo2. Ora, tutto quello che sto dicendo in caso di NCache, puoi scriverlo completamente, in modo che possa essere automatizzato. Lascerò tutte le impostazioni predefinite. Questa è la porta TCP su cui si sono formati i cluster di cache. Specifica la quantità di memoria che voglio che la cache utilizzi su questo server e la cache non utilizzerà più di questa memoria. Quindi, qualunque cosa specifichi qui è questa volta due perché. C'è una partizione e c'è una replica.
Quindi, questa è la dimensione di una partizione. Quindi, nel tuo caso sarà molto più di questo ovviamente perché, se hai 16 giga in un server cache dovresti lasciare da 2 a 2.5 giga per il sistema operativo e altri processi e allocare il resto. Quindi, diciamo, da un 16 giga ne hai 13 e mezzo rimasti, ma 13 e mezzo diviso per 2 sarebbe una dimensione della partizione e quindi NCache farà in modo che non utilizzi più di questa memoria. Quindi, quando viene consumata tanta memoria, la cache viene considerata piena in caso di NCache. E poi NCache ha una delle due opzioni. Uno, puoi dirlo NCache rifiuterà qualsiasi nuova aggiunta di dati fino a quando alcuni dei dati non scadono automaticamente o puoi fare ciò che questa cosa chiamata sfratto. Così, NCache ti offre tre algoritmi di sfratto LRU, LFU e FIFO prioritario. Quindi, puoi dire in questo caso, sfratta il 5% della cache.
Quindi ora voglio parlarne un po' nel contesto di, diciamo che stai memorizzando in ciascuno dei caso d'uso qui. Se stai eseguendo la memorizzazione nella cache dei dati dell'applicazione, l'eliminazione è perfettamente OK. Non c'è problema. Hai appena esaurito la memoria che avevi sfrattato alcuni dei meno utilizzati di recente e poi hai fatto spazio a nuovi dati. Quindi, diventa come una finestra in movimento, giusto? Quindi, man mano che usi sempre più dati, quello più vecchio viene rimosso e quello nuovo. Quindi, questo è il più comunemente usato. Ma cosa succede se si tratta di una sessione? Se la cache viene utilizzata per archiviare le sessioni, non desideri sfratti. Perché non vuoi che venga sfrattato? Perché la sessione potrebbe essere ancora attiva. Potrebbe non aver superato quei 20 minuti o qualunque sia il tuo timeout. Se è così e continui a rimuovere la sessione, stai forzando lo stesso problema di cui abbiamo appena parlato, ovvero che un utente non si è disconnesso ma stai calciando. Quindi, quello che devi fare è pianificare la tua capacità. In caso di NCache, puoi farlo molto facilmente, puoi vedere quanta memoria sta consumando una sessione media e quindi pianificare la tua capacità. Estrapola quanta memoria verrà utilizzata. Fai la capacità che quest'altra memoria di sessione non verrà mai eliminata. L'archiviazione dei dati dell'applicazione o la cache dei dati dell'applicazione possono essere eliminati, nessun problema. Tuttavia, la cache della sessione non dovrebbe essere rimossa. Dovrebbe scadere solo quando l'utente non utilizza più la sessione.
Quindi, dirò solo fine e ho un cluster di cache a due nodi. Verrò qui e aggiungerò un nodo client. Nel mio caso ho solo un nodo client come ho detto. Penso che probabilmente non ho la cache, quindi abbiamo iniziato. Ho bisogno di quel servizio così il NCache manager può parlare con questo ed eseguire la configurazione. Bene! Ora che l'ho fatto, verrò qui e dirò di avviare la cache. Quindi ora avviando la cache, NCache sta costruendo un cluster tra queste due scatole, a quel TCP.
Simula lo stress e monitora le statistiche della cache
Quindi, in modo da non entrare nei dettagli di quali caselle hanno quali dati e se il cluster. Sai solo che c'è un democache. Ogni volta che ti connetti a quella cache, la tua applicazione si connetterà automaticamente a tutti i server in caso di repliche partizionate. Così, NCache si prende cura di tutti i dettagli e verrò qui e dirò di visualizzare le statistiche e questi sono alcuni contatori PerfMon su in modo che tu possa vedere cosa NCache lo farà ma una volta che inizi a usarlo. Inizierò anche questo strumento chiamato NCache tenere sotto controllo. Ed è come uno strumento in stile dashboard. E, in caso di NCache, hai questa possibilità di utilizzare uno strumento di stress test che ti consente di simulare molto rapidamente l'utilizzo dell'applicazione senza alcuna programmazione.
Quindi, ad esempio, dirò democache dello strumento di stress test, quindi se ne prenderà uno e cose del genere. E all'improvviso, ora vedrai che questo strumento sta parlando con entrambi i server della cache e sta eseguendo circa 700 richieste al secondo su ciascuna scatola, da 7 a 800 fino a mille. Diciamo che voglio aumentare il carico. Quindi, voglio lanciare un altro strumento di stress test.
Questo è come faresti con la tua applicazione. Voglio dire, quando vuoi metterti alla prova con la tua applicazione, eseguirai la tua applicazione con uno strumento di stress test e poi continuerai ad aggiungere sempre più stress e quindi vorrai vedere se l'intero sistema funziona. Quindi, in questo momento stai solo testando il componente cache di esso. La maggior parte dei nostri clienti cosa fanno quando valutano NCache, fanno questo benchmarking. Quindi, una volta che hanno configurato tutto nel loro ambiente, anche se abbiamo pubblicato i nostri benchmark, non lo fanno. Voglio dire, verificano tutto nel loro ambiente. Quindi, man mano che ne aggiungi sempre di più, vedrai che questo carico è appena raddoppiato.
Lasciami andare un altro strumento per lo stress test. Vedrai che continua a salire. Proprio lì, vedi! Quindi, posso continuare ad aggiungere sempre più strumenti di stress test, fino a quando non riesco a massimizzare la CPU del mio client. Quindi, sono passato a circa il 50 percento sul mio server delle applicazioni. Quindi, posso sicuramente aggiungere più strumenti per i test di stress. Una volta che avrò raggiunto il limite massimo di quel client, aggiungerò un altro client. Quindi, è così che posso. Quindi, anche in questo momento, ad esempio, stiamo eseguendo circa 5,000 richieste al secondo con solo tre strumenti di stress test. Quindi, con questo e poi puoi anche monitorare ad esempio qui tutta questa roba. Quindi, con questo puoi effettivamente vedere come appare una cache. E ora, entriamo più nel dettaglio dal punto di vista degli sviluppatori.
Memorizzazione nella cache specifica di ASP.NET
Quindi, ora che sai che aspetto ha una cache, vediamo come utilizzare quella cache all'interno della tua applicazione. Quindi, per ASP.NET, come ho detto, la prima cosa che dovresti fare è usare la cache per le sessioni. Come mai? Perché è il più semplice. Non c'è programmazione, non c'è sforzo che puoi fare. Ti ho appena mostrato quanto velocemente puoi configurare una cache con interesse NCache, diciamo che se dovessi venire qui e approfondire parte del codice di esempio avrei dovuto già aprirli, ma non lo faccio. Quindi, ecco un'applicazione ASP.NET da utilizzare NCache con ASP.NET per le sessioni. Devi solo andare e modificare web.config. Quindi, ho il web.config. La prima cosa che devi fare è aggiungere questa catena di montaggio al montaggio. NCache, questo provider dell'archivio sessioni è NCache assembly che ha implementato l'interfaccia del provider dell'archivio sessioni ASP.NET. Quindi, questo è ciò che consente NCache per collegarsi. Quindi, puoi semplicemente copiare la riga qui e poi arrivi al tag di stato della sessione, che è proprio qui. In caso di NCache, basta copiare quel tag. Assicurati che questa modalità sia personalizzata perché è ciò che consente a quella cache di terze parti di collegarsi. Il timeout è quello che vuoi che sia e quindi l'unica cosa di cui hai bisogno in caso di NCache è assicurarsi che il nome della cache sia specificato.
Quindi, una volta installato NCache quindi sui server cache si installa la parte del server, sul server delle applicazioni di cui si installa la parte client NCache, crei la cache come abbiamo appena fatto e aggiorni questo e basta. Questo è tutto lo sforzo di cui hai bisogno per iniziare a usarlo NCache e quindi ogni sessione è un oggetto nella cache. Quando lo fai in quel contatore PerfMon, vedrai quante sessioni stai vedendo. Cosa succede in genere, i nostri clienti creano tre cache. Quindi, abbiamo appena creato una cache qui, giusto? Quindi, i nostri clienti creeranno tre cache. Una delle cache è per le sessioni. Quindi, hanno una cache separata per le sessioni. Una delle cache e due cache sono per i dati dell'applicazione. Uno è quello che chiamano i dati di riferimento. L'altro sono i dati transazionali. I dati transazionali sono qualcosa che cambia molto frequentemente. E, il motivo per cui lo fanno è a causa di alcune delle altre funzionalità di cui parlerò. Ma, sulle stesse VM, puoi avere più di una cache creata. Quindi, questo è tutto ciò che devi fare per l'archiviazione dello stato della sessione, è molto semplice, non è necessaria alcuna programmazione e quindi sei a posto.
Memorizzazione nella cache dei dati dell'app
Ma, se si desidera eseguire la memorizzazione nella cache dei dati dell'applicazione, sfortunatamente nello spazio .NET EF core ora fornisce finalmente un'architettura in cui è possibile collegare una cache di terze parti.
NCache lo supporta anche. Ma, fino a EF6 incluso EF6, l'architettura non supportava realmente il collegamento di una cache di terze parti. NHibernate per molto tempo ha supportato quell'architettura. Quindi, per NHibernate NCache può collegarsi senza alcuna programmazione. Quindi, anche la memorizzazione nella cache dei dati delle applicazioni con funzionalità minime, puoi semplicemente fare a meno di eseguire chiamate API. Ma, per la maggior parte, devi essere mentalmente preparato lì per la memorizzazione nella cache dei dati dell'applicazione, dovrai fare la programmazione. Ma è un'API molto semplice. Questa API assomiglia molto a un oggetto cache ASP.NET. Ti connetti alla cache con un nome di cache.
Lascia che ti mostri rapidamente come appare. Fammi aprire... Ho riscontrato alcuni problemi con la macchina virtuale di Azure. Comincio quest'altra roba e poi a questo tutto aperto. Quindi, diciamo che ho questa applicazione console davvero di base. La prima cosa che devi fare è collegare due dei NCache assemblee, uno lo è NCache.Runtime, l'altro è NCache.Ragnatela. NCache.Web è la vera API che stai chiamando. Quindi colleghi questi due o usi di nuovo questi due spazi dei nomi NCache.Runtime e poi .Web.Caching. All'inizio della tua applicazione, ti connetti alla cache in base a un nome e ottieni un handle della cache proprio come per il database. Ovviamente, in un'applicazione ASP.NET probabilmente lo farai nel global.ASAX nell'avvio dell'applicazione o nel metodo InIt. Quindi crei il tuo oggetto e fai Cache.Add. Cache.Add utilizzerà una chiave, una sorta di stringa. Questa non è una buona chiave, la tua chiave deve essere molto più specifica e quindi ecco il tuo oggetto e basta. Fai quella chiamata e dietro le quinte ora sta andando. Diciamo che se si dispone di quella topologia di replica partizionata, ciò che accadrà è che l'applicazione è connessa. Quindi, ogni scatola è collegata a tutti i server di cache. Quindi, hai appena fatto un Cache.Add giusto? Quindi, Cache.Add andrà a guardare la mappa di distribuzione che è come la mappa del secchio. Ogni bucket ha un intervallo di valori chiave in termini di un intervallo di valori di chiavi hash in termini di quali chiavi possono entrare in questo bucket. Quindi, utilizzerà quella mappa dei bucket per sapere a quale server dovrebbe andare e parlare perché è connesso a tutti loro, giusto?
E andrà e diciamo che stavi aggiungendo l'elemento numero tre qui. Andrà e aggiungerà l'elemento numero tre qui e se hai abilitato la replica asincrona l'applicazione tornerà indietro e l'applicazione sarà completata. La cache ora lo farà, questa partizione sa che deve replicarlo qui. Quindi, in modo asincrono, in un'operazione in blocco, lo replicherà nell'altra casella e avrai immediatamente quell'elemento in due posizioni. Quindi, questo è ciò che ha fatto Cache.Add sotto le coperte.
Va bene, vado avanti e indietro perché volevo solo in qualche modo darti una panoramica, ma sembra una cache, come crearla, come appare un'API.
Funzionalità di memorizzazione nella cache dei dati dell'app
Ora, entriamo in quali sono i problemi che devi risolvere nell'uso della cache per la memorizzazione nella cache dei dati dell'applicazione.
Mantieni la cache fresca
Ne abbiamo parlato mantenendo la cache fresca, giusto? Quindi, come mantieni la cache fresca? Come ti assicuri che una cache sia fresca?
Il più comune e quello che tutti supportano incluso Redis è la scadenza. La scadenza assoluta. Quindi, quando aggiungi qualcosa alla cache, diciamo, anche qui specifichi una scadenza qui, che è diciamo che stai dicendo che scade dopo un minuto. Quando dici questo in caso di NCache, NCache creerà indici sul server e controlleremo quei dati e scadranno dopo un minuto. Quindi, in realtà è quello, in realtà specificherà un valore di data e ora assoluto che era tra un minuto. NCache sa che in quel giorno il valore deve scadere quell'articolo. Quindi, è così che la cache si occupa automaticamente di assicurarsi che i dati vengano rimossi. E cosa significa davvero? Ciò significa che stai dicendo alla cache che non mi sento davvero a mio agio nel conservare questi dati per più di un minuto o più di cinque minuti perché penso che qualcuno li cambierà nel database. Quindi, è sicuro solo tenerlo nella cache per così tanto tempo. C'è un'altra scadenza chiamata scadenza scorrevole che suona come la stessa ma il suo scopo è completamente diverso. La scadenza scorrevole viene utilizzata principalmente per la pulizia. Quindi, se hai sessioni, usi la scadenza scorrevole per ripulire dopo che nessuno sta usando questa sessione. Quindi, quando qualcuno si disconnette dopo 20 minuti di inattività, la sessione sarà considerata scaduta. Quindi, verrà automaticamente rimosso.
Utilizzo delle dipendenze del databaseMa ciò non ha nulla a che fare con il mantenimento della cache fresca. La scadenza assoluta è quella che mantiene fresca la cache. Ma c'è un grosso problema con la scadenza assoluta. E il problema è che stai ipotizzando che sia sicuro conservare i dati per quello nella cache per così tanto tempo e quell'ipotesi non è sempre accurata. Allora, cosa fai in quel caso? Quindi, in tal caso, devi avere la possibilità che la cache si sincronizzi da sola. Se rileva un cambiamento nel database, significa che la cache deve sapere qual è il tuo database. Ciò significa che la cache deve avere una relazione tra l'elemento memorizzato nella cache e qualcosa in alcuni dati nel database che devi dire alla cache ed è lì che c'è questa cosa chiamata dipendenza dalla cache SQL in ADO.NET che NCache usa, che è una dipendenza da SQL e questa è anche chiamata dipendenza da Oracle, che in realtà funziona in un modo molto semplice. Ma è una caratteristica davvero potente. E veniamo qui. Userò solo la dipendenza SQL. Quindi, quando aggiungi qualcosa alla cache, fai lo stesso Cache.Add, giusto? Hai una chiave cache. Ora, invece del valore, specifichi l'elemento cache che è NCache's propria struttura di dati e lì contiene il valore ma contiene anche questa cosa chiamata dipendenza dalla cache SQL.
Questa dipendenza dalla cache SQL è NCache's propria classe ma esegue il mapping alla dipendenza della cache SQL di ADO.NET. Si noti che ha una stringa di connessione qui e quindi ha un'istruzione SQL. Pertanto, l'istruzione SQL in questo caso viene mappata su una riga nella tabella del prodotto. Allora, cosa sta succedendo davvero qui? Voglio dire, stai effettivamente eseguendo questo codice proprio qui. Il tuo database è qui, quindi stai chiedendo al cluster di cache di connettersi ora al database in base a quella stringa di connessione che l'hai appena passata, in base a quella stringa di connessione e stai passando nel server SQL e stai dicendo per favore connettersi con il mio database del server SQL. E monitora il server SQL per avvisarti, essendo tu il server della cache, se ci sono modifiche che si verificano a questo set di dati. Ciò significa che questa riga viene aggiornata o eliminata. Se ciò accade, il server SQL invia una notifica del database al client che in questo caso è il server cache. Uno di questi. E poi cosa fa il server cache? Il server della cache rimuove quell'elemento dalla cache. Rimuovere significa che, poiché non è più nella cache, l'applicazione è costretta ad andare a prenderla dal database che ora ha la copia più recente. Quindi, mentre la scadenza è un'ipotesi plausibile, questa non è un'ipotesi. Questa è una sincronizzazione reale e prevedibile, in cui si assicura che la cache sia sempre coerente con il database.
Ora, in caso di NCache, ci sono tre modi diversi per farlo. Uno è la dipendenza SQL che utilizza gli eventi del database, che è come il tempo reale. L'altro è NCaches propria dipendenza dal DB che usa il polling e questo è per quei database che non hanno un meccanismo di notifica degli eventi o anche per il server SQL, se pensi di avere troppe dipendenze SQL e per ogni dipendenza SQL viene creata una dipendenza della cache SQL SQL server che è una struttura di dati aggiuntiva. Pensa se ne avessi centinaia di migliaia creati, il tuo server SQL si strozzerebbe. Quindi forse non è una buona idea se hai molte dipendenze SQL per avere quel modo di sincronizzare. Quindi forse la dipendenza da DB è molto meglio in quanto in una chiamata può sincronizzare migliaia di righe perché ha una tabella di polling che monitora.
E c'è un terzo modo che in realtà è semplicemente scrivere una stored procedure CLR e farla chiamare dal trigger. Quindi, se si dispone di un trigger di aggiornamento, inserimento, aggiornamento o eliminazione, chiamare questa procedura CLR. Inoltre, la procedura CLR prende i dati da quella riga, costruisce l'oggetto .NET utilizzato dall'applicazione e lo archivia nella cache. Ora, è qui che un'API asincrona è molto utile perché non si desidera attendere all'interno della transazione del database l'aggiornamento di una cache. Rallenta semplicemente le transazioni del database che tendono a scadere molto rapidamente. Quindi, è davvero consigliabile che, se si intende implementare questo meccanismo, utilizzare i metodi asincroni per aggiornare i dati.
Quindi, questi sono i tre modi in cui puoi sincronizzare la cache. Questa funzione è davvero importante perché ti consente di assicurarti che la cache sia sempre aggiornata senza la quale stai solo facendo un'ipotesi. E allo stesso modo puoi sincronizzare la cache con database non relazionali. C'è una funzione di dipendenza personalizzata che NCache ha qual è il tuo codice che NCache chiamate che puoi andare e monitorare il tuo archivio dati personalizzato. La tua origine dati personalizzata potrebbe essere un archivio cloud. Potrebbe essere qualsiasi cosa, è solo un qualsiasi codice che puoi controllare. Quindi, mantenere la cache fresca è davvero importante e questi sono i modi in cui puoi assicurarlo.
Read-through e Write-through
Quindi, la funzionalità successiva è read-through e write-through.
La lettura è fondamentalmente, è di nuovo il tuo codice. Ora, tutte queste caratteristiche di cui sto parlando NCache li ha ma non lo sono NCache solo. Le cache Java li hanno tutte. Redis può o non può averli. Quindi, questo è quello che devi fare se vuoi fare un dettagliato, se vuoi sapere se cosa Redis ha o meno, in caso di NCache vieni qui e vai ai confronti e c'è un Redis NCache confronto delle caratteristiche. Questo si basa sulla loro documentazione e la documentazione memorizzata nella cache. Quindi, puoi effettivamente scaricarlo e passare attraverso tutte queste funzionalità. Quindi, il read-through è fondamentalmente il tuo codice che si trova sul server cache. Quindi, sembra così. Quindi, è che si implementa. Quindi, lascia che ti mostri quell'interfaccia in modo che l'interfaccia di lettura assomigli... Quindi, ecco un'interfaccia di lettura qui, giusto? Cursore della mano dentro NCache e c'è un InIt che si collega alla tua origine dati, elimina e c'è un metodo di caricamento. Quindi, il caricamento ti dà una chiave e restituisci un oggetto in base ai dati che hai. E poi puoi specificare quando dovrebbe scadere e cose del genere. La stessa cosa vale con write-through è che hai InIt e smaltisci e poi c'è una scrittura alla fonte. Quindi, la scrittura potrebbe essere aggiunta, aggiornata o eliminata. Dove usi il read-through write-through e perché sono così importanti?
La lettura, prima di tutto, così come funziona, ti consente di avere un Cache.Get e la cache non ha i dati. Cache chiamerà il tuo read-through per andare a prenderlo dal database. Questo è un vantaggio. Il secondo vantaggio è che puoi combinare la lettura con la scadenza e la sincronizzazione del database. Quindi, invece di rimuoverlo dalla cache, lo ricarichi. Il write-through funziona allo stesso modo tranne che c'è un write-behind che significa che aggiorni la cache solo in quanto la cache aggiorna il tuo database. Quindi, anche i tuoi aggiornamenti diventano superveloci. Quindi, ovunque le prestazioni del database diventino un collo di bottiglia, hai una cache per salvarti. Una volta implementato il read-through, write-through, puoi consolidare tutto il codice di persistenza o la maggior parte di esso nel livello di memorizzazione nella cache e puoi beneficiare di entrambe queste funzionalità di cui abbiamo appena parlato.
Raggruppamento e ricerca dei dati
Quindi, una volta che mantieni la cache fresca e stai anche facendo il read-through write-through, ora inizi a memorizzare nella cache molti dati. Quindi, la cache non è più solo un archivio di valori chiave. Voglio dire, non è conveniente recuperare tutto come chiave.
Devi essere in grado di cercare. Devi essere in grado di eseguire la ricerca SQL. Quindi, devi essere in grado di fare ciò che sei abituato a fare con il database.
Se una cache non ti consente di eseguire ricerche SQL, diventa molto limitante e allo stesso modo perché non puoi eseguire join in una cache perché è una cache distribuita ci sono altre funzionalità di raggruppamento e sottoraggruppamento e tag che ti consentono di raggruppare dati e recupera tutto in una chiamata.
Quindi, ancora una volta, semplificare la ricerca dei dati nella cache è davvero importante se intendi memorizzare nella cache molti dati. Quindi, queste caratteristiche sono molto importanti.
Funzionalità della cache distribuita
Esaminerò rapidamente alcune, una funzionalità che volevo davvero toccare si chiama vicino alla cache o alla cache del client.
Non appena le persone che sono abituate a fare cache InProc standalone, quando passano a una cache distribuita improvvisamente le loro prestazioni diminuiscono perché stanno attraversando la rete. Devono passare attraverso la serializzazione e improvvisamente le prestazioni non sono più veloci. Molti dei nostri clienti si lamentano, beh, mi aspettavo che le mie prestazioni aumentassero, in realtà sono diminuite. E il motivo è perché non puoi competere con la cache InProc standalone che ha l'oggetto archiviato nel tuo heap. Quindi, se si dispone di una funzionalità di cache del client che essenzialmente è esattamente una cache locale che mantiene quell'oggetto locale ma è connesso alla cache in cluster.
Ancora una volta, questa è una caratteristica che NCache ha e la maggior parte delle cache Java ha che ti darà davvero le stesse prestazioni veloci senza perdere la cosa.
Nel NCache, puoi andare sul nostro sito Web e scaricarlo è una cache open source. Quindi, puoi scaricare la cache open source o l'Enterprise Edition e, come ho detto, puoi ottenere tutti i confronti tra NCache ed Redis su quello.