NCache Architektur

Peer-to-Peer-Cluster (selbstheilend)

NCache Der Cluster verfügt über eine Peer-to-Peer-Clusterarchitektur. Das bedeutet, dass es keine Master-/Slave-Knoten gibt und jeder Server ein Peer ist. Der Cluster-Koordinator ist jedoch der älteste Knoten im Cluster. Fällt er aus, wird der nächstälteste Knoten automatisch zum Koordinator.

Dieser Cluster-Koordinator verwaltet alle Clustervorgänge und andere Cache-Konfigurationsinformationen. Er verwaltet außerdem die Clusterintegrität und entfernt zwangsweise alle Cache-Server, die nur teilweise mit den anderen Servern im Cluster verbunden sind.

Dynamisches Clustering

Der Kern des NCache Hochverfügbarkeit wird durch dynamisches Clustering erreicht, das das Hinzufügen oder Entfernen von Servern ohne Ausfallzeiten ermöglicht, indem Mitgliedschaftsänderungen in Echtzeit über TCP weitergegeben werden. Wie bereits erwähnt, NCache hat eine Dynamische Clustering-Architektur. Dies erlaubt NCache auch bei solchen Änderungen immer betriebsbereit zu sein.

Dynamisches Clustering ermöglicht Ihnen Folgendes:

• - Cache-Server zur Laufzeit hinzufügen/entfernen ohne den Cache oder Ihre Anwendung zu stoppen.
• - Clustermitgliedschaft wird zur Laufzeit aktualisiert und an alle Server im Cluster und alle mit dem Cluster verbundenen Clients weitergegeben.

Umgang mit Split-Brain-Clustern

NCache Löst Split-Brain-Szenarien mithilfe eines intelligenten Erkennungsalgorithmus, der divergierende Subcluster automatisch abgleicht, um die Datenintegrität ohne manuelles Eingreifen wiederherzustellen. Ein weiterer Teil von NCache Dynamisches Clustering ist seine intelligente Split Brain-Erkennung und -Wiederherstellung Split Brain tritt auf, wenn aufgrund von Netzwerkproblemen die Verbindung zwischen Cache-Servern unterbrochen wird. Dadurch bilden sich mehrere unabhängige Subcluster, von denen jeder davon ausgeht, dass die anderen ausgefallen sind und er der einzige verbleibende Cluster ist.

In solchen Fällen, wenn Cache-Server den Cluster abrupt verlassen, werden die verbleibenden NCache Die Server versuchen weiterhin, die Verbindung wiederherzustellen. Währenddessen aktualisiert jedoch jeder Subcluster die Daten unabhängig voneinander, wodurch mehrere nicht synchronisierte Versionen der Daten entstehen.

Nachdem das Netzwerkproblem behoben ist, NCache löst automatisch Split Brain aus. Dies geschieht automatisch, indem entschieden wird, welche Cache-Server ihre Daten behalten dürfen (Gewinner) und welche Server ihre Daten abgeben müssen (Verlierer). Dies ist notwendig, da die Server des Verliererclusters als neue Knoten wieder dem Gewinnercluster beitreten müssen. Es kommt zwar zu Datenverlusten, aber das Endergebnis ist eine schnelle Wiederherstellung des Cache-Clusters ohne menschliches Eingreifen.

Dynamische Client-Verbindungen

NCache lässt dich auch hinzufügen oder entfernen Clients zur Laufzeit, ohne den Cache oder einen seiner anderen Clients zu stoppen. Wenn Sie einen Client hinzufügen, benötigt dieser nur einen einzigen Cache-Server im Cluster, um eine Verbindung herzustellen. Sobald er eine Verbindung zu diesem Server herstellt, erhält er die erforderlichen Informationen zur Cluster-Mitgliedschaft und zur Caching-Topologie. Anschließend entscheidet er, mit welchen anderen Servern er eine Verbindung herstellt.

