Mehrere Möglichkeiten für den Nginx-Load-Balancer, die Sitzungsfreigabe zu handhaben

1) Anstatt eine Sitzung zu verwenden, verwenden Sie ein Cookie.

Wenn Sie die Sitzung in ein Cookie ändern können, können Sie einige der Nachteile der Sitzung vermeiden. In einem J2EE-Buch, das ich zuvor gelesen habe, wurde auch darauf hingewiesen Die Sitzung des Clustersystems kann nicht verwendet werden, da es sonst zu Problemen kommt und die Handhabung schwierig wird. Wenn das System nicht kompliziert ist, legen Sie Wert darauf, ob die Sitzung entfernt werden kann. Wenn das Ändern sehr schwierig ist, verwenden Sie die folgende Methode.

2) Der Anwendungsserver implementiert die gemeinsame Nutzung selbst

Wie bekannt, kann PHP eine Datenbank oder einen Memcached verwenden, um die Sitzung zu speichern und so einen Sitzungscluster in PHP selbst einzurichten. Die Sitzung kann stabil sein. Selbst wenn ein Knoten ausfällt, geht die Sitzung nicht verloren. Sie eignet sich für strengere Situationen, aber für ein geringes Anforderungsvolumen. Allerdings ist seine Effizienz nicht sehr hoch und es eignet sich nicht für Anlässe, die eine hohe Effizienz erfordern.

Die beiden oben genannten Methoden haben nichts mit Nginx zu tun. Lassen Sie uns über die Verwendung von Nginx sprechen:

3) ip_hash

Die ip_hash-Technologie in Nginx kann eine bestimmte IP konvertieren Anfragen werden an dasselbe Backend weitergeleitet, sodass ein Client und ein Backend unter dieser IP eine stabile Sitzung aufbauen können. ip_hash ist in der Upstream-Konfiguration definiert:

Upstream-Backend {
Server 127.0.0.1:8001 ;
server 127.0.0.1:8002;
ip_hash;
}

ip_hash ist leicht zu verstehen, aber da nur der IP-Faktor zum Zuweisen von Backends verwendet werden kann, ist ip_hash defekt und kann nicht in einigen Fällen verwendet werden:

1/ Nginx ist nicht der Front-End-Server. ip_hash erfordert, dass nginx der Front-End-Server sein muss. Andernfalls kann nginx nicht die richtige IP erhalten und kann keinen Hash basierend auf der IP durchführen. Wenn beispielsweise Squid als Frontend verwendet wird, kann Nginx beim Abrufen der IP nur die Server-IP-Adresse von Squid abrufen. Es ist definitiv verwirrend, diese Adresse für die Verteilung zu verwenden.

2/ Das Backend von Nginx verfügt auch über andere Methoden zum Lastausgleich. Wenn auf dem Nginx-Backend ein anderer Lastausgleich stattfindet und die Anfragen auf andere Weise umgeleitet werden, dann wird eine Anfrage eines bestimmten Clients mit Sicherheit nicht auf demselben Sitzungsanwendungsserver liegen. Bei dieser Berechnung kann das Nginx-Backend nur direkt auf den Anwendungsserver verweisen oder einen Squid erstellen und dann auf den Anwendungsserver verweisen. Am besten verwenden Sie den Standort als Umleitung, leiten einige Anfragen, die eine Sitzung erfordern, über ip_hash um und gehen für den Rest zu anderen Backends.

4) upstream_hash

Um einige Probleme von ip_hash zu lösen, können Sie das Drittanbietermodul upstream_hash verwenden. Dieses Modul wird in den meisten Fällen für url_hash verwendet, verhindert dies jedoch nicht von der Verwendung für die Sitzungsfreigabe:

Wenn das Frontend Squid ist, wird die IP zum x_forwarded_for http_header hinzugefügt. Verwenden Sie upstream_hash, um diesen Header als Faktor zu verwenden, um die Anfrage an das angegebene Backend weiterzuleiten:

Sie können dieses Dokument sehen:

http://www.oschina.net/discuss/thread/622

Im Dokument wird $request_uri geringfügig als Faktor verwendet geändert:

hash $http_x_forwarded_for;

Auf diese Weise wird der Header x_forwarded_for als Faktor verwendet. In der neuen Version von Nginx kann er das Lesen von Cookie-Werten unterstützen geändert in:

hash $cookie_jsessionid;

Wenn die in PHP konfigurierte Sitzung ohne Cookies ist, können Sie mit dem Nginx-eigenen Modul userid_module ein Cookie mit Nginx generieren