問題タブ [sticky-session]

URL パラメーターに基づいて接続をスティッキーにすることが可能であることはわかっています :

URLパスのIDに基づいてそれを行うことも可能ですか?

私のURLが次の場合: /objects/:objectId

どうにかして :objectId を使用して接続を固定することはできますか?

編集

以下の構成を使用して、URL パスでリクエストをスティッキーにする負荷分散を行うことができました。

現在の問題は、サーバーの 1 つがダウンした場合、スティック テーブルが更新されないことです。サーバーの 1 つに到達できない場合、そのサーバーを指すスティック テーブル内のエントリが削除されるようにするにはどうすればよいですか?

最終回答

わかりました、私はそれを理解することができました。以下の構成では、リクエストが URL パスに固定され、HAProxy は 250 ミリ秒ごとに /health への HTTP GET を作成し、200 を返さない場合はサーバーがダウンしていると見なし、スティックからすべてのエントリを削除します。テーブル。

nodejsクラスタリングとスティッキーセッションのドキュメントと、これに関する別のスタックオーバーフローの回答を調べました

上記のスニペットが fork せずに実行された場合は正常に動作しますが、スレッドが開始されてもサーバーが初期化されない上記のクラスター化された例に示されているように動作しません。

スティッキークラスターの代替手段があることを読みました。誰かがこのトピックについて適切な信頼できる回答を与えることができます。これは、同じものを探している人にとって役立ちます。これに伴う別の主な問題は、変数を保存するために使用される app.locals オブジェクトです。アプリインスタンスと複数のサーバーインスタンスが発生すると、インスタンスごとに値が異なるため、これが壊れます。このアプローチは大きな問題を引き起こし、アプリが壊れます。答えるときは、コードをコピーして貼り付けないでください。その利点と欠点にアプローチします。

sticky-sessions nodejs モジュールの使用に限定された答えを探しているわけではありません。プロセッサのすべてのコアが使用され、セッションの継続性が保証される他のすべてのアプローチを歓迎します。

RedisStore や MongoDb ストアが関係する場合は問題ありません。知りたいのは、セッション継続性を備えたクラスタリングを使用する nodejs アプリケーションの場合の標準的なアプローチについてです。

https://github.com/indutny/sticky-session

https://nodejs.org/api/cluster.html

https://stackoverflow.com/a/37769107/3127499

NGINX をキャッシュ レイヤーとして使用してきましたが、最近負荷テストを行ったときに、異常な問題に遭遇しました。負荷テストでは、すべてのコンテンツでキャッシュ ミスしか発生しませんでした。

トラフィックは次のように流れます: クライアント > NLB > NGINX > ELB (スティッキ性) > アプリケーション層

少し分析とトラブルシューティングを行った結果、この動作の理由は、負荷インジェクターが送信するリクエストに「AWSELB」スティッキー Cookie が含まれていないことが原因であるという結論に達しました。Cookie が設定されていない場合、AWS ELB は AWSELB の値を含む「set-cookie」を送信し、キャッシュ コントロール: no-cache="set-cookie"も含めます。

「no-cache」ディレクティブがあるため、NGINX は、Cookie が送信されない限り、期待されるキャッシュ エントリを作成しません (この時点以降のリクエストは、キャッシュ ヒット動作を行います)。多くのリンク/質問とドキュメントを調べてきましたが、これまでのところ解決策を見つけることができませんでした. 誰かがこれを経験しましたか?どのように対処しましたか?

サンプルリクエスト:

サンプル応答スニペット:

問題の署名に最も近い投稿/記事ですが、CloudFront に適用され、それがどのように処理されたかについての詳細はありません: https://forums.aws.amazon.com/thread.jspa?messageID=362272

HTML5 キャンバスでの共同描画用の Node.js アプリケーションを作成しています。通信に Socket.IO を使用しており、クラスタリングを実装しているため、アプリケーションをスケーリングできます。私の講師は、クラスタリングを使用するのは良いアイデアだと言いましたが、CPU のすべてのコアに同じことをさせるのは賢明ではありません。つまり、目的に反します。したがって、私の場合、まったく同じペインティングで 8 つのコアを使用するのは賢明ではありませんが、代わりに 8 つの異なるペインティング (コアごとに 1 つのペインティング) を使用することもできます。また、Socket.IO は 1 つのコアを介してのみ通信することも知っています。今、私はどこから、どのように始めるべきかについて少し混乱しています。この「粘着性のある」socket.ioモジュールがあることは知っていますが、それは通信を共有するだけで、コアごとに異なる絵を作成しませんか?

これが私が作ったサーバーです：