SignalRを使用してクライアントUIを更新するアプリケーションがあります。現在、アプリは私たちが維持しているIISでホストされており、クライアントは私たちに直接接続されています。
ただし、これを企業全体のフレームワークに統合する過程にあり、アプリを内部に格納します。引き続きアプリをホストしますが、ページにアクセスした人は誰でも、負荷分散戦略であると言われていることを実行します。 「スティッキーセッションでアクティブ/アクティブとして設定されたリージョンごとに2つのゲートウェイサーバー」
私の質問は、SignalRがトランスポートプロトコルとしてロングポーリングを選択し、どういうわけか接続が切断された場合に問題が発生するかどうかです。
申し訳ありませんが、負荷分散についての知識はあまりありません。
どんな助けでも大いに感謝されます。
さて、あなたが本当に「スティッキー」セッションを使用していると仮定すると、スティッキーのために次のリクエストが同じ基盤となるサーバーに戻るはずなので、接続が切断されることは問題ではありません。結局のところ、スティッキーセッションとは、HTTPの標準の要求/応答モデルを、複数の要求の過程で同じサーバーに戻すことです。したがって、長いポーリングは、応答が長く/ストリーミングされる標準的な要求にすぎないため、標準のスティッキーセッションの実装とうまく統合する必要があります。
考慮する必要があるのは、障害または保守のためにサーバーAを失った場合はどうなるかということです。スケールアウトされたメッセージバスソリューション（Redis、Azure SB）を使用していない場合、サーバーAからサーバーBに移行するときに、メッセージが失われたり失われたりする可能性があります。