NCache Architettura

Spettacolo registrato
Di Ron Hussain e Zack Khan

Il webinar di oggi si baserà su NCache Architettura. Ora tratteremo una panoramica della memorizzazione nella cache distribuita e di come risolve i colli di bottiglia in .NET e .NET Core. Esamineremo i casi d'uso comuni, nonché l'architettura della cache distribuita e i dettagli del clustering, nonché tutte le domande che potresti avere in merito non solo a NCache, ma la memorizzazione nella cache in generale. Ora, in qualsiasi momento durante questo webinar, abbiamo la possibilità di porre domande qui nella scheda delle domande di GoToWebinar, quindi dai un'occhiata a tuo piacimento per la scheda delle domande. E, una volta che avrai scritto una domanda, potrò sollevarla durante la presentazione per ricevere risposta da Ron o da me. Abbiamo anche un po' di tempo alla fine di questa sessione per poter rispondere a tutte le altre domande che arriveranno, ma non vediamo l'ora di divertirci.

Quindi, senza ulteriori indugi, lo consegnerò a Ron e cominciamo. Molto bene, grazie, Zack. Quindi, come ha appena detto Zack, l'argomento di oggi è NCache architettura. In questo webinar, tratterò dettagliatamente come NCache funziona il clustering, quali sono le topologie più comuni tra cui è possibile scegliere e uno dei principali vantaggi di NCache in termini di casi d'uso dell'applicazione. Quali sono questi casi d'uso e come puoi trarne il massimo vantaggio NCache all'interno delle applicazioni server?

Quindi spero che tutti possano vedere il mio schermo. Se riesco a ottenere una rapida conferma in merito, inizierò rapidamente a lavorare su questo. Sì, penso che stiamo tutti bene se puoi. Ecco qua, penso. Sì, sembra bello. Perfetto. Ok, quindi iniziamo rapidamente con questo.

Il problema della scalabilità

Va bene, allora definiamo prima di tutto cosa NCache È? E per questo dovrò andare avanti e definire cos'è un problema di scalabilità e poi come NCache è in grado di risolvere il problema di scalabilità. Quindi, in una tipica architettura server in cui sono distribuite applicazioni, di solito è più di un'istanza o più di un server, sai, indipendentemente dal fatto che tali applicazioni siano distribuite. Quindi, è sicuro affermare che il livello dell'applicazione è qualcosa di molto scalabile.

È possibile aggiungere tanti server in un livello applicazione. È possibile costruire un modulo Web, un modulo dell'app, dove più server applicazioni o server Web ospitano la stessa applicazione, ma lavorano in team e dividono tra loro il carico della richiesta. Inoltre, se si passa a un'architettura più recente, anche con un'architettura di microservizi, si ha la possibilità di scalare individualmente i servizi applicativi, microservizi che richiedono più calcoli o maggiore capacità di gestione delle richieste.

Pertanto, il livello dell'app è molto scalabile. È linearmente scalabile. Man mano che cresci, sei in grado di gestire un carico di richieste sempre maggiore. Il problema entra in gioco quando hai a che fare con il database, come un database relazionale. Poiché tutte queste applicazioni, indipendentemente dal livello di scalabilità e dalla scalabilità, dovrebbero sempre comunicare con un database back-end. E, quando parlano con un database back-end, di solito si tratta di un'unica fonte. E non è molto scalabile. È molto buono per l'archiviazione; puoi avere molte risorse su disco. Quindi, puoi trarne vantaggi in termini di spazio di archiviazione. Ma quando si ha un carico transazionale enorme sulle applicazioni e questo si traduce in un carico transazionale del database, i database tendono a soffocarsi. E questo è il problema principale, dove l'applicazione ha difficoltà con la gestione delle richieste. Non è scalabile e anche l'esperienza dell'utente finale è compromessa.

NoSQL databaserisolvono in qualche modo questo problema. Puoi avere un database SQL, ma ciò richiede che la tua applicazione venga riarchitettura in modo tale da smettere di utilizzare un database relazionale e iniziare a utilizzare un NoSQL database e questo è un grande progetto. COSÌ, NoSQL non è sempre una soluzione a un problema di scalabilità.

La soluzione: NCache Cache distribuita

Quindi, cosa dovremmo fare ora che abbiamo questo? La soluzione è molto semplice: dovresti avere una cache distribuita in memoria come in NCache. Prima di tutto, è in memoria, quindi il vantaggio principale che ottieni è che le prestazioni della tua applicazione verranno aumentate. È super veloce rispetto a un database relazionale. E il vantaggio principale è che è linearmente scalabile. A differenza di un server di database, che di solito è un'unica fonte. NCache può risiedere su più server. Ti permette di creare un file cluster di cache che può essere eseguito su più box. Inoltre, come sai, i tuoi requisiti o esigenze crescono, laddove devi avere una maggiore capacità di gestione delle richieste che deve essere gestita dal livello dell'applicazione, puoi aggiungere più server in fase di esecuzione nel cluster di cache.

La cosa bella NCache è che lo usi in aggiunta a un database relazionale; o un database back-end, non sostituisce le origini dati convenzionali. È qualcosa che integrerà le origini dati esistenti in modo tale da poter aumentare le prestazioni delle tue applicazioni. È in grado di aumentare la capacità di gestione delle richieste per le tue applicazioni. Inoltre, man mano che si cresce a livello dell'applicazione, è sempre possibile aumentare il numero di server nel cluster di cache, poiché si tratta di server in un cluster e quindi lavorano come un team. Sono in grado di dividere tra loro il carico delle richieste in modo tale da fornire come risultato una scalabilità lineare. COSÌ, NCache è un modello scalabile linearmente ed è molto facile da usare. Parliamo di come funziona l'architettura di distribuzione. Quindi, in un ambiente di produzione tipicamente di grandi dimensioni, ecco come NCache sembrerebbe:

Avresti un sacco di server. Potrebbero essere servizi Windows o Linux, progettati in modo tale che NCache si trova tra l'applicazione e il database. Ad esempio, puoi iniziare con due o tre NCache server, e poi puoi crescere fino a quattro o cinque NCache server e diversi tipi di applicazioni, ad esempio ASP.NET o ASP.NET Core app Web, il tuo .NET o .NET Core servizi o .NET/.NET Core applicazioni del server. O anche potrebbe essere Java o Node.js. Pertanto, anche tali applicazioni possono trarre vantaggio dalla memorizzazione nella cache distribuita.

NCache stesso è scritto in .NET/.NET Core. Funziona sia su Windows che su Linux. Allo stesso modo, le tue applicazioni potrebbero trovarsi su qualsiasi piattaforma e funzionerebbero senza problemi. In genere, ti consigliamo di averlo NCache su server di installazione dedicati, che ospitano solo NCache, in modo da avere una natura dedicata delle risorse per NCache. Inoltre, i server delle applicazioni si trovano su un livello separato. In modo da avere una natura dedicata delle risorse anche per le tue applicazioni. Ma c'è anche un'altra opzione di distribuzione, dove puoi avere configurazioni più piccole NCache seduti sulle stesse scatole, dove sono in esecuzione anche le tue applicazioni. Quindi, questa è sempre una possibilità con NCache. Ma, come discusso, l'opzione consigliata è quella di avere un livello di cache separato, come mostrato nel diagramma. Poi NCache si trova tra l'applicazione e il database. L'idea qui è che metti nella cache tutti i dati che usi più frequentemente all'interno delle tue applicazioni. Potrebbe essere un dato di riferimento o un dato transazionale. Per "riferimento" intendo dati che richiedono una maggiore intensità di lettura e per "transazionali" intendo dati che vengono letti e scritti ad alta intensità. E, una volta che sai quali dati memorizzare nella cache, puoi chiamare tali dati come il tuo "set di lavoro". Per la prima volta, puoi recuperare i dati dal database e quindi puoi anche aggiungerli all'interno NCache e le chiamate successive possono essere gestite tramite NCache solo, risparmi viaggi costosi nel database. Questo è ciò che in genere chiamiamo modello "cache-aside", in cui tutte le modifiche apportate vengono propagate anche alla cache e quindi al database. Inoltre, qualsiasi database non esiste nella cache, lo recuperi sempre dal database e lo conservi all'interno NCache ma prima controlli sempre la cache. Quindi, se trovi dati nella cache, non devi andare al database e ritorni da quel punto.

