NCache Architektur

Peer-to-Peer-Cluster (Selbstheilung)

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. Es gibt einen Cluster-Koordinatorknoten, der der älteste Knoten im Cluster ist. Wenn der Cluster-Koordinator-Knoten ausfällt, wird der nächstälteste Knoten automatisch zum Koordinator.

Der Cluster-Koordinator verwaltet alle Cluster-bezogenen Vorgänge, einschließlich der Cluster-Mitgliedschaft, wenn Knoten hinzugefügt oder entfernt werden, und der Verteilungskarte für Partitionierter Cache / Partitionsreplikat-Cache Topologie und andere Cache-Konfigurationsinformationen. Cluster Coordinator verwaltet auch den Cluster-Zustand und entfernt zwangsweise alle Cache-Server, die teilweise mit allen anderen Servern im Cluster verbunden sind.

Dynamisches Clustering

NCache hat eine Dynamische Clustering-Architektur. Das heißt, Sie können hinzufügen or entfernen Sie können jeden Cache-Server aus dem Cluster entfernen, ohne den Cache oder die Anwendungen zu stoppen. Immer wenn Sie einen Cache-Server hinzufügen oder entfernen, wird die Clustermitgliedschaft sofort zur Laufzeit aktualisiert und an alle Server im Cluster sowie alle mit dem Cluster verbundenen Clients weitergegeben. Diese Laufzeitaktualisierung und -weitergabe ermöglicht 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

Ein weiterer Teil von NCache Dynamic Clustering ist intelligent Split-Brain-Erkennung und Wiederherstellung Fähigkeit. Das Split Brain tritt im Wesentlichen auf, wenn aufgrund einiger Netzwerkprobleme die Netzwerkverbindung zwischen diesen Cache-Servern unterbrochen wird und dies zu mehreren unabhängigen Sub-Clustern führt, wobei jeder Sub-Cluster davon ausgeht, dass alle anderen Cache-Server ausgefallen sind und es sich um den korrekten verbleibenden Cluster handelt .

In solchen Fällen, NCache Server erkennen, dass die anderen Cache-Server den Cluster plötzlich verlassen haben, und versuchen daher weiterhin, eine Verbindung zu ihnen wiederherzustellen. Dann, wenn das Netzwerkproblem behoben ist, diese NCache Server können sich wieder mit den anderen Cache-Servern verbinden. Aber jetzt hat jeder Sub-Cluster den Cache parallel aktualisiert, ohne ihn mit anderen Cache-Servern zu synchronisieren, und daher existieren mehrere Versionen der Daten über Sub-Cluster hinweg.

NCache bietet eine Möglichkeit, sich von diesem „Split Brain“ zu erholen, indem automatisch entschieden wird, welche Cache-Server ihre Daten aufgeben müssen und andere Cache-Server ihre Daten behalten dürfen. Es kommt zu einem gewissen Datenverlust, aber das Endergebnis ist eine schnelle Wiederherstellung des Cache-Clusters ohne menschliches Eingreifen.

Dynamische Client-Verbindungen

NCache lässt dich auch Cache-Clients zur Laufzeit hinzufügen oder entfernen ohne den Cache oder andere Clients zu stoppen. Wenn Sie einen Client hinzufügen, muss dieser Client lediglich über einen beliebigen Cache-Server im Cluster Bescheid wissen, zu dem er eine Verbindung herstellen möchte. Sobald es eine Verbindung zu diesem Server herstellt, erhält es Informationen zur Clustermitgliedschaft und zur Caching-Topologie, auf deren Grundlage es entscheidet, mit welchen anderen Servern eine Verbindung hergestellt werden soll.