• - Partitionierter/Partitionsreplikat-Cache: Der Client verbindet sich mit allen Cache-Server-Partitionen (aber nicht mit Replikaten, da Replikate nur mit ihren Partitionen kommunizieren). Dadurch kann der Client die entsprechende Partition für Lese- und Schreibvorgänge auswählen. Wird dem Cluster ein neuer Server hinzugefügt, erhält der Client aktualisierte Cluster-Mitgliedschaftsinformationen und verbindet sich ebenfalls mit diesem neu hinzugefügten Server.
• - Replizierter Cache: Im Falle der Replizierter Cacheverbindet sich der Client nur mit einem Cache-Server im Cluster, allerdings mit Lastenausgleich, um sicherzustellen, dass alle Cache-Server die gleiche Anzahl an Clients haben. Somit sind alle Lese- und Schreibvorgänge auf einem Cache-Server möglich. Wenn dem Cluster ein neuer Server hinzugefügt wird, erhält der Client diese Informationen vom Cache-Server und stellt bei Bedarf eine erneute Verbindung zu einem neuen Server her.
• - Gespiegelter Cache: Im Falle der Gespiegelter CacheDer Client verbindet sich nur mit dem einzigen aktiven Knoten in diesem 2-Knoten-Cluster. Wenn der Client eine Verbindung zum passiven Knoten herstellt, informiert der passive Knoten den Client über den aktiven Knoten, und der Client stellt automatisch die Verbindung zum aktiven Knoten wieder her. Wenn der aktive Knoten ausfällt und der passive Knoten aktiv wird, verbinden sich alle Clients automatisch mit dem neuen aktiven Knoten.

Dynamische Konfiguration

Wie in den Abschnitten „Dynamische Clientverbindungen“ und „Dynamisches Clustering“ erwähnt, NCache ermöglicht die dynamische Konfiguration des Caches und der Clients. Dieser Abschnitt erläutert die Funktionsweise dieser Laufzeitkonfiguration.

• - Cache-Konfiguration: Wenn ein Cache über Admin-Tools erstellt wird, werden diese Konfigurationsinformationen auf alle zu diesem Zeitpunkt bekannten Cache-Server kopiert. Ebenso erhält jeder neue Server, der zur Laufzeit zum Cluster hinzugefügt wird, die gesamte aktualisierte Cache-Konfiguration und kopiert sie auf seine lokale Festplatte.
• - Konfigurationsänderungen im laufenden Betrieb anwenden: Sie können einige Cache-Konfigurationen zur Laufzeit über "Hot Apply" ändern. Zum Beispiel beim Ändern der Cache-Größe oder aktivieren Kompression. In diesem Fall werden die aktualisierten Konfigurationsinformationen zur Laufzeit an alle Cache-Server weitergegeben und auf deren Festplatten gespeichert. Ein Teil dieser Informationen wird bei Bedarf auch an alle Clients gesendet.
• - Verteilungskarte (partitionierter/Partitions-Replikat-Cache): Diese wird beim Start eines Caches erstellt und anschließend auf alle Cache-Server und -Clients kopiert. Diese Verteilungskarte enthält Informationen darüber, welche Buckets (von insgesamt 1000 Buckets im Cluster-Cache) sich in welcher Partition befinden.

Verbindungs-Failover innerhalb des Clusters

Alle Cache-Server im Cluster sind über TCP verbunden. Und jeder Cache-Server ist mit allen anderen Cache-Servern im Cluster verbunden, einschließlich aller neuen Server, die zur Laufzeit hinzugefügt werden. NCache bietet verschiedene Möglichkeiten, um sicherzustellen, dass alle Verbindungen innerhalb des Clusters am Leben gehalten trotz Verbindungsfehler. Diese Fehler treten normalerweise aufgrund einer Netzwerkstörung aufgrund von Routern, Firewalls oder einem Problem mit der Netzwerkkarte/dem Netzwerktreiber auf.

• - Verbindungsversuche: Wenn die Verbindung zwischen zwei Cache-Servern abbricht, NCache versucht automatisch mehrere Versuche, diese Verbindung wiederherzustellen. Diese versucht es erneut für die Dauer der benutzerdefinierten Zeitüberschreitung auftreten.
• - Keep-Alive-Herzschlag: NCache verfügt außerdem über eine Funktion, mit der jeder Cache-Server weiterhin kleine Datenpakete als Heartbeat an alle anderen Server sendet. Dadurch wird sichergestellt, dass die Cache-Server ein Netzwerk-Socket-Problem erkennen und durch erneute Versuche beheben.
• - Teilweise verbundene Server: In einigen Fällen können Netzwerkprobleme den Cluster in Untercluster aufteilen (ein "Geteiltes Gehirn"). NCache erkennt und behebt dies automatisch, sobald das Netzwerk wiederhergestellt ist, indem entschieden wird, welcher Cluster seine Daten behält, und die anderen aufgefordert werden, sich erneut anzuschließen.

