NCache Architektur

Aufgezeichnete Show
Von Ron Hussain und Zack Khan

Das heutige Webinar basiert auf NCache ArchitekturWir werden Ihnen nun einen Überblick über verteiltes Caching geben und zeigen, wie es Ihre Engpässe in .NET und .NET Core behebt. Wir werden gängige Anwendungsfälle, die Architektur des verteilten Caches und Details zum Clustering behandeln sowie alle Ihre Fragen dazu beantworten. NCache, aber Caching im Allgemeinen. Während des gesamten Webinars haben Sie die Möglichkeit, hier im GoToWebinar-Fragen-Tab jederzeit Fragen zu stellen. Schauen Sie sich also gerne den Fragen-Tab an. Sobald Sie eine Frage stellen, kann ich sie während der Präsentation aufrufen und von Ron oder mir beantworten lassen. Am Ende dieser Sitzung haben wir noch etwas Zeit, um weitere Fragen zu beantworten. Wir freuen uns auf eine tolle Zeit.

Also, ohne weitere Umschweife übergebe ich das Wort an Ron, und los geht’s. Sehr gut, danke, Zack. Also, wie Zack gerade erwähnt hat, das heutige Thema ist NCache Architektur. In diesem Webinar werde ich detailliert erläutern, wie NCache Clustering funktioniert, was sind die gängigsten Topologien, aus denen Sie wählen können, und einer der Hauptvorteile von NCache in Bezug auf Ihre Anwendungsfälle. Was sind diese Anwendungsfälle und wie können Sie den vollen Nutzen daraus ziehen? NCache innerhalb Ihrer Serveranwendungen?

Ich hoffe, jeder kann meinen Bildschirm sehen. Sobald ich eine kurze Bestätigung dafür bekomme, kann ich schnell loslegen. Ja, ich denke, wir sind alle gut aufgestellt. So, denke ich. Sieht gut aus. Perfekt. Okay, also, lasst uns schnell damit anfangen.

Das Skalierbarkeitsproblem

Also gut, definieren wir zunächst, was NCache ist? Und dafür muss ich definieren, was ein Skalierbarkeitsproblem ist und wie NCache kann dieses Skalierbarkeitsproblem lösen. In einer typischen Serverarchitektur, in der Anwendungen bereitgestellt werden, sind in der Regel mehrere Instanzen oder Server vorhanden, unabhängig davon, ob diese Anwendungen bereitgestellt werden. Man kann also davon ausgehen, dass Ihre Anwendungsebene sehr skalierbar ist.

Sie können beliebig viele Server in einer Anwendungsebene hinzufügen. Sie können ein Webformular oder ein App-Formular erstellen, bei dem mehrere Anwendungsserver oder Webserver dieselbe Anwendung hosten, aber im Team arbeiten und die Anforderungslast untereinander aufteilen. Und wenn Sie auf eine neuere Architektur, beispielsweise eine Microservices-Architektur, umsteigen, können Sie Ihre Anwendungsdienste individuell skalieren – Microservices, die mehr Rechenleistung oder mehr Kapazität zur Anforderungsbearbeitung benötigen.

Die App-Ebene ist also sehr skalierbar. Sie ist linear skalierbar. Mit zunehmendem Wachstum können Sie immer mehr Anfragen bewältigen. Problematisch wird es bei Datenbanken, beispielsweise relationalen Datenbanken. Denn all diese Anwendungen müssen, unabhängig von ihrer Skalierbarkeit, immer mit einer Backend-Datenbank kommunizieren. Und wenn sie mit einer Backend-Datenbank kommunizieren, handelt es sich in der Regel um eine einzelne Quelle. Und das ist nicht sehr skalierbar. Für die Speicherung ist das sehr gut, man kann über viele Festplattenressourcen verfügen und so von Speichervorteilen profitieren. Aber wenn Ihre Anwendungen eine enorme Transaktionslast haben und sich dies auf die Datenbanktransaktionslast auswirkt, neigen Datenbanken dazu, auszufallen. Und das ist das Hauptproblem, denn die Anwendung hat Probleme mit der Anfrageverarbeitung. Es ist nicht skalierbar und auch die Endbenutzererfahrung wird beeinträchtigt.

NoSQL-Datenbanken lösen dieses Problem teilweise. Zwar ist auch eine SQL-Datenbank möglich, doch erfordert dies eine grundlegende Umstrukturierung der Anwendung, sodass keine relationale Datenbank mehr verwendet wird, sondern eine NoSQL-Datenbank zum Einsatz kommt – ein umfangreiches Projekt. Daher ist NoSQL nicht immer die optimale Lösung für Skalierungsprobleme.

Die Lösung: NCache Verteilter Cache

Was sollten wir also jetzt tun, wenn wir das haben? Die Lösung ist ganz einfach: Sie sollten einen verteilten Cache im Arbeitsspeicher haben, wie in NCache. Erstens ist es In-Memory, sodass der größte Vorteil darin besteht, dass die Leistung Ihrer Anwendung gesteigert wird. Es ist superschnell im Vergleich zu einer relationalen Datenbank. Und der Hauptvorteil ist die lineare Skalierung. Im Gegensatz zu einem Datenbankserver, der in der Regel eine einzelne Quelle ist. NCache kann auf mehreren Servern liegen. Es ermöglicht Ihnen, eine Cache-Cluster die auf mehreren Rechnern laufen kann. Und wie Sie wissen, wachsen Ihre Anforderungen oder Bedürfnisse, wenn Sie mehr Kapazität zur Anforderungsverarbeitung benötigen, die von Ihrer Anwendungsebene verarbeitet werden muss. Sie können zur Laufzeit weitere Server im Cache-Cluster hinzufügen.

Das Schöne daran NCache Der Vorteil liegt darin, dass Sie es zusätzlich zu einer relationalen Datenbank oder einer Back-End-Datenbank verwenden. Es ersetzt nicht Ihre herkömmlichen Datenquellen. Es ergänzt die vorhandenen Datenquellen und steigert so die Leistung Ihrer Anwendungen. Es erhöht die Anfragekapazität Ihrer Anwendungen. Und wenn Ihre Anwendung wächst, können Sie die Anzahl der Server im Cache-Cluster jederzeit erhöhen, da diese Server in einem Cluster als Team arbeiten. Sie können die Anfragelast so untereinander aufteilen, dass Sie lineare Skalierbarkeit erhalten. NCache ist ein linear skalierbares Modell und sehr einfach zu verwenden. Lassen Sie uns darüber sprechen, wie die Bereitstellungsarchitektur funktioniert. In einer typischen großen Produktionsumgebung sieht das folgendermaßen aus: NCache würde aussehen wie:

Sie hätten eine Reihe von Servern. Dies könnten Windows- oder Linux-Dienste sein, die so konzipiert sind, dass NCache sitzt zwischen Ihrer Anwendung und der Datenbank. Sie können beispielsweise mit zwei oder drei NCache Server, und dann können Sie auf vier oder fünf NCache Server und verschiedene Anwendungstypen – beispielsweise Ihre ASP.NET- oder ASP.NET Core-Webanwendungen, Ihre .NET- oder .NET Core-Dienste oder .NET/.NET Core-Serveranwendungen. Auch Java- oder Node.js-Anwendungen können davon profitieren.

NCache Es selbst ist in .NET/.NET Core geschrieben. Es läuft sowohl unter Windows als auch unter Linux. Ihre Anwendungen können daher auf jeder beliebigen Plattform laufen und funktionieren problemlos. Im Allgemeinen empfehlen wir Ihnen Folgendes: NCache auf dedizierten Setup-Servern, die nur hosten NCache, sodass Sie über dedizierte Ressourcen verfügen für NCacheUnd dann befinden sich Ihre Anwendungsserver auf einer separaten Ebene. So verfügen Sie auch über dedizierte Ressourcen für Ihre Anwendungen. Es gibt aber auch eine weitere Bereitstellungsoption, bei der Sie für kleinere Konfigurationen Folgendes haben können: NCache sitzen auf den gleichen Boxen, wo Ihre Anwendungen auch laufen. Also, das ist immer eine Möglichkeit mit NCache. Wie bereits erwähnt, empfiehlt sich jedoch die Verwendung einer separaten Cache-Ebene, wie im Diagramm dargestellt. Und dann NCache sitzt zwischen Ihrer Anwendung und der Datenbank. Die Idee dahinter ist, dass Sie die Daten zwischenspeichern, die Sie in Ihren Anwendungen am häufigsten verwenden. Dabei kann es sich um Referenzdaten oder Transaktionsdaten handeln. Mit „Referenz“ meine ich Daten, die leseintensiv sind, und mit „Transaktionsdaten“ meine ich Daten, die sowohl lese- als auch schreibintensiv sind. Sobald Sie wissen, welche Daten zwischengespeichert werden sollen, können Sie diese Daten als „Arbeitssatz“ bezeichnen. Sie können diese Daten zunächst aus der Datenbank abrufen und anschließend in NCache und nachfolgende Anrufe können über NCache Sie sparen sich teure Datenbankzugriffe. Dies wird als „Cache-Aside“-Muster bezeichnet, bei dem alle Änderungen, die Sie vornehmen, auch in den Cache und dann in die Datenbank übertragen werden. Und da die Datenbank nicht im Cache vorhanden ist, holen Sie sie immer aus der Datenbank und behalten sie im Cache. NCache Sie überprüfen jedoch immer zuerst den Cache. Wenn Sie also Daten im Cache finden, müssen Sie nicht zur Datenbank gehen und können von dort aus zurückkehren.

