NCache Architettura

Spettacolo registrato
Di Ron Hussain e Zack Khan

Il webinar di oggi si baserà su NCache ArchitetturaOra, tratteremo una panoramica della cache distribuita e di come risolve i colli di bottiglia in .NET e .NET Core. Analizzeremo i casi d'uso comuni, l'architettura della cache distribuita e i dettagli del clustering, nonché tutte le domande che potresti avere riguardo non solo a NCache, ma in generale sulla memorizzazione nella cache. Ora, in qualsiasi momento durante questo webinar, abbiamo la possibilità di porre domande qui nella scheda "Domande di GoToWebinar", quindi vi preghiamo di consultare la scheda "Domande" quando vi è più comodo. E, una volta che avrete scritto una domanda, potrò sollevarla durante la presentazione affinché Ron o io stesso rispondiamo. Avremo anche un po' di tempo alla fine di questa sessione per poter rispondere a eventuali altre domande che dovessero pervenire, ma non vediamo l'ora di divertirci.

Quindi, senza ulteriori indugi, passo la parola a Ron e cominciamo. Molto bene, grazie, Zack. Allora, come ha appena detto Zack, l'argomento di oggi è NCache architettura. In questo webinar, spiegherò in dettaglio come NCache il clustering funziona, quali sono le topologie più comuni tra cui puoi scegliere e uno dei principali vantaggi di NCache in termini di casi d'uso della tua applicazione. Quali sono questi casi d'uso e come puoi sfruttarli appieno NCache all'interno delle tue applicazioni server?

Quindi, spero che tutti possano vedere il mio schermo. Se riesco ad avere una rapida conferma, inizierò subito a lavorare. Sì, penso che siamo tutti a posto, se puoi. Ecco fatto, direi. Sì, sembra bello. Perfetto. Ok, quindi iniziamo velocemente.

Il problema della scalabilità

Bene, allora definiamo prima di tutto cosa NCache è? E per questo, dovrò andare avanti e definire cosa è un problema di scalabilità, e poi come NCache è in grado di risolvere questo problema di scalabilità. Quindi, in una tipica architettura server in cui vengono distribuite applicazioni, di solito si tratta di più di un'istanza o più di un server, a seconda che tali applicazioni siano distribuite. Quindi, si può tranquillamente affermare che il livello applicativo è altamente scalabile.

È possibile aggiungere quanti server si desidera a un livello applicativo. È possibile creare un modulo web, un modulo app, in cui più server applicativi o server web ospitano la stessa applicazione, ma lavorano in team e si dividono il carico di richieste. E, se si passa a un'architettura più recente, anche con microservizi, è possibile scalare individualmente i servizi applicativi, microservizi che richiedono maggiore potenza di calcolo o maggiore capacità di gestione delle richieste.

Quindi, il livello App è molto scalabile. È scalabile linearmente. Man mano che si cresce, si è in grado di gestire un carico di richieste sempre maggiore. Il problema si presenta quando si ha a che fare con il database, come un database relazionale. Perché tutte queste applicazioni, indipendentemente dal livello di scalabilità, devono sempre comunicare con un database backend. E quando comunicano con un database backend, di solito si tratta di una singola sorgente. E questo non è molto scalabile. È ottimo per lo storage; si possono avere molte risorse disco. Quindi, si possono trarre vantaggi in termini di storage. Ma quando si ha un enorme carico transazionale sulle applicazioni, e questo si traduce in un carico transazionale del database, i database tendono a bloccarsi. E questo è il problema principale, ovvero quando l'applicazione ha difficoltà a gestire le richieste. Non è scalabile e anche l'esperienza dell'utente finale ne risulta compromessa.

I database NoSQL risolvono in qualche modo questo problema. È possibile utilizzare un database SQL, ma ciò richiede una riprogettazione dell'applicazione, che deve passare da un database relazionale a un database NoSQL, e questo è un progetto complesso. Pertanto, NoSQL non è sempre la soluzione ideale a un problema di scalabilità.

La soluzione: NCache Cache distribuita

Quindi, cosa dovremmo fare ora che ci troviamo di fronte a questo? La soluzione è molto semplice: dovremmo avere una cache distribuita in memoria come in NCacheInnanzitutto, è in-memory, quindi il vantaggio principale è che le prestazioni della tua applicazione saranno migliorate. È superveloce 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 consente di creare un cluster di cache che può essere eseguito su più server. E, come sapete, quando i requisiti o le esigenze aumentano, è necessario disporre di una maggiore capacità di gestione delle richieste da gestire dal livello applicativo; è possibile aggiungere più server in fase di esecuzione nel cluster di cache.

La cosa bella di NCache è che lo si utilizza in aggiunta a un database relazionale; o a un database back-end, non sostituisce le fonti dati convenzionali. È qualcosa che integra, sapete, le fonti dati esistenti in modo tale da aumentare le prestazioni delle applicazioni. È in grado di aumentare la capacità di gestione delle richieste per le applicazioni. E, man mano che si cresce sul lato applicativo, è sempre possibile aumentare il numero di server nel cluster di cache, perché questi sono server in un cluster, quindi lavorano come un team. Sono in grado di dividere il carico di richieste tra loro in modo tale da offrire una scalabilità lineare. Quindi, 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. Questi 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 le tue applicazioni web ASP.NET o ASP.NET Core, i tuoi servizi .NET o .NET Core o le applicazioni server .NET/.NET Core. Oppure potrebbero essere anche Java o Node.js. Quindi, anche queste applicazioni possono trarre vantaggio dalla cache distribuita.

NCache è scritto in .NET/.NET Core. Funziona sia su Windows che su Linux. Allo stesso modo, le tue applicazioni potrebbero essere su qualsiasi piattaforma e funzionerebbero senza problemi. In genere, consigliamo di avere NCache su server di configurazione dedicati, che ospitano solo NCache, in modo da avere risorse dedicate per NCache. Inoltre, i server applicativi si trovano su un livello separato. In questo modo, anche le risorse per le applicazioni sono dedicate. Ma esiste anche un'altra opzione di distribuzione, che per configurazioni più piccole può essere: NCache che si trovano sulle stesse scatole, dove sono in esecuzione anche le tue applicazioni. Quindi, questa è sempre una possibilità con NCacheMa, come discusso, l'opzione consigliata è quella di avere un livello di cache separato, come mostrato nel diagramma. E, quindi NCache Si trova tra l'applicazione e il database. L'idea è di memorizzare nella cache tutti i dati che utilizzi più frequentemente all'interno delle tue applicazioni. Potrebbero essere dati di riferimento o dati transazionali. Per "riferimento" intendo dati che richiedono un'intensa attività di lettura, mentre per "transazionali" intendo dati che richiedono sia un'intensa attività di lettura che di scrittura. Una volta che sai quali dati memorizzare nella cache, puoi chiamare quei dati il ​​tuo "working set". Per la prima volta, puoi recuperare quei dati dal database e, in seguito, aggiungerli all'interno. NCache e le chiamate successive possono essere gestite tramite NCache Solo così si risparmiano costosi spostamenti al database. Questo è ciò che in genere chiamiamo schema "cache-aside", in cui tutte le modifiche apportate vengono propagate alla cache e quindi al database. E se un database non è presente nella cache, viene sempre recuperato dal database e conservato al suo interno. NCache Ma prima controlla sempre la cache. Quindi, se trovi dati nella cache, non devi andare al database e tornare indietro da lì.

