Mehrere Arbeiter mit GEVENT-socketio nicht mit XHR-Polling-Transport wegen der Sitzungen

Question

ich derzeit versuche gevent-socketio über mehrere Arbeiter mit dem gunicorn Server skaliert mit dem Arbeiter socketio.sgunicorn.GeventSocketIOWorker. Ich benutze Websockets, wenn es existiert, sonst erzwinge ich XHR-Polling (für IE usw.).

XHR-Polling benötigt eine Sitzung, um die folgenden Umfragen zu verfolgen, aber sobald ich von einem zu zwei oder mehr Arbeitern gehe, beginnen sich die Anfragen zwischen sich auszubreiten, was bedeutet, dass der Zustand verloren geht und alles zusammenbricht.

Ich denke, die folgenden Codezeilen sind relevant: https://github.com/abourget/gevent-socketio/blob/master/socketio/handler.py#L104-106 Ich glaube, ich brauche ein anderes Speicher-Engine, zum Beispiel redis, die ich für die regelmäßigen PubSub-Aktionen verwenden, aber das ist tief im Innern der eigentlichen Bibliothek.

So ist meine Frage, wie kann ich von In-Memory-Sitzungsspeicher zu einer anderen Backend-Engine global in meiner Anwendung gehen (funktioniert es graziös den Sitzungscode in dem obigen Link außer Kraft setzen?) ohne die Bibliothek zu modifizieren selbst? Something like PHP's session directives in php.ini. Ich nehme an, es könnte argumentiert werden, dass dies eine sehr generische Python-Frage ist, aber ich habe Probleme, relevante Informationen zu finden, und ich bin mir auch nicht sicher, ob es für diese Bibliothek funktioniert.

Oder wie kann ich den xhr-polling-Transport von gevent-socketio über verschiedene Workers und Server hinweg (ohne Stickies) nutzen?

Danke!

Answer 1

Dies ist offensichtlich eine Einschränkung der socketio. Von dem, was ich im Web sehen kann, erfolgt die Sitzungsbehandlung typischerweise auf der Web-Framework-Ebene statt auf dem Webserver. socketio versucht, es auf eigene, untere Ebene zu tun, und tut es in einer begrenzten Art und Weise. Ich schätze, die Autoren hielten eine vollwertige Lösung für einen Overkill. In Ihrem Fall haben sie sich als falsch erwiesen.

Es gibt nur zwei Möglichkeiten, um Einschränkungen zu überwinden, die eine logische Änderung erfordern: Patchen der Quelle und Patchen in der Laufzeit. Wählen Sie, was Ihnen am meisten gefällt (oder, naja, ekelt am wenigsten: ^)). Für die zweite Option, ich schlage vor, request_tokens und/oder den Code zu ersetzen, der es mit einer anderen Entität mit der gleichen Schnittstelle erstellt. Aus den Gründen, die im ersten Absatz erwähnt werden, glaube ich wirklich, dass socketio-Autoren wahrscheinlich einen Quell-Patch akzeptieren, der es erlauben würde, externe Session-Handling-Mechanismen zu verwenden, wenn Sie einen vorschlagen.

Standardspeicherorte für Sitzungsinformationen sind: gemeinsamer Speicher, Dateien, Datenbank. Ich schlage vor, dass Sie die Logik so ändern, dass socketio denselben Mechanismus verwendet wie Ihr Webframework (oder was auch immer Ihre Seiten zusammensetzt).

Answer 2

Schauen Sie sich die Beispiele hier:

https://github.com/abourget/gevent-socketio/tree/master/examples/pyramid_backbone_redis_chat_persistence

Es zeigt, wie redis als verteiltes Nachrichtenwarteschlange

Answer 3

Nur ein Gedanke verwenden, da ich das gleiche Problem habe; Anstatt Gunicorn fork (mit der -w-Flagge) zu lassen, könntest du vielleicht mehrere Gunicorn-Prozesse auf verschiedenen Ports spawnen und dann nginx verwenden, um sie mit einem "upstream" block with "sticky" session auszubalancieren. Ich glaube, das ist die Art und Weise, wie die Nodejs-Implementierung die Mehrfachverarbeitung von Arbeitern behandelt, wenn sie keine Zustände mit Redis teilen.