• - Clients zur Laufzeit hinzufügen/entfernen: ohne den Cache oder Ihre Anwendung zu stoppen.
• - Partitionierter Cache/Partitions-Replikat-Cache: Der Client stellt eine Verbindung zu allen Partitionen in allen Cache-Servern her (nicht zu Replikaten, da Partitionen mit ihren Replikaten kommunizieren). Dadurch kann der Client direkt dorthin gehen, wo sich die Daten zum Lesen und Schreiben befinden. Und wenn dem Cluster ein neuer Server hinzugefügt wird, erhält der Client aktualisierte Cluster-Mitgliedschaftsinformationen und stellt dann auch eine Verbindung zu diesem neu hinzugefügten Cache-Server her.
• - Replizierter Cache: im Falle von Replizierter Cachestellt der Client nur eine Verbindung zu einem Cache-Server im Cluster her, jedoch mit Lastenausgleich, um sicherzustellen, dass alle Cache-Server über die gleiche Anzahl von Clients verfügen. Der Client erhält die Lastausgleichsinformationen von diesem Cache-Server und verbindet sich auf dieser Grundlage bei Bedarf erneut mit dem entsprechenden Cache-Server. Der Client verbindet sich nur mit einem Cache-Server, da jeder Server über den gesamten Cache verfügt, sodass alle Lese- und Schreibvorgänge direkt dort möglich sind.
• - Gespiegelter Cache: im Falle von Gespiegelter Cache, verbindet sich der Client einfach nur mit dem aktiven Knoten in diesem 2-Knoten-Cluster. Wenn sich der Client mit dem passiven Knoten verbindet, teilt der passive Knoten dem Client den aktiven Knoten mit und der Client verbindet sich automatisch wieder mit dem aktiven Knoten. Wenn der aktive Knoten ausfällt und der passive Knoten aktiv wird, verbinden sich alle Clients automatisch mit dem neuen aktiven Knoten.

Dynamische Konfiguration

NCache bietet auch eine dynamische Konfiguration des Caches und der Clients. Der Zweck besteht darin, Ihnen zu ermöglichen, später Änderungen vorzunehmen, wenn der Cache ausgeführt wird, ohne den Cache oder Ihre Anwendung zu stoppen.

• - Zur Laufzeit an alle Server und Clients weitergeben: Dazu gehören alle Konfigurationen und deren Änderungen sowie die Verteilungskarte.
• - Cache-Konfiguration: Wenn eine Cache-Konfiguration über Admin-Tools erstellt wird, werden diese Konfigurationsinformationen auf alle zu diesem Zeitpunkt bekannten Cache-Server kopiert. Und jeder neue Server, der zur Laufzeit hinzugefügt wird, empfängt diese gesamte Cache-Konfiguration und kopiert sie auf seine lokale Festplatte.
• - Konfigurationsänderungen im laufenden Betrieb anwenden: Sie können einen Teil der Cache-Konfiguration zur Laufzeit ändern, indem Sie „Heiß anwenden„Merkmal von NCache. Wenn Sie dies tun, werden die aktualisierten Konfigurationsinformationen zur Laufzeit an alle Cache-Server weitergegeben und auf deren Festplatten gespeichert. Ein Teil dieser Informationen wird auch an alle Kunden gesendet, die für ihre Bedürfnisse relevant sind.
• - Verteilungszuordnung (partitionierter/Partitions-Replikat-Cache): Wird beim Starten des Caches erstellt und dann auf alle Cache-Server und Cache-Clients kopiert. Diese Verteilungskarte enthält Informationen darüber, welche Buckets (von insgesamt 1000 Buckets im Cluster-Cache) sich auf welcher Partition befinden.

Verbindungs-Failover innerhalb des Clusters

Alle Cache-Server im Cluster sind über TCP miteinander verbunden. Und jeder Cache-Server ist mit allen anderen Cache-Servern im Cluster verbunden, einschließlich aller neu zur Laufzeit hinzugefügten Server. NCache bietet verschiedene Möglichkeiten, um sicherzustellen, dass alle Verbindungen innerhalb des Clusters trotz Verbindungsunterbrechung aufrechterhalten werden. Verbindungsunterbrechungen treten normalerweise aufgrund eines Netzwerkfehlers aufgrund eines Routers oder einer Firewall oder eines Problems mit der Netzwerkkarte oder dem Netzwerktreiber auf.

