Wie Sie wissen, verfügen JSP-Anwendungen über das Konzept eines Sitzungsobjekts, um mehrere HTTP-Anfragen zu verarbeiten. Dies liegt daran, dass das HTTP-Protokoll zustandslos ist und die Sitzung zur Aufrechterhaltung des Benutzerstatus über mehrere HTTP-Anfragen hinweg verwendet wird.
Bei einer Einzel-Webserver-Konfiguration gibt es kein Problem, aber sobald Sie über eine Webfarm mit mehreren Servern und Lastausgleich verfügen, auf der eine JSP-Anwendung ausgeführt wird, stehen Sie sofort vor der Frage, wo die Sitzung gespeichert werden soll. Dies liegt daran, dass ein Load Balancer idealerweise jede HTTP-Anfrage an den am besten geeigneten Webserver weiterleiten möchte. Wenn die Sitzung jedoch nur auf einem Webserver gehalten wird, müssen Sie die Sticky-Session-Funktion des Load Balancers verwenden, bei der Anfragen im Zusammenhang mit einer bestimmten Sitzung nur an den Webserver gesendet werden, auf dem sich die Sitzung befindet.
Dies bedeutet, dass ein Webserver möglicherweise überlastet ist, selbst wenn ein anderer Webserver im Leerlauf ist, da sich die Sitzung für diesen Benutzer auf diesem Webserver befindet. Dies beeinträchtigt natürlich die Skalierbarkeit. Wenn das Session-Objekt nur auf einem Webserver verbleibt, gehen darüber hinaus auch Sitzungsdaten verloren, wenn dieser Webserver aus irgendeinem Grund ausfällt.
Um dieses Datenverlustproblem zu vermeiden, müssen Sie über einen Mechanismus verfügen, mit dem die Sitzung auf mehr als einen Webserver repliziert wird. Hier bieten die führenden Servlet-Engines (Tomcat, WebLogic, WebSphere und JBoss) alle eine Form der Sitzungspersistenz. Sie beinhalten sogar eine Form der Sitzungsreplikation, aber alle weisen Probleme auf. Beispielsweise sind dateibasierte und JDBC-Persistenz langsam und verursachen Leistungs- und Skalierbarkeitsprobleme. Die Sitzungsreplikation ist ebenfalls sehr schwach, da sie alle Sitzungen auf allen Webservern repliziert und dadurch unnötige Kopien der Sitzung erstellt, wenn Sie mehr als zwei Webserver haben, obwohl Fehlertoleranz mit nur zwei Kopien erreicht werden kann.
In solchen Situationen kann ein verteilter Java-Cache verwendet werden NCache ist die beste Wahl, um sicherzustellen, dass die Sitzungspersistenz auf mehreren Servern im Webcluster sehr intelligent und ohne Beeinträchtigung Ihrer Skalierbarkeit erfolgt. NCache verfügt über eine Caching-Topologie namens „Partition-Replica“, die Ihnen nicht nur Hochverfügbarkeit und Failover durch Replikation, sondern auch großen In-Memory-Sitzungsspeicher durch Datenpartitionierung bietet. Durch die Datenpartitionierung können Sie große Datenmengen zwischenspeichern, indem Sie den Cache in Partitionen aufteilen und jede Partition auf verschiedenen Cache-Servern im Cache-Cluster speichern.
NCache Die Partition-Replica-Topologie repliziert die Sitzungsdaten jedes Knotens nur auf einen anderen Knoten im Cluster. Dieser Ansatz eliminiert die Leistungseinbußen der Replikation von Sitzungsdaten auf allen Serverknoten, ohne die Zuverlässigkeit zu beeinträchtigen.
Darüber hinaus nutzt die von den Webservern (Apache, Tomcat, Weblogic und WebSphere) bereitgestellte Sitzungspersistenz die Ressourcen und den Speicher des Webclusters. Dieser Ansatz beeinträchtigt die Leistung Ihrer Anwendung, da die Web-Cluster-Knoten, die für die Verarbeitung der Client-Anfrage verantwortlich sind, auch die zusätzliche Arbeit der Sitzungsreplikation und der In-Memory-Speicherung übernehmen. Dagegen können Sie laufen NCache auf separaten Boxen außer dem einen Teil Ihres Webclusters. Auf diese Weise können Sie Web-Cluster-Ressourcen freigeben und der Web-Cluster kann diese Ressourcen nutzen, um immer mehr Client-Anfragen zu bearbeiten.
Für JSP-Sitzungspersistenz: NCache hat ein Sitzungsmodul implementiert NCacheSessionProvider als Java-Filter. NCache Der JSP-Servlet-Filter fängt Anfragen und Antworten dynamisch ab und kümmert sich hinter den Kulissen um die Sitzungspersistenz. Und Sie müssen keinen Ihrer JSP-Anwendungscodes ändern.
Hier ist ein Beispiel NCache JSP-Servlet-Filterkonfiguration, die Sie zur Verwendung in Ihrem Anwendungsbereitstellungsdeskriptor definieren müssen NCache für JSP-Sitzungspersistenz:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
<filter> <filter-name>NCacheSessionProvider</filter-name> <filter-class> com.alachisoft.ncache.web.sessionstate.NSessionStoreProvider </filter-class> </filter> <filter-mapping> <filter-name>NCacheSessionProvider</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> <init-param> <param-name>cacheName</param-name> <param-value>PORCache</param-value> </init-param> <init-param> <param-name>configPath</param-name> <param-value>/usr/local/ncache/config/</param-value> </init-param> |
Daher NCache Bietet Ihnen einen viel besseren Mechanismus, um Sitzungspersistenz im Webcluster zusammen mit Leistungssteigerung und Skalierbarkeit zu erreichen.
Laden Sie also eine voll funktionsfähige 60-Tage-Testversion von herunter NCache Enterprise und probiere es selbst aus.