7

私の状況では、現在、WebSocket リスナーを使用してサーバー側で Node.js を使用するオンライン アプリケーションを作成しています。2 つの異なる部分があります。1 つはページを提供し、node.js と express+ejs を使用します。もう 1 つは、WebSocket 用の socket.io ライブラリのみを含む完全に異なるアプリです。ここで、websockets 部分のスケーラビリティーの問題に行き着きます。

私たちが見つけた解決策の 1 つは、redis を使用してサーバー間でソケット情報を共有することですが、アーキテクチャのために他の情報の負荷を共有する必要があり、サーバーに大きなオーバーヘッドが発生します。

このイントロの後、私の質問は、WebSocket に Cookie ベースの負荷分散を使用することは可能ですか? したがって、Cookie server=server1 を使用したユーザーからのすべての接続は常に server1 に転送され、Cookie server=server2 を使用したすべての接続は server2 に転送され、そのような Cookie を使用しない接続は最も負荷の低いサーバーに転送されます。

更新: 1 つの「答え」が言うように - はい、私はこれが存在することを知っています。名前がスティッキー セッションであることを覚えていませんでした。しかし問題は、それが websocket で機能するかどうかです。考えられる合併症はありますか？

4

1 に答える 1

5

Node.js プロダクション スタックでも同様の問題が発生しました。通常のユースケースで機能するWebSocketを使用する2つのサーバーがありますが、ロードバランサーが2つのサーバー間でこれらの接続をバウンスし、問題が発生することがあります. (バックエンドにセッ​​ション コードがあり、修正されているはずですが、適切に処理されませんでした。)

これらのサーバーの前にある Barracuda ロード バランサーで Sticky Session を有効にしようとしましたが、動作方法が原因で WebSocket トラフィックがブロックされることがわかりました。オンラインで入手できる情報がほとんどないため、正確な理由は調査していませんが、バランサーが HTTP リクエストのヘッダーを取り除き、Cookie を取得し、リクエストを正しいバックエンド サーバーに転送する方法によるものと思われます。WebSockets は HTTP として開始され、その後アップグレードされるため、ロード バランサーは接続の違いに気付かず、同じ HTTP 処理を実行しようとします。これにより、WebSocket 接続が失敗し、ユーザーが切断されます。

以下は、現在非常にうまく機能している場所です。バックエンド サーバーの前に Barracuda ロード バランサーを引き続き使用していますが、ロード バランサーでスティッキー セッションを有効にしていません。バックエンド サーバーでは、アプリケーション サーバーの前に HAProxy があり、これは WebSocket を適切にサポートし、スティッキー セッションを「回り道」で提供できます。

リクエストフロー一覧

  1. 着信クライアント リクエストがプライマリ Barracuda Load Balancer にヒットする
  2. ロード バランサーは、アクティブなバックエンド サーバーのいずれかに転送します
  3. HAProxy がリクエストを受け取り、新しい「スティッキー Cookie」をチェックします
  4. Cookie に基づいて、HAProxy は正しいバックエンド アプリケーション サーバーに転送します。

リクエストフロー図

 WebSocket Request  /--> Barracuda 1 -->\   /--> Host 1 -->\   /--> App 1
------------------->                     -->                -->
                    \--> Barracuda 2 -->/   \--> Host 2 -->/   \--> App 1

矢印が 1 つの要求に戻る場合、その要求はフローのいずれのポイントにも流れることができます。

HAProxy 構成の詳細

backend app_1
   cookie ha_app_1 insert
   server host1 10.0.0.101:80011 weight 1 maxconn 1024 cookie host_1 check
   server host2 10.0.0.102:80011 weight 1 maxconn 1024 cookie host_2 check

上記の構成では:

  • cookie ha_app_1 insert実際に使用される Cookie 名です
  • cookie host_1 checkまたはcookie host_2 checkクッキー値を設定します
于 2012-08-08T20:36:31.400 に答える