Durchlesen / Durchschreiben

Der alternative Ansatz hierzu besteht in der Verwendung von „Read-Through“ oder „Write-Through“, was hier durch gepunktete Linien dargestellt wird. NCache verfügt über eine Funktion, die dies automatisieren kann. Sie bietet die Option „Cache-Through“, die als „Read-Through“ für Lesevorgänge und „Write-Through“ für Schreibvorgänge bezeichnet wird. Dabei verwenden Sie immer den Cache als Hauptquelle und implementieren einen Read-Through- und Write-Through-Handler im Cache, der die Aktualisierung der Backend-Datenquellen übernimmt. Unabhängig davon, welche Lesevorgänge Sie durchführen, werden fehlende Daten nahtlos in Ihre Datenbank (basierend auf Ihrem Provider) übertragen, für Ihre Anwendung abgerufen, an die App zurückgegeben und dort gespeichert. NCache. Bei Updates werden der Cache und die Datenbank synchron oder asynchron aktualisiert, je nachdem, welches Modell Sie von der Anwendung aus aufgerufen haben.

Ich werde Ihnen mehr Details zu Read-Through-, Write-Through- und Caching-Mustern mitteilen. Um Ihnen jedoch einen Überblick über die Bereitstellung zu geben, sehen Sie Folgendes: NCache in einem Serverformular bereitgestellt, wo mehrere Anwendungen oder Anwendungsformulare sie verbinden können NCache Und dann können sie die Vorteile des verteilten Cachings nutzen, bei dem der Zugriff auf den Arbeitsspeicher die Anwendungsleistung verbessert. Mehrere Server in der Cache-Ebene ermöglichen zudem lineare Skalierbarkeit. Ich hoffe, das war verständlich. Bei Fragen melden Sie sich bitte. Zum Glück gibt es derzeit keine, also fahren Sie ruhig fort. Sehr gut.

NCache Skalierbarkeitszahlen

Als nächstes werde ich darüber sprechen NCacheSkalierbarkeitszahlen. Wir haben gerade erwähnt, dass NCache ist in der Lage, das Skalierbarkeitsproblem für Ihre Anwendung zu lösen. Also, NCache selbst ist linear skalierbar. Da die Anwendungsebene skalierbar ist und ein Datenbankengpass durch ein linear skalierbares Modell behoben wird, sind hier einige Zahlen, die Sie als Referenz nehmen können. Dies waren unsere Benchmarktests, die wir in unserer QA-Umgebung durchgeführt haben. Wir verwendeten Server mit hoher CPU- und RAM-Auslastung, um sie optimal nutzen und in Hochlastsituationen einsetzen zu können. Wir begannen mit einem Server und erhöhten die Anwendungslast mit zwei Servern kontinuierlich. Sobald die CPU- und RAM-Kapazität eines Servers ausgeschöpft war, fügten wir einen weiteren Server hinzu.

Das ist die Faustregel; wo Sie bestehende Cache-Server weiter verwenden können, beginnen Sie mit zwei NCache Server, und wenn Sie sehen, dass die Hardwarekapazität dieser beiden Server an ihre Grenzen stößt, wenn Ihre CPU oder Ihr RAM an ihre Grenzen stößt – dann ist das der Punkt, an dem Sie entscheiden, dass Sie jetzt skalieren und einen dritten Server zum Cache-Cluster hinzufügen müssen. Genau das haben wir mit einer durchschnittlichen Objektgröße von 1 Kilobyte gemacht. Wir haben die Anwendungslast und die Anzahl der Server immer weiter erhöht, bis die angegebene Serveranzahl an ihre Grenzen gestoßen war. Und das waren keine unsicheren Daten, sondern echte Anwendungsdaten, die jedoch in unserem QA-Labor simuliert wurden. Mit zwei, drei, vier, fünf oder sogar bis zu fünf Servern konnten wir also 2 Millionen Anfragen pro Sekunde mit einer durchschnittlichen Objektgröße von 1 Kilobyte verarbeiten.

Es handelte sich also um eine Kombination aus Lese- und Schreibvorgängen, die konsequent auf den Cache angewendet wurden. So wurde insgesamt ein Durchsatz von 2 Millionen Anfragen pro Sekunde erreicht. Und das ohne Kompromisse bei der Leistung. Durchsatz bedeutet also nicht nur die Anzahl der Anfragen pro Sekunde, sondern auch die Einhaltung der Latenz einzelner Anfragen und eine hohe Geschwindigkeit. Eine Videodemonstration hierzu sowie ein Whitepaper finden Sie auf unserer Website (Siehe hier). Und das ist etwas, das Sie ebenfalls überprüfen können.

Allgemeine Verwendung von verteiltem Cache

Okay, lassen Sie uns über einige der häufigsten Anwendungsfälle von NCache.

• App-Daten-Caching

  Der wichtigste Anwendungsfall ist das Zwischenspeichern von Anwendungsdaten. Wir nennen es App-Daten-Caching. Dies sind die Daten, die aus einer Backend-Datenbank stammen. Wir haben bereits festgestellt, dass Datenbanken im Allgemeinen langsam sind, da sie festplattenbasiert sind. RAM ist im Vergleich dazu eine schnellere Quelle. Ein weiteres Problem ist, dass Datenbanken bei hohem Datenverkehr oft überlastet sind. Bei hoher Transaktionslast und nur einem Server ist zu erwarten, dass dieser nicht die erforderliche Leistung für die Anwendung bietet. Daher ist es sinnvoll, Anwendungsdaten innerhalb Ihrer Anwendungen zu cachen, indem Sie NCache. Es ist ganz einfach; Sie verwenden NCache APIs und Sie rufen einfach den Cache auf. Sie verbinden sich mit dem Cache, indem Sie die Cache-Initialisierungs-APIs aufrufen. Sobald Sie mit dem Cache verbunden sind, können Sie „Cache.Hinzufügen, Cache.Aktualisieren, Cache.Entfernen' oder 'Cache.Get', um Daten aus dem Cache abzurufen. Ich werde Ihnen am Ende einige Beispiele zeigen. Die Idee dahinter ist, dass Sie alle Daten, die Sie mehr als einmal lesen möchten, ob Referenzdaten oder Transaktionsdaten, verwenden können. Für Referenzdaten gilt: NCache wird einen großen Mehrwert bieten, da zum Abrufen von Änderungen nicht zur Datenbank zurückgekehrt werden muss.

  

  Richtig, die Daten im Cache bleiben für einen längeren Zeitraum nutzbar. Und während Sie Daten aus NCachemüssen Sie nicht auf die Backend-Datenbank zugreifen. Das verbessert die Leistung Ihrer Anwendung. Und es bietet Ihnen Skalierbarkeit, weil NCache ist im Vergleich skalierbar.

  Es ist ganz intuitiv, alle Referenzdaten zu cachen. Wir empfehlen jedoch auch, einige oder sogar die meisten Transaktionsdaten zu cachen. Unserer Erfahrung nach empfehlen wir, alle Daten, die Sie mehr als einmal lesen, auch zwei- oder dreimal, zu cachen. Denn selbst wenn die Daten in der Datenbank geändert werden und nach dieser Änderung mehr als einmal gelesen werden – zwei- oder dreimal –, ist es sinnvoll, diese Daten zu cachen, damit Sie nicht in die Backend-Datenbank gehen müssen. Und wir haben Funktionen integriert in NCache Dadurch erhalten Sie auch eine 100%ige Synchronisierung mit der Datenbank. Das ist etwas, das Sie, wissen Sie, auch immer in Betracht ziehen können.

  Ron, ich habe eine kurze Frage, die hauptsächlich lautet:
  Muss ich immer über das Netzwerk auf meinen Cluster-Cache zugreifen? Ich befürchte, dass meine Anwendungen aufgrund von Netzwerkproblemen nicht mehr funktionieren. Gibt es eine Möglichkeit, einige meiner Daten lokal zu verwalten?

  Okay, normalerweise empfehlen wir Ihnen, dass Sie NCache auf separaten Feldern und dann Ihre Anwendung auf separaten Feldern, richtig? So dass, wenn NCache basiert auf dem TCP-Protokoll und ist somit ein Netzwerkaufruf. Es gibt eine Funktion namens „Client-Cache“, einen lokalen Cache auf den Anwendungsrechnern. Wenn Sie mehr Leistung benötigen und netzwerkbedingte Latenzen vermeiden möchten, kann der Cache auch „in-proc“ implementiert werden, d. h., er befindet sich innerhalb Ihres Anwendungsprozesses. In diesem Fall wird die Datenmenge automatisch in den Client-Cache übertragen. Das spart Prozess-zu-Prozess-Kommunikation und damit Netzwerkkommunikation und Netzwerk-Overhead. Wir haben also eine Funktion, auf die ich im Rahmen unserer Topologien eingehen werde. Ich werde noch einige Details erläutern, aber um Ihnen einen kurzen Überblick zu geben: So funktioniert der Client-Cache: Er befindet sich auf demselben Rechner wie Ihre Anwendungen. Die Idee dahinter ist, dass bei aktiviertem Client-Cache keine häufigen Netzwerkzugriffe erforderlich sind. Und das funktioniert ohne Codeänderungen. Ich hoffe, das beantwortet die Frage. Bitte lasst mich wissen, wenn es noch weitere Fragen gibt. Ja, klingt gut. Ron, übernimm die Sache. Sehr gut.