Lettura/scrittura

L'approccio alternativo è quello di utilizzare "read-through" o "write-through", qui rappresentati da linee tratteggiate. NCache Dispone di una funzionalità che può automatizzare questa operazione, offrendo l'opzione "cache-through", definita "read-through" per le letture e "write-through" per le scritture. Funzionerà in modo tale che la cache venga sempre utilizzata come sorgente principale e che venga implementato un gestore read-through e write-through sulla cache, che si occuperà dell'aggiornamento delle sorgenti dati backend. Quindi, qualunque operazione di lettura si esegua, se i dati non esistono, verranno trasferiti senza problemi al database in base al provider, recuperati per l'applicazione e restituiti all'app, dove verranno anche memorizzati. NCachePer gli aggiornamenti, aggiornerà la cache e il database in modo sincrono o asincrono, a seconda del modello richiamato dall'applicazione.

Quindi, condividerò maggiori dettagli sui modelli di lettura, scrittura e memorizzazione nella cache, ma solo per darti un quadro generale della distribuzione, ecco come vedresti NCache distribuiti in un formato server, dove più applicazioni o moduli applicativi possono connettersi NCache e, quindi, possono sfruttare la cache distribuita, dove l'accesso in memoria migliora le prestazioni delle applicazioni. E avere più server nel livello di cache può offrire una scalabilità lineare. Spero di essere stato chiaro; fatemi sapere se avete domande. Beh, per fortuna, al momento sembra che non ce ne siano, quindi sentitevi liberi di continuare. Molto bene.

NCache Numeri di scalabilità

Quindi, ora parlerò di NCachei numeri di scalabilità. Abbiamo appena detto che NCache è in grado di risolvere il problema di scalabilità della tua applicazione. Quindi, NCache Di per sé, è scalabile linearmente. Quindi, con il livello applicativo scalabile, ovvero con un collo di bottiglia del database risolto tramite un modello scalabile linearmente, ecco alcuni numeri che potete prendere come riferimento. Questi erano i nostri test di benchmark condotti nel nostro ambiente QA; abbiamo utilizzato server con un elevato consumo di CPU e RAM, in modo da poterli sfruttare al meglio e utilizzarli in situazioni di carico elevato. Abbiamo iniziato con un server e abbiamo continuato ad aumentare il carico applicativo con due server. Non appena un set di server ha raggiunto il limite massimo di CPU e RAM, abbiamo aggiunto un altro server.

Questa è la regola generale: quando puoi continuare a utilizzare i server cache esistenti, inizia con due NCache server, e quando vedi che quei due server stanno sfruttando al massimo la capacità hardware, se la CPU o la RAM stanno sfruttando al massimo, è il momento in cui decidi di scalare orizzontalmente e di aggiungere un terzo server al 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 il numero di server. Fino a quando il set di server specificato non ha raggiunto il massimo. E questi non erano dati improvvisati; erano dati di applicazioni 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.

Si è trattato di una combinazione di letture e scritture applicate in modo coerente alla cache. Complessivamente, è stato raggiunto un throughput di 2 milioni di richieste al secondo, senza compromettere le prestazioni. Quindi, il throughput non consiste solo nell'avere un gran numero di richieste al secondo; ma anche nel mantenere la latenza delle singole richieste, e nel garantire la massima velocità. Una dimostrazione video di questo aspetto, così come un white paper, sono pubblicati sul nostro sito web (Vedere qui). E anche questo è qualcosa che puoi rivedere.

Usi comuni della cache distribuita

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

• Memorizzazione nella cache dei dati dell'app

  Il caso d'uso numero uno è la memorizzazione nella cache dei dati dell'applicazione, lo chiamiamo Memorizzazione nella cache dei dati dell'appOra, questi sono i dati che provengono da un database back-end. Abbiamo già stabilito che il database è lento in generale perché è basato su disco, mentre la RAM è una fonte più veloce. L'altro problema è che il database tende a bloccarsi in caso di traffico elevato. Se si ha un carico transazionale elevato e c'è un singolo server, è prevedibile che non fornirà le prestazioni necessarie sul lato applicativo. Quindi, ha molto senso memorizzare nella cache i dati dell'applicazione all'interno delle applicazioni utilizzando NCacheÈ molto semplice; si usa NCache API e basta chiamare la cache. Ci si connette alla cache chiamando le API di inizializzazione della cache. Una volta connessi alla cache, è possibile chiamare 'cache.Aggiungi, cache.Aggiorna, cache.Rimuovi' o 'cache.Get' per recuperare i dati dalla cache. Quindi, vi mostrerò alcuni esempi verso la fine. Ma l'idea qui è che qualsiasi dato pensiate di leggere più di una volta, che si tratti di dati di riferimento o dati transazionali. Per i dati di riferimento, NCache aggiungerà molto valore perché non sarà necessario tornare al database per recuperare le modifiche.

  

  Bene, i dati nella cache saranno utilizzabili per un periodo di tempo più lungo. E, mentre si utilizzano i dati da NCache, non devi accedere al database backend. Questo migliora le prestazioni della tua applicazione. E ti offre scalabilità perché NCache è scalabile in confronto.

  Quindi, è molto intuitivo memorizzare nella cache tutti i dati di riferimento, ma consigliamo anche di memorizzare nella cache alcuni o addirittura la maggior parte dei dati transazionali. Nella nostra esperienza, consigliamo di memorizzare nella cache qualsiasi dato letto più di una volta, anche se si tratta di qualcosa che leggerete due o tre volte. Perché anche se vengono modificati nel database, e dopo tale modifica, se leggete più di una volta – due o tre volte – ha molto senso memorizzare nella cache quei dati, in modo da non dover accedere al database backend. E abbiamo funzionalità integrate in NCache che può garantire anche una sincronizzazione al 100% con il database. È qualcosa che puoi sempre considerare.

  Ron, mi è arrivata una domanda veloce, che in sostanza era:
  Devo sempre accedere alla mia cache in cluster tramite la rete? Temo che problemi di rete possano impedire il funzionamento delle mie applicazioni. Esiste un modo per gestire alcuni dei miei dati in locale?

  Ok, quindi in genere, la distribuzione predefinita è quella che ti consigliamo di avere NCache su caselle separate, e poi la tua applicazione su caselle separate, giusto? Quindi, quando NCache Si basa sul protocollo TCP, quindi è una chiamata di rete. Esiste una funzionalità chiamata "Client-Cache", che è una cache locale che risiede sui box applicativi. E, in alcuni casi, se si ha davvero bisogno di più prestazioni e non si desidera alcun tipo di latenza causata dalla rete, può anche essere resa "in-proc", il che significa che risiederà all'interno del processo applicativo. Quindi, quando ciò accade, il sottoinsieme dei dati viene automaticamente inserito nella cache client. Questo eviterà qualsiasi comunicazione tra processi. E quindi risparmierà anche qualsiasi comunicazione di rete o qualsiasi sovraccarico di rete. Quindi, abbiamo una funzionalità; è un aspetto che tratterò quando parleremo delle nostre topologie. Condividerò quindi maggiori dettagli, ma solo per darvi una rapida panoramica, ecco come funziona la cache client. È una cache che risiede sullo stesso box in cui si trovano le vostre applicazioni. E l'idea è che non richieda frequenti accessi alla rete se la cache client è abilitata. E questo funziona senza alcuna modifica al codice. Spero di aver risposto alla domanda. Fatemi sapere se avete altre domande. Sì, sembra una buona idea. Ron, prendi la parola. Molto bene.