Lettura/scrittura

L'approccio alternativo è quello di utilizzare "read-through" o "write-through" che è qui rappresentato da linee tratteggiate. NCache ha una funzionalità che può automatizzarlo, fornendo l'opzione "cache-through" ed è definita "read-through" per le letture e "write-through" per le scritture. Funzionerà in modo tale da utilizzare sempre la cache come fonte principale e implementare un gestore di lettura e scrittura sulla cache e questo si occuperà dell'aggiornamento delle origini dati di back-end. Pertanto, qualunque operazione di lettura esegui, se i dati non esistono, andranno senza problemi al tuo database in base al tuo provider, li recupereranno per la tua applicazione, torneranno anche all'app e li memorizzeranno anche all'interno NCache. Per gli aggiornamenti, aggiornerà la cache e il database con un approccio sincronizzato o asincrono, a seconda del modello chiamato dall'applicazione.

Quindi, condividerò maggiori dettagli sui modelli di lettura, scrittura e memorizzazione nella cache, ma solo per darti un quadro di distribuzione di alto livello, ecco come vedresti NCache distribuito in un modulo server, a cui possono connettersi più applicazioni o moduli di domanda NCache e poi possono trarre vantaggio da un caching distribuito, dove l'accesso alla memoria migliora le prestazioni delle applicazioni. Inoltre, avere più server nel livello cache è in grado di offrirti una scalabilità lineare. Spero che sia stato chiaro; per favore fatemi sapere se ci sono domande. Bene, per fortuna, in questo momento sembra che non ce ne siano, quindi sentiti libero di continuare. Molto bene.

NCache Numeri di scalabilità

Quindi, dopo, parlerò di NCachei numeri di scalabilità. Ne abbiamo appena parlato NCache è in grado di risolvere il problema di scalabilità della tua applicazione. COSÌ, NCache stesso è linearmente scalabile. Quindi, poiché il livello applicazione è scalabile, sai, avendo un collo di bottiglia del database risolto attraverso un modello scalabile linearmente, ecco alcuni numeri che puoi prendere come riferimento. Questi sono stati i nostri test di riferimento che abbiamo condotto nel nostro ambiente di controllo qualità, abbiamo utilizzato server con CPU e RAM elevate in modo da poterli davvero sfruttare e utilizzarli in una situazione di carico elevato. Abbiamo iniziato con un server e abbiamo continuato ad aumentare il carico delle applicazioni con due server. Non appena la capacità di CPU e RAM di un set di server ha raggiunto il limite massimo, è stato il punto in cui abbiamo aggiunto un altro server.

Questa è la regola pratica; dove puoi continuare a utilizzare i server cache esistenti, inizia con due NCache server e quando vedi che la capacità hardware di questi due server è al massimo, se la tua CPU o la tua RAM sono al massimo, quello è il punto in cui fai una scelta che ora devo ampliare e io è necessario aggiungere un terzo server nel cluster di cache. Questo è esattamente ciò che abbiamo fatto con una dimensione media degli oggetti di 1 kilobyte, abbiamo continuato ad aumentare il carico delle applicazioni e ad aumentare il numero di server. Fino a quando il set di server specificato non è stato esaurito. E non si trattava di dati provvisori; si trattava di dati applicativi reali ma simulati nel nostro laboratorio di controllo qualità. Quindi, con due server, con tre, quattro, cinque, fino a cinque server siamo stati in grado di gestire 2 milioni di richieste al secondo con una dimensione media degli oggetti di 1 kilobyte.

Quindi, si trattava di una combinazione di letture e scritture applicate in modo coerente alla cache. Nel complesso, è stato quindi raggiunto un throughput di 2 milioni di richieste al secondo. E, allo stesso tempo, senza compromettere le prestazioni. Quindi, il throughput non significa solo avere molte richieste al secondo; ma anche la latenza delle richieste individuali dovrebbe essere mantenuta e dovrebbe essere super veloce. Sul nostro sito web sono pubblicati un video dimostrativo e un libro bianco (Vedere qui). E anche questo è qualcosa che puoi rivedere.

Usi comuni della cache distribuita

Ok, parliamo di alcuni dei casi d'uso comuni di NCache.

• Memorizzazione nella cache dei dati dell'app

  Il caso d'uso numero uno è la memorizzazione nella cache dei dati dell'applicazione, come lo chiamiamo Memorizzazione nella cache dei dati dell'app. Ora questi sono i dati che provengono da un database back-end. Abbiamo già stabilito che il database è lento in generale perché è basato su disco, in confronto la RAM è una fonte più veloce. L'altro problema è che il database tende a soffocarsi in caso di traffico elevato. Se hai molto carico transazionale e c'è un singolo server, è probabile che non ti fornisca le prestazioni necessarie di cui hai bisogno sul lato dell'applicazione. Pertanto, è molto logico memorizzare nella cache i dati dell'applicazione all'interno delle applicazioni utilizzando NCache. È molto semplice; usate NCache API e chiami semplicemente cache. Ti connetti alla cache chiamando le API di inizializzazione della cache. Una volta connesso alla cache, puoi chiamare 'cache.Aggiungi, cache.Aggiorna, cache.Rimuovi' o 'cache.Get' per recuperare i dati dalla cache. Quindi, ti mostrerò alcuni esempi verso la fine. Ma l'idea qui è che qualunque sia il dato che pensi di leggere più di una volta, siano essi dati di riferimento o dati transazionali. Per i dati di riferimento, NCache aggiungerà molto valore perché non è necessario tornare al database per recuperare eventuali modifiche.

  

  Esatto, i dati nella cache saranno utilizzabili per un periodo di tempo più lungo. E, mentre utilizzi i dati da NCache, non è necessario accedere al database back-end. Ciò migliora le prestazioni della tua applicazione. E ti dà scalabilità perché NCache è scalabile in confronto.

  Pertanto, è molto intuitivo memorizzare nella cache tutti i tuoi dati di riferimento, ma ti consigliamo anche di memorizzare nella cache anche alcuni o addirittura la maggior parte dei tuoi dati transazionali. Secondo la nostra esperienza, tutti i dati che leggi più di una volta, anche se si tratta di qualcosa che leggerai due o tre volte, ti consigliamo di memorizzarli nella cache. Perché anche se viene modificato nel database, e dopo tale modifica, se leggi più di una volta, due o tre volte, ha molto senso memorizzare nella cache quei dati, in modo da non doverlo fare vai al database di back-end. E abbiamo funzionalità integrate NCache che può darti anche una sincronizzazione al 100% con il database. Questo è qualcosa che puoi anche, sai, considerare sempre.

  Ron, mi è arrivata una domanda veloce, principalmente:
  Devo sempre accedere alla cache in cluster sulla rete? Ho paura che problemi di rete possano far sì che le mie applicazioni non funzionino. Esiste un modo per conservare alcuni dei miei dati localmente?

  Ok, quindi in genere, la distribuzione predefinita è quella che ti consigliamo di avere NCache su scatole separate, e poi la tua domanda su scatole separate, giusto? Quindi, quando NCache è basato sul protocollo TCP, quindi è una chiamata di rete. Esiste una funzionalità chiamata "Client-Cache", che è una cache locale che si trova nelle caselle delle applicazioni. E, in alcuni casi, se hai davvero bisogno di più artisti e non vuoi avere alcun tipo di latenza causata dalla rete, può anche essere reso "in-proc", il che significa che si troverà all'interno del processo di candidatura. Pertanto, quando ciò accade, il sottoinsieme dei dati viene automaticamente portato nella cache del client. Pertanto, ciò salverà qualsiasi comunicazione da processo a processo. E quindi risparmierà anche qualsiasi comunicazione di rete o eventuali spese generali di rete. Quindi, abbiamo una funzionalità; è qualcosa che tratterò una volta che avremo esaminato le nostre topologie. Quindi condividerò qualche dettaglio in più, ma solo per darti una rapida panoramica, ecco come funziona la cache del client. È una cache che si trova nella stessa scatola in cui si trovano le tue applicazioni. E l'idea qui è che non richiede frequenti viaggi in rete se la cache del client è abilitata. E funziona senza alcuna modifica del codice. Quindi, spero che questo risponda alla domanda. Per favore fatemi sapere se ci sono altre domande. Sì, suona bene. Ron, portalo via. Molto bene.

