La memorizzazione nella cache distribuita è stata riconosciuta come una parte importante e integrante delle applicazioni Web .NET ad alte prestazioni. Ciò vale per le applicazioni degli utenti finali che richiedono tempi di risposta rapidi dai servizi di livello intermedio o dai componenti Web distribuiti. Per questi motivi, Microsoft ha introdotto AppFabric, una cache distribuita in memoria, per fornire un aumento delle prestazioni e della scalabilità per le applicazioni che utilizzano .NET Framework.
AppFabric la memorizzazione nella cache è stata utilizzata principalmente per archiviare i dati sullo stato della sessione ASP.NET e per fornire funzionalità di memorizzazione nella cache degli oggetti di base. Ma anche se la memorizzazione nella cache è parte integrante di qualsiasi sistema N-Tier, Microsoft l'ha scritto sul blog AppFabric il supporto finisce dall'11 aprile 2017 per tutte le versioni. Questo è un buon incentivo per l'impiego di stack .NET AppFabric per passare a una cache migliore, supportata e distribuita.
Quindi, cosa supporta la fine in realtà significa? Significa:
Pertanto, significa che utilizzerai AppFabric a tuo rischio. Microsoft non sarà responsabile per incidenti o bug. Per questo motivo dobbiamo valutare se le operazioni aziendali possono sostenere tempi di inattività a causa di un bug senza una rapida risoluzione.
Tali domande possono guidarti verso alternative. Se sei pronto per un'alternativa, ce n'è una che fornisce la migrazione senza interruzioni dalla tua configurazione attuale a una cache distribuita .NET con modifiche minime al codice, quindi non introduce alcun bug. Questa cache distribuita alternativa non solo supporta la migrazione senza interruzioni, ma è anche più veloce e fornisce più funzionalità di AppFabric.
NCache è una scelta forte come alternativa. Microsoft infatti consigliato NCache a loro annuncio finale AppFabric supporto. NCache ha guadagnato questa raccomandazione poiché è ampiamente utilizzato all'interno della comunità .NET ed è stato il leader di mercato nella memorizzazione nella cache distribuita .NET per 10 anni consecutivi. NCache fornisce prestazioni eccezionali insieme a un'ampia gamma di funzionalità tra cui:
Altri benefici di NCache include facilità d'uso (è valutato da una società di analisi leader come la cache distribuita più facile da usare) solide capacità di gestione e monitoraggio attraverso i suoi strumenti GUI appositamente creati ed è disponibile come Open Source (su GitHub) con costi praticamente zero prima e dopo la migrazione. Open Source e la versione Enterprise, con supporto ufficiale, sono disponibili on premise e nel cloud (Amazon Web Services e Azure).
Mentre Redis è una buona cache in memoria, il Redis la comunità lo osserva Redis non è pronto per Windows, nonostante la disponibilità di a Redis Porta Windows. Redis non è completamente scalabile né offre funzionalità di alta disponibilità. Redis' il set di strumenti di monitoraggio e gestione è solo CLI. NCache offre molti vantaggi rispetto Redis come mostrato in questo collegamento video (e questa condivisione diapositiva guida intelligente) Compreso.
Per soddisfare le esigenze di qualsiasi ambiente operativo, NCache fornisce tre modi per migrare le applicazioni .NET da AppFabric a NCache; ogni metodo ha il proprio insieme di vantaggi.
I tre metodi di migrazione sono:
NCache AppFabric I wrapper offrono una migrazione più agevole e senza interruzioni, ma la migrazione tramite chiamate API dirette fornisce un maggiore controllo e ti consente di sfruttare tutte le funzionalità di NCache.
Per quelle organizzazioni che cercano la transizione più semplice e veloce da AppFabric, questo wrapper fornisce la migrazione più semplice di sempre. Sono necessarie solo tre modifiche minori nell'applicazione .NET per farlo NCache conforme senza introdurre alcun possibile bug. Queste modifiche sono:
<appSettings>
<add key="region1" value="myPartitionedCache"/>
<add key="Expirable" value="True"/>
<add key="TTL" value="5"/>
</appSettings>using Microsoft.ApplicationServer.Caching.Client;
using Microsoft.ApplicationServer.Caching.core;
con:
using Alachisoft.NCache.Data.Caching;E questo è tutto! Non sono necessarie altre modifiche al codice all'interno dell'applicazione .NET.
utilizzando NCache Open Source ti permette di migrare da AppFabric senza costi poiché entrambi i prodotti sono gratuiti. NCache Open Source ha un set di funzionalità più limitato rispetto all'edizione Enterprise, ma senza alcun degrado nelle prestazioni della cache principale.
Per facilitare la migrazione, una versione separata di AppFabric è previsto un involucro NCache OSS, che è compatibile con l'API open source. Date meno funzionalità in NCache Open Source, le NCache Open Source wrapper funziona attorno alle funzionalità mancanti che includono:
I NCache Open Source involucro per AppFabric supera la sfida di mantenere il controllo delle versioni degli elementi incapsulando ogni oggetto all'interno di un'altra classe. Questo viene fatto introducendo una nuova classe denominata MetaDataCapsule nel wrapper modificato.
namespace Alachisoft.NCache.Data.Caching.Util
{
[Serializable]
class MetaDataCapsule
{
private object value;
public ItemVersion CacheItemVersion { get; set; }
public string Group { get; set; }
public object Value { get { return this.value; } }
private MetaDataCapsule(object value, ItemVersion version, string group)
{
this.CacheItemVersion = version;
this.Group = group;
this.value = value;
}
public static MetaDataCapsule Encapsulate(object value, string region)
{
return new MetaDataCapsule(value, 1, region);
}
}
}Questo aiuta a mantenere la versione dell'oggetto di un oggetto e trasportare altre informazioni utili, se necessario. La classe è contrassegnata come serializzabile poiché deve viaggiare sulla rete.
Per garantire la versione dell'oggetto e la coerenza dell'oggetto in tutte le istanze multiple di applicazioni diverse o simili, viene utilizzato il blocco distribuito. Il blocco distribuito è una caratteristica di NCache che consente a più applicazioni di accedere e modificare la stessa risorsa senza compromettere la coerenza dei dati ed evitare possibili condizioni di gara.
LockHandle lockhandle = null;
MetaDataCapsule oldMetadata;
bool lockAcquired = GetLock(_key, ref lockhandle, out oldMetadata);
if(!lockAcquired)
{
_NCache.Unlock(key);
throw new DataCacheException("Unable to acqurie lock to update Item Version");
}
//Return in case of version provided
if (oldVersion != null && oldMetadata.CacheItemVersion == oldVersion._itemVersion)
{
_NCache.Unlock(key);
return null;
}
if (lockAcquired)
(_item.Value as MetaDataCapsule).CacheItemVersion = ++metadata.CacheItemVersion;
_NCache.Insert(_key, _item, lockhandle, true);In sintesi, su ogni operazione Put:
Il blocco nello scenario precedente garantirà che nessun'altra applicazione possa aggiornare o rimuovere l'elemento se un'altra applicazione sta tentando di modificare la stessa chiave.
Nel codice precedente è presente un metodo denominato GetLock, l'implementazione è la seguente.
// <summary>
// Tries to acqurie lock and return LockHandle and MetaDataCapsule object.
// If LockHandle is provided uses that instead.
// <para>Default Lock Timeout (default 5 seconds), Retry Count (default 3)
// and retry interval (default 100 ms) is set when Cache Handler is instantiated.
// </para>
// </summary>
// <param name="key">Formatted Key i.e compile from formatter</param>
// <param name="lockHandle">Either provide a lock or keep it null to acquire a new lock
// </param>
// <param name="metadata">The returned object for internal use</param>
// <returns>true if lock was acquired</returns>
internal bool GetLock(string key, ref LockHandle lockHandle,
out MetaDataCapsule metadata)
{
//Item is locked
int count = _retries;
while (count != 0)
{
//If lock was provided attempt to acquire the lock from the given handle
if (lockHandle == null)
{
lockHandle = new LockHandle();
}
object obj = _NCache.Get(key, _defaultLockTime, ref lockHandle, true);
//obj is null of the lock was not acquired
if (obj == null)
{
count--;
Thread.Sleep(_retryTimeOut);
}
else
{
metadata = obj as MetaDataCapsule;
return true;
}
}
lockHandle = null;
metadata = null;
return false;
}Il metodo GetLock tenterà di acquisire il blocco tre volte. In caso contrario, restituirà "null" consentendo al metodo chiamante di gestire questa eccezione. Così, con l'aiuto del Distributed Locking, il AppFabric involucro per NCache Open Source mantiene la versione dell'elemento della cache inserita dalle applicazioni client, inclusi i casi di eccezione.
A causa della mancanza di alcune funzionalità aziendali nell'edizione open source, le seguenti funzioni sono contrassegnate come "obsolete" e contrassegnate con "genera errore di compilazione" per garantire una modifica del codice ed evitare sorprese.
Pertanto, se l'applicazione dipende fortemente da queste funzionalità, selezionare NCache Enterprise la versione potrebbe essere l'opzione migliore per consentire una migrazione più fluida, senza interruzioni e senza bug.
Per gli sviluppatori che vogliono sfruttare appieno molti NCache Enterprise caratteristiche, potresti preferire chiamare direttamente il NCache API invece di usare il wrapper. Puoi anche usare il "metodo di scarto" da AppFabric wrapper con cui lavorare direttamente NCache come pure.
In ogni caso, si consiglia di eseguire la migrazione in due fasi. Nella fase 1, continua a utilizzare il tuo AppFabric funzionalità, ma sostituisci la cache con NCache. Nella fase 2, implementare ulteriori, nuovi NCache funzionalità che non erano disponibili in AppFabric.
In questa fase il tuo obiettivo è solo quello di sostituire AppFabric. Pertanto, è importante capire come si comportano queste due cache distribuite (vedi maggiori dettagli di seguito e in sezione di riferimento alla fine). Come accennato, AppFabric memorizza i dati in regioni su macchine specifiche. D'altra parte, per replicare i dati della tua regione in NCache puoi creare una cache per ogni AppFabric regione, oppure puoi creare NCache gruppi da tenere AppFabric dati della regione.
NCache Gruppi/Sottogruppi fornisce vari modi per raggruppare gli elementi memorizzati nella cache. Poiché le regioni risiedono all'interno di una cache denominata, NCache utilizza i gruppi per riprodurre questo comportamento. L'unica differenza è che dentro AppFabric una chiave deve essere univoca solo all'interno di una regione e non all'interno dell'intera cache denominata. Mentre in NCache, la chiave deve essere univoca nell'intera cache e non importa a quale gruppo appartenga. Questo ostacolo può essere rapidamente superato se i nomi delle regioni sono preceduti da ogni chiave.
Per esempio:
In AppFabric, un'operazione di aggiunta di base è simile alla seguente:
// AppFabric API
regionCache.Add(stringKey, stringValue);E in NCache il comando di base non è diverso, tranne per il fatto che il nome di una regione può essere specificato come gruppo nel comando:
// NCache API
cacheInstance.Add(regionName + ":" + stringKey, stringValue, regionName);
// Where regionName is as Group
Qui, ogni chiave è anteposta al nome della regione per ottenere l'unicità tra le chiavi della cache. Un gruppo viene assegnato alla chiave per un recupero più rapido o per facilitare il recupero dei dati utilizzando query SQL durante l'esecuzione di operazioni di ricerca.
L'altro modo per raggruppare gli elementi memorizzati nella cache consiste nell'eliminare completamente la correlazione da regione a gruppo e utilizzare una cache separata per ogni regione. Per ottenere lo stesso risultato, dove ad ogni regione viene assegnata una cache separata, è possibile memorizzare una mappa dei nomi delle regioni corrispondenti alle cache.
// NCache API
cacheInstance = map.get(regionName);
cacheInstance.Add(stringKey, stringValue);In questo esempio, non è necessario anteporre la chiave della regione alla chiave della cache poiché viene memorizzata nella cache NCache si escludono a vicenda anche se risiedono nello stesso cluster.
Se la tua applicazione deve gestire molte regioni (ad es. più di 15), è meglio utilizzare le regioni come gruppi poiché 15 cache per cluster è un numero massimo consigliato di cache (anche se un cluster può ospitare logicamente un numero infinito di cache) .
Nella fase successiva, puoi sfruttare le funzionalità che NCache fornisce quale AppFabric ed Redis la mancanza. Funzionalità come:
La sincronizzazione del database è una caratteristica molto importante per qualsiasi buona cache distribuita. Poiché la maggior parte dei dati memorizzati nella cache proviene da un database relazionale, ci sono sempre situazioni in cui altre applicazioni o utenti potrebbero modificare i dati e far sì che i dati memorizzati nella cache diventino obsoleti.
Le applicazioni spesso vogliono recuperare un sottoinsieme di questi dati e se possono cercare nella cache distribuita con un linguaggio di query simile a SQL e specificare gli attributi degli oggetti come parte dei criteri, la cache distribuita è molto più utile per loro.
Molte persone usano la cache distribuita come "cache laterale" in cui recuperano i dati direttamente dal database e li mettono nella cache. Un altro approccio è il "cache through" in cui l'applicazione richiede semplicemente i dati alla cache. E, se i dati non sono presenti, la cache distribuita li ottiene dall'origine dati. La stessa cosa vale per la scrittura.
Insieme a questo, NCache supporta anche MapReduce che abilita Big Data Analytics nei dati in memoria, producendo risultati quasi in tempo reale.
La cache del client è semplicemente una cache InProc/OutProc locale sulla macchina client, ma che rimane connessa e sincronizzata con il cluster di cache distribuita. In questo modo, le prestazioni delle applicazioni beneficiano davvero di questa "vicinanza" senza compromettere l'integrità dei dati.
La replica WAN è una caratteristica importante per molte applicazioni distribuite in più data center per scopi di ripristino di emergenza o per il bilanciamento del carico del traffico regionale.
L'idea alla base della replica WAN è che non deve rallentare la cache in ciascuna posizione geografica a causa dell'elevata latenza della WAN. NCache fornisce Bridge Topology per gestire tutto questo.
Supporto per Microsoft AppFabric termina ad aprile 2017. Questo white paper presenta tre possibili modi per migrare le applicazioni .NET da AppFabric a NCachee i vantaggi di apportare questa modifica. NCache è una cache .NET stabile, completa e distribuita disponibile come Open Source in Azure e Amazon Web Services, nonché sul NCache sito web. È disponibile anche il supporto completo.
Utilizzando il free NCache AppFabric involucro per entrambi NCache Open Source or NCache Enterprise, offre il metodo di migrazione più semplice, senza codifica e senza bug. Migrazione chiamando direttamente il NCache L'API fornisce un maggiore controllo dei dati e abilita tutto NCache caratteristiche. Tutti i metodi di migrazione sono descritti in questo whitepaper.
Controlla queste risorse aggiuntive per soddisfare le tue esigenze di valutazione e prodotto.
Regioni in AppFabric sono contenitori logici di coppie chiave-valore archiviate in un'istanza di una cache, che è collegata a una macchina server. Per questo motivo, i dati all'interno delle regioni non possono essere distribuiti. Questa struttura architettonica afferma di consentire recuperi più rapidi. Ma riduce significativamente le prestazioni complessive rispetto a una cache distribuita.
NCache è una cache distribuita al suo interno. Tutti i dati all'interno NCache viene distribuito e una copia di backup viene conservata in un'altra macchina fisica se il Replica di partizione Viene utilizzata la topologia (PR). PR offre prestazioni di livello mondiale, prestazioni super veloci e repliche di failover per zero perdite di dati.
Pertanto, le regioni in AppFabric sono configurati come cache separate in NCache senza compromettere la capacità di recupero dei dati. Il AppFabric wrapper assume questa complessità e memorizza automaticamente tutti i dati della regione nel nome della cache fornito. L'unico requisito è che venga memorizzato nella cache NCache dovrebbe preesistere. Crei cache tramite NCache direttore, uno strumento di gestione dei cluster basato su GUI. Una volta create le cache, i dati risiedono AppFabric le regioni sono distribuite a quelle specificate NCache grappolo/i. Nonostante i dati siano realmente distribuiti, non vi è alcun compromesso nella tua capacità di eseguire ricerche avanzate, comprese le query SQL (le query SQL non sono disponibili con AppFabric affatto).
L'altra notevole differenza tra NCache ed AppFabric è il modo in cui sono configurati entrambi i prodotti. AppFabric è configurato dall'applicazione in fase di esecuzione (anche la creazione della cache) e in contrasto NCache viene configurato prima dell'avvio della cache. Ad esempio, le topologie della cache non possono essere modificate in fase di esecuzione, mentre altre configurazioni, ad esempio le scadenze predefinite della cache, ecc., possono essere modificate in un secondo momento e sono chiamate hotapply-able. Nonostante NCache può essere gestito utilizzando l'applicazione .NET (compresa la creazione della cache) ma è preferibile gestire dal NCache Manager - Un unico strumento dedicato per la gestione dei cluster di cache. È anche possibile creare, configurare e mantenere una cache dalla CLI.
Mentre NCache AppFabric-wrapper fornisce il modo più semplice per migrare le applicazioni .NET NCache, che è anche con il minor numero di modifiche al codice possibili, alcuni sviluppatori preferiscono ancora sfruttare tutte le funzionalità che NCache deve offrire. Ecco dove chiamare direttamente il NCache L'API aiuta. C'è anche la possibilità di utilizzare entrambi i metodi chiamando il metodo Unwrap da AppFabric involucro.
I AppFabric cluster non è completamente dinamico. Dipendenza da "regola della maggioranza degli host principali" significa che il cluster può andare giù molto facilmente se anche un host principale va giù. Questi nodi host principali assomigliano anche all'architettura "master" e "slave" e quindi non sono completamente peer to peer.
NCache mentre è altamente dinamico e ti consente di aggiungere o rimuovere server di cache in fase di esecuzione senza alcuna interruzione della cache o della tua applicazione. I dati vengono ribilanciati automaticamente (chiamato trasferimento di stato) in fase di esecuzione senza alcuna interruzione o degrado delle prestazioni. NCache i client continuano a comunicare con i server cache, indipendentemente dallo stato del server. I cluster garantiscono l'esecuzione delle operazioni client anche quando è in corso il bilanciamento dei dati.
Ciò significa che anche per NCache, non sono presenti nodi "master" o "slave" nel cluster. C'è un nodo "coordinatore primario" che è il nodo più anziano. E, se va giù, il prossimo nodo più anziano diventa automaticamente il coordinatore principale. Tutto ciò avviene senza alcuna interruzione delle operazioni del cliente.