5

私は現在、ワーカー socketio.sgunicorn.GeventSocketIOWorker を使用して、gunicorn サーバーを使用して複数のワーカー間で gevent-socketio をスケーリングしようとしています。それ以外の場合は、XHR ポーリング (IE など) を強制しています。

XHR ポーリングには、次のポーリングを追跡するためのセッションが必要ですが、ワーカーが 1 つから 2 つ以上になるとすぐに、要求がそれらの間で広がり始めます。つまり、状態が失われ、すべてが崩壊します。

次のコード行が関連していると思います: https://github.com/abourget/gevent-socketio/blob/master/socketio/handler.py#L104-106 他のストレージ エンジンが必要だと思います。私は通常の pubsub-action に使用していますが、これは実際のライブラリの奥深くにあります。

私の質問は、ライブラリ自体を変更することなく、アプリケーション内でメモリ内セッション ストレージから別のバックエンド エンジンにグローバルに移動する方法です (上記のリンクのセッション コードを適切にオーバーライドしますか?)。php.ini の PHP のセッション ディレクティブのようなもの。これは非常に一般的な python の質問であるという議論ができると思いますが、関連情報を見つけるのに苦労しており、このライブラリで機能するかどうかもわかりません。

または、別の方法として、gevent-socketio の xhr-polling トランスポートをさまざまなワーカーとサーバー間で (スティッキーなしで) 使用するにはどうすればよいですか?

ありがとう！

4

3 に答える 3

3

これは明らかに socketio の制限です。Web で確認できることから、セッション処理は通常、Web サーバー層ではなく Web フレームワーク層で行われます。socketio はそれを独自の下位層で実行しようとし、制限付きで実行します。著者は、本格的な解決策はやり過ぎだと考えていたと思います。あなたの場合、彼らは間違っていることがわかりました。

ロジックの変更を必要とする制限を克服するには、ソースにパッチを適用する方法とランタイムにパッチを適用する方法の 2 つしかありません。最も気に入ったものを選択してください (または、まあ、嫌悪感が最も少ないものを選択してください :^) )。2 番目のオプションについては、同じインターフェイスを持つ別のエンティティで、および/またはそれを作成するコードを置き換えることをお勧めします。request_tokens第 1 段落で述べた理由により、socketio の作成者は、提案された場合に外部セッション処理メカニズムを利用できるようにするソース パッチを受け入れる可能性が高いと思います。

セッション情報の標準的な場所は、共有メモリ、ファイル、データベースです。socketio が Web フレームワーク (またはページを構成するもの) と同じメカニズムを使用するようにロジックを変更することをお勧めします。

于 2012-10-28T12:30:21.303 に答える
0

ここで例を見てください：

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

redis を分散メッセージ キューとして使用する方法を示します。

于 2012-11-23T13:02:59.447 に答える
0

私は同じ問題を抱えているので、ちょっと考えてみてください。gunicorn を (-w フラグを使用して) フォークさせる代わりに、異なるポートで gunicorn の複数のプロセスを生成し、nginx を使用して「スティッキー」セッションの「アップストリーム」ブロックを使用してバランスを取ることができます。Redis と状態を共有しない場合、nodejs 実装がワーカーのマルチプロセッシングを処理する方法はこれだと思います。

于 2015-03-19T21:36:59.613 に答える