meteor - SockJS と meteor: ロード バランサーがスティッキー セッションをサポートしていない場合はどうなりますか?

Question

Meteor のバランス調整オプションを検討しています。この記事は非常にクールに見え、Meteor の負荷を分散するために以下をサポートする必要があると書かれています。

1. モンゴオプテーリング。そうしないと、10 秒ごとに DB のポーリングと差分を行うポーリング Mongo ドライバーが使用されるため、Meteor の 1 つのインスタンスが別のインスタンスから更新を取得するのに最大 10 秒かかる場合があります。
2. ウェブソケット。これも明らかです。そうしないと、クライアントは HTTP とロング ポーリングにフォールバックしますが、これは機能しますが、Websocket ほどクールではありません。
3. 「SockJS に必要なスティッキー セッション」。ここで質問が来ます：

私が理解したように、「スティッキー セッション サポート」は、セッション中に 1 つのクライアントを同じサーバーに割り当てるものです。それは不可欠ですか？スティッキー セッションをまったく構成しないとどうなりますか?

これが私が自分で思いついたものです：

1. Meteor はクライアントに送信されたすべてのデータをメモリに格納するため、クライアントが X サーバーに接続すると、X 倍のメモリが消費されます。
2. たとえば、異なるタブやウィンドウで、同じユーザーに対してマイナーな (または oplog がない場合はメジャーな) 遅延が発生することがありますが、これは驚くべきことです。
3. SockJS が再接続し、再接続後も一部のデータを維持したい場合、うまくいきません。SockJS の仕組みがよくわからないのですが、この点は有効ですか?

どんな悪いことが起こりますか？これらの 3 つのポイントはそれほど悪くはありません。データは有効であり、利用可能であり、追加のメモリ消費が発生する可能性があります。

Answer 1

基本

スティッキー セッションは、ブラウザのメモリ内セッションをサーバーが正しく管理できるようにするために必要です。

最初に、スティッキー セッションが必要な理由を説明します。

通常のパブリッシュ カーソルを使用する各パブリッシュは、クライアントが持つ可能性のあるコレクションを追跡します。そのため、何かが変更された場合、何をクライアントに送り返すかを認識します。これは、DDP 接続が必要な場合、すべての Meteor アプリに適用されます。これは、websockets と sockjs の場合です。

さらに、変数に保存されている他のクライアント セッション状態が存在する場合がありますが、これらはエッジ ケースです (たとえば、ユーザーの状態を変数に保存します)。

サーバーが切断して再接続すると問題が発生しますが、何らかの理由で接続が別のノードに転送される可能性があります (新しい接続を再確立せずに)。

SockJS とロング ポーリングの問題

SockJS には追加の問題があります。SockJS は、長いポーリングにフォールバックするときに websocket エミュレーションを使用します。

ロング ポーリングでは、新しいデータが利用可能になるたびに、新しい接続試行/新しい http 要求が行われます。

スティッキー セッションが有効になっていない場合、これらの各接続はランダムに異なるノード/ダイナモに割り当てられます。

したがって、新しいデータが利用可能になるたびに、サーバーがクライアントの DDP セッションについてまったく知らない可能性が 50% あります (ランダムの場合) 。

次に、クライアントに接続の再ネゴシエーションを強制するか、クライアントの DDP コマンドを無視するように強制し、クライアントで非常に奇妙な動作が発生することになります。

これらの半分は、間違ったノードに送信されます。