Wiele pracownicy gevent-socketio nie z transportem XHR-wyborczym z powodu sesji

Question

Obecnie próbuję skalować gevent-socketio w wielu robotników z serwerem gunicorn pomocą pracownika socketio.sgunicorn.GeventSocketIOWorker. Używam websockets gdy istnieje inaczej wymuszam XHR-polling (dla IE itp.).

Ankieta XHR wymaga sesji, w której można śledzić następujące ankiety, ale gdy tylko przejdę od jednego do dwóch lub więcej pracowników, prośby zaczynają się rozprzestrzeniać między sobą, co oznacza, że ​​państwo zostaje utracone, a wszystko zepsuje się.

myślę następujące linie kodu jest istotne: https://github.com/abourget/gevent-socketio/blob/master/socketio/handler.py#L104-106 Chyba potrzebuję trochę inny silnik składowania, na przykład REDiS którego używam do regularnych PubSub-działań, ale jest to głęboko wewnątrz rzeczywistej biblioteki.

Więc moje pytanie brzmi: w jaki sposób przejść od w pamięci przechowywania sesji na innym silniku backend globalnie w mojej aplikacji (czy to z wdziękiem nadpisać kod sesji w linku powyżej?) bez konieczności modyfikowania samej biblioteki? Something like PHP's session directives in php.ini. Przypuszczam, że można argumentować, że jest to bardzo ogólne pytanie pythonowe, ale mam problem ze znalezieniem odpowiednich informacji, a także nie jestem pewien, czy zadziała w tej bibliotece.

lub alternatywnie, w jaki sposób korzystać z transportu XHR-odpytywania gevent-socketio w poprzek różnych pracowników i serwerów (bez stickyness)?

Dzięki!

Answer 1

Jest to oczywiście ograniczenie socketio. Z tego, co widzę w Internecie, obsługa sesji jest zwykle wykonywana na warstwie struktury sieci Web, a nie na serwerze WWW. socketio próbuje zrobić to na własnej, niższej warstwie i robi to w ograniczony sposób. Sądzę, że autorzy uważali, że pełne rozwiązanie byłoby przesadą. W twoim przypadku okazały się błędne.

Istnieją tylko dwa sposoby na pokonanie ograniczeń, które wymagają zmiany logicznych: łatanie łatanie i źródła w środowisku wykonawczym. Wybierz to, co ci się najbardziej podoba (lub, cóż, odrazę najmniej: ^)). Dla drugiej opcji sugeruję zastąpić request_tokens i/lub kod, który tworzy go z innym obiektem z tym samym interfejsem. Z powodów wymienionych w pierwszym akapicie, naprawdę myślę, że autorzy socketio prawdopodobnie zaakceptują łatę źródłową, która pozwoliłaby jej wykorzystać zewnętrzne mechanizmy obsługi sesji, jeśli je zaproponujesz.

standardowe lokalizacje dla informacji o sesji są: wspólna pamięć, pliki, bazy danych. Proponuję zmienić logikę w taki sposób, aby socketio korzystał z tego samego mechanizmu, co robi twoja struktura sieciowa (lub cokolwiek, co komponuje twoje strony).

Answer 2

Spójrz tutaj przykładów:

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

To pokazuje, jak używać Redis jako rozproszonej kolejki komunikatów

Answer 3

tylko myśl, jak mam ten sam problem; zamiast pozwolić gunicornowi widelcowi (z flagą -w), być może mógłbyś odrodzić wiele procesów gunicorn na różnych portach, a następnie użyć nginx, aby zrównoważyć je za pomocą "upstream" block with "sticky" session. Uważam, że w ten sposób implementacja nodejs radzi sobie z wieloprocesowymi robotami, kiedy nie dzielą się państwami z Redis.