Frage Wie wird die Session-Klebrigkeit auf mehreren Webservern erreicht?


Wie viele Webserver hat StackOverflow / ServerFault?

Wenn die Antwort "mehr als eins" ist, dann wird es erreicht Sitzungsklebrigkeit während DNS-Abfragen?


20


Ursprung


Nicht wirklich, aber wenn es anders formuliert wäre, könnte es eine interessante Frage stellen.
Sie sollten die Frage umformulieren. Ändern Sie den Titel in "Wie wird Sitzungs-Klebrigkeit über mehrere Webserver erreicht?" oder sowas ähnliches... - William Brendel
Könntest du mir einen Gefallen tun, um mir den richtigen Ausdruck zu zeigen?
@William Brendel, danke
Die Annahme, dass mehrere Server klebrige Sitzungen beinhalten - was ein Greuel ist - schmerzt mich. - womble♦


Antworten:


Große Websites können über mehrere Computer verteilt werden. Bei vielen Lastausgleichs-Setups kann ein Benutzer während einer Sitzung auf einen der Back-End-Computer zugreifen. Aus diesem Grund gibt es eine Reihe von Methoden, mit denen viele Computer Benutzersitzungen teilen können.

Die gewählte Methode hängt von der Art des verwendeten Lastausgleichs sowie der Verfügbarkeit / Kapazität des Backend-Speichers ab:

Sitzungsinformationen werden nur in Cookies gespeichert: Sitzungsinformationen (nicht nur eine Sitzungskennung) werden im Cookie eines Benutzers gespeichert. Zum Beispiel könnte der Cookie des Benutzers den Inhalt seines Einkaufskorbs enthalten. Um zu verhindern, dass Benutzer die Sitzungsdaten manipulieren, kann ein HMAC zusammen mit dem Cookie bereitgestellt werden. Diese Methode ist wahrscheinlich für die meisten Anwendungen am wenigsten geeignet:

  • Kein Backend-Speicher ist erforderlich
  • Der Benutzer muss nicht jedes Mal auf denselben Computer zugreifen, sodass der DNS-Lastenausgleich verwendet werden kann
  • Mit dem Abrufen der Sitzungsinformationen von einem Datenbankcomputer (wie er mit der HTTP-Anforderung bereitgestellt wird) ist keine Wartezeit verbunden. Nützlich, wenn Ihre Website von Computern auf verschiedenen Kontinenten belastet wird.
  • Die Menge der Daten, die in der Sitzung gespeichert werden können, ist begrenzt (durch das 4K-Cookie-Größenlimit)
  • Die Verschlüsselung muss verwendet werden, wenn ein Benutzer den Inhalt seiner Sitzung nicht sehen kann
  • HMAC (oder Ähnliches) muss verwendet werden, um eine Manipulation der Sitzungsdaten durch den Benutzer zu verhindern
  • Da die Sitzungsdaten nicht serverseitig gespeichert werden, ist es für Entwickler schwieriger zu debuggen

Load Balancer führt den Benutzer immer zum selben Rechner: Viele Load-Balancer können ihren eigenen Sitzungscookie festlegen, der angibt, von welchem ​​Back-End-Computer ein Benutzer Anfragen absetzt, und sie in Zukunft an diesen Computer weiterleiten. Da der Benutzer immer zu demselben Computer geleitet wird, ist die Sitzungsfreigabe zwischen mehreren Computern nicht erforderlich. Dies kann in einigen Situationen gut sein:

  • Die Sitzungsbehandlung einer vorhandenen Anwendung muss möglicherweise nicht geändert werden, um mehrere Maschinen zu erkennen
  • Zum Speichern von Sitzungen ist kein gemeinsames Datenbanksystem (oder ähnliches) erforderlich, was möglicherweise die Zuverlässigkeit erhöht, jedoch auf Kosten der Komplexität
  • Ein heruntergehender Back-End-Rechner wird alle damit begonnenen Benutzersitzungen beenden.
  • Maschinen außer Betrieb zu nehmen ist schwieriger. Benutzer mit Sitzungen auf einer Maschine, die zur Wartung heruntergefahren werden sollen, sollten ihre Aufgaben ausführen können, bevor die Maschine ausgeschaltet wird. Um dies zu unterstützen, können Web Load Balancer eine Funktion haben, um Anfragen an einen bestimmten Back-End-Rechner zu "entleeren".

Gemeinsame Backend-Datenbank oder Schlüssel / Wert-Speicher: Sitzungsinformationen werden in einer Back-End-Datenbank gespeichert, auf die alle Webserver zugreifen und sie aktualisieren können. Der Browser des Benutzers speichert ein Cookie, das eine Kennung enthält (z. B. die Sitzungs-ID) und auf die Sitzungsinformationen verweist. Dies ist wahrscheinlich die sauberste Methode der drei:

  • Der Benutzer muss niemals den gespeicherten Sitzungsinformationen ausgesetzt sein.
  • Der Benutzer muss nicht jedes Mal auf denselben Computer zugreifen, sodass der DNS-Lastenausgleich verwendet werden kann
  • Ein Nachteil ist der Engpass, der auf das Backend-Speichersystem angewendet werden kann.
  • Sitzungsinformationen sind möglicherweise abgelaufen und werden regelmäßig gesichert.

