Caching-Topologien für 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.

Nachfolgend sind die wichtigsten Caching-Topologien aufgeführt, die NCache anbieten:

1. Partitionierter Cache
2. Partitionsreplikat-Cache
3. Replizierter Cache
4. Gespiegelter Cache (2 Knoten aktiv/passiv)
5. Client-Cache (InProc-Geschwindigkeit; lokaler Cache mit Clustered-Cache verbunden)

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.

Das Zwischenspeichern eines Produktkatalogs, in dem sich die Preise nicht sehr häufig ändern, sind Referenzdaten. Auf der anderen Seite ASP.NET Core Die Sitzungsspeicherung wird als transaktionale Verwendung betrachtet, da eine Sitzung einmal bei jeder Webanforderung gelesen und aktualisiert wird, was alle paar Sekunden geschehen kann.

Früher wurde ein Cache hauptsächlich für Referenzdaten als gut angesehen, da häufig geänderte Daten veraltet und nicht mehr mit den neuesten Daten in der Datenbank synchron waren. Aber, 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 skalieren einige Caching-Topologien speziell für Updates nicht so stark, also denken Sie auch daran.

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

1. 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.
2. Partitionsreplikat-Cache (Am beliebtesten): Sehr gute. Superschnell für Lese- und Schreibvorgänge und auch linear skaliert durch Hinzufügen von Servern. Zweitschnellste Topologie, repliziert Daten jedoch aus Gründen der Zuverlässigkeit, ohne die lineare Skalierbarkeit zu beeinträchtigen. Beste Kombination aus Geschwindigkeit/Skalierbarkeit und Datenzuverlässigkeit.
3. Replizierter Cache: Sehr gut für kleinere Umgebungen. Superschnell und linear skalierbar für Lesevorgänge. Moderat 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 ausgeführt werden.
4. Gespiegelter Cache: Sehr gut für kleinere Umgebungen. Superschnell zum Lesen. Schreibvorgänge sind schneller als Replicated Cache for 2-Node Active/Passive. Skaliert aber nicht darüber hinaus.
5. Client-Cache: Sehr gut für leseintensiven Gebrauch mit allen Caching-Topologien. Ermöglicht es Ihnen, InProc-Geschwindigkeit mit verteiltem Cache zu erreichen.

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.

1. Dynamische Partitionen: Cache wird zur Laufzeit in Partitionen aufgeteilt, wobei jeder Cache-Server eine Partition hat. Es gibt insgesamt 1000 Buckets pro Cluster-Cache, die gleichmäßig auf alle Partitionen verteilt sind. Das Hinzufügen/Entfernen von Cache-Servern führt zur Erstellung/Löschung von Partitionen zur Laufzeit. Die Bucket-Zuweisung 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).
2. Verbreitungskarte: Der Cache-Cluster erstellt eine Verteilungskarte, die Informationen darüber enthält, welche Buckets in welchen Partitionen vorhanden sind. Die Verteilungskarte wird immer dann aktualisiert, wenn Partitionen hinzugefügt oder gelöscht werden oder wenn ein Datenausgleich stattfindet (siehe unten). Distribution Map wird an alle Server und Clients weitergegeben. Die Clients verwenden dies, um herauszufinden, mit welchem ​​Cache-Server sie sprechen müssen, um ein bestimmtes zwischengespeichertes Element zu lesen oder zu schreiben.
3. Dynamischer Datenausgleich: Da alle Buckets tatsächlich HashMap-Buckets sind, in denen Daten basierend auf einem Hashing-Algorithmus auf den Schlüsseln gespeichert werden, besteht die Möglichkeit, dass einige Buckets mehr Daten enthalten als andere, je nachdem, welche Schlüssel verwendet wurden. Wenn dieses Ungleichgewicht einen konfigurierbaren Schwellenwert überschreitet, NCache verschiebt automatisch Schaufeln, um diese Last auszugleichen.
4. Clients verbinden sich mit ALLEN Partitionen: Clients stellen eine Verbindung zu allen Cache-Servern her, sodass sie Daten in einer Anfrage vom Server direkt lesen oder schreiben können. Wenn die Verbindung eines Clients mit einem Cache-Server unterbrochen wird, fordert er einen der anderen Server auf, ein zwischengespeichertes Element zu lesen oder zu schreiben, das auf dem Server vorhanden ist, auf das er nicht zugreifen kann. Und dieser Server hilft dem Client, 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.

1. Dynamische Partitionen: wie Partitionierter Cache.
2. Dynamische Replikate: Wenn Partitionen zur Laufzeit erstellt oder gelöscht werden, werden ihre Replicas ebenfalls erstellt oder gelöscht. Replicas befinden sich immer auf einem anderen Cache-Server und es gibt nur ein Replica für eine Partition.
3. Asynchrone Replikation: Standardmäßig ist 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 Operationen in die Warteschlange gestellt werden. Und dann werden sie in BULK 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.
4. Replikation synchronisieren: Wenn Ihre Daten sehr sensibel sind (z. B. Finanzdaten) und Sie es sich nicht leisten können, jemals veraltete Daten zu haben, können Sie die Option „Replikation synchronisieren“ in der Konfiguration auswählen. Wenn diese Option ausgewählt ist, werden alle Schreibvorgänge synchron auf Partition und Replikat ausgeführt, bis sie als abgeschlossen betrachtet werden. Wenn der Vorgang auf dem Replikat fehlschlägt, schlägt er auf diese Weise auch auf der Partition fehl. Und Sie können garantieren, dass alle Daten im Cache (sowohl in der Partition als auch im Replikat) immer konsistent sind. Dies wirkt sich jedoch auf die Leistung aus, da es langsamer als die asynchrone Replikation ist.
5. Verbreitungskarte: wie Partitionierter Cache.
6. Dynamischer Datenausgleich (Partitionen & Replikate): wie Partitionierter Cache. Im Partition-Replica Cache findet der Datenausgleich jedoch auch in den Replicas statt, wenn die Partitionen datenausgeglichen sind.
7. Clients verbinden sich mit ALLEN Partitionen: wie Partitionierter Cache. Darüber hinaus kommunizieren die Clients im Partition-Replica Cache nur mit Partitionen und nicht mit ihren Repliken. Dies liegt daran, dass Replikate passiv sind und nur Partitionen mit ihren Replikaten kommunizieren, wenn sie Daten an sie replizieren.