• ASP.NET- und ASP.NET Core-Caching

  Der nächste Anwendungsfall von NCache Es handelt sich um eine Webanwendung. Wenn beispielsweise Benutzerdaten zwischengespeichert werden müssen, ist das üblich. Typischerweise wird dafür der Sitzungsstatus von ASP.NET oder ASP.NET Core verwendet. Diese Daten gehören nicht in die Datenbank, da sie temporär sind. Es handelt sich um Daten, die ein Benutzer erstellt und die nur so lange im Anwendungskontext verbleiben, wie der Benutzer aktiv ist. In manchen Fällen kann es sinnvoll sein, sie aus historischen Gründen in der Datenbank zu speichern, aber in den meisten Fällen gehören die Daten dem jeweiligen Benutzer.

  Also, Microsoft ASP.NET oder ASP.NET Core Session. Es gibt verschiedene Optionen: Sie können einen Statusserver, In-Process-Sessions oder einen Datenbankserver verwenden. Alle diese Optionen haben ihre Nachteile. In-Process-Sessions stellen beispielsweise einen Single Point of Failure dar; Sie müssen Sticky Session Load Balancing verwenden. Der ASP.NET-Statusserver ist ebenfalls ein Single Point of Failure und bekanntermaßen nicht skalierbar. Eine Datenbank ist eine Option und stellt zwar keinen Single Point of Failure dar, da sie gesichert werden kann, aber in manchen Fällen kann sie dennoch ein Single Point of Failure sein. Sie ist jedoch langsam und nicht skalierbar. Was also tun? Erwägen Sie erneut die Verwendung von NCache Für das Zwischenspeichern des Sitzungsstatus in ASP.NET und ASP.NET Core. Es funktioniert so, dass Sie unseren Provider einbinden. Es ist keine Codeänderung erforderlich, aber sobald Sie ihn einbinden, ... NCache innerhalb Ihrer Anwendungen, NCache wird Ihr Hauptsitzungsspeicher. Und die Idee dahinter ist, dass es superschnell sein wird, weil es RAM-basiert ist. Es ist sehr skalierbar, da es mehrere Server gibt. Und innerhalb NCache, sobald wir mit der Präsentation fortfahren und ich Topologien bespreche, werden Sie verstehen, dass NCache verfügt über Backups mithilfe von Replikationen. Und Sitzungsdaten sind Benutzerdaten, nicht wahr? Es sind also Daten, die man auf keinen Fall verlieren möchte, denn ein Verlust hat Auswirkungen auf den Benutzer und das Unternehmen. Mit der Replikation werden Daten also auch gesichert.

  

  Wenn ich also die Vorteile aufzählen muss, die Sie erhalten, dann ist es zunächst einmal die Verbesserung der Anwendungsleistung durch In-Memory-Zugriff. Sie haben mehrere Server, die Ihre Anwendungen für das Session-Caching unterstützen, was eine hohe Skalierbarkeit ermöglicht. Darüber hinaus sind Funktionen für hohe Verfügbarkeit und Datenzuverlässigkeit integriert. Es kommt also nicht zu Sitzungsdatenverlusten oder Ausfallzeiten der Anwendung, falls NCache Server ausfällt. Und Sie müssen Sticky Session Load Balancing nicht mehr verwenden, weil NCache ist eine gemeinsame Entität. Anfragen können an jeden Webserver gesendet werden; es werden immer Daten von NCache basierend auf unserem Protokoll. Also alles ohne Codeänderungen.

  Ein weiterer Anwendungsfall: Sie können Ihren Ansichtsstatus auch bündeln, wenn Sie ASP.NET-Webformulare verwenden. Dort wird auch der Ansichtsstatus zwischengespeichert. Der Ansichtsstatus ist umfangreich und verbraucht viel Bandbreite. Er wird Teil Ihrer Anfrage- und Antwortpakete und wird immer an den Browser zurückgesendet. Dort wird er nie wirklich verwendet, sondern im Browser, auf der Clientseite, gespeichert. Und wenn Sie ihn zurücksenden, wird der Ansichtsstatus dort auf der Serverseite zurückgebracht. Also, mit NCacheWir ermöglichen Ihnen, den Ansichtsstatus serverseitig zwischenzuspeichern, sodass Ihre Nutzlast keinen umfangreichen Ansichtsstatus mehr hat. Das verbessert die Leistung. Obwohl der Ansichtsstatus immer im Browser gespeichert wird, verbessert es das allgemeine Anwendungsverhalten, wenn Sie ihn serverseitig belassen, wo er benötigt wird. Er verbraucht nicht mehr Ihre Bandbreite, da das eigentliche Anforderungs- und Antwortpaket keinen umfangreichen Ansichtsstatus mehr hat. Und es ist sehr sicher, da der Ansichtsstatus serverseitig gespeichert wird. Darüber hinaus können Sie Verschlüsselung und Sicherheitsfunktionen einrichten. Auch diese Option erfordert keine Codeänderungen. Sie gilt jedoch nur für ältere Webformulare. Wenn Sie also eine ASP.NET-Webformularanwendung haben, empfehle ich Ihnen, auch die Zwischenspeicherung des Ansichtsstatus in Betracht zu ziehen.

  Und dann gibt es noch das Antwort-Caching von ASP.NET und ASP.NET Core. Statische Seiten oder statische Seitenteile sollten zwischengespeichert werden. In ASP.NET Core gibt es eine Option für das Antwort-Caching, die ohne Codeänderungen aktiviert werden kann. Zusätzlich gibt es die SignalR-Backplane von ASP.NET und ASP.NET Core. Bei der Verwendung von SignalR in einem Webformular ist eine Backplane zwingend erforderlich. Typische Backplanes, wie Dateisysteme oder Datenbanken, können die bereits erwähnten Skalierungs- und Leistungsprobleme mit sich bringen. NCacheDas System wird extrem schnell, hochskalierbar und zuverlässig sein, da wir im Hintergrund ein äußerst zuverlässiges Messaging-System verwenden. Dies sind einige Anwendungsfälle, die Sie in ASP.NET- oder ASP.NET Core-Anwendungen nutzen können.

Bevor ich weitermache, Zack, ich glaube, es wurde eine Frage gestellt. Ja. Die Frage kam im Grunde von „DB by default“. Ich wollte warten, bis Sie fertig sind, aber die Frage ist im Grunde: Könnten Sie die Frage bitte näher erläutern, Sir?

Hallo Ron, ist NCache auch für Datenveröffentlichungszwecke geeignet, mit der Anforderung, Daten im Arbeitsspeicher-Cache zu speichern, mit Optionen zum Synchronisieren von Daten in der Datenbank als Hintergrundprozess? Und kann NCache Kümmert sich standardmäßig um den Synchronisierungsmechanismus zwischen Speichercache und Datenbanken?

Ja, das ist eine sehr gute Frage. In fortgeschrittenen Fällen ist dies immer eine Voraussetzung. Es funktioniert auf zwei Arten. Erstens verwendet Ihre Anwendung jetzt Daten, die von NCache, aber Daten sind in der Datenbank vorhanden. Es handelt sich also um zwei verschiedene Quellen, die sowohl zum Lesen als auch zum Schreiben synchronisiert werden müssen. Wenn nun die Anwendung, die mit NCache und die Datenbank ist die einzige Anwendung, die für die Änderung von Daten innerhalb verantwortlich ist NCache und Datenbank, Sie jetzt, wir empfehlen Ihnen, Read-Through und Write-Through zu verwenden. Und ja, dies kann je nach Ihren Anforderungen asynchron oder synchron erfolgen. Was also wirklich passiert, ist, wenn Sie versuchen, einige Daten abzurufen von NCache und es ist nicht im Cache vorhanden und Sie möchten es zwischenspeichern, rufen Sie automatisch Read-Through auf, das basierend auf Ihrem Code aus der Backend-Datenbank liest. Ähnlich verhält es sich, wenn Daten aus einer Datenbank stammen und diese Daten in der Datenbank aktualisiert werden müssen. Sobald Sie die Daten im Cache aktualisieren, verwenden Sie Write-Through. Write-Through kann auch Write-Behind sein, was bedeutet, dass die Daten innerhalb aktualisiert werden müssen. NCache und in der Datenbank mithilfe Ihres Write-Through-Handlers. Und wenn Sie einen asynchronen Aufruf wünschen, können Sie Write-Behind verwenden, sodass dies im Hintergrund erfolgen kann. Aber noch einmal, NCache und Ihre Anwendung ist dafür verantwortlich, wo NCache ruft Ihren Code auf und Ihre Anwendung ruft diesen auf.