Insgesamt führen die meisten dynamischen Webanwendungen eine Reihe von Datenbankabfragen oder Schlüssel / Wert-Speicheranforderungen aus, so dass die Datenbank oder der Schlüssel / Wertspeicher der logische Speicherort von Sitzungsdaten ist.


42



+1 Ziemlich umfassende Antwort und spart mir das Schreiben. :) Was den DB-Speicher betrifft, ist eine relationale Datenbank wahrscheinlich das Falsche. Etwas wie eine der persistenten Memcached Forks ist besser. memcachedb könnte geeignet sein. Sie haben außerdem Informationen zur Replikationssitzung zwischen Servern verpasst. Es ist nicht die beste Methode, aber Dinge wie Tomcat tun es, also lohnt es sich zu dokumentieren. - David Pashley
Welchen Ansatz nutzt Google, Twitter oder Facebook? - Dannyboy
Ich bin mir nicht sicher über Google, Twitter oder Facebook, aber Redis eignet sich hervorragend für einen Session Store. Es ist im Grunde der "persistent memcached" David Pashley, der 2009 empfohlen wurde, als Redis embryonal war. - Ben R


Wenn Ihre Frage darin besteht, Sitzungen über mehrere Front-End-Webserver hinweg zu verwalten, lautet die Antwort in der Regel die Verwendung einer zentralisierten Datenbank. Statt sich auf die Webserver-Instanzen zu verlassen, um Sitzungsdateien auf den lokalen Dateisystemen zu verfolgen, würden Sie die Sitzungs-IDs und Daten in eine zentrale DB schreiben, und alle Webserver würden stattdessen die Daten von dort abrufen.


4



+1 für die Erwähnung der Centalized-Datenbank. Nur um diese Idee etwas zu erweitern / zu vereinfachen. Wenn Sie einen Cookie auf dem PC eines Benutzers mit einer eindeutigen Kennung wie einer globalen Benutzer-ID festlegen, können Sie diese GUID in einer Datenbank speichern. Es spielt keine Rolle, mit welchem ​​Server ein Client eine Verbindung herstellt, solange sie die GUID / den Cookie haben, können Sie sie mit der Datenbank vergleichen und die Sitzung entsprechend verfolgen. - KPWINC
Das Speichern von Sitzungen in einer relationalen Datenbank ist immer eine schlechte Idee. Sie sollten keine Datenbanken zum Speichern von transienten Daten verwenden. - David Pashley


Die Verwendung von Nemcached scheint eine gute Lösung zu sein, die nicht von @David Pashley erwähnt wird

Dies bedeutet, dass eine remote memcached-Instanz von allen Servern gemeinsam genutzt wird und die Memcache-PECL-Erweiterung verwendet wird, die ihren eigenen Sitzungshandler bereitstellt.

Es müssen nur zwei Parameter in der PHP-Konfiguration geändert werden!

Hier ist ein gutes Tutorial http://www.dotdeb.org/2008/08/25/storing-your-php-sessions-using-memcached/


1



Aber was gibt es mehrere Datencenter? - Dannyboy


IIRC, in DotNetRocks # 440 sagten sie eine Serverperiode. Ich weiß nicht, ob das immer noch so ist.

Edit: Eigentlich war es das Hanselminutes # 134. Es tut uns leid.


0





Sie können einen Cookie setzen.

Sie können einen Hash der Remote-IP berechnen (im einfachsten Fall gehen ungerade Hosts auf Server A, Hosts mit geraden Nummern auf Server B).

Es sieht so aus, als könntest du es auch über einige Werte tun, die beim Quellsystem bleiben, wenn du einen SSL-Tunnel verwendest.

In der Regel erfordert jeder der oben genannten Mechanismen einen "Reverse-Proxy" -Server oder einen Load-Balancer. Dieser Load Balancer akzeptiert den Datenverkehr und leitet ihn dann basierend auf einem der oben genannten Kriterien an den Server weiter, auf dem die Sitzung ursprünglich stattfand.

Ich bin mir nicht sicher, was Sie unter "DNS-Polling" verstehen.


0





a) Sie können Sitzungsinformationen in einem Benutzer-Cookie speichern. Sehen Sie sich zustandslose gehärtete Cookies an, die keine Daten auf der Serverseite speichern, aber den Sitzungsstatus beibehalten http://www.cl.cam.ac.uk/~sjm217/papers/protocols08cookies.pdf . b) Sie können den Backend-Speicher der Sitzung in die Datenbank oder in memcached ändern. Um einen einzelnen Fehlerpunkt zu eliminieren, können Sie die Datenbankreplikation oder mehrere memcached Knoten festlegen. Beachten Sie, dass Memcached in solchen Setups empfohlen wird, in denen der Verlust des Benutzerstatus in der Sitzung kein großer Fehler ist und ihn nicht sehr unglücklich macht. In Fällen, in denen der Erhaltungszustand wichtig ist, verwenden Sie Datenbanken. Sowohl PHP als auch Django und Rails erlauben dem Entwickler, benutzerdefiniertes Session-Backend zu schreiben.


0