Verbindungs-Failover mit Clients

Das Verbindungsfailover bei Clients ähnelt Cluster-Failover-Wiederholungsversuchen, Heartbeats und der automatischen Neuverbindung mit fehlerfreien Servern.

• - Verbindungsversuche: In Bezug auf Failover sind die Verbindungswiederholungen auf Cluster- und Clientebene gleich. Wenn jedoch eine Verbindung zwischen einem Client und Cache-Servern unterbrochen wird, NCache Der Client tut dies automatisch mehrere Verbindungsversuche um diese Verbindung herzustellen. Diese Wiederholungsversuche erfolgen für die Dauer des Timeout-Zeitraums. Wenn keine Verbindung hergestellt werden kann, wird eine Ausnahme an die Clientanwendung gesendet, damit diese die Verbindung verarbeiten kann.
• - Keep-Alive-Herzschlag: Dasselbe wie bei Verbindungsfailover innerhalb des Clusters.
• - Teilweise verbundene Clients (partitionierter/Partitionsreplikat-Cache): Manchmal wird die Verbindung trotz wiederholter Versuche nicht rechtzeitig wiederhergestellt, sodass der Client davon ausgeht, dass andere Server nicht erreichbar sind, obwohl dies nicht der Fall ist. Im Fall eines partitionierten/partitionsreplizierten Caches interagiert er mit anderen Servern, um alle Daten zu lesen oder zu schreiben, obwohl seine Verteilungskarte ihm anzeigt, dass der Server, mit dem er nicht kommunizieren kann, über die Daten verfügt. In diesem Fall fungiert der andere Cache-Server als Vermittler, um einen erfolgreichen Betrieb zu gewährleisten.

Caching-Topologien (lineare Skalierbarkeit)

NCache bietet eine Vielzahl von Caching-Topologien für lineare Skalierbarkeit bei gleichzeitiger Wahrung von Datenkonsistenz und Zuverlässigkeit. Ziel ist die Unterstützung von Anwendungen vom kleinen Cache mit zwei Servern bis hin zu großen Clustern mit Hunderten von Servern. Eine Caching-Topologie ist im Wesentlichen eine Strategie für Datenspeicherung, Datenreplikation und Clientverbindungen in einem Cluster-Cache, der mehrere Cache-Server umfasst.

Referenzdaten vs. Transaktionsdaten

Referenzdaten ändern sich nicht sehr häufig. Sie werden zwischengespeichert, um häufige Anfragen zu bearbeiten und kostspielige Datenbankzugriffe zu vermeiden. Sie werden nur gelegentlich aktualisiert. Transaktionsdaten hingegen ändern sich sehr häufig und können so oft aktualisiert werden, wie Sie sie lesen.

In der Anfangszeit wurden Caches hauptsächlich für Referenzdaten verwendet, da sich häufig geänderte Daten veralten und nicht mehr mit den neuesten Daten in der Datenbank synchronisiert waren. Allerdings NCache bietet jetzt sehr leistungsstarke Funktionen, die es dem Cache ermöglichen, seine zwischengespeicherten Daten mit der Datenbank zu synchronisieren.

Alle NCacheDie Caching-Topologien von eignen sich gut für Referenzdaten, einige sind jedoch besonders für Transaktionsdaten nützlich. Daher müssen Sie die Anzahl der Lese- und Schreibvorgänge ermitteln, um die für Sie optimale Topologie zu finden. Darüber hinaus sind einige Caching-Topologien, insbesondere bei Updates, weniger skalierbar. Berücksichtigen Sie dies ebenfalls.

Nachfolgend finden Sie eine Liste von Caching-Topologien zusammen mit ihren Auswirkungen auf Lese- und Schreibvorgänge.

