Benötigt die WS-Websocket-Serverbibliothek eine sticky-Sitzung, wenn sie hinter einem Load Balancer verwendet wird?

Ich versuche, Websocket-Server hinter einem Load Balancer einzurichten. Zuerst benutzte ich die socket.io Bibliothek. Aber ich fand, dass es erforderlich ist sticky session, wenn hinter einem Load Balancer verwendet.Benötigt die WS-Websocket-Serverbibliothek eine sticky-Sitzung, wenn sie hinter einem Load Balancer verwendet wird?

Nach this website sendet es mehrere Anforderungen zum Ausführen von Handshake und Herstellen einer Verbindung. Wenn die Anforderungen an verschiedene Server gesendet werden, schlägt die Verbindung fehl.

Nach weiteren Studien fand ich, dass andere Websocket Server-Bibliothek wie SockJS auch das gleiche Problem haben. Sie alle erfordern eine Sitzung, um hinter einem Load Balancer zu arbeiten.

Jetzt überprüfe ich die Websocket-Bibliothek ws. Aber ich konnte kein Beispiel finden, das es hinter Load Balancer verwendet.

Erfordert die Bibliothek ws die Verwendung der Sticky-Sitzung?

Gibt es eine andere Websocket-Bibliothek, die ohne Sticky-Sitzung hinter einem Load Balancer funktionieren kann?

Quelle

2016-12-13 userpal

Ich glaube nicht. Sie müssten die Socket-Sitzungen auf allen Ihren Servern replizieren, um die Sticky-Sitzung zu vermeiden. – Hosar

Gibt es einen bestimmten Grund, warum Sie sich nicht auf Sticky-Sitzungen verlassen können/wollen?

Wenn Sie Socket-Verbindungen über mehrere Hosts verteilen möchten, benötigen Sie einige Lösung, und sticky Sitzungen ist eine vollkommen gute.

Die socket.io page on using multiple nodes Sie verknüpfen, beschreibt sogar eine Möglichkeit zur Implementierung der Lösung, "durch Routing-Clients basierend auf ihrer ursprünglichen Adresse" über NginX. Hast du das versucht und festgestellt, dass es nicht funktioniert?

Es gibt auch einen sehr guten Artikel auf Horizontally Scaling Node.js and WebSockets with Redis, der das Lösen des genauen Problems beschreibt, das Sie mit sticky-Sitzungen und automatischem Failover haben.

Quelle

2016-12-22 12:07:47 duncanhall

Ich weiß, dass wir klebrige Sitzungen erstellen können, indem wir die Clients basierend auf ihrer Quell-IP-Adresse routen. Wir können auch eine noch bessere Methode verwenden, nämlich Cookie zu injizieren und dann die Clients basierend auf dem Cookie weiterzuleiten, wie in dem Link in Ihrem letzten Absatz gezeigt. Ich möchte jedoch auf jeden Fall vermeiden, klebrige Sitzung zu verwenden, wenn möglich. Wenn wir im Load Balancer eine sticky-Sitzung verwenden, ist es unmöglich, die Last gleichmäßig auf die Server hinter dem Load Balancer zu verteilen. – userpal

Nehmen wir an, wir erstellen eine sticky-Sitzung basierend auf der Quell-IP. Wenn 500 Clients aus dem Netzwerk eines Unternehmens NAT (mit einer öffentlichen IP-Adresse) verwenden, werden alle an denselben Server weitergeleitet. In diesem Fall wird 1 Server überlastet, während die anderen Server inaktiv sind. Das Erstellen von Sticky Sessions mit Cookies ist etwas besser, aber auch hier ist es nicht möglich, die Last gleichmäßig auf die Server zu verteilen. – userpal

Ich hoffe, dass wir die Websocket-Server wie die HTTP-Webserver horizontal skalieren können und der Load Balancer die Last gleichmäßig auf alle Server verteilen kann. In dem Link in Ihrem letzten Absatz erwähnte es, dass "" ... Dies ist nicht immer notwendig, aber wenn Sie etwas wie SockJS verwenden, verhindert dies, dass Ihre Benutzer zwischen den Servern springen, wenn sie auf Abfragen zurückkommen ". Es scheint, dass die sticky-Sitzung nur benötigt wird, wenn sie auf Abfragen zurückfällt. – userpal

Benötigt die WS-Websocket-Serverbibliothek eine sticky-Sitzung, wenn sie hinter einem Load Balancer verwendet wird?

Antwort

Verwandte Themen