• ASP.NET e ASP.NET Core Caching

  Il prossimo caso d'uso di NCache si trova in un'applicazione web. Se ci sono alcuni requisiti per la memorizzazione nella cache dei dati utente, giusto? E in genere è ASP.NET o ASP.NET Core stato della sessione. Ora questi dati non appartengono al database, perché sono dati transitori. È un dato che un utente costruirà e rimane nell'ambito dell'applicazione mentre l'utente è attivo. In alcuni casi, potresti conservarli nel database per un punto di vista storico, ma nella maggior parte dei casi i dati appartengono a un utente.

  Quindi, Microsoft ASP.NET o ASP.NET Core sessione. Ci sono alcune opzioni che puoi usare il server di stato che puoi usare in-proc puoi usare un server di database, tutte queste hanno opzioni hanno problemi. Ad esempio, in-proc è un singolo punto di errore; devi usare il bilanciamento del carico della sessione fissa. ASP.NET State Server è ancora una volta un singolo punto di errore e, sai, non è scalabile. Il database è un'opzione, ancora una volta non è un singolo punto di errore perché è possibile eseguirne il backup, ma in alcuni casi potrebbe essere un singolo punto di errore, ma è lento e non scalabile. Allora, cosa dovremmo fare qui? Ancora una volta, considera l'utilizzo NCache per ASP.NET e ASP.NET Core memorizzazione nella cache dello stato della sessione. Funziona in modo tale che ti colleghi al nostro provider. È un'opzione che non prevede la modifica del codice, ma non appena ti colleghi NCache all'interno delle tue applicazioni, NCache diventa la memoria della tua sessione principale. E l'idea qui è che sarà super veloce perché è basato sulla RAM. È molto scalabile perché ci sono più server. E, dentro NCache, una volta che avanzeremo nella presentazione e tratteremo le topologie, lo capirai NCache dispone di backup, con l'aiuto di repliche. E i dati della sessione sono dati utente, giusto? Quindi sono dati che non vorresti perdere in nessuna situazione perché una volta persi quei dati, questo ha un impatto sull'utente, un impatto sul business. Pertanto, con la replica, viene eseguito anche il backup dei dati.

  

  Quindi, se devo elencare i vantaggi che ottieni, e sai, prima di tutto, migliorerai le prestazioni della tua applicazione grazie all'accesso in memoria. Hai più server che supportano le tue applicazioni per la memorizzazione nella cache delle sessioni, quindi è molto scalabile. Inoltre, dispone di funzionalità di alta disponibilità e affidabilità dei dati integrate. Pertanto, non si verificano perdite di dati della sessione o tempi di inattività dell'applicazione NCache il server si interrompe. E non devi più utilizzare il bilanciamento del carico della sessione fissa perché NCache è un'entità condivisa. La richiesta può essere indirizzata a qualsiasi server web; sarà sempre in grado di trovare dati da NCache in base al nostro protocollo. Quindi, tutto questo senza alcuna modifica del codice.

  Un altro caso d'uso qui è anche quello di raggruppare lo stato di visualizzazione se si utilizzano moduli Web ASP.NET. È lì che memorizzerà anche lo stato di visualizzazione nella cache. Lo stato di visualizzazione diventa pesante; consuma molta larghezza di banda. Diventa parte dei pacchetti di richiesta e risposta e viene sempre rinviato al browser. E non è mai stato realmente utilizzato lì, ma è qualcosa che viene memorizzato nel browser, sul lato client. E quando pubblichi di nuovo, è lì che lo stato di visualizzazione viene riportato sul lato server. Quindi, con NCache, ti consentiamo di memorizzare nella cache lo stato di visualizzazione sul lato server, in modo che al tuo carico utile non sia più associato uno stato di visualizzazione pesante. Ciò migliora le prestazioni. Anche se, sai, lo stato di visualizzazione è qualcosa che viene sempre memorizzato sul lato del browser. Ma se lo mantieni sul lato server, dove è necessario, migliorerai il comportamento generale dell'applicazione. Non consumerà più la larghezza di banda perché al pacchetto di richiesta e risposta effettivo non è più associato uno stato di visualizzazione pesante. Inoltre, saremo molto sicuri perché lo stato di visualizzazione è archiviato sul lato server e quindi puoi impostare la crittografia e alcune funzionalità di sicurezza sopra di esso. E questa è anche un'opzione senza modifica del codice. Ma si applica solo ai moduli Web legacy. Pertanto, ti consiglio di considerare, se disponi di un'applicazione per moduli Web ASP.NET, anche uno stato di visualizzazione della memorizzazione nella cache.

  E poi abbiamo ASP.NET e ASP.NET core memorizzazione nella cache delle risposte. Pertanto, per le pagine statiche o le porzioni di pagina all'interno di una pagina che sono statiche, dovresti prendere in considerazione la memorizzazione nella cache di tali output della pagina. E nell'ASP.NET core, è possibile scegliere un'opzione di memorizzazione nella cache delle risposte, anch'essa un'opzione che non prevede la modifica del codice. Oltre a questo, abbiamo anche ASP.NET e ASP.NET Core SignalR Backplane. Perché in un modulo Web, se usi SignalR, è necessario un backplane. E i tipici backplane, come un file system o un database, che possono presentare tutte quelle sfide di scalabilità e prestazioni di cui abbiamo appena discusso. Con NCache, sarà superveloce, molto scalabile e affidabile, perché dietro le quinte utilizziamo un sistema di messaggistica molto affidabile. Pertanto, questi sono alcuni dei casi d'uso che puoi sfruttare su ASP.NET o ASP.NET Core applicazioni.

Prima di passare a Zack; Penso che ci sia una domanda pubblicata. Sì. Quindi, la domanda è nata sostanzialmente dal dire e DB per impostazione predefinita. Quindi, nel bel mezzo del tuo... volevo aspettare finché non l'avessi finito, ma in pratica la domanda è questa. E nel caso, potrebbe approfondire la questione, signore?

Ciao Ron, lo è NCache adatto anche per scopi di pubblicazione dei dati, con il requisito, dove il requisito è quello di salvare i dati nella cache in memoria con opzioni per sincronizzare i dati nel database come processo in background? E può NCache prendersi cura di quel meccanismo di sincronizzazione tra cache di memoria e database per impostazione predefinita?

Sì, è un'ottima domanda. Per i casi avanzati, questo è qualcosa che potrebbe sempre essere un requisito. Funziona in due modi. Uno è che la tua applicazione ora utilizza i dati provenienti da NCache, ma i dati esistono nel database. Quindi, queste sono due fonti diverse che devono essere sincronizzate sia per la lettura che per la scrittura. Ora, se l'applicazione a cui è connesso NCache e il database è l'unica applicazione responsabile della modifica dei dati all'interno NCache e database, ora ti consigliamo di utilizzare read-through e write-through. E sì, questo può essere fatto in modo asincrono o sincronizzato, a seconda delle tue esigenze. Quindi, ciò che accadrà realmente è, ogni volta che provi a recuperare alcuni dati da NCache e non esiste nella cache e vuoi che venga memorizzato nella cache, chiameresti automaticamente read-through e questo leggerà dal database back-end in base al tuo codice. Allo stesso modo, se i dati provengono da un database e, ancora una volta, tali dati devono essere aggiornati nel database, non appena si aggiornano i dati nella cache, in tal caso si utilizzerà il write-through. Ora il write through può anche essere write-behind, il che significa che i dati devono essere aggiornati all'interno NCache e nel database utilizzando il gestore write-through. E se vuoi un'invocazione asincrona di questo, in quel caso puoi usare write-behind, quindi può essere fatto in background. Ma ancora una volta, NCache e la tua applicazione è responsabile di quello, dove NCache sta chiamando il tuo codice e la tua applicazione lo sta invocando.