• - Verbindungsversuche: wenn die Verbindung zwischen zwei Cache-Servern unterbrochen wird, NCache Der Server unternimmt automatisch mehrere Wiederholungsversuche, um diese Verbindung herzustellen. Diese Wiederholungen werden durchgeführt, bis die „Timeout“-Periode aufgebraucht ist. In den meisten Situationen wird dadurch die Verbindung wiederhergestellt.
• - Keep-Alive-Herzschlag: NCache hat auch eine Funktion, mit der jeder Cache-Server einige kleine Datenpakete als Herzschlag an alle anderen Server senden kann. Dadurch wird sichergestellt, dass die Cache-Server bei einem Problem mit einem Ausfall des Netzwerk-Sockets davon erfahren und es durch Wiederholungsversuche beheben.
• - Teilweise verbundene Server: Trotz Wiederholungsversuchen kann es vorkommen, dass eine Verbindung nicht innerhalb des Timeout-Zeitraums wiederhergestellt wird und ein Cache-Server davon ausgeht, dass einer oder mehrere der anderen Cache-Server ausgefallen sind. Es funktioniert also auch ohne sie weiter. In Wirklichkeit sind die anderen Server jedoch nicht ausgefallen und werden tatsächlich von einigen anderen Servern im Cluster erkannt. Dies wird als teilweise verbundene Server bezeichnet. Wenn dies geschieht, nimmt der Cluster-Koordinator dies zur Kenntnis und entfernt den „Teilweise verbundenen“ Server zwangsweise aus dem Cluster. Dadurch wird der Cluster wieder gesund. Und der entfernte Server kann durch manuelles Eingreifen wieder dem Cluster beitreten.

Verbindungs-Failover mit Clients

Alle Cache-Clients sind abhängig von den Caching-Topologien über TCP mit einem oder mehreren Cache-Servern im Cluster verbunden. Beim partitionierten/partitionierten Replikat-Cache ist jeder Client mit allen Cache-Servern verbunden. Beim replizierten Cache ist jeder Client normalerweise über einen von den Cache-Servern verwendeten Lastausgleichsalgorithmus mit nur einem der Cache-Server verbunden. Und für Mirrored Cache sind alle Clients nur mit dem aktiven Knoten verbunden und verbinden sich nur mit dem passiven Knoten, wenn der aktive Knoten ausfällt und der passive Knoten zum aktiven Knoten wird.

• - Verbindungsversuche: Wenn eine Verbindung zwischen einem Client und Cache-Servern unterbrochen wird, NCache Der Client tut dies automatisch mehrere Verbindungsversuche um diese Verbindung herzustellen. Diese Wiederholungen werden durchgeführt, bis die "Timeout"-Periode aufgebraucht ist. In den meisten Situationen wird dadurch die Verbindung wiederhergestellt, ohne dass die Client-Anwendung dies überhaupt bemerkt. Wenn keine Verbindung hergestellt werden kann, wird eine Ausnahme an die Clientanwendung geworfen, damit sie damit umgehen kann.
• - Keep-Alive-Herzschlag: NCache hat auch eine Funktion, mit der jeder Client einige kleine Datenpakete senden kann Herzschlag an alle Cache-Server, mit denen es verbunden ist. Dadurch wird sichergestellt, dass der Client bei einem Problem mit einem Netzwerk-Socket-Fehler davon erfährt und es durch erneute Verbindungsversuche behebt.
• - Teilweise verbundene Clients (partitionierter/Partitionsreplikat-Cache): Trotz Wiederholungsversuchen kann es vorkommen, dass eine Verbindung nicht innerhalb des Timeout-Zeitraums wiederhergestellt wird und ein Cache-Client davon ausgeht, dass er einen oder mehrere der anderen Cache-Server nicht erreichen kann, auch wenn diese möglicherweise nicht ausgefallen sind. Im Fall von Partitioned/Partition-Replica Cache interagiert er also mit anderen Servern, um alle Daten zu lesen oder zu schreiben, obwohl seine Verteilungszuordnung ihm mitteilt, 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 den Vorgang erfolgreich durchzuführen.
• - Trennung mit Server (replizierter/gespiegelter Cache): Im Falle von Replicated Cache ist der Client nur mit einem Server verbunden und wenn diese Verbindung unterbrochen wird, verbindet sich der Client automatisch mit einem der anderen Cache-Server. Wenn der Client im Falle eines gespiegelten Caches keine Verbindung zum aktiven Knoten herstellen kann, geht er davon aus, dass er ausgefallen ist, und versucht, eine Verbindung zum passiven Knoten herzustellen.