Eine andere Situation könnte sein, dass andere Anwendungen Daten in der Datenbank direkt ändern, ohne dass Ihre Anwendung davon Kenntnis hat. In diesem Fall müssen Sie unsere Datenbanksynchronisierungsfunktionen nutzen. Sie sollten benutzerdefinierte Abhängigkeiten erstellen. SQL Server verfügt über eine Kettenbenachrichtigung. Wir haben Datenbankabhängigkeiten. Es gibt also viele Synchronisierungsfunktionen, bei denen jede Änderung in der Datenbank erfasst wird. NCache automatisch. Und Sie können wieder Read-Through verwenden, und Sie können Daten innerhalb neu laden NCache auch. Also, um es zusammenzufassen: NCache kann, wissen Sie, beide Situationen bewältigen: entweder ist es Ihre Anwendung, die die einzige Entität ist, die etwas innerhalb ändert NCache und Datenbank oder in einer Situation, in der die Datenbank außerhalb des Geltungsbereichs der Anwendung geändert werden kann, die das Caching verwendet.

Beide Szenarien sind also abgedeckt, und NCache gibt Ihnen eine 100%ige Synchronisierungsoption für diese Fälle. Wenn Sie über Speichercache sprechen, wird Speichercache normalerweise auch von ASP.NET unterstützt, richtig! Aber wenn Sie sich auf NCache als Speichercache. Ich habe die Frage also bereits beantwortet. Bitte lassen Sie mich wissen, wenn Sie weitere Fragen haben, dann können wir von dort aus weitermachen.

• Pub/Sub-Messaging

  Klingt gut. Ich denke, wir können weitermachen. Klar. Also gut, als nächstes befasse ich mich mit Pub-Sub-Messaging. Wie Sie sehen, NCache wird bereits von Anwendungen gemeinsam genutzt. Es handelt sich also um eine Entität, die Sie für Ihre Datenanforderungen nutzen können. Sie können Daten hinzufügen und abrufen. Sie profitieren von Leistungs- und Skalierbarkeitsvorteilen durch NCacheSie können diesen Anwendungsfall erweitern, indem Sie NCache als Messaging-Plattform. Also, NCache Messaging ist sehr wirkungsvoll innerhalb NCacheEs handelt sich um einen asynchronen, ereignisgesteuerten Mechanismus, bei dem mehrere Anwendungen untereinander Messaging-Anforderungen oder App-Koordinationsanforderungen steuern können. Wenn mehrere Anwendungen miteinander kommunizieren müssen, ist der Aufbau einer Kommunikation eine Herausforderung. Sie müssten sich also auf eine zentrale Einheit verlassen. NCache ist diese Entität. Und mit seiner Messaging-Unterstützung bietet es Ihnen die Möglichkeit, Daten oder Nachrichten einer Anwendung hinzuzufügen NCache, und diese Nachrichten können an alle Abonnenten am anderen Ende weitergeleitet werden: die anderen Anwendungen, die diese Nachrichten benötigen.

  

  Ebenso können datengesteuerte Nachrichten verwendet werden. Sie werden beispielsweise benachrichtigt, wenn Daten hinzugefügt, aktualisiert oder gelöscht werden. Dies können benutzerdefinierte Anwendungsnachrichten oder datengesteuerte Nachrichten sein, sodass beide Bereiche abgedeckt sind, in denen Daten gespeichert werden. NCache Und Sie möchten, dass andere Anwendungen davon erfahren, können Sie die Messaging-Anforderungen darüber steuern. Alternativ kann es sich um benutzerdefiniertes oder anwendungsgesteuertes Messaging handeln, bei dem eine Anwendung mit einer anderen Anwendung kommunizieren muss. Es basiert wiederum auf einem skalierbaren In-Memory-Modell. Es bietet außerdem zuverlässige Replikationsoptionen. Es basiert auf einer konventionellen Pub-Sub-Messaging-Plattform, die ein Topic-Konzept und ein Message-Broker-Konzept verwendet, mit dem mehrere Anwendungen verbunden sind. Sie können also Publisher- und Subscriber-Anwendungen definieren. Publisher-Anwendungen veröffentlichen Nachrichten an NCache die dann an alle diese Abonnenten übermittelt werden. Und dann können die Abonnenten auch ihre eigenen Nachrichten senden. NCache fungiert als Kommunikationsplattform zwischen diesen verschiedenen Anwendungen.

• Volltextsuche (Distributed Lucene)

  Schließlich haben wir noch einen weiteren Anwendungsfall: die Volltextsuche. Wenn Sie also eine Anwendung haben und die Anforderungen für die Volltextsuche erfüllen müssen, NCache, können Sie die Verwendung unserer auf Lucine.NET basierenden Volltextsuchfunktionen in Betracht ziehen.

  Normalerweise ist die Lucene-API eine eigenständige API. Aber innerhalb von Jungs können Sie sie auf mehrere Server erweitern. NCache ermöglicht Ihnen auch das Laden von Indizes im Speicher. NCache plattenbasierte Indizes verwenden, aber es ermöglicht Ihnen, die Speicher- und Anfragekapazität durch den Einsatz mehrerer Server zu erweitern. Obwohl es plattenbasiert ist, ist es dennoch besser als eine einzelne Quelle in der Datenbank. Denn bei hoher Transaktionslast ist jeder Server für seine eigenen Indexanfragen verantwortlich. Es ist daher sehr skalierbar und zudem sehr zuverlässig. Da es sich um einen unterstützten Speicher handelt, ist die Persistenz der Szenenindizes ein Feature mit einem NCache. Alle Daten, die Sie in NCache kann auch auf der Festplatte gespeichert werden, oder basierend auf einigen Datenbankanbietern kann es auch auf einigen Datenbanken gespeichert werden. Aber Lucene ist die einzige Funktion, bei der NCache verwendet Festplatten im Vergleich zu RAM, da die Art des Anwendungsfalls die dauerhafte Speicherung von Daten erfordert.

  

Ich hoffe, es war verständlich. Dies waren einige der Anwendungsfälle. Auch innerhalb dieser Anwendungsfälle bieten wir zahlreiche Funktionen. Alle Arten von Anwendungen und spezifischen Anforderungen innerhalb einer Anwendung können mithilfe unserer Objekt- und Sitzungs-Caching-Funktionen vollständig abgedeckt werden.

Nur eine kurze Frage, Ron.
Gibt es eine Möglichkeit, auf meine Daten im Cache wie auf meine MySQL-Datenbank zuzugreifen? Ich möchte SQL-Abfragen auf meinen Cache-Daten ausführen können. Ist das möglich?

Sicher. NCache unterstützt zunächst eine SQL-Suche und LINQ-Abfragen. Wenn Sie also die Möglichkeit haben, eine Anwendung zu schreiben, die einfach eine Verbindung herstellen kann zu NCacheund führen Sie dann kriterienbasierte Suchen aus. Dies ist die einfache Option, die Sie nutzen können, indem Sie eine kriterienbasierte Suche schreiben. Sie können beispielsweise alle Produkte auswählen, bei denen Produktpreis ist größer als 10 und kleiner als 100. Oder Sie können alle Produkte basierend auf einer Kategorie finden; Sie können Kunden basierend auf einer Region finden. Sie können also SQL-basierte Suchen oder LINQ-basierte Suchen durchführen und NCache würde Ihnen die Daten aus dem Cache geben. Das ist also eine Möglichkeit.

Alternativ bieten wir eine LINQ Pad-Integration an. Wenn Sie Daten visualisieren möchten, ohne eine Anwendung entwickeln zu müssen, ist LINQ Pad eine einfache Lösung. Sie können LINQ-Abfragen ausführen und anschließend Daten visualisieren.

Und als dritte Option bieten wir in unserer nächsten Version ein Datenanalysetool an. Damit bieten wir Ihnen ein automatisiertes Monitoring-Tool, mit dem Sie Ihre im Cache vorhandenen Daten überwachen können. Es bietet Ihnen kriterienbasierte Suchoptionen über eine grafische Benutzeroberfläche. Das ist in Planung; die Anforderungen sind erfüllt, die Entwicklungsarbeiten sind abgeschlossen. Ich denke, es wird Teil unserer nächsten Version sein.

Ich freue mich schon auf alles. Perfekt. Ja. Sehr gut. Ich denke, wir sind fürs Erste gut, Ron. Ein paar dieser Fragen hebe ich mir auch für den Schluss auf, da wir einige interessante Fragen bekommen haben, aber ja, lass uns weitermachen. Klar.

Selbstheilender dynamischer Cluster