Un'altra situazione potrebbe essere che ci siano altre applicazioni che potrebbero modificare direttamente i dati nel database e la tua applicazione non ne è a conoscenza. Quindi, in tal caso, ciò che realmente accadrà è che dovrai utilizzare le nostre funzionalità di sincronizzazione del database. Dovresti creare una dipendenza personalizzata; sai, SQL Server ha una notifica a catena. Abbiamo dipendenze dal database. Pertanto, ci sono molte funzionalità di sincronizzazione in cui viene catturata qualsiasi modifica nel database NCache automaticamente. Inoltre, puoi nuovamente utilizzare la lettura attraverso e ricaricare i dati all'interno NCache anche. Quindi, per riassumere, NCache puoi, sai, gestire entrambe le situazioni: dove è la tua applicazione l'unica entità che cambia qualcosa al suo interno NCache e database o in una situazione in cui il database può essere modificato al di fuori dell'ambito dell'applicazione che utilizza la memorizzazione nella cache.

Quindi, entrambi gli scenari sono coperti e NCache ti darà un'opzione di sincronizzazione 100 che conosci per questi casi. Se parli di cache di memoria, in genere la cache di memoria è presente anche in ASP.NET, giusto! Ma se ti riferisci NCache come cache di memoria, quindi ho già risposto alla domanda. Quindi, per favore, fammi sapere se ci sono altre domande e possiamo iniziare da lì.

• Messaggistica Pub/Sub

  Suona bene. Penso che possiamo andare avanti. Sicuro. Va bene, quindi ora parlerò della messaggistica Pub-Sub. Come potete vedere, NCache è già condiviso tra le applicazioni, giusto. Quindi è un'entità che puoi utilizzare per i tuoi requisiti di dati. Puoi aggiungervi dati; puoi recuperare i dati da esso. Puoi ottenere vantaggi in termini di prestazioni e scalabilità NCache. È possibile estendere questo caso d'uso utilizzando NCache anche come piattaforma di messaggistica. COSÌ, NCache la messaggistica è molto potente all'interno NCache. Si tratta di un meccanismo asincrono basato sugli eventi in cui più applicazioni possono gestire tra loro i requisiti di messaggistica o i requisiti di coordinamento delle app. Se hai bisogno che più applicazioni comunichino tra loro, costruire la comunicazione è una sfida. Quindi dovresti fare affidamento su qualcosa che sia un'entità centralizzata, NCache è quell'entità. E con il suo supporto di messaggistica, è in grado di darti quell'opzione in cui un'applicazione può aggiungere dati o messaggi NCachee quei messaggi possono essere propagati a tutti gli abbonati dall'altra parte: le altre applicazioni che hanno bisogno, sai, di quei messaggi.

  

  Allo stesso modo, anche questi potrebbero essere messaggi basati sui dati. Ad esempio, se i dati vengono aggiunti, aggiornati o eliminati, riceverai una notifica. Potrebbero trattarsi di messaggi di applicazioni personalizzate o messaggi basati sui dati, quindi coprono entrambe le aree in cui vengono popolati i dati all'interno NCache e vuoi che altre applicazioni ne siano a conoscenza, puoi gestire i requisiti di messaggistica attraverso questo. Oppure potrebbe trattarsi di messaggistica personalizzata o di messaggistica basata sull'applicazione in cui un'applicazione deve comunicare con un'altra applicazione. Si basa ancora una volta sul modello scalabile in memoria. Ha anche opzioni di replica affidabili disponibili. Si basa sulla piattaforma di messaggistica Pub-Sub convenzionale in cui abbiamo un concetto di argomento e abbiamo un concetto di broker di messaggi, a cui sono collegate più applicazioni. Pertanto, è possibile definire le applicazioni dell'editore e dell'abbonato. Le applicazioni dell'editore pubblicano i messaggi che conosci NCache che vengono poi trasmessi a tutti questi abbonati. E poi, gli abbonati possono anche inviare i propri messaggi. NCache funge da piattaforma di comunicazione tra queste diverse applicazioni.

• Ricerca full-text (Lucene distribuita)

  Infine, abbiamo un altro caso d'uso, ovvero la ricerca full-text. Pertanto, se disponi di un'applicazione e devi soddisfare i requisiti di ricerca del testo completo da NCache, puoi prendere in considerazione l'utilizzo delle nostre funzionalità di ricerca full-text basate su Lucine.NET.

  In genere, l'API Lucene è autonoma. Esatto, ragazzi, potete estenderlo su più server. NCache ti dà anche la possibilità di caricare indici all'interno della memoria. COSÌ, NCache utilizzerebbe indici basati su disco, ma consente, in realtà, di estendere la capacità di archiviazione e di gestione delle richieste disponendo di più server. Quindi, anche se è basato su disco, sarà comunque migliore di una singola fonte nel database. Perché, nei casi in cui il carico transazionale è elevato, ogni server sarà responsabile del proprio set di richieste di indici. Quindi sarà molto scalabile; sarà anche molto affidabile. Poiché si tratta di un archivio assistito, quando si tratta degli indici delle scene, la persistenza stessa è una funzionalità con un file NCache. Tutti i dati archiviati all'interno NCache può essere persistente anche sul disco oppure, in base ad alcuni provider di database, può essere persistente anche su alcuni database. Ma Lucene è l'unica caratteristica in cui NCache utilizza il disco rispetto alla RAM, perché la natura del caso d'uso è tale da richiedere che i dati siano persistenti.

  

Spero che sia stato semplice. Quindi, questi erano alcuni dei casi d'uso. Ancora una volta, all'interno di questi casi d'uso, abbiamo molte funzionalità; qualsiasi tipo di applicazione, qualsiasi requisito specifico all'interno di un'applicazione, può essere completamente gestito utilizzando le nostre funzionalità di caching degli oggetti e di sessione.

Solo una domanda veloce, Ron.
C'è un modo per accedere ai miei dati nella cache come faccio nel mio database MySQL? Voglio essere in grado di eseguire query SQL sui dati della mia cache. Posso farlo?

Sicuro. NCache innanzitutto supporta una ricerca SQL e query LINQ. Quindi, se hai la capacità di scrivere un'applicazione a cui puoi semplicemente connetterti NCache, quindi esegui ricerche basate su criteri, quindi questa è l'opzione semplice che puoi utilizzare, dove scrivi una ricerca basata su criteri. Ad esempio, puoi selezionare tutti i prodotti dove prezzo del prodotto è maggiore di 10 e minore di 100. Oppure puoi trovare tutti i prodotti in base a una categoria; puoi trovare clienti in base a una regione. Quindi, puoi elaborare ricerche basate su SQL o ricerche basate su LINQ e NCache ti fornirebbe i dati dalla cache. Quindi questa è un'opzione.

L'altra opzione è che abbiamo un'integrazione LINQ Pad. Pertanto, se desideri solo visualizzare i dati senza dover passare attraverso lo sviluppo di un'applicazione, LINQ Pad è una soluzione semplice in cui puoi eseguire query LINQ e quindi visualizzare i dati eseguendo query LINQ.

E poi, nella nostra prossima versione, la terza opzione è quella di fornire uno strumento di analisi dei dati. Quindi ti forniremo un modo automatizzato, uno strumento di monitoraggio, che ti darà la possibilità di monitorare i tuoi dati presenti nella cache. E ti fornirà quelle opzioni di ricerca basate su criteri da una GUI, quindi è qualcosa che è in cantiere; i requisiti sono stati completati, il lavoro di sviluppo è stato completato. Penso che farà parte della nostra prossima uscita.

Sicuramente non vedo l'ora di vedere tutto ciò. Perfetto. Sì. Molto bene. Penso che per ora sia tutto a posto, Ron. Terrò da parte anche un paio di queste domande per la fine perché ne abbiamo alcune interessanti, ma sì, continuiamo. Sicuro.

Cluster dinamico di autoguarigione

