Verteiltes Caching gilt als wichtiger und integraler Bestandteil leistungsstarker .NET-Webanwendungen. Dies gilt für Endbenutzeranwendungen, die eine schnelle Reaktionszeit von den bereitgestellten Middle-Tier-Diensten oder Webkomponenten erfordern. Aus diesen Gründen hat Microsoft eingeführt AppFabric, ein verteilter In-Memory-Cache, um eine Leistungs- und Skalierbarkeitssteigerung für Anwendungen bereitzustellen, die den verwenden .NET Framework.
AppFabric Caching wird hauptsächlich zum Speichern von ASP.NET-Sitzungsstatusdaten und zur Bereitstellung grundlegender Objekt-Caching-Funktionen verwendet. Aber obwohl Caching ein integraler Bestandteil jedes N-Tier-Systems ist, hat Microsoft darüber gebloggt AppFabric Die Unterstützung endet Stand 11. April 2017 für alle Versionen. Dies ist ein guter Anreiz für den Einsatz von .NET-Stacks AppFabric um zu einem besseren, unterstützten, verteilten Cache zu wechseln.
Was bedeutet also Endunterstützung? eigentlich gemein? Es bedeutet:
Daher bedeutet dies, dass Sie Folgendes verwenden werden AppFabric auf eigene Gefahr. Microsoft übernimmt keine Haftung für Pannen oder Fehler. Aus diesem Grund müssen wir bewerten, ob der Geschäftsbetrieb Ausfallzeiten aufgrund eines Fehlers ohne schnelle Lösung verkraften kann.
Solche Fragen können Sie zu Alternativen veranlassen. Wenn Sie für eine Alternative bereit sind, gibt es eine, die eine nahtlose Migration von Ihrem aktuellen Setup zu einem verteilten .NET-Cache mit minimalen Codeänderungen ermöglicht und somit überhaupt keine Fehler verursacht. Dieser alternative verteilte Cache unterstützt nicht nur eine nahtlose Migration, sondern ist auch schneller und bietet mehr Funktionen als AppFabric.
NCache ist eine gute Alternative. Microsoft hat es tatsächlich empfohlen NCache in ihrer Ankündigung Ende AppFabric unterstützen. NCache hat diese Empfehlung erhalten, da es in der .NET-Community häufig verwendet wird und Marktführer für verteiltes .NET-Caching ist 10 Jahre in Folge. NCache bietet außergewöhnliche Leistung zusammen mit einer breiten Palette von Funktionen, darunter:
Weitere Vorteile von NCache Dazu gehören Benutzerfreundlichkeit (es wird von einem führenden Analystenunternehmen als der am einfachsten zu verwendende verteilte Cache eingestuft), starke Verwaltungs- und Überwachungsfunktionen durch seine speziell entwickelten GUI-Tools und es ist praktisch kostenlos als Open Source (auf GitHub) verfügbar vor und nach der Migration. Open Source und die Enterprise-Version mit offiziellem Support sind vor Ort und in der Cloud (Amazon Web Services und Azure) verfügbar.
Während Redis ist ein guter In-Memory-Cache, der Redis Die Community nimmt das zur Kenntnis Redis ist nicht Windows-bereit, trotz der Verfügbarkeit von a Redis Windows-Port. Redis ist weder vollständig skalierbar noch bietet es Hochverfügbarkeitsfunktionen. Redis' Das Überwachungs- und Verwaltungstoolset ist nur CLI. NCache bietet viele Vorteile gegenüber Redis wie hier gezeigt Video-Link (und diese Folie teilen kluger Führer) einschließlich.
Um den Anforderungen jeder Betriebsumgebung gerecht zu werden, NCache bietet drei Möglichkeiten zur Migration von .NET-Anwendungen AppFabric zu NCache; Jede Methode hat ihre eigenen Vorteile.
Die drei Migrationsmethoden sind:
NCache AppFabric Wrapper bieten eine reibungslosere und nahtlosere Migration, aber die Migration über direkte API-Aufrufe bietet mehr Kontrolle und ermöglicht es Ihnen, alle Funktionen von zu nutzen NCache.
Für Organisationen, die den einfachsten und schnellsten Übergang suchen AppFabricDieser Wrapper bietet die einfachste Migration aller Zeiten. Dazu sind lediglich drei geringfügige Änderungen in der .NET-Anwendung erforderlich NCache konform, ohne dass irgendwelche möglichen Fehler auftreten. Diese Änderungen sind:
<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;
mit:
using Alachisoft.NCache.Data.Caching;Und das ist es! Innerhalb der .NET-Anwendung sind keine weiteren Codeänderungen erforderlich.
Die richtigen NCache Open Source ermöglicht Ihnen die Migration von AppFabric kostenlos, da beide Produkte kostenlos sind. NCache Open Source verfügt im Vergleich zur Enterprise-Edition über einen eingeschränkteren Funktionsumfang, jedoch ohne Einbußen bei der Kerncache-Leistung.
Um die Migration zu erleichtern, wird eine separate Version von bereitgestellt AppFabric Wrapper ist vorgesehen NCache OSS, das mit der Open-Source-API kompatibel ist. Angesichts weniger Funktionen in NCache Open Source, der NCache Open Source Wrapper umgeht die fehlenden Funktionen, darunter:
Das NCache Open Source Wrapper für AppFabric überwindet die Herausforderung der Aufrechterhaltung der Elementversionierung, indem jedes Objekt in einer anderen Klasse gekapselt wird. Dies geschieht durch die Einführung einer neuen Klasse namens MetaDataCapsule im geänderten Wrapper.
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);
}
}
}Dies hilft dabei, die Artikelversion eines Objekts zu verwalten und bei Bedarf weitere nützliche Informationen zu übertragen. Die Klasse ist als Serialisierbar gekennzeichnet, da sie über das Netzwerk übertragen werden muss.
Um die Konsistenz von Elementversionen und Objekten über alle Instanzen verschiedener oder ähnlicher Anwendungen hinweg sicherzustellen, wird verteiltes Sperren verwendet. Verteiltes Sperren ist eine Funktion von NCache Dadurch können mehrere Anwendungen auf dieselbe Ressource zugreifen und diese ändern, ohne die Datenkonsistenz zu beeinträchtigen und mögliche Race Conditions zu vermeiden.
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);Zusammenfassend gilt bei jeder Put-Operation Folgendes:
Durch das Sperren im obigen Szenario wird sichergestellt, dass keine andere Anwendung das Element aktualisieren oder entfernen kann, wenn eine andere Anwendung versucht, denselben Schlüssel zu ändern.
Im obigen Code gibt es eine Methode namens GetLock. Die Implementierung ist wie folgt.
// <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;
}Die GetLock-Methode versucht dreimal, die Sperre zu erhalten. Wenn dies fehlschlägt, wird „null“ zurückgegeben, sodass die aufrufende Methode diese Ausnahme behandeln kann. Mit Hilfe von Distributed Locking kann die AppFabric Wrapper für NCache Open Source Behält die von den Clientanwendungen eingefügte Cache-Elementversion bei, einschließlich Ausnahmefällen.
Aufgrund des Fehlens einiger Unternehmensfunktionen in der Open-Source-Edition werden die folgenden Funktionen als „veraltet“ und mit „Kompilierungsfehler auslösen“ gekennzeichnet, um eine Codeänderung sicherzustellen und Überraschungen zu vermeiden.
Wenn Ihre Anwendung daher stark von diesen Funktionen abhängt, wählen Sie NCache Enterprise Version könnte die beste Option sein, um eine reibungslosere, nahtlosere und fehlerfreie Migration zu ermöglichen.
Für Entwickler, die viele Vorteile voll ausschöpfen möchten NCache Enterprise Funktionen möchten Sie möglicherweise lieber direkt anrufen NCache API statt Verwendung des Wrappers. Sie können auch die „Unwrap-Methode“ aus dem verwenden AppFabric Wrapper, mit dem direkt gearbeitet werden kann NCache .
In jedem Fall wird empfohlen, die Migration in zwei Phasen durchzuführen. Verwenden Sie in Phase 1 weiterhin Ihr AppFabric Funktionen, aber ersetzen Sie Ihren Cache durch NCache. In Phase 2 weitere, neue implementieren NCache Funktionen, die in nicht verfügbar waren AppFabric.
In dieser Phase liegt Ihr Fokus nur auf dem Ersetzen AppFabric. Daher ist es wichtig zu verstehen, wie sich diese beiden verteilten Caches verhalten (weitere Einzelheiten finden Sie weiter unten und im Referenzteil Am Ende). Wie erwähnt, AppFabric speichert Daten in Regionen auf bestimmten Maschinen. Andererseits, um Ihre Regionsdaten zu replizieren NCache Sie können für jeden einen Cache erstellen AppFabric Region, oder Sie können erstellen NCache Gruppen zu halten AppFabric Regionsdaten.
NCache Gruppen/Untergruppen bieten verschiedene Möglichkeiten zum Gruppieren zwischengespeicherter Elemente. Da sich Regionen in einem benannten Cache befinden, NCache verwendet Gruppen, um dieses Verhalten zu reproduzieren. Der einzige Unterschied besteht darin, dass in AppFabric Ein Schlüssel muss nur innerhalb einer Region und nicht innerhalb des gesamten benannten Caches eindeutig sein. Während in NCache, muss der Schlüssel im gesamten Cache eindeutig sein und es spielt keine Rolle, zu welcher Gruppe er gehört. Dieses Hindernis kann schnell überwunden werden, wenn jedem Schlüssel Regionsnamen vorangestellt werden.
Beispielsweise:
In AppFabric, sieht ein einfacher Add-Vorgang wie folgt aus:
// AppFabric API
regionCache.Add(stringKey, stringValue);Und in NCache Der Basisbefehl ist nicht anders, außer dass im Befehl ein Regionsname als Gruppe angegeben werden könnte:
// NCache API
cacheInstance.Add(regionName + ":" + stringKey, stringValue, regionName);
// Where regionName is as Group
Hier wird jedem Schlüssel der Regionsname vorangestellt, um eine Eindeutigkeit unter den Cache-Schlüsseln zu erreichen. Dem Schlüssel wird eine Gruppe zugewiesen, um den Abruf zu beschleunigen oder den Datenabruf mithilfe von SQL-Abfragen bei der Durchführung von Suchvorgängen zu erleichtern.
Die andere Möglichkeit, zwischengespeicherte Elemente zu gruppieren, besteht darin, die Region-zu-Gruppen-Korrelation vollständig wegzulassen und für jede Region einen separaten Cache zu verwenden. Um das gleiche Ergebnis zu erzielen, wenn jeder Region ein separater Cache zugewiesen wird, kann eine Karte der den Caches entsprechenden Regionsnamen gespeichert werden.
// NCache API
cacheInstance = map.get(regionName);
cacheInstance.Add(stringKey, stringValue);In diesem Beispiel ist es nicht erforderlich, den Regionsschlüssel dem Cache-Schlüssel voranzustellen, da er zwischengespeichert wird NCache schließen sich gegenseitig aus, auch wenn sie sich im selben Cluster befinden.
Wenn Ihre Anwendung viele Regionen (z. B. mehr als 15) verarbeiten muss, ist es besser, Regionen als Gruppen zu verwenden, da 15 Caches pro Cluster eine empfohlene maximale Anzahl von Caches sind (auch wenn ein Cluster logischerweise eine unendliche Anzahl von Caches hosten kann). .
In der nächsten Phase können Sie die Funktionen nutzen NCache bietet welche AppFabric und Redis Mangel. Funktionen wie:
Die Datenbanksynchronisierung ist eine sehr wichtige Funktion für jeden guten verteilten Cache. Da die meisten zwischengespeicherten Daten aus einer relationalen Datenbank stammen, gibt es immer Situationen, in denen andere Anwendungen oder Benutzer die Daten ändern und dazu führen können, dass die zwischengespeicherten Daten veraltet sind.
Anwendungen möchten häufig eine Teilmenge dieser Daten abrufen. Wenn sie den verteilten Cache mit einer SQL-ähnlichen Abfragesprache durchsuchen und Objektattribute als Teil der Kriterien angeben können, wird der verteilte Cache für sie viel nützlicher.
Viele Leute nutzen den verteilten Cache als „Nebencache“, bei dem sie Daten direkt aus der Datenbank abrufen und in den Cache legen. Ein anderer Ansatz ist „Cache Through“, bei dem Ihre Anwendung einfach den Cache nach den Daten fragt. Und wenn die Daten nicht vorhanden sind, ruft der verteilte Cache sie aus Ihrer Datenquelle ab. Das Gleiche gilt für das Durchschreiben.
Zusammen mit, NCache Unterstützt auch MapReduce, das Big Data Analytics in In-Memory-Daten ermöglicht und Ergebnisse nahezu in Echtzeit liefert.
Der Client-Cache ist einfach ein lokaler InProc/OutProc-Cache auf dem Client-Computer, der jedoch mit dem verteilten Cache-Cluster verbunden und synchronisiert bleibt. Auf diese Weise profitiert die Anwendungsleistung wirklich von dieser „Nähe“, ohne die Datenintegrität zu beeinträchtigen.
Die WAN-Replikation ist eine wichtige Funktion für viele Anwendungen, die in mehreren Rechenzentren entweder für Notfallwiederherstellungszwecke oder für den Lastausgleich des regionalen Datenverkehrs bereitgestellt werden.
Die Idee hinter der WAN-Replikation besteht darin, dass der Cache nicht an jedem geografischen Standort aufgrund der hohen Latenz des WAN verlangsamt werden darf. NCache bietet eine Bridge-Topologie, um all dies zu bewältigen.
Unterstützung für Microsoft AppFabric endet im April 2017. Dieses Whitepaper stellt drei Möglichkeiten zur Migration von .NET-Anwendungen vor AppFabric zu NCache, und Vorteile dieser Änderung. NCache ist ein stabiler, voll funktionsfähiger, verteilter .NET-Cache, der als Open Source in Azure und Amazon Web Services sowie auf der Website verfügbar ist NCache Webseite. Vollständiger Support ist ebenfalls verfügbar.
Mit dem kostenlosen NCache AppFabric Wrapper für beides NCache Open Source or NCache Enterprisebietet die einfachste, programmierungsfreie und fehlerfreie Migrationsmethode. Migration durch direkten Aufruf von NCache Die API bietet mehr Datenkontrolle und ermöglicht alles NCache Merkmale. Alle Migrationsmethoden werden in diesem Whitepaper beschrieben.
Bitte prüfen Sie diese zusätzlichen Ressourcen, um Ihren Evaluierungs- und Produktanforderungen gerecht zu werden.
Regionen in AppFabric sind logische Container von Schlüssel-Wert-Paaren, die in einer Instanz eines Caches gespeichert sind, der an einen Servercomputer gebunden ist. Aus diesem Grund können Daten innerhalb von Regionen nicht verteilt werden. Diese architektonische Struktur soll schnellere Abrufe ermöglichen. Im Vergleich zu einem verteilten Cache verringert sich jedoch die Gesamtleistung erheblich.
NCache ist im Kern ein verteilter Cache. Alle Daten darin NCache verteilt wird und eine Sicherungskopie auf einer anderen physischen Maschine aufbewahrt wird, wenn die Partitionsreplik (PR)-Topologie wird verwendet. PR bietet erstklassige, superschnelle Leistung und Failover-Replikate ohne Datenverlust.
Somit sind Regionen in AppFabric sind als separate Caches konfiguriert NCache ohne die Datenabruffähigkeit zu beeinträchtigen. Der AppFabric Der Wrapper übernimmt diese Komplexität und speichert automatisch alle Regionsdaten im angegebenen Cache-Namen. Die einzige Voraussetzung ist, dass zwischengespeichert wird NCache sollte bereits vorhanden sein. Du erstellst Caches über NCache Geschäftsführer, ein GUI-basiertes Cluster-Management-Tool. Sobald die Caches erstellt sind, werden die darin enthaltenen Daten gespeichert AppFabric Regionen werden an die angegebenen verteilt NCache Cluster(s). Obwohl die Daten wirklich verteilt sind, gibt es keine Kompromisse bei der Fähigkeit, erweiterte Suchvorgänge auszuführen, einschließlich SQL-Abfragen (SQL-Abfragen sind nicht verfügbar). AppFabric überhaupt).
Der andere auffällige Unterschied zwischen NCache und AppFabric ist die Art und Weise, wie beide Produkte konfiguriert sind. AppFabric wird von der Anwendung zur Laufzeit konfiguriert (sogar die Cache-Erstellung) und im Gegensatz dazu NCache wird konfiguriert, bevor der Cache gestartet wird. Beispielsweise können Cache-Topologien nicht zur Laufzeit geändert werden, während andere Konfigurationen, beispielsweise Cache-Standardabläufe usw., später geändert werden können und diese als Hotapply-fähig bezeichnet werden. Wenngleich NCache kann mit der .NET-Anwendung verwaltet werden (einschließlich Cache-Erstellung), es ist jedoch vorzuziehen, über die zu verwalten NCache Manager – Ein dediziertes einzelnes Tool zur Verwaltung der Cache-Cluster. Ein Cache kann auch über die CLI erstellt, konfiguriert und verwaltet werden.
Während NCache AppFabric-wrapper bietet die einfachste Möglichkeit, .NET-Anwendungen nach zu migrieren NCache, was auch mit möglichst wenigen Codeänderungen möglich ist, ziehen es einige Entwickler dennoch vor, alle Vorteile zu nutzen, die das bietet NCache muss anbieten. Dort können Sie direkt anrufen NCache API hilft. Es besteht auch die Möglichkeit, beide Methoden zu verwenden, indem Sie die Unwrap-Methode aufrufen AppFabric Verpackung.
Das AppFabric Cluster ist nicht vollständig dynamisch. Abhängigkeit von „Mehrheitsregel der Hauptgastgeber“ bedeutet, dass der Cluster sehr leicht ausfallen kann, wenn auch nur ein Haupthost ausfällt. Diese Lead-Host-Knoten ähneln auch einer „Master“- und „Slave“-Architektur und sind daher auch nicht vollständig Peer-to-Peer.
NCache wohingegen ist hochdynamisch und ermöglicht das Hinzufügen oder Entfernen von Cache-Servern zur Laufzeit ohne Unterbrechung des Caches oder Ihrer Anwendung. Die Daten werden zur Laufzeit automatisch neu ausgeglichen (Statusübertragung genannt), ohne dass es zu Unterbrechungen oder Leistungseinbußen kommt. NCache Clients kommunizieren weiterhin mit Cache-Servern, unabhängig vom Status des Servers. Cluster stellen die Ausführung von Client-Vorgängen auch dann sicher, wenn der Datenausgleich läuft.
Dies bedeutet, dass auch für NCache, es gibt keine „Master“- oder „Slave“-Knoten im Cluster. Es gibt einen „primären Koordinator“-Knoten, der der höchste Knoten ist. Und wenn es ausfällt, wird der nächsthöhere Knoten automatisch zum primären Koordinator. All dies geschieht ohne Unterbrechung des Client-Betriebs.