Sticky- und NON-Sticky-Sitzungen

255

Ich möchte den Unterschied zwischen klebrigen und nicht klebrigen Sitzungen kennen. Was ich nach dem Lesen aus dem Internet verstanden habe:

Sticky : Es wird nur ein einziges Sitzungsobjekt vorhanden sein.

Nicht klebrige Sitzung : Sitzungsobjekt für jeden Serverknoten

session

— Sunny Gupta
quelle

Antworten:

612

Wenn Ihre Website nur von einem Webserver bereitgestellt wird, wird für jedes Client-Server-Paar ein Sitzungsobjekt erstellt, das im Speicher des Webservers verbleibt. Alle Anforderungen vom Client gehen an diesen Webserver und aktualisieren dieses Sitzungsobjekt. Wenn einige Daten während des Interaktionszeitraums im Sitzungsobjekt gespeichert werden müssen, werden sie in diesem Sitzungsobjekt gespeichert und bleiben dort, solange die Sitzung vorhanden ist.

Wenn Ihre Website jedoch von mehreren Webservern bereitgestellt wird, die sich hinter einem Load Balancer befinden, entscheidet der Load Balancer, an welchen tatsächlichen (physischen) Webserver jede Anforderung gesendet werden soll. Wenn sich beispielsweise 3 Webserver A, B und C hinter dem Load Balancer befinden, wird möglicherweise www.mywebsite.com/index.jsp von Server A und www.mywebsite.com/login.jsp von Server A aus bedient Server B und www.mywebsite.com/accoutdetails.php werden von Server C aus bedient.

Wenn die Anforderungen von (physisch) 3 verschiedenen Servern bedient werden, hat jeder Server ein Sitzungsobjekt für Sie erstellt. Da sich diese Sitzungsobjekte auf drei unabhängigen Feldern befinden, kann niemand direkt wissen, was sich im Sitzungsobjekt befindet des anderen. Um zwischen diesen Serversitzungen zu synchronisieren, müssen Sie möglicherweise die Sitzungsdaten in eine Schicht schreiben / lesen, die allen gemeinsam ist - wie eine Datenbank. Das Schreiben und Lesen von Daten in / aus einer Datenbank für diesen Anwendungsfall ist möglicherweise keine gute Idee. Hier kommt nun die Rolle der Sticky-Session .

Wenn der Load Balancer angewiesen wird, Sticky-Sitzungen zu verwenden, werden alle Ihre Interaktionen mit demselben physischen Server ausgeführt, obwohl andere Server vorhanden sind. Somit ist Ihr Sitzungsobjekt während Ihrer gesamten Interaktion mit dieser Website identisch.

Zusammenfassend lässt sich sagen, dass bei Sticky Sessions alle Ihre Anforderungen an denselben physischen Webserver weitergeleitet werden, während bei einem nicht Sticky Loadbalancer ein beliebiger Webserver ausgewählt werden kann, der Ihre Anforderungen bearbeitet.

Als Beispiel können Sie hier über Amazon Elastic Load Balancer und Sticky Sessions lesen: http://aws.typepad.com/aws/2010/04/new-elastic-load-balancing-feature-sticky-sessions.html

— TJ-
quelle

@ TJ- Was passiert, wenn ein Knoten nicht verfügbar ist?

— gstackoverflow

In den meisten Fällen geht die Sitzung verloren. Im Fall von AWS ESB Wenn eine Instanz ausfällt oder fehlerhaft wird, beendet der Load Balancer das Weiterleiten der Anforderung an diese Instanz und wählt stattdessen eine neue fehlerfreie Instanz basierend auf dem vorhandenen Load Balancing-Algorithmus. Der Load Balancer behandelt die Sitzung als "festgefahren" für die neue fehlerfreie Instanz und leitet die Weiterleitung von Anforderungen an diese Instanz weiter, selbst wenn die fehlgeschlagene Instanz zurückkommt.

— TJ

Nach welchen Informationen macht der LoadBalancer eine HTTP-Sitzung klebrig? Insbesondere bei HTTPS-Verbindungen wird dieses Problem interessant. Versorgen Sie die LB mit dem privaten Schlüssel des Webservers, damit die SSL-Verbindung unterbrochen und die HTTP-Sitzung abgerufen werden kann? Oder nutzt die LB einfach die Client-IP-Adresse? Was ist in diesem Fall mit dem Proxyserver, auf dem mehrere Clients dieselbe IP-Adresse verwenden? Oder noch schlimmer, mobile Clients, bei denen sich die IP-Adresse häufig ändert? Oder gibt es dafür noch eine bessere Technik? Danke

— g000ze

Ja, du bist absolut richtig. Um in diesem Zusammenhang den Header "x-forwarded-for" oder ein Sticky-Cookie zu verwenden , muss die SSL-Beendigung verwendet werden, und daher muss die Anforderung in der LB entschlüsselt werden.

— TJ

@ g000ze Wenn es um Anwendungen geht, die nicht direkt im Internet bereitgestellt werden, ist es meines Erachtens üblich, TLS nur auf dem äußersten Proxyserver zu aktivieren. (Ein Load Balancer kann möglicherweise vereinfacht als ein spezieller Typ eines Proxyservers angesehen werden, der die Anforderung an einen von mehreren Servern weiterleiten kann.) Der Datenverkehr zwischen dem Load Balancer und den anderen Servern erfolgt in einem lokalen, gesicherten Netzwerk und es ist daher oft nicht notwendig, es zu verschlüsseln, oder wenn es verschlüsselt werden muss, kann ein selbstsigniertes Zertifikat ausreichend sein (da der Proxy so konfiguriert werden kann, dass er ihm vertraut).