Caching-Topologien (lineare Skalierbarkeit)

NCache bietet eine Vielzahl von Caching-Topologien, um eine lineare Skalierbarkeit zu ermöglichen und gleichzeitig Datenkonsistenz und Zuverlässigkeit zu gewährleisten. Das Ziel besteht darin, die Anforderungen von Anwendungen zu erfüllen, die mit sehr kleinen Zwei-Server-Caches bis hin zu sehr großen Cache-Clustern laufen, die aus Dutzenden oder sogar Hunderten von Cache-Servern bestehen. Eine Caching-Topologie ist im Wesentlichen eine Datenspeicherungs-, Datenreplikations- und Clientverbindungsstrategie in einem geclusterten Cache, der sich über mehrere Cache-Server erstreckt.

Referenzdaten vs. Transaktionsdaten

Referenzdaten sind Daten, die sich nicht sehr häufig ändern und die Sie zwischenspeichern, um sie immer wieder zu erreichen und gelegentlich zu aktualisieren. Transaktionsdaten hingegen sind Daten, die sich sehr häufig ändern, und Sie können sie so oft aktualisieren, wie Sie sie lesen.

In der Anfangszeit galt ein Cache vor allem für Referenzdaten als gut, da häufig geänderte Daten veraltet waren und nicht mehr mit den neuesten Daten in der Datenbank synchronisiert waren. Jedoch, NCache bietet jetzt sehr leistungsstarke Funktionen, die es dem Cache ermöglichen, seine zwischengespeicherten Daten mit der Datenbank zu synchronisieren.

Alle Caching-Topologien eignen sich gut für Referenzdaten, aber nur einige Caching-Topologien eignen sich besonders gut für Transaktionsdaten. Sie müssen bestimmen, wie viele Lese- und Schreibvorgänge Sie durchführen werden, um herauszufinden, welche Topologie für Sie am besten geeignet ist. Darüber hinaus lassen sich einige Caching-Topologien nicht so gut skalieren, insbesondere bei Updates. Denken Sie also auch daran.

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

• - Partitionierter Cache (keine Replikation): Sehr gute. Superschnell für Lese- und Schreibvorgänge und auch linear skaliert durch Hinzufügen von Servern. Schnellste Topologie, repliziert aber keine Daten, sodass es zu Datenverlusten kommt, wenn ein Cache-Server ausfällt.
• - Partitionsreplikat-Cache (Am beliebtesten): Sehr gute. Superschnell für Lese- und Schreibvorgänge und auch durch das Hinzufügen von Servern linear skalierbar. Zweitschnellste Topologie, repliziert jedoch Daten für Zuverlässigkeit, ohne die lineare Skalierbarkeit zu beeinträchtigen. Die beste Kombination aus Geschwindigkeit/Skalierbarkeit und Datenzuverlässigkeit.
• - Replizierter Cache: Sehr gut für kleinere Umgebungen. Superschnell und linear skalierbar für Lesevorgänge. Mäßig schnell für Schreibvorgänge in einem 2-Knoten-Cluster, skaliert jedoch nicht, wenn Sie weitere Server hinzufügen, da Schreibvorgänge synchron auf allen Cache-Servern erfolgen.
• - Gespiegelter Cache: Sehr gut für kleinere Umgebungen. Superschnell zum Lesen. Schreibvorgänge sind schneller als der replizierte Cache für 2-Knoten-Aktiv/Passiv. Aber es geht nicht darüber hinaus.
• - Client-Cache: Sehr gut für leseintensiven Gebrauch mit allen Caching-Topologien. Ermöglicht das Erreichen von InProc-Geschwindigkeit mit einem verteilten Cache.

Partitionierter Cache

Partitionierter Cache ist die schnellste und am besten skalierbare Caching-Topologie für Lese- und Schreibvorgänge. Er ist für größere Cache-Cluster gedacht und die Performance beim Lesen und Schreiben bleibt auch bei Spitzenlasten sehr gut. Es werden jedoch keine Daten repliziert, und daher kommt es zu Datenverlusten, wenn ein Cache-Server ausfällt.