• Caching per ASP.NET e ASP.NET Core

  Il prossimo caso d'uso di NCache Si tratta di un'applicazione web. Se, ad esempio, ci sono dei requisiti per la memorizzazione nella cache dei dati utente, giusto? In genere si tratta dello stato della sessione ASP.NET o ASP.NET Core. Questi dati non appartengono al database, perché sono dati transitori. Sono dati che un utente crea e rimangono nell'ambito dell'applicazione finché l'utente è attivo. In alcuni casi, è possibile conservarli nel database per motivi storici, ma nella maggior parte dei casi i dati appartengono all'utente.

  Quindi, sessione Microsoft ASP.NET o ASP.NET Core. Ci sono diverse opzioni: puoi usare un server di stato, puoi usare in-proc, puoi usare un server di database, ma ognuna di queste opzioni ha dei problemi. Ad esempio, in-proc è un singolo punto di errore; devi usare il bilanciamento del carico della sessione persistente. Anche ASP.NET State Server è un singolo punto di errore e, come sai, non è scalabile. Il database è un'opzione, non è un singolo punto di errore perché puoi eseguirne il backup, ma in alcuni casi potrebbe esserlo, tuttavia è lento e non scalabile. Quindi, cosa dovremmo fare qui? Ancora una volta, considera l'utilizzo di NCache per la memorizzazione nella cache dello stato della sessione ASP.NET e ASP.NET Core. Funziona in modo tale da poter collegare il nostro provider. È un'opzione senza modifiche al codice, ma non appena lo colleghi NCache all'interno delle tue applicazioni, NCache diventa il tuo storage di sessione principale. E l'idea è che sarà super veloce perché basato sulla RAM. È molto scalabile perché ci sono più server. E, all'interno NCache, una volta che procederemo con la presentazione e parlerò delle topologie, capirete che NCache Dispone di backup, con l'ausilio delle repliche. E i dati di sessione sono dati utente, giusto? Quindi sono dati che non si vorrebbero perdere in nessuna situazione, perché una volta persi, si ha un impatto sull'utente e sull'azienda. Quindi, con la replica, anche i dati vengono sottoposti a backup.

  

  Quindi, se dovessi elencare i vantaggi che otterrete, e sapete, prima di tutto, che migliorerete le prestazioni della vostra applicazione grazie all'accesso in memoria. Avrete più server che supportano le vostre applicazioni per il caching delle sessioni, quindi è molto scalabile. Inoltre, ha funzionalità integrate di alta disponibilità e affidabilità dei dati. Quindi, non ci saranno perdite di dati di sessione o tempi di inattività dell'applicazione in caso di... NCache il server si blocca. E non è più necessario 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 al codice.

  Un altro caso d'uso è quello di raggruppare lo stato di visualizzazione se si utilizzano moduli Web ASP.NET. È lì che verrà memorizzato nella cache anche lo stato di visualizzazione. Lo stato di visualizzazione diventa pesante; consuma molta larghezza di banda. Diventa parte dei pacchetti di richiesta e risposta e viene sempre inviato al browser. E non viene mai realmente utilizzato lì, ma è qualcosa che viene memorizzato sul browser, sul lato client. E quando si esegue il postback, è 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 il tuo payload non abbia più un pesante stato di visualizzazione associato. Questo migliora le prestazioni. Anche se, sai, lo stato di visualizzazione è qualcosa che viene sempre memorizzato sul lato browser. Ma se lo mantieni sul lato server, dove è necessario, migliorerà il comportamento generale dell'applicazione. Non consumerà più la tua larghezza di banda perché il pacchetto di richiesta e risposta effettivo non ha più un pesante stato di visualizzazione associato. E, inoltre, saremo molto sicuri perché lo stato di visualizzazione è memorizzato sul lato server, e quindi puoi impostare una crittografia e alcune funzionalità di sicurezza. E questa è anche un'opzione che non richiede modifiche al codice. Ma si applica solo ai moduli web legacy. Quindi, consiglierei, se hai un'applicazione per moduli web ASP.NET, di prendere in considerazione anche la memorizzazione nella cache dello stato di visualizzazione.

  E poi abbiamo la cache di risposta di ASP.NET e ASP.NET Core. Quindi, per le pagine statiche o le porzioni di pagina all'interno di una pagina che sono statiche, dovresti considerare la memorizzazione nella cache di questi output di pagina. E in ASP.NET Core, abbiamo un'opzione di cache di risposta che puoi scegliere, e questa è anche un'opzione senza modifiche al codice. Oltre a questo abbiamo anche ASP.NET e ASP.NET Core SignalR Backplane. Perché in un modulo web, se stai usando SignalR hai bisogno di un backplane come requisito indispensabile. E i backplane tipici, come un file system o un database, possono avere tutte quelle sfide di scalabilità e prestazioni di cui abbiamo appena parlato. Con NCacheSarà estremamente veloce, scalabile e affidabile, perché utilizziamo un sistema di messaggistica molto affidabile in background. Questi sono solo alcuni dei casi d'uso che è possibile sfruttare nelle applicazioni ASP.NET o ASP.NET Core.

Prima di proseguire, Zack, credo che ci sia una domanda pubblicata. Sì. Quindi, la domanda è nata sostanzialmente dal presupposto che DB sia di default. Quindi, nel bel mezzo del tuo... volevo aspettare che tu finissi, ma la domanda in pratica chiede... E nel caso, potresti approfondire la questione, signore?

Ciao Ron, è NCache adatto anche per scopi di pubblicazione di dati, con il requisito, dove il requisito è quello di salvare i dati nella cache di 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 potrebbe sempre essere un requisito. Funziona in due modi. Uno è che la tua applicazione ora utilizza dati provenienti da NCache, ma i dati esistono nel database. Quindi, si tratta di due fonti diverse che devono essere sincronizzate sia per la lettura che per la scrittura. Ora, se l'applicazione connessa a NCache e il database è l'unica applicazione responsabile della modifica dei dati al suo interno NCache e database, ora ti consigliamo di utilizzare read-through e write-through. E sì, questo può essere fatto in modalità asincrona o sincrona, a seconda delle tue esigenze. Quindi, quello che succederà realmente è che, ogni volta che proverai a recuperare dei dati da NCache e non esiste nella cache e si desidera memorizzarlo, si chiama automaticamente read-through, che leggerà dal database backend in base al codice. Allo stesso modo, se i dati provengono da un database e, ancora una volta, devono essere aggiornati nel database, non appena si aggiornano i dati nella cache, in tal caso si utilizzerà write-through. Ora, 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 si desidera un'invocazione asincrona, in tal caso è possibile utilizzare il write-behind, in modo che possa essere eseguita in background. Ma ancora una volta, NCache e la tua applicazione è responsabile di ciò, dove NCache sta chiamando il tuo codice e la tua applicazione lo sta invocando.