Als nächstes werde ich auf den dynamischen Cache-Cluster eingehen, Sie wissen schon, auf alle Einzelheiten dazu. NCache Es basiert auf einem TCP/IP-basierten Cache-Clustering-Protokoll. Wir haben unser eigenes Cache-Clustering implementiert und verwenden weder Drittanbieter- noch Windows-Clustering. Es handelt sich um ein vollständig proprietäres Protokoll. Da es in .NET und .NET Core geschrieben ist, bietet es hohen Bedienkomfort – die TCP-Sockets basieren ebenfalls auf .NET und .NET Core. Die Architektur ist vollständig Peer-to-Peer, wodurch ein Single Point of Failure ausgeschlossen ist. Server können zur Laufzeit hinzugefügt oder entfernt werden, ohne dass der Cache oder die damit verbundenen Clientanwendungen gestoppt werden müssen. So lassen sich Änderungen an einem laufenden Cache-Cluster dynamisch vornehmen. NCache Dies bereitet keine Probleme. Wenn Sie einen Server hinzufügen, werden die Clients zur Laufzeit benachrichtigt. Sie wissen also automatisch, dass dieser Server nicht mehr Teil des Cache-Clusters ist und nutzen den zusätzlichen Server. Der Cluster passt sich automatisch an. Sobald Sie einen Server entfernen, erkennen andere Server, dass dieser endgültig verschwunden ist. Sie benachrichtigen die Clients, und die Clients nutzen den verlorenen Server nicht mehr. Es gibt eine Failover-Unterstützung für Verbindungen, die auch auf der Client-Seite integriert ist. Wenn ein Server ausfällt, stellt der Cluster sicher, dass die Clients dies bemerken, die Verbindung per Failover sichern und die verbleibenden Server nutzen.

Änderungen im Cluster werden in jedem Fall an die Clients weitergegeben. Clients sind intelligent und kennen den Zustand des Cache-Clusters stets. Dies stellt sicher, dass es weder zu Ausfallzeiten noch zu Datenverlust kommt, da die Replikationsunterstützung integriert ist. NCache ist hochverfügbar und dank Replikation auch sehr zuverlässig. Es gewährleistet 100% Verfügbarkeit auf der Anwendungsseite, ohne Anwendungsunterbrechungen. Sie können weiterhin NCache.

Caching-Topologien

Als Nächstes werde ich über die Caching-Topologien sprechen. Das ist der Hauptaspekt, den ich behandeln wollte. Wir haben vier Optionen zur Auswahl. Die erste Option ist wiederum für kleinere Konfigurationen gedacht. Diese bestimmen, wie Sie einen Cache konfigurieren.

Gespiegelter Cache

Wir haben also die Möglichkeit, einen Cache mit einer gespiegelten Cache-Topologie zu konfigurieren. Dabei stehen maximal zwei Server zur Verfügung. Einer dieser Server fungiert als aktiver Server, mit dem alle Clients verbunden sind. Der andere Server fungiert als passiver Server, der als Backup dient. Das Backup wird von NCacheDiese Topologie folgt, sobald Sie sie konfiguriert haben, automatisch der Architektur. Sie müssen im Grunde nicht definieren, ob dies aktiv oder passiv wird. Das geschieht durch NCache automatisch. Sobald dies geschieht, verbinden sich alle Client-Anwendungen mit dem aktiven Server und lesen und schreiben dort Daten. Alle Daten auf dem aktiven Server werden über eine asynchrone Spiegelungsoption auf dem passiven Server gesichert. Der Client aktualisiert den aktiven Server und gibt ihn zurück, sodass auf der Client-Anwendungsseite keine Replikationsgebühren anfallen. Die Client-Anwendung ist superschnell. Hinter den Kulissen NCache sollte das Backup aktualisieren. Das Backup hat einen wichtigen Grund: Fällt Server 1 aus, wird der Backup-Server automatisch als aktiver Server aktualisiert. Clients wechseln dann ihre Verbindungen und nutzen den neuen, zuvor aktiven Backup-Server. Sobald der erste Server wieder verfügbar ist, wird er erneut als Backup-Knoten und nicht als aktiver Knoten hinzugefügt, da wir bereits einen aktiven im Cache-Cluster haben. All dies geschieht nahtlos für Ihre Anwendungen. Sie müssen nicht eingreifen, wenn ein Server hinzugefügt wird oder ausfällt.

Diese Topologie eignet sich sowohl für Lese- als auch für Schreibvorgänge. Sie eignet sich gut für Referenzdaten und Transaktionsdaten, hat aber ein Kapazitätsproblem, da maximal zwei Server zur Verfügung stehen und von diesen jeweils nur einer aktiv ist. Für kleinere Konfigurationen mit zuverlässigen Daten könnte Caching eine Option sein.

Replizierter Cache

Die zweite Option ist ein replizierter Cache. Auch dieser ist für kleinere Konfigurationen gedacht. Dabei sind alle Server aktiv. Wie Sie sehen, sind Server 1 und Server 2 beide aktiv. Die Clients sind auf verschiedene Server verteilt. Bei sechs Clients, wie im Diagramm dargestellt, verbinden sich also einige mit Server 2 und andere mit Server 2. Diese drei sind mit Server XNUMX und diese mit Server XNUMX verbunden.

Dies geschieht automatisch; der Verbindungsausgleich ist in NCacheAlle Server sind aktiv, aber jeder Server verfügt über eine Kopie des Caches. Unabhängig von den Daten auf Server 1 befindet sich eine Kopie auf Server 2, die mithilfe von Synchronisierungsupdates verwaltet wird. Alle Updates, die Sie auf einem Server durchführen, müssen in einem Synchronisierungsaufruf auf den anderen Servern angewendet werden. Der Client wartet also, bis der Vorgang abgeschlossen ist. Schlägt der Vorgang auf einem Server fehl, wird der gesamte Vorgang zurückgesetzt. So erreichen wir eine 100 % synchronisierte Kopie auf allen Servern. Dies ist sehr zuverlässig, aber auch bei leseintensiven Anwendungsfällen erhöht sich die Lesekapazität, da Sie mehr Datenkopien oder Kopien von verschiedenen Servern haben. Mit zunehmender Anzahl an Servern erhöht sich die Lesekapazität, da mehr Server Anfragen bearbeiten können. Wie Sie gerade gesehen haben, muss jedoch jeder Schreibvorgang durch ein Synchronisierungsupdate auf allen Servern ausgeführt werden. Dies eignet sich daher für kleinere Konfigurationen hinsichtlich der Schreibkapazität. Bei drei oder vier Servern müssen Sie denselben Vorgang drei- oder viermal ausführen, was sich negativ auf die Leistung auswirken kann. Diese Topologie empfiehlt sich daher eher für Referenzdatenszenarien und kleinere Konfigurationen. Sie ist skalierbar für Lesevorgänge, weniger skalierbar für Schreibvorgänge, aber sehr zuverlässig. Sie sorgt für hohe Verfügbarkeit und Datenzuverlässigkeit, denn bei Serverausfall, beispielsweise bei Server 1, kommt es weder zu Datenverlusten noch zu Ausfallzeiten, da die Anwendungen ein Failover durchführen und den verbleibenden Server auswählen, der bereits über eine Kopie des Caches verfügt.

Partitionierter Cache und Partitionsreplikat-Cache

Die nächste Option ist die Konfiguration eines partitionierten Caches. Partitionierte und partitionierte Replikate sind die gängigsten Topologien. Mit partitioniertem Cache können Sie Daten auf Ihre verfügbaren Serverknoten verteilen. Wenn Sie beispielsweise zwei Server haben und Daten haben, wird die Hälfte der Daten auf Server 1 und die andere Hälfte auf Server 2 gespeichert. Die Datenverteilung ist ebenfalls Teil von NCache. Dies ist nicht etwas, was Ihre Anwendungen tun, sondern wird zur Laufzeit automatisch von Anwendungen erledigt. Es gibt eine intelligente Verteilungskarte und einen Hash-Algorithmus, die bestimmen, welche Daten an welchen Server gesendet werden.

Basierend darauf verteilen Ihre Anwendungen die Daten gleichmäßig auf alle Server im Cache-Cluster. Da die Daten nun gleichmäßig verteilt sind, verteilt sich auch Ihre Anfragelast gleichmäßig. Dadurch erhalten Sie je nach Serveranzahl mehr Lese- und Schreibkapazität. Bei zwei Servern arbeiten zwei Server im Team. Und wenn Sie von zwei auf drei erweitern, verarbeiten mehr Server Ihre Lese- und Schreibanfragen. Sie erhalten also mehr Skalierbarkeit für Lese- und Schreibvorgänge. Linear skalierbar erhöhen Sie die Skalierbarkeit, wenn Sie weitere Server hinzufügen. Durch das Hinzufügen weiterer Server bündeln Sie auch die Speicherressourcen, da die Daten verteilt sind und Sie den Speicher aller Server zusammenfassen. Bei zwei Servern haben Sie also die Kapazität von zwei Servern. Wenn Sie einen dritten oder vierten Server hinzufügen, erhöhen Sie Ihre Kapazität um die entsprechende Anzahl an Servern. Die Gesamtkapazität wird also gepoolt, sodass Sie ein lineares Wachstum erzielen, wenn Sie weitere Server zum Cache-Cluster hinzufügen.