• - Partitionierter Cache (keine Replikation): Dies ist die schnellste Topologie, aber sie repliziert keine Daten, sodass es zu Datenverlusten kommt, wenn ein Cache-Server ausfällt.
• - Partitionsreplikat-Cache (Am beliebtesten): Diese Topologie ist sowohl beim Lesen als auch beim Schreiben superschnell. Sie repliziert jedoch auch Daten für eine kompromisslose Zuverlässigkeit. Die beste Kombination aus Geschwindigkeit/Skalierbarkeit und Datenzuverlässigkeit.
• - Replizierter Cache: Sehr gut für kleinere Umgebungen. Jeder Server speichert eine vollständige Sicherung des Caches, was hohe Datenzuverlässigkeit und Fehlertoleranz gewährleistet. Superschnell und linear skalierbar für Lesevorgänge. Mäßig schnell für Schreibvorgänge in einem 2-Knoten-Cluster, skaliert jedoch nicht mit dem Hinzufügen weiterer Server, da Schreibvorgänge synchron auf allen Cache-Servern ausgeführt werden.
• - Gespiegelter Cache: Diese Topologie eignet sich sehr gut für kleinere Umgebungen. Sie bietet schnellere Schreibvorgänge als der replizierte Cache für 2-Knoten aktiv/passiv. Darüber hinaus ist sie jedoch nicht skalierbar.
• - Client-Cache: Sehr gut für leseintensive Anwendungsfälle mit allen Caching-Topologien. Ermöglicht Ihnen, InProc-Geschwindigkeit mit einem verteilten Cache zu erreichen

Partitionierter Cache

Partitionierter Cache ist die schnellste und skalierbarste Caching-Topologie für Lese- und Schreibvorgänge. Er ist für große Cluster konzipiert und ermöglicht schnelle Lese- und Schreibvorgänge auch bei Spitzenlast. Allerdings repliziert er keine Daten. Daher gibt es kein Backup für den Fall eines Serverausfalls.

Hier sind einige Merkmale des partitionierten Caches.

• - Dynamische Partitionen: Der Cache wird zur Laufzeit in Partitionen aufgeteilt, wobei jeder Cache-Server eine Partition hat. Pro Cluster-Cache gibt es insgesamt 1000 Buckets, die gleichmäßig auf alle Partitionen verteilt sind. Das Hinzufügen/Entfernen von Cache-Servern führt im Wesentlichen zur Erstellung/Löschung von Partitionen zur Laufzeit. Die Partitions-Bucket-Zuordnung ändert sich nicht, wenn Daten zum Cache hinzugefügt werden. Sie ändert sich nur, wenn Partitionen hinzugefügt oder gelöscht werden oder wenn Daten Lastenausgleich. Diese Neuverteilung bezieht sich auf den Zustandsübertragungsprozess, der Buckets und ihre Daten in die Zielpartitionen verschiebt
• - Verbreitungskarte: Der Cache-Cluster erstellt eine Verteilungskarte, die Informationen darüber enthält, welche Buckets in welchen Partitionen vorhanden sind. Die Verteilungskarte wird bei jeder Statusübertragung aktualisiert. Die Verteilungskarte wird an alle Server und Clients weitergegeben. Die Clients nutzen diese Karte, um herauszufinden, mit welchem ​​Cache-Server sie für Lese-/Schreibvorgänge kommunizieren müssen.
• - Dynamischer Datenausgleich: Da alle Buckets HashMap-basiert sind und die Daten basierend auf einem auf die Schlüssel angewendeten Hashing-Algorithmus gespeichert werden, kann dies dazu führen, dass einige Buckets je nach verwendeten Schlüsseln mehr Daten enthalten als andere. Überschreitet dieses Ungleichgewicht einen konfigurierbaren Schwellenwert, NCache verschiebt die Eimer automatisch, um diese Last neu auszugleichen.
• - Clients stellen eine Verbindung zu ALLEN Partitionen her: Clients stellen eine Verbindung zu allen Cache-Servern her, um Daten in einer Anfrage direkt vom Server lesen oder schreiben zu können. Fällt die Verbindung eines Clients zu einem Cache-Server aus, fordert er einen der anderen Server auf, ein zwischengespeichertes Element auf dem Server zu lesen oder zu schreiben, auf das er keinen Zugriff hat. Dieser Server unterstützt den Client dabei.

Partitionsreplikat-Cache