Un'altra situazione potrebbe essere che altre applicazioni stiano modificando direttamente i dati nel database e la tua applicazione non ne sia a conoscenza. In tal caso, ciò che accadrà realmente è 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 del database. Quindi, ci sono molte funzionalità di sincronizzazione in cui qualsiasi modifica nel database viene catturata da NCache automaticamente. E puoi usare di nuovo la lettura e ricaricare i dati all'interno NCache anche. Quindi, per riassumere, NCache puoi, sai, gestire entrambe le situazioni: in cui è la tua applicazione l'unica entità che modifica qualcosa al suo interno NCache e database, oppure 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 al 100% per questi casi. Se stai parlando di cache di memoria, in genere la cache di memoria è presente anche in ASP.NET, giusto! Ma se ti riferisci a NCache come cache di memoria, quindi ho già risposto alla domanda. Quindi, fatemi sapere se avete altre domande, così possiamo proseguire.

• Messaggistica Pub/Sub

  Sembra una buona idea. Penso che possiamo andare avanti. Certo. Bene, ora parlerò della messaggistica Pub-Sub. Come puoi vedere, NCache è già condiviso tra le applicazioni, giusto? Quindi è un'entità che puoi utilizzare per i tuoi requisiti di dati. Puoi aggiungervi dati; puoi recuperarli. Puoi ottenere vantaggi in termini di prestazioni e scalabilità da NCacheÈ possibile estendere questo caso d'uso utilizzando NCache anche come piattaforma di messaggistica. Quindi, NCache la messaggistica è molto potente all'interno NCacheSi tratta di un meccanismo asincrono, basato sugli eventi, in cui più applicazioni possono gestire requisiti di messaggistica o di coordinamento tra loro. Se è necessario che più applicazioni comunichino tra loro, creare una comunicazione efficace è una sfida. Pertanto, è necessario affidarsi a un'entità centralizzata. NCache è quell'entità. E con il suo supporto di messaggistica, è in grado di darti l'opzione in cui un'applicazione può aggiungere dati o messaggi a NCachee tali messaggi possono essere propagati a tutti gli abbonati all'altro capo del telefono: le altre applicazioni che necessitano, sapete, di tali messaggi.

  

  Allo stesso modo, potrebbero essere messaggi basati sui dati. Ad esempio, se vengono aggiunti, aggiornati o eliminati dati, si riceve una notifica. Potrebbero essere messaggi applicativi personalizzati o messaggi basati sui dati, in modo da coprire entrambe le aree in cui vengono inseriti i dati. NCache e si desidera che altre applicazioni ne siano a conoscenza, è possibile gestire i requisiti di messaggistica tramite questo. Oppure, potrebbe trattarsi di messaggistica personalizzata o di messaggistica basata sulle applicazioni, in cui un'applicazione deve comunicare con un'altra applicazione. Si basa ancora una volta su un modello scalabile in memoria. Offre anche opzioni di replica affidabili. Si basa sulla piattaforma di messaggistica Pub-Sub convenzionale, in cui abbiamo un concetto di argomento e un concetto di broker di messaggi, a cui sono connesse più applicazioni. Quindi, è possibile definire applicazioni di pubblicazione e di sottoscrizione. Le applicazioni di pubblicazione pubblicano, sapete, messaggi a NCache che vengono poi trasmessi a tutti gli abbonati. A loro volta, gli abbonati possono inviare i propri messaggi. NCache funge da piattaforma di comunicazione tra queste diverse applicazioni.

• Ricerca full-text (Lucene distribuito)

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

  Di solito, l'API di Lucene è autonoma. Ma all'interno, è possibile estenderla su più server. NCache ti dà anche la possibilità di caricare indici all'interno della memoria. Quindi, NCache utilizzerebbe indici basati su disco, ma consente di estendere la capacità di archiviazione e di gestione delle richieste tramite l'utilizzo di più server. Quindi, sebbene sia basato su disco, sarà comunque migliore di una singola sorgente sul database. Perché, nei casi in cui si ha un carico transazionale elevato, ogni server sarà responsabile del proprio set di richieste di indici. Quindi, sarà molto scalabile e anche molto affidabile. Poiché si tratta di un archivio assistito, quando si tratta degli indici di scena, la persistenza stessa è una funzionalità con un NCacheTutti i dati che memorizzi all'interno NCache può essere mantenuto anche sul disco o, in base ad alcuni provider di database, può essere mantenuto anche su alcuni database. Ma Lucene è l'unica funzionalità in cui NCache utilizza il disco anziché la RAM, perché la natura del caso d'uso è tale che richiede che i dati siano persistenti.

  

Spero di essere stato chiaro. Quindi, questi erano alcuni dei casi d'uso. Anche in questo caso, abbiamo molte funzionalità; qualsiasi tipo di applicazione, qualsiasi requisito specifico all'interno di un'applicazione, può essere gestito completamente utilizzando le nostre funzionalità di caching degli oggetti e di caching delle sessioni.

Solo una domanda veloce, Ron.
Esiste un modo per accedere ai dati nella cache come faccio nel mio database MySQL? Vorrei poter eseguire query SQL sui dati della mia cache. Posso farlo?

Sicuro. NCache Innanzitutto supporta la ricerca SQL e le query LINQ. Quindi, se si ha la capacità di scrivere un'applicazione che può semplicemente connettersi a NCachee quindi eseguire ricerche basate su criteri, quindi questa è l'opzione più semplice che puoi utilizzare, ovvero scrivere una ricerca basata su criteri. Ad esempio, puoi selezionare tutti i prodotti in cui prodotto.prezzo è maggiore di 10 e minore di 100. Oppure puoi trovare tutti i prodotti in base a una categoria; puoi trovare i clienti in base a una regione. Quindi, puoi creare ricerche basate su SQL o ricerche basate su LINQ e NCache ti darebbe i dati dalla cache. Quindi questa è una delle opzioni.

L'altra opzione è l'integrazione con LINQ Pad. Quindi, se si desidera semplicemente visualizzare i dati senza dover sviluppare un'applicazione, LINQ Pad è una soluzione semplice che consente di eseguire query LINQ e quindi visualizzare i dati eseguendo query LINQ.

E poi, nella nostra prossima release, la terza opzione è quella di fornire uno strumento di analisi dei dati. Quindi vi forniremo un metodo automatizzato, uno strumento di monitoraggio, che vi darà la possibilità di monitorare i dati presenti nella cache. E vi fornirà opzioni di ricerca basate su criteri tramite un'interfaccia grafica, quindi è qualcosa che è in fase di sviluppo; i requisiti sono stati completati, il lavoro di sviluppo è stato completato. Credo che sarà parte della nostra prossima release.

Non vedo l'ora di vedere tutto questo. Perfetto. Sì. Molto bene. Penso che per ora siamo a posto, Ron. Riserverò un paio di queste domande per la fine perché ne abbiamo avute alcune interessanti, ma sì, andiamo avanti. Certo.

Cluster dinamico auto-riparante