Quindi, ora tratterò il cluster di cache dinamica, tutti i dettagli a riguardo. NCache si basa sul protocollo di clustering della cache basato su TCP IP. È il nostro clustering di cache implementato. Non utilizziamo clustering di terze parti o Windows per questo problema. È un protocollo proprietario al 100%. È scritto in .NET e .NET Core, quindi sai che è molto conveniente in termini di --- anche i socket TCP sono .NET e .NET Core basato. È un'architettura peer-to-peer al 100%, quindi non esiste un singolo punto di errore. È possibile aggiungere o rimuovere server in fase di runtime. Non è necessario arrestare la cache o le applicazioni client ad essa connesse. Quindi, dinamicamente puoi apportare modifiche a un cluster di cache in esecuzione e, NCache non ti darà alcun problema per questo. Quando aggiungi un server, i client ricevono una notifica in fase di esecuzione, quindi sanno automaticamente che questo server non è più, sai, fa parte del cluster di cache ora, quindi iniziano a utilizzare il server aggiuntivo, il cluster si adatta automaticamente. Allo stesso modo, una volta rimosso un server, gli altri server rilevano che questo server è andato per sempre. Avvisano i client e i client smettono di utilizzare il server perso. C'è un supporto per il failover della connessione, anch'esso costruito sul lato client, quindi qualsiasi server inattivo garantirà che, sai, il cluster assicurerà che i client ne siano consapevoli e, effettueranno il failover della connessione e, inizieranno a utilizzare la parte sopravvissuta server.

Quindi, in ogni caso, eventuali modifiche nel cluster vengono propagate ai client. I client sono intelligenti, sono sempre consapevoli dello stato del cluster di cache. Pertanto, questo garantisce che non si verifichino tempi di inattività o perdita di dati, poiché abbiamo integrato anche il supporto per la replica. COSÌ, NCache è altamente disponibile e, inoltre, è molto affidabile con l'aiuto della replica. Garantisce un tempo di attività del 100% sull'estremità dell'applicazione, senza alcuna interruzione dell'applicazione, puoi continuare a utilizzare NCache.

Topologie di memorizzazione nella cache

Successivamente parlerò delle topologie di memorizzazione nella cache. Questa è la parte principale che volevo coprire. Abbiamo quattro opzioni tra cui scegliere. La prima opzione è ancora una volta per configurazioni più piccole. Questi determinano come configurare una cache.

cache specchiata

Quindi, abbiamo la possibilità di configurare una cache utilizzando una topologia di cache mirrorata e il modo in cui funziona è che hai solo due server al massimo. Uno di questi server fungerebbe da server attivo, a cui saranno connessi tutti i client. L'altro server fungerebbe da server passivo, che funge da backup e il backup viene eseguito da NCache. Questa topologia, una volta configurata, segue automaticamente l'architettura. Non devi, fondamentalmente lo sai, definire che questo diventi attivo o questo diventi passivo, è fatto da NCache automaticamente. Ma, una volta fatto ciò, ciò che realmente accadrà è che tutte le applicazioni client si connetteranno al server attivo ed è da lì che leggeranno e scriveranno i dati. Tutti i dati che abbiamo sul server attivo verranno sottoposti a backup sul server passivo tramite un'opzione di mirroring asincrono. Pertanto, il client aggiorna l'attivo, restituisce, quindi il costo della replica non viene sostenuto dall'estremità dell'applicazione client. L'applicazione client sarà super veloce. Dietro le quinte, NCache dovrebbe aggiornare il backup. Inoltre, il backup è presente per un motivo importante: se il server uno non funziona, il server di backup viene automaticamente aggiornato come server attivo e i client eseguono il failover delle loro connessioni e iniziano a utilizzare il server appena attivo e precedentemente di backup. E, ora che il primo server rientra, si unirà nuovamente come nodo di backup, non come nodo attivo, perché ne abbiamo già uno attivo nel cluster di cache. E tutto questo viene aggiunto perfettamente alle tue applicazioni. Non è necessario effettuare alcun intervento quando un server viene aggiunto o perso.

Questa topologia è ottima sia per le letture che per le scritture. Quindi, buono come riferimento, buono per i dati transazionali, ma ha un problema di capacità perché hai solo due server al massimo e, di questi due server, solo un server è attivo in un dato momento. Quindi, per configurazioni più piccole, con dati affidabili, sai la memorizzazione nella cache, questa potrebbe essere una delle opzioni.

Cache replicata

Andando avanti, la seconda opzione è una cache replicata. Questo è ancora una volta per configurazioni più piccole. Funziona in modo tale che tutti i server siano attivi, come puoi vedere il server 1 e il server 2, entrambi sono attivi. I client sono divisi tra diversi server, quindi, se hai sei client come mostrato nel diagramma, alcuni di essi si collegheranno al server uno e altri si collegheranno al server 2. Esatto, questi tre sono collegati al server uno e questi sono collegati a servitore 2.

Ciò avviene automaticamente; il bilanciamento della connessione è qualcosa che è costruito dentro NCache. Tutti i server sono attivi ma ogni server ha una copia della cache. Pertanto, qualunque dato tu abbia sul server 1, una copia è sul server 2 e questa copia viene mantenuta con l'aiuto degli aggiornamenti di sincronizzazione. Pertanto, qualunque siano gli aggiornamenti eseguiti su un server, tali aggiornamenti devono essere applicati su altri server in una chiamata di sincronizzazione e, con questo intendiamo che il client attenderà fino al completamento dell'intera operazione. Se l'operazione fallisce su qualsiasi server, viene eseguito il rollback dell'intera operazione. Ed è così che otteniamo una copia sincronizzata al 100% su tutti i server. Ora, questo è molto buono in termini di affidabilità, ma, e anche se hai un caso di utilizzo intensivo di lettura, perché hai più copie di dati o più copie da server diversi, quindi, poiché hai più server, la tua capacità di lettura aumenterà perché hai più server per soddisfare le richieste. Tuttavia, come hai appena notato, è disponibile un aggiornamento di sincronizzazione, quindi qualsiasi operazione di scrittura deve essere applicata su tutti i server. Quindi, è utile per configurazioni più piccole per la capacità di scrittura. Se disponi di tre o quattro server, devi applicare la stessa operazione tre o quattro volte, in modo che ciò possa influire negativamente sull'aumento delle prestazioni. Pertanto, questa topologia è più consigliata per scenari di dati di riferimento, per configurazioni più piccole. È scalabile per le letture, non molto scalabile per le scritture, ma è molto affidabile. Offre elevata disponibilità e affidabilità dei dati, perché, se perdi un server, ad esempio, il server 1 viene perso, non si verificano perdite di dati o tempi di inattività perché queste applicazioni eseguiranno il failover e inizieranno a scegliere il server sopravvissuto e avranno una copia della cache già disponibile.

Cache partizionata e cache di replica delle partizioni

L'opzione successiva è che puoi scegliere, sai, puoi configurare una cache utilizzando la cache partizionata. Ora partizionato e la replica delle partizioni è la topologia più popolare. La cache partizionata ti consente di distribuire i dati tra i nodi del server disponibili. Ad esempio, se hai due server e hai dei dati, metà dei dati andrà sul server 1, metà dei dati andrà sul server 2. Anche la distribuzione dei dati fa parte di NCache. Non è qualcosa che fanno le tue applicazioni, viene eseguito automaticamente dalle applicazioni in fase di runtime. C'è una mappa di distribuzione intelligente e un algoritmo hash che determina quali dati andranno a quale server.

Quindi, in base a ciò, le tue applicazioni sono quelle che distribuiranno i dati in modo uniforme tra tutti i server nel cluster di cache. Ora i dati sono distribuiti equamente, quindi anche il carico della tua richiesta sarà distribuito equamente. Quindi, questo ti darà più capacità di lettura e scrittura in base al numero di server. Se hai due server, hai due server che lavorano in squadra. E, se passi da due a tre, avrai più server che gestiscono le tue richieste di lettura e scrittura. Quindi, ottieni maggiore scalabilità per letture e scritture. Quindi, in modo linearmente scalabile, ottieni maggiore scalabilità se aggiungi più server. Aggiungendo più server, stai anche raggruppando le risorse di memoria, poiché i dati sono distribuiti, quindi stai raggruppando insieme lo spazio di archiviazione di tutti i server. Quindi, se hai due server, hai una capacità di due server. Se aggiungi un terzo o un quarto server, aumenti la tua capacità di tanti server. Pertanto, la capacità complessiva viene raggruppata, in modo da ottenere una crescita lineare man mano che si aggiungono più server nel cluster di cache.

Ottimo per le letture, ottimo per le scritture, molto scalabile per riferimento e per i dati transazionali. L'unico svantaggio di questa topologia è che non dispone di alcun backup. Se perdi un server, perdi quella partizione. Quindi, quando ciò accade, devi avere un modo per costruire quei dati da un database back-end. Pertanto, se il tuo obiettivo principale è ottenere prestazioni elevate, se un'applicazione incentrata sulle prestazioni e puoi permetterti di tornare a un database, come comunemente accade, non ti affidi a NCache per l'elevata disponibilità e l'affidabilità dei dati, questo ti offrirà le migliori prestazioni rispetto a tutte le altre topologie.