HINWEIS: Alles, was im Abschnitt „Partitionierter Cache“ erwähnt wird, gilt auch hier.

Genau wie Partitionierter CacheDer Partition-Replica Cache ist eine extrem schnelle und linear skalierbare Cache-Topologie für Lese- und Schreibvorgänge. Er ist für größere Cache-Cluster konzipiert und bietet selbst bei Spitzenlast eine sehr gute Lese- und Schreibleistung. Darüber hinaus repliziert der Partition-Replica Cache auch Daten. Daher kommt es selbst bei einem Ausfall eines Cache-Servers nicht zu Datenverlusten.

Partitionsreplikat-Cache ist unsere beliebteste Caching-Topologie weil es Ihnen das Beste aus beiden Welten bietet: Leistung/lineare Skalierbarkeit und Datenzuverlässigkeit.

Nachfolgend sind einige der Merkmale des Partition-Replica-Cache aufgeführt.

• - Dynamische Partitionen: Dasselbe wie partitionierter Cache.
• - Dynamische Replikate: Wenn Partitionen zur Laufzeit erstellt oder gelöscht werden, werden auch ihre Replikate erstellt oder gelöscht. Replikate befinden sich immer auf einem anderen Cache-Server, und es gibt nur ein Replikat für eine Partition.
• - Asynchrone Replikation: Standardmäßig erfolgt die Replikation von einer Partition auf ihre Replik asynchron. Client-Schreibvorgänge (Hinzufügen/Aktualisieren/Löschen) treffen auf die Partition und werden für die asynchrone Massenreplikation auf die Replik in die Warteschlange gestellt. Dies verbessert die Leistung, birgt jedoch ein geringes Risiko von Datenverlust, falls eine Partition ausfällt und nicht alle Aktualisierungen auf die Replik repliziert wurden. Dies kommt jedoch äußerst selten vor.
• - Replikation synchronisieren: Wenn Ihre Daten sehr sensibel sind (z. B. Finanzdaten) und Sie sich keine veralteten Daten leisten können, können Sie in der Konfiguration die Option „Synchronisierte Replikation“ wählen. Bei Auswahl dieser Option werden alle Schreibvorgänge synchron auf der Partition und dem Replikat ausgeführt, bis sie als abgeschlossen gelten. Wenn der Vorgang auf dem Replikat fehlschlägt, schlägt er somit auch auf der Partition fehl. Dadurch ist gewährleistet, dass alle Daten im Cache (sowohl in der Partition als auch im Replikat) stets konsistent sind. Dies hat jedoch Auswirkungen auf die Leistung, da es langsamer ist als die asynchrone Replikation.
• - Verbreitungskarte: Dasselbe wie partitionierter Cache.
• - Dynamischer Datenausgleich (Partitionen und Replikate): Wie beim partitionierten Cache. Beim Partitionsreplikat-Cache erfolgt der Datenausgleich jedoch auch in den Replikaten, wenn die Daten der Partitionen ausgeglichen sind.
• - Clients stellen eine Verbindung zu ALLEN Partitionen her: Wie beim partitionierten Cache. Im Partitionsreplikat-Cache kommunizieren die Clients jedoch nur mit den Partitionen und nicht mit deren Replikaten. Dies liegt daran, dass Replikate passiv sind und die Partitionen nur mit ihren Replikaten kommunizieren, wenn sie Daten auf diese replizieren.

Replizierter Cache

Der replizierte Cache bietet Datenzuverlässigkeit durch Replikation auf zwei oder mehr Cache-Servern. Er ist sehr schnell und skalierbar für Lesevorgänge. Schreibvorgänge sind jedoch nicht skalierbar, da diese synchron zu allen Servern im Cluster erfolgen. Bei einem Cluster mit zwei Knoten sind die Schreibvorgänge schneller als Ihre Datenbank, aber nicht so schnell wie bei einem Partitionsreplikat-Cache. Bei Clustern mit drei oder mehr Servern nimmt die Schreibleistung ab und wird schließlich kostspielig.

Unten sind einige der Eigenschaften von Replicated Cache aufgeführt.