Quindi, ora parlerò del cluster di cache dinamica e di tutti i dettagli a riguardo. NCache si basa sul protocollo di clustering della cache basato su TCP/IP. È un clustering della cache implementato internamente. Non utilizziamo clustering di terze parti o di Windows. È un protocollo proprietario al 100%. È scritto in .NET e .NET Core, quindi è molto pratico in termini di: anche i socket TCP sono basati su .NET e .NET Core. L'architettura è peer-to-peer al 100%, quindi non esiste un singolo punto di errore. È possibile aggiungere o rimuovere server in fase di esecuzione. Non è necessario arrestare la cache o le applicazioni client ad essa connesse. Quindi, è possibile apportare modifiche dinamiche a un cluster di cache in esecuzione e, NCache Non vi creerà alcun problema. Quando aggiungete un server, i client vengono avvisati in fase di esecuzione, quindi sanno automaticamente che questo server non c'è più, cioè non fa più parte del cluster di cache, quindi iniziano a utilizzare il server aggiuntivo e il cluster si adatta automaticamente. Allo stesso modo, una volta rimosso un server, altri server rilevano che questo server è andato perso per sempre. Avvisano i client, che smettono di utilizzare il server perso. C'è un supporto per il failover della connessione, anch'esso integrato sul lato client, quindi qualsiasi server inattivo garantirà che il cluster si assicurerà che i client ne siano a conoscenza, e che eseguano il failover della connessione e inizino a utilizzare i server ancora attivi.

Quindi, in ogni caso, qualsiasi modifica nel cluster viene propagata ai client. I client sono intelligenti e sono sempre a conoscenza dello stato del cluster di cache. Questo garantisce che non si verifichino tempi di inattività o perdite di dati, perché abbiamo integrato anche il supporto per la replicazione. Quindi, NCache è altamente disponibile e, inoltre, molto affidabile grazie alla replicazione. Garantisce il 100% di uptime sul lato applicazione, senza alcuna interruzione dell'applicazione, puoi continuare a utilizzare NCache.

Topologie di memorizzazione nella cache

Ora parlerò delle topologie di caching. Questa è la parte principale che volevo trattare. Abbiamo quattro opzioni tra cui scegliere. La prima opzione è ancora una volta per configurazioni più piccole. Queste determinano come configurare una cache.

cache specchiata

Abbiamo quindi la possibilità di configurare una cache utilizzando una topologia di cache mirrored, che prevede al massimo due server. 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 NCacheQuesta topologia, una volta configurata, segue automaticamente l'architettura. In pratica, non è necessario definire se questa diventa attiva o passiva, è tutto fatto da NCache automaticamente. Ma, una volta fatto questo, ciò che accadrà realmente è che tutte le applicazioni client si connetteranno al server attivo e da lì leggeranno e scriveranno i dati. Tutti i dati presenti sul server attivo verranno sottoposti a backup sul server passivo tramite un'opzione di mirroring asincrono. Quindi, il client aggiorna il server attivo, restituisce i dati, quindi i costi di replica non vengono sostenuti dall'applicazione client. L'applicazione client sarà super veloce. Dietro le quinte, NCache Dovrebbe aggiornare il backup. E il backup è presente per un motivo importante: se il server uno dovesse mai andare in crash, 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 di backup precedentemente attivo. E, ora che il primo server torna in servizio, si unirà di nuovo come nodo di backup, non come nodo attivo, perché ne abbiamo già uno attivo nel cluster di cache. E tutto questo viene eseguito senza problemi sulle tue applicazioni. Non devi effettuare alcun intervento quando un server viene aggiunto o perso.

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

Cache replicata

Proseguendo, la seconda opzione è una cache replicata. Anche questa è adatta a configurazioni più piccole. Funziona in modo tale che tutti i server siano attivi, come si può vedere, sia il server 1 che il server 2. I client sono suddivisi tra server diversi, quindi, se si hanno sei client come mostrato nel diagramma, alcuni si connetteranno al server 2 e altri al server 2. Esatto, questi tre sono connessi al server XNUMX e questi al server XNUMX.

Questo avviene automaticamente; il bilanciamento della connessione è qualcosa che è costruito internamente NCacheTutti i server sono attivi, ma ogni server ha una copia della cache. Quindi, qualunque dato si trovi sul server 1, una copia è presente sul server 2 e questa copia viene gestita tramite aggiornamenti di sincronizzazione. Quindi, qualunque aggiornamento si esegua su un server, deve essere applicato agli altri server tramite una chiamata di sincronizzazione e, con questo, intendiamo dire che il client attenderà il completamento dell'intera operazione. Se l'operazione fallisce su un server, l'intera operazione viene annullata. Ed è così che otteniamo una copia sincronizzata al 100% su tutti i server. Questo è molto positivo in termini di affidabilità, ma anche se si ha un caso d'uso intensivo in lettura, poiché si hanno più copie di dati o più copie da server diversi, con l'aumentare del numero di server la capacità di lettura aumenterà perché si hanno più server per gestire le richieste. Tuttavia, come avete appena notato, abbiamo un aggiornamento di sincronizzazione, quindi qualsiasi operazione di scrittura deve essere applicata a tutti i server. Quindi, è utile per configurazioni più piccole in termini di capacità di scrittura. Se si dispone di tre o quattro server, è necessario applicare la stessa operazione tre o quattro volte, il che può influire negativamente sull'aumento delle prestazioni. Pertanto, questa topologia è più consigliata per scenari di dati di riferimento, per configurazioni più piccole. È scalabile in lettura, non molto in scrittura, ma è molto affidabile. Garantisce elevata disponibilità e affidabilità dei dati, perché, in caso di perdita di un server, ad esempio il server 1, non si verificano perdite di dati o tempi di inattività, poiché queste applicazioni eseguiranno il failover e inizieranno a scegliere il server superstite, che dispone già di una copia della cache.

Cache partizionata e cache di replica delle partizioni

L'opzione successiva è quella di configurare una cache utilizzando una cache partizionata. La cache partizionata e la replica di partizioni sono le topologie più diffuse. La cache partizionata consente di distribuire i dati tra i nodi server disponibili. Ad esempio, se si hanno due server e si hanno dei dati, metà dei dati andrebbe sul server 1 e metà sul server 2. Anche la distribuzione dei dati fa parte di NCacheNon è qualcosa che fanno le tue applicazioni, ma viene fatto automaticamente dalle applicazioni in fase di esecuzione. Esiste una mappa di distribuzione intelligente e un algoritmo hash, che determina quali dati andranno a quale server.

In base a ciò, le applicazioni distribuiranno i dati in modo uniforme tra tutti i server del cluster di cache. Ora i dati sono distribuiti uniformemente, quindi anche il carico di richieste sarà distribuito uniformemente. Questo fornirà una maggiore capacità di lettura e scrittura in base al numero di server. Se si dispone di due server, si hanno due server che lavorano in team. E, se si passa da due a tre, si hanno più server che gestiscono le richieste di lettura e scrittura. Quindi, si ottiene una maggiore scalabilità per letture e scritture. Quindi, in modo lineare, si ottiene una maggiore scalabilità aggiungendo più server. Aggiungendo più server, si mettono in comune anche le risorse di memoria, poiché i dati sono distribuiti, quindi si raggruppa lo storage di tutti i server. Quindi, se si hanno due server, si ha una capacità di due server. Se si aggiunge un terzo o un quarto server, si aumenta la capacità di un numero di server maggiore. Quindi, la capacità complessiva viene messa in comune, quindi si ottiene una crescita lineare man mano che si aggiungono più server al cluster di cache.