Ma se hai bisogno di un'elevata disponibilità e sai, anche i requisiti di affidabilità dei dati devono essere soddisfatti NCache, ho una topologia migliore, chiamata Partition of Replica cache. Ora, l'architettura complessiva è esattamente come quella partizionata con un miglioramento delle repliche, in cui ogni server ha una partizione di dati, ma ogni server mantiene due partizioni; una partizione dati attiva, a cui sono connessi i client e una partizione di backup di un altro server. Il server 1 è attivo, il suo backup è su 2, il server 2 è attivo, il suo backup è su 1. E hai la possibilità di scegliere le opzioni di backup sincronizzato o asincrono. Se si sceglie la partizione di replica con asincrono, il client aggiornerà la partizione attiva e restituirà le operazioni completate sul client e quindi, NCache aggiornerà la partizione di backup dietro le quinte. Se si sceglie la sincronizzazione, l'applicazione client aggiornerà l'attivo e il backup come operazione transazionale. In ogni caso, la sincronizzazione è ovviamente più affidabile, l'asincronizzazione è più veloce. Ma in ogni caso, NCache è in grado di gestire l'affidabilità dei dati in modo tale che se un server si guasta, la topologia di backup viene attivata e non si riscontra alcuna perdita di dati o tempi di inattività delle applicazioni. Giusto.

Quindi, lascia che ti mostri rapidamente questa topologia con 3 server. Quindi, otteniamo tutti i vantaggi di prestazioni elevate per le letture, prestazioni elevate per le scritture, sai, scalabilità lineare sia per le letture che per le scritture. Oltre a ciò, otteniamo vantaggi in termini di scalabilità, alta disponibilità e affidabilità dei dati. Se un server si guasta, non si verificherà alcuna perdita di dati o tempi di inattività delle applicazioni.

Dimo

Spero che sia chiaro. Permettimi di portarti ora nel nostro ambiente demo e di mostrarti rapidamente come costruire queste topologie di memorizzazione nella cache e poi ti mostrerò anche come testare rapidamente un cluster di cache. Ma, nel frattempo, per favore fatemi sapere se ci sono domande. Bene, solo un breve promemoria che tutto ciò che stiamo mostrando, possiamo anche farlo con voi con sessioni di assistenza tecnica e sessioni di supporto tecnico nei vostri ambienti, per i vostri casi d'uso specifici. Quindi, su tutto ciò di cui discutiamo qui, anche dopo il webinar, saremmo felici come squadra di poterci riunire con voi anche su questo, per poter dimostrare come funzionerebbe per voi.

Per quanto riguarda le domande, ne ho una che è arrivata proprio alla fine. Uno di questi è uno dei tuoi preferiti.
Si è discusso molto sull'uso di Hazelcast per il caching delle applicazioni. Cosa fa NCache prevedere che Hazelcast non lo faccia?

Va bene. Prima di tutto, è più un dibattito. NCache è effettivamente scritto in .NET e .NET Core, quindi piattaforma preferita per NCache è Windows. La cosa bella di NCache è che funziona su .NET, così come su Windows, così come su Linux. Quindi, la piattaforma e la compatibilità lo supportano NCache offerte, non esiste nessun altro prodotto in grado di raggiungere questo obiettivo. Quindi, questa è la prima parte, dove è la scelta più preferibile se, sai, hai considerato la piattaforma che intendi utilizzare. L'altra differenza è e, vorrei incoraggiare tutti a dare un'occhiata, sai, al nostro pagine di confronto, troverai anche dell'ottimo materiale laggiù. Ma, per riassumere velocemente, NCache il supporto della memorizzazione nella cache degli oggetti ha molte funzionalità che mancano completamente ad altri prodotti. Ad esempio, per la ricerca SQL abbiamo un elaborato set di funzionalità disponibili al suo interno NCache. Abbiamo un caricatore di cache e un aggiornamento della cache. Queste sono caratteristiche completamente uniche NCache. Il nostro gestore di lettura e scrittura con la capacità di eseguire .NET e .NET Core codice sul lato server, è qualcosa che è una caratteristica assolutamente unica NCache, e l'elenco potrebbe continuare, giusto. Quindi, alcune delle funzionalità che, sai, puoi personalizzare sul lato server. Quelli sono disponibili solo in NCache poi, dal punto di vista applicativo, ci sono molte funzionalità che mancano in altri prodotti. Quindi, incoraggerei tutti a controllare la nostra pagina di confronto. Sono stati pubblicati alcuni confronti, funzionalità per funzionalità, che ti forniranno informazioni più dettagliate al riguardo.

Questa è sicuramente la nostra linea di domande preferita, che si tratti di un webinar o anche di una soluzione tecnologica, potrebbe essere Hazlecast, potrebbe essere Scala, potrebbe essere Redis, ma grazie mille, Ron. Sì, penso che siamo a posto. Perfavore continua. Sicuro.

Crea una nuova cache in cluster

Vorrei quindi fornire una rapida demo del prodotto creando una nuova cache in cluster. Chiamiamolo cache di test. Bene, lasciami spostare questa parte qui, abbi pazienza. Va bene.

Quindi, abbiamo appena spiegato quattro topologie di memorizzazione nella cache. Utilizzerò la cache Partition of Replica, perché è quella più consigliata con l'opzione di replica asincrona. Manterrò tutte queste impostazioni predefinite.

Vai avanti e ti mostrerò quanto è facile configurare una cache utilizzando gli strumenti della GUI. Questo è il nostro gestore web, ma puoi ottenere tutto utilizzando anche i nostri cmdlet di PowerShell e puoi anche automatizzare questa distribuzione, se questo è un requisito. Aggiungerò il server uno, dove NCache è installato. Aggiungerò quindi il server 2. Quindi, le mie 2 scatole con NCache con dimensioni di 2 concerti saranno, sai, allestiti. Quindi, la mia idea qui è che creerò un cluster di cache a 2 nodi utilizzando 2 GB di dimensione della cache su ciascuno. Quindi, in totale quattro concerti con 2 server dove NCache è già installato. E poi utilizzerò il mio box per connettermi a questo cluster di cache.

parametri TCP. questa è la porta che devi configurare, una volta fatto ciò. Mantienilo predefinito o specifica qualsiasi porta su cui il firewall non influisce su quella porta.

Se devi impostare la crittografia e la compressione, questa è la schermata. Lo terrò così com'è. Scegli successivo. Sfratti, se la tua cache si riempie, è qualcosa che puoi scegliere. Un'opzione è che la tua cache semplicemente non intratterrà alcuna operazione di scrittura. Ti verrà dato un errore, "la cache è piena". Un'altra opzione è impostare l'eliminazione e, in base a questi algoritmi, verranno rimossi alcuni elementi dalla cache in fase di esecuzione. Pertanto, in base alla priorità, all'utilizzo, è possibile rimuovere gli elementi utilizzati meno di recente o utilizzati di frequente e il XNUMX% degli elementi verrà rimosso dalla cache. Inizierò questa cache al termine e, con l'avvio automatico, in modo che ogni volta che il mio server si riavvia o NCache al riavvio del server è in grado di riavviare le cache che sono state arrestate.

Scelgo la finitura e basta. È così semplice configurare un cluster di cache. E tra poco mi mostrerà un'altra vista, dove verrà avviata questa cache, e poi ti mostrerò alcuni dettagli di monitoraggio e gestione da lì. Abbiamo alcuni video più dettagliati disponibili sulle configurazioni della cache, quindi se c'è, ci sono domande, fatemelo sapere ora, oppure possiamo, sai, fare affidamento anche su quei video.

Posso selezionare e scegliere il cluster di monitoraggio e ciò aprirà un'altra dashboard, che mi consentirà di monitorare completamente la mia cache. Mi mostra un cluster di cache completamente connesso, contatori di velocità effettiva delle richieste, contatori di latenza e quindi sono presenti anche aggiunte, recuperi e contatori di aggiornamento. Allo stesso modo, mi mostra l'utilizzo della CPU e della memoria e le situazioni di cache piena.

