NCache Architektur
Heute werde ich darüber sprechen NCache Architektur. NCache ist ein verteilter In-Memory-Speicher für .NET- und Java-Anwendungen. Es ist extrem schnell und skalierbar. Und Sie können es in Ihren Serveranwendungen mit hohem Transaktionsvolumen verwenden, um die Leistung und Skalierbarkeit Ihrer Anwendung zu steigern.
Gemeinsame Verwendung von NCache
Verteilter Cache
Die zwei gängigen Wege NCache wird eingesetzt. Nummer eins ist als Verteilter Cache wo Sie die Anwendungsdaten zwischenspeichern, um diese teuren Datenbankfahrten zu reduzieren, und Nummer zwei ist a Nachrichten und Streams Plattform. Ich werde beides kurz durchgehen, bevor ich auf die Architektur eingehe.
-
App-Daten-Caching
Im verteilten Cache bedeutet das Zwischenspeichern von Anwendungsdaten also, dass Sie einen verwenden NCache Die API dient normalerweise nur dazu, Ihre Anwendungsdaten zwischenzuspeichern, sodass Sie nicht so häufig auf die Datenbank zugreifen müssen, da der Cache viel schneller ist als die Datenbank. Außerdem ist es skalierbarer, da es sich im Speicher befindet und daher schnell ist. Da es nah an Ihrer Anwendung ist, ist es schnell und verteilt, sodass es skalierbar ist. Und wenn Sie eine .NET-Anwendung haben und EF Core verwenden, können Sie diese verwenden NCache auch über EF Core und auch NHibernate und EF 6. Wenn Sie über Java-Anwendungen verfügen, können Sie diese verwenden NCache als Hibernate-Second-Level-Cache. Sie können es auch als Spring Cache verwenden oder gegen JCache programmieren. -
Web-App-Caching
Der zweite Teil der verteilten Cache-Nutzung besteht darin, dass Sie Ihre Webanwendungen speichern können, wenn Sie über Webanwendungen verfügen Sitzungen in NCache und dann NCache repliziert diese Sitzungen auf mehrere Server, sodass, falls vorhanden, ein solcher vorhanden ist NCache Wenn ein Server ausfällt, verlieren Sie keine Daten, aber diese Sitzungen sind wieder sehr skalierbar, da es sich um einen verteilten Speicher handelt und offensichtlich superschnell ist. Es gibt auch eine Multi-Site-Sitzungsfunktion, die in allen Sprachen .NET, Java, Nodejs usw. verfügbar ist. Zusätzlich zu Sitzungen, beispielsweise für .NET 6, ASP.NET Core Anwendungen können ihre speichern Antwortcache in NCache und sie können auch verwenden NCache wie die Rückwandplatine für SignalR. SignalR ist für Live-Webanwendungen gedacht, bei denen die Web-App Ereignisse an die Clients senden muss. Und wenn Sie .NET 4.8 verwenden, können Sie auch Ihren Sitzungsstatus speichern, Sichtzustand, Ausgabe-Cache, und auch SignalR.
NCache für geschäftskritische Apps
Lassen Sie mich Ihnen schnell zeigen, was NCache sieht aus wie. Dies ist ein verteilter Cache für geschäftskritische Anwendungen. Ich verwende das Wort geschäftskritisch, weil wir in den meisten Fällen sehen, dass es Kunden gibt NCache in sehr sensiblen, kundenorientierten Anwendungen, die für ihr Geschäft sehr wichtig sind. Also, NCache ist in diesem Fall, wie Sie wissen, Teil Ihrer sehr kritischen Infrastruktur.
Und das sind, wie gesagt, Serveranwendungen mit hohem Transaktionsaufwand. Dabei handelt es sich um Webanwendungen. Dies sind Microservices, Web-APIs oder andere Serveranwendungen. Natürlich können Sie .NET, Java, Node.js oder Python verwenden. Und diese Anwendungen versuchen, auf Ihre Datenbank zuzugreifen, entweder als SQL Server, Oracle, Db2, MySQL oder eine andere relationale Datenbank, oder sie greifen möglicherweise auf Ihre alten Mainframe-Daten zu oder verwenden möglicherweise eine NoSQL database wie Mongo DB, Cosmos DB, Cassandra oder andere. In dieser Situation, NCache wird zu einem verteilten Cache, indem ... Sie ihn verwenden NCache B. zwei oder mehr Server als separate Caching-Ebene. Obwohl Sie keine separate Caching-Ebene benötigen, kann Ihre Anwendung in derselben Box ausgeführt werden NCache und funktioniert einfach einwandfrei, aber die beliebtere Bereitstellungsarchitektur besteht darin, eine separate Caching-Ebene zu haben, das ist einfach eine sauberere Art der Nutzung NCache.
Nehmen wir an, Sie beginnen mit einem Cache-Cluster mit zwei Servern. NCache Gruppe, NCache bündelt den Arbeitsspeicher, die CPU und die Netzwerkkartenressourcen all dieser Server in einer logischen Kapazität, auf die Sie beispielsweise mehr Transaktionslast durch Ihre Anwendungen übertragen NCache und diese beiden Server ausgeschöpft sind, können Sie problemlos einen dritten Server, einen vierten Server, einen fünften Server usw. hinzufügen. NCache wird nie zu einem Engpass. Das ist etwas, was Sie mit Ihren Datenbanken nicht tun können. Datenbanken sind nicht skalierbar. NoSQL lässt sich zwar skalieren, aber in den meisten Fällen haben wir festgestellt, dass Menschen aus verschiedenen geschäftlichen Gründen relationale Datenbanken verwenden müssen und außerdem über veraltete Mainframes verfügen. Weil die Datenspeicherschicht also nicht skaliert werden kann NCache hilft Ihrer Anwendung bei der Skalierung, indem Sie so viele Daten wie möglich zwischenspeichern können. Das allgemeine Ziel besteht darin, etwa 80 % der Zeit zur Verfügung zu haben, aus der Sie die Daten finden sollten NCache anstatt in Ihre Datenbank zu gehen. Wenn Sie dieses Verhältnis erreichen können, haben Sie die Datenbanken entlastet und Ihre Anwendung wird skalierbar sein.
Nachrichten und Streams
Der zweite häufige Anwendungsfall oder die Verwendung von NCache besteht darin, es als Messaging- und Streams-Plattform zu verwenden, über die mehrere Anwendungen miteinander kommunizieren können Pub/Sub-MessagingDurch Kontinuierliche Abfrage, oder NCache basierte Veranstaltungen. Ich zeige Ihnen, wie das aussieht. Wenn Sie beispielsweise über eine Serveranwendung mit hohem Transaktionsvolumen verfügen, die viel Echtzeit-Messaging oder Stream-Verarbeitung durchführen muss, können Sie diese verwenden NCache. Jetzt das Gleiche NCache Was einst ein verteilter Cache war, wird nun zu einer Messaging- und Stream-Plattform. Auch hier handelt es sich um einen In-Memory Distributed Store. Es skaliert linear. Es repliziert die Nachrichten auf mehreren Servern. Tatsächlich, NCache hat auch Beharrlichkeit in sich.
Damit können Sie also verschiedene Anwendungen haben, zum Beispiel ist Pub/Sub-Messaging eine sehr beliebte Methode, es ist eine Methodik, es ist ein Paradigma, bei dem Sie mehrere Herausgeber und mehrere Abonnenten haben, die entkoppelt miteinander kommunizieren können. Entkoppelt bedeutet, dass der Herausgeber nicht weiß, wer der Abonnent ist. Er veröffentlicht lediglich Nachrichten zu bestimmten Themen und diese Abonnenten können sie erhalten. Kontinuierliche Abfragen funktionieren auf die gleiche Weise. Das sind also die beiden gängigen Methoden NCache wird eingesetzt.
.NET vs. Java-Anwendungen
Lassen Sie uns nun darüber sprechen, wie NCache verarbeitet .NET- und Java-Anwendungen. NCache verfügt über eine einzigartige native Multiplattform-Fähigkeit, die Sie sehr interessant finden werden. Lassen Sie mich näher darauf eingehen.
.NET-Edition
NCache versucht, Ihnen eine native Lösung sowohl für .NET als auch für Java bereitzustellen. Und damit meine ich, dass wenn Sie eine .NET-Anwendung haben, Ihr gesamter Anwendungsstapel .NET nutzt und Sie nichts anderes als .NET verwenden. Also zum Beispiel NCache verfügt über einen nativen .NET-Client, den Ihre Anwendung in Ihrer Anwendung verwenden wird. Dies läuft auf Ihrem Anwendungsserver und NCache hat dies zu 100 % in „C Sharp“ (C#) entwickelt.
Wenn Sie über serverseitigen Code wie „Read-through“, „Write-through“, „Right-behind“ oder „Loader/Refresher“ verfügen, den Sie in .NET geschrieben haben, NCache führt diesen Code in seinem eigenen .NET CLR-Prozess aus. Lassen Sie mich Ihnen zeigen, wie. Und ich werde immer wieder auf dieses Diagramm zurückkommen. Hier ist zum Beispiel ein NCache Architektur haben Sie hier eine .NET-Anwendung, die möglicherweise unter Windows oder Linux läuft. Es hat einen Eingeborenen NCache .NET-Client. Und das ist ein Gespräch mit einem NCache Cluster, der eine .NET Edition ist NCache Cluster. Das bedeutet also, dass der serverseitige Code ebenfalls .NET ist.
Nun der Weg NCache ist so konzipiert, dass es für die native Multiplattform-Unterstützung wirklich leistungsstark ist, weil es einen Cache-Prozess und einen Verwaltungsprozess gibt, die von Ihrem serverseitigen Codeprozess getrennt sind. Und es gibt einen sehr leistungsstarken RPC. Es ist ein In-Memory-RPC NCache nutzt, das NCache hat einen eigenen proprietären RPC entwickelt, der superschnell ist. Auf diese Weise kommuniziert der Cache also mit Ihrem serverseitigen Code. Wenn also beispielsweise der Read-through-Handler aufgerufen werden muss, wird Ihr Read-through-Handler in diesem .NET CLR-Prozess ausgeführt, um zu Ihrer Datenbank zu gelangen, um die Daten abzurufen, und übergibt sie dann an den Cache. Und das Gleiche gilt für Write-through, den Loader und den Refresher. Das gesamte Erlebnis Ihrer Anwendung ist also .NET.
Java-Edition
Nun, wechseln wir zur Java-Seite. Auch hier haben Sie auf die gleiche Weise einen serverseitigen Java-Code. NCache verfügt über einen 100 % Java-Client, der auf Ihrem Anwendungsserver und dann auf die gleiche Weise wie .NET ausgeführt wird. Hier ist die Java Edition. Nehmen wir an, Sie haben eine Java-Anwendung, die höchstwahrscheinlich unter Linux läuft, oder vielleicht sogar unter Windows, vielleicht Docker, vielleicht Kubernetes. Diese Anwendung wird also das einbetten NCache Java-Client, der, wie ich bereits sagte, zu 100 % natives Java ist, und dieser Java-Client ist im Grunde identisch mit dem .NET-Client. Es spricht auch mit dem NCache Clustern Sie auf die gleiche Weise wie der .NET-Client mithilfe von NCacheDas eigene proprietäre Socket-Protokoll und das NCache Der Server ist so konzipiert, dass Ihr serverseitiger Java-Code auf einer eigenen JVM ausgeführt wird.
Die gesamte Entwicklung sowie das Testen und Debuggen, die Sie durchführen werden, erfolgt also ausschließlich in nativen JVM-Prozessen. Und dieser Cache-Prozess ruft beispielsweise den Read-through-Handler auf, der beispielsweise in Oracle oder Db2 oder sogar in die SQL Server-Datenbank geht, die Daten abruft und sie an den Cache-Prozess weitergibt. Auch hier wird derselbe leistungsstarke In-Memory-RPC verwendet. Durch eine Architektur, die den .NET- und den Java-Code gewissermaßen in ihren eigenen nativen Prozessen kapselt, NCache ist in der Lage, Ihnen einen nativen Stack für Java und .NET bereitzustellen.
Und auch im Falle einer Java-Anwendung möchten Sie Ihre Entwicklung möglicherweise entweder unter Windows oder Mac OS durchführen NCache unterstützt es vollständig, oder sogar Linux, und dann verwenden Sie eher Docker und Kubernetes als die .NET-Leute NCache bietet Ihnen die Docker-Images und dann auch volle Unterstützung für Kubernetes, das Azure AKS, das AWS EKS, das Google GKE oder das Red Hat OpenShift. Sie können es sehr nahtlos verwenden.
Damit NCache ist sehr einzigartig. Es bietet Ihnen ein natives .NET-Erlebnis und gleichzeitig ein natives Java-Erlebnis. Wenn Sie also ein Java-Shop sind, haben Sie nicht das Gefühl, ein Nicht-Java-Produkt zu verwenden, und wenn Sie ein .NET-Shop sind, haben Sie nicht das Gefühl, ein Nicht-Java-Produkt zu verwenden. NET-Produkt. Das ist das Schöne daran NCache die Art und Weise, wie es aufgebaut ist.
Dynamischer Cluster
Okay, kommen wir jetzt zur Sache Dynamisches Clustering Teil des NCache Architektur, die auf Hochverfügbarkeit ausgelegt ist. Und, eine Sekunde, okay. Der erste Teil ist also der dynamische Cluster. Wenn ich das Wort Cluster verwende, meine ich nicht Kubernetes-Cluster, sondern irgendeinen anderen Cluster auf Betriebssystemebene. Das ist NCacheist ein eigener TCP-basierter Cluster. Und dieser Cluster verfügt über eine Peer-to-Peer-Architektur. Peer-to-Peer bedeutet, dass es keinen Meister und keinen Sklaven gibt. Das Problem beim Master/Slave besteht darin, dass bei einem Ausfall des Masters der Slave entweder funktionsunfähig oder eingeschränkt wird, wohingegen in einer Peer-to-Peer-Architektur jeder Knoten gleichermaßen leistungsfähig ist. Offensichtlich gibt es einen Cluster-Koordinatorknoten, der der älteste Knoten ist. Wenn dieser Knoten jemals ausfällt, wird automatisch der nächstälteste als Cluster-Koordinator ausgewählt. Der Clusterkoordinator übernimmt die Clustermitgliedschaft. Es verwaltet die Verteilungskarte, den Clusterzustand und eine Reihe anderer Dinge, von denen ich einiges besprechen werde.
Das dynamische Clustering bedeutet, dass Sie zur Laufzeit Server zum Cluster hinzufügen oder daraus entfernen können, ohne den Cache oder Ihre Anwendung anzuhalten. Es gibt keine Unterbrechung. Und wenn Sie, sagen wir, einen neuen Server zum Cluster hinzufügen, wird die Clustermitgliedschaft offensichtlich zur Laufzeit aktualisiert und diese Laufzeitinformationen werden dann an die Clients weitergegeben. Und darüber werde ich auf der nächsten Folie etwas ausführlicher sprechen.
Es gibt auch eine Failover-Funktion für Clusterverbindungen. Da es sich also um Sockets handelt, befinden sich die Cluster-Server zwar normalerweise im selben Subnetz, ziemlich nahe beieinander, aber das ist möglicherweise nicht immer der Fall. Wir haben Kunden, die Server sogar in verschiedenen Regionen bereitgestellt haben, und es funktioniert einwandfrei, obwohl wir dies in den meisten Fällen empfehlen NCache Server sollten ziemlich nah beieinander sein. Es könnte jedoch immer noch zu einem Verbindungsfehler kommen. Wenn das der Fall ist NCache verfügt über eine Wiederholungslogik und es gibt Zeitüberschreitungen. Es gibt eine Heartbeat-Logik, um sicherzustellen, dass alles dynamisch ist.
Dynamische Clients und dynamische Konfiguration
Dynamische Client-Verbindungen
Der andere Teil der dynamischen Architektur sind die dynamischen Clients. Genauso hatte der Cluster die Möglichkeit, zur Laufzeit Server hinzuzufügen oder zu entfernen, und Sie hatten auch die Möglichkeit, zur Laufzeit Clients hinzuzufügen oder zu entfernen. Was bedeutet ein Kunde? Ein Kunde ist der NCache Client, der auf Ihrem Anwendungsserver, Ihrem Webserver, läuft, das ist der Teil, mit dem Ihre Anwendung kommuniziert. Sie können also zur Laufzeit einen Client hinzufügen oder einen Client zur Laufzeit entfernen, ohne ihn anzuhalten NCache, den Cache oder Ihre Anwendung ohne Unterbrechung. Das ist also der erste Teil.
Dynamische Konfiguration
Der zweite Teil ist die dynamische Konfiguration. Wie ich auf der letzten Folie erwähnt habe, ändert sich die Clustermitgliedschaft, wenn Sie dem Cluster einen Server hinzufügen. Nun, das wird an alle vorhandenen Clients weitergegeben, die verbunden sind, sodass sie jetzt wissen, dass es einen neuen Server gibt, mit dem sie eine Verbindung herstellen müssen. Wenn sie sich also aufgrund der Caching-Topologie dafür entscheiden, können sie sich auch mit diesem Server verbinden. Darüber hinaus kann je nach Topologie eine Verteilungskarte vorhanden sein. Eine Verteilungszuordnung ist eher für den partitionierten Cache und den partitionierten Replikat-Cache gedacht. Wenn Sie jedoch einen Server hinzufügen, wird dieser aktualisiert und zur Laufzeit weitergegeben. Und auch eine Reihe anderer Konfigurationsänderungen. Es gibt eine Hot-Apply-Funktion, die Sie ausführen können und die zur Laufzeit weitergegeben wird. Das ist also der zweite Teil.
Failover der Clientverbindung
Der dritte Teil besteht darin, dass es erneut ein Client-Verbindungs-Failover gibt, das auf die gleiche Weise wie das Cluster-Verbindungs-Failover erfolgt. Dies ist jedoch sogar noch notwendiger, da die Clients wahrscheinlich nicht immer in unmittelbarer Nähe der Cluster-Server sein werden. Und es können einige Router oder Firewalls dazwischen liegen. Daher ist es wahrscheinlicher, dass die Verbindung zwischen den Clients und dem Cluster unterbrochen wird. Also, NCache verfügt über eine ziemlich intelligente Wiederholungsfunktion, Zeitüberschreitung. Es gibt auch eine Keep-Alive-Funktion, sodass der Client auch dann verbunden bleibt, wenn die Verbindung unterbrochen wird und der Client sich erneut mit dem verbindet NCache Cluster.
Split-Brain-Erkennung und -Wiederherstellung
Ein weiteres wichtiges Thema des dynamischen Aspekts von NCache Architektur ist das Split Brain. Das Split Brain ist ein Phänomen, das im Cluster auftreten kann.
Split-Brain tritt bei Verbindungsunterbrechung auf
Und Split Brain tritt immer dann auf, wenn Sie beispielsweise über einen fehlerfreien Cluster aus sechs Servern verfügen. Ein Split Brain tritt dann auf, wenn die Verbindung zwischen einigen dieser Server aus irgendeinem Grund unterbrochen wird, und wann immer Sie Netzwerkverbindungen haben, können diese unterbrochen werden. Und das sehen wir ständig. Wenn das passiert, bilden sich Untercluster. Nehmen wir an, in diesem Fall gibt es Split 1, Split 2, Split 3. Jeder Untercluster denkt, er sei der Überlebende. Daher erstellt es einen eigenen Cluster-Koordinator und wird zu einem unabhängigen Cluster.
Split-Brain-Erkennung
Alle diese Aufteilungen erinnern jedoch daran, dass sie früher Teil eines gesunden Clusters waren und diese Server nicht freiwillig, sondern nicht reibungslos abreisten. Sie haben keinen Knoten vom Knoten verlassen NCache Stattdessen brach die Verbindung im Management Tool ab. Daher werden sie weiterhin nach diesen Servern suchen, um zu sehen, ob die Netzwerkverbindung wiederhergestellt ist. Und meistens vielleicht fünf, zehn Minuten, eine halbe Stunde, eine Stunde später wird die Verbindung höchstwahrscheinlich wiederhergestellt sein.
Split-Brain-Recovery
Wenn das passiert, wird eine Split-Brain-Recovery durchgeführt. Und dort verschmelzen diese Spaltungen. Diese Untercluster werden iterativ vom größten zum kleinsten zusammengeführt, und es kommt offensichtlich zu einem gewissen Datenverlust, da diese zu unabhängigen Clustern wurden und nun einige Daten verloren gehen müssen. Aber das alles geschieht automatisch, basierend auf den Regeln, die Sie festlegen.
Weitere Einzelheiten zum Split Brain finden Sie in einem separaten Artikel Video Aber das gibt Ihnen irgendwie einen Überblick. Es ist eine sehr wichtige Funktion, die sicherstellt, dass Ihre NCache Der Cluster bleibt gesund und kann sich erholen, wenn es zu einer Gehirnspaltung kommt.
Caching-Topologien
Okay, jetzt gehen wir weiter Caching-Topologien. Bei Caching-Topologien handelt es sich im Wesentlichen um Datenspeicherung, Replikationsstrategien und auch Client-Verbindungsstrategien. Es gibt vier Topologien: Partitionierter Cache, Partitionsreplik, replizierter Cache und gespiegelter Cache. Kommen wir zum partitionierten Cache.
Partitionierter Cache
Partitionierter Cache besteht im Grunde darin, dass der gesamte Cache in Partitionen aufgeteilt ist und jeder Server eine Partition hat. Und es gibt dieses Konzept von Eimern. Jede Partition hat also Buckets. Insgesamt 100 Buckets für den gesamten Cache. Je nachdem, wie viele Partitionen Sie haben, werden diese Buckets also gleichmäßig unter ihnen aufgeteilt.
Und diese Partitionen werden zur Laufzeit erstellt, das ist der wichtige Teil dabei. Wenn Sie also einen Server hinzufügen, wird eine Partition erstellt. Nehmen wir an, Sie beginnen mit einem Server, es gibt nur eine Partition, alle 100 Buckets befinden sich in dieser Partition. Wenn Sie zur Laufzeit einen zweiten Server hinzufügen, werden nicht nur die Informationen zur Clustermitgliedschaft aktualisiert, die ich in den vorherigen Folien erwähnt habe, sondern jetzt auch die Verteilungskarte. Eine Verteilungskarte ist im Wesentlichen eine Karte darüber, welche Partition welche Buckets enthält. Nehmen wir also an, wenn Sie eine zweite Partition hinzugefügt haben, wird die Verteilungskarte jetzt geändert. Bei einer Verteilungskarte handelt es sich eigentlich um eine Hash-Karte, die Buckets zugeordnet ist. Der Hash-Map-Wert reicht von Buckets. Und dies ändert sich nicht abhängig davon, wie viele Daten Sie hinzugefügt haben, sondern nur, wenn Sie die Anzahl der Server oder die Anzahl der Partitionen ändern oder die Daten neu ausgleichen. Die Partitionen sind also dynamisch.
Dynamischer Datenausgleich
Der zweite Teil besteht darin, dass es einen dynamischen Datenausgleich gibt. Da dies also alles auf einer Hash-Map basiert, ist es sehr wahrscheinlich, dass einige der Buckets basierend auf der Art der von Ihnen verwendeten Schlüssel mehr Daten erhalten als andere. Und am Ende werden einige Partitionen fast voll und die anderen fast leer sein. Und wenn das passiert, dann NCache verfügt über diese Funktion, mit der Sie einen Schwellenwert festlegen können. Nehmen wir an, wenn eine Partition zu mehr als 80 % voll ist, entfernen Sie 20 %, 10 % oder 5 % davon. Nicht entfernen, ich meine es dynamisch ausgleichen. Datenausgleich bedeutet also, diese Buckets von Partition 1 zu nehmen und auf andere zu kopieren oder sie auf andere Partitionen zu verschieben. Der Datenausgleich stellt also sicher, dass die Daten und alle Partitionen einigermaßen gleichmäßig sind.
Der Client stellt eine Verbindung zu allen Partitionen her
Im partitionierten Cache stellt jeder Client eine Verbindung zu allen Partitionen oder allen Servern her. Der Grund dafür ist, dass es in einem Aufruf direkt auf jedes gewünschte Element zugreifen möchte. Wenn es beispielsweise nur mit einem Server verbunden wäre und Artikel Nummer 3 wollte, kommuniziert es mit Server 1, Server 1 geht zu Server 2 und holt es sich. Und das ist ein Zwei-Hop-Vorgang, der nicht so optimiert ist, als ob der Client direkt dorthin gehen könnte, wo sich die Daten befinden. Und der Kunde weiß das aufgrund einer Verbreitungskarte. Aus diesem Grund wird die Verteilungskarte erstellt, damit die Kunden wissen, wo sich die Daten befinden, sodass sie sie direkt von dort abrufen können.
Daher verfügt der partitionierte Cache über keine Replikation. Wenn also ein Server ausfällt, gehen diese Daten verloren. Es gibt keine andere Möglichkeit, außer wenn Sie „Persistenz“ verwenden, worüber ich gleich sprechen werde. Dann gehen auch beim Partitioned Cache keine Daten verloren.
Partitionsreplikat-Cache
Replikate von Partitionen (dynamisch)
Die nächste Topologie ist der Partition-Replica-Cache. Dies ist übrigens unsere beliebteste Topologie, da sie Ihnen das Beste aus beiden Welten bietet. Es gibt Ihnen die Partitionierung, also die Skalierbarkeit. Und es ermöglicht Ihnen auch die Replikation, also die Hochverfügbarkeit. Es gibt also keinen Datenverlust. Es ist also zum Beispiel dasselbe wie bei Partitioned Cache, alles ist gleich, aber jede Partition hat jetzt eine Replik auf einem anderen Server. Wenn sich Partition eins also auf Server 1 befindet, heißt ihr Replikat Replikat 1, das sich in diesem Fall beispielsweise auf Server 2 befindet. So wie die Partitionen zur Zeit dynamisch erstellt wurden, werden auch die Replikate zur Laufzeit erstellt, wenn die Partitionen hinzugefügt oder entfernt werden. Und sie befinden sich offensichtlich immer auf einem anderen Server.
Der andere Teil ist, dass alle Replikate passiv sind. Passiv bedeutet, dass kein Kunde direkt mit ihm spricht. Das bedeutet, dass die Clients nur mit den Partitionen kommunizieren und die Partitionen dann ihr Replikat aktualisieren. Wenn Sie also etwas in der Partition aktualisieren, aktualisiert die Partition es im Replikat. Und dieses Update ist standardmäßig asynchron. Asynchron ist, damit es schneller sein kann. Erstens muss der Client nicht auf die Replikation warten, zweitens können Sie eine Massenreplikation durchführen. Sie können also Hunderte oder Tausende dieser Updates zusammenfassen und sie gleichzeitig verschieben oder auf das Replikat übertragen. Denn die Kosten für diese Netzwerkreise sind viel schneller oder teurer als die Kombination von Daten.
Asynchrone/synchrone Replikation
Allerdings ist die asynchrone Replikation offensichtlich nicht immer konsistent. Es ist schließlich konsistent, was in etwa 95 % bis 99 % der Fälle gut genug ist, und es gibt vielleicht 1 bis 5 % der Fälle, in denen Sie es mit sehr sensiblen Daten zu tun haben. Sie möchten also keine asynchrone Replikation, sondern eine synchrone Replikation. Es gibt also eine Funktion namens „Replikation synchronisieren“, die Sie aktivieren können. Wenn Sie das tun, wird der Vorgang immer dann, wenn der Client Elemente in der Partition aktualisiert, erst dann abgeschlossen, wenn die Partition zuerst das Replikat aktualisiert. Wenn also diese Replikation fehlschlägt, schlägt der Vorgang fehl. Auf diese Weise wissen Sie, dass die Replikation auch erfolgreich war, wenn der Vorgang erfolgreich war. Das ist also ein sehr wichtiges Merkmal.
Und schließlich gibt es, genau wie bei der partitionierten Topologie und der partitionierten Cache-Topologie, auch den dynamischen Datenausgleich auf den Replikaten. Wenn die Partitionen also einen dynamischen Datenausgleich haben, müssen die Replikate damit übereinstimmen, da die Replikate immer eine identische Kopie der Partition sind. Sie werden also auch einen Datenabgleich durchführen.
Dynamische Partitionierung
Lassen Sie uns nun kurz durchgehen, wie die dynamische Partitionierung wirklich erfolgt. Nehmen wir also an, Sie hätten einen Zwei-Server-Cluster und sechs Elemente darin und Sie wollten einen dritten Server hinzufügen. Ich füge noch keine weiteren Daten hinzu, da dies ein anderer Anwendungsfall ist. Die Daten sind einfach so wird auf andere Partitionen verschoben, wenn Sie einen weiteren Knoten hinzufügen.
Nehmen wir an, Sie fügen einen Knoten hinzu. Es gibt also jetzt einen dritten Server. Also wird Partition 3 erstellt und Partition 3 erhält nun Daten von Partition 1 und Partition 2. Sie erhält also einige Daten von 1, einige von 2. Nehmen wir also an, dass sie Element 3 von Partition 1 und Element 4 von Partition 2 übernimmt und wird zur Partition 3.
Da es nun zu Partition 3 wurde, muss sich sein Replikat auf einem anderen Server befinden. Nehmen wir also an, es wird auf Server 1 abgelegt. Server 1 hatte also früher Replikat 2, es wird in Replikat 3 konvertiert und dann wird Replikat 2 verschoben in Server 3. So enthält Replikat 3 jetzt beispielsweise 3, 4 statt 4, 5, 6, und Replikat 2 enthält 5, 6. All dies wird dynamisch zur Laufzeit erfolgen, ohne dass Ihre Anwendung es sieht jede Unterbrechung.
Das Gleiche passiert umgekehrt, wenn ein Server ausfällt, sagen wir, Sie hätten eine Partition mit drei Partitionen NCache Cluster und Server 3 sind ausgefallen, entweder haben Sie ihn heruntergefahren, oder er ist ausgefallen, sobald das passiert, weil Partition 3 nicht mehr verfügbar ist. Replikat 3, wie Sie sehen können, habe ich seine Farbe geändert, es wird aktiv. Normalerweise sind Replikate, wie gesagt, nicht aktiv, oder? Nur die Partitionen sind aktiv, aber jetzt wird diese zu einer Partition. Dies ist jedoch nur vorübergehend, da Sie nicht zwei Partitionen auf derselben Box und dann kein Replikat haben möchten.
Das verschmilzt hier also mit Partition 1, also sagen wir mal, Element 3 geht zu Partition 1, Element 4 geht zu Partition 2, und Ihre Situation ist hier so und diese Replik 3 wird jetzt zu Replik 2. Also, das Das Gleiche passiert rückwärts, alles zur Laufzeit, dynamische Partitionierung, sehr, sehr flexibel, sehr dynamisch. Diese Dynamik trägt zur Hochverfügbarkeit von bei NCache.
Wartungsmodus
Nun, obwohl diese dynamische Partitionierung sehr nützlich und sehr leistungsfähig ist, gibt es einige Fälle, in denen Sie keine Neupartitionierung wünschen, und einer dieser Fälle ist die geplante Wartung. Nehmen wir an, Sie führen einen Betriebssystem-Patch durch und dieser Patch wird den Server für fünf oder zehn Minuten herunterfahren. Nun, Sie wissen, dass Ihr gesamter Cache-Cluster möglicherweise Dutzende Gigabyte an Daten umfasst. Sie möchten also nicht nur für diese fünf Minuten neu partitionieren und dann erneut neu partitionieren, wenn Sie den Knoten wieder hochfahren. Sie können also eine Funktion zur Zeitplanwartung aktivieren NCache Wenn Sie diesen Knoten in diesem Fall herunterfahren, müssen Sie ihn erneut über Ihr Verwaltungstool herunterfahren. Dadurch wird Folgendes ausgelöst: Dieses Replikat wird aktiv, es erfolgt jedoch keine Neupartitionierung.
Es bleibt also eine Konfiguration mit zwei Servern mit Partition 1, Replikat 3, Partition 2, Replikat 1, und diese Replik 3 ist tatsächlich Partition 3, was bedeutet, dass sie aktiv ist und funktioniert. Offensichtlich ist es keine Hochverfügbarkeit, denn obwohl Partition 1 hier gesichert ist. Partition 2 verfügt über kein Backup und Replikat 3 über kein Backup. Dies ist jedoch nur vorübergehend, da Sie es nur für 5, 10 Minuten benötigen. Sobald dieser Server also wieder hochgefahren ist, kehrt er in den alten Zustand zurück und wird wieder zu einer Replik, wenn dieser wieder zu einer Partition wird. So funktioniert also die geplante Wartungsfunktion von NCache Werke.
Replizierter Cache
Die nächste Topologie heißt a Replizierter Cache. In dieser Topologie können Sie zwei oder mehr Server haben, wobei jeder Server über eine vollständige Kopie des Caches verfügt und jeder Server aktiv ist, was bedeutet, dass mit jedem Server Clients verbunden sind. Allerdings verbindet sich hier jeder Client nur mit einem Server. Denn dieser Server verfügt über den gesamten Cache. Daher muss keine Verbindung zu zwei Servern wie einer Partition oder einer Partitionsreplik hergestellt werden.
Bei dieser Topologie sind alle Lesevorgänge superschnell, da sich der gesamte Cache direkt dort befindet, die Aktualisierungen müssen jedoch synchron erfolgen. Da es sich bei beiden um aktive Server handelt, könnte dasselbe Element hier und hier gleichzeitig aktualisiert werden, und Sie möchten offensichtlich nicht auf ein Problem mit der Datenintegrität eingehen. Es erfolgt also auf synchrone Weise, wobei es ein Indexierungsschema gibt, es gibt einen Index, es gibt tatsächlich so etwas wie eine Sequenznummer, die ausgegeben wird, und jedes Element wird in derselben Reihenfolge aktualisiert. Dadurch können die Aktualisierungen stets korrekt durchgeführt werden. Der Preis besteht jedoch darin, dass ein synchrones Update bedeutet, dass, wenn Sie einen Client haben, der Artikel 1 aktualisiert, dieser Server Artikel 2 benachrichtigt, Artikel 1 zu aktualisieren. Wenn beide Server Artikel 1 erfolgreich aktualisiert haben, ist nur dann die Aktualisierung erfolgreich und die Steuerung geht zurück. Das bedeutet also, dass es nicht so schnell ist wie die Topologie „Partition“ oder „Partitionsreplikat“, aber der Vorgang ist garantiert. Wenn die Aktualisierung erfolgreich ist, bedeutet dies, dass sie immer auf allen Servern durchgeführt wird.
Diese Topologie eignet sich gut für leseintensive Vorgänge. Bei einem Zwei-Server-Cluster sind sogar die Schreibvorgänge ziemlich schnell, nicht so schnell wie bei der Partitionsreplikation, aber für die meisten Situationen einigermaßen schnell. Wenn Sie jedoch weitere Server hinzufügen, sinkt die Leistung der Updates. Tatsächlich wird es langsamer, da mehr Server synchron aktualisiert werden müssen. Diese Topologie hat also ihre eigenen Verwendungsmöglichkeiten, deshalb behalten wir sie bei. Viele unserer Kunden nutzen es in besonderen Situationen.
Gespiegelter Cache
Die vierte Topologie heißt Gespiegelter Cache. Dies ist wiederum eine sehr spezifische Topologie. Es handelt sich lediglich um eine 2-Knoten-Topologie. Es gibt einen aktiven und einen passiven Knoten. Auch hier verfügt der aktive Knoten über den gesamten Cache und eine Kopie des Caches befindet sich auf dem passiven Knoten. Alle Clients stellen eine Verbindung zum aktiven Knoten her und aktualisieren den aktiven Knoten für alle Dinge. Die Aktualisierungen werden asynchron auf dem passiven Knoten gespiegelt oder repliziert. Und diese Asynchronität bedeutet, dass es genauso schnell ist wie Partition Replica.
Wenn in dieser Topologie der aktive Knoten jemals ausfällt, wird der passive Knoten automatisch aktiv und alle Clients wechseln automatisch zum passiven oder zum neu aktiven Knoten. Und auf diese Weise gibt es keine Ausfallzeiten, es gibt keine Unterbrechungen und das nennt man die automatische Failover-Unterstützung, das habe ich damit gemeint. Und wenn der aktive Knoten dann wieder hochkommt, wird er wieder aktiv, und das Gleiche passiert umgekehrt.
Daher ist die Spiegeltopologie auch für spezielle Fälle sehr nützlich. Es ist nicht über diese beiden Server hinaus skalierbar, hat aber seinen eigenen Nutzen, da alle Clients hier eine Verbindung herstellen und Sie dann eine Replik auf einer anderen Box erstellen können. Ich meine, dies könnte beispielsweise im Falle einer Notfallwiederherstellung verwendet werden.
Live-Persistenz
Eine weitere sehr leistungsstarke Funktion von NCache wird genannt Live-Persistenz. Live-Persistenz ist nur für Partitions- und Partitionsreplikat-Topologien verfügbar und ist live, was bedeutet, dass der Persistenzspeicher sofort aktualisiert wird, wenn Sie den Cache zur Laufzeit aktualisieren. Die Aktualisierung des persistenten Speichers erfolgt asynchron. Es beeinträchtigt also nicht die Leistung Ihrer Anwendung oder NCache Leistung. So kann Ihre Bewerbung sehr schnell erfolgen. Die Persistenz erfolgt auf Bucket-Ebene. Es gibt also 100 Buckets, die den gesamten Cache darstellen und in einem gespeichert werden NoSQL Dokumentenspeicher. Da es sich um einen dateibasierten Speicher handelt, handelt es sich nicht um einen serverbasierten Speicher. Es ist kein NoSQL database Server, es ist ein NoSQL Dokument speichern, dass NCache Verwendet. Sie können es an einem gemeinsamen Standort verwenden, der allen Servern im gemeinsam ist NCache Cluster, und auf diese Weise können sie sich alle auf denselben persistenten Speicher verlassen.
Zu den Vorteilen und dem Grund, warum diese Funktion bereitgestellt wird, zählt erstens, dass Sie beispielsweise den gesamten Cache beibehalten können, unabhängig davon, was Sie beibehalten, und dass der gesamte Cache immer beibehalten wird. Man kann sagen, dass alles, was Sie im Cache aktualisieren, mit der Differenz von ein paar Millisekunden auch im persistenten Speicher gespeichert wird. Sie können das also nehmen und in einen anderen Cache neu laden, oder wenn alle Server ausfallen sollten, können Sie sie jederzeit über die persistenten Speicher neu starten. Sie verlieren keine Daten außer sehr, sehr kleinen Datenmengen. Oder vielleicht möchten Sie den Cache von einer Umgebung in eine andere übertragen, das ist ganz einfach möglich.
Der andere Vorteil besteht darin, dass Partitions- und Partitionsreplikattopologien tatsächlich eine höhere Hochverfügbarkeit erhalten. Nun, Partitionstopologie, und darauf gehe ich hier ein. Partitionierter Cache hat also, wie ich bereits erwähnt habe, keine Replikation. Wenn also eine Partition oder ein Server ausfällt, geht diese Partition verloren, oder? Nun, wenn Sie Beharrlichkeit haben, dann tun Sie das nicht. Denn in diesen Buckets wird auch eine Kopie dieser Daten gespeichert. Wenn also dieser Server ausfällt, werden die Buckets im Speicher neu zugewiesen, aber offensichtlich ohne Daten an andere Server, und diese Server wissen nun, dass es sich um leere Buckets handelt, deren Daten im Persistenzspeicher vorhanden sind, also laden sie diese Daten aus der Persistenz neu speichern.
So gehen auch bei einem Serverausfall keine Daten verloren, obwohl Sie Partitioned-Cache verwenden. Und Sie haben die gleichen Vorteile wie ein Partitionsreplikat wie ein Partitioned-Cache.
Der Vorteil besteht darin, dass Sie mehr Speicher nutzen können. Sie können mehr Daten im Cache speichern, da Sie hier mehr Speicher für das Replikat zuweisen müssen, den Sie hier nicht zuweisen müssen, aber Sie müssen den Persistenzspeicher zuweisen. Das ist also der Vorteil von Partitioned Cache. Partition-Replica bietet auch Vorteile. Und es ist irgendwie interessant, dass Sie dadurch zwar bereits eine hohe Verfügbarkeit erhalten, diese hohe Fähigkeit jedoch nur dann auftritt, wenn ein Server zu einem bestimmten Zeitpunkt ausfällt, aber sagen wir mal, wenn zwei Server gleichzeitig ausfallen würden, ohne dass die Persistenz überhaupt vorhanden wäre In Partition-Replica würden Sie Daten verlieren. Denn wissen Sie, es gibt nur eine Kopie jeder Partition und wenn zwei Server ausfallen würden, würden Sie mehr Server verlieren, als Sie sich leisten können. Nun, mit der Persistenz haben Sie kein Problem, Sie können einfach alle Daten aus dem Persistenzspeicher neu laden.
In beiden Fällen müssen Sie natürlich bedenken, dass Sie beim Laden von Daten aus dem Persistenzspeicher drei Server hatten und jetzt zwei. Nun, die Daten sind möglicherweise zu groß, um auf die beiden Server zu passen. Ein weiteres Problem, mit dem Sie sich befassen müssen, besteht darin, sicherzustellen, dass auf diesen beiden verbleibenden Servern genügend Speicher vorhanden ist, damit das Äquivalent aller drei Server untergebracht werden kann Server. Das ist also die einzige Einschränkung. Ansonsten ist die Persistenz sowohl für den Partitioned-Cache als auch für den Partition-Replica-Cache von großem Wert.
Client-Cache
Okay, ein weiteres sehr wichtiges Merkmal von NCache wird genannt Client-Cache. Es bietet Ihnen eine InProc-Geschwindigkeit in einer verteilten Filialumgebung. So haben Sie beispielsweise eine verteilte NCache Cluster, Ihre Anwendung wird hier ausgeführt. Dies ist normalerweise ein Cache über Ihrer Datenbank oder was auch immer Sie sonst tun. Ein Client-Cache wird normalerweise verwendet, wenn Sie ein verteiltes Cache-Szenario haben, und ein Client-Cache ist ein Cache darüber Dieser Cache-Cluster befindet sich sehr nah an Ihrer Anwendung. Es befindet sich auf dem Anwendungsserver oder dem NCache Client-Box. Und es kann je nach Wunsch sogar InProc oder OutProc sein. Ein InProc-Cache ist superschnell, da er die Daten tatsächlich in einer deserialisierten Objektform auf Ihrem Heap speichert. Es ist also, als ob Sie dieses Objekt auf Ihrem Heap hätten. Es kann schneller gehen.
Ein InProc-Cache ist also superschnell, aber gleichzeitig ist das Schöne daran, dass er mit dem synchronisiert ist NCache Cluster. Und die Art und Weise, wie es synchronisiert wird, hängt davon ab, was im Client-Cache gespeichert ist, von dem der Cluster weiß. Wenn also etwas, das in diesem Client-Cache gespeichert war, ein anderer Client im Cluster aktualisiert, benachrichtigt der Cluster diesen Client-Cache, um sich selbst zu aktualisieren. Und dann aktualisiert sich dieser Client-Cache asynchron. Natürlich gibt es eine Verzögerung von ein paar Millisekunden, aber das ist, wie gesagt, in den meisten Fällen das Modell der letztendlichen Konsistenz, und das ist normalerweise in 99 % der Fälle akzeptabel.
Wenn das nicht akzeptabel ist, dann NCache bietet Ihnen … und die optimistische Synchronisierung ist die Standardeinstellung, bei der es zu einigen Millisekunden Verzögerung kommt und es technisch gesehen zu einer Situation kommen kann, in der Sie veraltete Daten haben, was, wie gesagt, in 99 % der Fälle in Ordnung ist. Aber sagen wir mal, wenn es nicht in Ordnung wäre und Ihre Daten sehr sensibel wären, Sie aber trotzdem den Client-Cache verwenden möchten, dann könnten Sie eine pessimistische Synchronisierungsfunktion verwenden, die sicherstellt, dass der Client, bevor Ihre Anwendung etwas aus dem Client-Cache abruft Der Cache prüft nur, ob es eine neuere Version dieser Daten gibt. Das ist ein schnellerer Aufruf als das Abrufen der Daten selbst, weil NCache behält dann mehrere Versionsinformationen bei. Und wenn es dann eine neuere Version dieser Daten gibt, ruft der Client-Cache diese ab, andernfalls gibt er sie einfach aus dem Client-Cache zurück.
Ein Client-Cache, den Sie ohne Codeänderungen verwenden können. Es fügt sich einfach in Ihre Umgebung ein und eignet sich gut für leseintensive Situationen. Wenn Sie viel mehr Lesevorgänge ausführen, ist mindestens 5:1, 10:1 ideal, aber wenn es 1:1 ist, sagen wir, bei Websitzungen, dann hilft Client Cache überhaupt nicht. Tatsächlich ist es überhaupt nicht zu empfehlen.
WAN-Replikation
Mehrzonen/Mehrregionen
Okay, ein weiterer Teil von NCache ist das Wo NCache die WAN-Replikation für die Bereitstellung Ihrer Anwendungen in mehreren Zonen oder Regionen. So könnten Sie Ihre Anwendung beispielsweise für die Notfallwiederherstellung an zwei verschiedenen Standorten bereitstellen, von denen einer für die Notfallwiederherstellung aktiv und der andere passiv ist. Und Sie haben diese Anwendung, eine NCache läuft damit, und Sie haben hier eine Anwendung, die nicht läuft. Sie möchten jedoch sicherstellen, dass die Website im Falle eines Ausfalls sofort wieder in Betrieb genommen werden kann. Sie können also eine Brücke bauen. Eine Bridge ist selbst ein 2-Knoten-Cluster, der sich auf denselben Boxen wie der befinden kann NCache main, oder es könnte ein separates dediziertes sein, es liegt an Ihnen. Und dann wird alles, was Sie in diesem Cache aktualisieren, asynchron über das WAN in den anderen Cache repliziert. Das ist also das Aktiv-Passiv.
Das Gleiche können Sie mit einem Aktiv-Aktiv-Befehl tun. Nehmen wir an, wenn Sie eine Situation haben, in der sogar diese Site aktiv ist, können Sie genau dasselbe mit einem Aktiv-Aktiv-Modus tun, bei dem sich beide Sites gegenseitig aktualisieren können. In diesem Fall gibt es auch eine Situation, in der sich ein Konflikt lösen und entstehen kann. Und ein Konflikt bedeutet, dass das gleiche Element, der gleiche Schlüssel auf beiden Seiten gleichzeitig aktualisiert wird. In diesem Fall wendet die Bridge standardmäßig die Logik „Letztes Update gewinnt“ an. Es gewinnt also derjenige, der den späteren Zeitstempel des Updates hat. Wenn Sie möchten, können Sie aber beispielsweise auch einen Konfliktlösungs- und Konfliktlösungshandler bereitstellen, bei dem es sich um Ihren .NET- oder Java-Code handelt, den die Bridge aufruft, und der beide Kopien der Daten oder des Objekts an diesen Auflösungshandler übergibt Und dann können Sie den Inhalt analysieren, um festzustellen, welcher korrekter ist, und dann sagen Sie: Okay, dieses Update gewinnt, und dann wird dieses Update auf beide Websites angewendet. Solange dies auf beide Seiten angewendet wird, gibt es keinen Konflikt.
Das NCache hat die Möglichkeit, Ihnen drei oder mehr Standorte im Aktiv-Aktiv- oder Aktiv-Passiv-Modus oder einer Kombination davon bereitzustellen. So benötigen Sie beispielsweise mindestens einen aktiven, diese könnten dann aber alle passiv sein, oder diese könnten alle aktiv sein oder es könnte eine Kombination aus aktiv und passiv sein. Und wenn mehr als einer aktiv ist, kann dies auch zur Konfliktlösung führen.
Container (Docker und Kubernetes)
Schließlich sind Container wie Docker und Kubernetes sehr beliebt geworden. Also, NCache Offensichtlich werden sie unterstützt, weil sie auf der Java- und Linux-Seite beliebter sind als auf der .NET- und Windows-Seite, aber ich bin mir sicher, dass sich das mit der Zeit ändern wird. Also, so oder so, NCache ist in beiden Umgebungen voll damit zurechtgekommen. Hier ist zum Beispiel ein typisches Beispiel Kubernetes-Bereitstellung von NCache.
Hier ist eine NCache Einsatz. Es gibt NCache hat einen eigenen Discovery Service. Dies sind Pods, die skaliert werden können, und dann gibt es im Kubernetes-Cluster Anwendungen, die skalierbar sind NCache Clients und dies können entweder Azure, AKS, AWS, EKS, Google GKE oder Red Hat OpenShift sein. Red Hat OpenShift ist normalerweise entweder eine andere Cloud wie AWS, Azure oder Google oder vielleicht eine andere Cloud NCache unterstützt sie alle. Und dieser Pod könnte Linux sein, was bei Kubernetes häufiger der Fall ist, und NCache Funktioniert einwandfrei. Und die Anwendung kann auch Linux oder Windows sein. Dies können also entweder Linux oder Windows, Linux oder Windows sein.
Docker / Kubernetes (Multi-Zone)
Auf die gleiche Weise setzt die WAN-Replikation ein, und wenn Sie möchten, können Sie, sagen wir, aufgrund der Cloud mehrere Verfügbarkeitszonen haben. Sie wollten ein Kubernetes mit mehreren Zonen erstellen.
Wir empfehlen also, dass Sie einen Kubernetes-Cluster erstellen und zwei haben NCache Bei Bereitstellungen kann es sich um Aktiv-Aktiv- oder Aktiv-Passiv-Bereitstellungen handeln. Und dann kann die Brücke entweder ganz hier oder ganz hier stehen. Oder Sie können sogar eine Brückenaufteilung vornehmen, bei der sich ein Teil in dieser Zone und ein Teil in dieser Zone befindet und die Replikation dann asynchron erfolgt.
Ich denke, das deckt das heutige Thema weitgehend ab. Ich empfehle Ihnen dringend, unsere Website zu besuchen und einen Blick darauf zu werfen NCache Spielplatz Dies ist wirklich eine sehr schnelle und einfache Möglichkeit, von Ihrem Browser aus eine live laufende Kopie von zu verwenden NCache, und Sie können sogar einen 2-Knoten erhalten NCache Cluster mit allen Tools ohne Installationsaufwand. Oder wenn Sie bereit sind, kommen Sie einfach hierher und registrieren und herunterladen entweder NCache Enterprise für .NET Edition oder NCache Enterprise für Java Edition. Wie gesagt, Sie können entweder die .tar.gz-Datei für Linux oder die .msi-Datei oder auch Docker herunterladen. Sie können einfach ein Docker-Image davon ziehen NCache. Das ist das Ende meiner Präsentation. Vielen Dank.