Ottima per le letture, ottima per le scritture, molto scalabile sia per i dati di riferimento che per quelli transazionali. L'unico svantaggio di questa topologia è che non prevede alcun backup. Se si perde un server, si perde anche la relativa partizione. Quindi, quando ciò accade, è necessario disporre di un modo per ricostruire tali dati da un database back-end. Quindi, se l'obiettivo principale è raggiungere prestazioni elevate, se si tratta di un'applicazione incentrata sulle prestazioni, e ci si può permettere di tornare a un database, cosa che accade comunemente, non ci si affida a... NCache per un'elevata disponibilità e affidabilità dei dati, questa topologia ti garantirà le migliori prestazioni rispetto a tutte le altre.

Ma se hai bisogno di elevata disponibilità e sai che anche i requisiti di affidabilità dei dati devono essere soddisfatti NCacheHo una topologia migliore, chiamata cache di partizione della replica. 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, dove 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. Ed è possibile scegliere le opzioni di backup sincronizzato o asincrono. Se si sceglie la partizione della replica con asincrono, il client aggiornerà la partizione attiva e restituirà che le operazioni sul client sono state completate e quindi, NCache aggiornerà la partizione di backup in background. Se si sceglie la sincronizzazione, l'applicazione client aggiornerà la partizione attiva e quella di backup come operazione transazionale. In entrambi i casi, la sincronizzazione è ovviamente più affidabile, mentre quella asincrona è più veloce. Ma in entrambi i casi, NCache è in grado di gestire, sai, l'affidabilità dei dati in modo tale che, se un server si guasta, la topologia di backup si attiva e non si verificano perdite di dati o tempi di inattività delle applicazioni. Giusto.

Ora, lasciatemi mostrarvi rapidamente questa topologia con 3 server. In questo modo, otteniamo tutti i vantaggi di elevate prestazioni in lettura e in scrittura, nonché scalabilità lineare sia in lettura che in scrittura. Oltre a ciò, otteniamo scalabilità, elevata disponibilità e affidabilità dei dati. Se un server dovesse guastarsi, non ci saranno perdite di dati o tempi di inattività delle applicazioni.

Demo

Spero sia chiaro. Ora vi mostrerò il nostro ambiente demo e vi mostrerò rapidamente come costruire queste topologie di caching. Poi vi mostrerò anche come testare rapidamente un cluster di cache. Nel frattempo, fatemi sapere se avete domande. Bene, solo un breve promemoria: tutto ciò che vi mostriamo può essere utilizzato anche con voi, con sessioni di supporto tecnico e di supporto nei vostri ambienti, per i vostri casi d'uso specifici. Quindi, per tutto ciò di cui parleremo qui, anche dopo il webinar, saremo lieti di poter collaborare con voi, come team, per dimostrarvi come potrebbe funzionare per voi.

Per quanto riguarda le domande, ne ho una che mi è arrivata proprio alla fine. Una di queste è una delle vostre preferite.
Si è discusso molto sull'uso di Hazelcast per la memorizzazione nella cache delle applicazioni. Cosa fa NCache prevede che Hazelcast non lo faccia?

Ok. Prima di tutto, è più un dibattito. NCache è effettivamente scritto in .NET e .NET Core, quindi la piattaforma preferita per NCache è Windows. La cosa bella di NCache è che funziona su .NET, così come, sai, su Windows e Linux. Quindi, il supporto di piattaforma e compatibilità che NCache offre, non esiste nessun altro prodotto in grado di raggiungere questo risultato. Quindi, questo è il primo aspetto, in cui è la scelta più preferibile se si sta valutando la piattaforma che si intende utilizzare. L'altra differenza è che, e incoraggerei tutti a dare un'occhiata, sapete, al nostro pagine di confronto, anche lì troverete del materiale molto valido. Ma, per riassumere velocemente, NCache Il supporto per la memorizzazione nella cache degli oggetti offre numerose funzionalità, di cui altri prodotti sono completamente privi. Ad esempio, per la ricerca SQL, disponiamo di un elaborato set di funzionalità disponibili al suo interno. NCacheAbbiamo un caricatore di cache e un aggiornamento della cache. Queste sono funzionalità completamente esclusive di NCache. Il nostro gestore di lettura e scrittura con la capacità di eseguire codice .NET e .NET Core sul lato server, questa è una caratteristica assolutamente unica. NCache, e l'elenco continua, giusto. Quindi, alcune delle funzionalità che, sai, puoi personalizzare sul lato server. Sono disponibili solo in NCache e poi, dal punto di vista applicativo, ci sono molte funzionalità che mancano in altri prodotti. Quindi, consiglio a tutti di consultare la nostra pagina di confronto. Sono stati pubblicati alcuni confronti, funzionalità per funzionalità, che vi 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 possiamo andare. Per favore, continua. Certo.

Crea una nuova cache clusterizzata

Quindi, lasciatemi fare una rapida dimostrazione del prodotto creando una nuova cache clusterizzata. Chiamiamola cache di test. Bene, lasciatemi spostare questa parte qui, abbiate pazienza. Okay.

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

Proseguiamo e ti mostrerò quanto è facile configurare una cache utilizzando gli strumenti GUI. Questo è il nostro gestore web, ma puoi ottenere tutto ciò che desideri anche utilizzando i nostri cmdlet di PowerShell e, se necessario, puoi automatizzare anche questa distribuzione. Aggiungerò il server uno, dove NCache è installato. Aggiungerò quindi il server 2. Quindi, le mie 2 caselle con NCache con una dimensione di 2 GB sarà, sai, configurato. Quindi, la mia idea qui è quella di creare un cluster di cache a 2 nodi utilizzando 2 GB di cache ciascuno. Quindi, un totale di quattro GB con 2 server dove NCache è già installato. Quindi, userò il mio box per connettermi a questo cluster di cache.

Parametri TCP. Questa è la porta che devi impostare una volta fatto questo. Lasciala predefinita o specifica una porta qualsiasi su cui il firewall non abbia alcun impatto.

Se devi impostare crittografia e compressione, questa è la schermata. La lascerò così com'è. Scegli Avanti. Le espulsioni, se la cache si riempie, sono una cosa che puoi scegliere. Un'opzione è che la cache semplicemente non accetti operazioni di scrittura. Ti darà un errore, "cache piena". Un'altra opzione è che imposti l'espulsione e, in base a questi algoritmi, rimuoverà alcuni elementi dalla cache in fase di esecuzione. Quindi, in base alla priorità, all'utilizzo, gli elementi meno recenti o utilizzati di frequente possono essere rimossi e il cinque percento degli elementi verrà rimosso dalla cache. Avvierò questa cache al termine e con avvio automatico, in modo che ogni volta che il mio server si riavvia o NCache il server si riavvia, è in grado di riavviare le cache che sono state arrestate.

Seleziono "Fine" e il gioco è fatto. È così facile configurare un cluster di cache. Tra poco, mi mostrerà un'altra schermata, dove verrà avviata questa cache, e poi vi mostrerò alcuni dettagli di monitoraggio e gestione da lì. Sono disponibili video più dettagliati sulle configurazioni delle cache, quindi se ce ne sono, se avete domande, fatemelo sapere ora, oppure possiamo, sapete, fare affidamento anche su quei video.

Posso selezionare e scegliere "monitora cluster" e si aprirà un'altra dashboard che mi permetterà di monitorare completamente la mia cache. Mi mostra un cluster di cache completamente connesso, contatori di throughput delle richieste, contatori di latenza e contatori di aggiunte, recuperi e aggiornamenti. Allo stesso modo, mi mostra l'utilizzo di CPU e memoria e le situazioni di cache piena.