Ho anche dashboard per il client, nonché una visualizzazione report, in cui vediamo dashboard lato server e lato client. Al momento non esiste alcuna applicazione ad esso collegata, ma esiste un modo per simulare un carico utilizzando questo pulsante di test-stress. Quindi, posso avviare un caricamento fittizio o qualche attività sul mio cluster di cache chiamando questo test-stress. Non appena lo farò, vedrai che un client è connesso e questa topologia richiede che i miei dati vengano distribuiti, giusto. Pertanto, alcuni dati andrebbero sul server 1 e altri sul 2. Pertanto, questo client utilizza entrambi i server in modo uniforme. Come puoi vedere, le richieste arrivano a entrambi i server, la dimensione della cache sta aumentando su entrambi i server.

Abbiamo anche partizioni attive e di backup visualizzate su entrambi i server. E se ti mostro rapidamente i contatori di latenza, è una latenza inferiore al millisecondo, addirittura microsecondo, per quanto riguarda le mie operazioni. E posso vedere la dashboard del client che mostra queste statistiche lato client e, allo stesso modo, abbiamo un report che mostra le statistiche lato server.

Ron, ho una domanda, in realtà abbiamo un paio di domande che sono arrivate, quindi una di queste è:
Qual è la tua raccomandazione per lo sfratto? E, se almeno lo sfratto, aspetta il prossimo è, se lo sfratto è disattivato, possiamo aumentare la dimensione della cache o diminuirla?

Sicuro. Quindi, sai, lo sfratto è qualcosa che deve essere impostato in base al tuo caso d'uso, giusto. Se i dati sono qualcosa che puoi permetterti di essere sfrattato, giusto. Lo sfratto stesso rimuoverà alcuni dati se la cache si riempie. La situazione ideale è che non devi mai farlo e che la tua cache rientra ampiamente nella capacità, giusto. Quindi, dai abbastanza spazio o memoria sufficiente alla tua cache in modo che non si riempia mai. Ma, nei casi in cui lo fa, si arriva al punto in cui diventa pieno. In tal caso, se i tuoi dati sono qualcosa che puoi sempre ricostruire da un database back-end, si consiglia di attivare le eliminazioni. Ad esempio, per le sessioni ASP.NET, non è consigliabile attivare gli eliminazioni, poiché rimuoveresti alcuni utenti per fare spazio ai nuovi utenti e tutti gli utenti hanno i propri dati importanti, giusto. Quindi, sono dati che non vorresti perdere in nessun determinato scenario. Pertanto, per questi scenari ti consigliamo di aumentare la dimensione della cache. Pianifica le dimensioni della cache in modo tale che sia sufficientemente grande e nei casi in cui si riempie NCache consente di modificare la dimensione della cache in fase di esecuzione. Puoi modificarlo, a destra, e in base a ciò puoi aumentare e quindi salvare queste impostazioni su una cache in esecuzione. Pertanto, è applicabile a caldo e aumenterà la dimensione della cache in fase di esecuzione.

Qualsiasi altra domanda? Sembra che questo abbia risposto e ne salverò un paio per la fine, in modo che tu possa completare la tua dimostrazione. Sicuro. Quindi, tornando al mio ambiente demo, potresti aggiungere client, ad esempio, posso aggiungere il mio box come client e questa è una rapida panoramica di un'applicazione di esempio che posso eseguire dal mio box. Ad esempio, questo è disponibile anche da GitHub, quindi se cerchi NCache su GitHub vedresti alcuni esempi e da lì ho estratto uno degli esempi. Quindi, ciò che devi veramente fare all'interno della tua applicazione è includere questo pacchetto NuGet che è Alachisoft.NCache.Sdke se sei interessato a memorizzazione nella cache dei dati dell'app, questo è il campione che dovresti considerare. E, in base a ciò, una volta aggiunto questo, puoi includere alcune risorse all'interno dell'applicazione.

Ciò includerà già alcune, sai, librerie di NCache, come parte di questo nuovo pacchetto NuGet. E quindi includi questo riferimento utilizzando Alachisoft.NCache.Cliente. Aggiungi anche Runtime.Caching, giusto, e in base a ciò puoi definire un handle di cache e, al suo interno abbiamo un sacco di metodi. Ad esempio, lascia che ti mostri come inizializzare la cache. Entriamo davvero in questo. Sopportami. Sto attraversando un periodo difficile. Comunque, per qualche motivo, non sono in grado di entrarci, penso che ci sia un problema con la scatola stessa. Ma comunque, le API sono piuttosto intuitive. Lascia che te lo mostri dal nostro PowerPoint. Questo esempio lo sta effettivamente utilizzando, non sono in grado di dimostrarlo perché non sono in grado di entrare nel codice. Non me lo permette.

Quindi, questo è un handle di cache e questo è il pezzo di codice che volevo mostrare, ovvero il file CacheManager.GetCache ti consentirà di connetterti alla cache. Allora puoi chiamare cache.Get per ottenere effettivamente tutti i dati dalla cache. Allo stesso modo, puoi chiamare cache.Aggiungi or cache.AddAsync per aggiungere qualsiasi record nella cache e allo stesso modo inserirlo come in upsert dove aggiunge, oltre ad aggiornare, i dati nella cache e allo stesso modo, puoi chiamare cache.Rimuovi.

Così questo campione è disponibile che puoi scaricare ed eseguire sulla cache. Tutto quello che devi fare è puntare alla cache dall'estremità dell'applicazione. Ci sono un sacco di configurazioni. È possibile specificare il nome della cache e dell'IP inline oppure fare affidamento su un client.ncconf, incluso nel progetto da questo pacchetto NuGet. Quindi, se ti mostro rapidamente alcune risorse, vedi, vengono effettivamente aggiunti molti file e questo file qui è un file che ti consente di connetterti alla cache. Quindi è già in grado di connettersi al mio "democache". Se lo eseguo, eseguirà alcune attività sulla mia cache e avvierà le operazioni di memorizzazione nella cache.

Allo stesso modo, ho un altro campione che fornirà, sai, alcune opzioni in più, ad esempio su cui c'era una domanda cercando dentro NCache, Giusto. Quindi, ti consiglierei di utilizzare questo esempio proprio qui. Questo è per la ricerca SQL. Viene nuovamente scaricato da GitHub e ancora una volta utilizza la ricerca, utilizzando, ha dati di esempio e quindi chiama la ricerca utilizzando SQL. E ha un sacco di funzionalità proprio qui, sempre sulla stessa linea, gli esempi sono piuttosto intuitivi. Puoi inserire elementi e poi puoi interrogare usando i tag, puoi interrogare, sai, interrogare usando indici o proiezioni definiti.

Sfortunatamente non posso approfondire questi metodi a causa dei problemi ambientali, ma ancora una volta questi servirebbero come ottimo punto di riferimento per l'utilizzo NCache da qualsiasi applicazione, che necessita di utilizzare la memorizzazione nella cache all'interno dell'applicazione o che hanno un caso d'uso di ricerca all'interno dell'applicazione.

Cache cliente

C'era un'altra domanda a riguardo Cache cliente, quindi anche questa topologia è un'opzione senza modifica del codice. Tutti i dati memorizzati nella cache da un database interno NCache, puoi memorizzarlo ulteriormente nella cache utilizzando la cache del client. È una cache sopra un'altra cache. Funziona senza alcuna modifica del codice. È una cache sincronizzata con una cache in cluster, quindi non ci sono problemi di coerenza dei dati. La sincronizzazione viene eseguita da NCache. Tutti gli aggiornamenti effettuati su una cache del client vengono propagati necessariamente alla cache in cluster, quindi propagati alle altre cache del client e nella cache viene gestita tutta la sincronizzazione. Per scenari di dati di riferimento, in cui non si hanno molte scritture, questa è un'opzione molto consigliata tra cui scegliere.

Replica WAN

Analogamente, NCache ha anche un Replica WAN. Abbiamo topologie attivo-passivo e attivo-attivo. Pertanto, tutti i dati della cache possono essere replicati da un data center all'altro tramite la nostra cache bridge. Il backup di Bridge stesso viene eseguito su un server passivo attivo, quindi hai una cache di origine e una cache di destinazione, replica unidirezionale o migrazione da est a ovest dei dati da un data center all'altro per scenari DR o per migrazione da est a ovest, sai, o per situazioni in cui hai bisogno di dati da un'applicazione e devi utilizzarli nell'applicazione di destinazione. Pertanto, potresti trasferire interi dati della cache da un data center all'altro.