Hier sind einige Merkmale des partitionierten Caches.

• - Dynamische Partitionen: Der Cache wird zur Laufzeit in Partitionen unterteilt, wobei jeder Cache-Server über eine Partition verfügt. Es gibt insgesamt 1000 Buckets pro Cluster-Cache, die gleichmäßig auf alle Partitionen verteilt sind. Das Hinzufügen/Entfernen eines Cache-Servers führt zur Erstellung/Löschung von Partitionen zur Laufzeit. Die Zuordnung der Buckets zu Partitionen ändert sich nicht, wenn Daten zum Cache hinzugefügt werden. Stattdessen ändert es sich nur, wenn Partitionen hinzugefügt oder gelöscht werden oder wenn ein Datenausgleich stattfindet (siehe unten).
• - Verbreitungskarte: Der Cache-Cluster erstellt eine Verteilungszuordnung, die Informationen darüber enthält, welche Buckets in welchen Partitionen vorhanden sind. Die Verteilungskarte wird jedes Mal aktualisiert, wenn Partitionen hinzugefügt oder gelöscht werden oder wenn ein Datenausgleich stattfindet (siehe unten). Die Verteilungszuordnung wird an alle Server und Clients weitergegeben. Die Clients nutzen dies, um herauszufinden, mit welchem ​​Cache-Server sie kommunizieren müssen, um ein bestimmtes zwischengespeichertes Element zu lesen oder zu schreiben.
• - Dynamischer Datenausgleich: Da es sich bei allen Buckets tatsächlich um HashMap-Buckets handelt, in denen Daten basierend auf einem Hashing-Algorithmus für die Schlüssel gespeichert werden, besteht die Möglichkeit, dass einige Buckets je nach den verwendeten Schlüsseln mehr Daten enthalten als andere. Wenn dieses Ungleichgewicht einen konfigurierbaren Schwellenwert überschreitet, NCache verschiebt automatisch Schaufeln, um diese Last auszugleichen.
• - Clients stellen eine Verbindung zu ALLEN Partitionen her: Clients stellen eine Verbindung zu allen Cache-Servern her, sodass sie Daten in einer Anfrage direkt vom Server lesen oder schreiben können. Wenn die Verbindung eines Clients mit einem Cache-Server ausfällt, fordert er einen der anderen Server auf, ein zwischengespeichertes Element zu lesen oder zu schreiben, das auf dem Server vorhanden ist und auf das er nicht zugreifen kann. Und dieser Server hilft dem Client dabei, dies zu erreichen.

Partitionsreplikat-Cache

HINWEIS: Alles, was in Partitioned Cache erwähnt wird, trifft auch hier zu.

Genau wie Partitionierter Cache, Partition-Replica Cache ist eine extrem schnelle und linear skalierbare Caching-Topologie für Lese- und Schreibvorgänge. Er ist für größere Cache-Cluster gedacht und die Performance beim Lesen und Schreiben bleibt auch bei Spitzenlasten sehr gut. Darüber hinaus repliziert Partition-Replica Cache auch Daten, sodass selbst bei einem Ausfall eines Cache-Servers kein Datenverlust auftritt.

Partition-Replica Cache ist unser 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 deren 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 der Partition zum Replikat asynchron. Das bedeutet, dass der Client beliebige Daten in der Partition hinzufügen, aktualisieren oder löschen kann und alle diese Vorgänge in die Warteschlange gestellt werden. Und dann werden sie in großen Mengen auf der Replik repliziert. Dies verbessert die Leistung, birgt jedoch das geringe Risiko eines Datenverlusts, falls eine Partition ausfällt und nicht alle Aktualisierungen auf das Replikat repliziert wurden. Aber in den meisten Situationen ist das völlig in Ordnung.
• - Replikation synchronisieren: Wenn Ihre Daten sehr vertraulich sind (z. B. Finanzdaten) und Sie es sich nicht leisten können, jemals über veraltete Daten zu verfügen, können Sie in der Konfiguration die Option „Replikation synchronisieren“ wählen. Wenn diese Option ausgewählt ist, 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 auf diese Weise auch auf der Partition fehl. Und Sie können sicher sein, dass alle Daten im Cache (sowohl in der Partition als auch im Replikat) immer 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): dasselbe wie Partitionierter Cache. Im Partition-Replica-Cache erfolgt der Datenausgleich jedoch auch in den Replikaten, wenn die Partitionen datenausgleichend sind.
• - Clients stellen eine Verbindung zu ALLEN Partitionen her: dasselbe wie Partitionierter Cache. Darüber hinaus kommunizieren die Clients im Partition-Replica-Cache nur mit Partitionen und nicht mit deren Replikaten. Dies liegt daran, dass Replikate passiv sind und nur Partitionen mit ihren Replikaten kommunizieren, wenn sie Daten auf sie replizieren.