Ho anche dashboard per il client, così come una vista report, dove vediamo dashboard lato server e lato client. Al momento non c'è alcuna applicazione connessa, ma c'è un modo per simulare un carico usando questo pulsante test-stress. Quindi, posso avviare un carico fittizio, o un'attività sul mio cluster di cache chiamando questo test-stress. Non appena lo farò, vedrete che un client è connesso e, questa topologia richiede che i miei dati siano distribuiti, giusto? Quindi, alcuni dati andranno sul server 1 e altri sul 2. Quindi, questo client utilizza entrambi i server in modo uniforme. Come potete vedere, le richieste arrivano a entrambi i server e la dimensione della cache aumenta su entrambi i server.

Abbiamo anche partizioni attive e di backup visualizzate su entrambi i server. E se vi mostro rapidamente i contatori di latenza, si tratta di latenze inferiori al millisecondo, persino al 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à ne abbiamo ricevute un paio, quindi una di queste è:
Qual è il tuo consiglio per l'espulsione? E, se si tratta almeno dell'espulsione, aspetta un attimo: la prossima domanda è: se l'espulsione è disattivata, possiamo aumentare o diminuire la dimensione della cache?

Certo. Quindi, sai, l'espulsione è qualcosa che deve essere impostato in base al tuo caso d'uso, giusto. Se i dati sono qualcosa che puoi permetterti di espellere, giusto. L'espulsione stessa rimuoverà alcuni dati se la cache si riempie. La situazione ideale è che non devi mai farlo e la cache è ben al di sotto della capacità, giusto. Quindi, assegni alla cache una dimensione o una memoria sufficienti in modo che non si riempia mai. Ma, nei casi in cui accade, sai, arrivi a un punto in cui si riempie. In tal caso, se i tuoi dati sono qualcosa che puoi sempre ricostruire da un database back-end, è consigliabile attivare le espulsioni. Ad esempio, per le sessioni ASP.NET, non consigliamo di attivare le espulsioni, perché rimuoveresti alcuni utenti per fare spazio ai nuovi utenti, e tutti gli utenti hanno i loro dati importanti, giusto. Quindi, sono dati che non vorresti perdere in nessun caso. Quindi, per questi scenari, ti consigliamo di aumentare le dimensioni della cache. Pianifica le dimensioni della cache in modo che siano sufficientemente grandi e, nei casi in cui si riempiano NCache Permette di modificare la dimensione della cache in fase di esecuzione. È possibile modificarla, e in base a ciò è possibile aumentare e quindi salvare queste impostazioni su una cache in esecuzione. Quindi, è altamente applicabile e aumenterà la dimensione della cache in fase di esecuzione.

Altre domande? Sembra che questa sia la risposta, e ne terrò un paio per la fine, così potrai completare la dimostrazione. Certo. Quindi, tornando al mio ambiente demo, sai, 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, è disponibile anche su GitHub, quindi se cerchi NCache Su GitHub puoi trovare alcuni esempi, e ne ho estratto uno da lì. Quindi, quello che devi fare veramente all'interno della tua applicazione è includere questo pacchetto NuGet che è Alachisoft.NCache.Sdke se sei interessato a memorizzazione nella cache dei dati dell'appQuesto è l'esempio che dovresti prendere in considerazione. E, in base a questo, una volta aggiunto, puoi includere alcune risorse all'interno dell'applicazione.

Questo includerà già alcune, sai, librerie di NCache, come parte di questo nuovo pacchetto NuGet. E poi includi questo riferimento usando Alachisoft.NCache.Cliente. Aggiungi anche Runtime.CachingGiusto, e in base a questo 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. Entriamoci dentro. Abbi pazienza. Sto avendo difficoltà. Comunque, per qualche motivo, non riesco ad entrare dentro, credo ci sia un problema con la casella stessa. Comunque, le API sono piuttosto intuitive. Lascia che ti mostri dal nostro PowerPoint. Questo esempio lo usa effettivamente, non sono in grado di dimostrarlo perché non riesco a entrare nel codice. Non me lo permette.

Quindi, questo è un handle della cache e questo è il pezzo di codice che volevo mostrare, che il CacheManager.GetCache ti permetterà di connetterti alla cache. Quindi puoi chiamare cache.Get per ottenere effettivamente dati dalla cache. Allo stesso modo, puoi chiamare cache.Aggiungi or cache.AddAsync per aggiungere qualsiasi record nella cache e inserirlo in modo simile come in upsert dove aggiunge, così come aggiorna i dati nella cache e in modo simile, puoi chiamare cache.Rimuovi.

Così questo campione È disponibile un programma che puoi scaricare ed eseguire sulla tua cache. Tutto quello che devi fare è puntare alla cache da un'applicazione. Ci sono diverse configurazioni. Puoi specificare il nome della cache e l'IP in linea, oppure puoi affidarti a un client.ncconf, che questo pacchetto NuGet include nel progetto. Quindi, se ti mostro velocemente alcune risorse, vedi, molti file sono stati effettivamente aggiunti, e questo file qui è un file che ti permette di connetterti alla cache. Quindi, è già in grado di connettersi alla mia "democache". Se lo eseguo, eseguirà alcune attività sulla mia cache e avvierà le operazioni di caching.

Allo stesso modo, ho un altro campione che darà, sai, altre opzioni, ad esempio, c'era una domanda su cercando dentro NCacheGiusto. Quindi, ti consiglio di usare questo esempio qui. Questo è per la ricerca SQL. È stato scaricato da GitHub e, ancora una volta, usa la ricerca, usa, ha dati di esempio e poi chiama la ricerca usando SQL. E ha un sacco di funzionalità proprio qui, sempre sulla stessa linea, gli esempi sono piuttosto intuitivi. Puoi inserire elementi e poi puoi eseguire query usando i tag nome, puoi eseguire query, sai, query usando indici o proiezioni definiti.

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

Cache cliente

C'era un'altra domanda su Cache cliente, quindi questa topologia è anche un'opzione senza modifiche al codice. Tutti i dati memorizzati nella cache da un database all'interno NCache, è possibile memorizzarlo ulteriormente nella cache utilizzando la cache client. Si tratta di una cache sovrapposta a un'altra cache. Funziona senza alcuna modifica al codice. È una cache sincronizzata con una cache clusterizzata, quindi non ci sono problemi di coerenza dei dati. La sincronizzazione viene eseguita da NCacheTutti gli aggiornamenti effettuati su una cache client vengono propagati obbligatoriamente alla cache cluster, che a sua volta li propaga alle altre cache client, dove gestisce tutta la sincronizzazione. Per scenari di dati di riferimento in cui non si verificano molte scritture, questa è un'opzione altamente consigliata.

Replica WAN

Analogamente, NCache ha anche un Replica WANDisponiamo di topologie attive-passive e attive-attive. Pertanto, tutti i dati della cache possono essere replicati da un data center all'altro tramite la nostra cache bridge. Il backup del bridge stesso avviene su un server attivo-passivo, quindi si dispone di una cache di origine e di una cache di destinazione, con replica unidirezionale o migrazione est-ovest dei dati da un data center all'altro per scenari di disaster recovery o per la migrazione est-ovest, oppure per situazioni in cui sono necessari dati da un'applicazione e devono essere utilizzati per l'applicazione di destinazione. In questo modo, è possibile trasferire interi dati della cache da un data center all'altro.