— jpmc26

106

Ich habe hier eine Antwort mit einigen weiteren Details gegeben: https://stackoverflow.com/a/11045462/592477

Oder Sie können es dort lesen ==>

Wenn Sie den Lastausgleich verwenden, bedeutet dies, dass Sie mehrere Instanzen von Tomcat haben und die Lasten teilen müssen.

Wenn Sie die Sitzungsreplikation ohne Sticky-Sitzung verwenden: Stellen Sie sich vor, Sie haben nur einen Benutzer, der Ihre Web-App verwendet, und Sie haben 3 Tomcat-Instanzen. Dieser Benutzer sendet mehrere Anforderungen an Ihre App. Der Loadbalancer sendet dann einige dieser Anforderungen an die erste Tomcat-Instanz und einige andere dieser Anforderungen an die zweite Instanz und andere an die dritte.
Wenn Sie eine Sticky-Sitzung ohne Replikation verwenden:Stellen Sie sich vor, Sie haben nur einen Benutzer, der Ihre Web-App verwendet, und Sie haben 3 Tomcat-Instanzen. Dieser Benutzer sendet mehrere Anforderungen an Ihre App. Anschließend sendet der Loadbalancer die erste Benutzeranforderung an eine der drei Tomcat-Instanzen. Alle anderen Anforderungen, die dieser Benutzer während seiner Sitzung sendet, werden an dieselbe Tomcat-Instanz gesendet. Wenn Sie während dieser Anforderungen diese Tomcat-Instanz (verwendete Tomcat-Instanz) herunterfahren oder neu starten, sendet der Loadbalancer die verbleibenden Anforderungen an eine andere Tomcat-Instanz, die noch ausgeführt wird, ABER da Sie keine Sitzungsreplikation verwenden, die empfangene Instanz Tomcat Die verbleibenden Anforderungen enthalten keine Kopie der Benutzersitzung. Für diesen Tomcat beginnt der Benutzer eine Sitzung: Der Benutzer verliert seine Sitzung und wird von der Web-App getrennt, obwohl die Web-App noch ausgeführt wird.
Wenn Sie eine Sticky-Sitzung mit Sitzungsreplikation verwenden:Stellen Sie sich vor, Sie haben nur einen Benutzer, der Ihre Web-App verwendet, und Sie haben 3 Tomcat-Instanzen. Dieser Benutzer sendet mehrere Anforderungen an Ihre App. Anschließend sendet der Loadbalancer die erste Benutzeranforderung an eine der drei Tomcat-Instanzen. Alle anderen Anforderungen, die dieser Benutzer während seiner Sitzung sendet, werden an dieselbe Tomcat-Instanz gesendet. Wenn Sie während dieser Anforderungen diese Tomcat-Instanz (die verwendete Tomcat-Instanz) herunterfahren oder neu starten, sendet der Loadbalancer die verbleibenden Anforderungen an eine andere Tomcat-Instanz, die noch ausgeführt wird, da Sie die Sitzungsreplikation verwenden, die Instanz Tomcat, die die verbleibenden Anforderungen empfängt Eine Kopie der Benutzersitzung, dann setzt der Benutzer seine Sitzung fort: Der Benutzer durchsucht weiterhin Ihre Webanwendung, ohne die Verbindung zu trennen. Das Herunterfahren der Tomcat-Instanz hat keinen Einfluss auf die Benutzernavigation.

— Nico
quelle

Hmm .. beim Lesen frage ich mich: Wäre es nicht sinnvoll, eine vierte Option zu haben: Non-Sticky WITH Session Replication? Oder anders ausgedrückt: Was ist der Vorteil einer Sticky-Sitzung, wenn man die Sitzung trotzdem auf die verschiedenen Instanzen repliziert? Ich meine, wenn Sie die Sitzungen über die Instanzen hinweg replizieren, können Sie die Anfrage auch einfach an einen beliebigen Server weiterleiten, oder? Was vermisse ich?

— Dingalapadum

@dingalapadum Sie haben Recht, theoretisch können Sie Sitzungsreplikation ohne Sticky-Sitzung haben. Bei einem großen Cluster ist die Netzwerkleistung jedoch schlecht. Dann gibt es einige Strategien bei der Verwendung der Sitzungsreplikation mit einer Sticky-Sitzung wie dieser in Tomcat ( tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html ), eine Sticky-Sitzung und nur eine Replik (hier ein Knoten) zu erstellen genannt Backup Manager, der die gesamte Knotensitzungsreplikation beibehält).

— Nico

Bei einer Sticky-Sitzung können Sie nur eine Sitzungsreplik haben, was in großen Clustern am besten ist.

— Nico

Ah, ich verstehe - Wenn ich das richtig verstehe, meinen Sie, dass das Replizieren aller Sitzungen im gesamten Cluster den Cluster intern überfluten würde - ich sehe das Problem. Oh, und jetzt, als ich mir Ihre Antwort genauer

— ansah

@dingalapadum Ihre Frage ist willkommen, es erlaubt, die Antwort zu verbessern

— Nico