Replizierter Cache

Replizierter Cache bietet Datenzuverlässigkeit durch Replikation auf zwei oder mehr Cache-Servern. Es ist sehr schnell und skalierbar für Lesevorgänge. Es lässt sich jedoch nicht für Schreibvorgänge skalieren, da diese mit allen Servern im Cluster synchron sind. Bei einem 2-Knoten-Cluster sind die Schreibvorgänge schneller als in Ihrer Datenbank, aber nicht so schnell wie im Partition-Replica-Cache. Bei 3 oder mehr Serverclustern nimmt die Schreibleistung ab und wird schließlich unattraktiv.

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 anzuhalten. Der neu hinzugefügte Server erstellt eine Kopie (Replik) des gesamten Caches auf sich selbst. Und der entfernte Server aktualisiert 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: Lesevorgänge sind superschnell und skalierbar, wenn Sie weitere Server hinzufügen. Das Hinzufügen weiterer Server erhöht jedoch nicht die Cache-Größ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, was bedeutet, dass jeder Schreibvorgang erst abgeschlossen wird, wenn alle Cache-Server synchron aktualisiert sind. Aus diesem Grund sind Schreibvorgänge nicht so schnell wie bei anderen Topologien und ihre Leistung nimmt ab, wenn Sie die Clustergröße über 2 Knoten hinaus erhöhen.
• - Der Client stellt nur eine Verbindung zu einem Server her: Jeder Cache-Client stellt nur eine Verbindung zu einem Server im Cluster her, basierend auf einem von den Cache-Servern festgelegten Lastausgleichsalgorithmus. Wenn dieser Cache-Server ausfällt, stellt der Client eine Verbindung zum nächsten Server in der Liste her. Sie können in der Cache-Konfigurationsdatei auch manuell den Server angeben, zu dem eine Verbindung hergestellt werden soll, wenn Sie den Lastausgleich nicht verwenden möchten.

Gespiegelter Cache

Mirrored Cache ist ein Aktiv/Passiv-Cache-Cluster mit zwei Knoten, der für kleinere Umgebungen gedacht ist. Es bietet Datenzuverlässigkeit durch asynchrone Replikation/Spiegelung vom aktiven Knoten zum passiven Knoten. Es ist sowohl für Lese- als auch für Schreibvorgänge sehr schnell (tatsächlich sind Schreibvorgänge schneller als der replizierte Cache), lässt sich jedoch 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: Mirrored Cache hat nur zwei Server. Einer ist aktiv und der andere ist passiv. Beide haben eine Kopie des gesamten Caches. Wenn der aktive Server ausfällt, wird der passive Server automatisch aktiv. Und wenn der zuvor ausgefallene aktive Server wieder hochfährt, wird er als passiver Server behandelt, es sei denn, Sie ändern diese Bezeichnung zur Laufzeit über Admin-Tools.
• - Clientverbindungen mit Failover-Unterstützung: Jeder Cache-Client stellt nur eine Verbindung zum aktiven Server im Cluster her, um seine Lese- und Schreibvorgänge auszuführen. Wenn dieser aktive Server ausfällt, verbinden sich alle Clients automatisch mit dem inzwischen aktiven passiven Server. Diese Failover-Unterstützung stellt sicher, dass der gespiegelte Cache immer betriebsbereit ist, auch wenn ein Server ausfällt.
• - Asynchrone Spiegelung: Alle auf dem aktiven Server durchgeführten Schreibvorgänge werden asynchron auf dem passiven Server gespiegelt/repliziert. Dadurch wird sichergestellt, dass der Passivserver immer mit den neuesten Daten synchronisiert ist, falls der Aktivserver ausfällt und der Passivserver aktiv werden muss. Asynchrone Spiegelung bedeutet auch eine schnellere Leistung, da mehrere Schreibvorgänge als BULK-Vorgang auf dem Passivserver ausgeführt werden.

