Multisite-Java-Session-Unterstützung
NCache Bietet Multi-Site-Sitzungspersistenz, die zum Verwalten von Servlet-Java-Sitzungen über mehrere Webfarmen (die geografisch getrennt sind) verwendet werden kann, wenn Sie aufgrund der Bandbreitenverbrauchskosten keine Sitzungen über das WAN replizieren möchten.
Um die Persistenz von Sitzungen an mehreren Standorten zu verstehen, betrachten Sie Java-Servlet-Anwendungen, die in Webserverfarmen mit Lastausgleich ausgeführt werden, die sich über mehrere Regionen erstrecken. Ein Load Balancer kann Clients je nach Benutzerverkehr in verschiedene Regionen umleiten. Zum Zwischenspeichern von Java-Sitzungen ist ein Cluster-Cache erforderlich, damit Sitzungen über Regionen hinweg repliziert werden. Dieser Ansatz ist aufgrund der Sitzungsreplikation über das WAN möglicherweise nicht geeignet. Außerdem kann es zu Leistungsproblemen kommen, da die Caching-Knoten geografisch getrennt sind.
NCache Multi-Site-Java-Sitzungen
Um diese Probleme zu lösen, NCache stellt das Konzept der Multi-Site-Sitzungen vor. Das Zwischenspeichern der Sitzungen in einer geografisch getrennten Webfarmanwendung erfordert die Konfiguration separater Caches in jeder Region. Nehmen wir an, Sie haben vier Regionen, die jeweils mit separaten Caches als CR-1, CR-2, CR-3 und CR-4 konfiguriert sind. Jeder geclusterte Cache verfügt über einen eigenen Satz von Clients (Java-Servlet) als Webfarm. Jeder Client konfiguriert das NCache Sitzungsservletfilter. Sie müssen den primären Cache (Cache der aktuellen Region) und eine Reihe sekundärer Caches (Liste anderer Region-Caches) zusammen mit den benutzerdefinierten Präfixen für jeden Cache-Namen angeben.
Diese Konfiguration wird bei der Initialisierung des geladen NCache Sitzungsanbieterfilter. Auf diese Weise wird jeder Client über Caches in anderen Regionen informiert. Die von der erstellte Sitzungs-ID NCache Der Sitzungsanbieter richtet sich nach dem primären Cache-Präfix jeder Region, d. h. das Präfix des primären Caches wird an die Sitzungs-IDs dieser Region angehängt. Diese Clients fügen Sitzungen hinzu, aktualisieren sie und beziehen sie hauptsächlich aus ihrem eigenen Cluster-Cache, also dem primären Cache. Allerdings kann es vorkommen, dass eine Client-Anfrage zum Lastausgleich an die Webfarm eines anderen geografischen Standorts gesendet wird. Jetzt, NCache identifiziert die Anfrage anhand ihres primären Cache-Präfixes und ermöglicht den Benutzeranfragen den Zugriff auf dieselbe Sitzung aus dem vorherigen Cache.
Um dies zu verstehen, betrachten Sie eine Anforderungsroute zu einer Webfarm des CR-2-Regioncaches. In dieser Situation, NCache extrahiert das Sitzungs-ID-Präfix, das CR-1 sein wird, und durchsucht seine Cache-ID in seiner eigenen sekundären Cache-Liste. Da alle Regions-Clients über einen Satz aller anderen Regions-Caches als sekundäre Caches verfügen, NCache ruft diese Sitzung aus dem CR-1-Cache ab. NCache aktualisiert die ID dieser Sitzung, indem es ihr aktuelles primäres Cache-Präfix, dh CR-2, anhängt und es im aktuellen primären Cache (CR-2) aktualisiert, um zukünftige Anfragen zu bedienen.
Nehmen wir an, ein Client stellt eine Anfrage, die den Load Balancer durchläuft. Angenommen, die Sitzungsanforderung wird basierend auf der Systemlast an den Webserver1 innerhalb einer Webfarm weitergeleitet. Sobald die Anforderung eintrifft, wird eine Sitzung mit dem Präfix „Web Server1“ und der angehängten Sitzungs-ID erstellt und im primären Cache für diese Webfarm, in diesem Fall „Replizierter Cache1“, gespeichert.
Wenn der Load Balancer denselben Client an Web Farm2 weiterleitet, NCache analysiert das Sitzungspräfix. Mithilfe dieses Präfixes wird die Sitzung aus dem replizierten Cache1 abgerufen, obwohl sie zu Web Farm1 gehört. Dies ermöglicht Ihnen, über zwei oder mehr aktive Rechenzentren zu verfügen und den Großteil des Datenverkehrs im eigenen Rechenzentrum zu belassen, aber bei Bedarf gelegentlich auch auf andere Rechenzentren überzulaufen. Sie können auch eines der Rechenzentren herunterfahren, ohne dass es zu Unterbrechungen für die Benutzer kommt, da ihre Sitzungen dann für andere Rechenzentren zugänglich sind. Oder wir können sagen: Wenn eine der Webfarmen aus irgendeinem Grund ausfällt, greifen andere Webfarmen auf Benutzersitzungen aus dem Cache dieser Region zu und schließlich werden die gesamten Sitzungsdaten in den Cache der nächsten Region verschoben, um einen Sitzungsverlust zu verhindern Daten.
NCache Bietet eine Option ohne Codeänderung für Java-basierte Webanwendungen zum Speichern von Sitzungen NCache durch Implementierung des Sitzungsmoduls nc-sessionprovider.jar als JSP-Servlet-Filter. Um das zu nutzen NCache Für das Java-Sitzungsmodul müssen Sie einen mit Servlet 2.3+ kompatiblen Container (Webserver) ausführen. Der Benutzer muss nur auf einige Bibliotheken verweisen und einen Filter hinzufügen web.xml der Anwendung, so dass alle Anfragen durch an die Anwendung gelangen NCache. Die folgenden J2EE/Jakarta-Plattformen werden unterstützt:
- Kater
- JBoss/WildFly
- Weblogik
- WebSphere
Weitere Informationen zur Konfiguration des Multi-Site-Sitzungsmoduls finden Sie unter Multi-Site-Sitzungsstatusanbieter.
Siehe auch
Konzeptionelle Übersicht
Konfigurieren von Anwendungen zur Verwendung des Java-Sitzungsmoduls
Fehlerprotokollierung