問題タブ [sticky-session]

私は2つのサービスを持っています:

1. Nginx を使用した RESTful/websocket API サービス (2 つのレプリカ)

2. デーモン サービス (1 つのレプリカ)

デーモン サービスは、ある時点で Websocket イベントをフロントエンドに送信します。ただし、デーモン サービスからフロントエンドにイベントが正常に発行されていないようです。

また、API サーバーからフロントエンドにイベントを発行しようとしたところ、イベントは正常にフロントエンドに発行されました。(フロントエンドが API WebSocket サーバーに接続されているためかもしれません)。

私がスティッキーセッションのために行ったこと：

私たちの ALB は、複数のターゲット グループに登録されています。各ターゲット グループは、同じドメインの下で Web サイトの異なる部分を提供する個別の Web アプリケーションです。

スティッキー セッション Cookie エンコーディングの実践に関するAWS ドキュメントのスニペットを次に示します。

ロードバランサーは、クライアントから最初にリクエストを受け取ると、リクエストをターゲットにルーティングし、AWSALB という名前の Cookie を生成します。この Cookie は、選択されたターゲットに関する情報をエンコードし、Cookie を暗号化し、クライアントへの応答に Cookie を含めます。

これが私たちが直面していることの要約です

• クライアントが並列リクエストを行う場合、どのリクエストにもまだ AWSALB Cookie がないため、セッション スティッキは機能しません。

• クライアントが単一のブロッキング リクエストに続いて複数の並行リクエストを行う場合、最初のブロッキング リクエストを処理したターゲット グループでのみスティッキが機能します。残りの並列リクエストが他のターゲット グループを対象としている場合、ターゲット グループの情報はまだ AWSALB Cookie にエンコードされていないため、スティッキ性はありません。

ここでの 1 つの解決策は、さまざまなターゲット グループをヒットするために、さまざまな URL に対して一連の連続したリクエストを作成して、各ターゲット グループとの粘着性を確立することです。ただし、これは実用的ではありません。連続したブロッキング リクエストを行うと、クライアントの速度が低下するからです。

単一のリクエストですべてのターゲット グループに関するセッション スティッキネス情報をエンコードするように ALB に指示する方法があるかどうか疑問に思っていましたか? この場合、各ターゲット グループ間でフォローアップ要求がスティッキになるように、すべてのターゲット グループに対してスティッキ性が確立されます。

.Net に LoadBalanced WebServer があります。ユーザーが Web サイトにログインするとき、そのユーザーの次のリクエストが同じ Web サーバーに送られるかどうかはわかりません。そのため、SqlServer DB に asp.net セッションを保存すると、サーバー間でリクエストが切り替わったときにユーザーを認識する問題が解決されます。

jboss eap 7.2 でスティッキー セッションを処理する方法を知りたいです。Apache の worker.properties worker.lbStore.sticky_session=1 で変更が行われました。しかし、リクエストごとに JSESSIONID ノードの変更がまだ見られます。

ありがとう。