Sehr gut für Lese- und Schreibvorgänge, sehr skalierbar für Referenz- und Transaktionsdaten. Einziger Nachteil dieser Topologie: Sie verfügt über kein Backup. Fällt ein Server aus, geht auch die Partition verloren. In diesem Fall müssen Sie die Daten aus einer Backend-Datenbank wiederherstellen. Wenn Ihr Hauptziel also eine hohe Performance ist, eine leistungsorientierte Anwendung, und Sie es sich leisten können, auf eine Datenbank zurückzugreifen, was häufig der Fall ist, sind Sie nicht auf NCache Für hohe Verfügbarkeit und Datenzuverlässigkeit bietet Ihnen dies die beste Leistung im Vergleich zu allen anderen Topologien.

Wenn Sie jedoch hohe Verfügbarkeit benötigen und die Anforderungen an die Datenzuverlässigkeit auch von NCacheIch habe eine bessere Topologie, die sich „Partition of Replica Cache“ nennt. Die Gesamtarchitektur ist nun genau wie eine Partitionierung mit einer Erweiterung der Replikate, wobei jeder Server eine Datenpartition hat, aber jeder Server zwei Partitionen verwaltet: eine aktive Datenpartition, mit der die Clients verbunden sind, und eine Backup-Partition eines anderen Servers. Server 1 ist aktiv, sein Backup befindet sich auf Server 2, Server 2 ist aktiv, sein Backup befindet sich auf Server 1. Sie haben die Möglichkeit, zwischen synchronen und asynchronen Backup-Optionen zu wählen. Wenn Sie die Replikatpartition mit asynchronem Modus wählen, aktualisiert der Client die aktive Partition und gibt die auf dem Client abgeschlossenen Vorgänge zurück. Anschließend NCache aktualisiert die Backup-Partition im Hintergrund. Wenn Sie synchronisieren, aktualisiert die Client-Anwendung die aktive Partition und das Backup transaktional. So oder so ist synchronisieren natürlich zuverlässiger, asynchron ist schneller. Aber so oder so, NCache ist in der Lage, die Datenzuverlässigkeit so zu handhaben, dass beim Ausfall eines Servers die Backup-Topologie aktiviert wird und es weder zu Datenverlusten noch zu Anwendungsausfallzeiten kommt. Richtig.

Lassen Sie mich Ihnen kurz diese Topologie mit drei Servern zeigen. Sie bietet alle Vorteile: hohe Leistung beim Lesen und Schreiben, lineare Skalierbarkeit sowohl beim Lesen als auch beim Schreiben. Darüber hinaus profitieren wir von Skalierbarkeit, hoher Verfügbarkeit und Datenzuverlässigkeit. Bei einem Serverausfall kommt es weder zu Datenverlusten noch zu Anwendungsausfällen.

Demo

Ich hoffe, das ist verständlich. Ich zeige Ihnen jetzt unsere Demoumgebung und zeige Ihnen kurz, wie Sie diese Caching-Topologien erstellen und anschließend einen Cache-Cluster schnell testen. Bei Fragen stehen wir Ihnen gerne zur Verfügung. Nur eine kurze Erinnerung: Alles, was wir zeigen, können wir auch in Form von Hand-Holding-Sitzungen und technischen Support-Sitzungen in Ihren Umgebungen für Ihre spezifischen Anwendungsfälle durchführen. Wir würden uns freuen, auch nach dem Webinar mit Ihnen als Team darüber sprechen zu können, um Ihnen zu zeigen, wie es für Sie funktionieren würde.

Was die Fragen betrifft, habe ich eine, die ganz zum Schluss kam. Eine davon ist eine Ihrer Lieblingsfragen.
Es gab viele Diskussionen über die Verwendung von Hazelcast für das Anwendungs-Caching. Was bedeutet NCache bieten, was Hazelcast nicht bietet?

Okay. Zunächst einmal handelt es sich eher um eine Debatte. NCache ist tatsächlich in .NET und .NET Core geschrieben, daher die bevorzugte Plattform für NCache ist Windows. Das Schöne an NCache ist, dass es sowohl auf .NET als auch auf Windows und Linux läuft. Plattform- und Kompatibilitätsunterstützung, die NCache Angebote, es gibt kein anderes Produkt, das das erreichen kann. Das ist also der erste Punkt, bei dem es die bevorzugte Wahl ist, wenn Sie sich Gedanken über die Plattform machen, die Sie nutzen möchten. Der andere Unterschied ist, und ich würde jedem empfehlen, sich unsere Vergleichsseiten, dort finden Sie auch sehr gutes Material. Aber um es kurz zusammenzufassen: NCache Die Objekt-Caching-Unterstützung bietet viele Funktionen, die anderen Produkten völlig fehlen. Zum Beispiel verfügen wir für die SQL-Suche über umfangreiche Funktionen in NCache. Wir haben Cache Loader und Cache Refresher. Das sind Funktionen, die völlig einzigartig sind NCacheUnser Read-Through- und Write-Through-Handler mit der Fähigkeit, .NET- und .NET Core-Code serverseitig auszuführen, ist ein absolut einzigartiges Merkmal. NCache, und die Liste geht weiter, richtig. Einige der Funktionen, die Sie serverseitig anpassen können, sind nur verfügbar in NCache Aus Anwendungssicht fehlen viele Funktionen in anderen Produkten. Ich empfehle daher jedem, einen Blick auf unsere Vergleichsseite zu werfen. Dort finden Sie einige Vergleiche einzelner Funktionen, die Ihnen detailliertere Informationen dazu bieten.

Dies ist definitiv unsere Lieblingsfrage, ob es sich um ein Webinar oder sogar eine technische Lösung handelt, es könnte Hazlecast sein, es könnte Scala sein, es könnte Redis, aber vielen Dank, Ron. Ja, ich denke, wir können loslegen. Bitte fahren Sie fort. Sicher.

Neuen Cluster-Cache erstellen

Lassen Sie mich Ihnen eine kurze Produktdemo geben, indem ich einen neuen Cluster-Cache erstelle. Nennen wir ihn Test-Cache. Gut, lassen Sie mich das hier verschieben, bitte haben Sie etwas Geduld. Okay.

So, und wir haben gerade vier Caching-Topologien erklärt. Ich entscheide mich für die Partition des Replikat-Caches, da diese mit der asynchronen Replikationsoption am meisten empfohlen wird. Ich behalte alle Standardeinstellungen bei.

Im Folgenden zeige ich Ihnen, wie einfach es ist, einen Cache mit GUI-Tools zu konfigurieren. Dies ist unser Webmanager, aber Sie können alles auch mit unseren PowerShell-Cmdlets erreichen und die Bereitstellung bei Bedarf automatisieren. Ich füge Server eins hinzu, wo NCache ist installiert. Ich werde dann Server 2 hinzufügen. Also, meine 2 Boxen mit NCache mit einer Größe von 2 GB wird eingerichtet. Meine Idee ist, einen 2-Knoten-Cache-Cluster mit jeweils 2 GB Cache-Größe zu erstellen. Insgesamt also vier GB mit zwei Servern, auf denen NCache ist bereits installiert. Und dann verwende ich meine Box, um eine Verbindung zu diesem Cache-Cluster herzustellen.

TCP-Parameter. Dies ist der Port, den Sie einrichten müssen, sobald Sie dies getan haben. Behalten Sie die Standardeinstellung bei oder geben Sie einen beliebigen Port an, der nicht von der Firewall beeinflusst wird.

Wenn Sie Verschlüsselung und Komprimierung einrichten möchten, sehen Sie hier den Bildschirm. Ich behalte ihn einfach so. Wählen Sie „Weiter“. Wenn Ihr Cache voll ist, können Sie die Auslagerungen auswählen. Eine Option ist, dass der Cache keine Schreibvorgänge mehr zulässt. Es wird die Fehlermeldung „Cache voll“ angezeigt. Alternativ können Sie die Auslagerung einrichten. Basierend auf diesen Algorithmen werden einige Elemente zur Laufzeit aus dem Cache entfernt. Je nach Priorität, Nutzung, zuletzt verwendeten oder häufig verwendeten Elementen können fünf Prozent der Elemente aus dem Cache entfernt werden. Ich starte diesen Cache beim Beenden und Autostart, sodass er bei jedem Neustart des Servers oder NCache Beim Neustart des Servers ist es möglich, die angehaltenen Caches neu zu starten.

Ich wähle „Fertig“, und das war’s. So einfach ist die Einrichtung eines Cache-Clusters. Gleich wird eine weitere Ansicht angezeigt, in der dieser Cache gestartet wird. Anschließend zeige ich Ihnen einige Überwachungs- und Verwaltungsdetails. Wir haben einige ausführlichere Videos zu Cache-Konfigurationen verfügbar. Bei Fragen können Sie sich gerne melden. Wir können aber auch auf diese Videos zurückgreifen.

Ich kann „Cluster überwachen“ auswählen. Daraufhin öffnet sich ein weiteres Dashboard, mit dem ich meinen Cache vollständig überwachen kann. Es zeigt mir einen vollständig verbundenen Cache-Cluster, Zähler für Anforderungsdurchsatz, Latenz und auch Zähler für Hinzufügungen, Abrufe und Aktualisierungen. Ebenso werden mir CPU- und Speicherauslastung sowie Situationen angezeigt, in denen der Cache voll ist.