• - Dynamisch replizierte Knoten: Sie können Cache-Server zur Laufzeit zu einem vorhandenen Cache hinzufügen oder daraus entfernen, ohne den Cache oder Ihre Anwendung zu stoppen. Der neu hinzugefügte Server erstellt eine Kopie (Replikat) des gesamten Caches auf sich selbst. Der entfernte Server aktualisiert außerdem die Clustermitgliedschaft, und alle seine Clients werden auf andere Server verschoben.
• - Gesamter Cache auf jedem Knoten: Der gesamte Cache wird auf jeden Server im Cluster kopiert.
• - Lesevorgänge sind skalierbar: Die Lesevorgänge sind superschnell und skalierbar, wenn Sie weitere Server hinzufügen. Das Hinzufügen weiterer Server erhöht jedoch nicht die Cachegröße, da der neu hinzugefügte Server lediglich eine weitere Kopie des gesamten Caches ist.
• - Schreibvorgänge sind synchron: Schreibvorgänge sind für einen 2-Knoten-Cluster sehr schnell und schneller als Ihre Datenbank. Allerdings sind Schreibvorgänge synchron, d. h. jeder Schreibvorgang wird erst abgeschlossen, wenn alle Cache-Server synchron aktualisiert wurden. Daher sind Schreibvorgänge nicht so schnell wie bei anderen Topologien.
• - Der Client stellt nur eine Verbindung zu einem Server her: Jeder Cache-Client verbindet sich basierend auf einem von den Cache-Servern festgelegten Lastausgleichsalgorithmus nur mit einem Server im Cluster. Fällt dieser Cache-Server aus, verbindet sich der Client mit dem nächsten Server in der Liste. Wenn Sie keinen Lastausgleich verwenden möchten, können Sie den Server, mit dem eine Verbindung hergestellt werden soll, auch manuell in der Cache-Konfigurationsdatei angeben.

Gespiegelter Cache

Der Mirrored Cache ist ein 2-Knoten-Aktiv/Passiv-Cache-Cluster für kleinere Umgebungen. Er bietet Datenzuverlässigkeit durch asynchrone Replikation/Spiegelung vom aktiven zum passiven Knoten. Er ist sowohl beim Lesen als auch beim Schreiben sehr schnell (die Schreibvorgänge sind sogar schneller als beim Replicated Cache), lässt sich aber nicht über diesen 2-Knoten-Aktiv/Passiv-Cluster hinaus skalieren.

Nachfolgend sind einige der Merkmale von Mirrored Cache aufgeführt.

• - 1 aktiver und 1 passiver Server: Der gespiegelte Cache verfügt nur über zwei Server. Einer ist aktiv, der andere passiv. Beide verfügen über eine Kopie des gesamten Caches. Fällt der aktive Server aus, wird der passive Server automatisch aktiviert. Und wenn der zuvor ausgefallene aktive Server wieder hochfährt, wird er als passiver Server behandelt, sofern Sie diese Bezeichnung nicht zur Laufzeit über die Admin-Tools ändern.
• - Clientverbindungen mit Failover-Unterstützung: Jeder Cache-Client verbindet sich für Lese- und Schreibvorgänge nur mit dem aktiven Server im Cluster. Fällt dieser aktive Server aus, verbinden sich alle Clients automatisch mit dem inzwischen aktiven passiven Server. Diese Failover-Unterstützung stellt sicher, dass der gespiegelte Cache auch bei einem Serverausfall immer betriebsbereit ist.
• - Asynchrone Spiegelung: Alle Schreibvorgänge auf dem aktiven Server werden asynchron auf den passiven Server gespiegelt/repliziert. Dadurch wird sichergestellt, dass der passive Server immer mit den neuesten Daten synchronisiert ist, falls der aktive Server ausfällt und der passive Server aktiviert werden muss. Asynchrone Spiegelung bedeutet auch eine schnellere Leistung, da mehrere Schreibvorgänge als BULK-Operation auf dem passiven Server ausgeführt werden.

Client-Cache (InProc-Geschwindigkeit)

Der Client-Cache befindet sich lokal auf Ihrem Web-/App-Server und in unmittelbarer Nähe Ihrer Anwendung. Er ermöglicht Ihnen das Zwischenspeichern von Daten, die Sie aus dem verteilten Cache lesen (unabhängig von der Cache-Topologie). Obwohl er lokal auf Ihrer Anwendung vorhanden ist, ist ein Client-Cache kein eigenständiges System. Stattdessen wird er stets mit dem Cluster-Cache synchronisiert. Dadurch wird sichergestellt, dass die Daten im Client-Cache stets aktuell sind.