L'altra opzione è attiva-attiva. In questo caso, entrambi i siti sono attivi, quindi il sito uno trasferisce dati al sito due e il sito due trasferisce dati al sito uno. Anche in questo caso, non è richiesta alcuna modifica del codice. È solo una questione di configurazione. Una volta configurato il bridge, si collegano due cache insieme e NCache prende il sopravvento e inizia la replicazione dei dati tra quelle cache.

E questo si estende anche alla topologia multi-attivo-attivo, quindi non è necessario che ci siano solo due siti, potrebbero esserci tre, quattro o cinque siti in cui tutti i siti trasferiscono dati tra loro. Quindi, NCacheLa capacità di sincronizzare effettivamente i dati da tutti i siti, contemporaneamente. E, a proposito, questo avviene in modo asincrono, quindi il costo della replica non viene nuovamente sostenuto dall'applicazione o dall'utente. Viene eseguito a livello di applicazione. Le applicazioni client sono connesse qui e qui. Non subiscono alcun degrado delle prestazioni a causa di questa replica WAN. Viene eseguita dietro le quinte da NCacheFatemi sapere se avete domande. Concludiamo qui la presentazione e le funzionalità. Zack, fatemi sapere se avete domande.

Sì, ne abbiamo un paio. E apprezzo molto la vostra pazienza, quindi questo è anche il momento giusto per porre altre domande, se ve ne siete chiesti durante la presentazione. Quindi, iniziamo con una.
Come si fa a verificare se la cache funziona correttamente? Riceviamo notifiche, ecc.? Come facciamo a sapere se c'è un problema?

Certo. Abbiamo strumenti di monitoraggio e gestioneQuindi, una cosa potrebbe essere ispezionare visivamente e vedere lo stato di salute del cluster. Vedi l'utilizzo della CPU e della RAM. Se conosci la tua base di riferimento, quante richieste generano le tue applicazioni e qual è l'utilizzo tipico di NCache Sulla base di questi contatori, è possibile effettuare ispezioni visive utilizzando le nostre dashboard di monitoraggio e gestione. Inoltre, abbiamo avvisi per qualsiasi situazione, ad esempio quando si avvia una cache, si arresta una cache, un nodo si unisce, si abbandona, la dimensione della cache si riempie o il cluster entra in uno stato non funzionante, come ad esempio in caso di split brain. Abbiamo avvisi che registriamo nei registri eventi di Windows. È anche possibile impostare avvisi e-mail da NCachee può anche generare un'e-mail per te. Quindi, questo sarà un monitoraggio proattivo, un avviso da NCacheDurante la serata, NCache ti avviserà e potrai intraprendere azioni in base a ciò. Inoltre, abbiamo dati storici acquisiti sotto forma di registri dei contatori PerfMon e registri della cache. Per quelle situazioni in cui non sapevi cosa fosse andato storto e hai riscontrato alcuni problemi con NCache, possiamo venire e partecipare, e possiamo rivedere NCache log e, in tal caso, effettuare una valutazione dello stato di salute della cache. Quindi, ci sono molte strade che possiamo esplorare a questo proposito.

Sembra una buona idea. Un'altra domanda è:
Qual è l'ultima versione di .NET che NCache attualmente supporta i clienti?

Okay. In genere, tendiamo a utilizzare l'ultima versione del framework .NET, .NET Core. .NET 6 è attualmente supportato, che è un prerequisito per NCache. È necessario avere .NET 6 come elemento obbligatorio NCache server. Ma le tue applicazioni possono essere su qualsiasi framework .NET, credo dalla versione 3.5 in poi, 4.0, 4.5 o anche 4.7, 4.8. Le tue applicazioni possono essere su qualsiasi framework .NET o .NET Core. È solo una limitazione lato server. E, non appena la compatibilità con un framework più recente viene testata, ad esempio per .NET 7, lo stiamo già testando nel nostro laboratorio di controllo qualità. Quindi, una volta che avremo l'approvazione, rilasceremo anche il supporto ufficiale.

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

Va bene. Prima di tutto, NCache Non impone alcun limite al numero di cache configurabili. Infatti, se si guarda il mio ambiente demo, ho due cache configurate. Quindi, è possibile crearne quante ne servono. Tuttavia, esiste una raccomandazione tecnica o relativa alla capacità che in genere consigliamo in un ambiente di produzione di non superare le quattro o cinque cache. Poiché ogni cache è un cluster di cache separato, consumerà effettivamente tutte le risorse per l'archiviazione, il clustering e la comunicazione, con conseguente sovraccarico di gestione del cluster. Quindi, all'aumentare del numero di cache, si introduce di fatto un problema di capacità in quell'ambiente, o al suo interno. Pertanto, consigliamo di mantenerlo, se possibile, entro quattro o cinque. In una situazione in cui è necessario disporre di più cache, è possibile estenderlo fino a 10. Ma, come ho detto, si tratta ancora una volta di una raccomandazione. Non esiste un limite effettivo che lo imponga. È una raccomandazione di carattere generale da parte nostra.

Ok. Vorrei solo aggiungere un'ultima cosa, dato che so che siamo alla fine della sessione e che c'è gente che ha altre cose da fare sul Docker.
Può NCache fornire la replica DR?

Sì, è così. La funzionalità di replica WAN di cui ho appena parlato, l'ultima topologia, copre il DR, il disaster recovery. I siti possono essere trasmessi con i dati dal sito attivo, quindi si avrebbe un sito DR completamente sottoposto a backup. Basta semplicemente effettuare lo switch sul lato applicazione. Poiché tutti i dati sono già sottoposti a backup, non si verifica alcuna perdita di dati in caso di guasto completo di un data center o di necessità di disattivarlo per manutenzione.

Bene. Penso che ne abbiamo centrati il ​​più possibile. Signore e signori, sappiate che siamo disponibili anche al di fuori di queste sessioni. Siamo molto lieti di lavorare con voi, fianco a fianco, quando si tratta di analizzare le vostre configurazioni esistenti, se siete già utenti di NCacheSe sei nuovo a NCache, saremo lieti di offrirti una prova gratuita e di organizzare sessioni di supporto per spiegarti come funzionerà nelle tue applicazioni integrate, ma soprattutto, sappi che puoi contattarci in qualsiasi momento per qualsiasi domanda su NCache, o anche come utilizzare il prodotto e se hai bisogno di aiuto. Abbiamo un sacco di novità in arrivo, anche nuove versioni, quindi, restate sintonizzati e presto pubblicheremo altri webinar di questo tipo.

Un applauso a Ron. Apprezzo molto il fatto che tu abbia trovato il tempo per una sessione oggi e non vedo l'ora della prossima. Grazie a tutti. Grazie, Zack. Certo. Va bene, a tutti. Vi auguro una splendida giornata e non vediamo l'ora di rivedervi al nostro prossimo webinar. E solo una precisazione: al termine di questo webinar, ne pubblicheremo una registrazione sul nostro sito web, una volta ultimato tutto. Quindi, se non avete avuto modo di rispondere a qualche domanda, se desiderate rivedere uno dei punti che abbiamo trattato, non esitate a visitare nuovamente il nostro sito web e a rivedere la registrazione del webinar.

Bene, allora. Un saluto a tutti. Buona giornata. Grazie, ragazzi. Ciao, ciao.

Cosa fare dopo?

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