Client-Cache (InProc-Geschwindigkeit)

Der Client-Cache ist lokal auf Ihrem Web-/Anwendungsserver und befindet sich sehr nahe an Ihrer Anwendung und ermöglicht Ihnen das Zwischenspeichern von Daten, die Sie aus dem verteilten Cache lesen (jede Caching-Topologie). Sie können dies als „Cache auf einem Cache“ sehen und die Leistung und Skalierbarkeit Ihrer Anwendung noch weiter verbessern. Wenn Sie Client Cache im InProc-Modus verwenden, können Sie InProc-Geschwindigkeit erreichen.

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 ist nur dann sinnvoll, wenn Sie einen leseintensiven Anwendungsfall haben, bei dem die Anzahl der Lesevorgänge um ein Vielfaches höher ist als die der Schreibvorgänge. Wenn die Anzahl der Schreibvorgänge mit der Anzahl der Lesevorgänge übereinstimmt, ist der Client-Cache tatsächlich langsamer, da ein Schreibvorgang eine Aktualisierung an zwei Stellen erfordert.
• - Höhere Geschwindigkeit wie ein lokaler Cache (InProc / OutProc): Ein Client-Cache ist entweder innerhalb Ihres Anwendungsprozesses (InProc-Modus) oder lokal auf Ihrem Web-/App-Server (OutProc-Modus) vorhanden. In beiden Fällen steigert es die Leistung Ihrer Anwendung erheblich im Vergleich zum bloßen Abrufen dieser Daten aus dem Cluster-Cache. Im InProc-Modus können Sie Objekte auf Ihrem „Anwendungsheap“ zwischenspeichern, wodurch Sie eine „InProc-Geschwindigkeit“ erhalten, die von keinem verteilten Cache erreicht werden kann.
• - Kein eigenständiger Cache: Der Client-Cache ist möglicherweise ein lokaler Cache, aber kein eigenständiger Cache. Stattdessen hält es sich selbst mit dem Cluster-Cache synchronisiert. Das bedeutet, dass, wenn ein anderer Client Daten im Cluster-Cache aktualisiert, den Sie in Ihrem Client-Cache haben, der Cluster-Cache den Client-Cache benachrichtigt, sich selbst mit der neuesten Kopie dieser Daten zu aktualisieren. Und dies geschieht asynchron, aber sofort.
• - Optimistische / pessimistische Synchronisation: Standardmäßig verwendet Client Cache die optimistische Synchronisierung, was bedeutet, dass NCache Der Client geht davon aus, dass alle Daten, die der Client-Cache enthält, die neueste Kopie sind. Wenn der Client-Cache keine Daten hat, ruft der Client sie aus dem Clustered Cache ab, legt sie in den Client-Cache und gibt sie an die Client-Anwendung zurück. Pessimistische Synchronisierung bedeutet, dass der Cache-Client zuerst den Clustered Cache überprüft, ob er eine neuere Version eines zwischengespeicherten Elements enthält. Wenn dies der Fall ist, ruft der Client sie ab, legt sie in den Client-Cache und gibt sie an die Client-Anwendung zurück. Andernfalls wird alles zurückgegeben, was sich im Client-Cache befindet.
• - Plug-in ohne Code-Änderung: Das Beste am Client Cache ist, dass keine Codeänderung in Ihrer Anwendung erforderlich ist. Stattdessen schließen Sie es einfach über eine Konfigurationsänderung an. Und, NCache Die Client-API hinter den Kulissen weiß, was bei der Verwendung des Client-Cache zu tun ist.

Was macht man als nächstes?

• NCache Details
• Herunterladen NCache
• Editionsvergleich