Sie können dies als „Cache über einem Cache“ betrachten und es verbessert die Leistung und Skalierbarkeit Ihrer Anwendung noch weiter. Wenn Sie den Client-Cache im InProc-Modus verwenden, können Sie InProc-Geschwindigkeit erreichen. NCache bietet zwei Varianten des Client-Cache: den regulären und den Full-Data-Client-Cache. Beide Varianten steigern die Leistung durch die Reduzierung von Netzwerkaufrufen und gewährleisten gleichzeitig die Synchronisierung mit dem Cluster-Cache.

Regulärer Client-Cache

Der reguläre Client-Cache fungiert als lokaler Cache (L1) auf dem Client-Rechner und hält eine Teilmenge häufig abgerufener Daten in der Nähe der Anwendung. Dies reduziert wiederholte Netzwerkzugriffe auf den Cluster-Cache (L2). Um die Konsistenz zu gewährleisten, bleibt der Client-Cache durch den Empfang von Änderungsbenachrichtigungen mit dem Cluster-Cache synchronisiert. Da er nicht den vollständigen Datensatz enthält, werden alle Abfragen weiterhin über den Cluster-Cache (L2) ausgeführt.

Vollständiger Daten-Client-Cache

Der Full Data Client Cache geht noch einen Schritt weiter und speichert ganze Datensätze lokal auf dem Client-Rechner. Er bietet folgende Vorteile und Optionen:

• - Speichert komplette Datensätze lokal im Cache: Zwischenspeichert alle Einträge ausgewählter .NET-Klassen und stellt die vollständigen Datensätze sofort zur Verfügung.
• - Nahezu In-Proc-Geschwindigkeit: Der Full-Data-Client-Cache bietet schnellere Lesevorgänge und ermöglicht die vollständige Ausführung von SQL-Abfragen im Client-Cache, da der vollständige Datensatz lokal vorhanden ist.
• - Synchronisierung mit Clustered Cache: Es bleibt vollständig mit dem Cluster-Cache synchronisiert, um Konsistenz zu gewährleisten.
• - Strikte Abfragedurchsetzung: Diese Erzwingung stellt sicher, dass Abfragen nur ausgeführt werden, wenn der vollständige Datensatz lokal verfügbar ist. Wenn der Datensatz nur teilweise geladen ist, schlägt die Abfrage sofort fehl, ohne dass auf den Cluster-Cache zurückgegriffen wird.
• - Strikte lokale Lesevorgänge: Dadurch werden alle Lesevorgänge ausschließlich aus dem Client-Cache ausgeführt. Wenn ein Schlüssel lokal nicht gefunden wird, wird ein Cache-Fehler zurückgegeben, anstatt ihn aus dem Cluster-Cache abzurufen.

Ein Client-Cache ist zwar lokal für Ihre Anwendung, aber nicht eigenständig. Stattdessen wird es immer mit dem gruppierten Cache synchronisiert. Dadurch wird sichergestellt, dass die Daten im Client-Cache niemals veraltet sind.

Nachfolgend sind einige der Merkmale von Mirrored Cache aufgeführt.