Ich habe auch Dashboards für Clients sowie eine Berichtsansicht, in der wir serverseitige und clientseitige Dashboards sehen. Im Moment ist keine Anwendung damit verbunden, aber ich kann mit dieser Schaltfläche „Test-Stress“ eine Last simulieren. So kann ich eine Dummy-Last oder eine Aktivität in meinem Cache-Cluster starten, indem ich diesen Test-Stress aufrufe. Sobald ich das tue, sehen Sie, dass ein Client verbunden ist. Diese Topologie erfordert, dass meine Daten verteilt werden. Ein Teil der Daten würde also auf Server 1 und ein Teil auf Server 2 gehen. Dieser Client nutzt also beide Server gleichmäßig. Wie Sie sehen, gehen Anfragen an beide Server, die Cache-Größe wächst auf beiden Servern.

Wir haben aktive und Backup-Partitionen auf beiden Servern. Wenn ich Ihnen kurz die Latenzzähler zeige, liegt die Latenz bei meinen Operationen unter einer Millisekunde, sogar im Mikrosekundenbereich. Das Client-Dashboard zeigt diese clientseitigen Statistiken an, und wir haben einen Bericht mit den serverseitigen Statistiken.

Ron, ich habe eine Frage. Tatsächlich sind mehrere Fragen eingegangen, und eine davon lautet:
Was empfehlen Sie für die Räumung? Und wenn die Räumung zumindest aktiviert ist, dann bleibt nur noch die Frage: Können wir die Cache-Größe erhöhen oder verringern, wenn die Räumung deaktiviert ist?

Sicher. Die Auslagerung muss je nach Anwendungsfall eingerichtet werden. Wenn Sie sich die Auslagerung von Daten leisten können, ist das richtig. Die Auslagerung selbst entfernt Daten, wenn Ihr Cache voll ist. Im Idealfall müssen Sie dies nie tun, und Ihr Cache ist ausreichend groß. Geben Sie Ihrem Cache also genügend Speicherplatz, damit er nie voll wird. Sollte er jedoch irgendwann voll werden, empfehlen wir die Aktivierung der Auslagerung, wenn Ihre Daten jederzeit aus einer Backend-Datenbank wiederhergestellt werden können. Für ASP.NET-Sitzungen empfehlen wir beispielsweise keine Auslagerung, da Sie Benutzer entfernen würden, um Platz für neue Benutzer zu schaffen. Alle Benutzer verfügen über ihre wichtigen Daten. Diese Daten möchten Sie in keinem Fall verlieren. Daher empfehlen wir Ihnen, die Cache-Größe zu erhöhen. Planen Sie die Größe Ihres Cachings so, dass es groß genug ist und in Fällen, in denen es voll wird NCache Ermöglicht die Änderung der Cache-Größe zur Laufzeit. Sie können dies bearbeiten und basierend darauf die Einstellungen erhöhen und anschließend im laufenden Cache speichern. Es ist also direkt anwendbar und erhöht die Cache-Größe zur Laufzeit.

Noch Fragen? Das scheint sie beantwortet zu haben. Ich hebe mir ein paar für den Schluss auf, damit Sie Ihre Demonstration abschließen können. Sicher. Zurück zu meiner Demo-Umgebung: Sie können Clients hinzufügen. Ich kann beispielsweise meine Box als Client hinzufügen. Dies ist ein kurzer Überblick über eine Beispielanwendung, die ich von meiner Box aus ausführen kann. Diese ist beispielsweise auch auf GitHub verfügbar. Suchen Sie also nach NCache Auf GitHub finden Sie einige Beispiele, und ich habe eines davon extrahiert. Was Sie also wirklich in Ihre Anwendung einbinden müssen, ist dieses NuGet-Paket, das Alachisoft.NCache.SDK, und wenn Sie Interesse haben an App-Daten-CachingDies ist das Beispiel, das Sie berücksichtigen sollten. Sobald es hinzugefügt ist, können Sie auf dieser Grundlage einige Ressourcen in die Anwendung einbinden.

Dies umfasst bereits einige Bibliotheken von NCache, als Teil dieses neuen NuGet-Pakets. Und dann fügen Sie diese Referenz mit Alachisoft.NCache.Klient. Fügen Sie außerdem hinzu Laufzeit-Caching, richtig, und darauf basierend können Sie einen Cache-Handle definieren, und darin haben wir eine Reihe von Methoden. Lassen Sie mich Ihnen zum Beispiel zeigen, wie Sie den Cache initialisieren. Sehen wir uns das genauer an. Haben Sie Geduld. Ich tue mich schwer. Jedenfalls kann ich aus irgendeinem Grund nicht wirklich hineingehen, ich glaube, es gibt ein Problem mit der Box selbst. Aber wie dem auch sei, die APIs sind ziemlich intuitiv. Lassen Sie es mich Ihnen anhand unserer PowerPoint-Präsentation zeigen. Dieses Beispiel verwendet es tatsächlich, ich kann es nicht demonstrieren, weil ich nicht in den Code einsteigen kann. Er lässt mich nicht.

Dies ist also ein Cache-Handle und dies ist der Code, den ich zeigen wollte, dass die CacheManager.GetCache ermöglicht Ihnen die Verbindung zum Cache. Anschließend können Sie Cache.Get um tatsächlich Daten aus dem Cache zu erhalten. Ebenso können Sie aufrufen cache.Hinzufügen or cache.AddAsync um Datensätze im Cache hinzuzufügen und ähnlich wie bei Upsert einzufügen, wo Daten im Cache hinzugefügt und aktualisiert werden. Ebenso können Sie aufrufen Cache.Entfernen.

Also das Sample ist verfügbar, Sie können es herunterladen und mit Ihrem Cache ausführen. Sie müssen lediglich von der Anwendungsseite aus auf den Cache verweisen. Es gibt eine Reihe von Konfigurationsmöglichkeiten. Sie können den Namen des Caches und die IP-Adresse direkt angeben oder auf eine client.ncconf zurückgreifen, die dieses NuGet-Paket im Projekt enthält. Wenn ich Ihnen kurz einige Ressourcen zeige, sehen Sie, dass tatsächlich viele Dateien hinzugefügt wurden, und diese Datei hier ermöglicht Ihnen die Verbindung zum Cache. Es kann also bereits eine Verbindung zu meinem „Democache“ herstellen. Wenn ich es ausführe, wird es einige Aktivitäten mit meinem Cache durchführen und die Caching-Operationen starten.

Ebenso habe ich ein weiteres Beispiel, das Ihnen einige weitere Optionen bietet. Zum Beispiel gab es eine Frage zu Suche im Inneren NCache, richtig. Ich empfehle Ihnen daher, dieses Beispiel hier zu verwenden. Es ist für die SQL-Suche gedacht. Es wurde ebenfalls von GitHub heruntergeladen und verwendet ebenfalls die Suche. Es enthält Beispieldaten und ruft dann die Suche per SQL auf. Es bietet zahlreiche Funktionen, die Beispiele sind ebenfalls recht intuitiv. Sie können Elemente einfügen und dann mithilfe von Namensschildern, definierten Indizes oder Projektionen abfragen.

Leider kann ich diese Methoden wegen der Umweltprobleme nicht näher erläutern, aber sie wären wiederum ein guter Bezugspunkt für die Verwendung NCache von jeder Anwendung, die Caching innerhalb der Anwendung verwenden muss oder für die ein Anwendungsfall der Suche innerhalb der Anwendung vorliegt.

Client-Cache

Es gab noch eine Frage zu Client-Cache, daher ist diese Topologie auch eine Option ohne Codeänderung. Alle Daten, die Sie aus einer Datenbank innerhalb NCache, können Sie es zusätzlich mit dem Client-Cache zwischenspeichern. Es handelt sich um einen Cache über einem anderen Cache. Funktioniert ohne Codeänderungen. Es handelt sich um einen synchronisierten Cache mit einem Cluster-Cache, sodass keine Probleme mit der Datenkonsistenz auftreten. Die Synchronisierung erfolgt durch NCacheAlle Aktualisierungen eines Client-Caches werden zwingend an den Cluster-Cache und anschließend an andere Client-Caches weitergegeben. Der Cache verwaltet die gesamte Synchronisierung. Für Referenzdatenszenarien mit wenigen Schreibvorgängen ist diese Option sehr empfehlenswert.

WAN-Replikation

Ebenso NCache hat auch eine WAN-ReplikationWir bieten Aktiv-Passiv- und Aktiv-Aktiv-Topologien. Ihre gesamten Cache-Daten können über unseren Bridge-Cache von einem Rechenzentrum zum anderen repliziert werden. Bridge selbst wird auf einem Aktiv-Passiv-Server gesichert, sodass Sie einen Quell-Cache und einen Ziel-Cache haben. Für DR-Szenarien oder für Ost-West-Migrationen ist eine unidirektionale Replikation oder Ost-West-Migration von Daten von einem Rechenzentrum zum anderen möglich. Auch für Situationen, in denen Sie Daten aus einer Anwendung für die Zielanwendung benötigen, ist eine Übertragung der gesamten Cache-Daten von einem Rechenzentrum zum anderen möglich.