Replizierter Cache

Replicated Cache bietet Datenzuverlässigkeit durch Replikation auf zwei oder mehr Cache-Servern. Es ist sehr schnell und für Lesevorgänge skalierbar. Schreibvorgänge werden jedoch nicht skaliert, da sie mit allen Servern im Cluster synchron sind. Bei einem 2-Knoten-Cluster sind die Schreibvorgänge schneller als Ihre Datenbank, aber nicht so schnell wie Partitionsreplikat-Cache. Bei Clustern mit 3 oder mehr Servern verschlechtert sich die Schreibleistung und wird schließlich unattraktiv.

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

1. 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. Ein neu hinzugefügter Server erstellt eine Kopie (Replica) des gesamten Caches auf sich selbst. Und der entfernte Server aktualisiert die Cluster-Mitgliedschaft, und alle seine Clients werden auf andere Server verschoben.
2. Gesamter Cache auf jedem Knoten: Der gesamte Cache wird auf jeden Server im Cluster kopiert.
3. 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 nur eine weitere Kopie des gesamten Caches ist.
4. Schreibvorgänge sind Synchronous: Schreibvorgänge sind für einen 2-Knoten-Cluster sehr schnell und schneller als Ihre Datenbank. Schreibvorgänge sind jedoch synchron, was bedeutet, dass jeder Schreibvorgang nicht abgeschlossen wird, bis alle Cache-Server synchron aktualisiert wurden. 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.
5. Client verbindet sich nur mit einem Server: Jeder Cache-Client stellt nur eine Verbindung zu einem Server im Cluster her, basierend auf einem Lastausgleichsalgorithmus, der von den Cache-Servern bestimmt wird. Wenn dieser Cache-Server ausfällt, verbindet sich der Client mit dem nächsten Server in der Liste. Sie können den Server, zu dem eine Verbindung hergestellt werden soll, auch manuell in der Cache-Konfigurationsdatei angeben, wenn Sie den Lastenausgleich nicht verwenden möchten.

Gespiegelter Cache

Mirrored Cache ist ein Aktiv/Passiv-Cache-Cluster mit 2 Knoten, der für kleinere Umgebungen vorgesehen ist. Es bietet Datenzuverlässigkeit durch asynchrone Replikation/Spiegelung von Active Node zu Passive Node. Es ist sowohl beim Lesen als auch beim Schreiben sehr schnell (tatsächlich sind Schreibvorgänge schneller als Replizierter Cache), skaliert jedoch nicht über diesen 2-Knoten-Aktiv/Passiv-Cluster hinaus.

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

1. 1 aktiver & 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 heruntergefahrene aktive Server wieder hochgefahren wird, wird er als passiver Server behandelt, es sei denn, Sie ändern diese Bezeichnung zur Laufzeit über Admin-Tools.
2. Clientverbindungen mit Failover-Unterstützung: Jeder Cache-Client verbindet sich nur mit dem Active Server im Cluster, um seine Lese- und Schreiboperationen durchzuführen. 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 immer betriebsbereit ist, selbst wenn ein Server ausfällt.
3. 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 wird, falls der Active Server ausfällt und der Passive Server aktiv werden muss. Asynchrone Spiegelung bedeutet auch eine schnellere Leistung, da mehrere Schreibvorgänge als BULK-Vorgang auf dem passiven Server 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.

1. Gut für leseintensive Fälle: Der Client-Cache ist nur dann gut, 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 der Lesevorgänge entspricht, ist der Client-Cache tatsächlich langsamer, da ein Schreibvorgang eine Aktualisierung an zwei Stellen erfordert.
2. Schnellere Geschwindigkeit wie ein lokaler Cache (InProc / OutProc): Ein Client-Cache existiert entweder innerhalb Ihres Anwendungsprozesses (InProc-Modus) oder lokal auf Ihrem Web-/App-Server (OutProc-Modus). In beiden Fällen wird Ihre Anwendungsleistung erheblich gesteigert, verglichen mit dem einfachen Abrufen dieser Daten aus dem Cluster-Cache. Im InProc-Modus können Sie Objekte auf Ihrem „Anwendungs-Heap“ zwischenspeichern, wodurch Sie eine „InProc-Geschwindigkeit“ erhalten, die von keinem verteilten Cache erreicht werden kann.
3. Kein eigenständiger Cache: Der Client-Cache kann ein lokaler Cache sein, aber es ist kein eigenständiger Cache. Stattdessen hält es sich selbst mit dem gruppierten Cache synchronisiert. Dies bedeutet Folgendes: Wenn ein anderer Client Daten im Cluster-Cache aktualisiert, den Sie in Ihrem Client-Cache haben, benachrichtigt der Cluster-Cache den Client-Cache, sich selbst mit der neuesten Kopie dieser Daten zu aktualisieren. Und dies geschieht asynchron, aber sofort.
4. Optimistische/pessimistische Synchronisation: Standardmäßig verwendet der 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.
5. Plug-in ohne Codeänderung: Das Beste am Client-Cache ist, dass es keine Codeänderung in Ihrer Anwendung erfordert. Stattdessen schließen Sie es einfach durch 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