• - Gut für leseintensive Fälle: Der Client-Cache eignet sich ideal für leseintensive Anwendungsfälle. Wenn jedoch die Anzahl der Schreibvorgänge mit der Anzahl der Lesevorgänge übereinstimmt, ist der Client-Cache tatsächlich langsamer, da bei einem Schreibvorgang die Daten an zwei Stellen aktualisiert werden.
• - Höhere Geschwindigkeit wie ein lokaler Cache (InProc / OutProc): Ein Client-Cache befindet sich entweder innerhalb Ihres Anwendungsprozesses (InProc-Modus) oder lokal auf Ihrem Web-/App-Server (OutProc-Modus). In beiden Fällen steigert er die Anwendungsleistung deutlich im Vergleich zum bloßen Abrufen der Daten aus dem Cluster-Cache. Im InProc-Modus können Sie Objekte auf Ihrem „Anwendungsheap“ zwischenspeichern, was Ihnen eine „InProc-Geschwindigkeit“ bietet, die kein verteilter Cache erreichen kann.
• - Kein eigenständiger Cache: Ein Client-Cache kann ein lokaler Cache sein, ist aber kein eigenständiger Cache. Er ist mit dem Cluster-Cache synchronisiert. Das bedeutet: Wenn ein anderer Client Daten im Cluster-Cache aktualisiert, benachrichtigt der Cluster-Cache den Client-Cache, sich mit der neuesten Kopie dieser Daten zu aktualisieren. Dies geschieht asynchron, aber sofort.
• - Optimistische / pessimistische Synchronisation: Standardmäßig verwendet der Client-Cache die optimistische Synchronisierung, was bedeutet, dass die NCache Der Client geht davon aus, dass die im Client-Cache vorhandenen Daten die neueste Kopie sind. Wenn der Client-Cache keine Daten enthält, ruft der Client diese aus dem Cluster-Cache ab, legt sie im Client-Cache ab und gibt sie an die Client-Anwendung zurück. Pessimistische Synchronisierung bedeutet, dass der Cache-Client zunächst den Cluster-Cache prüft, ob eine neuere Version eines zwischengespeicherten Elements vorhanden ist. Ist dies der Fall, ruft der Client diese ab, legt sie im Client-Cache ab und gibt sie an die Client-Anwendung zurück. Andernfalls gibt er den Inhalt des Client-Cache zurück.
• - Plug-in ohne Code-Änderung: Die Nutzung des Client-Cache erfordert keine Änderung des Anwendungscodes. Stattdessen ist eine einfache Konfigurationsänderung erforderlich.

Was macht man als nächstes?

• NCache Details
• Herunterladen NCache
• Editionsvergleich

Häufig gestellte Fragen (FAQ)

Wie funktioniert NCache Lineare Skalierbarkeit erreichen?

NCache Erreicht lineare Skalierbarkeit durch die Verwendung einer 1000-Bucket-Verteilungskarte zur Partitionierung der Daten auf mehrere Serverknoten, wodurch der Cluster in der Lage ist, erhöhte Transaktionslasten zu bewältigen, wenn zur Laufzeit neue Hardware hinzugefügt wird.

Was macht NCache's Clustering "Selbstheilung"?

NCache nutzt eine 100%ige Peer-to-Peer-Architektur, bei der jeder Server ein Peer ist; wenn ein Knoten (einschließlich des Cluster-Koordinators) ausfällt, wählen die verbleibenden Knoten automatisch einen neuen Koordinator und gleichen den Cluster über TCP-basierte Heartbeats neu aus, um eine 100%ige Verfügbarkeit zu gewährleisten.

Worin besteht der Unterschied zwischen partitionierten und partitionierten Replikat-Topologien?

Während beide eine lineare Skalierbarkeit bieten, bietet Partitioned Cache die höchste Geschwindigkeit ohne Datenredundanz, während Partition-Replica Cache die beliebteste Wahl ist, da er extreme Leistung mit hoher Verfügbarkeit in Einklang bringt, indem er passive Replikate jeder Partition erstellt.

Wie funktioniert NCache „Split-Brain“-Szenarien lösen?

NCache Löst Split-Brain-Szenarien durch einen intelligenten Erkennungs- und Wiederherstellungsalgorithmus, der divergierende Subcluster automatisch ausgleicht und die Datenintegrität wiederherstellt, ohne dass ein manuelles Eingreifen erforderlich ist.

Warum sollte ich ein NCache Client-Cache (L1)?

An NCache Der Client-Cache (L1) ermöglicht InProc-Geschwindigkeiten im Submillisekundenbereich, indem er eine häufig abgerufene Teilmenge der Daten direkt auf dem Anwendungsserver speichert, wodurch die Netzwerklatenz zum Cluster-Cache (L2) drastisch reduziert wird.

Kann ich Server zur Laufzeit hinzufügen oder entfernen, ohne dass es zu Ausfallzeiten kommt?

Ja, NCache Unterstützt dynamisches Clustering, wodurch die Erweiterung oder Entfernung von Servermitgliedschaften ohne Ausfallzeiten möglich ist, indem die Clusterverteilungskarte automatisch in Echtzeit aktualisiert und an alle Clients weitergegeben wird.