L'altra opzione è attivo-attivo. In questo caso, abbiamo entrambi i siti attivi, quindi il sito uno sta trasferendo i dati al sito due e il sito due sta trasferendo i dati al sito Uno. Anche in questo caso si tratta di un'opzione senza modifica del codice. E' solo una configurazione. Una volta impostato il bridge, colleghi due cache insieme e NCache prende il sopravvento e avvia la replica dei dati tra tali cache.

E questo è esteso anche alla topologia multi-attivo-attivo, quindi non è necessario che abbia solo due siti, potrebbero essere tre, quattro o cinque siti in cui tutti i siti trasferiscono i dati l'uno all'altro. COSÌ, NCacheè la capacità di sincronizzare i dati di tutti i siti contemporaneamente. E, a proposito, questo viene fatto in modo asincrono, quindi il costo della replica non viene nuovamente sostenuto dal lato dell'applicazione o dal lato dell'utente. Viene fatto sull'applicazione. Hai applicazioni client collegate qui così come qui. Non riscontrano alcun degrado delle prestazioni a causa di questa replica WAN. È fatto dietro le quinte da NCache. Fammi sapere se ci sono domande. Concludiamo a questo punto la presentazione e l'insieme delle funzionalità. Zack, fammi sapere se ci sono domande.

Sì, ne abbiamo un paio. E sapete tutti, apprezzo la vostra pazienza, quindi questo è anche un buon momento per inserire qualsiasi altra domanda se ve lo siete chiesto durante la presentazione. Quindi, cominciamo con uno.
Come puoi verificare se la cache è in esecuzione in uno stato integro? Riceviamo qualche tipo di notifica, ecc.? Ad esempio, come facciamo a sapere se c'è un problema?

Sicuro. Abbiamo strumenti di monitoraggio e gestione. Quindi, una cosa potrebbe essere che ispezioni visivamente e vedi l'integrità del cluster. Vedete, l'utilizzo della CPU, l'utilizzo della RAM. Se conosci la tua linea di base, quante richieste stanno generando le tue applicazioni e qual è l'utilizzo tipico di NCache sulla base di questi contatori potrai ispezionarli visivamente utilizzando le nostre dashboard di monitoraggio e gestione. E poi, abbiamo avvisi per qualsiasi situazione, ad esempio, avvii una cache, interrompi una cache, un nodo si unisce, esce, la dimensione della cache diventa piena o il cluster entra in uno stato non integro, come, cervello diviso, abbiamo avvisi, che accediamo ai registri eventi di Windows. E poi puoi anche impostare avvisi e-mail da NCachee può anche generare un'e-mail per te. Quindi, questo è qualcosa che sarà un monitoraggio proattivo, da cui verranno generati alcuni avvisi NCache, Dove NCache avviserà e potrai intraprendere azioni in base a ciò. Inoltre, disponiamo di dati storici acquisiti sotto forma di registri dei contatori perfmon, nonché registri della cache. Per quelle situazioni in cui non sapevi cosa è andato storto e hai riscontrato alcuni problemi NCache, possiamo venire e essere coinvolti e possiamo rivedere NCache logs e, in tal caso, effettuare una valutazione dell'integrità della cache. Quindi, molti di voi conoscono strade a questo riguardo che possiamo esplorare.

Suona bene. Un'altra domanda è:
Qual è l'ultima versione di .NET? NCache attualmente supporta i clienti?

Va bene. In genere, tendiamo ad essere aggiornati .NET framework versione, .NET Core. .NET 6 è attualmente supportato, ovvero un prerequisito per NCache. È necessario avere .NET 6 come elemento obbligatorio NCache server. Ma le tue applicazioni possono essere su qualsiasi, sai, .NET framework, penso da 3.5 in poi 4.0, 4.5, o anche 4.7, 4.8. Le tue applicazioni possono trovarsi su uno qualsiasi dei .NET o .NET Core struttura. È solo una limitazione lato server. E, non appena viene testata la compatibilità di un framework più recente, ad esempio per .NET 7, lo stiamo già testando nel nostro laboratorio di controllo qualità. Quindi, una volta che avremo firmato questo, rilasceremo un supporto ufficiale anche per quello.

Meraviglioso. Un'altra domanda è:
Quale considereresti la quantità sicura di cache in cluster tra i miei server di cache? Posso creare, ad esempio, 15 cache in cluster tra i miei server di cache?

Va bene. Prima di tutto, NCache non impone alcun limite al numero di cache che è possibile configurare. È un dato di fatto, se guardi il mio ambiente demo, ho due cache configurate. Quindi, puoi crearne quanti ne hai bisogno. Tuttavia, esiste una raccomandazione tecnica o una raccomandazione relativa alla capacità che in genere consigliamo in un ambiente di produzione di non superare le quattro o cinque cache. Perché ogni cache è un cluster di cache separato. In realtà consumerà tutte le risorse per l'archiviazione, per il clustering, per la comunicazione, c'è anche un sovraccarico di gestione del cluster. Quindi, man mano che il numero di cache aumenta, stai effettivamente introducendo quel problema di capacità in quell'ambiente o all'interno di quell'ambiente. Quindi, ti consigliamo di mantenerlo, sai, entro le quattro o le cinque, se possibile. In una situazione in cui devi avere più cache, puoi estenderla fino a 10. Ma, come ho detto, è ancora una raccomandazione. Non esiste un limite effettivo che lo imponga. È una raccomandazione generale da parte nostra.

Va bene. Lasciatemene aggiungerne un altro poiché, so che siamo alla fine della sessione e so che la gente ha altre cose sulla finestra mobile.
Può NCache fornire la replica DR?

Sì, lo fa. La funzionalità di replica WAN di cui ho appena parlato, l'ultima topologia, che copre il DR e il ripristino di emergenza. I siti possono essere trasmessi con i dati dal sito attivo, quindi avrai un sito DR completamente sottoposto a backup. Devi solo effettuare l'interruttore alla fine dell'applicazione. Poiché è già stato eseguito il backup di tutti i dati, non vi è alcuna perdita di dati nella situazione in cui un data center va completamente fuori servizio o è necessario disattivarlo tu stesso per la manutenzione.

Va bene. Penso che praticamente ne abbiamo centrati quanti più potevamo. Signore e signori, sappiate che siamo disponibili anche al di fuori di queste sessioni. Siamo molto felici di lavorare con te, fianco a fianco, quando si tratta di esaminare le tue configurazioni esistenti, se sei già un utente di NCache. Se sei nuovo a NCache, saremo lieti di fornirti una prova e di tenere sessioni dirette per spiegarti come funzionerebbe nelle tue applicazioni integrate, ma soprattutto, sappi che puoi contattarci in qualsiasi momento quando si tratta di qualsiasi domanda su NCacheo anche utilizzando il prodotto e se hai bisogno di aiuto. Abbiamo un sacco di novità in arrivo, anche il rilascio di nuove versioni, quindi tieniti sintonizzato e presto avremo altri webinar di questo tipo.

Un applauso per Ron. Apprezzo davvero che tu abbia dedicato del tempo per una sessione oggi e non vedo l'ora che arrivi la prossima. Grazie a tutti. Grazie, Zack. Ovviamente. Va bene, tutti quanti. Buona giornata a tutti e non vediamo l'ora di vedervi nel nostro prossimo webinar. E solo un disclaimer: una volta terminato questo webinar, ne caricheremo una registrazione sul nostro sito web, una volta che tutto sarà finito e spolverato. Quindi, se non hai avuto la possibilità di avere risposta a qualche domanda, se desideri rivisitare qualcuno dei punti che abbiamo sollevato, non esitare a tornare di nuovo sul nostro sito Web e controllare il webinar registrato.

Bene allora. Un saluto a tutti. Ne hai uno buono. Grazie ragazzi. Ciao ciao.

Cosa fare dopo?

• NCache Dettagli
• Scaricare NCache
• Richiedi una Demo LIVE personalizzata