Die andere Option ist Aktiv-Aktiv. Dabei sind beide Standorte aktiv, sodass Standort eins Daten an Standort zwei überträgt und Standort zwei Daten an Standort eins. Auch hier ist keine Codeänderung erforderlich. Es handelt sich lediglich um eine Konfiguration. Sobald Sie Bridge eingerichtet haben, verbinden Sie zwei Caches miteinander und NCache übernimmt und beginnt mit der Replikation der Daten zwischen diesen Caches.

Dies gilt auch für die Multi-Active-Active-Topologie. Es müssen also nicht nur zwei Standorte vorhanden sein, sondern drei, vier oder fünf, wobei alle Standorte Daten untereinander übertragen. NCacheDie Möglichkeit, Daten von allen Standorten gleichzeitig zu synchronisieren. Dies geschieht asynchron, sodass weder auf Anwendungs- noch auf Benutzerseite Kosten für die Replikation anfallen. Die Replikation erfolgt direkt in der Anwendung. Sowohl hier als auch hier sind Client-Anwendungen verbunden. Diese erleben durch die WAN-Replikation keine Leistungseinbußen. Sie erfolgt im Hintergrund durch NCache. Lassen Sie mich wissen, wenn es Fragen gibt. Lassen Sie uns an dieser Stelle die Präsentation und den Funktionsumfang abschließen. Zack, lassen Sie mich wissen, wenn es Fragen gibt.

Ja, wir haben ein paar. Und ich weiß Ihre Geduld zu schätzen. Dies ist auch ein guter Zeitpunkt, um weitere Fragen zu stellen, falls Sie sich während der Präsentation Fragen gestellt haben. Beginnen wir also mit einer.
Wie stellen Sie sicher, dass Ihr Cache einwandfrei läuft? Erhalten wir Benachrichtigungen usw.? Wie erfahren wir beispielsweise, ob ein Problem vorliegt?

Sicher. Wir haben Überwachungs- und Managementtools. Eine Möglichkeit wäre, den Cluster-Zustand visuell zu überprüfen. Sie sehen die CPU-Auslastung und die RAM-Auslastung. Wenn Sie Ihre Basiswerte kennen, wissen Sie, wie viele Anfragen Ihre Anwendungen generieren und wie hoch die typische Auslastung ist. NCache Basierend auf diesen Zählern können Sie mithilfe unserer Überwachungs- und Verwaltungs-Dashboards eine visuelle Überprüfung durchführen. Darüber hinaus bieten wir Warnmeldungen für jede Situation, z. B. wenn Sie einen Cache starten oder stoppen, ein Knoten hinzukommt oder verlässt, der Cache voll ist oder ein Cluster in einen fehlerhaften Zustand gerät, z. B. bei Split Brain. Wir haben Warnmeldungen, die wir in den Windows-Ereignisprotokollen protokollieren. Außerdem können Sie E-Mail-Benachrichtigungen einrichten von NCache, und es kann auch eine E-Mail an Sie generieren. Dies ist also etwas, das eine proaktive Überwachung sein wird, einige Warnungen von NCache, Wobei NCache Sie erhalten eine Warnung und können darauf basierend Maßnahmen ergreifen. Darüber hinaus verfügen wir über historische Daten in Form von Perfmon-Zählerprotokollen sowie Cache-Protokollen. Für Situationen, in denen Sie nicht wussten, was schiefgelaufen ist, und Probleme mit NCache, wir können kommen und uns einbringen, und wir können überprüfen NCache Protokolle und nehmen Sie in diesem Fall eine Bewertung des Cache-Zustands vor. Es gibt in dieser Hinsicht also viele Möglichkeiten, die wir erkunden können.

Klingt gut. Eine weitere Frage ist:
Was ist die neueste .NET-Version, die NCache unterstützt derzeit Kunden?

Okay. Normalerweise verwenden wir die neueste .NET Framework-Version, .NET Core. .NET 6 wird aktuell unterstützt und ist eine Voraussetzung für NCache. Sie müssen .NET 6 als obligatorische Sache haben auf NCache Server. Ihre Anwendungen können jedoch auf jedem .NET Framework laufen, ich glaube ab Version 3.5, 4.0, 4.5 oder sogar 4.7, 4.8. Sie können sowohl auf dem .NET- als auch auf dem .NET Core-Framework laufen. Dies ist lediglich eine Einschränkung auf Serverseite. Sobald die Kompatibilität mit einem neueren Framework getestet ist, beispielsweise mit .NET 7 – wir testen dies bereits in unserem QA-Labor –, werden wir nach erfolgreicher Prüfung auch offizielle Unterstützung dafür bereitstellen.

Wunderbar. Eine weitere Frage ist:
Was halten Sie für die sichere Anzahl an Cluster-Caches zwischen meinen Cache-Servern? Kann ich beispielsweise 15 Cluster-Caches zwischen meinen Cache-Servern erstellen?

Okay. Zunächst einmal, NCache Es gibt keine Begrenzung für die Anzahl der konfigurierbaren Caches. In meiner Demoumgebung habe ich sogar zwei Caches konfiguriert. Sie können also so viele erstellen, wie Sie benötigen. Es gibt jedoch eine technische oder kapazitätsbezogene Empfehlung, die wir in Produktionsumgebungen typischerweise empfehlen: nicht mehr als vier bis fünf Caches zu verwenden. Da jeder Cache ein separater Cache-Cluster ist, verbraucht er alle Ressourcen für Speicher, Clustering und Kommunikation. Außerdem entsteht ein Cluster-Verwaltungsaufwand. Wenn Sie also die Anzahl der Caches erhöhen, entsteht ein Kapazitätsproblem in der Umgebung. Wir empfehlen daher, die Anzahl möglichst auf vier bis fünf zu beschränken. Falls Sie mehrere Caches benötigen, können Sie auf bis zu zehn erweitern. Aber wie gesagt, es handelt sich nur um eine Empfehlung. Es gibt keine zwingende Begrenzung. Es ist eine allgemeine Empfehlung unsererseits.

Okay. Lassen Sie mich noch eine Frage einwerfen, da wir uns am Ende der Sitzung befinden und die Leute noch andere Dinge im Docker haben.
Können NCache DR-Replikation bereitstellen?

Ja, das ist möglich. Die WAN-Replikation, die ich gerade besprochen habe, die letzte Topologie, deckt DR, Disaster Recovery, ab. Standorte können mit den Daten des aktiven Standorts übertragen werden, sodass Sie einen vollständig gesicherten DR-Standort haben. Sie müssen lediglich auf der Anwendungsseite umschalten. Da alle Daten bereits gesichert sind, kommt es zu keinem Datenverlust, wenn ein Rechenzentrum komplett ausfällt oder Sie es für Wartungsarbeiten selbst herunterfahren müssen.

Alles klar. Ich denke, wir haben so ziemlich alles abgedeckt, was wir konnten. Sehr geehrte Damen und Herren, wir stehen Ihnen auch außerhalb dieser Sitzungen zur Verfügung. Wir freuen uns sehr, mit Ihnen Seite an Seite zu arbeiten, wenn es darum geht, Ihre bestehenden Konfigurationen zu prüfen, wenn Sie bereits Nutzer von NCache. Wenn Sie neu sind bei NCache, wir würden uns freuen, Ihnen eine Testversion zur Verfügung zu stellen und Ihnen in Hand-Holding-Sitzungen zu zeigen, wie dies in Ihren integrierten Anwendungen funktionieren würde, aber vor allem wissen Sie bitte, dass Sie sich jederzeit an uns wenden können, wenn es um Fragen zu NCache, oder sogar bei der Verwendung des Produkts und wenn Sie Hilfe benötigen. Wir haben eine Menge neuer Sachen in der Pipeline, auch neue Versionsveröffentlichungen, also bleiben Sie dran, wir werden bald weitere dieser Webinare anbieten.

Applaus für Ron. Ich weiß es wirklich zu schätzen, dass Sie sich heute die Zeit für eine Sitzung genommen haben, und freue mich schon auf die nächste. Vielen Dank an alle. Danke, Zack. Natürlich. Also gut, alle zusammen. Ich wünsche Ihnen allen einen schönen Tag und freue mich darauf, Sie in unserem nächsten Webinar zu sehen. Nur ein kleiner Hinweis: Nach Abschluss dieses Webinars werden wir eine Aufzeichnung auf unsere Website hochladen, sobald alles abgeschlossen ist. Wenn Sie also keine Gelegenheit hatten, Fragen zu stellen oder einen der angesprochenen Punkte noch einmal zu wiederholen, besuchen Sie unsere Website gerne erneut und sehen Sie sich die Aufzeichnung des Webinars an.

Also gut. Grüße an alle. Habt einen schönen Tag. Danke, Jungs. Tschüss.

Was macht man als nächstes?

• NCache Details
• Herunterladen NCache
• Fordern Sie eine personalisierte LIVE-Demo an